🚀 go-pugleaf

According to my news server, this question is asked every two months or so
> 25 Oct 1995 henty@foxbat.sur.uct.ac.za (Henty Waker)
> 28 Dec 1995 js9sf@fnpx19.fnal.gov (Jiangeng Sun)
> 20 Feb 1996 borkner@ibm.net (Olaf Borkner).

Yet, I couldn't find the proper answer.
"G++ info" lists three ways to deal with template classes:
1. Borland-C++: 
   Put everything in the header, let the linker do sort of "redundancy
   filtering".
   With g++, this awfully breaks the concept of header files.
2. Cfront method (AT&T, SUN C++):
   The compiler mysteriously knows, where the template member functions are
   defined, determines which intances are needed and compiles them.
   G++, not being magic, needs "#pragma interface"/"#pragma implementation"/
   "template class ..."/"-fexternal-templates" for this, thus enforcing a 
   complicated (for larger projects) administrative overhead. This is 
   contratictory to the principles of OOP.
3. Explicitly instantiate all the template instances you use, with
   "template class ..." in the definition file. Compile with 
   "-fno-implicit-templates".
   This is straight forward, easy to understand and easy to implement/
   maintain, although it sometimes may create instances of unneeded 
   functions.

Unfortunately, using "-fno-implicit-templates" for files with inline function
templates prohibits them from being inserted/instanciated (causing unresolved
ref's).
Doing "template class ..." for inline functions seems ridiculous to me. I 
could as well do some "dublicate"+"replace" with the function definition
to hard code the instances.

Is there any chance to avoid this implication of "-fno-implicit-templates"
(keeping the files arrangement due to the model of the programs tasks and
avoiding administrative overhead)?

I think the compiler should be able to distinguish inline from extern!

Thanx, gerhard.