26 ms·

C++ is a great real world example of ignoring the advice "if you find yourself in a hole, stop digging". They have this problem with complexity and the only str

C++ is a great real world example of ignoring the advice "if you find yourself in a hole, stop digging". They have this problem with complexity and the only strategy they have to tackle it is by adding more complexity. Maybe they're going to overflow back to 0. Or they'll come out in China. Who knows. I've moved on.

klyrs 4y ago
I've got my eye on Cpp2... Herb says he isn't interested in making it an official language but I suspect that once it stabilizes it will be an attractive migration.
- elteto 4y ago
  But then you have Google with Carbon… which is a direct competitor to cpp2. Apple hasn’t shown interest in either, and MS will of course most likely support cpp2. Without the giants aligning their interests I’m afraid there will be a split in the community. Clang’s std C++ library is already behind GCC’s because Apple and Google have “moved” on.
  - bsldld 4y ago
    > ...Apple and Google have “moved” on. Apple moved to Swift, but what has Google moved to?
    - elteto 4y ago
      It’s in the process of “moving” on to Carbon.
      - devnullbrain 4y ago
        That is a lot of optimism for a 2022 project from 2022 Google.
        elteto 4y ago
        Everything starts somewhere. I believe Chandler Carruth is leading the project so that means non-trivial resources are being dedicated to it. Their timeline is also fairly aggressive.
        ameliaquining 4y ago
        They're also simultaneously looking at Rust as a possible successor to C++ (e.g., by developing better interop tooling). It's believed that at most one of these projects can succeed in the long term.
        elteto 4y ago
        Interesting, thanks for the insider take. I honestly would love if they went with Rust.
- tialaramex 4y ago
  Herb doesn't even want to default to immutable local variables (what he as a C++ person calls "const by default"). Obviously Cpp2 isn't finished enough for this to necessarily jump out, but Herb figures if we make a variable then we must intend to vary it, which is one of those claims I expect from newbie C++ programmers keen to defend their new language. No, come on Herb, Kate Gregory has told us why there are variables, they are names for things. The machine doesn't need names, but the human maintenance programmers do. As a Microsoft employee I'm going to hazard a guess that Herb spends a lot less time staring at C++ real humans wrote before they died/ retired/ got fired without notice than Kate does in her consulting job. She knows what she's talking about.
  - ameliaquining 4y ago
    I'm honestly not convinced that immutability for local variables is a particularly useful feature. Within the scope of a single function, it's usually pretty easy to see if a variable is being reassigned or not; there aren't the same kind of programming-in-the-large preventing-spooky-action-at-a-distance benefits that come from immutability across API boundaries. You increase the language's complexity and learning curve, for a benefit that's rather speculative and unclear. (The exception is closures; prohibiting a variable from being reassigned after it's been closed over is useful because anyone reading the code may expect one of two conflicting behaviors depending on context, and so it's good to instead write the code in a way that doesn't have that ambiguity. Java got this one right.) A post articulating this point, by the person primarily responsible for Rust's shared-xor-mutable architecture (so presumably he has some idea what he's talking about, though note that his argument did not carry the day): https://smallcultfollowing.com/babysteps/blog/2014/05/13/focusing-on-ownership/ https://smallcultfollowing.com/babysteps/blog/2014/05/13/foc...
    - tialaramex 4y ago
      Notice that what you're asking for is to abolish const local variables. Which also isn't what Herb offers, this was the status quo in C during the K&R era because "const" didn't exist in K&R C. If you actually want const local variables, just not by default, you're not actually agreeing with Niko.
- cpeterso 4y ago
  For people curious about Herb's Cpp2, here's a presentation he gave at CppCon 2022: "Can C++ be 10x Simpler & Safer? (Simplifying C++ #9 of N)" https://www.youtube.com/watch?v=ELeZAKCN4tY https://www.youtube.com/watch?v=ELeZAKCN4tY
