|
Boost : |
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2007-05-22 16:38:18
On 5/22/07, Jeffrey Faust <jefffaust_at_[hidden]> wrote:
> My only complaint about boost::optional is that it is very difficult to
> see values in the debugger. I brought this up in a discussion at
> BoostCon, and Jeff Garland suggested I submit a patch.
>
> Well, I have a patch. The change introduces a new private T* m_value and
> protected method update_debug() which sets this variable. The variable is
> only visible when building debug, and the method is empty in non-debug.
> From there, I simply call update_debug() in each public method that
> changes the storage.
>
> The final result is that debuggers can see the variable data by looking at
> opt.m_value. When not set, the value is null.
>
> Any thoughts?
>
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.
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.
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.
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.
gpd
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk