From: Siva Chandra <sivachandra@google.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] Extend existing support for evaluating expressions using overloaded operators
Date: Tue, 05 Jun 2012 18:34:00 -0000 [thread overview]
Message-ID: <CAGyQ6gxz-feRLk8S8mafVGFjiXxb=fF1Eg63jUkdtgLFjN4TUg@mail.gmail.com> (raw)
In-Reply-To: <87aa0in6ii.fsf@fleche.redhat.com>
Siva> * valarith.c (value_binop): Extend to handle overloaded
Siva> binary operations on compound types.
Tom> I don't understand why value_binop must be modified.
Tom> I think in the current design it is up to the caller to check this.
Tom> (I don't necessarily think this is a good design -- but changing it
Tom> would require more changes elsewhere.)
If we want to extend the operator overloading support into Python,
then we will have to have code to decide whether to call value_binop
or value_x_binop in the py-value.c. Another client of these two
functions is evaluate_subexp_standard, which also has code to decide
whether to call value_binop or value_x_binop. Though I did not mention
in my post, my intention is avoid such repetitive code and get all
clients to depend only on value_binop and treat value_x_binop as
'internal'. I would like to follow this patch with another patch to do
this change. Note that, only evaluate_subexp_standard calls
value_x_binop currently. Hence, replacing these calls with value_binop
should not be much work (though I have not yet come up with a way to
deal with the 'noside' argument of value_x_binop).
Siva> +int
Siva> +is_compound_type (struct type *type)
Siva> +{
Siva> + enum type_code type_code;
Siva> +
Siva> + CHECK_TYPEDEF (type);
Siva> +
Siva> + type_code = TYPE_CODE (type);
Siva> + if (type_code == TYPE_CODE_STRUCT || type_code == TYPE_CODE_UNION)
Tom> It seems to me that there is other code which assumes that only
Tom> TYPE_CODE_STRUCT can be overloaded. At least binop_types_user_defined_p,
Tom> but maybe others. Those spots should be updated.
Actually, AFAICT binop_types_user_defined_p has a copy-paste typo due
to which it is currently wrong. Even otherwise, with the change I have
in mind this function can go away I think.
Tom> It would be nice if the test suite tested this case as well.
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.
An exception is thrown if we are trying to lookup methods of a
non-struct and non-union type. One can ask that, in such cases, why
call value_find_oload_method_list at all. My argument is, if
value_find_oload_method_list is doing the check, why should we repeat
before calling it.
Thanks,
Siva Chandra
next prev parent reply other threads:[~2012-06-05 18:34 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 [this message]
2012-06-08 17:41 ` Tom Tromey
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='CAGyQ6gxz-feRLk8S8mafVGFjiXxb=fF1Eg63jUkdtgLFjN4TUg@mail.gmail.com' \
--to=sivachandra@google.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@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