5 ms·

> What is much less prevalent is a demand from average C++ users for memory safety features; they’re much more concerned about compilation speed. When most C++

> What is much less prevalent is a demand from average C++ users for memory safety features; they’re much more concerned about compilation speed. When most C++ developers haven’t adopted tools like Coverity and C++ core guidelines checkers, it is hard to claim that memory safety features substantially improve their lives at least from their point of view. I don’t really agree with this. There’s also a group of developers that want more safety, but don’t feel like setting up (or in the case of Coverity purchasing) additional tooling. Some people just want a decent out of the box experience.

moffkalast 3y ago
I think it's less about not wanting memory safety and more that compilation speeds are so time-wastingly abysmal that it's a few orders of magnitude more important to address. The whole deal with interpreted languages was to avoid sitting there for a few minutes every time you make a god damn one letter change, with the unfortunate but usually acceptable trade-off of some execution speed.
- mxmlnkn 3y ago
  And the additional trade-off that some bugs are only noticed at runtime when that particular line is executed while it could have been noticed by the compiler of a strongly typed language. Pytype helps but at this point you have a static analyzer that potentially runs as slow as a compiler without the additional performance benefit.
  - moffkalast 3y ago
    Idk as long as you can develop at speed I don't see why a static analyser that's a few times slower than compiling couldn't run on the latest commit overnight? More as a sonarqube type thing I suppose.
  - josephg 3y ago
    There’s no good reason for type checking to be super slow. I’m no fan of Go, but the language compiles insanely fast while being fully statically typed. As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once. This isn’t a problem with static typing. It’s a problem with C++, and to a lesser extent C.
    - aw1621107 3y ago
      > As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once. That's one of the things that can slow compilation down but it's definitely not the only one. It helps that precompiled headers (and maybe modules?) can go a long way towards reducing and possibly eliminating these costs as well. I think some (most?) of the larger remaining costs revolve around template instantiation, especially it impacts link times as well due to the fact that the linker needs to do extra work to eliminate redundant instantiations.
      - josephg 3y ago
        > due to the fact that the linker needs to do extra work to eliminate redundant instantiations. Yeah, I see this as another consequence of C++'s poor compilation model: - Compilation is slow because a template class in your header file gets compiled N times (maybe with precompiled headers). The compiler produces N object files filled with redundant code. - Then the linker is slow because it needs to parse all those object files, and filter out all the redundant code that you just wasted time generating. Its a bad design.
        aw1621107 3y ago
        I'm not sure I'd call the design "bad". At the very least it's a product of the design constraints, and I'm not sure there's an obviously better implementation without sacrificing something else. I think separate compilation and monomorphization are the biggest contributors, but I wouldn't be surprised if there was something I was forgetting. Somewhat related, there was some work in Rust about sharing monomorphized generics across crates, but it appears it was not a universal win at the time[0]. I'm not sure if anything has changed since that point, unfortunately, or if something similar could be applied to C++ somehow. [0]: https://github.com/rust-lang/rust/issues/47317#issuecomment-478894318 https://github.com/rust-lang/rust/issues/47317#issuecomment-...
        josephg 3y ago
        > I'm not sure I'd call the design "bad". At the very least it's a product of the design constraints, and I'm not sure there's an obviously better implementation without sacrificing something else. It was a product of the design constraints in the 70s when memory was expensive, and compilers couldn't store a whole program in memory during compilation. The problem C++ has now is that the preprocessor operates on the raw text of a header file (which is a relic from C). This means the same header file can generate totally different source code each time its included in your program. C++ can't change that behaviour without breaking backwards compatibility. So headers get parsed over and over again "just in case" - wasting time producing excess code that just gets stripped back out again by the linker. The way C++ works doesn't make any sense now that memory is so much cheaper. Go, C#, java, rust, zig - basically every compiled language younger than C++ compiles faster than C++ because these languages don't contain C++'s design mistake. Rust doesn't share monomorphized generics across crates, but at least each crate is compiled as a single compilation unit.
- JohnFen 3y ago
  I know I'm weird, but as long as I can compile individual units and link them to other already-compiled units then compilation speed is something I don't care about much at all.
  - carlmr 3y ago
    That's fine and dandy as long as you don't use C++ with templates and other stuff that needs 90% of the code to be in the headers. Any recompile triggers a lot of recompilation. And no, I can't change the code the other hundred devs are writing in my company. In C++ there is no individual units. In C it's somewhat plausible with some discipline.
    - penguin_booze 3y ago
      > In C++ there is no individual units There's a still a notion of the compilation unit, which is the cpp file on which you invoke the compiler. Due to templates being prevalent in C++, included files contain the implementation as well; so any changes you make there lead to re-compiling a lot more compilation units than, for example, in C.
      - carlmr 3y ago
        That is kind of restating my point. There might be these translation units, but they're tightly coupled to all the other translation units, making them not very individual IMO.
    - JohnFen 3y ago
      yes, that's why I used the disclaimer "as long as I can compile individual units and link them". The problem with C++ templates is accurate, and is one of the several reasons why I avoid using templates in my own C++ code. I don't have that freedom in the code I write for my employer, though. > In C++ there is no individual units. Yes, there are. Those unit boundaries are often blurred by other C++ features, but they do exist.
sakjur 3y ago
That sentence stood out to me as well. I don't think C++ developers is necessarily the best people to ask when discussing whether memory safety is important and urgent to work on or not. A lot of developers are relatively shielded from the consequences of bugs and security vulnerabilities, either by their programs not being exposed to the wild in any major sense or by bureaucracy being in between them and any consequences. At some point, the deficiencies of a language becomes a concern for its end-users rather than its developers.
- JohnFen 3y ago
  > the deficiencies of a language becomes a concern for its end-users rather than its developers. I think that this level of professional malpractice is something that can't be solved by language choice.
  - eviks 3y ago
    But the level of damage can be reduced by language choice
    - JohnFen 3y ago
      Maybe, but surely the better answer is for devs to do better.
      - iFreilicht 3y ago
        That actually seems unrealistic to me. Of course, people will always become better at doing the things they do, and we can always try harder, but many of these issues take time to consider and find during code reviews, and a few just slip by. That's why tools like Coverity exist, but you have to spend time and money to set those up, meaning it's only done when absolutely necessary (or one dedicated person is really pushing for it). Choosing a different language is basically free in the beginning, and it will impact which sort of bugs will be caught by default and which won't. C++ is also massively hurt in this regard by not having a package manager. JS is a very risky language by default, but a few tools just with their default settings will already help massively. I guess Nix could be considered the missing package manager for C and C++, but it's still niche and definitely not a "default" like pip, npm or cargo.
worik 3y ago
Yes It is not about what we want. It is what we need Not real.y "we". I have lost any interest in C++ now. I loved it, in the day. Time has moved on
MaulingMonkey 3y ago
I'll make a similar, but fundamentally different, claim to what you're quoting: There isn't much demand for half assed memory safety features. And C++ memory safety features are - nearly by definition - half assed. They're opt-in (meaning all the third-party and system code you link against doesn't have coverage), slow (meaning you can't use it in production), and tend to catch the trivial bugs rather than the hard-to-find ones that keep you up at night.
- andrewmcwatters 3y ago
  Reminds me of "type-safety" features in duck type languages.
BeetleB 3y ago
C++ Developers aren't complaining for two reasons: 1. Most of those who care about memory safety have already left the building. 2. Those who are still in the building and care don't speak up because their colleagues don't value it, and many of their colleagues will view them as having lower competence.
dagmx 3y ago
Yeah that stood out to me too. I guess the problem is that only a small percentage of developers both understand the need for memory safety and are vocal about it. That is very different from the number of users who would benefit from better memory safety. When someone encounters a crash, their actionable item isn’t to go ask the C++ committee for better safety. That’s an unassailable wall for most developers, assuming they even understand what’s happening and that there are better options out there.

moffkalast 3y ago

I think it's less about not wanting memory safety and more that compilation speeds are so time-wastingly abysmal that it's a few orders of magnitude more important to address. The whole deal with interpreted languages was to avoid sitting there for a few minutes every time you make a god damn one letter change, with the unfortunate but usually acceptable trade-off of some execution speed.

mxmlnkn 3y ago
And the additional trade-off that some bugs are only noticed at runtime when that particular line is executed while it could have been noticed by the compiler of a strongly typed language. Pytype helps but at this point you have a static analyzer that potentially runs as slow as a compiler without the additional performance benefit.
- moffkalast 3y ago
  Idk as long as you can develop at speed I don't see why a static analyser that's a few times slower than compiling couldn't run on the latest commit overnight? More as a sonarqube type thing I suppose.
- josephg 3y ago
  There’s no good reason for type checking to be super slow. I’m no fan of Go, but the language compiles insanely fast while being fully statically typed. As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once. This isn’t a problem with static typing. It’s a problem with C++, and to a lesser extent C.
  - aw1621107 3y ago
    > As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once. That's one of the things that can slow compilation down but it's definitely not the only one. It helps that precompiled headers (and maybe modules?) can go a long way towards reducing and possibly eliminating these costs as well. I think some (most?) of the larger remaining costs revolve around template instantiation, especially it impacts link times as well due to the fact that the linker needs to do extra work to eliminate redundant instantiations.
    - josephg 3y ago
      > due to the fact that the linker needs to do extra work to eliminate redundant instantiations. Yeah, I see this as another consequence of C++'s poor compilation model: - Compilation is slow because a template class in your header file gets compiled N times (maybe with precompiled headers). The compiler produces N object files filled with redundant code. - Then the linker is slow because it needs to parse all those object files, and filter out all the redundant code that you just wasted time generating. Its a bad design.
      - aw1621107 3y ago
        I'm not sure I'd call the design "bad". At the very least it's a product of the design constraints, and I'm not sure there's an obviously better implementation without sacrificing something else. I think separate compilation and monomorphization are the biggest contributors, but I wouldn't be surprised if there was something I was forgetting. Somewhat related, there was some work in Rust about sharing monomorphized generics across crates, but it appears it was not a universal win at the time[0]. I'm not sure if anything has changed since that point, unfortunately, or if something similar could be applied to C++ somehow. [0]: https://github.com/rust-lang/rust/issues/47317#issuecomment-478894318 https://github.com/rust-lang/rust/issues/47317#issuecomment-...
        josephg 3y ago
        > I'm not sure I'd call the design "bad". At the very least it's a product of the design constraints, and I'm not sure there's an obviously better implementation without sacrificing something else. It was a product of the design constraints in the 70s when memory was expensive, and compilers couldn't store a whole program in memory during compilation. The problem C++ has now is that the preprocessor operates on the raw text of a header file (which is a relic from C). This means the same header file can generate totally different source code each time its included in your program. C++ can't change that behaviour without breaking backwards compatibility. So headers get parsed over and over again "just in case" - wasting time producing excess code that just gets stripped back out again by the linker. The way C++ works doesn't make any sense now that memory is so much cheaper. Go, C#, java, rust, zig - basically every compiled language younger than C++ compiles faster than C++ because these languages don't contain C++'s design mistake. Rust doesn't share monomorphized generics across crates, but at least each crate is compiled as a single compilation unit.
