9 ms·

Nice to see some concrete examples of where you don't want exceptions, rtti or dynamic memory. Quite a few developers believe that if you don't have these feat

Nice to see some concrete examples of where you don't want exceptions, rtti or dynamic memory. Quite a few developers believe that if you don't have these features you aren't writing "real C++" but it's common practice in quite a few industries where size/performance is critical.

kartD 10y ago
Very true, I'd wager that a significant portion (20-30%) of all of the existing C/C++ codebase fits this description.
vonmoltke 10y ago
I think that attitude deserves some mention in the section discussing why C++ doesn't get used more often. If you listen to the faction who denigrates anything that looks like "C with classes" then C++ is fundamentally incompatible with bare-metal programming.
- pjmlp 10y ago
  Mostly because the "C with classes" crowd tend to be C developers dragged into using a C++ compiler. Personally I like to turn everything on, but I also understand there are use-cases where it isn't possible. My first C++ compiler was Turbo C++ 1.0 for MS-DOS, so I also used this kind of bare metal programming back in the day. What I don't like is "C with classes" which throws away all the safety mechanisms that C++ offers over C, to the point the code could be compiled with a C compiler. However the advices presented in the "Practical Guide to Bare Metal C++" look quite good.
  - evincarofautumn 10y ago
    There’s something to be said for only using those features of C++ that you really need, if not because the platform demands it, then at least because it goes easier on the language-lawyering part of the brain. I for one am perfectly happy with “C with destructors and templates”. The usual criticism of “C with classes” is levelled at a specific kind of code that’s neither particularly good C++ nor particularly good C. But not all “C with classes” is necessarily that way.
- fsloth 10y ago
  "If you listen to..." No-one should need to listen to a bunch of fanatics. Different problems are have different constraints. Some problems are easier to solve using a different formalism than some other. People try to sound like Herb Sutter or Stroustrup when peddling their "best practice" advice after looking at a few lines of code and deciding it's not to their liking. Sutter and Stroustrup usually have a grasp of the higher level context, while random best practice commisars in the web, seldom dont. Since C++ contains so many footguns the charitable explanation is that they grasp to the only way of coding they can hold in their head. Damn the establishment! C++ offers a refreshing multiplicty of styles of implementation. ML style for data transforms, lispish dynamic lists for parsers, vanilla object style for some problem domains, relational style with structs of indices for others. Note: solutions of these styles can be wrapped in a nice cplusplushy interface but if one starts to solve the problem from the point of view of designing the class hierarchy rather than looking at the data and transforms required often leads to a technically inferior dessign (by which I mean - my designs became much better after I understood to focus on the latter and not the former). One needs to be strict, yes, but the strictness needs to be on a closer-core-cs-concepts level and not on the class design level. Just wrote a parser in lisp style C++ and loved it (and yes, there were enough constraints to limit C++ as the only language).
  - vardump 10y ago
    You seem to be talking about usual C++ programming, not bare metal case. Bare metal means no OS, no runtime, no nothing.
    - pjmlp 10y ago
      Runtime is always there, even if it is a thin library to talk to IO pins, or whatever board you happen to plug in.
      - vardump 10y ago
        > thin library to talk to IO pins That might be a bit bad example, because IO pin control is usually compiled to just one or at most a few machine instructions. IO pin control for those is often a macro or intrinsic, not really a library. Sometimes there's no runtime, other than what you implement. That's true bare metal.
maxxxxx 10y ago
In my mind "real C++" doesn't use RTTI much but relies more on the compiler to figure out things. This and exceptions are things I generally try to avoid as much as possible. I am big fan of templates though.
- fish2000 10y ago
  Yes, there is a Zen state of C++ programming wherein you, the programmer, surrender to the wisdom of the compiler, and in doing so are liberated from caring about the minutiae of the type system, to be carried forth, skyward, on the twin winds of inference and overload resolution. I do enjoy that. RTTI is nothing like this – it’s a red herring, neither elegant nor powerful… at best it’s a misnomer (it’s more like RTT total lack of I, amirite) and at worst a distraction. I dislike exceptions too, but in a difference-of-opinion way where I can be like “OK, that otherwise legible and reasonable code uses exceptions, unlike mine” and it doesn’t make me grimace like I involuntarily do for RTTI… I’d love to be mistaken tho, anyone with an inspiring counterexample, do share.
jandrewrogers 10y ago
Maybe my experience is atypical but RTTI and exceptions are features of C++ that I never see used in real-world C++ almost regardless of the application. When I have seen them used, it is by people new to C++ that haven't fully figured out the common development idioms of the language yet.
- jlarocco 10y ago
  I've never seen RTTI use in production code. Even with modern C++, RTTI almost always adds too much runtime overhead and negative performance impacts. Most importantly, it's usually a sign of bad design. My experience with exceptions is different, though, and I see them used quite a bit. It depends a lot on the age of the code base and the group working on it. Old code is less likely to use them, and developers with a heavy C background, or a lot of pre-C++98 experience are less like to use them. Except for maybe some tiny embedded systems (like microcontrollers), the overhead of exceptions isn't that bad any more.
  - vvanders 10y ago
    My experience has been no rtti and no exceptions. Quite a few compilers generate rtti if you use exceptions. Generally I haven't found any error handling solution where exceptions provided superior semantics. The lack of checking means that you can catch more bugs with enum error codes + switch and Wall.
  - fauigerzigerk 10y ago
    The strange thing about exceptions in C++ is that they make ubiquitous use of RAII a necessity, but at the same time they must not be thrown in destructors. And then C++ exceptions don't come with a stack trace that makes quick and dirty exceptions based code so convenient in Java or C#. I was never a principled opponent of exceptions, but I find myself removing them from more and more code the more thoroughly I think about all the possible error states of code that should really be robust.
    - tibbetts 10y ago
toby 10y ago
The Google C++ style [1] guide bans exceptions entirely and strongly advises against RTTI. [1] https://google.github.io/styleguide/cppguide.html https://google.github.io/styleguide/cppguide.html
- nomel 10y ago
  This link is constantly misused. Their reason is having to support legacy code that can't handle exceptions. That's it. From that link: "However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions." Would the use exceptions if they could do it again?
  - vvanders 10y ago
    LLVM [1] has very similar restrictions for different reasons. [1] http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or...
  - amaks 10y ago
    No. The reason they don't use exceptions is because they lead to unreliable code that is difficult to maintain. There are other ways to indicate error situations such as returning error result that caller must handle.
    - maxlybbert 10y ago
      From the Google style guide (section on exceptions): "On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions. "Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in a new project. The conversion process would be slow and error-prone. We don't believe that the available alternatives to exceptions, such as error codes and assertions, introduce a significant burden. "Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. ... Things would probably be different if we had to do it all over again from scratch."
PopsiclePete 10y ago
Honest question: At some point, why even bother with C++? The streams library is a mess - don't use it. Exceptions are too slow - don't use 'em. Can't have exceptions, can't have RAII, MI is bad in 99% of cases - avoid. At some point, you're left with "C with classes", maybe with some templates sprinkled here and there, and nice map/list/string implementations. Ok fine. So is this still C++? And if it is, and if it's exactly what you need, and C is still not good enough, maybe there's a use-case for either a new language, call is --C++, or some kind of "C++ without the bad stuff" accepted standard to drive the entire eco-system forward with well-defined features, boundaries, libraries, tools, all that good stuff?
- kchoudhu 10y ago
  The more I mess around with Rust, the more it seems to fit the bill as the new --C++.
- pandaman 10y ago
  I don't feel like I have to use every single feature of a language. I prefer C++ over C for: namespaces, overloads, encapsulation and user defined types. E.g. I'd rather write simple expressions for vector math than a bunch of function calls. I'd rather have the compiler enforce the type invariants than do runtime checks everywhere. I'd rather have my ids without prefixes to evade name conflicts etc. etc. As for your proposal - why? I can already disable exceptions and RTTI with compiler switches. And is it really a sane idea to spin off a new language if you don't like some library?

