[Bug c++/21008] [3.4/4.0/4.1 Regression] Acess failure in accessing data member of base class from derived template class

["sebor at roguewave dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From sebor at roguewave dot com  2005-04-19 15:41 -------
Here's a followup email from Mike with some calarifying comments:

Mike Miller wrote:
> Martin Sebor wrote:
> 
>> Thanks a lot for the detailed analysis! I wonder if your reasoning
>> would be the same given a slightly different test case (one that's
>> closer to the original in comment #1):
>>
>>>
>>>     struct A {
>>
>>
>>       protected:     // <<< ADDED <<<
>>
>>>       int foo_;
>>>     };
>>>     template <typename T> struct B: public A { };
>>>     template <typename T> struct C: B<T> {
>>>       int foo() {
>>>         return A::foo_;  // #1
>>>       }
>>>     };
> 
> 
> No, I don't think that changes things.  Again, the situation is the 
> same: whether A is the global class or the injected-class-name doesn't 
> affect whether C<int> (or whatever) has access to A::foo_.  (There are 
> cases where it does matter, but this isn't one of them.  Those typically 
> involve private or protected inheritance, where the access from 
> "outside" is greater than the inherited access.)
> 
> The general principle is that non-dependent names are looked up and 
> bound in the definition context (14.6.3), but that's really the only 
> semantic effect.  In cases like this one, it's as if "A" were replaced 
> by "::A".  If the result of using "::A" is well-formed, then the version 
> with just "A" is, too.
> 
>> But if an implementation is permitted to diagnose access violations
>> at definition time wouldn't the gcc compilation error be justified?
> 
> 
> I think the general rule is that you should only issue a diagnostic if 
> you can tell that no well-formed instantiation is possible (14.6p7).  In 
> these cases, at least some specializations will have well-formed 
> instantiations, so no diagnostic is permitted.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008