On 4/8/19 6:08 PM, Gavin Lambert via Boost wrote:
On 9/04/2019 11:13, Niall Douglas wrote:
Why do you bother with the #ifdef NDEBUG ?
It signifies "this is important for the final release binary" i.e. please ask one of the tech leadership if you break this.
It has no technical meaning. But it is *very* effective at worrying people.
Its technical meaning is that during development in debug builds (which presumably people should be using most of the time in order to verify runtime asserts and other things like debug iterators and debug heaps), all of these asserts are disabled, so people don't discover that they did something wrong at the time that they broke it, which makes it harder to discover what they broke.+1
So it seems like an odd choice, unless something about a debug build makes the assertion untrue (eg. debug components changing sizeof).
Why not use #ifndef JUNIOR_DEVS_DONT_TOUCH or something similarly never defined (and so never disabling the check) but expressing your real intent? -1
First of all I'm with Naill in using static_assert alot. But I come at it from a different place. A big concern of mine is the explicit specification of type requirements. This has now been subsumed in C++ as "concepts". Ideally, I like to see the type requirements as explicitly list for each type in the documentation and mirrored in the code. It might seem redundant, but it's not. One is the interface design and the other is the implementation. using static_assert for this purpose is a perfect match. In my opinion - C++ concepts as specified for C++20 are superfluous. Short version: a) I think you're doing it basically right b) It's a mistake to characterize this iast "protection against other developers. Actually it could be considered offensive to other developers. We all need to do our part for creating a safe space for those other developers. c) It's better to see it as using the compiler to explicity enforce type requirements in order to get correct code. Robert Ramey.