4 ms·

Don’t know who this guy is, but I’m glad I never interviewed with him. This is language-version-specific behavioral minutiae that anyone can look up in 5 minute

by avalys 6mo ago

Don’t know who this guy is, but I’m glad I never interviewed with him. 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. This article is a junior engineer’s idea of what a senior engineer should know.

nvch 6mo ago
Well, now those who will go to look it up in 5 minutes may end up reading this guy’s article.
rhoopr 6mo ago
“The camera is the least important element in photography.”
p1necone 6mo ago
This feels like an overly negative comment. language specific minutiae is interesting to a lot of developers, and this kind of stuff is exactly what you'd ask if someone claimed to be an experienced C++ developer. You're not going to decide not to hire them based on them not knowing this specific thing, but if you ask them 5 different questions about specific behaviour/edge cases/whatever and they don't know any of them it's probably a bad sign. (Although "this is bad practice, I've never done it, I didn't care to look up details" would be a perfectly fine answer to me if I was the interviewer)
- BobbyTables2 6mo ago
  Damn. Just the new C++ syntax for this stuff makes it seem like a foreign language. It’s no longer the C++ from 20 years ago. Raising exceptions in a destructor sounds even more fun than a “return” statement inside a Python “finally” block of a method. The footgun store will never go out of business!!!
- zarzavat 6mo ago
  It's as close as you can get to useless knowledge. It's like asking a pilot "exactly how will the aircraft break apart if you nose dive it at high speed into the ground?"
  - throwaway27448 6mo ago
    This analogy makes a lot of sense until you need to deal with an exception emanating from a destructor... then it looks a lot more like "what's the proper way to hold a chainsaw"
    - foltik 6mo ago
      I want to play a game. In your hands is a chainsaw about to be destructed. Another exception is already in flight. Live, or std::terminate. Make your choice. -Jigsaw
- menaerus 6mo ago
  I am an experienced C++ developer, I know what happens in this particular case, but this type of minutiae are only interesting to the developers who have never had an actually hard problem to solve so it's a red flag to me as well. 10 years ago I would have thought differently but today I do not. High performance teams do not care about this stuff.
bsder 6mo ago
> 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.
- dotancohen 6mo ago
  Ban constructors? Though I don't agree with the practice, I could imagine a reason for banning destructors. But constructors? Why?
  - bsder 6mo ago
    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 6mo ago
      I see, thank you. I have never done embedded.
- 112233 6mo ago
  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...
112233 6mo ago
If you noticed, the article did not actually tell you what happens when destructor throws. It was only about double-exception case and throwing in nothrow() function (both perfectly valid things to know when jobbing). What state are members left in when destructor throws? If exception happens in virtual base? If member destructor throws, what other class members have they destructor executed? will delete[] be called? The author possibly does not care to know themselves! As you say, totally irrelevant to any normal programming. Unless you are writing clang or gdb

by avalys 6mo ago

nvch 6mo ago

Well, now those who will go to look it up in 5 minutes may end up reading this guy’s article.

rhoopr 6mo ago

“The camera is the least important element in photography.”

p1necone 6mo ago

This feels like an overly negative comment. language specific minutiae is interesting to a lot of developers, and this kind of stuff is exactly what you'd ask if someone claimed to be an experienced C++ developer. You're not going to decide not to hire them based on them not knowing this specific thing, but if you ask them 5 different questions about specific behaviour/edge cases/whatever and they don't know any of them it's probably a bad sign. (Although "this is bad practice, I've never done it, I didn't care to look up details" would be a perfectly fine answer to me if I was the interviewer)

BobbyTables2 6mo ago
Damn. Just the new C++ syntax for this stuff makes it seem like a foreign language. It’s no longer the C++ from 20 years ago. Raising exceptions in a destructor sounds even more fun than a “return” statement inside a Python “finally” block of a method. The footgun store will never go out of business!!!
zarzavat 6mo ago
It's as close as you can get to useless knowledge. It's like asking a pilot "exactly how will the aircraft break apart if you nose dive it at high speed into the ground?"
- throwaway27448 6mo ago
  This analogy makes a lot of sense until you need to deal with an exception emanating from a destructor... then it looks a lot more like "what's the proper way to hold a chainsaw"
  - foltik 6mo ago
    I want to play a game. In your hands is a chainsaw about to be destructed. Another exception is already in flight. Live, or std::terminate. Make your choice. -Jigsaw
menaerus 6mo ago
I am an experienced C++ developer, I know what happens in this particular case, but this type of minutiae are only interesting to the developers who have never had an actually hard problem to solve so it's a red flag to me as well. 10 years ago I would have thought differently but today I do not. High performance teams do not care about this stuff.

bsder 6mo ago

> 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.

dotancohen 6mo ago
Ban constructors? Though I don't agree with the practice, I could imagine a reason for banning destructors. But constructors? Why?
- bsder 6mo ago
  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 6mo ago
    I see, thank you. I have never done embedded.
112233 6mo ago
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...

112233 6mo ago

If you noticed, the article did not actually tell you what happens when destructor throws. It was only about double-exception case and throwing in nothrow() function (both perfectly valid things to know when jobbing). What state are members left in when destructor throws? If exception happens in virtual base? If member destructor throws, what other class members have they destructor executed? will delete[] be called? The author possibly does not care to know themselves! As you say, totally irrelevant to any normal programming. Unless you are writing clang or gdb