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