This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
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