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

41–50 of 63 posts

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

#41

Post by willtim »

msorvig wrote: post #38
byuu wrote: post #27

Earlier quoted context omitted.

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.

I believe the issue is that C++ does not track what are, and are not pure functions, so the ordering optimisation is, in general, unsafe.

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

#42

Post by byuu »

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…

Ah, I understand what you're saying now. I guess we'll have to agree to disagree, then.

I am much more interested in predictability in my code than I am about reordering arguments in mature codebases.

Lots of languages guarantee expression ordering to follow precedence and associativity rules, and I've never heard anyone say that it was a problem to refactor their code as a result.

Whereas I am 100% certain that there are lots of codebases where this is a ticking timebomb with developers unintentionally relying on the order their compiler decides to evaluate expressions in. And it will blow up when, not if, the GCC devs find some micro-optimization and decide to reverse things on them. And that's not just a problem for them, it's a problem for everyone who relies on their code.

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

#43

Post by byuu »

msorvig wrote: post #38
byuu wrote: post #27

Earlier quoted context omitted.

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.

> You want that to be line-based when expressions have side effects.

No, I really don't. I don't want three lines instead of one line of code. And I don't want two named variables leaking into my scope. (I could encapsulate the block with {} here, but if print returned a value that I wanted to capture, then I couldn't do that.)

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

#44

Post by blub »

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

Rust isn't finely tuned either, it just has memory safety (finely) turned up to 11.

I wouldn't call C++'s design organic, just severly constrained by backwards compatibility. It is finely tuned, but the results are not even close to an ideal that didn't consider C. Finely tuned doesn't imply perfection.

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

#45

Post by cousin_it »

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…

Hey, try compiling this:

    templateclass C{Ca;Cb;};Cc;
(c) Marc Aldorasi

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

#46

Post by krylon »

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.

I agree. I only spent very little time with C++, but that book was both highly interesting and very entertaining to read. Highly recommended!

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

#47

Post by cynicalkane »

shin_lao wrote: post #32
paulddraper wrote: post #23

Earlier quoted context omitted.

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

I don't think the usual criticisms of NULL are satisfied by it becoming slightly more type-safe.

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

#48

Post by izym »

cynicalkane wrote: post #47
shin_lao wrote: post #32

Earlier quoted context omitted.

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.

I don't think the usual criticisms of NULL are satisfied by it becoming slightly more type-safe.

References don't allow null.

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

#49

Post by humanrebar »

shin_lao wrote: post #32
paulddraper wrote: post #23

Earlier quoted context omitted.

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

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

Pedantically, it's discouraged, not deprecated. NULL is a preprocessor constant defined in so many places, often in contradictory ways. There's no practical way for the C++ standards to deprecate it.

Compiler and analysis tools vendors could (and should) provide warnings when NULL is used when nullptr is more appropriate (which is always IMO).

Post reply on HN