Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Design of C++ (1994) [video]

computerhistory.org

Post reply on HN
Print view View original

21–30 of 63 posts

Re: The Design of C++ (1994) [video]

#21

Post by mastax »

netheril96 wrote: post #18
byuu wrote: post #16

Earlier quoted context omitted.

After seeing P0145R3 on C++17 refinements to expression order guarantees (and many things like that before it) ... I think I've finally started to actively dislike C++ now as well, after nearly 20 years of using it daily. They had a golden opportunity to fix it, but even with C++17 and the expression "a(b(), c());", it is still left indeterminate whether b() or c() will be invoked first. Even between calls in the sam…

The standards body move very slowly. More practical approach is to push compilers to add more options to define undefined behavior so that we have safety with the minor cost of performance. We already have -fwrapv, -ftrapv and -fno-strict-aliasing. We could ask for more and a general -fsafe flag.

UBSan is not quite the same thing, but it's quite good.

http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

Re: The Design of C++ (1994) [video]

#22

Post by yongjik »

byuu wrote: post #16
hga wrote: post #3

Even if you dislike C++, or like me, came to loathe it, I highly recommend the book he published in the same year, The Design and Evolution of C++ ( https://www.amazon.com/Design-Evolution-C-Bjarne-Stroustrup/... ). It's very educational about you go about making a successful language in an existing ecosystem, and even after swearing off the language I don't regret one bit the time I spent reading the book.

After seeing P0145R3 on C++17 refinements to expression order guarantees (and many things like that before it) ... I think I've finally started to actively dislike C++ now as well, after nearly 20 years of using it daily. They had a golden opportunity to fix it, but even with C++17 and the expression "a(b(), c());", it is still left indeterminate whether b() or c() will be invoked first. Even between calls in the sam…

I'm not a big fan of UB either, but keeping the order of argument evaluation indeterminate seems very sensible to me.

Imagine you have a function like f(int, double). If argument evaluation order is fixed, you can no longer exchange the order of arguments: for all you know, someone might be depending on the first argument being evaluated first!

Re: The Design of C++ (1994) [video]

#23

Post by paulddraper »

Koshkin wrote: post #17

The language may seem complex to some, but so does math. It is the single most powerful programming tool the world has ever known. Sure, it may be hard to see that it is beautiful, but that is so only because it is a product of both intelligent design and evolution. The language structure is extremely logical, and there is very little that could be changed in it without the danger of destroying its finely tuned fabri…

> there is very little that could be changed in it without the danger of destroying its finely tuned fabric built from intricately interacting concepts and mechanisms

Really? Very little? Finely tuned fabric?

Is diamond inheritance really part of that fabric? And NULL?

C++ is old and has only accumulated, never lost. When I think "finely tuned fabric", I think of Rust, which has the fortune of decades of learning. C++ piled on rvalues and move semantics. Rust is the one that "tuned" its design.

I'm not dissing C++; it's a true veteran, and has witnessed entire languages rise and fall. But let's be honest: the design of C++ is (as one would expect for a decades-old language) organic, not "finely tuned".

Re: The Design of C++ (1994) [video]

#24

Post by mannykannot »

I finally figured how Dr. Stroustrup can always make C++ seem like not only a reasonable thing, but probably the best possible one. He has chosen a number of goals that, while being reasonable and desirable individually, each tend to complicate the realization of all the others. Consequently, for any of the complications of the language, he can pick a couple of goals and show that they make the complication unavoidable.

Re: The Design of C++ (1994) [video]

#25

Post by wildmusings »

byuu wrote: post #16
hga wrote: post #3

Even if you dislike C++, or like me, came to loathe it, I highly recommend the book he published in the same year, The Design and Evolution of C++ ( https://www.amazon.com/Design-Evolution-C-Bjarne-Stroustrup/... ). It's very educational about you go about making a successful language in an existing ecosystem, and even after swearing off the language I don't regret one bit the time I spent reading the book.

After seeing P0145R3 on C++17 refinements to expression order guarantees (and many things like that before it) ... I think I've finally started to actively dislike C++ now as well, after nearly 20 years of using it daily. They had a golden opportunity to fix it, but even with C++17 and the expression "a(b(), c());", it is still left indeterminate whether b() or c() will be invoked first. Even between calls in the sam…

>They had a golden opportunity to fix it, but even with C++17 and the expression "a(b(), c());", it is still left indeterminate whether b() or c() will be invoked first.

If the order of b() and c() matter, then they shouldn't be in the same statement. That is an abomination. What you little you gain in terseness, you more than make up for in future headaches.

Re: The Design of C++ (1994) [video]

#26

Post by pjmlp »

netheril96 wrote: post #18
byuu wrote: post #16

Earlier quoted context omitted.

After seeing P0145R3 on C++17 refinements to expression order guarantees (and many things like that before it) ... I think I've finally started to actively dislike C++ now as well, after nearly 20 years of using it daily. They had a golden opportunity to fix it, but even with C++17 and the expression "a(b(), c());", it is still left indeterminate whether b() or c() will be invoked first. Even between calls in the sam…

The standards body move very slowly. More practical approach is to push compilers to add more options to define undefined behavior so that we have safety with the minor cost of performance. We already have -fwrapv, -ftrapv and -fno-strict-aliasing. We could ask for more and a general -fsafe flag.

> We already have -fwrapv, -ftrapv and -fno-strict-aliasing.

You have it in specific compilers, not in the standard.

Not everyone is able to go installing clang and gcc on their work platform, when there are so many compilers to choose from.

https://en.wikipedia.org/wiki/List_of_compilers#C.2B.2B_comp...

Re: The Design of C++ (1994) [video]

#27

Post by byuu »

wildmusings wrote: post #25
byuu wrote: post #16

Earlier quoted context omitted.

After seeing P0145R3 on C++17 refinements to expression order guarantees (and many things like that before it) ... I think I've finally started to actively dislike C++ now as well, after nearly 20 years of using it daily. They had a golden opportunity to fix it, but even with C++17 and the expression "a(b(), c());", it is still left indeterminate whether b() or c() will be invoked first. Even between calls in the sam…

> They had a golden opportunity to fix it, but even with C++17 and the expression "a(b(), c());", it is still left indeterminate whether b() or c() will be invoked first. If the order of b() and c() matter, then they shouldn't be in the same statement. That is an abomination. What you little you gain in terseness, you more than make up for in future headaches.

That is not an abomination. Turning this:

    int val = a(b(c(), d()), e(f(), g()));
Into this:

    auto _1 = c();
    auto _2 = d();
    auto _3 = b(_1, _2);
    auto _4 = f();
    auto _5 = g();
    auto _6 = e(_4, _5);
    int val = a(_6);
Is the abomination.

Expecting every programmer to know that a(b(), c()); may call b() first or may call c() first is an abomination. Having a programmer's app work fine on most PCs, and then suddenly having a security vulnerability that takes down my server because a compiler dev decided to exploit this on my system in order to save two clock ticks on a 4GHz CPU is an abomination.

Here's a more tangible use case:

    template void print(P&&...);
    print("The value of: ", binaryObject.getNextToken(), " is ", binaryObject.getNextToken(), "\n");
Looks sensible, until you find out that the compiler decides to switch the parameter ordering and you get the value before the name.

And it's not just me: the point of that PR was because people were doing exactly that with cout completely random.

Re: The Design of C++ (1994) [video]

#28

Post by byuu »

yongjik wrote: post #22
byuu wrote: post #16

Earlier quoted context omitted.

After seeing P0145R3 on C++17 refinements to expression order guarantees (and many things like that before it) ... I think I've finally started to actively dislike C++ now as well, after nearly 20 years of using it daily. They had a golden opportunity to fix it, but even with C++17 and the expression "a(b(), c());", it is still left indeterminate whether b() or c() will be invoked first. Even between calls in the sam…

I'm not a big fan of UB either, but keeping the order of argument evaluation indeterminate seems very sensible to me. Imagine you have a function like f(int, double). If argument evaluation order is fixed, you can no longer exchange the order of arguments: for all you know, someone might be depending on the first argument being evaluated first!

If there's really a performance advantage to argument reordering then you can do it whenever there are less than two arguments that may have side effects. Safe instances would be:

* constants

* regular variables that aren't using the cast constructor for implicit conversion

* member functions marked const

* constexpr functions

You would only need to actually evaluate function calls that may change global state, or that perform in-place assignment (eg f(x += 1, x += 2)).

I will take the performance impact of doing something 'stupid' like calling f(a(), b()) instead of splitting the expression up into three lines any day over potentially introducing a security vulnerability that I don't even know about and that the compiler doesn't warn me about any day of the week.

Performance is not the be-all end-all of the world. We should not make critical applications insecure in order to get our apps to be 0.0001% faster.

> If argument evaluation order is fixed, you can no longer exchange the order of arguments: for all you know, someone might be depending on the first argument being evaluated first!

... I don't understand how moving from arbitrary argument evaluation ordering to fixed argument evaluation ordering can possibly turn any valid code existing today into bad code. Quite the opposite, it has the potential to fix a lot of code. Anything that relied on the arguments being evaluated backward (I don't even know of a compiler that does that ... yet) would have been technically broken per the previous language specs anyway. So I don't know what point you are trying to make here, sorry.

Re: The Design of C++ (1994) [video]

#29

Post by byuu »

netheril96 wrote: post #18
byuu wrote: post #16

Earlier quoted context omitted.

After seeing P0145R3 on C++17 refinements to expression order guarantees (and many things like that before it) ... I think I've finally started to actively dislike C++ now as well, after nearly 20 years of using it daily. They had a golden opportunity to fix it, but even with C++17 and the expression "a(b(), c());", it is still left indeterminate whether b() or c() will be invoked first. Even between calls in the sam…

The standards body move very slowly. More practical approach is to push compilers to add more options to define undefined behavior so that we have safety with the minor cost of performance. We already have -fwrapv, -ftrapv and -fno-strict-aliasing. We could ask for more and a general -fsafe flag.

I definitely use -fwrapv already. Unfortunately, there is no -fhonor-precedence-associativity switch in GCC or Clang. And I would need it in both to support all the systems I target.

But even moreso, yes!! I would love if we had a -fsafe directive that turned undefined behavior from "do whatever is fastest" into "do whatever is most expected." I would seriously start paying $100 a year to use such a compiler -- not even joking a little.

Unfortunately, as I've said, the compiler devs seem to have lost touch completely with the developers using the language and love playing these nasty games with UB. So I'm not sure how we can go about getting them to implement such a flag. And I just don't have the bandwidth to fork and maintain GCC or Clang to do it myself =(

Re: The Design of C++ (1994) [video]

#30

Post by [deleted] »

byuu wrote: post #16
hga wrote: post #3

Even if you dislike C++, or like me, came to loathe it, I highly recommend the book he published in the same year, The Design and Evolution of C++ ( https://www.amazon.com/Design-Evolution-C-Bjarne-Stroustrup/... ). It's very educational about you go about making a successful language in an existing ecosystem, and even after swearing off the language I don't regret one bit the time I spent reading the book.

After seeing P0145R3 on C++17 refinements to expression order guarantees (and many things like that before it) ... I think I've finally started to actively dislike C++ now as well, after nearly 20 years of using it daily. They had a golden opportunity to fix it, but even with C++17 and the expression "a(b(), c());", it is still left indeterminate whether b() or c() will be invoked first. Even between calls in the sam…

[deleted]
Post reply on HN