Is it me or is it gcc?

[Boltar]

hi

I've come across a wierd template related error with gcc 3.4.6 on
linux. It doesn't occur with 3.3.3 or 4.2.1 so I'm wondering if its a
compiler bug or the compiler is just being extra pedantic (however
using -fpermissive makes no difference).

The error is:

$ c++ t.cc
t.cc: In member function `void n2<T>::test()':
t.cc:15: error: `wibble' was not declared in this scope
$

the code is:
template <typename T>
class n1
{
public:
int wibble;
};
template<typename T>
class n2: public n1<T>
{
public:
void test()
{
wibble = 1;
}
};
int main()
{
n2<intn;
return 0;
}
It can be fixed by changing wibble=1 to this->wibble=1 but clearly
doing this in a large program for every single inherited base class
variable and function is not practical.

Anyone come across this before and know the solution or do we just
need to dump this version of gcc?

Thanks for any help

B2003

[Boltar]

On Sep 12, 12:24 pm, Michael DOUBEZ <[e-mail]:

Look up template-dependant name:http://www.parashift.com/c++-faq-lit...html#faq-35.19

Thats just retarded. What idiot thought that up? Why would I want
"this->" in front of every inherited variable and class, I might just
as well code in C!

I thought 4.2.1 would throw an error.

Perhaps the guys at GNU realise what a PITA this is and removed the
check.

B2003

[James Kanze]

On Sep 12, 2:22 pm, Boltar <[e-mail]:

On Sep 12, 12:24 pm, Michael DOUBEZ <[e-mail]:

Look up template-dependant
name:http://www.parashift.com/c++-faq-lit...html#faq-35.19

Thats just retarded. What idiot thought that up? Why would I
want "this->" in front of every inherited variable and class,
I might just as well code in C!

The problem is just the opposite. Suppose you have something
like:

extern int wibble ;
template< typename T >
class U : public T
{
public:
int f() { return wibble ; }
} ;

Now what happens if T contains a member wibble? (That's the
official reason---I'm not saying I agree with it.)

It has nothing to do with base classes or inheritance. It has
to do with whether the expression depends on the template
arguments or not. Without reason to do otherwise, "wibble",
used alone, doesn't depend on the template arguments, so is
looked up (and bound) immediately. Putting this-in front of
it makes it depend on the template arguments (if there is a base
class which depends on the template arguments), so name lookup
and binding is deferred to instantiation time.

I thought 4.2.1 would throw an error.

Perhaps the guys at GNU realise what a PITA this is and
removed the check.

I don't think so, but who knows.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Boltar]

On Sep 12, 2:14 pm, James Kanze <[e-mail]:

On Sep 12, 2:22 pm, Boltar <[e-mail]:

On Sep 12, 12:24 pm, Michael DOUBEZ <[e-mail]:

Look up template-dependant
name:http://www.parashift.com/c++-faq-lit...html#faq-35.19

Thats just retarded. What idiot thought that up? Why would I
want "this->" in front of every inherited variable and class,
I might just as well code in C!

The problem is just the opposite. Suppose you have something
like:

extern int wibble ;
template< typename T >
class U : public T
{
public:
int f() { return wibble ; }
} ;

Now what happens if T contains a member wibble? (That's the
official reason---I'm not saying I agree with it.)

But in that example you're inheriting from a template type so yes, I
can see the problem there. In my example however I was inheriting from
one of my own classes that happened to take template definition
parameters. Its not the same thing.

If the template in my example had a member variable "wibble" it
wouldn't make any difference since its obvious from the code I'm
trying to access the member variable from my own class , not that of
any variables created with the template type because in that case I'd
have to do [template type var].wibble=1

B2003

[blargg]

In article
<f6**********************************@m73g2000hsh. googlegroups.com>,
Boltar <bo********@yahoo.co.ukwrote:

On Sep 12, 2:14 pm, James Kanze <[e-mail]:

On Sep 12, 2:22 pm, Boltar <[e-mail]:
[...]Suppose you have something like:

extern int wibble ;
template< typename T >
class U : public T
{
public:
int f() { return wibble ; }
} ;

Now what happens if T contains a member wibble? (That's the
official reason---I'm not saying I agree with it.)

But in that example you're inheriting from a template type so yes, I
can see the problem there. In my example however I was inheriting from
one of my own classes that happened to take template definition
parameters. Its not the same thing.

How so? In both cases below the compiler doesn't know anything about the
type derived from, since Foo could have specializations:

template<typename Tclass U : public T;

template<typename Tclass Foo { ... };
template<typename Tclass U : public Foo<T>;

If the template in my example had a member variable "wibble" it
wouldn't make any difference since its obvious from the code I'm
trying to access the member variable from my own class , not that of
any variables created with the template type because in that case I'd
have to do [template type var].wibble=1

I'd rather a compiler which followed well-defined rules rather than vague
things like "obvious", which differ from one person to the next. For one,
the compiler sees a lot more than the human does, in terms of all the
details.

[Boltar]

On Sep 12, 3:25 pm, [e-mail] (blargg) wrote:

How so? In both cases below the compiler doesn't know anything about the
type derived from, since Foo could have specializations:

template<typename Tclass U : public T;

template<typename Tclass Foo { ... };
template<typename Tclass U : public Foo<T>;

It doesn't in my example. For heavens sake , is it too much to ask a
compiler to know when specialisation is in use and when it isn't in
the same module for the same class?

I'd rather a compiler which followed well-defined rules rather than vague
things like "obvious", which differ from one person to the next. For one,
the compiler sees a lot more than the human does, in terms of all the
details.

Rubbish. These rules make it virtually impossible to use inheritence
with templates. Which rather defeats the point of using C++. As I said
earlier , I might as well use C. I'm pretty sure the compiler writers
have understood this which is why 4.2.1 doesn't error and just
compiles the code.

B2003

[Bernd Strieder]

Hello,

Boltar wrote:

On Sep 12, 3:25 pm, [e-mail] (blargg) wrote:

>How so? In both cases below the compiler doesn't know anything about
the type derived from, since Foo could have specializations:

template<typename Tclass U : public T;

template<typename Tclass Foo { ... };
template<typename Tclass U : public Foo<T>;

It doesn't in my example. For heavens sake , is it too much to ask a
compiler to know when specialisation is in use and when it isn't in
the same module for the same class?

A compiler cannot sensibly work in a way that it makes assumptions which
might be broken later on. If it took the wibble in your example as you
like it, somebody else could change your example by adding a
specialization for the base class and bring the compiler into trouble.

Older releases of gcc basically did some kind of textual insertion with
the macros at instantiation time, so all lookups happened at the point
that is now the second phase of lookup. The problem with that is, that
you basically could not have fixed meanings for names when the code is
parsed first time by the compiler, fixed in the sense that no later
specialization can change it. The first phase of name lookup for
templates ensures that this is possible.

>

>I'd rather a compiler which followed well-defined rules rather than
vague things like "obvious", which differ from one person to the
next. For one, the compiler sees a lot more than the human does, in
terms of all the details.

Rubbish. These rules make it virtually impossible to use inheritence
with templates. Which rather defeats the point of using C++. As I said
earlier , I might as well use C. I'm pretty sure the compiler writers
have understood this which is why 4.2.1 doesn't error and just
compiles the code.

Then gcc 4.3 has reverted 4.2.1 again. 4.2.2 seems to have serious
problems with your example modified a little, it compiles the
following:

template <typename T>
class n1
{
public:
int wibble;
};
template<typename T>
class n2: public n1<T>
{
public:
void test()
{
this->wibble = 1;
//::wibble = 1; global variable
// wibble = 1; //this->wibble or ::wibble ?
// max(3,4)
/* this->max or std::max (with using namespace std) */
}
};

template<>
class n1<int>
{
public:
int wobble;
// int max(int,int);
};

int main()
{
n2<intn;
n.test();
return 0;
}

Imagine you have something named wibble in the same namespace as n2. How
would you distinguish between that wibble and the wibble of class
template n1? Especially how would you do that at the point you are
parsing the body of your method test(), without making speculations? If
the compiler sees the wibble alone and took it as an argument-dependent
name, then suddenly all non-related names used within templates would
have to be fully qualified to distinguish them, think about the
max-example above. That would be quite a lot more work in non-trivial
templates than having to add this-to make something
argument-dependent.

Bernd Strieder

[Andrey Tarasevich]

Boltar wrote:

On Sep 12, 3:25 pm, [e-mail] (blargg) wrote:

>How so? In both cases below the compiler doesn't know anything about the
type derived from, since Foo could have specializations:

template<typename Tclass U : public T;

template<typename Tclass Foo { ... };
template<typename Tclass U : public Foo<T>;

It doesn't in my example. For heavens sake , is it too much to ask a
compiler to know when specialisation is in use and when it isn't in
the same module for the same class?

It is not a matter of whether it is "too much to ask " or not. It is a
matter of common sense. Having the semantics of _unqualified_ names to
be implicitly dependent on the template context would deal a huge amount
of damage to the readability of the code. It would be downright
dangerous. For these reasons C++ is pretty consistent in this regard:
the user has to explicitly acknowledge the "dependentness" of a name in
cases like that.

>I'd rather a compiler which followed well-defined rules rather than vague
things like "obvious", which differ from one person to the next. For one,
the compiler sees a lot more than the human does, in terms of all the
details.

Rubbish. These rules make it virtually impossible to use inheritence
with templates. Which rather defeats the point of using C++.

No, quite the opposite. These rules are what keeps inheritance useful
with templates.

--
Best regards,
Andrey Tarasevich

[Boltar]

On 12 Sep, 18:09, Bernd Strieder <[e-mail]>
wrote:

A compiler cannot sensibly work in a way that it makes assumptions which
might be broken later on. If it took the wibble in your example as you
like it, somebody else could change your example by adding a
specialization for the base class and bring the compiler into trouble.

But the point is that there is no specialisation in that example. You
could use the same argument to say that ALL class member variables
must be qualified with their class name in case two or more classes
have variables with the same name. That clearly is crazy , just as
having to use "this->" in the above sort of template classes IMO.

B2003

[Boltar]

On 12 Sep, 16:45, "Alf P. Steinbach" <[e-mail]:

in the context of the 'main' above n2::test would refer to n1::wibble, while in
the context

template<class n1<char{};

struct MakeMyDay
{
void operator=( int ) { std::cout << "Dang!" << std::endl; }
} wibble;

void foo() { n2<charn; n.test(); }

n2::test would refer to the global wibble, and cause an output operation.

But in that example just make the compiler give a duplicate
declaration or unknown scope error when it spots 2 objects/vars with
the same name. If there is only one variable in the whole program
called "wibble" why should it need to be qualified with "this->" ?

B2003

[Andrey Tarasevich]

Boltar wrote:

On 12 Sep, 18:09, Bernd Strieder <[e-mail]>
wrote:

>A compiler cannot sensibly work in a way that it makes assumptions which
might be broken later on. If it took the wibble in your example as you
like it, somebody else could change your example by adding a
specialization for the base class and bring the compiler into trouble.

But the point is that there is no specialisation in that example. You
could use the same argument to say that ALL class member variables
must be qualified with their class name in case two or more classes
have variables with the same name. That clearly is crazy , just as
having to use "this->" in the above sort of template classes IMO.

How does two or more classes having variables with the same names could
lead to any ambiguity of the nature similar to the one in your original
example? Care to elaborate?

--
Best regards,
Andrey Tarasevich

[Andrey Tarasevich]

Boltar wrote:

But in that example just make the compiler give a duplicate
declaration or unknown scope error when it spots 2 objects/vars with
the same name. If there is only one variable in the whole program
called "wibble" why should it need to be qualified with "this->" ?

Whole program? What "whole program"? C++ compiler doesn't see the "whole
program". Neither it is supposed to. The principle of independent
translation of translation units still remains one of the foundation
stones of C++ language.

In your previous posts you referred to a "module", instead of the "whole
program". That made more sense, assuming that by "module" you mean
"translation unit". It is indeed possible to analyze the entire
translation unit and come to the conclusion that your unqualified
'wibble' actually refers to the inherited 'wibble'. But that opens the
door to a rather hideous and unwelcome consequences, when the meaning if
the code at one point in the translation unit changes, depending on the
code located further down in the translation unit. While it is true,
that such change might occur in C++ in some other situations, the case
with an unqualified variable name is not one of them. And it shouldn't
be one of them, unless you want to turn the relevant C++ code into a
hopelessly obfuscated mess.

--
Best regards,
Andrey Tarasevich

[James Kanze]

On Sep 12, 3:30 pm, Boltar <[e-mail]:

On Sep 12, 2:14 pm, James Kanze <[e-mail]:

On Sep 12, 2:22 pm, Boltar <[e-mail]:

On Sep 12, 12:24 pm, Michael DOUBEZ <[e-mail]:
Look up template-dependant
name:http://www.parashift.com/c++-faq-lit...html#faq-35.19
Thats just retarded. What idiot thought that up? Why would
I want "this->" in front of every inherited variable and
class, I might just as well code in C!

The problem is just the opposite. Suppose you have something
like:

extern int wibble ;
template< typename T >
class U : public T
{
public:
int f() { return wibble ; }
} ;

Now what happens if T contains a member wibble? (That's the
official reason---I'm not saying I agree with it.)

But in that example you're inheriting from a template type so
yes, I can see the problem there. In my example however I was
inheriting from one of my own classes that happened to take
template definition parameters. Its not the same thing.

Yes it is. The type of your base class depends on the argument
of the template.

If the template in my example had a member variable "wibble"
it wouldn't make any difference since its obvious from the
code I'm trying to access the member variable from my own
class, not that of any variables created with the template
type because in that case I'd have to do [template type
var].wibble=1

In your example, you inherited from a template, not a class.
The compiler cannot know the contents of this template until it
knows what the template argument will be, and it won't know that
until you instantiate the second template. (Think about
explicit specializations, for example.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Sep 12, 7:37 pm, Boltar <[e-mail]:

On 12 Sep, 18:09, Bernd Strieder <[e-mail]>
wrote:

A compiler cannot sensibly work in a way that it makes
assumptions which might be broken later on. If it took the
wibble in your example as you like it, somebody else could
change your example by adding a specialization for the base
class and bring the compiler into trouble.

But the point is that there is no specialisation in that example.

But the point is that the compiler has no way of knowing that,
since the specialization is not required to be visible until the
template is actually instantiated.

You could use the same argument to say that ALL class member
variables must be qualified with their class name in case two
or more classes have variables with the same name.

No. A class is a class; it has only one definition. You
derived from template, which only becomes a class when
instantiated. And there are an infinite number of possible
instantiations.

That clearly is crazy , just as having to use "this->" in the
above sort of template classes IMO.

IMHO, it's not the ideal solution, but it certainly isn't crazy,
and it certainly doesn't make deriving from a dependent base
impossible.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Sep 12, 7:25 pm, Andrey Tarasevich <[e-mail]>
wrote:

Boltar wrote:

On Sep 12, 3:25 pm, [e-mail] (blargg) wrote:

How so? In both cases below the compiler doesn't know
anything about the type derived from, since Foo could have
specializations:

template<typename Tclass U : public T;

template<typename Tclass Foo { ... };
template<typename Tclass U : public Foo<T>;

It doesn't in my example. For heavens sake , is it too much
to ask a compiler to know when specialisation is in use and
when it isn't in the same module for the same class?

It is not a matter of whether it is "too much to ask " or not.
It is a matter of common sense. Having the semantics of
_unqualified_ names to be implicitly dependent on the template
context would deal a huge amount of damage to the readability
of the code. It would be downright dangerous.

Don't exagerate. Template implementations existed for a long
time without dependent look-up, and there weren't any real
problems in practice. (Of course, existing "best practice" even
then said to always fully qualify such names anyway, using
::whatever or this->whatever to ensure that regardless of the
instantiation context, you got the symbol you wanted.)

For these reasons C++ is pretty consistent in this regard: the
user has to explicitly acknowledge the "dependentness" of a
name in cases like that.

IMHO, that's where there is a real problem. The user doesn't
explicitly state what is dependent or not; the compiler
"guesses" according to a fixed set of heuristics, and the user
has to then trick the compiler into guessing what he wants it to
guess. IMHO, 1) dependent names are a solution to something
that isn't a real problem in practice, and 2) if the distinction
is deemed desirable (because it does offer some protection),
then the user should state clearly which names are dependent,
and not have to second guess the heuristics the compiler uses
for guessing.

I'd rather a compiler which followed well-defined rules
rather than vague things like "obvious", which differ from
one person to the next. For one, the compiler sees a lot
more than the human does, in terms of all the details.

Rubbish. These rules make it virtually impossible to use
inheritence with templates. Which rather defeats the point
of using C++.

No, quite the opposite. These rules are what keeps inheritance
useful with templates.

Come now, inheritance was useful long before the rules were
adopted.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Sep 12, 5:45 pm, "Alf P. Steinbach" <[e-mail]:

* Boltar:

[...]

It can be fixed by changing wibble=1 to this->wibble=1 but
clearly doing this in a large program for every single
inherited base class variable and function is not practical.

Another and more practical solution is to add

using n1<T>::wibble;

in class n2.

Which isn't too bad.

But for a type you'd have to do something like

typedef typename n1<T>::SomeType SomeType;

which IMHO is bad.

It's really annoying, and verbose, and redundant, and silly.

Most of all, it's not orthogonal.

Have you thought of proposing to the committee that using work
also for types (in this context)? It's a bit late now, but I
suspect that it would have been viewed favorably earlier.

Anyone come across this before and know the solution or do
we just need to dump this version of gcc?

As others have remarked, it's a (language) feature, not a
bug... ;-)

As I understand it the rationale is that the definition of
class n2 should *mean the same* in every context it's used --
which might bring some conceptual clarity, might prevent bugs,
and might help with implementation of 'export' as well as a
compiler's use of some intermediate representation of the
template.

The rationale I heard was that it was to prevent name hijacking.
In his case, for example, if he'd wanted wibble to refer to a
global variable, a base class (or a specialization of the
template he used as a base class) which defined it would
"hijack" the name. By making it non-dependent, we ensure that
this cannot happen.

For example, if not for this rule, *or some other
disambiguation rule*, then in the context of the 'main' above
n2::test would refer to n1::wibble, while in the context

template<class n1<char{};

struct MakeMyDay
{
void operator=( int ) { std::cout << "Dang!" << std::endl; }
} wibble;

void foo() { n2<charn; n.test(); }

n2::test would refer to the global wibble, and cause an output
operation.

Exactly. Except that the problem is more likely in the opposite
sense: he wanted some global, but picked up a name defined in
the base class.

And IMNO, you make a very good point with *or some other
disambiguation rule*. The actual rules for determining when a
symbol is dependent or not are fairly complex.

Thus, without this rule, *or some other disambiguation rule*,
the definition of class n2 would be very brittle, easily
"broken" simply by client code defining some global.

Earlier compilers didn't implement two phase look up, and we
didn't have problems with templates with them. And hey, this is
C++ anyway. Despite namespaces, dependent and non-dependent
names, and all the rest, the code is still "brittle", and will
be broken by the first unfortunate #define that comes along.
(That's why we have export.)

Personally I would rather have had the rule that in class
templates, use of global names would have to be qualified,
that all references were implicitly to class members unless
otherwise indicated.

That would certainly be simpler and easier to understand than
the current rules. But how is it to work with overloaded
operators and ADL?

I think that would have broken even more code than the
introduction of two-phase lookup did (history: template lookup
rules were changed at standardization). But I think, if code
was going to be broken anyway, it would have made sense to
care more about future than about past.

One could argue that such code was already broken, since it
allowed name hijacking. The best established practice in the
early days with templates was to fully qualify all names, to be
sure of getting the one you wanted (modulo macros, of course).

Disclaimer: I haven't really thought deep about the
qualify-globals-rule. Perhaps there's something that means it
wouldn't work.

Well, the way namespace works more or less makes ADL necessary,
and having to fully qualify a name turns that off.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Juha Nieminen]

Boltar wrote:

Rubbish. These rules make it virtually impossible to use inheritence
with templates. Which rather defeats the point of using C++.

Wait a minute: You have to write "this->" in front of base class
member variable names in your derived class, and this makes it
IMPOSSIBLE to use inheritance with templates?

Are you nuts?

What next? If you want to access the member function of an object, you
have to write "objectName." or "objectName->" in front of that function
name, which makes it impossible to use objects in C++? If you want to
call a function, you have to write "(" before the function parameters
and ")" after them, and this makes it impossible to call functions in
C++? If you want to write a C++ program you have to write "int main("
somewhere, so this makes it impossible to write C++ programs.

Let me guess: You also always write a "using namespace" line in all
your source files to get rid of those pesky namespaces. After all, if
that was not possible, you would have to write "std::" in front of every
standard library name, which would make it IMPOSSIBLE to write any C++.
Lucky they added the "using namespace" trick, or else no programs could
be written.