Subject: Re: [boost] Variant2 review
From: Robert Ramey (ramey_at_[hidden])
Date: 2019-04-09 01:40:15
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
> 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?
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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk