Const vs. constexpr vs. consteval vs. constinit in C++20
cppstories.com
cppstories.com
Without the giants aligning their interests I’m afraid there will be a split in the community. Clang’s std C++ library is already behind GCC’s because Apple and Google have “moved” on.
Apple moved to Swift, but what has Google moved to?
No, come on Herb, Kate Gregory has told us why there are variables, they are names for things. The machine doesn't need names, but the human maintenance programmers do. As a Microsoft employee I'm going to hazard a guess that Herb spends a lot less time staring at C++ real humans wrote before they died/ retired/ got fired without notice than Kate does in her consulting job. She knows what she's talking about.
(The exception is closures; prohibiting a variable from being reassigned after it's been closed over is useful because anyone reading the code may expect one of two conflicting behaviors depending on context, and so it's good to instead write the code in a way that doesn't have that ambiguity. Java got this one right.)
A post articulating this point, by the person primarily responsible for Rust's shared-xor-mutable architecture (so presumably he has some idea what he's talking about, though note that his argument did not carry the day): https://smallcultfollowing.com/babysteps/blog/2014/05/13/foc...
Yes I do write my own libs as well but those are very domain oriented and mostly serve needs of particular application. Nothing exciting there.
May I ask you why? The whole preprocessor macro thing is just a disgusting hack that compiles slowly, is error prone and is not even expressive enough for the most basic of things.
Full rebuild of the project took 14 seconds.
While it is not blazing speed like one gets with the likes of Delphi, Go, etc. it is still quite ok. I am a practical person and can tolerate couple of seconds of compile-run in return to convenient libs.
And it is sure expressive enough to give me what I want. Yeah, writing template libs is something but fortunately other than writing template here and there I do not really have to do this kind of work.
In reality if the applications are of any decent size there is basically no difference time-wise doing those either in C++ with libs or PHP/JS/Python. I have fair practical experience on this.
As for open source - I run 2 companies and do a lot of development myself. I have family and also do a lot of fitness so I can creak along at my young age of 60. You get the drill.
I've found that the way I'm most productive is by using data-oriented design where I put everything in structs and don't use classes. I still use a lot of modern C++ library features, but it reads more like C.
For example:
struct BufferPool
{
alignas(PAGE_SIZE) char frames[BUF_POOL_NUM_FRAMES][PAGE_SIZE];
std::atomic_uint32_t free_frames[BUF_POOL_NUM_FRAMES];
std::atomic_uint32_t pin_count[BUF_POOL_NUM_FRAMES];
std::atomic_bool is_dirty[BUF_POOL_NUM_FRAMES];
std::atomic_uint32_t page_id_to_frame_idx[];
};
std::span<const char>
BufferPool_get_record(BufferPool* pool, RecordID rid, int db_file_fd);
For a long time, I tried to cram everything I wrote in C++ into an OOP pattern with classes, and it just didn't jive with me. Then I stopped doing that and started writing it more like TypeScript/Kotlin/C which I'm more familiar with and it's been a lot more pleasant ever since.
There's been so much great stuff in C++ 17/20/23 and you can just cherry pick all the bits you want to use out of it and ignore the rest.
So using one over the other doesn’t really change anything with regards to data oriented design.
It's just a small annoyance to have to put "public:" at the top of every data-class definition
So I use structs everywhere but you're completely right, no real difference
It’s mostly just a mental marker for myself that I want to treat one as a value type.
I know logically/semantically they're equivalent. The v-table function generated if the method is moved inside the class/struct winds up being identical.
Dunno what it is, some kind of familiarity bias with the way the code is laid out I guess, not coming from OOP languages
In this case, the addresses of all the methods are known at compile time and the compiler knows which to choose when anyone is invoked in the source code, based on the type of the object and on the types of the method arguments.
When there is at least one "virtual" method and you have a pointer to an object, the type of the object cannot be known at compile-time, so the compiler cannot determine which method to invoke.
That is why the compiler needs to create a table with pointers to the virtual methods for each class with such methods, and each object of those classes must include a pointer to the corresponding vtable, so that the correct method to invoke can be determined at run time (from the index of the virtual method).
Even if the method is virtual, C++ compilers make an effort to call methods directly without indirection through a vtable wherever possible.
A long term ambition for C++ and more specifically for Bjarne has been UFCS, Universal Function Call Syntax, which a few other languages have. But C++ can't do this today.
``` struct foo { void bar(); }
bar(foo* i) { assert(i != nullptr); i->bar(); } ```
work, but there's enough syntactic complexity in the language that it isn't as easy as it should be.
Example: https://godbolt.org/z/6Y1raxMce
https://en.cppreference.com/w/cpp/language/object#Polymorphi...
Unless you add some additional semantics/keywords, it's not going to create a vtable.
> Dunno what it is, some kind of familiarity bias with the way the code is laid out I guess, not coming from OOP languages.
I'm sure that's what it is.
I do understand that it’s just a snippet of code to show a style, so ignore this pedant!
What re alternatives for a system programming language? (Rust seems to be fine, but still it's not super easy...)
I agree with your broader point but parameter packs (aka, variadic templates) were an addition to templates made in C++11. So strictly speaking they have gotten more complex.
It'd be I think reflection, however that ends up looking, that's the next actual feature set expansion of templates.
For context: I've been writing code in C++ for most of my career (25+ years) and being for VFX/3D rendering it was mostly performance critical code. Now I write Rust for some very performance critical tasks in finance ...
Define 'permitteed'. Unsafe is, among other things, exactly that. It tells rustc to permit you to do things that are ... well, unsafe. Including the ones you listed.
Maybe you don't understand the meaning of unsafe in Rust?
Unsafe causing UB is a possibility. As is taking two &mut refs to the same memory location using exactly that keyword. And that example works for multi-threaded Rust code using a shared resource accessed as such too.
In practice, it seems like the C/C++ model has some glaring flaws anyway, so I can’t say that Rust’s is really “worse”. But since Rust has this mission to be better than C++ in terms of safety, this is one of thorny issues of Rust that need to be tackled to really let its advantages shine.
https://fzn.fr/readings/c11comp.pdf
And also
https://plv.mpi-sws.org/scfix/paper.pdf
Though maybe these issues were fixed in C++20 (which I only learned till recently that they’ve revised their memory model there!)
Both threads can now change the Goose at the same time. That's a data race. As a result it destroys Sequential Consistency, but that barely matters in C++ because it also is Undefined Behaviour, your program no longer has any meaning.
In (safe) Rust it won't let you give both A and B a way to mutate the same Goose at the same time, thus data races can't occur, thus you have Sequential Consistency, and your program has a defined meaning.
You can presumably argue that all those things aren't "permitted" but there is no way to detect for sure if you wrote any of them, and if you did your entire C++ program has no defined meaning and might do anything at all.
There's a reason this exists. Rice's Theorem says non-trivial Semantic questions are Undecidable. You thus can't always correctly decide whether a program has some non-trivial semantic property, but C++ wants to require a whole lot of such properties. So, when it's difficult they just say the compiler must err on the side of emitting nonsense programs.
[Rust takes the other path here, if the Rust compiler can't be sure that your program has the required semantic properties you get an error. This is rare but annoying, typically you can easily modify your program to satisfy the compiler or when you try to do so you realise actually the compiler was right, this program doesn't have the required semantic properties]
I am increasingly confident that C++ made the wrong choice here, neither of these outcomes is desirable but the Rust outcome has a negative feedback loop - if changes make Rust's compiler annoy more programmers with spurious errors there's pushback. The C++ approach has positive feedback, as C++ gets less well-defined people's compilers accept whatever nonsense they wrote, nobody tells the committee to stop doing this - until one day it blows up in their face.
Use existing C++ libraries/code. I love Rust, or at least what I've seen of it since I haven't gotten the pleasure to use it in a meaningful capacity, but it's naive to pretend existing code can just be re-written and therefore existing languages should stop improving.
I do think it'll be fascinating to see how the performance of Rust and C++ ends up shaking out head to head. That is, how much is Rust actually sacrificing in performance by reducing the amount of UB (if anything, or if other aspects allow for better performance on average)
Out-of-bounds index access is a borderline case; both languages have a safe index operation wherein out-of-bounds accesses trap, and a fast one wherein they're undefined behavior. However, C++ gives the convenient bracket syntax, which programmers are likely to reach for by default, to the fast behavior, and requires the safe behavior to be spelled out ("at"), while Rust does the reverse (the fast behavior is "get_unchecked" or "get_unchecked_mut"). Also it seems that not all relevant data types in the C++ standard library support the safe behavior, which is unfortunate.
In all other cases (that I can think of), Rust prevents undefined behavior at runtime not by changing it to do something defined at runtime instead, but by requiring the programmer to prove to the compiler that the undefined behavior can't happen. This may be annoying, and may encourage programmers to resort to things like RefCell that have runtime costs in order to avoid the difficulty of such proofs, but it should never stop you from doing the unsafe maximum-performance thing if you really want to.
Rust can also do some optimizations that C++ can't; it has additional forms of undefined behavior, like mutable aliasing and invalid UTF-8 strings, that the compiler can in principle exploit. Probably the more important advantage, though, is that Rust's maintainers can freely make changes to its compiler and standard library that don't preserve compatibility with existing compiled code (as opposed to existing source code), because the language has never promised ABI stability and (unlike C++) doesn't have an entrenched community of users who count on ABI stability and will complain if it's broken. Almost all Rust binaries statically link all dependencies except for libc, and build all statically-linked dependencies other than the standard library (which is tightly coupled to the compiler) from source on every compilation, and this has been the case since the language's beginning. For an explanation of why C++'s need to preserve backwards compatibility for compiled code inhibits optimization, see: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20...
As for your other point, I think Rust will need smoother C++ interop than it currently has before it can displace C++, but there's hope. Here's the project I'm currently most optimistic about: https://github.com/google/crubit
Cuda :(
At least variadic generics isn't really a performance thing, it's just an example of a rough edge you run into here and there. Specialization and placement can be pretty important for performance though!
Template metaprogramming is not a language feature that is needed when I write code that is close to the metal.
Again, templates are not a feature that is part of the close-to-the-metal part of C++.
What exactly does template metaprogramming in C++ allow you to do that you could not do in Rust? In the context of performance critical code?
Besides, Rust has generics and macros. The latter are arguable as powerful (if almost as cumbersome to debug) as C++ templates.
That’s not a thing you want from a programming language. What you can express is just as important as what you can’t.
C++ won't let you define new types at runtime, but the advantage there is you know that the rest of your C++ codebase won't be doing that. It won't let you reflect on runtime data, but that means various changes you make to your program are undetectable outside of bounds (class or translation unit, sometimes shared library).
Forth or assembly will let you do whatever the hardware is game for because either can emit raw bytes and then interpret them as machine code. The cost is you have, at best, conventions about what the rest of the codebase is doing.
If you push too hard towards high performance in C++ the language lets you down. Aliasing rules mean data must be always atomic or never, and can't sometimes be an array of simd values. Or fno-strict-aliasing which costs you elsewhere. No control over calling conventions, instruction selection, register allocation or scheduling. On the bright side you can usually force partial evaluation well enough with template instantiations, but you can't have the inverse where you explicitly fold equal machine code implementations on different types. Plus trivial stuff like the embarrassment of unique_ptr imposing overhead if you pass it to a function. So C++ will get you within N% of optimal, most of the time, and that's usually good enough.
In C/C++, the language designers can't take anything out. That would break things. There's so much legacy code.
C hasn't even totally removed "strcat", etc. yet. That should have been removed in the previous century.
If you've moved on then your insight is outdated.
The ideal modern C++ without having to worry about "deprecated" ways of coding, is more the exception than the rule.
That doesn't even make sense. Maybe you meant "destructors" but even then it has nothing to do with reality
> a group of obviously related units of which the degree and nature of the relationship is imperfectly known[0]
It's impossible for any single person to understand how the C++ language interacts with itself without a reference manual: it's grammar can lead to the most vexing parse; it has metaprogramming builtin using templates or macros, allowing for arbitrary code execution at compile time; it has a ridiculous number of ways to construct an object (move constructors, copy constructors, default constructors, is the object heap or stack allocated, are you using bracket initialization or parenthesis, etc); and more.
Also, I pointed this out in a comment awhile ago, but as of C++17 and over 20 years of writing technical books about C++, Scott Meyers doesn't trust himself to determine whether a given code snippet is or is not valid C++:
> It's not that I'm too lazy to do it. It's that in order to fix errors, I have to be able to identify them. That's something I no longer trust myself to do.[1]
If this language isn't considered complex, I don't know what is.
[0]: https://www.merriam-webster.com/dictionary/complex
[1]: https://scottmeyers.blogspot.com/2018/09/the-errata-evaluati...
Personally, I prefer to use C (C89) which is high-level enough to be reasonably productive, while at the same time not high-level enough to discourage the creation of overly complex code.
There are surprisingly frequent posts here from people who have written their own C compiler. I don't think I've seen a single C++ one yet.
Of course, it's a joke. In reality C++23 has only 20 ways to initialize a variable:
I like to be able to do more compile-time evaluation and it's definitely a lot less confusing now than abusing templates for that.
The comments all seem like just mindless anti-C++ circle jerking, with zero relevance to what's actually being discussed in the article. But that's sadly quite common with C++ articles here. If the title has C++, expect to see the same rants regardless of the article.
As for `constinit`, it looks like ziglang doesn't have an answer for the problem that constinit solves. That is, ziglang appears to have the same bugs here that C++ did before constinit was added.
zig has lazily initialized at runtime mutable globals, and compile-time initialized constant globals (so C++'s constexpr variables). But what it doesn't have is compile-time initialized mutable globals (which is what `constinit` does)
// compile-time initialized mutable global:
var foo = bar();I'm not sure how to reconcile that Zig documentation with your comment's claim. It appears that Zig relies on opportunistic behaviors here instead of contracts. That is, your var foo could be comptime known, but isn't required to be. Which is fine enough, but not comparable to `constinit` either.
Alternatively if all container variables are exclusively comptime initialized, then the obvious missing part from Zig would be the inverse of constinit which is the onload initializer behavior.
When is onload? I don't think that's a time that occurs during program execution in Zig.
If not then that'd be the 3rd type of initialization it's missing, the equivalent of C++'s nothing specified.
You can order the init sections on your own when you generate the binaries and add your own constraints, and if your toolchain doesn't give you that control, you can generate and call your own init functions. (Since I didn't want to dick with the linker too much, I generated my own init functions in my natively compiled language to solve this problem).
Your language's dlopen wrapper can also dlsym the initializer and call it if it's present.
This is very much a C++ problem, because its separate compilation model throws away initializer ordering, and prevents the compiler from doing anything about it. And, of course, compatibility makes this a tough sell for C++ -- languages unconstrained by history don't have to worry about this.
tl;dr: Ignore the constructor attribute/init section, and generate your own function that orders things correctly. Then call it before main.
How does my shared library do that?
def loadlib() {
lib = dlopen("libfoo.so")
sym = dlsym(lib, "pkgname.__init__")
sym()
return lib
}
If you have a DAG of dependencies, it's impossible for your library to care whether main or dlopen has called its initializer, because the same initialization order of dependencies is observed in either case. The only thing you need to beware of is guarding against double-init if you dlopen, and the generated library-level initializer code can do that.
If you generate a single initialization symbol that guards against multiple runs in the init section, this works just fine with dlopen.
This isn't even hard, but you need to be able to form a full dag of imports.
The only problem is that the linker slams together the .init, .ctors, or .init_array sections in some arbitrary order (usually the order that .o files are passed in on the command line, but there are no guarantees). If you topologically sorted the object and library list by import order, things would work out. But because the linker doesn't cooperate, a language that wants to avoid the initialization order fiasco needs to provide its own ordering. Or its own linker.
As far as Zig goes -- I have no clue what it does. Never touched it.
Also, as a side note -- initializers were initially designed so that there would be exactly one init function per binary or library, and then people wanted to split the initialization up, so the way the init section ends up getting constructed on most unixes is fascinatingly hacky: The linker links `crti.o`, your .o files, `crtn.o`. crti.o contains a function prologue; the init sections in your .o files contain a sequence of call functions, and crtn.o contains a function epilogue. Stitch them all together in order, and you get a single function that you can call.
This is deprecated, and now there's a table of function pointers (.init_array).
This is a very widely used capability and it is very definitely not trivial to just make an init function & define the import dag and have that work reliably. People will forget to call it & most of the time they won't have any clue what their dependency DAG even is. And that's assuming it can even form a DAG at all - cyclic dependencies are absolutely a thing, after all.
And I'm not sure how you can forget to import a library and still expect to use it, assuming your language has a module system.
C and C++ can't solve this problem, of course, due to textual inclusion.
no, it isn't because your library has to integrate with other languages when you make native stuff. I should be able to call dlopen from any native language without having to care in which language your library was implemented, just calling my OS's dlopen / LoadLibrary OS API function should be enough. If this doesn't work, then your solution is just not acceptable in many cases, so yes you have to work with its limits.
People want to initialize stuff at load library time. They will always want to do this. If the language doesn't provide a solution, people will just bolt on shitty add-on toolchains to do it anyway.
This isn't a uniquely C++ problem (__attribute__((constructor)) is after all for C, not C++).
Take for example Rust, which also doesn't provide an attribute((constructor)) equivalent and says nothing happens before or after main. Except https://crates.io/crates/ctor exists to immediately say "fuck that noise" and racked up >20m downloads.
You realize Java has the feature you're discussing, without dependency injection?
class Foo {
static {
initialize();
}
}
https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.htm..., section 8.7, with order defined in section 12.4
So no, that's not equivalent. Not even close. This is why you see things in Java that scan through loaded jars looking for all classes with attributes to just speculatively load. To recreate what c++ has natively & C has with a broadly supported extension.
Consider: C++ let's an increasingly large subset of the language be evaluated at compile.
Current endpoint: the whole language will have constexpr everywhere.
Correct design: Eagerly try to evaluate everything, ban things that obviously shouldn't or can't be done at compile time.
And thus 'constexpr' - it can run in both modes, depending on when & where it's called.
'consteval' then is for when it must happen at compile time, which is a rather narrow (but very useful!) subset of constexpr.
Now, what is silly is that `if constexpr` is only allowed to happen at compile time. That should have been `if consteval` instead, the ordering of these additions is unfortunately reversed.
It should be explicit on what the program is going to put out, especially in a language like C/C++. When you're writing code close to the metal, you need to make sure it's exactly what you wrote. It may be a target platform difference, since I don't use the STL and mainly using C++ language features to target extremely low level devices or goals. In an application dev environment, I can see how constexpr "doing it for you" is fine, but the fact they only had one and not the other is a travesty and has so many footguns.
For example, I wrote a DRM program that required an additional buildstep to yell at the developer if they exposed strings or confidential information in the binary. This is solved by consteval, which should've been in there since the beggining.
consteval is helpful in iterations during development to catch that, and I like it as such, but it's definitely not a constexpr replacement nor what constexpr should have been. It's a very small subset of constexpr usages.
`constexpr` makes "you can use this at compile time" an explicitly documented attribute of the function, instead of just a guess or by needing to read the implementation.
There were already a bunch of places in the language that required compile-time evaluation- array sizes, template args, static_assert, case expressions, etc. "Can be" is all about enabling existing APIs to be used in those contexts. You can't (and don't want to) force those APIs to run exclusively at compile time, because programs are already using them at runtime all over the place!
This talk about compile time evaluation got some people thinking about all the other things they'd like to do at compile time. And there is a way to do that with just `constexpr`- `constexpr` variable initializers are a new "compile-time-only" context just like array sizes/etc, so you can decide at the leaves what to compute ahead of time, without forcing the callees to be exclusively compile time.
But there seems to be some kind of disconnect in how people learn about constexpr, where they hear "compile time" and imagine a different design than what actually went into the language, then get even more confused when they hear "can be" and imagine it as something that happens at the compiler's whim rather than deterministically based on the calling context.
Did you mean C11 there or C++11? I'm not sure why C11 is relevant in a discussion about C++. MSVC's support of C has been abysmal for ages, but this has no reflection on its C++ support. Of which it definitely supports all of C++11. And 14. And 17. And even complete support for C++20
For C++20, GCC is "only" missing module support, but otherwise supports everything else. Clang is lagging behind, though.
>For C++20, GCC is "only" missing module support, but otherwise supports everything else. Clang is lagging behind, though.
Then I'll rephrase: it's not only not available widely, it's not available at all.
- [1](https://www.stroustrup.com/P0977-remember-the-vasa.pdf)
The basic Windows / Linux versions of the cheapest commercial Ada package only recently dropped to high 4-figures / seat. The equivalent cross-compilers are still $$,$$$.
constexpr variables are constant and usable in constant expressions
constinit variables are not constant and cannot be used in constant expressions
constexpr can be applied on local automatic variables; this is not possible with constinit, which can only work on static or thread_local objects
you can have a constexpr function, but it’s not possible to have a constinit function declarationconsteval is applied to functions and asserts that a function definition can be evaluated at compile time, and only at compile time, for all possible arguments; the compiler is required to check this. This is different form contexpr that merely allows it and possibly only for a subset of the arguments.
constinit is applied to static variables and asserts that the initialization is static (static variables can otherwise still be initialized dynamically on startup or on first use).
I'm a big fan of C++. It's been my primary programming language since 1996. C++11 was awesome! I'm in the minority of the C++ developers that occasionally take the language (and the compilers - just like Internet Explorer was a great pain for "front end" developers for a decade, MSVC was a pain in the a* for C++ developers) for a ride to it's limits.
However, the complexity of the language in C++ 23 is mind mind-boggling.
The complexity in C++ 11 was quite frankly already overwhelming. I've worked as a senior and principle C++ developer in small startups and big established software companies. In the last decade, I've only met a handful of really qualified C++ developers (people who actually know the language, and how to use it effectively). Most of the "Senior C++" developers I've worked with can use basic things in the same way that average Java developers can use Java - but they know nothing about for example template meta-programming or how to do concurrency correctly. Many of them were just C programmers who at some point were thrown into a "C++ project" and learned how to "use classes", but still use C functions for starting new threads. In other words, In 2022 they have not even updated themselves to C++ 11.
It's hard to learn C++ to an advanced level. It's /really/ hard. Most people don't have the personal drive to do it. At least not the majority of the C++ developers I've worked with over the years. They learn the basics, and then just use the knowledge they already have to do their job.
Even I, and friends of mine that are even more enthusiastic about C++ than I am, are starting to feel exhausted by the ever increasing complexity of the language (and the libraries). One of them suggested to me to take a look at Rust. It's a lot simpler to learn Java/Kotlin (applications) or Rust (system programming) than it is even to maintain a good knowledge about C++.
I still think C++ is a lot of fun, and programming exiting things in the language gets me into flow in a way few other activities can. It's also rewarding - I can do incredibly cool things, and I can incrementally improve on the way I solve the same problem each time I run into it in a new project.
But that's me. Most of the C++ code I've seen in small and large companies stinks. The developers have the tool to do wonderful things - but like the Wizard's Apprentice - they don't know the tool very well, and they don't know how to use it. I think most of the projects started today in C++ would be better off written in a simpler language that the developers actually comprehend.
GCC has already added -fconstexpr to implicitly mark all functions as constexpr.
in which sense do you mean this? consider for instance
constexpr int foo(int x)
{ if(x < 0) throw "error"; return x; }
constexpr int a = foo(123); // works fine
constexpr int b = foo(-123); // compile error
int c = foo(-123); // works fine
constexpr is_right_answer(int x){
if (x==42) return true;
else {
std::cout <<"try again \n";
return false;
}
I believe consteval has the semantics you want but I've yet to study it in details.
For more details see: https://www.foonathan.net/2020/10/constexpr-platform/ .
Where'd you see -fconstexpr?
Of course you need the function body to actually do comptime evaluation.