Hello, the new support of two-stage name-lookup for templates in gcc 3.4.0 for C++ brings a problem that I don't know how to resolve. I would like to know what is your recommended way of dealing with the following. Here is some code that used to compile and link on gcc 3.3 (sorry to copy some code but that's key to understanding the problem) /////// // A.h /////// class B; class A { public: A(){} ~A(){} template <class T> int f( T t ) { B b; return ( b.getInt() + t ); } int getInt() const { return 1; } }; ////// //B.h ////// class A; class B { public: B(){} ~B(){} template <class T> int g( T t ) { A a; return ( a.getInt() + t ); } int getInt() const { return 2; } }; /////////// //Main.cpp /////////// #include "A.h" #include "B.h" int main( void ) { A a; int i = 1; a.f( i ); B b; b.g( i ); } As you can see in A.h, the template method f() uses B and in B.h, the template method g() uses A. As these methods were only compiled at instantiation time (with gcc 3.3) the fact that A uses B and B uses A was not a problem but if I compile the same code with gcc 3.4 I have: > gcc -v Reading specs from /var/gnu/3.4.0/lib/gcc/sparc-sun-solaris2.8/3.4.0/specs Configured with: ../gcc-3.4.0/configure --prefix=/var/gnu/3.4.0 --disable-nls --enable-languages=c,c++ Thread model: posix gcc version 3.4.0 > gcc -c -save-temps Main.cpp In file included from Main.cpp:1: A.h: In member function `int A::f(T)': A.h:13: error: invalid use of undefined type `struct B' A.h:1: error: forward declaration of `struct B' This is normal as with 3.4, B needs to be known at definition time in A.h as it is not dependent on a template parameter. But obvioulsy, if I change my code so that A.h includes B.h, and B.h includes B.h, I have a cyclic dependency and it won't compile. The next step in order to remove such a dependency is usually to get the method code out of the header file and put it in the cpp file. But of course, this is a template method and the only method I know to do this with templates is to use the keyword export... that you don't support. This last point is fair enough as lots of compilers don't support it but I would like to know what is you recommended solution to fix this problem?
Created attachment 8204 [details] source code and *.ii files
The easy way to fix this is to make the template function not be in the class definition. Anyways if you read a good C++ book, this would be explained there.
I am sorry but that is not good enough. If I read correcly, you recommend that to solve the problem with my template function member of a class is ... not to use template functions as members of the class. My example was indeed simple and you could get the template out of the class but if I alter slightly B.h, you can see why I want g() to be a member of the class. I can obviouly come up with solutions where I don't use member template functions or even where I don't use templates at all but what I want to know is how you are supposed to deal with this problem at hand. What is the recommended way, with gcc 3.4, to deal with template methods and circular dependencies? Again, when I read a good C++ book, the solution is to use the export keyword but GCC does not support it. /////// // B.h /////// class A; class B { public: B(){} ~B(){} template <class T> int g( T t ) { A * a = GetA(); return ( a->getInt() + t ); } int getInt() const { return 2; } private: A * GetA(); };
Maybe it is not very clear to you, but this is the GCC Bugzilla. This is where people report *bugs* of the GCC compiler. It is not a help desk for C++ programmers. If you have a BUG to report about GCC, we're eager to know. If you do not know how to write your program so that it follows all the ISO C++ rules, we really cannot help. Try asking in a newsgroup like comp.lang.c++.moderated. Anyway, the solution for your problem is very easy, you just need to define your member functions outside the class definition.
Fair enough, you can indeed resolve the circular dependencies by moving the definition but you still have more dependencies between files than you used to with 3.3. It's all good to follow the standard but implementing the two phase lookup without implementing the export keyword makes it difficult to minimize the dependencies. Anyway, thanks for your "help"