hinkley 4y ago
C++ is a bit of a honey trap for people who love complexity. Unfortunately it's only caught a small fraction of all of the people who worship at that altar.
- FpUser 4y ago
  I love simplicity. I also love performance. This is why I use modern C++ for backend servers. It allows me to write very simple code that is still very performant (actually leaves standard stacks in the dust). I sure do not fall into honeytraps so for me complex languages like C++ is an advantage as I can always find what works the best for particular task.
  - namkt 4y ago
    Do you use any public libraries for those backend servers, or is it all home-grown? Curious what's at play.
    - FpUser 4y ago
      yes I do: spp-httplib, taopq, spdlog, rapidjson. Also some other extras and alternatives depending on particular needs but the ones mentioned are enough to get one started on generic web app backend. What I do not and likely will not use are big opinionated frameworks. Yes I do write my own libs as well but those are very domain oriented and mostly serve needs of particular application. Nothing exciting there.
      - fredrikholm 4y ago
        Do you have any open sourced projects wit this setup? I have a soft spot for (C) single header libraries, would be interesting to compare.
        kaba0 4y ago
        > I have a soft spot for (C) single header libraries May I ask you why? The whole preprocessor macro thing is just a disgusting hack that compiles slowly, is error prone and is not even expressive enough for the most basic of things.
gavinray 4y ago
I don't write C++ for a living, and only have ~2 years' experience writing it for some hobby projects on weekends. I've found that the way I'm most productive is by using data-oriented design where I put everything in structs and don't use classes. I still use a lot of modern C++ library features, but it reads more like C. For example: struct BufferPool { alignas(PAGE_SIZE) char frames[BUF_POOL_NUM_FRAMES][PAGE_SIZE]; std::atomic_uint32_t free_frames[BUF_POOL_NUM_FRAMES]; std::atomic_uint32_t pin_count[BUF_POOL_NUM_FRAMES]; std::atomic_bool is_dirty[BUF_POOL_NUM_FRAMES]; std::atomic_uint32_t page_id_to_frame_idx[]; }; std::span<const char> BufferPool_get_record(BufferPool* pool, RecordID rid, int db_file_fd); What's nice about having all this stuff thrown into the language is that you're free to pick and choose what you want to adopt from it. For a long time, I tried to cram everything I wrote in C++ into an OOP pattern with classes, and it just didn't jive with me. Then I stopped doing that and started writing it more like TypeScript/Kotlin/C which I'm more familiar with and it's been a lot more pleasant ever since. There's been so much great stuff in C++ 17/20/23 and you can just cherry pick all the bits you want to use out of it and ignore the rest.
- dagmx 4y ago
  FWIW, structs and classes are largely identical in C++ , with the exception of public/private defaults. So using one over the other doesn’t really change anything with regards to data oriented design.
  - gavinray 4y ago
    Aye, as opposed to D where structs are value types and classes are reference types It's just a small annoyance to have to put "public:" at the top of every data-class definition So I use structs everywhere but you're completely right, no real difference
    - dagmx 4y ago
      Yeah I do the same as you since I write a ton of Swift (which does the same delineation as D). It’s mostly just a mental marker for myself that I want to treat one as a value type.
joebaf 4y ago
on the other hand with more options you can express more and write safer code (for example with constinit which solves static order init fiasco...) And if you don't have enough knowledge you can just stick to const. What re alternatives for a system programming language? (Rust seems to be fine, but still it's not super easy...)
fluoridation 4y ago
I don't agree with that analogy. For example, templates were for sure complex, and they're very much a complete feature. That is, they haven't been made more complex over time. If we accept that the committee has already dug themselves into a hole, what they're doing is digging themselves out by digging out the entire field to the same depth, thus eliminating the hole originally dug, which I think it's a perfectly reasonable strategy.
- kllrnohj 4y ago
  > For example, templates were for sure complex, and they're very much a complete feature. That is, they haven't been made more complex over time. I agree with your broader point but parameter packs (aka, variadic templates) were an addition to templates made in C++11. So strictly speaking they have gotten more complex.
  - fluoridation 4y ago
    Fair enough, but that addition wasn't to solve the problem of templates being too complex, but to support usages that were previously impossible.
    - usrnm 4y ago
      They were possible and widely used, but a lot less ergonomic. You "just" had to copy-paste some number of instantiatons for the number of arguments between 0 and, say, 50.
      - fluoridation 4y ago
        Wasn't it also at the cost of compilation memory? I still remember the time when it was easy to crash compilers by just giving them hard enough templates.
  - cbsmith 4y ago
    I mean, that's just the tip of the iceberg. Templates have evolved a great deal over time, and continue to do so (C++20 added Concepts).
g42gregory 4y ago
I feel that this is a feature, not a bug. While I don't use C++ extensively, I think the Industry needs at least one language, which does not constrain the developer in any way. I think such a language is currently C++. It has all kinds of guidelines now to stay in the "safe zone", but there are many developers who (1) need unfettered access to the hardware and/or (2) need all kinds of language capabilities to write an extreme performance code.
- virtualritz 4y ago
  Could you elaborate what I can do in C++ that I can't do in Rust (using unsafe, if I must)? For context: I've been writing code in C++ for most of my career (25+ years) and being for VFX/3D rendering it was mostly performance critical code. Now I write Rust for some very performance critical tasks in finance ...
  - eloff 4y ago
    I also use Rust now. If you use unsafe, there is little you can do in C++ that you can't do in Rust. However, some things like data races and mutable aliasing are permitted in C++, but not in unsafe Rust, as they invoke undefined behavior. The Rust nomicon has more details about what's allowed.
    - virtualritz 4y ago
      > However, some things like data races and mutable aliasing are permitted in C++, but not in unsafe Rust, as they invoke undefined behavior. Define 'permitteed'. Unsafe is, among other things, exactly that. It tells rustc to permit you to do things that are ... well, unsafe. Including the ones you listed. Maybe you don't understand the meaning of unsafe in Rust? Unsafe causing UB is a possibility. As is taking two &mut refs to the same memory location using exactly that keyword. And that example works for multi-threaded Rust code using a shared resource accessed as such too.
      - kaba0 4y ago
Animats 4y ago
I'm glad I switched to Rust. In C/C++, the language designers can't take anything out. That would break things. There's so much legacy code. C hasn't even totally removed "strcat", etc. yet. That should have been removed in the previous century.
devnullbrain 4y ago
This is a surface-level meme that just doesn't reflect reality. In old C++ you had to spend all your time worrying about manual ctors and memory management. These problems have been erased by improvements to the language. You don't even use raw pointers any more. The language is less complex to use now than it was 10 years ago. If you've moved on then your insight is outdated.
- pjmlp 4y ago
  Kind of true, if we ignore all the code that is in production and no one is going to rewrite for C++20 ways of coding.
  - devnullbrain 4y ago
    Which would not have its problems solved by halting C++ development or moving to a new language
    - pjmlp 4y ago
      Anyone working on those codebases needs to be aware of the new ways, while mastering the old ways. The ideal modern C++ without having to worry about "deprecated" ways of coding, is more the exception than the rule.
- usrnm 4y ago
  > In old C++ you had to spend all your time worrying about manual ctors That doesn't even make sense. Maybe you meant "destructors" but even then it has nothing to do with reality
  - devnullbrain 4y ago
    I mean constructors. It's the exception to have to do anything meaningful in the body of a constructor in modern C++ - you can do a lot with member initialisation lists, delegated constructors and defaulted/deleted constructors (remember boost::noncopyable?). And your assignment operators will actually be exception safe.
userbinator 4y ago
The trick with C++ is to use and pick things to work on that haven't devolved into a massive abomination of complexity just to be trendy and "modern". I've found that something like the classic (pun intended) "C with classes" style is a good balance. Personally, I prefer to use C (C89) which is high-level enough to be reasonably productive, while at the same time not high-level enough to discourage the creation of overly complex code. There are surprisingly frequent posts here from people who have written their own C compiler. I don't think I've seen a single C++ one yet.
- estebank 4y ago
  Are you baiting Walter for a reply? :)
- JonChesterfield 4y ago
  `clang++ -ffreestanding` (without a standard library) is growing on me as a C89 replacement. There's some annoyances like std::launder that you need to implement using compiler intrinsics but it's feasible.
overgard 4y ago
Eh, it's gotten more complex sure, but in real world code most of this solves real problems, and even if it's technically adding to the language in practice most of the new stuff replaces old patterns. I don't think anyone that's used c++20 would want to go back to c++98, or c++11.

klyrs 4y ago

I've got my eye on Cpp2... Herb says he isn't interested in making it an official language but I suspect that once it stabilizes it will be an attractive migration.

elteto 4y ago
But then you have Google with Carbon… which is a direct competitor to cpp2. Apple hasn’t shown interest in either, and MS will of course most likely support cpp2. Without the giants aligning their interests I’m afraid there will be a split in the community. Clang’s std C++ library is already behind GCC’s because Apple and Google have “moved” on.
- bsldld 4y ago
  > ...Apple and Google have “moved” on. Apple moved to Swift, but what has Google moved to?
  - elteto 4y ago
    It’s in the process of “moving” on to Carbon.
    - devnullbrain 4y ago
      That is a lot of optimism for a 2022 project from 2022 Google.
      - elteto 4y ago
        Everything starts somewhere. I believe Chandler Carruth is leading the project so that means non-trivial resources are being dedicated to it. Their timeline is also fairly aggressive.
        ameliaquining 4y ago
        They're also simultaneously looking at Rust as a possible successor to C++ (e.g., by developing better interop tooling). It's believed that at most one of these projects can succeed in the long term.
        elteto 4y ago
        Interesting, thanks for the insider take. I honestly would love if they went with Rust.
tialaramex 4y ago
Herb doesn't even want to default to immutable local variables (what he as a C++ person calls "const by default"). Obviously Cpp2 isn't finished enough for this to necessarily jump out, but Herb figures if we make a variable then we must intend to vary it, which is one of those claims I expect from newbie C++ programmers keen to defend their new language. No, come on Herb, Kate Gregory has told us why there are variables, they are names for things. The machine doesn't need names, but the human maintenance programmers do. As a Microsoft employee I'm going to hazard a guess that Herb spends a lot less time staring at C++ real humans wrote before they died/ retired/ got fired without notice than Kate does in her consulting job. She knows what she's talking about.
- ameliaquining 4y ago
  I'm honestly not convinced that immutability for local variables is a particularly useful feature. Within the scope of a single function, it's usually pretty easy to see if a variable is being reassigned or not; there aren't the same kind of programming-in-the-large preventing-spooky-action-at-a-distance benefits that come from immutability across API boundaries. You increase the language's complexity and learning curve, for a benefit that's rather speculative and unclear. (The exception is closures; prohibiting a variable from being reassigned after it's been closed over is useful because anyone reading the code may expect one of two conflicting behaviors depending on context, and so it's good to instead write the code in a way that doesn't have that ambiguity. Java got this one right.) A post articulating this point, by the person primarily responsible for Rust's shared-xor-mutable architecture (so presumably he has some idea what he's talking about, though note that his argument did not carry the day): https://smallcultfollowing.com/babysteps/blog/2014/05/13/focusing-on-ownership/ https://smallcultfollowing.com/babysteps/blog/2014/05/13/foc...
  - tialaramex 4y ago
    Notice that what you're asking for is to abolish const local variables. Which also isn't what Herb offers, this was the status quo in C during the K&R era because "const" didn't exist in K&R C. If you actually want const local variables, just not by default, you're not actually agreeing with Niko.
cpeterso 4y ago
For people curious about Herb's Cpp2, here's a presentation he gave at CppCon 2022: "Can C++ be 10x Simpler & Safer? (Simplifying C++ #9 of N)" https://www.youtube.com/watch?v=ELeZAKCN4tY https://www.youtube.com/watch?v=ELeZAKCN4tY

hinkley 4y ago

C++ is a bit of a honey trap for people who love complexity. Unfortunately it's only caught a small fraction of all of the people who worship at that altar.

FpUser 4y ago
I love simplicity. I also love performance. This is why I use modern C++ for backend servers. It allows me to write very simple code that is still very performant (actually leaves standard stacks in the dust). I sure do not fall into honeytraps so for me complex languages like C++ is an advantage as I can always find what works the best for particular task.
- namkt 4y ago
  Do you use any public libraries for those backend servers, or is it all home-grown? Curious what's at play.
  - FpUser 4y ago
    yes I do: spp-httplib, taopq, spdlog, rapidjson. Also some other extras and alternatives depending on particular needs but the ones mentioned are enough to get one started on generic web app backend. What I do not and likely will not use are big opinionated frameworks. Yes I do write my own libs as well but those are very domain oriented and mostly serve needs of particular application. Nothing exciting there.
    - fredrikholm 4y ago
      Do you have any open sourced projects wit this setup? I have a soft spot for (C) single header libraries, would be interesting to compare.
      - kaba0 4y ago
        > I have a soft spot for (C) single header libraries May I ask you why? The whole preprocessor macro thing is just a disgusting hack that compiles slowly, is error prone and is not even expressive enough for the most basic of things.

gavinray 4y ago

I don't write C++ for a living, and only have ~2 years' experience writing it for some hobby projects on weekends. I've found that the way I'm most productive is by using data-oriented design where I put everything in structs and don't use classes. I still use a lot of modern C++ library features, but it reads more like C. For example: struct BufferPool { alignas(PAGE_SIZE) char frames[BUF_POOL_NUM_FRAMES][PAGE_SIZE]; std::atomic_uint32_t free_frames[BUF_POOL_NUM_FRAMES]; std::atomic_uint32_t pin_count[BUF_POOL_NUM_FRAMES]; std::atomic_bool is_dirty[BUF_POOL_NUM_FRAMES]; std::atomic_uint32_t page_id_to_frame_idx[]; }; std::span<const char> BufferPool_get_record(BufferPool* pool, RecordID rid, int db_file_fd); What's nice about having all this stuff thrown into the language is that you're free to pick and choose what you want to adopt from it. For a long time, I tried to cram everything I wrote in C++ into an OOP pattern with classes, and it just didn't jive with me. Then I stopped doing that and started writing it more like TypeScript/Kotlin/C which I'm more familiar with and it's been a lot more pleasant ever since. There's been so much great stuff in C++ 17/20/23 and you can just cherry pick all the bits you want to use out of it and ignore the rest.

dagmx 4y ago
FWIW, structs and classes are largely identical in C++ , with the exception of public/private defaults. So using one over the other doesn’t really change anything with regards to data oriented design.
- gavinray 4y ago
  Aye, as opposed to D where structs are value types and classes are reference types It's just a small annoyance to have to put "public:" at the top of every data-class definition So I use structs everywhere but you're completely right, no real difference
  - dagmx 4y ago
    Yeah I do the same as you since I write a ton of Swift (which does the same delineation as D). It’s mostly just a mental marker for myself that I want to treat one as a value type.

joebaf 4y ago

on the other hand with more options you can express more and write safer code (for example with constinit which solves static order init fiasco...) And if you don't have enough knowledge you can just stick to const. What re alternatives for a system programming language? (Rust seems to be fine, but still it's not super easy...)

fluoridation 4y ago

I don't agree with that analogy. For example, templates were for sure complex, and they're very much a complete feature. That is, they haven't been made more complex over time. If we accept that the committee has already dug themselves into a hole, what they're doing is digging themselves out by digging out the entire field to the same depth, thus eliminating the hole originally dug, which I think it's a perfectly reasonable strategy.

kllrnohj 4y ago
> For example, templates were for sure complex, and they're very much a complete feature. That is, they haven't been made more complex over time. I agree with your broader point but parameter packs (aka, variadic templates) were an addition to templates made in C++11. So strictly speaking they have gotten more complex.
- fluoridation 4y ago
  Fair enough, but that addition wasn't to solve the problem of templates being too complex, but to support usages that were previously impossible.
  - usrnm 4y ago
    They were possible and widely used, but a lot less ergonomic. You "just" had to copy-paste some number of instantiatons for the number of arguments between 0 and, say, 50.
    - fluoridation 4y ago
      Wasn't it also at the cost of compilation memory? I still remember the time when it was easy to crash compilers by just giving them hard enough templates.
- cbsmith 4y ago
  I mean, that's just the tip of the iceberg. Templates have evolved a great deal over time, and continue to do so (C++20 added Concepts).

g42gregory 4y ago

I feel that this is a feature, not a bug. While I don't use C++ extensively, I think the Industry needs at least one language, which does not constrain the developer in any way. I think such a language is currently C++. It has all kinds of guidelines now to stay in the "safe zone", but there are many developers who (1) need unfettered access to the hardware and/or (2) need all kinds of language capabilities to write an extreme performance code.

virtualritz 4y ago
Could you elaborate what I can do in C++ that I can't do in Rust (using unsafe, if I must)? For context: I've been writing code in C++ for most of my career (25+ years) and being for VFX/3D rendering it was mostly performance critical code. Now I write Rust for some very performance critical tasks in finance ...
- eloff 4y ago
  I also use Rust now. If you use unsafe, there is little you can do in C++ that you can't do in Rust. However, some things like data races and mutable aliasing are permitted in C++, but not in unsafe Rust, as they invoke undefined behavior. The Rust nomicon has more details about what's allowed.
  - virtualritz 4y ago
    > However, some things like data races and mutable aliasing are permitted in C++, but not in unsafe Rust, as they invoke undefined behavior. Define 'permitteed'. Unsafe is, among other things, exactly that. It tells rustc to permit you to do things that are ... well, unsafe. Including the ones you listed. Maybe you don't understand the meaning of unsafe in Rust? Unsafe causing UB is a possibility. As is taking two &mut refs to the same memory location using exactly that keyword. And that example works for multi-threaded Rust code using a shared resource accessed as such too.
    - kaba0 4y ago

Animats 4y ago

I'm glad I switched to Rust. In C/C++, the language designers can't take anything out. That would break things. There's so much legacy code. C hasn't even totally removed "strcat", etc. yet. That should have been removed in the previous century.

devnullbrain 4y ago

This is a surface-level meme that just doesn't reflect reality. In old C++ you had to spend all your time worrying about manual ctors and memory management. These problems have been erased by improvements to the language. You don't even use raw pointers any more. The language is less complex to use now than it was 10 years ago. If you've moved on then your insight is outdated.

pjmlp 4y ago
Kind of true, if we ignore all the code that is in production and no one is going to rewrite for C++20 ways of coding.
- devnullbrain 4y ago
  Which would not have its problems solved by halting C++ development or moving to a new language
  - pjmlp 4y ago
    Anyone working on those codebases needs to be aware of the new ways, while mastering the old ways. The ideal modern C++ without having to worry about "deprecated" ways of coding, is more the exception than the rule.
usrnm 4y ago
> In old C++ you had to spend all your time worrying about manual ctors That doesn't even make sense. Maybe you meant "destructors" but even then it has nothing to do with reality
- devnullbrain 4y ago
  I mean constructors. It's the exception to have to do anything meaningful in the body of a constructor in modern C++ - you can do a lot with member initialisation lists, delegated constructors and defaulted/deleted constructors (remember boost::noncopyable?). And your assignment operators will actually be exception safe.

userbinator 4y ago

The trick with C++ is to use and pick things to work on that haven't devolved into a massive abomination of complexity just to be trendy and "modern". I've found that something like the classic (pun intended) "C with classes" style is a good balance. Personally, I prefer to use C (C89) which is high-level enough to be reasonably productive, while at the same time not high-level enough to discourage the creation of overly complex code. There are surprisingly frequent posts here from people who have written their own C compiler. I don't think I've seen a single C++ one yet.

estebank 4y ago
Are you baiting Walter for a reply? :)
JonChesterfield 4y ago
`clang++ -ffreestanding` (without a standard library) is growing on me as a C89 replacement. There's some annoyances like std::launder that you need to implement using compiler intrinsics but it's feasible.

overgard 4y ago

Eh, it's gotten more complex sure, but in real world code most of this solves real problems, and even if it's technically adding to the language in practice most of the new stuff replaces old patterns. I don't think anyone that's used c++20 would want to go back to c++98, or c++11.