Re: [Mingw-users] Separate compilation of templates [Was: linker]

[Greg C. <chi...@co...>]

On 2005-03-30 03:34 AM, Foster, Gareth wrote:

> Thank you for the links, that is just the sort of information I was looking
> for, I'll be sure to read those over the course of the day.
> 
>>Before you go down any of these paths, what are you trying to 
>>accomplish?
>>There are pitfalls here for the unwary, and you should have a definite
>>reason before trying these techniques.
> 
> As for why I am doing what I am doing, I am writing a class that is going to
> parse text. So, I am attempting to write the class in the style of the STL,
> allowing the "method" to accept two iterators of any old type, then the user
> can use a std::vector of chars, or a std::string or istream_iterators or
> whatever they want. Hopefully this is a sensible use of templates, I'm
> always open to comments though.

Sure, that sounds like a sensible use of templates.

I should have phrased my question more clearly. What I had meant
to ask is: given that writing template definitions in the header
is almost universal practice, what are you hoping to gain by
doing otherwise? There are some real advantages, but there are
also some commonly perceived advantages that aren't realized.

> As for the .cc/.hh declaration/definition issue, I did solve it by including
> the .cc file from the .hh file, and removing the .cc file from my
> Makefile.am, it builds and links now. The good thing about this is that I
> can still keep the organisation I am used to (information hiding and all
> that) and hopefully, revert to the normal style as and when C++ becomes
> capable of supporting it where templates are in use - of course, I might
> change my mind on that one once I have digested those URLs you mentioned.

For templates, it's common practice to use the inverse of the
normal style: instead of declarations in .hh and definitions in
.cc, people tend to put everything in .hh--or, as you've quite
reasonably done, include the template .cc in the .hh . If you
just want to follow good design principles, then that's great.

Some people, however, seek something more than "information
hiding" in the OO sense of encapsulation: they want to distribute
compiled binaries of template code without divulging their
implementation. That seems to have been one of the original hopes
for the 'export' keyword, but it's not going to be fulfilled.

Some hoped that 'export' would make compilation faster, like
factoring non-template code out of an inline .hh implementation
into a separate .cc would. The Sutter and Plum paper I cited
says that hope isn't likely to be realized.

OTOH, alternative techniques other than 'export' may actually
make compilation faster and reduce template bloat, and they
actually work with most or all compilers. That's the only good
practical reason I know for considering those techniques.