5 ms·

> It makes me wonder if this can be solved technically by published curated language subsets. I'm biased, but I generally find the Google C++ Style Guide to be

> It makes me wonder if this can be solved technically by published curated language subsets. I'm biased, but I generally find the Google C++ Style Guide to be a good curation of C++: https://google.github.io/styleguide/cppguide.html https://google.github.io/styleguide/cppguide.html I generally stick to it in all projects I write. The only exception is that in a few cases I'll use features that are disallowed in Google C++ primarily for historical reasons, most notably exceptions: https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions

kevin_thibedeau 7y ago
The problem with exception-less C++ is that new, delete, ctors, and dtors become timebombs when they fail in a way that would have generated an exception.
- keldaris 7y ago
  I'm not sure why you were downvoted. I almost exclusively write exception-less C++ (compiling everything with "-fno-exceptions"), but correctly handling errors in constructors and destructors is absolutely an important concern. It's not hard to do, obviously, but it does require forethought and heavily encourages delegating complex logic to other parts of the code.
- heinrich5991 7y ago
  dtors that throw come with their own share of problems: If they do so while another exception is in flight (dtors are still called for objects when the stack is being unwound(?)), C++ crashes the process.
- NikkiA 7y ago
  If new fails your program crashing is probably going to be the only outcome anyway, might as well fail from an unhandled exception. And if you're putting things that can throw exceptions in your ctors or dtors you're probably already writing code that is a timebomb
malkia 7y ago
For our code base we avoid exceptions, except when due to awkard workarounds, or kludges mostly due to some API that's written in a way that you need to communicate with it with exceptions. That to be said, even if you don't use exceptions in C++ - you must write exception safe code - e.g. as much as possible no manual "begin"/"end" but wrap things behind RAII, such that "end" is still called, in case of exception. Hence allocation through unique_ptr, shared_ptr, etc. is preferred over new/delete. Because you never know the function you are calling whether deep down it won't throw an exception...

kevin_thibedeau 7y ago

The problem with exception-less C++ is that new, delete, ctors, and dtors become timebombs when they fail in a way that would have generated an exception.

keldaris 7y ago
I'm not sure why you were downvoted. I almost exclusively write exception-less C++ (compiling everything with "-fno-exceptions"), but correctly handling errors in constructors and destructors is absolutely an important concern. It's not hard to do, obviously, but it does require forethought and heavily encourages delegating complex logic to other parts of the code.
heinrich5991 7y ago
dtors that throw come with their own share of problems: If they do so while another exception is in flight (dtors are still called for objects when the stack is being unwound(?)), C++ crashes the process.
NikkiA 7y ago
If new fails your program crashing is probably going to be the only outcome anyway, might as well fail from an unhandled exception. And if you're putting things that can throw exceptions in your ctors or dtors you're probably already writing code that is a timebomb

malkia 7y ago

For our code base we avoid exceptions, except when due to awkard workarounds, or kludges mostly due to some API that's written in a way that you need to communicate with it with exceptions. That to be said, even if you don't use exceptions in C++ - you must write exception safe code - e.g. as much as possible no manual "begin"/"end" but wrap things behind RAII, such that "end" is still called, in case of exception. Hence allocation through unique_ptr, shared_ptr, etc. is preferred over new/delete. Because you never know the function you are calling whether deep down it won't throw an exception...