[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