kartD 10y ago

Very true, I'd wager that a significant portion (20-30%) of all of the existing C/C++ codebase fits this description.

vonmoltke 10y ago

I think that attitude deserves some mention in the section discussing why C++ doesn't get used more often. If you listen to the faction who denigrates anything that looks like "C with classes" then C++ is fundamentally incompatible with bare-metal programming.

pjmlp 10y ago
Mostly because the "C with classes" crowd tend to be C developers dragged into using a C++ compiler. Personally I like to turn everything on, but I also understand there are use-cases where it isn't possible. My first C++ compiler was Turbo C++ 1.0 for MS-DOS, so I also used this kind of bare metal programming back in the day. What I don't like is "C with classes" which throws away all the safety mechanisms that C++ offers over C, to the point the code could be compiled with a C compiler. However the advices presented in the "Practical Guide to Bare Metal C++" look quite good.
- evincarofautumn 10y ago
  There’s something to be said for only using those features of C++ that you really need, if not because the platform demands it, then at least because it goes easier on the language-lawyering part of the brain. I for one am perfectly happy with “C with destructors and templates”. The usual criticism of “C with classes” is levelled at a specific kind of code that’s neither particularly good C++ nor particularly good C. But not all “C with classes” is necessarily that way.
fsloth 10y ago
"If you listen to..." No-one should need to listen to a bunch of fanatics. Different problems are have different constraints. Some problems are easier to solve using a different formalism than some other. People try to sound like Herb Sutter or Stroustrup when peddling their "best practice" advice after looking at a few lines of code and deciding it's not to their liking. Sutter and Stroustrup usually have a grasp of the higher level context, while random best practice commisars in the web, seldom dont. Since C++ contains so many footguns the charitable explanation is that they grasp to the only way of coding they can hold in their head. Damn the establishment! C++ offers a refreshing multiplicty of styles of implementation. ML style for data transforms, lispish dynamic lists for parsers, vanilla object style for some problem domains, relational style with structs of indices for others. Note: solutions of these styles can be wrapped in a nice cplusplushy interface but if one starts to solve the problem from the point of view of designing the class hierarchy rather than looking at the data and transforms required often leads to a technically inferior dessign (by which I mean - my designs became much better after I understood to focus on the latter and not the former). One needs to be strict, yes, but the strictness needs to be on a closer-core-cs-concepts level and not on the class design level. Just wrote a parser in lisp style C++ and loved it (and yes, there were enough constraints to limit C++ as the only language).
- vardump 10y ago
  You seem to be talking about usual C++ programming, not bare metal case. Bare metal means no OS, no runtime, no nothing.
  - pjmlp 10y ago
    Runtime is always there, even if it is a thin library to talk to IO pins, or whatever board you happen to plug in.
    - vardump 10y ago
      > thin library to talk to IO pins That might be a bit bad example, because IO pin control is usually compiled to just one or at most a few machine instructions. IO pin control for those is often a macro or intrinsic, not really a library. Sometimes there's no runtime, other than what you implement. That's true bare metal.

maxxxxx 10y ago

In my mind "real C++" doesn't use RTTI much but relies more on the compiler to figure out things. This and exceptions are things I generally try to avoid as much as possible. I am big fan of templates though.

fish2000 10y ago
Yes, there is a Zen state of C++ programming wherein you, the programmer, surrender to the wisdom of the compiler, and in doing so are liberated from caring about the minutiae of the type system, to be carried forth, skyward, on the twin winds of inference and overload resolution. I do enjoy that. RTTI is nothing like this – it’s a red herring, neither elegant nor powerful… at best it’s a misnomer (it’s more like RTT total lack of I, amirite) and at worst a distraction. I dislike exceptions too, but in a difference-of-opinion way where I can be like “OK, that otherwise legible and reasonable code uses exceptions, unlike mine” and it doesn’t make me grimace like I involuntarily do for RTTI… I’d love to be mistaken tho, anyone with an inspiring counterexample, do share.

jandrewrogers 10y ago

Maybe my experience is atypical but RTTI and exceptions are features of C++ that I never see used in real-world C++ almost regardless of the application. When I have seen them used, it is by people new to C++ that haven't fully figured out the common development idioms of the language yet.

jlarocco 10y ago
I've never seen RTTI use in production code. Even with modern C++, RTTI almost always adds too much runtime overhead and negative performance impacts. Most importantly, it's usually a sign of bad design. My experience with exceptions is different, though, and I see them used quite a bit. It depends a lot on the age of the code base and the group working on it. Old code is less likely to use them, and developers with a heavy C background, or a lot of pre-C++98 experience are less like to use them. Except for maybe some tiny embedded systems (like microcontrollers), the overhead of exceptions isn't that bad any more.
- vvanders 10y ago
  My experience has been no rtti and no exceptions. Quite a few compilers generate rtti if you use exceptions. Generally I haven't found any error handling solution where exceptions provided superior semantics. The lack of checking means that you can catch more bugs with enum error codes + switch and Wall.
- fauigerzigerk 10y ago
  The strange thing about exceptions in C++ is that they make ubiquitous use of RAII a necessity, but at the same time they must not be thrown in destructors. And then C++ exceptions don't come with a stack trace that makes quick and dirty exceptions based code so convenient in Java or C#. I was never a principled opponent of exceptions, but I find myself removing them from more and more code the more thoroughly I think about all the possible error states of code that should really be robust.
  - tibbetts 10y ago

toby 10y ago

The Google C++ style [1] guide bans exceptions entirely and strongly advises against RTTI. [1] https://google.github.io/styleguide/cppguide.html https://google.github.io/styleguide/cppguide.html

nomel 10y ago
This link is constantly misused. Their reason is having to support legacy code that can't handle exceptions. That's it. From that link: "However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions." Would the use exceptions if they could do it again?
- vvanders 10y ago
  LLVM [1] has very similar restrictions for different reasons. [1] http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or...
- amaks 10y ago
  No. The reason they don't use exceptions is because they lead to unreliable code that is difficult to maintain. There are other ways to indicate error situations such as returning error result that caller must handle.
  - maxlybbert 10y ago
    From the Google style guide (section on exceptions): "On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions. "Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in a new project. The conversion process would be slow and error-prone. We don't believe that the available alternatives to exceptions, such as error codes and assertions, introduce a significant burden. "Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. ... Things would probably be different if we had to do it all over again from scratch."

PopsiclePete 10y ago

Honest question: At some point, why even bother with C++? The streams library is a mess - don't use it. Exceptions are too slow - don't use 'em. Can't have exceptions, can't have RAII, MI is bad in 99% of cases - avoid. At some point, you're left with "C with classes", maybe with some templates sprinkled here and there, and nice map/list/string implementations. Ok fine. So is this still C++? And if it is, and if it's exactly what you need, and C is still not good enough, maybe there's a use-case for either a new language, call is --C++, or some kind of "C++ without the bad stuff" accepted standard to drive the entire eco-system forward with well-defined features, boundaries, libraries, tools, all that good stuff?

kchoudhu 10y ago
The more I mess around with Rust, the more it seems to fit the bill as the new --C++.
pandaman 10y ago
I don't feel like I have to use every single feature of a language. I prefer C++ over C for: namespaces, overloads, encapsulation and user defined types. E.g. I'd rather write simple expressions for vector math than a bunch of function calls. I'd rather have the compiler enforce the type invariants than do runtime checks everywhere. I'd rather have my ids without prefixes to evade name conflicts etc. etc. As for your proposal - why? I can already disable exceptions and RTTI with compiler switches. And is it really a sane idea to spin off a new language if you don't like some library?