On Mon, Jul 11, 2005 at 09:18:22PM -0400, Daniel Jacobowitz wrote:
> Thanks for the explanation. That makes more sense. Personally, if
> you're going to do this, I don't see why you're keeping debug info for
> methods; either ditch all artificial methods (including defaulted
> constructors but not manually specified constructors), or ditch all
> methods.
We considered that too.
On the question of artifical-vs-actual c/dtors, that's one breakdown
I don't have hard numbers on yet, but my argument is that gdb's
knowledge of a class' cdtors is only useful when you're ptype'ing
that class -- you rarely find yourself needing to call the constructor
or destructor on an object from the gdb CLI. And these things are
awfully long in stabs. So this is the kind of minor functionality
that the user can be told "turn this switch on and ptype of the
class won't be accurate" and they'll understand the trade-off.
As for ditching methods, this quickly turns into a loss of functionality
because users can no longer call methods on on object from the gdb
command line. Many users don't know about inferior function calls,
but the Apple debugger UI exposes a feature that sits on top of
those ("custom data formatters"), where you can specify how objects
of a given type should be displayed in the variables window. For
complex OO types, these are often expressions involving an inferior
function call.
Jason
