Re: [boost] [optional] Making optional more debugger friendly

From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2007-05-22 21:42:50

On 5/22/07, Jeffrey Faust <jefffaust_at_[hidden]> wrote:
>
> That's a technique I use, but it's intrusive.  I use boost::optional like
> a value type.  I'd like it to be as transparent to the debugger as the
> type it wraps.  My coworkers have also expressed this issue when I started
> using boost::optional in our code.
>
> Is there anybody out there besides me that would find this useful?  If
> not, I'm happy to drop it.  I can always implement it locally for our own
> use.

I'm interested in non-intrusive means, of which neither of your
proposals really satisfy.  Modifying your own code to store the value
and watching that variable in the debugger is just a workaround for
the debugger's deficiency.  I think all of the previous points raised
by Giovanni about modifying the Boost code and imposing yet another
macro are valid, and it is a better but still undesirable solution.

There have been a few threads specific to debugging Boost libraries in
Visual Studio (3 to be exact, links below) which would be of interest
to me if implemented on a larger and more complete scale.  Modifying
autoexp.dat to allow Boost classes to be visualized is non-intrusive
and ideal IMHO, although, one could still argue it's just a workaround
for a deficient debugger  ;)

Here are the thread references:
http://thread.gmane.org/gmane.comp.lib.boost.user/26536
http://thread.gmane.org/gmane.comp.lib.boost.user/18665/focus=18684
http://thread.gmane.org/gmane.comp.lib.boost.user/20464/focus=20483

Are there non-intrusive solutions like the above for other debuggers?
I realize it's yet another bit of maintenance, but being able to
properly visualize all of Boost in all or most popular debuggers would
be very cool.

--Michael Fawcett