www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/03/20/10:01:47

From: hat AT se-46 DOT wpa DOT wtb DOT tue DOT nl ()
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Templates AND GCC
Date: 20 Mar 1998 14:33:18 GMT
Organization: Eindhoven University of Technology, The Netherlands
Lines: 70
Message-ID: <6etune$jea@tuegate.tue.nl>
References: <350EBB24 DOT EAEB38D5 AT geocities DOT com>
<351169b9 DOT 0 AT news DOT cadvision DOT com>
Reply-To: a DOT hofkamp AT wtb DOT tue DOT nl
NNTP-Posting-Host: se-46.wpa.wtb.tue.nl
Mime-Version: 1.0
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

In article <351169b9 DOT 0 AT news DOT cadvision DOT com>,
	frenchc AT SPAMISNTCOOLcadvision DOT com (Calvin French) writes:
> 
> really know exactly how this works. The problem is that it isn't comipling 
> your funtions list<int>::myfunc() because you haven't told it to. You've just 
> given it empty definitions (in list.cc) of HOW to compile them, but no data 
> types to actually compile them from. Now, I believe there are two solutions. 
> You can either put dummy statements of some kind into list.cc, for instance:
> 
> list<int> dummylist;

This is kind of strange. Why would you write a template, and force the
compiler to include it, without actually using it ?

The usual solution I use is to write a short test-program like

int main() {
list<int> dummylist;
/* here, do some test with the dummylist var */
return 0;
}

for testing the implementation. Once you're satisfied that it is
working, include the template in the real program you are writing. The
compiler will create instances of the templates when appropiate.

> generate code for an int list. Or you could do it the way I do; put all the 
> executable code into the .h file. This will make things a bit bloated as 
> the code will get repeated in every source file it's used (i.e., it will be 
> generated in main.cc for list<int>, but a totally different one wil also be 
> made if say you linked in a groo.cc using list<int>, even though they are 
> identical codes; I did read somewhere about there being an optimization in 

There is a repo patch available for gcc 2.7.2. It keeps track of
instances of templates which are really needed, and instances which are
not needed (because they are not used, or because they are already
instantiated somewhere else).
I used it succesfully on Linx, but it failed on MSDOS (with DJGPP). If
someone has the repo-patch up&running on DJGPP, I'd love to hear about it.

> the works for this, maybe gcc 2.8.0 is smart enough to keep track of separate 
> source files' templated instantiation thingies, I don't know), but that's 

imho you shouldn't worry too much about it. As time progresses, the
gcc-people will come with a solution.
The average computer is so big nowadays, that the extra memory needed is
not worth bothering about.

> just the price you pay for templates. And remember they are FAST at run time, 

I don't agree with your focus on runtime speed, but the general opinion is
different here.

> zoom zoom zoom so if they make things a bit FAT and SLOW compile time they 
> are probably still worth it! So GOOD LUCK! 

the repo-patch is really slow to compile (it repeatedly re-compiles),
and you definitely don't want to try it until you are finished developing.

> PS the all-in-h-file approach is what the STL uses, but if you decide to 
> compile with STL you also have to include a library libstdcx or something, I 

Isn't this just the standard c++ library, which you need anyway to
compile a c++ program ?


Albert
---
Sorry, no .sig
The sys admin wiped the previous sig, and I haven't invented a new one yet.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019