On 5/22/07, Jeffrey Faust <jefffaust@verizon.net> 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