Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018) • Hacker News Board

Re: Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)

#91

Post by ncmncm » Sat, Apr 13, 2019, 1:58 AM UTC

notacoward wrote: post #88

ncmncm wrote: post #79

Earlier quoted context omitted.

You might have picked the wrong hill to die on. C++ destructors really are deterministic, even in the face of exceptions, lambdas, and moves: everything constructed gets destroyed. Modern wrinkles where the compiler is allowed to skip a construction and a destruction do not contradict that. You have to fool with heap memory or evoke UB to escape that law.

To be useful, determinism has to mean not only that something happens but that it happens at a predictable time . Otherwise you're into that tautological "everything is deterministic" territory, and you step into that even deeper when you acknowledge the "modern wrinkles". "Compiler is allowed" (but not required) is practically the definition of non-determinism.

"Compiler is allowed" not to destroy what it never constructed.

This is no different from the myriad other elisions modern compilers do -- and that CPU cores do.

Deterministically, destructors run exactly when the constructed object goes out of scope, after objects constructed later, before those constructed earlier. More determinism than that is something you will get from nobody.

You don't have to write any constructors at all. Write ordinary functions, and call them whenever you like. Been there, had enough of that for several lifetimes. Destructors are better.

Re: Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)

#92

Post by ncmncm » Sat, Apr 13, 2019, 2:31 AM UTC

signa11 wrote: post #82

ncmncm wrote: post #80

Earlier quoted context omitted.

Code like that is the bane of my existence. Give me `T2 function(T1)` every time. Besides being overwhelmingly clearer, I can use it in just one line. The other needs at least 3, more commonly 5, lines packed around it, so less than 20% of your code actually does anything useful toward the problem it is supposed to solve. Five times longer means you have five times the bugs. Besides being horrible style, operating on…

serious question: would you throw an exception if T2 cannot be created ? or use a variant data-type ? or something else altogether?

Generally, yes, throw.

Sometimes an optional is better, such as when downstream already takes one.

Occasionally, checking whether the operation (and a bunch of others) would succeed is best, particularly in high-rel/high-av systems. There, you are probably also logging, first, what you are about to attempt.

Re: Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)

#93

Post by FrankHB » Sun, Apr 14, 2019, 2:42 PM UTC

dataflow wrote: post #18

notacoward wrote: post #3

Excellent explanation. Too bad it's necessary. && and std::move are the biggest warts in C++ (that's saying a lot), representing the need for programmers to be constantly aware of the less-than-obvious ways that a compiler might put an expression in one category or another. It's the programmer helping the compiler, instead of the other way around as it should be. In general, if I need an rvalue and it's legal to conv…

It's not what what you're asking is unreasonable in concept, but that it goes against how RAII is used in C++; it'd make more sense in a new language. Specifically the issue is that despite its name, RAII isn't merely used for resource acquisition, but also to define dynamic scopes. That means destroying an object too early (which can happen if an object is automatically moved) can cause a subsequent statement that d…

Dynamic scopes are not available in C++. I suppose them as in languages like Emacs Lisp. I get the point, though.

Re: Lvalues, rvalues, glvalues, prvalues, xvalues, help (2018)

#94

Post by FrankHB » Sun, Apr 14, 2019, 3:05 PM UTC

notacoward wrote: post #3

Excellent explanation. Too bad it's necessary. && and std::move are the biggest warts in C++ (that's saying a lot), representing the need for programmers to be constantly aware of the less-than-obvious ways that a compiler might put an expression in one category or another. It's the programmer helping the compiler, instead of the other way around as it should be. In general, if I need an rvalue and it's legal to conv…

This is simply not acceptable because it would silently break too much code. Parameter passing in C++ used to mean copy, not move.

Perhaps a more important rule is that id-expressions should mean lvalues, not xvalues. Note that even expressions of rvalue references are not xvalues in such contexts. So, making something to-be-moved visually different from others is quite intentional.

Alternatively, to prevent use-after-move cases by additional syntaxes with typechecking rules (like Rust) can be a good idea, but it also does not work here. And C++ still lacks destructive move. (Note this has been considered at the very beginning of the design. Sadly it does not easily interact well with other features. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n137...)