6 ms·

C++ really is a blast and I think the complaints people have about it really depend on context. Lots of C++ devs hate that language but imo misdirect their hate

C++ really is a blast and I think the complaints people have about it really depend on context. Lots of C++ devs hate that language but imo misdirect their hate. They actually work on legacy products built by people who were never that great at writing software. This happened to me with Rust actually where I was thrust into an existing rust project at the company I work for. It's an "old" codebase with many different and conflicting conventions within it (different error handling types that don't compose well, bad class abstractions, lots of unsafe block when not needed, etc). The project was the most miserable project I've ever worked on and it's easy for me to blame Rust, but it's really just bad software development. There are warts in C++, but a lot of the pain people run into is just that they are working on crap code and it would be crap in any language.

psyclobe 2y ago
This 1000%, stop blaming the tools!
- mrcsd 2y ago
  How can we make better tools if we don't blame tools?
- zdragnar 2y ago
  Eh, I'm reminded of the old "programming languages as weapons" comic, with the one that I still remember is JavaScript was a sword without a hilt, with the blade being the "good part" and in place of the hilt, another blade labelled the "bad part". You can blame devs instead of tools all day long, but you can't deny that there are things about the tools that hold the developers back.
nvarsj 2y ago
True - but it’s much easier to make an incomprehensible mess in more complex languages. Whereas blub language projects are pretty easy to decipher regardless of the state of the codebase.
zahlman 2y ago
I really can't resonate with this. The type system is obnoxious (and you don't even get proper memory safety out of it), the "most vexing parse" truly is vexatious, there's all the weirdness inherited from C like pointer decay (and then building new solutions like std::array on top while being unable to get rid of old ways of doing things), and of course the continued reliance on a preprocessor to simulate an actual module import system (and the corresponding implications for how code for a class is organized, having to hack around with the pimpl idiom etc....) Essentially, the warts are too large and numerous for me to find any inner beauty in it any more.
- omolobo 2y ago
  [dead]
- ironman1478 2y ago
  I mean, this is all anecdotal, but I've only ran into the most vexing parse a few times, I rarely had to use the pimpl idiom, and the header file stuff... okay that isn't great. I've been a c++ dev for 10 years and I actually worked on an extremely old codebase and was involved in modernizing it is to C++11. Maybe I'm too C++ brained, but all those things just aren't that bad? There is no wartless language and you just deal with the warts of the language you're in and it's your responsibility to learn the details of the language.
  - blep-arsh 2y ago
    I can deal with all the warts but I'm not really having a blast.
  - cataphract 2y ago
    The header stuff is pretty bad. The rest are strange choices of stuff to complain about. The vexing parse was never a big deal and these days with bracket initialization (which only rarely you can't use) even less. The pimpl idiom: not sure why it's really a problem. Plus you have many choices for type erasure in c++.
    - 2y ago
CJefferson 2y ago
In every other language (except C), basically every time you write v[x]=y you aren't inviting the possibility of arbitary memory corruption. The C++ 'std::optional' type makes calling '*v' undefined behaviour if 'v' is empty. The whole point of optional is to store things that might be empty, so why put undefined behaviour on the most common operation on an optional when it's empty (which is going to be common in practice, that's the point!) The problem I have with C++ (and I've written a lot), is every programmer involved in your project has to be 100% perfect, 100% of the time. I know you can run memory checkers, and STL debug modes, but unless you are running these in release as well (is anyone doing that?), then you are then counting on your testsuite hitting every weird thing a silly, or malicious, user might do. Given how important software is nowadays, and how Rust seems close to the performance of C++, is it really worth using a language where so many of the basic fundamental features are incredibly hard to use safely? They keep making it worse, calling an empty std::function threw an assert, the new std::copyable_function has made this undefined behaviour instead!
- CyberDildonics 2y ago
  The C++ 'std::optional' type makes calling 'v' undefined behaviour if 'v' is empty* Are you talking about dereferencing a null pointer? That is going to case a low level exception in any language, it has nothing to do with std::optional. every time you write v[x]=y you aren't inviting the possibility of arbitary memory corruption That's how computers work. You either pay the penalty of turning every memory check into a conditional boundary check first or you avoid it all together and just iterate through data structures, which is not difficult to do. Also debug mode lets you turn on the bounds checking to debug and be fast in release mode. The reality is that with a tiny amount of experience this is almost never a problem. Things like this are mostly relegated to writing your own data structures.
  - CJefferson 2y ago
    No, I'm talking about std::optional<T>. It's a type designed to store an object of type T, or nothing. You use '*v' to get the value out (if one is present). It was originally discussed as a way of avoid null pointers, for the common case where they are representing the possibility of having a value. However, it has exactly the same UB problems as a null pointer, so isn't really any safer. I'm going to be honest, saying that memory corruption in C++ is 'almost never a problem' just doesn't match with my experience, of working on many large codebases, games, and seeing remote security holes caused by buffer overflows and memory corruption occurring in every OS and large software program ever written. Also, that 'penalty' really does seem to be tiny, as far as I can tell. Rust pays it (you can use unsafe to disable it, but most programs use unsafe very sparingly), and as far as I've seen benchmarks, the introduced overhead is tiny, a couple of percent at most.
spopejoy 2y ago
I refer you to the (admittedly dated, but also quite funny) C++ FQA https://yosefk.com/c++fqa/ https://yosefk.com/c++fqa/

psyclobe 2y ago

This 1000%, stop blaming the tools!

mrcsd 2y ago
How can we make better tools if we don't blame tools?
zdragnar 2y ago
Eh, I'm reminded of the old "programming languages as weapons" comic, with the one that I still remember is JavaScript was a sword without a hilt, with the blade being the "good part" and in place of the hilt, another blade labelled the "bad part". You can blame devs instead of tools all day long, but you can't deny that there are things about the tools that hold the developers back.

nvarsj 2y ago

True - but it’s much easier to make an incomprehensible mess in more complex languages. Whereas blub language projects are pretty easy to decipher regardless of the state of the codebase.

zahlman 2y ago

I really can't resonate with this. The type system is obnoxious (and you don't even get proper memory safety out of it), the "most vexing parse" truly is vexatious, there's all the weirdness inherited from C like pointer decay (and then building new solutions like std::array on top while being unable to get rid of old ways of doing things), and of course the continued reliance on a preprocessor to simulate an actual module import system (and the corresponding implications for how code for a class is organized, having to hack around with the pimpl idiom etc....) Essentially, the warts are too large and numerous for me to find any inner beauty in it any more.

omolobo 2y ago
[dead]
ironman1478 2y ago
I mean, this is all anecdotal, but I've only ran into the most vexing parse a few times, I rarely had to use the pimpl idiom, and the header file stuff... okay that isn't great. I've been a c++ dev for 10 years and I actually worked on an extremely old codebase and was involved in modernizing it is to C++11. Maybe I'm too C++ brained, but all those things just aren't that bad? There is no wartless language and you just deal with the warts of the language you're in and it's your responsibility to learn the details of the language.
- blep-arsh 2y ago
  I can deal with all the warts but I'm not really having a blast.
- cataphract 2y ago
  The header stuff is pretty bad. The rest are strange choices of stuff to complain about. The vexing parse was never a big deal and these days with bracket initialization (which only rarely you can't use) even less. The pimpl idiom: not sure why it's really a problem. Plus you have many choices for type erasure in c++.
  - 2y ago

CJefferson 2y ago

In every other language (except C), basically every time you write v[x]=y you aren't inviting the possibility of arbitary memory corruption. The C++ 'std::optional' type makes calling '*v' undefined behaviour if 'v' is empty. The whole point of optional is to store things that might be empty, so why put undefined behaviour on the most common operation on an optional when it's empty (which is going to be common in practice, that's the point!) The problem I have with C++ (and I've written a lot), is every programmer involved in your project has to be 100% perfect, 100% of the time. I know you can run memory checkers, and STL debug modes, but unless you are running these in release as well (is anyone doing that?), then you are then counting on your testsuite hitting every weird thing a silly, or malicious, user might do. Given how important software is nowadays, and how Rust seems close to the performance of C++, is it really worth using a language where so many of the basic fundamental features are incredibly hard to use safely? They keep making it worse, calling an empty std::function threw an assert, the new std::copyable_function has made this undefined behaviour instead!

CyberDildonics 2y ago
The C++ 'std::optional' type makes calling 'v' undefined behaviour if 'v' is empty* Are you talking about dereferencing a null pointer? That is going to case a low level exception in any language, it has nothing to do with std::optional. every time you write v[x]=y you aren't inviting the possibility of arbitary memory corruption That's how computers work. You either pay the penalty of turning every memory check into a conditional boundary check first or you avoid it all together and just iterate through data structures, which is not difficult to do. Also debug mode lets you turn on the bounds checking to debug and be fast in release mode. The reality is that with a tiny amount of experience this is almost never a problem. Things like this are mostly relegated to writing your own data structures.
- CJefferson 2y ago
  No, I'm talking about std::optional<T>. It's a type designed to store an object of type T, or nothing. You use '*v' to get the value out (if one is present). It was originally discussed as a way of avoid null pointers, for the common case where they are representing the possibility of having a value. However, it has exactly the same UB problems as a null pointer, so isn't really any safer. I'm going to be honest, saying that memory corruption in C++ is 'almost never a problem' just doesn't match with my experience, of working on many large codebases, games, and seeing remote security holes caused by buffer overflows and memory corruption occurring in every OS and large software program ever written. Also, that 'penalty' really does seem to be tiny, as far as I can tell. Rust pays it (you can use unsafe to disable it, but most programs use unsafe very sparingly), and as far as I've seen benchmarks, the introduced overhead is tiny, a couple of percent at most.

spopejoy 2y ago

I refer you to the (admittedly dated, but also quite funny) C++ FQA https://yosefk.com/c++fqa/ https://yosefk.com/c++fqa/