Don't constexpr All the Things - David Sankel [CppNow 2021] 

Glad you enjoyed it!

The ability to express code that _can_ be runtime or compile time is extremely important. I do wish that consteval was added in a much earlier version of the standard, though, because the inability to reason about metaprogramming in C++ with confidence for so many years has tremendously damaged the reputation of this language.

@@Cons-Cat Old comment, but I feel the need to disagree anyway. If you reach for compile time computation as a tool, I believe you've already made the decision that this is something that must happen at compile time. It's part of the solution to a problem. So if the tool to achieve that solution doesn't guarantee anything, it is not the right tool for the job. From that perspective, constexpr was starting in the wrong end. consteval should have come first. FWIW, in my humble opinion.

Glad you enjoyed it!

There are tons of ways to manipulate types, but the main one relevant to this video is to use meta control flow inside class definitions. template struct tuple { @meta for(int i : sizeof...(Ts)) Ts...[i] @(i); }; This for loop is executed at compile time (during class template instantiation). It walks over each member of the parameter pack and declares a new data member called @(i) with type Ts...[i]. @(x) is an operator that converts strings or integers to identifiers. So, @(0) gives identifier _0, @(1) gives identifier _1, @("foo") gives identifier foo, etc. Ts...[i] is just the i'th element of the pack. The data member declaration is non-meta, so it sinks through the meta scopes (like the for loop's body scope) and is attached to the inner-most enclosing non-meta scope, which is the class-specifier. You can do meta control flow inside namespaces, function definitions, class-specifiers and enum-specifiers. The general strategy is to use C++ at compile time to get data that describes how you want to build your types, and use meta control flow to programmatically define them. Also, this project is definitely not falling behind. The compiler keeps getting more robust, faster and more feature-rich. It compiles Boost Hana (the most challenging template library) 1.67x as fast as clang and 2.42x as fast as gcc. Follow me on twitter! I'm really open to ideas. If somebody has a good feature suggestion I go ahead and implement it. twitter.com/seanbax/status/1411331612260945920

I think the issue is even bigger than just this. The C++ Standard Committee writes the "Guidelines" of the language specifics. C++ has many different available features and tools as it is a both a low and high level language covering multiple paradigms. It is a strongly typed language, it can be used in a procedural way, a functional way, in an OOP way, and with templates Metaprogramming way. The idea behind C++ originally is that it was C with Classes as well as having a few other languages features that C didn't have built in such as a bool type, passing & returning by reference and a few others. C++ has also evolved since then... Yet the major consensus and agreement with the C++ committee that write the standards have agreed on a single principle that has not changed since its inception. The language is to be fast and efficient, based on types, portable across multiple machines and these "rules" well more of a guideline are set to describe the overall "virtual machine" that the C++ compiler ought to be and it's left up to the compiler designers to implement their features in their own manner as long as they yield the desired results based on a specific criteria within a generalized context. This is why Clang versus GCC versus MSV versus Intel versus MIPs versus Ming, etc... possess some features of the languages while others do not and some implement it in one way where others in a different manner. The core idea behind the language is that even though there is a generalized standard, C++ is not Restrictive and doesn't force anyone to do anything within their implementations. It will allow you to shoot yourself in the foot if you don't know what you are doing and this is done by both intent and design. I can write an entire program in C++ without ever using Templates, without ever using Macros, without even ever using Dynamic Memory, nor even classes. I can use #defines just as in C for constants and functions with overloads and still make a workable program. I can also write an entire program strictly in templates without any runtime code nor the use of dynamic memory. I can write a program using Raw Pointers and Pointer Arithmetic managing my own memory or use some library's smart pointers. I can write a program in C++ that is done purely with Macros and Preprocessor Directives. I can write a program that is fully contained with an asm{} block. I can write code that is completely Object Oriented. With C++17+ I can write a program that is done using only Lambdas. I can also write a program that uses only static class member functions. I can write a program that uses any or all of the features. C++ is very powerful language if one knows not only how to use the language but also knows how to design their data sets and their algorithms and knows what type of idiom to use within the right context. I'm also 100% self taught with the language and I've used it along with various libraries and APIs to build a working 3D Graphics / Game Engine with 3D Audio. I understand most of the languages features and knowing when, where and how to use them properly is key. This isn't going to be learnt overnight especially by someone who is new to the language. This takes years of practice, experience, patience, trials and errors along with problem solving skills. You just don't have to understand the language features, but you also need to know your compiler, linker, debugger and their error reporting systems as well as the Hardware & OS that you are targeting. How about when you start to write code that is going to executed on an Intel Architecture where its byte order is in Little Endian and you are working with Unions, Bitfields, binaries while doing some bit twiddling and you need to convert it to be "Network Compatible" where the standard convention is in "Big Endian". Now when you start to work with code that is in terms of Endianness based on a specifically targeted machine, you have to know that it isn't going to be very portable or generic code. Yet with the power of templates and metaprogramming along with preprocessor directives, you can have this test to see what Architect it's going to be executed on and in which Operating System will be handling the assemblers system calls, then you can branch your code to work on the appropriate different architects and platforms accordingly. Does this mean your entire program has to be branched? No, not necessarily it just might be that one specific function where you want a variant for each to run as optimally as you can based on the machine that this function is being called on. So even when you are working in C++ you just don't need to know the language. In most cases many may not need to know Assembly but in various cases you might and this also involves you to also know the hardware and its capabilities as well as the operating system. This also implies that you have to understand what the compiler is doing under the hood as well as what your assembler is doing too and this also implies that you would want a decent understanding of the ISA that you are going to targeting. Now with modern C++ and many of the "std::" library features that are out there they have made it a lot easier to allow your code to easily be more portable and generic over the years but this is only if you choose to use the std:: library. I can write an entire C++ program without std:: and use the simple C runtime library by using fprintf, snprintf_s, malloc, calloc, etc... You as the programmer have the choice to design your program as you see fit as long as it meets the specifications and criteria to your clients. So the core takeaway is that C++ will allow you to drive off a cliff if you are not paying attention to which direction you are driving...

Exactly.

no such thing as xexpressionx or constexpr etc, ts just machine, no nerdx or expx about it, cepitxuxyuax, say, can say,expx etc infix any nmw and any s perfect

I have a feeling that it will soon...

You make an important distinction that gets lost on people. The ability to interpret non-constexpr functions is a language decision; general compiler security is orthogonal to that.

about std::embed: meta-build-systems like CMake already scan the files themselves for what they include to build the dependency tree; and build-systems just check if a file changed, it shouldn't matter if it's a .cpp or a .png file and security, well, if you don't review the code you compile, it doesn't matter if the program gets the content of your /etc/shadow at compile time by the compiler or reads it in itself at runtime

The C++ standard still refuses to acknowledge that files exist and wants to somehow tackle security in lieu of the compiler and build system vendors, that'd be hilarious if it wasn't sad. Not to mention most of the reasons to block #embed weren't even rational: "just parse better" or whatever unfounded and dismissive nonsense the poor guy pushing the idea was getting as answers. Thankfully the C comittee were more open-minded and practical and accepted embed into C23, which likely means we'll get it by default in most C++ compilers. I't's like the C++ committee is missing every appointment with History it can, at this point.

The syntax is a superset of ISO C++. It implements most of the C++ 20 standard. It uses the Itanium C++ ABI. It's as much a C++ compiler as gcc, clang or msvc. All compilers have many extensions, (which are often needed to implement the standard library), Circle just has many more than the others. Switching to Circle is not at all like switching to Rust, because you don't need to learn a new language, and you don't have to recode anything. Start with your existing project and begin using reflection and the other features.

Circle is C++ .. is just a superset of 17. They even wrote a formal proposal to consider its features for the standard. Comparing that to Rust is completely ridiculous.

Yep, exactly. It's so lol: "oh, it's so bad that metaprogramming is a second language inside C++, let's come up with a third "language" then". It's a fantastic logic.

@@TheOnlyAndreySotnikov it's not a "third langauge." It provides a context for executing normal code at compile time. You can eg parse a json with json.hpp and not have to modify anything in that library. The point is to get more use out of existing software.

@@seanbaxter1050 hi sean, I think you're doing great work. What I'm trying to say is, as long as this is not part of the C++ language and implemented in the major compilers, it's "alien". I know the rejection was a bummer, so sorry for that. But even though this looks a lot like C++, it's not standard C++.

"Templates and metaprogramming ARE normal C++" They are not. It is a different syntax with different rules and different behaviour.

@@ABaumstumpf It's like saying that integrals are not normal calculus because they have a different syntax than derivatives. Many programmers are really strange "professionals." If you are a mathematician who knows calculus, you can't say, "I know calculus, but not integrals; they are too complicated and have weird syntax." In programming, it's totally acceptable, for some reason, one can learn 30% of the language and put C++ on their resume. Not only that, they also can aggressively dumb down their colleagues, demanding all around to use the only subset of the programming language they managed to learn.

If you do that (constexpr by default) you will not be able to distinguish what's compile-time and what's run-time, which was your first complaint