[PATCH][C++] Fix PR29433, make C++ use a lot less time/memory

Michael Matz matz@suse.de
Wed Dec 13 18:30:00 GMT 2006


Hi,

On Wed, 13 Dec 2006, Mark Mitchell wrote:

> For big C++ programs, no amount of eliding default arguments is going to 
> get you nice compact type names.

It really depends.  For instance STL (and may others) are full of 
many default arguments in the various classes, which aren't really 
intersting most of the time, e.g. std::string (here the reduction to the 
typedef'd name would already be enough, but also non-printing of default 
args would help).

> That's why C++ programs are full of 
> "typedef typename X::Y Z" stuff.  I think that what you really want to 
> ...
> The key point, echoing what you and Daniel have been saying, is that you
> need to be able to leverage the typedefs the programmer already has.

Yes.

> Breakpoints are easier than printing the types of things, since you can 
> accept multiple names for the same function as breakpoints, but when 
> printing a type who have to pick one way of printing it.  No 
> type-printing heuristic is ever going to be perfect.

Sure, but some are betters than others in most cases :)

> > debugger who looks at the current DW_AT_name for them).  Ask Richard 
> > about debugging tramp3D with gdb.  It's basically a joke.
> 
> We know a fair amount about debugging big C++ programs.  Remember who
> lead POOMA development for several years? :-)

He :)

> Nobody is arguing that DW_AT_name should be the huge string for the long 
> term.  However, I would argue that it should stay that huge string until 
> we add the template arguments to debug info, and until GDB understands 
> that information.

Hmm.  Okay, let's agree to disagree then :)

> I would consider dropping default arguments.  But, mangled names are not 
> in the spirit of DWARF, and dropping the template argument information 
> completely is taking away critical information.

Okay, I can agree to this though.  Dropping default args would already be 
nice.


Ciao,
Michael.



More information about the Gcc-patches mailing list