[bsder]

> This is language-version-specific behavioral minutiae that anyone can look up in 5 minutes in the rare case it matters, and is otherwise irrelevant to engineering software at a senior level.

The fact that C++ programming books have entire sections about destructors (see: Effective C++) shows that this is very much not irrelevant minutiae. C++ forces you to deal with this kind of detail all the time.

Now, we can have a much more interesting discussion about whether C++ is a disaster of a language precisely because you are forced to deal with this kind of minutiae by hand. We could also have an interesting discussion about whether RAII is the "object oriented" of our time. We could even have an interesting discussion as to why so many companies ban constructors/destructors in their C++ programming guidelines.

However, irrelevant minutiae C++ destructors are not.

[112233]

What book covers in depth *throwing* from destructors? Even more sane thing — throwing from constructors and function arguments — is mentioned in passing ("unwind will take care of everything, don't think too hard about it") unless you are in a language lawyer mailing list. But exceptions *during destruction*? What book discusses that? That's like covering use of NaN values as map<> keys...

[bsder]

"Effective C++" ?

  Chapter 2: Constructors, Destructors, and Assignment Operators
      Item 5: Know what functions C++ silently writes and calls.
      Item 6: Explicitly disallow the use of compiler generated functions you do not want.
      Item 7: Declare destructors virtual in polymorphic base classes.
      Item 8: Prevent exceptions from leaving destructors.
      Item 9: Never call virtual functions during construction or destruction.
      Item 10: Have assignment operators return a reference to *this.
      Item 11: Handle assignment to self in operator=.
      Item 12: Copy all parts of an object.

This stuff is bread and butter of C++ (or at least it used to be; perhaps this is different in "modern" C++) and lots and lots of grist for people like Scott Meyers and Herb Sutter.

[112233]

"Prevent exceptions from leaving destructors." — thank you for providing well known sources that support my point! Although sadly we all have to eat Sutter Meyers bread, at least it explicitly tells you to not worry about the way exceptions are handled during object destruction — by simply avoiding such exceptions.

No C++ "bread and butter" I have seen so far goes into depth on this subject.

[dotancohen]

Ban constructors? Though I don't agree with the practice, I could imagine a reason for banning destructors. But constructors? Why?

[bsder]

Because the two go together. If you have to ban one, you pretty much have to ban both.

Although, I guess if you only statically allocated everything once at startup, you could use constructors without destructors? Presumably using the placement versions would also let you use constructors without destructors.

I'm generally talking about systems that are <64KB. You basically don't get heap and determinism is really important.

[dotancohen]

I see, thank you. I have never done embedded.