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
next prev parent 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