Earlier this week, after mentally tracing through my perception of the process that led to a type resulting from the instantiation of a somewhat complex C++ template,  it occurred to me that it might be useful (especially as people begin to produce ever more elaborate templates in D) to have some kind of interactive debugger for these compile-time objects.

I'm imagining something that allows me to browse through D source, select some template instantiation, and then step into it (as one would step into a function call).  In a separate window would be displayed various template parameters (and the types that have been assigned to them).  One would also be able to see the names of dependent types (analogous to instance variables) and their types (analogous to values). In this way, one would be able to see the type being built up from the template arguments and dependent types in a fashion analogous to that in which one can see the return value of a function being computed while stepping through it in a normal debugger.

It's just a thought I'm toying with, but I'm curious as to whether anyone else would expect to find that useful.  I suspect that it could help beginners to more rapidly solidify their understanding of templates.  Experimentation with a tool like that could also serve as an aid in designing template-related enhancements for a future version of the language.

My guess is that it might not be too hard to implement since most of the hard logic (i.e., the template instantiation logic) is already implemented in the compiler.  But then, I haven't looked at any of the compilers' internals yet, so I'm really just spouting conjecture atm. ;-)

Thoughts?

Walter? :-)

In article <james-7A325D.00183717062004@digitalmars.com>, James Widman says...
>
>
>I'm imagining something that allows me to browse through D source, select some template instantiation, and then step into it (as one would step into a function call).  In a separate window would be displayed various template parameters (and the types that have been assigned to them).  One would also be able to see the names of dependent types (analogous to instance variables) and their types (analogous to values). In this way, one would be able to see the type being built up from the template arguments and dependent types in a fashion analogous to that in which one can see the return value of a function being computed while stepping through it in a normal debugger.

I've mentioned this before, and it's one of those things that's really important to some of us, but totally irrelevant to others, so I don't know what kind of priority it has.

The story so far, though, is that the DMD compiler does not, currently, write enough accurate debugging information into the generated .obj file for interactive debuggers to work with templates. In fact - it's not juat templates for which debugging information is missing or inaccurate. Also missing are: member variables of this; member variables of structures; member variables of objects (actually, just member variables general).

There are plenty of existing IDEs around which could do the job, if only the information were correctly stored in the .obj file in the first place. I use VC++ myself, but sometimes it is a pain not being able to see member variables (although I can get around that with the memory view and knowledge of the layout of D objects) - but I can't get around the inability to step into templates. It's something that needs to be fixed (IMO). But I really don't know if anyone's giving this a sufficiently high priority.

In any case, I don't think that any of us non-Digital-Mars types can do about it, short of writing a second D compiler. I guess we just keep pointing out that we think it's important until someone with power agrees.

Jill

There's gdc which has a nicer ability to debug.
You can get at local vars and class vars...
even global vars if you mangle the name properly

The name gets pretty mangled in the debugger...you have to look 1/3 down the string to find the actual function name because the name space is pasted a good 2-3 times first.

I really hope that gdc (gcc's D compiler) revs their versions. They still have a few old bugs and no support for recent features.  The bugs include silent ?: failures and silent failures when casting from static sized arrays to dynamic arrays. They're stuck on the feature set of the earrly .80's as well.

--Daniel

Arcane Jill wrote:
> In article <james-7A325D.00183717062004@digitalmars.com>, James Widman says...
> 
>>
>>I'm imagining something that allows me to browse through D source, select some template instantiation, and then step into it (as one would step into a function call).  In a separate window would be displayed various template parameters (and the types that have been assigned to them).  One would also be able to see the names of dependent types (analogous to instance variables) and their types (analogous to values).  In this way, one would be able to see the type being built up from the template arguments and dependent types in a fashion analogous to that in which one can see the return value of a function being computed while stepping through it in a normal debugger. 
> 
> 
> I've mentioned this before, and it's one of those things that's really important
> to some of us, but totally irrelevant to others, so I don't know what kind of
> priority it has.
> 
> The story so far, though, is that the DMD compiler does not, currently, write
> enough accurate debugging information into the generated .obj file for
> interactive debuggers to work with templates. In fact - it's not juat templates
> for which debugging information is missing or inaccurate. Also missing are:
> member variables of this; member variables of structures; member variables of
> objects (actually, just member variables general).
> 
> There are plenty of existing IDEs around which could do the job, if only the
> information were correctly stored in the .obj file in the first place. I use
> VC++ myself, but sometimes it is a pain not being able to see member variables
> (although I can get around that with the memory view and knowledge of the layout
> of D objects) - but I can't get around the inability to step into templates.
> It's something that needs to be fixed (IMO). But I really don't know if anyone's
> giving this a sufficiently high priority.
> 
> In any case, I don't think that any of us non-Digital-Mars types can do about
> it, short of writing a second D compiler. I guess we just keep pointing out that
> we think it's important until someone with power agrees.
> 
> Jill
> 
>