This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: struct environment


On Wed, Sep 18, 2002 at 12:51:46AM -0400, Daniel Berlin wrote:
> 
> On Tuesday, September 17, 2002, at 04:34  PM, Daniel Jacobowitz wrote:
> 
> >On Tue, Sep 17, 2002 at 03:52:33PM -0400, Daniel Berlin wrote:
> >>
> >>On Tuesday, September 17, 2002, at 02:02  PM, Daniel Jacobowitz wrote:
> >>
> >>>On Tue, Sep 17, 2002 at 01:54:07PM -0400, Andrew Cagney wrote:
> >>>>>Well, sort of.  It won't be a DAG necessarily (I think that mutual
> >>>>>>>"using" statements are legal in C++; I remember a GCC bug 
> >>>>>>>involving
> >>>>>>>them was fixed not long ago), and it will be somewhat complicated
> >>>>>>>figuring out which ones to look up (namespace links are different
> >>>>>>>than
> >>>>>>>block scope links).
> >>>>>
> >>>>>>
> >>>>>>Don't forget that GDB doesn't need to model the language.  Just 
> >>>>>>the
> >>>>>>namespace behavior at a given PC.  The effect of "using" would be 
> >>>>>>to
> >>>>>>just grow a nametab in someway.
> >>>>>
> >>>>>
> >>>>>This is legal C++:
> >>>>>
> >>>>>namespace D {}
> >>>>>
> >>>>>namespace C {
> >>>>>using namespace D;
> >>>>>int x, y;
> >>>>>}
> >>>>>
> >>>>>namespace D {
> >>>>>using namespace C;
> >>>>>int x, z;
> >>>>>}
> >>>>>
> >>>>>If using just grew a nametab we'd get into a great deal of trouble.
> >>>>
> >>>>Depends on how you grow it :-)  Something like (assuming a real
> >>>>language
> >>>>:-):
> >>>>	D:
> >>>>	0: x, z
> >>>>	1: x, y (from C)
> >>>>	2: ...
> >>>
> >>>How you intend to do this efficiently I don't know.  Remember that C
> >>>uses D in turn, and that things "using"'d into D will therefore be
> >>>visible in C.
> >>
> >>These types of problems are exactly why i said a lot of thought needs
> >>to be put into the design of the underlying structures, rather than
> >>just copying what we have because we have it.
> >>It's hard to call it "overengineered" if how to do lookups efficiently
> >>with large numbers of names in namespaces hasn't been considered.
> >>It's not really something you can bolt on later.
> >>Hasn't this been proven by the fact that it hasn't been bolted on yet?
> >
> >Absolutely.  But I've always thought that we'd still do it via
> >searching a succession of blocks, with some sort of global structure
> >for figuring out where to look; which means that at this point it's
> >been designed far enough.  I could be wrong :)
> 
> This might be the case.
> I'm just trying to make sure it *has* been considered.
> I'm not saying it actually requires any changes to the proposed way of 
> doing things.
> 
> In legal terms, i'm raising the objection to preserve it for a possible 
> later appeal.
> :)

Well then - it has been considered.  I'm not sure it's been considered
_enough_, but only time is going to answer that.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]