468,463 Members | 2,018 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,463 developers. It's quick & easy.

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
Dec 15 '07 #1
12 21751
Hi,

I don't see a

using namespace std;

in your code?

Regards, Ron AF Greve

http://www.InformationSuperHighway.eu

"Fab" <fa*************@free.frwrote in message
news:d2**********************************@n20g2000 hsh.googlegroups.com...
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

Dec 15 '07 #2
Fab wrote:
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.
Dec 15 '07 #3
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...

--
Ian Collins.
Dec 15 '07 #4
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

"Ron AF Greve" <ron@localhostwrote in message
news:47***********************@news.xs4all.nl...
Hi,

I don't see a

using namespace std;

in your code?

Regards, Ron AF Greve

http://www.InformationSuperHighway.eu

"Fab" <fa*************@free.frwrote in message
news:d2**********************************@n20g2000 hsh.googlegroups.com...
> 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


Dec 15 '07 #5
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
Dec 15 '07 #6
Fab wrote:
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.

--
Ian Collins.
Dec 15 '07 #7
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.

--
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)'

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
Dec 16 '07 #8
Fab wrote:
>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)'
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.

--
Ian Collins.
Dec 16 '07 #9
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.

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

Thanks,

Regards

Fabrice
Dec 16 '07 #10
On Dec 16, 5:47 am, Fab <fabricemarch...@free.frwrote:
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.
--
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)'

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).
Dec 16 '07 #11
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
Dec 16 '07 #12
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
Dec 16 '07 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

18 posts views Thread by Rhino | last post: by
2 posts views Thread by Jeffrey Melloy | last post: by
6 posts views Thread by massic80 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.