error: expected nested-name-specifier

[Fab]

Hi,

I try to compile a 2 years old project (successfully compiled with g++
3.3, if I correctly remember ).

But get problems now with g++ -> gcc 4.2.3 :

#include <list>
#include <hash_map>

template<class>
class ListPtr;

template<class T>
class ListPtrIterator {

public:
ListPtrIterator( ListPtr< T >* _user ):
M_user( _user ),
M_cur( M_user->begin() ) {}

bool
cur( T*& );

bool
reset( void ) {
M_cur =M_user->begin();
return M_cur!=M_user->end();
}

private:
ListPtr< T >* M_user;
typename list< T* >::iterator M_cur;
^^^^
ERROR: expected nested-name-specifier before 'list'
};

Please do you know what's the problem ?
Has something changed in "typename" syntax ?

Thanks,

Fabrice

 

[Ron AF Greve]

Hi,

I don't see a

using namespace std;

in your code?

Regards, Ron AF Greve

http://www.InformationSuperHighway.eu

 

[Ian Collins]

Hi,

I try to compile a 2 years old project (successfully compiled with g++
3.3, if I correctly remember ).

But get problems now with g++ -> gcc 4.2.3 :

typename list< T* >::iterator M_cur;
^^^^
ERROR: expected nested-name-specifier before 'list'
};

Should be std::list

Old gcc versions accepted standard containers in the global namespace.

 

[Ian Collins]

Ron AF Greve wrote:

[please don't top post]

Hi,

I don't see a

using namespace std;
in your code?

Nor should you, if this is from a header...

 

[Ron AF Greve]

BTW.

hash_map is a sgi extension AFAIK. I believe it is now located somewhere
else (then again you might have used a -I ext switch of course).



Regards, Ron AF Greve

http://www.InformationSuperHighway.eu

 

[Fab]

Thanks a lot for the explanations !

Yes, std:: perfectly solves the issue.

Thanks to have spoken about the changing of behaviour of gcc : the
makefile compiled before.
However I'm not surprised to run into problems in trying to build
this old project : because there were ugly things to be able to make
different gcc cope with SGI extensions.

Best regards,

Fabrice

 

[Ian Collins]

Thanks a lot for the explanations !

Yes, std:: perfectly solves the issue.

Thanks to have spoken about the changing of behaviour of gcc : the
makefile compiled before.
However I'm not surprised to run into problems in trying to build
this old project : because there were ugly things to be able to make
different gcc cope with SGI extensions.

You will often find ugly things to get different gcc versions to cope
with other gcc versions!

Make sure you invoke the compiler in its standard conforming mode, to
save yourself problems in the future.

 

[Fab]

You will often find ugly things to get different gcc versions to cope

with other gcc versions!

Make sure you invoke the compiler in its standard conforming mode, to
save yourself problems in the future.

Thanks for the advice !

Now that all sources successfully compiles with gcc 4.2.3., I get lot
of linker errors that complains about dozens of undefined references
to stl internals.
Here is the first one :

cvtChar.o: In function `escape(char)':
cvtChar.c++.text+0x53c): undefined reference to
`stlpmtx_std::__node_alloc::_M_deallocate(void*, unsigned int)'

I add a -llibstlport to the Makefile libraries but dunno : remains
stuck.
I'm absolutely sure that the last time I built this project nothing
additional was required for the link.

Then I tried to build a stl-manual example : same kind of linker
error.
I've not used C++ for about one year but remember not to have such
kind of problems with old compiler versions.

Please do you have an idea about how to make the libstlport be found
at link stage ?
The packages :
libstlport4.6c2
libstlport5.1
libstlport5.1-dev
are installed on this Debian Sid.
Maybe is there a problem about different runtime libraries ?

Regards,

Fabrice

 

[Ian Collins]

Thanks for the advice !

Now that all sources successfully compiles with gcc 4.2.3., I get lot
of linker errors that complains about dozens of undefined references
to stl internals.
Here is the first one :

cvtChar.o: In function `escape(char)':
cvtChar.c++.text+0x53c): undefined reference to
`stlpmtx_std::__node_alloc::_M_deallocate(void*, unsigned int)'

You have stayed into the realms of gcc or Linux specific problems I'm
afraid. You should be able to get help from a Linux of gcc group.

 

[Fab]

You have stayed into the realms of gcc or Linux specific problems I'm

afraid. You should be able to get help from a Linux of gcc group.

You probably are right, will ask the question in a Linux forum.

Thanks,

Regards

Fabrice

 

[Abhishek Padmanabh]

Thanks for the advice !

Now that all sources successfully compiles with gcc 4.2.3., I get lot
of linker errors that complains about dozens of undefined references
to stl internals.
Here is the first one :

cvtChar.o: In function `escape(char)':
cvtChar.c++.text+0x53c): undefined reference to
`stlpmtx_std::__node_alloc::_M_deallocate(void*, unsigned int)'

I add a -llibstlport to the Makefile libraries but dunno : remains
stuck.
I'm absolutely sure that the last time I built this project nothing
additional was required for the link.

Then I tried to build a stl-manual example : same kind of linker
error.
I've not used C++ for about one year but remember not to have such
kind of problems with old compiler versions.

Please do you have an idea about how to make the libstlport be found
at link stage ?
The packages :
libstlport4.6c2
libstlport5.1
libstlport5.1-dev
are installed on this Debian Sid.
Maybe is there a problem about different runtime libraries ?

Regards,

Fabrice

Try out ldd command to find out if you are linking to the correct
library. -llibstlport might not just be sufficient in that you would
need to tell the LIB_PATH,LD_LIBRARY_PATH (whatever your compiler
understands) as well about where the library is (not just the
includes).

 

[Fab]

Thanks !

Try out ldd command to find out if you are linking to the correct
library.

I however thought ldd was only able to list the needed libraries for
an existing executable ? It's unfortunately not yet the case.

-llibstlport might not just be sufficient in that you would
need to tell the LIB_PATH,LD_LIBRARY_PATH (whatever your compiler
understands) as well about where the library is (not just the
includes).

About this you are certainly right. I perform some trials.

Regards,

Fabrice

 

[Fab]

Leaved stlport5.1 and went back to 4.6..
Things ended to successfully build.
The link stage :
g++ -O3 -I /usr/include/stlport -lreadline -o k /usr/lib/
libstlport_gcc.so cvtChar.o readline.o input.o Form.o Overload.o
read.o eval.o print.o banner.o repl.o keywords.o

Were specifying stl lib this way, like a ".o" /usr/lib/
libstlport_gcc.so is absolutely ugly.
I don't worry about this : I just needed to build the executable and
maybe to add small changes on it to print some internals. This just to
understand how it works.

Regards,

Fabrice