help-gplusplus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can GCC guess where to find template definitions?


From: James Kanze
Subject: Re: Can GCC guess where to find template definitions?
Date: Sat, 16 Apr 2005 13:03:56 +0200
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

jDyre Tjeldvoll wrote:
> Tom Felker <tfelker2@uiuc.edu> writes:

> [snip]

>>I know I could use some preprocessor hackery to make the .h
>>include the .cpp file when necessary (my solution whenever I
>>can), or just put everything in the header, or make a seperate
>>.cpp file with explicit instantiations for everything I need,
>>or use the #pragma interface thing (which I don't fully
>>understand.) But my goal is to get it to work without changing
>>anything from the rather naive way it's done now.

>>If a way to do this doesn't exist, would it be possible to add
>>it as an option, or would that be too ugly to consider? I'd
>>give it a try if I thought it was plausible and if I could
>>understand the code I'd be changing.

> g++ may have something that can help you, but if your goal is to make a
> portable program you can forget it :( The only standard way to do this
> is by using the keyword export, and that is (to my knowledge)
> not suported by more than one (or a few) compiler vendors (e.g. EDG).

The standard specifies export (which as you correctly point out,
isn't widely implemented), but historically, most compilers
under Unix have used an implicit inclusion model, in which for a
template defined in x.{h,hh,..} it tried to find a file
x.{c,cc,...} which it then implicitly included.

Why g++ never implemented this, I'll never know, given that it
is pretty much standard practice in the world where g++ is most
used.

> Without export you need the definition of the template
> available when you instantiate it. Either put everything in
> the .h file or create an .i(mp) file that gets included in the
> TUs where you instantiate.

> I don't know if gcc is planning to implement export, but it
> seems like the current opinion is somewhat against export,
> even though it is in the standard, because it is difficult to
> implement and doesn't really yield all the benefits one would
> expect.

Dixit certain implementers (Microsoft?).  The few people I know
who have actually used export say only good things about it.
It's not a miracle worker, but it does improve encapsulation and
compile times.

--
James Kanze                                 mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
                       Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34


reply via email to

[Prev in Thread] Current Thread [Next in Thread]