Another template question (interface vs implementation)...

[barcaroller]

This is a follow-up to a previous post ("Templates: separating interface
from implementation", July 14)

My current GNU C++ compiler does not allow me to separate template
interfaces from the implementation. This seems to be the norm, according to
the documentation.

However, I dug up some old C++ I had written in the mid 1990's and, sure
enough, the template code is neatly separated into *.h and *.cpp files.
This code used to compile under Sun C++ on Solaris/SPARC and HP C++ on
HP-UX/PA-RISC. Is my memory playing tricks on me or has this particular
template behaviour changed over the last 15 years?

I have provided a snippet below (but I have a lot more examples, all written
in the early-to-mid 1990s).

tree.h
======

template<class T>
class tree
{
public:

...

Node<T>* AddFirstChild(Node<T>* newkid, Node<T>* parent);
...


tree.cpp
========

template<class T>
Node<T>* tree<T>::AddFirstChild(Node<T>* newkid, Node<T>* parent)
{
newkid->sibling = parent->firstchild;
parent->firstchild = newkid;
newkid->parent = parent;

return newkid;
}

 

[Jerry Coffin]

This is a follow-up to a previous post ("Templates: separating interface
from implementation", July 14)

My current GNU C++ compiler does not allow me to separate template
interfaces from the implementation. This seems to be the norm, according to
the documentation.

However, I dug up some old C++ I had written in the mid 1990's and, sure
enough, the template code is neatly separated into *.h and *.cpp files.
This code used to compile under Sun C++ on Solaris/SPARC and HP C++ on
HP-UX/PA-RISC. Is my memory playing tricks on me or has this particular
template behaviour changed over the last 15 years?

Yes, there have been a number of compilers (going all the way back to
some versions of cfront) that have supported separate compilation of
templates in some fashion or other. Exact semantics varied though --
I'm reasonably certain none of them supported two-phase name lookup.

 

[Martin Eisenberg]

However, I dug up some old C++ I had written in the mid 1990's
and, sure enough, the template code is neatly separated into *.h
and *.cpp files. This code used to compile under Sun C++ on
Solaris/SPARC and HP C++ on HP-UX/PA-RISC. Is my memory playing
tricks on me or has this particular template behaviour changed
over the last 15 years?

See:
http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Template-Instantiation.html


Martin

 

[barcaroller]

See:
http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Template-Instantiation.html

Ah yes, now I remember the template repositories that were created in my
source code directories; my compilers at the time were using the cfront
model.

 

[James Kanze]

It's not the norm. But g++ (like many others) doesn't implement
export.

Yes, there have been a number of compilers (going all the way
back to some versions of cfront) that have supported separate
compilation of templates in some fashion or other. Exact
semantics varied though -- I'm reasonably certain none of them
supported two-phase name lookup.

The compilers he cites are all originally based on CFront. What
CFront uses isn't really separate compilation (although it can
superficially seem like it), but implicit inclusion. The
template instantiation is still compiled in the context of the
instantiating program (or part of that context). Basically, if
I have a template defined in "MyTemplate.hh", and I instantiate
it over a type defined in "MyClass.hh", the compiler will
generate a "program" along the lines of:
#include "MyTemplate.hh"
#include "MyClass.hh"
#include "MyTemplate.cc"
// something to trigger explicit instantiation...
, placing that program in a repository, and compiling it at link
time. You still end up with a large part of the context of
MyClass, and not just the minimum necessary. (For example, any
#define's in MyClass.hh will affect the instantiation.)

(I originally thought like you, but I had a long discussion in
email with John Spicer about it, more than ten years ago, and
ended up agreeing with him. Not too surprising, really---if I'm
not mistaken, he's the author of the template code in CFront,
and while the standard doesn't recognize such things, I think he
could be considered the lead author of section 14 in the
standard.)

 

[Jerry Coffin]

(e-mail address removed)>, (e-mail address removed)
says...

[ ... ]

The compilers he cites are all originally based on CFront. What
CFront uses isn't really separate compilation (although it can
superficially seem like it), but implicit inclusion. The
template instantiation is still compiled in the context of the
instantiating program (or part of that context).

From that viewpoint, even Comeau doesn't really support separate
compilation either -- and if you restrict separate compilation to
meaning producing object code like we'd expect to see from C or non-
template C++, it's pretty clear that nothing really CAN support
separate compilation of templates either.

 

[James Kanze]

(e-mail address removed)>, (e-mail address removed)
says...

[ ... ]

The compilers he cites are all originally based on CFront.
What CFront uses isn't really separate compilation (although
it can superficially seem like it), but implicit inclusion.
The template instantiation is still compiled in the context
of the instantiating program (or part of that context).

From that viewpoint, even Comeau doesn't really support
separate compilation either -- and if you restrict separate
compilation to meaning producing object code like we'd expect
to see from C or non- template C++, it's pretty clear that
nothing really CAN support separate compilation of templates
either.

Not without an adequate object format. With an adequate object
format, there would be no problem. But that's not what I meant.
When CFront compiles a template instantiation, it picks up a lot
of the context of the point of instantiation. Relevant or not.
If you use export (which is true separate compilation), you
don't.

As I said, I felt a bit like you, until John Spicer took me to
task, and painfully explained to me all that was involved.