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
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:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk