This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] PR c++/26256


2010/6/9 Fabien ChÃne <fabien.chene@gmail.com>:
> 2010/6/8 Jason Merrill <jason@redhat.com>:
>> Hunh, I thought I had reviewed this already. ÂSorry for the delay.
>
> Do not apologize, you already did :-) I was working slowly on what you
> have suggested.
>
>>> I've tried a naive approach: basically, when a field
>>> decl is ambiguous, lookup_member (invoked with protect = 1) returns a
>>> TREE_LIST. So when we are in this case, I have implemented a lookup in
>>> the object scope, which try to disambiguate the field decl using
>>> 'using decl'. If the lookup succeeds, just return the selected field
>>> decl in the TREE_LIST.
>>
>> It seems like this only works if there is a using in the most derived class;
>> a using in an intermediate class wouldn't avoid the ambiguity.
>
> Yes, and I think the below code is illegal, don't you think so ?
>
> struct A { int next; };
> struct B { int next; };
> struct C : B { using B::next; };
>
> struct D : A, C
> {
> Â Â// using C::next;
> Â Âvoid f() { next = 1; }
> };

Ah, perhaps you mean that;

struct A { int next; };
struct B { int next; };
struct C : A, B { using B::next; };

struct D : C
{
    void f() { next = 1; }
};

I'll check.

-- 
Fabien


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]