From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30624 invoked by alias); 6 Sep 2003 11:13: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 30611 invoked from network); 6 Sep 2003 11:13:43 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 6 Sep 2003 11:13:43 -0000 Received: by nile.gnat.com (Postfix, from userid 1345) id 5F98DF2B63; Sat, 6 Sep 2003 07:13:43 -0400 (EDT) From: Paul Hilfinger To: ac131313@redhat.com Cc: gdb-patches@sources.redhat.com In-reply-to: <3F58B874.7020904@redhat.com> (message from Andrew Cagney on Fri, 05 Sep 2003 12:23:16 -0400) Subject: Re: RFA: Changes to allow extensions to operator set References: <20030901093941.0D2E9F2A64@nile.gnat.com> <3F58B874.7020904@redhat.com> Message-Id: <20030906111343.5F98DF2B63@nile.gnat.com> Date: Sat, 06 Sep 2003 11:13:00 -0000 X-SW-Source: 2003-09/txt/msg00088.txt.bz2 > [Where] is a method to handle operator evaluation missing? Otherwize won't > the jumbo switch in evaluate_subexp_standard still need to be modified > as languages add additional operators. Not so. The language vector already contains /* Evaluate an expression. */ struct value *(*evaluate_exp) (struct type *, struct expression *, int *, enum noside); Let me make clear that we do have an existence proof that the changes I submitted suffice, since we have used them (in patches still to come) to extend the operator set with the extra Ada operators WITHOUT extensions to expression.h, expprint.c, etc. So if something is missing, it can't be all that much. > I was thinking more of > struct operator > { > const char *name; > void (*length) (struct expression *exp, struct operator *op, ?others?); > int (*eval) (...); > ... > }; > struct exp_descriptor > { > int num_oper; > const struct operator *op; // is **op easier? > ... In short, you want to object orient these suckers. Well as a matter of fact, I actually implemented something along these lines in an earlier iteration. It certainly can be made to work. However, 1. To do it consistently requires a much more extensive and somewhat tedious change to the existing machinery (which works well enough) giving me even more opportunities to overlook something ("overlook" == "screw up"). 2. For example, to really do it up brown you'd want to modify all the .y files so that instead of emitting the integer codes directly, as they do now, there'd be operator-specific emission routines for parsing, so that, e.g., sequences like write_exp_elt_opcode (OP_FUNCALL); write_exp_elt_longcst ((LONGEST) end_arglist ()); write_exp_elt_opcode (OP_FUNCALL); } became OP_FUNCALL->write_exp_longest ((LONGEST) end_arglist ()); or some such thing. 3. Personally, I find that this is one of those gray cases where the OOP style gains little in clarity. That is, we have choice of writing (A) an enumeration type and a few big functions of the form () { switch () { case A: case B: } } and of writing (B) LOTS of little functions of the form () { } plus a big dispatch vector (of struct operators, in your case) naming them. Perhaps I am overinterpreting your suggestion, but I see a lot of effort for little gain in clarity (maybe <0) in going from the current style (A) to style (B). In fact, for these reasons, I went so far as to tear up my original, more bject-oriented version of this extension mechanism and go back to the mechanism I submitted, as a simpler and more conservative solution. Now if and when David Carlton gets his way and we eventually re-do GDB in C++, it might be time to revisit this decision, since C++ would remove the tedious table building and welter of names. Paul