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: RFA: Changes to allow extensions to operator set


Andrew,

>> Not so.  The language vector already contains
>> 
>>     /* Evaluate an expression. */
>>     struct value *(*evaluate_exp) (struct type *, struct expression *,
>> 				   int *, enum noside);

>Ah.  Is ada doing anything special with that - something that will bite 
>later?  Looking at the existing languages - they appear to simply be 
>overriding select operators but nothing more.

Nope; it overrides some stuff, and (of course), handles the new operators 
it defines.

> It took me some time to understand why the OO style really was better 
> and how come Java omiting enum's was a good thing.

So I guess I don't have to ask how you feel about C# putting them back 
in (:->).

> Not if, when.  GDB's being re-done OO regardless of the C++ schedule.

Yes, and none too soon in general.  It's just that for this particular
application --- large sets of operator objects with a fairly small set
of virtual operations in the interface --- I've always found the gains
achieved by the OO formulation to be just a tad disappointing.  I find
moreover that to make things readably concise in C or C++, I generally
end up resorting to macros, a separate pre-processing step, or a
specialized implementation language for dealing with expression trees.
The GDB community appears to have an almost superstitious aversion to
macros which I've never entirely understood (probably because I
instinctively write only beautifully clear macro definitions myself
;->).  Pre-processing tends to confuse debuggers, and specialized
implementation languages are generally not widely implemented.


> Can you please move evaluate_exp to the new expresion descriptor (is 
> anything else missing?); modify:

Sure; sounds sensible.

> to provide a an explicit and finite number of extended operators 
> OP_EXTENDED_0, OP_EXTENDED_1, ... (I'm assuming Ada will contain enum { 
> OP_ADA_... = OP_EXTENDED_0, ... }); add a note that this is an interum 
> and it will go away.

OK.

Paul


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