JohnFen 3y ago
I know I'm weird, but as long as I can compile individual units and link them to other already-compiled units then compilation speed is something I don't care about much at all.
- carlmr 3y ago
  That's fine and dandy as long as you don't use C++ with templates and other stuff that needs 90% of the code to be in the headers. Any recompile triggers a lot of recompilation. And no, I can't change the code the other hundred devs are writing in my company. In C++ there is no individual units. In C it's somewhat plausible with some discipline.
  - penguin_booze 3y ago
    > In C++ there is no individual units There's a still a notion of the compilation unit, which is the cpp file on which you invoke the compiler. Due to templates being prevalent in C++, included files contain the implementation as well; so any changes you make there lead to re-compiling a lot more compilation units than, for example, in C.
    - carlmr 3y ago
      That is kind of restating my point. There might be these translation units, but they're tightly coupled to all the other translation units, making them not very individual IMO.
  - JohnFen 3y ago
    yes, that's why I used the disclaimer "as long as I can compile individual units and link them". The problem with C++ templates is accurate, and is one of the several reasons why I avoid using templates in my own C++ code. I don't have that freedom in the code I write for my employer, though. > In C++ there is no individual units. Yes, there are. Those unit boundaries are often blurred by other C++ features, but they do exist.

sakjur 3y ago

That sentence stood out to me as well. I don't think C++ developers is necessarily the best people to ask when discussing whether memory safety is important and urgent to work on or not. A lot of developers are relatively shielded from the consequences of bugs and security vulnerabilities, either by their programs not being exposed to the wild in any major sense or by bureaucracy being in between them and any consequences. At some point, the deficiencies of a language becomes a concern for its end-users rather than its developers.

JohnFen 3y ago
> the deficiencies of a language becomes a concern for its end-users rather than its developers. I think that this level of professional malpractice is something that can't be solved by language choice.
- eviks 3y ago
  But the level of damage can be reduced by language choice
  - JohnFen 3y ago
    Maybe, but surely the better answer is for devs to do better.
    - iFreilicht 3y ago
      That actually seems unrealistic to me. Of course, people will always become better at doing the things they do, and we can always try harder, but many of these issues take time to consider and find during code reviews, and a few just slip by. That's why tools like Coverity exist, but you have to spend time and money to set those up, meaning it's only done when absolutely necessary (or one dedicated person is really pushing for it). Choosing a different language is basically free in the beginning, and it will impact which sort of bugs will be caught by default and which won't. C++ is also massively hurt in this regard by not having a package manager. JS is a very risky language by default, but a few tools just with their default settings will already help massively. I guess Nix could be considered the missing package manager for C and C++, but it's still niche and definitely not a "default" like pip, npm or cargo.

worik 3y ago

Yes It is not about what we want. It is what we need Not real.y "we". I have lost any interest in C++ now. I loved it, in the day. Time has moved on

MaulingMonkey 3y ago

I'll make a similar, but fundamentally different, claim to what you're quoting: There isn't much demand for half assed memory safety features. And C++ memory safety features are - nearly by definition - half assed. They're opt-in (meaning all the third-party and system code you link against doesn't have coverage), slow (meaning you can't use it in production), and tend to catch the trivial bugs rather than the hard-to-find ones that keep you up at night.

andrewmcwatters 3y ago
Reminds me of "type-safety" features in duck type languages.

BeetleB 3y ago

C++ Developers aren't complaining for two reasons: 1. Most of those who care about memory safety have already left the building. 2. Those who are still in the building and care don't speak up because their colleagues don't value it, and many of their colleagues will view them as having lower competence.

dagmx 3y ago

Yeah that stood out to me too. I guess the problem is that only a small percentage of developers both understand the need for memory safety and are vocal about it. That is very different from the number of users who would benefit from better memory safety. When someone encounters a crash, their actionable item isn’t to go ask the C++ committee for better safety. That’s an unassailable wall for most developers, assuming they even understand what’s happening and that there are better options out there.