[Bug c++/14317] New: Template functions linking problem

[Bug c++/14317] New: Template functions linking problem

[linux4sin at mail dot ru]

template.cc:
#include "templ.h"
#include <iostream>
#include <set>

int main(){
        std::set<int> set;
        set.insert(2);
        set.insert(4);
        std::cout << set;
}

templ.h:
#ifndef _TEMPL_H
#define _TEMPL_H

#include <iostream>
#include <set>

template<class T> std::ostream& operator<<(std::ostream& os, std::set<T>& s);

#endif /* _TEMPL_H */

templ.cc:
#include "templ.h"

template<class T> std::ostream& operator<<(std::ostream& os, std::set<T>& s){
        os << '{';
        typename std::set<T>::iterator i = s.begin();
        if(i != s.end()){
                os << *i++;
                while(i != s.end())
                        os << " ," << *i++;
        }
        os << '}' << std::endl;
        return os;
}

[sin@localhost gcc]$ g++ -o template template.cc templ.cc
/home/sin/tmp/ccwKtND2.o(.text+0x69): In function `main':
: undefined reference to `std::basic_ostream<char, std::char_traits<char> >&
operator<< <int>(std::basic_ostream<char, std::char_traits<char> >&,
std::set<int, std::less<int>, std::allocator<int> >&)'
collect2: ld returned 1 exit status

Reading specs from /usr/lib/gcc-lib/i586-alt-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib
--with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix --disable-checking --enable-long-long
--enable-__cxa_atexit --enable-languages=c,c++,f77,objc,treelang,java,ada
--program-suffix=-3.3 --enable-objc-gc --with-system-zlib
--without-included-gettext --host=i586-alt-linux --build=i586-alt-linux
--target=i586-alt-linux
Thread model: posix
gcc version 3.3.3 20040216 (ALT Linux, build 3.3.3-alt1)

Linux 2.6.1-sin26-up-alt5 i686 GNU/Linux

This problem come then template function and it call defined at different files.
Is it normal?

-- 
           Summary: Template functions linking problem
           Product: gcc
           Version: 3.3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: linux4sin at mail dot ru
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14317

[Bug c++/14317] Template functions linking problem

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-02-27 02:48 -------
No this is not a bug, C++ templates have been instainated so the source for the template have to be in 
the same source file.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14317

[Bug c++/14317] Template functions linking problem

[linux4sin at mail dot ru]

------- Additional Comments From linux4sin at mail dot ru  2004-02-27 07:24 -------
This is very strong restriction for common structures like templates.
Can I hope for elimination it in closest future?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14317

[Bug c++/14317] Template functions linking problem

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-02-27 12:38 -------
This is how the template inclusion model works, and it's what 99% of the 
compilers implement. There is also another separation model (using 
keyword 'export') which allows to keep the template implementation in a 
different file. Only one compiler on earth implements it right now, and there 
are ongoing discussions about its usefulness (the compiler can't "precompile" 
the template in any way, so it needs to "remember" its definition somehow, and 
maybe even reparse the implementation file later while compiling another file 
causing instantiation).

In short, I suggest you live with this for now. This is how everybody does.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14317