Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk