On Tue, 22 May 2007 13:38:18 -0700, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
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)?
That's correct.
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? Jeff Faust