Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Paul Hilfinger <hilfingr@gnat.com>
To: ac131313@redhat.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: Changes to allow extensions to operator set
Date: Sat, 13 Sep 2003 08:58:00 -0000	[thread overview]
Message-ID: <20030913085842.42D2FF2D71@nile.gnat.com> (raw)
In-Reply-To: <3F60C50F.5040704@redhat.com> (message from Andrew Cagney on Thu, 11 Sep 2003 14:55:11 -0400)


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


  reply	other threads:[~2003-09-13  8:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-01  9:39 Paul Hilfinger
2003-09-04  2:18 ` Andrew Cagney
2003-09-05  8:32   ` Paul Hilfinger
2003-09-05 15:57 ` Andrew Cagney
2003-09-05 16:23 ` Andrew Cagney
2003-09-06 11:13   ` Paul Hilfinger
2003-09-11 18:55     ` Andrew Cagney
2003-09-13  8:58       ` Paul Hilfinger [this message]
2003-09-18  9:20       ` Paul Hilfinger
2003-09-22 17:04         ` Andrew Cagney
2003-09-05 16:29 ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030913085842.42D2FF2D71@nile.gnat.com \
    --to=hilfingr@gnat.com \
    --cc=ac131313@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox