>>>>> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:

> In article <3uk1ic$pc5@metro.ucc.su.OZ.AU> maxtal@Physics.usyd.edu.au
> (John Max Skaller) writes:

> |> In article <3tubr7$kll@trumpet.uni-mannheim.de>,
> |> Volkan Yavuz <yavuzv@rummelplatz.uni-mannheim.de> wrote:

> |> >I have a little problem concerning templates. When I write
> |> >something like the following, the linker complains about
> |> >an undefined symbol. When I put all the code into one file,
> |> >it all works.

> |>  Your compiler, like all others I know of, does not
> |> (yet) permit separate compilation of templates. You have to
> |> #include the template body definitions -- i.e. make them visible --
> |> to permit instantiation.

> While compilers still generally require the sources to the templates
> to be available to the compiler (or rather the linker), g++ is the
> only one I'm aware of which requires you textually include the sources
> using #include (and I've not tried the more recent versions of g++, so
> they may have fixed this already).

Actually, Borland C++ also requires this.

Jason

In article <3tubr7$kll@trumpet.uni-mannheim.de>,
Volkan Yavuz <yavuzv@rummelplatz.uni-mannheim.de> wrote:
>Hi
>
>I have a little problem concerning templates. When I write
>something like the following, the linker complains about
>an undefined symbol. When I put all the code into one file,
>it all works.

 Your compiler, like all others I know of, does not
(yet) permit separate compilation of templates. You have to
#include the template body definitions -- i.e. make them visible --
to permit instantiation.

 The current CD requires separate compilation to work.
I believe this is kind of tricky to implement.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <3uk1ic$pc5@metro.ucc.su.OZ.AU> maxtal@Physics.usyd.edu.au
(John Max Skaller) writes:

|> In article <3tubr7$kll@trumpet.uni-mannheim.de>,
|> Volkan Yavuz <yavuzv@rummelplatz.uni-mannheim.de> wrote:

|> >I have a little problem concerning templates. When I write
|> >something like the following, the linker complains about
|> >an undefined symbol. When I put all the code into one file,
|> >it all works.

|>  Your compiler, like all others I know of, does not
|> (yet) permit separate compilation of templates. You have to
|> #include the template body definitions -- i.e. make them visible --
|> to permit instantiation.

While compilers still generally require the sources to the templates
to be available to the compiler (or rather the linker), g++ is the
only one I'm aware of which requires you textually include the sources
using #include (and I've not tried the more recent versions of g++, so
they may have fixed this already).

|>  The current CD requires separate compilation to work.
|> I believe this is kind of tricky to implement.

It may be tricky to implement well, but there is a trivial
implementation which works and is really simple to implement: just
copy the (possible compressed or encrypted) sources of the templates
into the object file.  An obvious improvement would be to pre-compile
them, at least to the point of lexical analysis.

The Sun CC compiler actually uses a hacky variant of this to provide
the tools.h++ without the sources.  (They don't put the encrypted
sources in a .o file, but they don't provide a non-encrypted version
either, except with an additional license fee.  So you could say that
they are capable of instantiating templates without having the
template source.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

John Max Skaller (maxtal@Physics.usyd.edu.au) wrote:
:  Your compiler, like all others I know of, does not
: (yet) permit separate compilation of templates. You have to
: #include the template body definitions -- i.e. make them visible --
: to permit instantiation.

:  The current CD requires separate compilation to work.
: I believe this is kind of tricky to implement.

Could someone clarify this for me, or point to towards a source?
It seems I am to #include my .c file in addition to the .h?

--jono

--
"Put down that cigarette, and share the modern world with me" - JRichmann
________________________________________________________________
|  | | "Down for you is up"                     -Lou Reed | |  |
|  | | "He who knows he has enough is rich" -Tao Te Ching | |  |
|  | | <Home Page: http://www.cse.ucsc.edu/~jono>         | |  |

Hi

I have a little problem concerning templates. When I write
something like the following, the linker complains about
an undefined symbol. When I put all the code into one file,
it all works. Sure, in the first case, the object isn't
instantiated. But isn't the line

  cChild<int> Child(1);

instantiation enough?? If not, how else could I instantiate
the object if not it that form?
It works using only one file, but why doesn't it work when
I split all the code into different files?
I couldn't find any answer somewhere and I really think it
is a stupid question, but I couldn't fix it yet.

Any help is really appreciated and
thank you for the time you took reading this.


// foo.h
#ifndef __FOO_H
#define __FOO_H

template<class T>
class cFoo
{
 public:
   cFoo(int size);

   virtual void run(T);
};

#endif


// foo.cc
#include "foo.h"

template<class T>
cFoo<T>::cFoo(int size)
{
}

template<class T>
void cFoo<T>::run(T a)
{
}

// child.h
#ifndef __CHILD_H
#define __CHILD_H

#include "base.h"

template <class T>
class cChild : public cFoo<T>
{
 public:
   cChild(int size);
   virtual void run(T);
};

#endif


// child.cc
#include "child.h"

template<class T>
cChild<T>::cChild(int size) : cBase<T>(size)
{
}

template<class T>
void cChild<T>::run(T a)
{
}


// main.cc
#include "child.h"

cChild<int> Child(1);

int main(void)
{
   Child.run(2);
   return 0;
}