[LC++]Why new behaviour of g++?

[Dr Mark H Phillips]

Thanks everyone for your feedback.  And thanks Torsten
for your explanation about why this behaviour is necessary.

Cheers,

Mark.

On Wed, 2005-02-23 at 00:24, Torsten Rennett wrote:
[snip]
> > But why does g++ now outlaw this?  
> 
> Suppose you have the following slightly modified code:
> 
>     template<typename T> struct SixStore 
>     {
>       int store;
>       SixStore() : store(6) {}
>     };
> 
>     template<typename T> struct Six : public SixStore<T>
>     {
>       void setStore(int val) { store = val; }	// point (1)
>     };
> 
>     template<>              // explicit specialization
>     struct SixStore<bool>
>     {
>       enum { store = 1 };			// point (2)
>     };
> 
>     int main()
>     {
>       Six<bool> s;
>       s.setStore(100);				// point (3)
>     }
> 
> 
> If the nondependent name ('store') would be looked up at point (1), it
> would be bind to the int member of class SixStore.  After this we
> declare an explicit specialization of class SixStore for the type bool,
> which unfortunately changes the meaning of 'store' (point 2) -- 'store'
> is no longer modifiable!  Finally we create an instance of Six<bool> at
> point (3). At this point the explicit specialization is known and causes
> a conflict, since we have bound 'store' too early at point (1).
> 
> To solve this conflict, the C++ Standard says that nondependent names
> are *not* looked up in dependent base classes.  So a standard conforming
> C++ compiler has to emit an error at point (1) -- and this is what gcc
> does :-)
> 
> If we modify the code like shown above (1st + 2nd solution), the binding
> will be delayed.  The dependent name can be looked up only at the time
> of instantiation and at that time the exact base specialization will be
> known -- and 'store' will bind correctly to the enum 'store' in class
> SixStore<bool>.  This time the compiler will emit an error at point (3),
> since setStore() can not modify an enum!
> 
> HTH,
> Torsten