3 ms·

At a 168 pages, I only had time to skim it, but this was much better than I thought it would be. He honestly addresses many of my complaints about C++. In the

by mtzet 5y ago

At a 168 pages, I only had time to skim it, but this was much better than I thought it would be. He honestly addresses many of my complaints about C++. In the discussion of variant, optional and any: - He bemoans that "The possibility of direct language, as opposed to standard-library, support appears not to have been seriously considered" - He acknowledges that "variant and friends address an important problem, but inelegantly." - He considers variant, optional and any a "stop-gap measure" - In discussion of a pattern matching library he acknowledges the need for "both closed sets of alternatives (algebraic types) and open sets (class hierarchies)." and explicitly says the aim is to remove the visitor pattern (whereas c++17 just added std library syntax for it) In the modules discussion (9.3.1), he also identifies the problem that "[the hello world program] yields 419,909 characters for the compiler to digest". I wish he'd also address visiblity specifiers at a module level, rather than just at a class level. In the static reflection discussion (9.6.2), he discusses the typical problem of iterating over members of a struct. This is indeed a point where C++ has not really progressed much since ANSI C. The discussion of error handling in chapter 7 felt a bit lacking. My main problem with exceptions isn't performance, but that I can't determine if I've handled all error conditions. The idea of using exceptions for non-local errors and error codes for local errors is too vague. It also doesn't really make error codes much easier to use. For my money, I still think that using error codes and providing syntactic sugar for dealing with the common boilerplate is the best compromise. I can accept exception/panics when they are not supposed to be caught, but just cleanly terminate the application. Maybe C++ will solve these problems in the future (C++23? C++26?), maybe not. In the meantime, the new languages on the block are attractive because they solve these problems _today_.

Negitivefrags 5y ago
I find it surprising that anyone could imagine that the creator of C++ is unaware of its issues. I’m sure he appreciates them better than almost anyone else and would be the first to acknowledge them. But compromises have to be made to create a useful langague and path dependency means that sometimes the sub-optimal long term choice is still the right choice to make right now.
- mjburgess 5y ago
  It's more the attitude of various creators. Some have a jobsian "this is how you should do it"; others frenetic, "next time it'll be perfect", others, "you dont really need this!". Etc.
- mtzet 5y ago
  > I find it surprising that anyone could imagine that the creator of C++ is unaware of its issues. While C++ adds a lot of new features, it does very little to solve the problems inherited from C. The lack of static introspection, a real module system and tagged unions are all inherited from C. I do think it's fair to think that if a problem is not addressed in 30 years, it just might not be considered important. Adding tagged unions is not a sophisticated language feature. Fat pointers (c++20 std::span) also seems like a no-brainer. Maybe I'm biased by hindsight, but these features were implemented by contemporaries like Pascal? Actually, the paper also contains a great section about fat pointers: > The obvious solution is to supply an abstraction that holds a pointer plus a size. For example, in 1990, Dennis Ritchie proposed that to the C standard committee: "'fat pointers' whose representation will include the space to store the adjustable bounds at run-time" [Ritchie 1990]. For various reasons, the C committee didn’t approve. At the time, I heard the priceless comment: "Dennis isn’t a C expert; he never comes to the meetings." It is probably good that I don’t remember who said that.
  - pjmlp 5y ago
    We are on the early days of module system, but it kind of works, at least on VC++. You can get tagged unions via std::variant.
blippage 5y ago
"but inelegantly." Yes. Bjarne an co. are reluctant, with good reason, to prefer to extend C++ with objects rather than syntax. The reason being: if you've goofed with your object design, everyone can simply ignore the object, but if you've goofed with your syntax, then you've committed everyone for all eternity. Dealing with variants via the visit() mechanism is pretty verbose, and I couldn't help but think that a nice bit of syntactic sugar wouldn't go amiss there. I was interested in the new coroutine feature in C++. That would seem like a fantastic feature to use on microcontrollers because it implements cooperative multitasking. But aye carumba, The tutorials I've seen on them have blown my mind. Overcomplicated much? I wonder if, at the end of the day, coroutines are fundamentally incompatible with the notion of a stack, and that you're always going to be trying to nail a square peg into a round hole if you try to do it.
- zabzonk 5y ago
  > Yes. Bjarne an co. are reluctant, with good reason, to prefer to extend C++ with objects rather than syntax. I think you either meant to elide "reluctant", or to say "syntax rather than objects".
