From: Jeffrey Faust (jefffaust_at_[hidden])
Date: 2007-05-22 23:24:38
Michael Fawcett wrote:
> On 5/22/07, Jeffrey Faust <jefffaust_at_[hidden]> wrote:
>
> 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.
I suppose you could argue that a debugger should be able to look at any
address as any type you pick. The aligned memory construct is certainly a
difficult case.
True, it is an intrusive patch, but that's not what I meant. An intrusive
change into library code is not noticed by the user. My goal was to
provide a benefit to what I see is a weakness in the library, at very
little cost.
> 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 ;)
Thanks for the links. I'll definitely use the ptr container additions.
Still, I've tried to find a solution for boost::optional some time ago and
failed. The link that mentions it is for only int64, and not a general
solution. I'll try to tackle the problem again with autoexp.dat.
However, I've failed previously, and don't expect better results this time
around.
Jeff Faust