This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [drow@mvista.com: Re: RFA: LOC_COMPUTED support]
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Jim Blandy <jimb at redhat dot com>, Elena Zannoni <ezannoni at redhat dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>,gdb-patches at sources dot redhat dot com
- Date: Fri, 21 Feb 2003 12:12:41 -0500
- Subject: Re: [drow@mvista.com: Re: RFA: LOC_COMPUTED support]
- References: <20030213211157.GA13537@nevyn.them.org> <vt21y22pndn.fsf@zenia.red-bean.com> <20030221152420.GA32260@nevyn.them.org>
Just a generic heads up on the structure of this code and these, er,
batons (from the point of view of the architecture).
This is implementing something like (I've not hacked C++ in > 10 years):
// some base classes
class A;
class B;
// a derived class (wonder if I got the order right).
class B::class B1;
// A `uses' B but is parameterized with the specific instance
class A->method (class B B);
in C.
I honestly think that using baton's distract from what is a simple O-O
construct and standard O-O terminology.
The frame and architecture code both reflect this structure - pass in
the object and then use methods supplied as part of the object.
Once all this is settled, I think I'll look to re-factor (hmm, buzword)
the code so that its structure better refects what is going on.
enjoy,
Andrew