struct environment

[Andrew Cagney]

> On Tue, Sep 17, 2002 at 03:37:58PM -0400, Andrew Cagney wrote:
> 
>> 
> 
>> >>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.
> 
>> 
>> By efficiency did you mean speed or memory?  I don't see speed being an 
>> issue (except for the global table), just memory (GDB's foot print growing).
> 
> 
> Either.  It's quite a hard problem, which is a reason why C++ compilers
> generally use Koenig lookup through multiple blocks rather than growing
> blocks.  And there's all sorts of other correctness issues.

{I'd better find out what a koenig lookup is.  I think I just tried to 
described one :-)

The correctness of course does need to come before the efficience.  So I 
guess (to back out) if the choice is between burning memory and having 
GDB print a correct value and being memory efficient but wrong, then the 
first is the correct choice.

Andrew


>> >  Remember that C
>> > uses D in turn, and that things "using"'d into D will therefore be
>> > visible in C.
> 
>> 
>> True, but I'm not the one implementing this.  I'm just trying to 
>> understand the core-gdb interface.
>> 
>> Andrew
>> 
>> 
>> 
> 
> 
> -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer