Re: GDB to C++ issue: deletion

[Paul Hilfinger <hilfingr at EECS dot Berkeley dot EDU>]

> > 1. Ahem, which is precisely why I used a new subject, so as not to 
> >    incorporate an incidental side discussion into the same thread!
> 
> Sorry.  You replied to the same thread; most current Unix mailers
> will thread such replies together regardless of subject.  I didn't
> even notice.

How "helpful" of them.  Sorry; I didn't edit my header stringently
enough.  My bad.

> > 2. On the other hand, if someone is going to claim the advantages of 
> >    not having to do delete as an advantage, it is not entirely 
> >    unreasonable to make sure it really works out that way in practice.
> 
> IMO that applies to short lived variables, not the sort of things that
> get obstacked at all.

Actually, I had already concluded that short-lived variables would NOT
be a great problem.  To a first approximation, the effect of using STL's
storage management is to increase allocation costs by some constant
factor, because deallocation cost for an object tends to be limited by
some constant times its allocation cost.  As long as GDB's allocation
costs are not huge (and the constant factors are not huge), we
shouldn't have much pain.  

But that's just an overall argument about total execution time.
Common sources of short-lived variables (say during parsing and
(sub)expression evaluation) don't produce that many variables between
prompts (usually).  What I was more interested in was the possibility
of noticeably large changes in pause times for expensive operations
(such as re-reading a symbol table) on large executables.  I can think
of approaches, certainly, but have no actual experience with how well
they integrate with STL classes in practice.

Paul