[C++ Patch] PR 53301
Paolo Carlini
paolo.carlini@oracle.com
Fri May 11 08:19:00 GMT 2012
Hi,
On 05/11/2012 06:41 AM, Jason Merrill wrote:
> On 05/10/2012 05:31 PM, Paolo Carlini wrote:
>> Let's see if we can do something *now* ;) My concrete proposal would be:
>>
>> TYPE_PTRMEM_P rename to TYPE_PTRDATAMEM_P (consistent with
>> TYPE_PTRMEMFUNC_P)
>> TYPE_PTR_TO_MEMBER_P rename to TYPE_PTRMEM_P
>>
>> and then finally
>>
>> #define TYPE_PTR_OR_PTRMEM_P(NODE) \
>> (TYPE_PTR_P (NODE) || TYPE_PTRMEM_P (NODE))
>>
>> and use it everywhere. Sounds like an improvement?
>
> Sounds pretty good. But I suspect a lot of places want to check
> TYPE_PTR_P || TYPE_PTRDATAMEM_P (because you can't just use TREE_TYPE
> to get the function type of a PMF), so this new macro doesn't help
> with your desire to avoid writing ||.
Well, I wanted to avoid writing it somewhere *else* ;) But, if we want,
we could add a new predicate for your case too, maybe in a following
step. What do you think?
>> Additionally, we could maybe rename PTRMEM_OK_P to PTRMEMFUNC_OK_P
> No, that flag applies to both varieties of members.
I see. Then while we are at it we could probably tweak a bit a the
comment, I find it a tad misleading:
/* Indicates when overload resolution may resolve to a pointer to
member function. [expr.unary.op]/3 */
???
Thanks,
Paolo.
More information about the Gcc-patches
mailing list