Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Siva Chandra <sivachandra@google.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] Extend existing support for evaluating expressions using overloaded operators
Date: Fri, 08 Jun 2012 17:41:00 -0000	[thread overview]
Message-ID: <871ulpem66.fsf@fleche.redhat.com> (raw)
In-Reply-To: <CAGyQ6gxz-feRLk8S8mafVGFjiXxb=fF1Eg63jUkdtgLFjN4TUg@mail.gmail.com>	(Siva Chandra's message of "Wed, 6 Jun 2012 00:03:39 +0530")

>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:

Siva> If we want to extend the operator overloading support into Python,
Siva> then we will have to have code to decide whether to call value_binop
Siva> or value_x_binop in the py-value.c. Another client of these two
Siva> functions is evaluate_subexp_standard, which also has code to decide
Siva> whether to call value_binop or value_x_binop. Though I did not mention
Siva> in my post, my intention is avoid such repetitive code and get all
Siva> clients to depend only on value_binop and treat value_x_binop as
Siva> 'internal'.

I think you should start with this cleanup, then.
After the current patch it seems to me that the code would be inconsistent.

I think this idea is ok in the abstract but you have to be sure to audit
all the existing uses to make sure it does the right thing.  (I don't
anticipate a problem here, but still...)

Siva> I would like to follow this patch with another patch to do
Siva> this change. Note that, only evaluate_subexp_standard calls
Siva> value_x_binop currently. Hence, replacing these calls with value_binop
Siva> should not be much work (though I have not yet come up with a way to
Siva> deal with the 'noside' argument of value_x_binop).

Letting that leak out of eval.c seems like a flaw.

Tom> It would be nice if the test suite tested this case as well.

Siva> I agree, I will add more tests after we finalize this patch.

Siva> +      TRY_CATCH (except, RETURN_MASK_ERROR)
Siva> +        {
Siva> +          /* Retrieve the list of methods with the name NAME.  */
Siva> +          fns_ptr = value_find_oload_method_list (&temp, name,
Siva> +                                           0, &num_fns,
Siva> +                                                  &basetype, &boffset);
Siva> +        }
Siva> +      if (except.reason < 0)
Siva> +        fns_ptr = NULL;

Tom> I'll have to go read this in more depth; but I wonder why it is ok to
Tom> ignore exceptions here.

Siva> An exception is thrown if we are trying to lookup methods of a
Siva> non-struct and non-union type. One can ask that, in such cases, why
Siva> call value_find_oload_method_list at all. My argument is, if
Siva> value_find_oload_method_list is doing the check, why should we repeat
Siva> before calling it.

Throwing and catching an exception is much more expensive, and less
clear, than just checking the type.

Tom


  reply	other threads:[~2012-06-08 17:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-01 19:52 Siva Chandra
2012-06-04 20:53 ` Tom Tromey
2012-06-05 18:34   ` Siva Chandra
2012-06-08 17:41     ` Tom Tromey [this message]
2012-06-08 19:18       ` Siva Chandra
2012-06-18  7:30         ` Siva Chandra

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=871ulpem66.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sivachandra@google.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