The Design of C++ (1994) [video] • Hacker News Board

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

#31

Post by yongjik » Sat, Sep 10, 2016, 6:29 AM UTC

byuu wrote: post #28

yongjik wrote: post #22

Earlier quoted context omitted.

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 th…

My scenario is:

* There's a function f(int, double), called in ~100 places, written by many different people.

* For some reason I decide to change it to f(double, int). Consistency, or preparing for some other refactoring, whatever.

* I have to track down ~100 occurrences of f and exchange arguments. Time-consuming but no big deal.

* If any code was dependent upon compiler silently evaluating the arguments in a particular way, then the code was broken, and reasonably competent coders don't write too much broken code. (Moreover, such a dependency is 99% likely to be broken by random changes in codes or compiler options, so chances are that I wouldn't encounter too many such bugs.)

In your world, it is just about impossible. If I want to go ahead, I could either change every occurrence into:

    int arg1 = ...;
    double arg2 = ...;
    f(arg2, arg1);

...or pore through every line calling f to see if it's safe.

C++ already has a reputation of being a difficult language to refactor, and your proposal will make it about impossible.

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

#32

Post by shin_lao » Sat, Sep 10, 2016, 6:51 AM UTC

paulddraper wrote: post #23

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+…

Is diamond inheritance really part of that fabric?

Diamond inheritance isn't a problem in C++ as each inheritance path is followed separately. A small price to pay to enjoy the power of multiple inheritance.

And NULL?

NULL is deprecated since C++ 11 in favor of nullptr.

C++ is old and has only accumulated, never lost.

You may want to have a look at the latest standards.

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

#33

Post by ScottBurson » Sat, Sep 10, 2016, 6:57 AM UTC

yongjik wrote: post #31

byuu wrote: post #28

Earlier quoted context omitted.

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 th…

My scenario is: * There's a function f(int, double), called in ~100 places, written by many different people. * For some reason I decide to change it to f(double, int). Consistency, or preparing for some other refactoring, whatever. * I have to track down ~100 occurrences of f and exchange arguments. Time-consuming but no big deal. * If any code was dependent upon compiler silently evaluating the arguments in a parti…

I've spent over three decades using languages that guarantee left-to-right evaluation order (Common Lisp and Java), and I have not found this to be a problem in practice.

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

#34

Post by stinos » Sat, Sep 10, 2016, 6:57 AM UTC

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…

I really like your description, it's pretty much the same as how I think about it. But only when I'm in a subjective 'C++ all the things' mood - which happens often, especially since C++14, there's just so much to love about C++.

When I try to be objective about it though, I'd say you are glorifying too much and skipping on the darker sides of it. You and me probably now exactly how to avoid those and that's also exactly one of the reasons why for us C++ is all utter greatness. But when I see inferior, dangerous, ugly, waiting-for-UB code produced by others I realize it's not all that great. Or maybe still great - after all you could blame their lack of knowledge instead of C++ - but I really wouldn't use terms like finely tuned or extremely logcical. Seriously, I've used the language for like 10 years and it still occurs to me that I see a C++ question and corresponding answer on SO which completely baffle me because I had no clue about that particular implementation detail. There aren't many languages like that. Here's one just from today: http://stackoverflow.com/questions/39422188/difference-betwe... granted I would never write that stuff, but also I really couldn't tell 100% sure how 'const int& x = 4;' at classlevel is supposed to behave.

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

#35

Post by pjmlp » Sat, Sep 10, 2016, 7:46 AM UTC

stinos wrote: post #34

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…

I really like your description, it's pretty much the same as how I think about it. But only when I'm in a subjective 'C++ all the things' mood - which happens often, especially since C++14, there's just so much to love about C++. When I try to be objective about it though, I'd say you are glorifying too much and skipping on the darker sides of it. You and me probably now exactly how to avoid those and that's also exa…

That is my feeling when I look at enterprise C++ code, which usually never goes beyond "C with Classes" style regardless of the improvements the language has gotten over the years, which is why in the end I came to be an happy JVM/.NET camper that only uses C++ on side projects or when JVM/.NET projects need a bit of outside help.

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

#36

Post by [deleted] » Sat, Sep 10, 2016, 7:49 AM UTC

vvanders wrote: post #20

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 willing to pay a 5-10% penalty, and give up compatibility with the Motorola 68000 platform, to get well-defined and predictable behavior. Maybe you keep C/C++ for that gaming OS, or that Wall Street trading system. But on my server? I can spare the CPU cycles. Come over to the land of Rust, where you can keep your high performance memory semantics and safety :). Seriously, life-long C++ dev here. Been writing C…

[deleted]

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

#37

Post by pjmlp » Sat, Sep 10, 2016, 7:55 AM UTC

santaclaus wrote: post #19

ArkyBeagle wrote: post #13

Earlier quoted context omitted.

The sort of puppy-dog C++ style on Arduinos - a sort of pedomorphic variation on "'C' with classes", chock full of singletons and the inability of constructors to operate unless they're called in A Certain Place - pretty much works. What's less attractive is Dogmatic Bikeshedding C++ OO Fundamentalism.

> What's less attractive is Dogmatic Bikeshedding C++ OO Fundamentalism. Is that a thing? I always saw more of that in the Java world than C++ -- Java's standard library is rife with the singleton factory decorator monstrosities that have come to be associated with OO, C++ and the standard library have always felt more generic-programy. Now egregious use of obscure template meta programming tricks because of perceive…

When the design patterns book was written it was all about Smalltalk and C++.

I guess you missed the boat on CORBA, COM and DCOM, fun days...

J2EE architects were mostly former C++ architects that moved into Java land.

Also UWP APIs are actually the second coming of COM as .NET was originally supposed to be.

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

#38

Post by msorvig » Sat, Sep 10, 2016, 7:58 AM UTC

byuu wrote: post #27

wildmusings wrote: post #25

Earlier quoted context omitted.

> 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…

But this is not particularly good imperative style. You want that to be line-based when expressions have side effects. ("one thing after another"):

  auto key = binaryObject.getNextToken();
  auto value = binaryObject.getNextToken();
  print("The value of: ", key, " is ", value, "\n");

Of course if you are calling pure functions you can use nested expressions. And then the order of evaluation does not matter.

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

#39

Post by TickleSteve » Sat, Sep 10, 2016, 7:59 AM UTC

ArkyBeagle wrote: post #13

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.

The sort of puppy-dog C++ style on Arduinos - a sort of pedomorphic variation on "'C' with classes", chock full of singletons and the inability of constructors to operate unless they're called in A Certain Place - pretty much works. What's less attractive is Dogmatic Bikeshedding C++ OO Fundamentalism.

its actually the full gcc compiler on arduino.... not that they advertise that.

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

#40

Post by pjmlp » Sat, Sep 10, 2016, 8:27 AM UTC

vvanders wrote: post #20

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 willing to pay a 5-10% penalty, and give up compatibility with the Motorola 68000 platform, to get well-defined and predictable behavior. Maybe you keep C/C++ for that gaming OS, or that Wall Street trading system. But on my server? I can spare the CPU cycles. Come over to the land of Rust, where you can keep your high performance memory semantics and safety :). Seriously, life-long C++ dev here. Been writing C…

I dabble with it every time a new release comes out, but I feel it still lacks many features relevant to me and our customers, ability to easily interoperate with COM like .NET languages, C++/CX, Delphi, C++ Builder do, is one of them.