From: Jeffrey Faust (jefffaust_at_[hidden])
Date: 2007-05-22 17:20:54
On Tue, 22 May 2007 13:38:18 -0700, Giovanni Piero Deretta
> This means that optional becomes bigger when debugging is enabled, right?
> Also, is debugging enabled when NDEBUG is not defined, right (it seems
> so looking at the patch)?
> I think that this functionality would be useful (even if I haven't
> needed it yet), but I think it should be enabled by another specific
> debug directive and shouldn't depend from NDEBUG. I think that many
> programmers leave NDEBUG undefined even on release builds, because it
> usually has little or no effect to performance that much.
Fair enough. How about BOOST_OPTIONAL_DEBUG?
> In this case a debug build it would not only be (marginally) slower,
> but will also take more memory. If you use for example big arrays of
> optionals it would be noticeable.
I'm not too concerned about this...
> But more importantly it would make a binary or library compiled with
> NDEBUG incompatible with one compiled without. While it is technically
> undefined behavior because it would lead to ODR violation,
> nevertheless, this is often done and on most systems it simply works.
... but this is a very good point! I don't want to break something that
currently works, even if it only works by accident.
> The best thing would probably be to use a different, optional
> specific, macro. If you really want to use NDEBUG, you could reuse the
> storage of the bool. Replace it with the pointer and use the pointer
> to store the "initialized/not initialized" state.
> This might still be wasteful on 64 bits architectures, but it is
> better than nothing.
Reusing the bool is an interesting idea, but I'm happy to use a different
precompiler macro. It does lead me to another question. An introduction
of a new macro will also require a change to the documentation. I know
how to submit a code patch, but how do you submit a doc patch?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk