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.
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)
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?"
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"
> 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.
There's nothing essential to know about what happens when a destructor throws other than it's bad and don't do it. Especially if the effect is to terminate.
I hate this style of interviewing which is more about the interviewer feeling good about themselves rather than doing their job and assessing candidates. Just wastes everyone's time all around.
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.
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)
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?"
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"
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!!!
> 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.
Well, now those who will go to look it up in 5 minutes may end up reading this guy’s article.
“The camera is the least important element in photography.”
I... I did not expect that noexcept(false) works on destructors
There's nothing essential to know about what happens when a destructor throws other than it's bad and don't do it. Especially if the effect is to terminate.
I hate this style of interviewing which is more about the interviewer feeling good about themselves rather than doing their job and assessing candidates. Just wastes everyone's time all around.
No mention of vtables or thunks? We decided to proceed with another candidate.