From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11329 invoked by alias); 13 Sep 2003 08:58:45 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11217 invoked from network); 13 Sep 2003 08:58:42 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 13 Sep 2003 08:58:42 -0000 Received: by nile.gnat.com (Postfix, from userid 1345) id 42D2FF2D71; Sat, 13 Sep 2003 04:58:42 -0400 (EDT) From: Paul Hilfinger To: ac131313@redhat.com Cc: gdb-patches@sources.redhat.com In-reply-to: <3F60C50F.5040704@redhat.com> (message from Andrew Cagney on Thu, 11 Sep 2003 14:55:11 -0400) Subject: Re: RFA: Changes to allow extensions to operator set References: <20030901093941.0D2E9F2A64@nile.gnat.com> <3F58B874.7020904@redhat.com> <20030906111343.5F98DF2B63@nile.gnat.com> <3F60C50F.5040704@redhat.com> Message-Id: <20030913085842.42D2FF2D71@nile.gnat.com> Date: Sat, 13 Sep 2003 08:58:00 -0000 X-SW-Source: 2003-09/txt/msg00284.txt.bz2 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