- pjmlp 5y ago
  The co-routines design is actually quite similar to C# and Kotlin machinery, although many don't realise it. https://devblogs.microsoft.com/premier-developer/extending-the-async-methods-in-c/ https://devblogs.microsoft.com/premier-developer/extending-t... https://kotlinlang.org/docs/coroutine-context-and-dispatchers.html#job-in-the-context https://kotlinlang.org/docs/coroutine-context-and-dispatcher... It gets a bit easier on them thanks GC, but in the end implementing custom co-routine types is of similar complexity level.
- duped 5y ago
  > I wonder if, at the end of the day, coroutines are fundamentally incompatible with the notion of a stack Well it is with stackless coroutines (by definition) but they are a kind of state machine. Without a stack or heap as an escape hatch they are quite limiting (as in they aren't Turing Complete by themselves). Stackful coroutines are much more powerful and give you pretty much every kind of control flow you need (while still being strictly less powerful than continuations). It is possible for a compiler to detect whether a coroutine should be stackless or stackful, in principle at least.

by mtzet 5y ago

Negitivefrags 5y ago

I find it surprising that anyone could imagine that the creator of C++ is unaware of its issues. I’m sure he appreciates them better than almost anyone else and would be the first to acknowledge them. But compromises have to be made to create a useful langague and path dependency means that sometimes the sub-optimal long term choice is still the right choice to make right now.

mjburgess 5y ago
It's more the attitude of various creators. Some have a jobsian "this is how you should do it"; others frenetic, "next time it'll be perfect", others, "you dont really need this!". Etc.
mtzet 5y ago
> I find it surprising that anyone could imagine that the creator of C++ is unaware of its issues. While C++ adds a lot of new features, it does very little to solve the problems inherited from C. The lack of static introspection, a real module system and tagged unions are all inherited from C. I do think it's fair to think that if a problem is not addressed in 30 years, it just might not be considered important. Adding tagged unions is not a sophisticated language feature. Fat pointers (c++20 std::span) also seems like a no-brainer. Maybe I'm biased by hindsight, but these features were implemented by contemporaries like Pascal? Actually, the paper also contains a great section about fat pointers: > The obvious solution is to supply an abstraction that holds a pointer plus a size. For example, in 1990, Dennis Ritchie proposed that to the C standard committee: "'fat pointers' whose representation will include the space to store the adjustable bounds at run-time" [Ritchie 1990]. For various reasons, the C committee didn’t approve. At the time, I heard the priceless comment: "Dennis isn’t a C expert; he never comes to the meetings." It is probably good that I don’t remember who said that.
- pjmlp 5y ago
  We are on the early days of module system, but it kind of works, at least on VC++. You can get tagged unions via std::variant.

blippage 5y ago

"but inelegantly." Yes. Bjarne an co. are reluctant, with good reason, to prefer to extend C++ with objects rather than syntax. The reason being: if you've goofed with your object design, everyone can simply ignore the object, but if you've goofed with your syntax, then you've committed everyone for all eternity. Dealing with variants via the visit() mechanism is pretty verbose, and I couldn't help but think that a nice bit of syntactic sugar wouldn't go amiss there. I was interested in the new coroutine feature in C++. That would seem like a fantastic feature to use on microcontrollers because it implements cooperative multitasking. But aye carumba, The tutorials I've seen on them have blown my mind. Overcomplicated much? I wonder if, at the end of the day, coroutines are fundamentally incompatible with the notion of a stack, and that you're always going to be trying to nail a square peg into a round hole if you try to do it.

zabzonk 5y ago
> Yes. Bjarne an co. are reluctant, with good reason, to prefer to extend C++ with objects rather than syntax. I think you either meant to elide "reluctant", or to say "syntax rather than objects".
pjmlp 5y ago
The co-routines design is actually quite similar to C# and Kotlin machinery, although many don't realise it. https://devblogs.microsoft.com/premier-developer/extending-the-async-methods-in-c/ https://devblogs.microsoft.com/premier-developer/extending-t... https://kotlinlang.org/docs/coroutine-context-and-dispatchers.html#job-in-the-context https://kotlinlang.org/docs/coroutine-context-and-dispatcher... It gets a bit easier on them thanks GC, but in the end implementing custom co-routine types is of similar complexity level.
duped 5y ago
> I wonder if, at the end of the day, coroutines are fundamentally incompatible with the notion of a stack Well it is with stackless coroutines (by definition) but they are a kind of state machine. Without a stack or heap as an escape hatch they are quite limiting (as in they aren't Turing Complete by themselves). Stackful coroutines are much more powerful and give you pretty much every kind of control flow you need (while still being strictly less powerful than continuations). It is possible for a compiler to detect whether a coroutine should be stackless or stackful, in principle at least.