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

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

#81

Post by Rusky » Thu, Apr 11, 2019, 11:57 PM UTC

mehrdadn wrote: post #77

Rusky wrote: post #71

Earlier quoted context omitted.

Automatic moves don't imply that you can't use RAII to define dynamic scopes. In fact it's the reverse- moves give RAII much more power and flexibility around scopes. The problem, instead, is that C++ has no way to determine whether later statements depend on moved-from variables. To a first approximation, this could be solved using the same analysis that powers "use of uninitialized variable warnings." In the genera…

No, lack of good code analysis is not the problem. If the compiler was to only do a move in cases where it could prove variable independence then it would be operating under the as-if rule -- which it is already allowed to do -- and hence your code wouldn't behave any differently than if it hadn't done that. Automatic moves OTOH change the semantics of the code, which is kind of the point -- the compiler can't do an…

Yes, we're discussing an alternative design here. An automatic move should change the semantics of the program, rendering later uses invalid.

This does not break RAII- it merely changes the defaults. It should be copies that are marked in the program source, not moves- this is unfortunately not backwards compatible, but it's also not a problem for how RAII gets used.

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

#82

Post by signa11 » Fri, Apr 12, 2019, 12:03 AM UTC

ncmncm wrote: post #80

leetcrew wrote: post #76

Earlier quoted context omitted.

> Out-parameters are a terrible choice in C++ why? I personally love functions like `EResult function(const T1& inParam1, T2& outParam2)`. the function signature makes it obvious what the function does (or should do, at least) and it's easy to avoid accidental copying.

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?

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

#83

Post by nixpulvis » Fri, Apr 12, 2019, 12:10 AM UTC

steveklabnik wrote: post #29

Sharlin wrote: post #20

Earlier quoted context omitted.

Few other languages have move semantics. Rust does, but has a quite different value model overall.

Our equivalent to lvalue/rvalue is “place expression” and “value expression” https://doc.rust-lang.org/reference/expressions.html#place-e...

I like that so much more!

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

#84

Post by bigcheesegs » Fri, Apr 12, 2019, 12:52 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?

Use a variant type like llvm::Expected.

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

#85

Post by dbaupp » Fri, Apr 12, 2019, 1:14 AM UTC

Rusky wrote: post #72

dbaupp wrote: post #64

Earlier quoted context omitted.

Why would moving a list have to allocate a new tail node? A lot of the value in moves is passing data around without having to copy/duplicate/allocate. The most useful aspect of having customisable move constructors like in C++ seems to be things like updating pointers in self-referential types, which hopefully can be written to never throw.

It's unfortunate but some C++ standard library implementations do require allocation in some moves (notably, IIRC, Microsoft's std::list). So we're stuck with it.

Huh, that is unfortunate!

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

#86

Post by userbinator » Fri, Apr 12, 2019, 1:21 AM UTC

meuk wrote: post #11

Articles like this make me feel very smug about my decision never to go down the rabbithole of learning C++. I feel perfectly comfortable with using pointers (and my intuition about them) in C.

To me, knowing C++, especially the "modern" dialect, is good for job security but like you I prefer plain old C for everything else.

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

#87

Post by signa11 » Fri, Apr 12, 2019, 3:07 AM UTC

bigcheesegs wrote: post #84

signa11 wrote: post #82

Earlier quoted context omitted.

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

Use a variant type like llvm::Expected.

yup, that's what i thought. i generally tend to use a construct simiar to 'error_or' though. that wrapped within a macro (^^) makes the whole invokation quite bearable

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

#88

Post by notacoward » Fri, Apr 12, 2019, 12:05 PM UTC

ncmncm wrote: post #79

notacoward wrote: post #70

Earlier quoted context omitted.

> I can't stress that enough. You can stress an untrue statement all you like. Shout it to the heavens. It will still be untrue. Thought for you to consider: the behavior might seem predictable to you but that's not a relevant standard. A chess opening, a volleyball play, a snowboard run might all seem straightforward to me, but that doesn't mean they'd suit everyone. It doesn't mean they're the best. It just means I…

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.

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

#89

Post by notacoward » Fri, Apr 12, 2019, 12:07 PM UTC

tjoff wrote: post #73

notacoward wrote: post #70

Earlier quoted context omitted.

> I can't stress that enough. You can stress an untrue statement all you like. Shout it to the heavens. It will still be untrue. Thought for you to consider: the behavior might seem predictable to you but that's not a relevant standard. A chess opening, a volleyball play, a snowboard run might all seem straightforward to me, but that doesn't mean they'd suit everyone. It doesn't mean they're the best. It just means I…

The behavior is predictable to anyone versed in the language. C++ is a complex language to learn so that is inherently harder than most alternatives, but the concepts here are not. I am first in line to acknowledge the flaws of C++ as well as sheering on more modern approaches. But I do find your criticisms shallow and a quite oddly chosen.

> The behavior is predictable to anyone versed in the language.

Ahh, there's that "don't care about the blubs" arrogance again. Never mind that your interlocutor is about 99.9% likely to be less of a blub than you are. Whether behavior is predictable given arbitrary amounts of information and effort is not the point. What matters is how much it distracts the programmer from the non-language-specific problem they're really trying to solve, and the answer for C++ remains way too damn much even when the programmer is highly skilled and well versed in the language.

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

#90

Post by tjoff » Fri, Apr 12, 2019, 2:11 PM UTC

notacoward wrote: post #89

tjoff wrote: post #73

Earlier quoted context omitted.

The behavior is predictable to anyone versed in the language. C++ is a complex language to learn so that is inherently harder than most alternatives, but the concepts here are not. I am first in line to acknowledge the flaws of C++ as well as sheering on more modern approaches. But I do find your criticisms shallow and a quite oddly chosen.

> The behavior is predictable to anyone versed in the language. Ahh, there's that "don't care about the blubs" arrogance again. Never mind that your interlocutor is about 99.9% likely to be less of a blub than you are. Whether behavior is predictable given arbitrary amounts of information and effort is not the point. What matters is how much it distracts the programmer from the non-language-specific problem they're r…

You know you reek of it yourself.

C++ and even C has tons of subtle edges that are impossible to keep track of. You need to be experienced to have a fighting chance, I'm not defending that. But it is a fact of life and in a large part of that are relics from the past.

You can't just take a concept that is somewhat unique to C++ and proclaim that it is bad just because C++ has a lot of warts. Your criticism doesn't even register on the weirdness scale in my opinion. It works as intended, is easy to reason about and solves practical problems. Object lifetimes is something I almost always miss when I don't use C++. A garbage collector is hell to work with in comparison.

What is unfortunate is that we don't really have any alternatives. Rust shows promise but we've had to suffer through decades to even get to this point, which also implies that we have decades left. And that assumes that rust continues in the pace it has and preferably also that we get more alternatives to chose from.