3 ms·
UB? What? That's completely off-topic. Please stop that, it's annoying. I can't imagine what LTO should have to do with that either, but if there's any substan
by jstimpfle 3y ago
UB? What? That's completely off-topic. Please stop that, it's annoying.
I can't imagine what LTO should have to do with that either, but if there's any substance here please enlighten me.
The order in which destructors get called is well defined (and generally useful insofar as it's the reverse order of construction). Can't you just accept a simple argument? I'm not even a huge fan of RAII, but it has its uses.
- nwlieb 3y agoThere's some ambiguity for argument destruction order for example: https://stackoverflow.com/a/36992250 https://stackoverflow.com/a/36992250 Similarly, the construction/destruction order for std::tuple elements is not well defined. Granted, that's implementation defined behavior, which is technically deterministic on a single compiler.
- jstimpfle 3y agoThis isn't really about constructors/destructors. Expressions like function calls with multiple arguments have always been "unsequenced" with respect to each other. In other words the order is left to decide for the compiler. It's always been like that, going back to C (and probably other languages). If you call f(x++, x++) what values get passed to f is unspecified. I suppose the destruction of whatever the expressions constructed still happens in reverse order of construction. But either way I might not even care, I'm aware that at the level of a single statement the execution sequences aren't much defined, so I rarely put more than one mutating thing per expression, or otherwise I'm sure that I don't care about the order -- I could live with any sequence as well as totally parallel execution. Example: buf[i++] = 5 has 2 mutating sub-expressions, but I know it's not messing up anything. I don't care whether i gets incremented before 5 gets assigned or the other way around.