By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,946 Members | 712 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,946 IT Pros & Developers. It's quick & easy.

compilation error related to template parameter

P: n/a
Consider the following program:

#include <iostream>
#include <string>
#include <vector>

using namespace std;

template<class Tclass Vec : public vector<T>
{
public:
Vec() : vector<T>() { }

Vec(int s) : vector<T>(s) { }

T& operator[] (int i) { return at(i); }
};

int main()
{
Vec<strings(3);

return 0;
}

Suppose this program is named as y.cpp

When this program is compiled under Redhat Enterprise Linux
Workstation, as
g++ -std=c++98 -pedantic -Wall -Wextra y.cpp

I am getting the following compilation error:

y.cpp: In member function `T& Vec<T>::operator[](int)':
y.cpp:14: error: there are no arguments to `at' that depend on a
template parameter, so a declaration of `at' must be available

However under VC++ Express Edition 2005, it compiles well without any
warning or error.

Kindly explain what is wrong with the above program and help me in
fixing the compilation error with g++ under Linux

Aug 14 '07 #1
Share this Question
Share on Google+
9 Replies


P: n/a
su**************@yahoo.com, India wrote:
Consider the following program:

#include <iostream>
#include <string>
#include <vector>

using namespace std;

template<class Tclass Vec : public vector<T>
generally not a good idea. vector is not intended for inheritance.
{
public:
Vec() : vector<T>() { }

Vec(int s) : vector<T>(s) { }

T& operator[] (int i) { return at(i); }
T& operator[](int i) { return this->at(i); }
};

int main()
{
Vec<strings(3);

return 0;
}
y.cpp: In member function `T& Vec<T>::operator[](int)':
y.cpp:14: error: there are no arguments to `at' that depend on a
template parameter, so a declaration of `at' must be available

See FAQ 35.19:
http://www.parashift.com/c++-faq-lit...html#faq-35.19
Aug 14 '07 #2

P: n/a
red floyd wrote:
su**************@yahoo.com, India wrote:
>Consider the following program:

#include <iostream>
#include <string>
#include <vector>

using namespace std;

template<class Tclass Vec : public vector<T>
generally not a good idea. vector is not intended for inheritance.
Tell me this is not another - "need virtual destructor so you can't
inherit" - argument. If it is, you will find it's not a position of
consensus.
>
>{
public:
Vec() : vector<T>() { }

Vec(int s) : vector<T>(s) { }

T& operator[] (int i) { return at(i); }

T& operator[](int i) { return this->at(i); }
>};

int main()
{
Vec<strings(3);

return 0;
}
y.cpp: In member function `T& Vec<T>::operator[](int)':
y.cpp:14: error: there are no arguments to `at' that depend on a
template parameter, so a declaration of `at' must be available


See FAQ 35.19:
http://www.parashift.com/c++-faq-lit...html#faq-35.19
Aug 14 '07 #3

P: n/a
On Aug 14, 11:02 am, "subramanian10...@yahoo.com, India"
<subramanian10...@yahoo.comwrote:
Consider the following program:

#include <iostream>
#include <string>
#include <vector>

using namespace std;

template<class Tclass Vec : public vector<T>
{
public:
Vec() : vector<T>() { }

Vec(int s) : vector<T>(s) { }

T& operator[] (int i) { return at(i); }

};

int main()
{
Vec<strings(3);

return 0;

}

Suppose this program is named as y.cpp

When this program is compiled under Redhat Enterprise Linux
Workstation, as
g++ -std=c++98 -pedantic -Wall -Wextra y.cpp

I am getting the following compilation error:

y.cpp: In member function `T& Vec<T>::operator[](int)':
y.cpp:14: error: there are no arguments to `at' that depend on a
template parameter, so a declaration of `at' must be available

However under VC++ Express Edition 2005, it compiles well without any
warning or error.

Kindly explain what is wrong with the above program and help me in
fixing the compilation error with g++ under Linux
Hi,
you can try following one:
rather than using return at(i) use the following one:
return vector<T>::at(i)

Aug 14 '07 #4

P: n/a
su**************@yahoo.com wrote:
Consider the following program:

#include <iostream>
#include <string>
#include <vector>

using namespace std;

template<class Tclass Vec : public vector<T>
{
public:
Vec() : vector<T>() { }

Vec(int s) : vector<T>(s) { }

T& operator[] (int i) { return at(i); }
};

int main()
{
Vec<strings(3);

return 0;
}

Suppose this program is named as y.cpp

When this program is compiled under Redhat Enterprise Linux
Workstation, as
g++ -std=c++98 -pedantic -Wall -Wextra y.cpp

I am getting the following compilation error:

y.cpp: In member function `T& Vec<T>::operator[](int)':
y.cpp:14: error: there are no arguments to `at' that depend on a
template parameter, so a declaration of `at' must be available

However under VC++ Express Edition 2005, it compiles well without any
warning or error.

Kindly explain what is wrong with the above program and help me in
fixing the compilation error with g++ under Linux
My newsserver is slow today, so I may be replying to something that
has already been discussed, sorry for that.

In your case 'at' is a dependent name. You need to help the compiler
to find it by pointing it to the member function. There are two ways
to do that, a 'using' declaration and an explicit qualification of
the name. So, either do

template<class Tclass Vec : public vector<T>
{
using vector<T>::at;
public:
Vec() : vector<T>() { }

Vec(int s) : vector<T>(s) { }

T& operator[] (int i) { return at(i); }
};

or
template<class Tclass Vec : public vector<T>
{
using vector<T>::at;
public:
Vec() : vector<T>() { }

Vec(int s) : vector<T>(s) { }

T& operator[] (int i) { return this->at(i); }
// or
// T& operator[] (int i) { return vector<T>->at(i); }
};

Next time read the FAQ first.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Aug 14 '07 #5

P: n/a
On Aug 14, 8:22 am, Gianni Mariani <gi3nos...@mariani.wswrote:
red floyd wrote:
subramanian10...@yahoo.com, India wrote:
Consider the following program:
#include <iostream>
#include <string>
#include <vector>
using namespace std;
template<class Tclass Vec : public vector<T>
generally not a good idea. vector is not intended for inheritance.
Tell me this is not another - "need virtual destructor so you can't
inherit" - argument. If it is, you will find it's not a position of
consensus.
It's probably more simply a case of "using a class in ways it
was not designed for doesn't work". A fact of life. (But there
are always amateur hackers who try to ignore it.)

--
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, +33 (0)1 30 23 00 34

Aug 14 '07 #6

P: n/a
James Kanze wrote:
On Aug 14, 8:22 am, Gianni Mariani <gi3nos...@mariani.wswrote:
>red floyd wrote:
>>subramanian10...@yahoo.com, India wrote:
Consider the following program:
>>>#include <iostream>
#include <string>
#include <vector>
>>>using namespace std;
>>>template<class Tclass Vec : public vector<T>
generally not a good idea. vector is not intended for inheritance.
>Tell me this is not another - "need virtual destructor so you can't
inherit" - argument. If it is, you will find it's not a position of
consensus.

It's probably more simply a case of "using a class in ways it
was not designed for doesn't work". A fact of life. (But there
are always amateur hackers who try to ignore it.)
It's probably another attempt to impose a style (coding or design)
ridden with undue limitations. Condescending tone does make one
look/sound important, no doubt.

Search the archives for "standard containers are not intended to be
derived from" and make your own conclusions, that's what I say.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Aug 14 '07 #7

P: n/a
Alf P. Steinbach wrote:
::
:: For the compiler needs to be informed -- somehow -- that "at" is
:: meant to be assumed to be a member function of vector<T>. Because
:: whether it is or not depends on T, which is unknown during the
:: first pass through the template definition. For example, "at"
:: could be a global function.
::
:: <speculation>
:: I always find the explanation I gave above to be lacking, but it
:: is the one usually offered. It's a bit lacking because before
:: two-phase template instantiation was standardized, compilers
:: managed code such as above very well thank you, as evidently
:: Visual C++ still does, without needing to be informed about
:: anything. A more Real(TM) reason why it matters could be that
:: "export" needs a context-independent template definition (that
:: could also help explain why "export" is so unpopular, only
:: officially supported by Comeau). </speculation>
::

It doesn't really work, it just pretends. Note that the OP used
"-std=c++98 -pedantic" with g++. That is definitely not the default
setting for VC++.

As you certainly know, in "compatibility mode" VC++ will pick whatever
it finds at instantiation time, a vector<mytype>::at() or some other
visible at() function, or just fail if none is present. I think this
is an ODR violation in disguise.

Isn't it better to fix the problem up front with the original
template, and not wait for the third case (or debug case two for a
month)?
Bo Persson
Aug 14 '07 #8

P: n/a

Victor Bazarov <v.********@comAcast.netwrote in message...
>
My newsserver is slow today,
I've noticed that too. I wonder if it has anything to do with dictator
bush's plan to monitor everything going into/out_of the U.S.A.. (that seems
to be about when it started.)

--
Bob R
POVrookie
Aug 14 '07 #9

P: n/a
BobR wrote:
Victor Bazarov <v.********@comAcast.netwrote in message...
>>
My newsserver is slow today,

I've noticed that too. I wonder if it has anything to do with dictator
bush's plan to monitor everything going into/out_of the U.S.A.. (that
seems to be about when it started.)
<shrug Then I'd see slowness on other sources as well, and I didn't.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Aug 16 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.