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