Re: Templates, inheritance and variable visibility
On Apr 4, 3:20 am, Ian Collins <ian-n...@hotmail.com> wrote:
Jeff Schwab wrote:
Ian Collins wrote:
Alf P. Steinbach wrote:
Exactly why that rule was chosen instead of the for C++98
more reasonable of having to qualify use of enclosing
scope names is a mystery.
How would you qualify a name as "from the enclosing scope?"
Within the current language, I think you'd have to hard-code
the entire sequence of namespaces for each identifier, from
global scope on down. If you so much as wrote std::cout,
the compiler would get confused, since it would have to
assume std was defined in the base class.
To you and me both. Although James has cited some corner
cases where it does make sense, I'm still not convinced.
It leads to some pretty ugly and unnecessarily verbose
code.
At the time the derived class is defined, the base class
hasn't necessarily been seen yet. There is no way for the
compiler (or the human reader) to know whether the base
defines a_, no matter what the base class's primary template
defines. The enclosing scope, OTOH, is already available.
Then how comes older compilers and those that choose not to
use two phase lookup mange?
Everything is know at the point of instantiation.
The argument is twofold: the first is that waiting until the
point of instantiation to fully evaluate the template results in
delayed error messages. I think that the actual argument is
that the error messages won't necessarily appear until the
template is used by the client. (IMHO, this is just bullshit.
If you release a template without having tested it, tough shit.
And if you've tested it, you've instantiated it, and seen any
error messages resulting from the instantiation.) The second
argument is that in some cases, the template will pick up
symbols that weren't intended. Something like:
template< typename T >
class C : public T
{
void f( double d1 ) { double d2 = sin( d1 ) ; }
} ;
The template author obviously wants the global sin, but what if
T contains a member function sin. All I can say to this is that
I've not found this to be a problem in actual code, and that
since the introduction of namespaces, that would be std::sin,
anyway, which obviously won't be found in T.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34