This is the mail archive of the gdb-patches@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: [drow@mvista.com: Re: RFA: LOC_COMPUTED support]


On Fri, Feb 21, 2003 at 12:12:41PM -0500, Andrew Cagney wrote:
> 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.

I don't think I agree with you on this, but if you want to change it by
all means post a patch for some concrete discussion :)  This is another
point when I am willing to sacrifice a certain amount of clarity to not
carry around an extra set of method pointers; there are a _large_
number of these batons.

I'd rather discuss a transition to C++ than any particular instance of
this problem.  Do you think it's feasible?

-- 
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]