6 ms·

My mental image of C++ is a tool which is great when used by an expert, but has lots of sharp edges which can cut you if you're not careful - so not something I

by rob74 4y ago

My mental image of C++ is a tool which is great when used by an expert, but has lots of sharp edges which can cut you if you're not careful - so not something I would apply the verb "embrace" to...

Koshkin 4y ago
Hence this book.
sgeisenh 4y ago
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?
jmspring 4y ago
Computer science programs used to teach variations of C/C++. Last I checked where I went as well as talking to junior engineers I have worked with. You can get through a whole CS program at a dop 50 university without touching the language. There have been debates here about C/C++ being "dangerous". And it can be, if you don't know how to use it. I recall discussions where doing in-line assembly in C had a similar discussion. It doesn't take being an "expert". It does take "understanding what you are doing" but that same thing applies regardless of the language/tool/etc.
- criddell 4y ago
  The depth of what you want to understand with C++ is sometimes pretty deep though. I’m thinking about things like lvalues, rvalues, const vs constexpr, etc…
- garren 4y ago
  Wouldn’t you say that “understanding what your doing” applies a little more to C/C++ than many other languages/tools/etc? Both Microsoft[0] and Google[1] have established that ~70% of the defects they encounter in their flagship products and systems are memory-related, and generally attributed to the “dangers” of the underlying language: C++ It seems significant that, given that the individuals working on these projects are professionals, experts by some definition, they too are encountering issues related to the sharp edges of these languages. Issues that have wide ranging implications. In light of that, doesn’t saying that “understanding what you’re doing” is all it takes to productively and safely use a language like C/C++ seem simplistic? Even the experts are getting it wrong. I took a couple C++ classes in college. I’ve worked on both desktop and backend C++ systems in both C++98 and ‘11. It can be a difficult language, it has more than its share of footguns, it definitely helped me appreciate other languages that don’t have similar issues. [0] https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro... [1] https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
  - nyanpasu64 4y ago
deltaonefour 4y ago
That's not even the right analogy. I think of it more as a rotary phone dial. It's old and overly complex and poorly designed. It's still in use for legacy reasons and because you have tons of these "experts" who have invested so much time and pride into it they actually can't really accept the fact that legacy is the only reason why C++ is still here. The problem is the nature of programming makes it so that once a language embeds itself into the infrastructure it's hard to remove or upgrade. Very similar to how most of the front end world is stuck with javascript. JavaScript as ugly as it is, is nowhere near the monstrosity that C++ has become though.

by rob74 4y ago

My mental image of C++ is a tool which is great when used by an expert, but has lots of sharp edges which can cut you if you're not careful - so not something I would apply the verb "embrace" to...

Koshkin 4y ago

Hence this book.

sgeisenh 4y ago

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?

jmspring 4y ago

Computer science programs used to teach variations of C/C++. Last I checked where I went as well as talking to junior engineers I have worked with. You can get through a whole CS program at a dop 50 university without touching the language. There have been debates here about C/C++ being "dangerous". And it can be, if you don't know how to use it. I recall discussions where doing in-line assembly in C had a similar discussion. It doesn't take being an "expert". It does take "understanding what you are doing" but that same thing applies regardless of the language/tool/etc.

criddell 4y ago
The depth of what you want to understand with C++ is sometimes pretty deep though. I’m thinking about things like lvalues, rvalues, const vs constexpr, etc…
garren 4y ago
Wouldn’t you say that “understanding what your doing” applies a little more to C/C++ than many other languages/tools/etc? Both Microsoft[0] and Google[1] have established that ~70% of the defects they encounter in their flagship products and systems are memory-related, and generally attributed to the “dangers” of the underlying language: C++ It seems significant that, given that the individuals working on these projects are professionals, experts by some definition, they too are encountering issues related to the sharp edges of these languages. Issues that have wide ranging implications. In light of that, doesn’t saying that “understanding what you’re doing” is all it takes to productively and safely use a language like C/C++ seem simplistic? Even the experts are getting it wrong. I took a couple C++ classes in college. I’ve worked on both desktop and backend C++ systems in both C++98 and ‘11. It can be a difficult language, it has more than its share of footguns, it definitely helped me appreciate other languages that don’t have similar issues. [0] https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro... [1] https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
- nyanpasu64 4y ago

deltaonefour 4y ago

That's not even the right analogy. I think of it more as a rotary phone dial. It's old and overly complex and poorly designed. It's still in use for legacy reasons and because you have tons of these "experts" who have invested so much time and pride into it they actually can't really accept the fact that legacy is the only reason why C++ is still here. The problem is the nature of programming makes it so that once a language embeds itself into the infrastructure it's hard to remove or upgrade. Very similar to how most of the front end world is stuck with javascript. JavaScript as ugly as it is, is nowhere near the monstrosity that C++ has become though.