improving debugging experience ;)
Andreas Pakulat
apaku at gmx.de
Fri Dec 9 00:47:02 UTC 2005
On 08.12.05 22:58:42, Christian Parpart wrote:
> While in debugging mode, you're able to hover a symbol and get it's
> data dump, just like an item in the "Variables View", however,
> it is comprehensivily splitted up into a tree-alike popup stacked down
> to just where your hover the next symbol within this popup.
>
> While this is quite handy, there still is another thing I'm missing.
Do you mean that this is in kdevelop already? Didn't see it yet, but
maybe just missed it :-)
> In C#/.NET each and every little object has a common base class even called
> object, having a virtual function called toString() making it possible,
> that the debugger is able to use this function to pretty print the
> output of a variable's object::ToString() instead of the raw data.
I wanted to comment on that, but then I saw you know already....
> Of course, in C++ you simply have no really common base class, in fact, we're
> having several frameworks and each and everyone calls is base class
> different, not to mention: TObject/QObject/CObject/Object/....
Right, C++ is not Java (don't know C#/.NET) and thus no common base
class and no Metaclass for information about classes...
> So now my idea is that KDevelop would just examine the data structure of a
> variable. If it hits a certain base class FOO containing a certain function
> BAR, then this one gets invoked and its return value is used for the pretty
> display.
> FOO and BAR shall be (of course) configurable, only one BAR per FOO and
> multiple type of FOOs.
I'm not a debugger expert, but I think this is already done today and
you can do it yourself. For example for QString you get the string value
in the variable view if you include the gdb-macros from the kdesdk
package. I think the same is true for other Qt3 containers, like QMap
and QList, even though I'm currently not sure how they appear in the
variable view.
If you look at those macros you can see that there's no "magic"
happening, just some "interpretation" of the data in the "d" pointers of
the classes (like QString, QMap and so on).
> Is this even possible from a kdevelop/gdb technical point of view?
The question is: Who is skilled enough with gdb to write this for each
and every framework?
Andreas
--
You will forget that you ever knew me.
More information about the KDevelop-devel
mailing list