5 ms·

Collaboration on a C++ codebase can be interesting. One of the most common approaches that organizations use is to choose a subset of the language and discourag

Collaboration on a C++ codebase can be interesting. One of the most common approaches that organizations use is to choose a subset of the language and discourage committing code that doesn't conform to that subset. This limits the sharp edges and in particular makes it easier to identify where they might exist. Perhaps the most common rule is the prohibition of exceptional control flow. This can seem really limiting at first, but encoding the possibility of errors using the type system and forcing callers to handle errors explicitly is really powerful.

colejohnson66 4y ago
If I have to use a subset of a language to avoid shooting my feet, why not just use a language without footguns?
- faitswulff 4y ago
  Not every project can be a greenfield project.
  - deltaonefour 4y ago
    I agree but C++ is so ingrained that tons of greenfield projects end up using C++ because of libraries and because too many people are used to it.
    - ncmncm 4y ago
      In other words, C++ is too useful not to use. A lot.
      - thfuran 4y ago
        Well, no. Too used to not use.
- loeg 4y ago
  There are lots of other advantages and disadvantages to any given language. You’re right that this is a mark against C++, but wrong in the assumption that it (always) outweighs all other considerations (performance, familiarity, compatibility with existing C++ codebase, portability to odd architectures). (Personally, I don’t like C++ and prefer Rust. But it is also reasonable to choose C++.)
- jstx1 4y ago
  Because that subset can still be better at solving your problem than those other languages - it could be faster, more mature, better at solving certain problems, you can leverage existing ecosystem etc.
  - Koshkin 4y ago
    This is exactly true. Noone in the C++ world uses all of C++ in their project. It is a multi-paradigm language, and you are free to choose one (or a few) of the paradigms and follow it throughout the entire project. For example, you can choose to base your project on virtual functions and interfaces, or you can choose to employ static polymorphism instead. Remarkably, even the C++ standard library, for all its intricacy and complexity, does not use all of C++. Also, it is useful to see C++ as two languages, one for library developers, and one for developers of applications.
- arinlen 4y ago
  > If I have to use a subset of a language to avoid shooting my feet, why not just use a language without footguns? Because it has absolutely nothing to do with footguns. The main factors in picking subsets, beyond personal tastes on coding styles and office politics, boil down to a) introducing exceptions in legacy code, and thus the need to revalidate what is otherwise solid code, b) not be forced to deal with the complexity of template metaprogramming when the value it adds back is negligible.
- jandrewrogers 4y ago
  Because different types of software make good use of different subsets of C++. A "footgun" for one codebase is a "high-leverage feature" for another code base. The subset of "no footguns" C++ that is common to virtually all applications probably asymptotically converges on the empty set. A feature of C++ is that you can precisely select an optimally expressive subset for most applications instead of being forced to write code in language that clearly wasn't designed with your use case in mind. Having a lot of tools in your toolbox doesn't necessitate using all of them in inappropriate contexts. I don't try to hammer a screw just because I own a hammer.
  - deltaonefour 4y ago
    This analogy sounds nice but is deceptive. The problem is there's no place where a foot gun is appropriate. I need a toolbox for screwing things so I get a screwdriver toolbox, but in that toolbox is a foot gun designed to blow my foot off. Why? What context is that foot gun appropriate? Should I put it in the hammer toolbox? C++ has footguns everywhere and there's no context where many of those footguns are appropriate. The other thing with C++ is the complexity. The toolbox is so jam packed full of millions of tools I have basically can't comprehend the full ecosystem and how everything works. Additionally I pick one tool and that single tool itself has like 20 different ways of being used with a bunch of edge case gotchas.
agumonkey 4y ago
I think I've seen stroustrup say that in a few talks.
froh 4y ago
Isn't that focus on a core c++ feature subset and coding patterns also the idea behind the "c++ core guidelines"? https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
- deleted 4y ago
  [deleted]
- tialaramex 4y ago
  Sure, the effect of such guidelines, including the "Core Guidelines" is to further shatter the language into effectively incompatible dialects while not really solving anything. One of the book's authors actually proposed work to get C++ to a place where C++ 20 could begin actually abolishing the things everybody agrees you shouldn't do, Vittorio's "Epochs" proposal. https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs.html https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs... But the preference for C++ 20 was to add yet further stuff. I believe that, unwittingly, the C++ 20 process sealed the fate of the language in choosing to land features like Concepts but not attempt Epochs, I'm not sure it was actually possible, but if it wasn't possible in 2020 it's not going to be any easier in 2026 and it's only going to be more necessary.
  - ncmncm 4y ago
    This is of course false. The active subset is always the set of features not supplanted by the latest Standard supported by tooling in use. Anything newer is safer and nicer than old crap, so there is no temptation to stick to old crap, except among people who have elected not to learn anything new. Those are typically approaching retirement anyway.
    - tialaramex 4y ago
      What part is false? The part where Vittorio proposed Epochs to fix this? The part where the Committee decided not to take it? Do you think that fixing this will magically get easier if you wait longer?

colejohnson66 4y ago

If I have to use a subset of a language to avoid shooting my feet, why not just use a language without footguns?

faitswulff 4y ago
Not every project can be a greenfield project.
- deltaonefour 4y ago
  I agree but C++ is so ingrained that tons of greenfield projects end up using C++ because of libraries and because too many people are used to it.
  - ncmncm 4y ago
    In other words, C++ is too useful not to use. A lot.
    - thfuran 4y ago
      Well, no. Too used to not use.
loeg 4y ago
There are lots of other advantages and disadvantages to any given language. You’re right that this is a mark against C++, but wrong in the assumption that it (always) outweighs all other considerations (performance, familiarity, compatibility with existing C++ codebase, portability to odd architectures). (Personally, I don’t like C++ and prefer Rust. But it is also reasonable to choose C++.)
jstx1 4y ago
Because that subset can still be better at solving your problem than those other languages - it could be faster, more mature, better at solving certain problems, you can leverage existing ecosystem etc.
- Koshkin 4y ago
  This is exactly true. Noone in the C++ world uses all of C++ in their project. It is a multi-paradigm language, and you are free to choose one (or a few) of the paradigms and follow it throughout the entire project. For example, you can choose to base your project on virtual functions and interfaces, or you can choose to employ static polymorphism instead. Remarkably, even the C++ standard library, for all its intricacy and complexity, does not use all of C++. Also, it is useful to see C++ as two languages, one for library developers, and one for developers of applications.
arinlen 4y ago
> If I have to use a subset of a language to avoid shooting my feet, why not just use a language without footguns? Because it has absolutely nothing to do with footguns. The main factors in picking subsets, beyond personal tastes on coding styles and office politics, boil down to a) introducing exceptions in legacy code, and thus the need to revalidate what is otherwise solid code, b) not be forced to deal with the complexity of template metaprogramming when the value it adds back is negligible.
jandrewrogers 4y ago
Because different types of software make good use of different subsets of C++. A "footgun" for one codebase is a "high-leverage feature" for another code base. The subset of "no footguns" C++ that is common to virtually all applications probably asymptotically converges on the empty set. A feature of C++ is that you can precisely select an optimally expressive subset for most applications instead of being forced to write code in language that clearly wasn't designed with your use case in mind. Having a lot of tools in your toolbox doesn't necessitate using all of them in inappropriate contexts. I don't try to hammer a screw just because I own a hammer.
- deltaonefour 4y ago
  This analogy sounds nice but is deceptive. The problem is there's no place where a foot gun is appropriate. I need a toolbox for screwing things so I get a screwdriver toolbox, but in that toolbox is a foot gun designed to blow my foot off. Why? What context is that foot gun appropriate? Should I put it in the hammer toolbox? C++ has footguns everywhere and there's no context where many of those footguns are appropriate. The other thing with C++ is the complexity. The toolbox is so jam packed full of millions of tools I have basically can't comprehend the full ecosystem and how everything works. Additionally I pick one tool and that single tool itself has like 20 different ways of being used with a bunch of edge case gotchas.

agumonkey 4y ago

I think I've seen stroustrup say that in a few talks.

froh 4y ago

Isn't that focus on a core c++ feature subset and coding patterns also the idea behind the "c++ core guidelines"? https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

deleted 4y ago
[deleted]
tialaramex 4y ago
Sure, the effect of such guidelines, including the "Core Guidelines" is to further shatter the language into effectively incompatible dialects while not really solving anything. One of the book's authors actually proposed work to get C++ to a place where C++ 20 could begin actually abolishing the things everybody agrees you shouldn't do, Vittorio's "Epochs" proposal. https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs.html https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs... But the preference for C++ 20 was to add yet further stuff. I believe that, unwittingly, the C++ 20 process sealed the fate of the language in choosing to land features like Concepts but not attempt Epochs, I'm not sure it was actually possible, but if it wasn't possible in 2020 it's not going to be any easier in 2026 and it's only going to be more necessary.
- ncmncm 4y ago
  This is of course false. The active subset is always the set of features not supplanted by the latest Standard supported by tooling in use. Anything newer is safer and nicer than old crap, so there is no temptation to stick to old crap, except among people who have elected not to learn anything new. Those are typically approaching retirement anyway.
  - tialaramex 4y ago
    What part is false? The part where Vittorio proposed Epochs to fix this? The part where the Committee decided not to take it? Do you think that fixing this will magically get easier if you wait longer?