Newsgroup: it.comp.lang.c++
Titolo: De Rerum Template (LOL)

Salve gente,
scusate il topic lolloso ma sto impazzendo con i template avanti e lo 
Stroustrup a sinistra...
Sto facendo dei test per implemantare i template in file separati (.h e 
.cpp) e non in un solo file.
Esempio singolo file:
.H
template <class X>
class CInt
{
private:	
	X _size;
public:	
	CInt<X>( X i ) : _size( i )
	{
	}
};
main.cpp
CInt<int> T ( 5 );
Funge tutto per bene.
Esempio file .h e .cpp
.H
template <class X>
class CInt
{
private:	
	X _size;
public:	
	CInt<X>( X i );
};
.CPP
// Esplicitando tutto per benino...
template <class X> CInt<X>::CInt<X> ( X i ) : _size( i )
{
}
Main:
	int u = 0;
	CInt<int> T( u );
	//std::cout<<T;
	return EXIT_SUCCESS;
Questo non mi da errori di compilazione ma di link, dicendo :
Test template error LNK2019: riferimento al simbolo esterno "public: 
__thiscall CInt<int>::CInt<int>(int)" (??0?$CInt@H@@QAE@H@Z) non risolto 
nella funzione _main
Cercando un costruttore che prende un intero...ma per come è definito 
non vorrebbe dire che ho deciso che il costruttore lavori su TUTTI i 
possibili tipi che possono comparire ???
Grazie...

 
come compili?
se hai x file "cpp", usando gcc devi mettere TUTTI I FILE .CPP
$ gcc -o uscita a.cpp b.cpp c.cpp ...
oK?

 
Salvo il caso in cui si adottino accorgimenti particolari o si utilizzi un 
compilatore che implementi l'export, non è possibile collocare la 
definizione (implementazione) di un template in una unità di compilazione 
(file .cpp) diversa da quella in cui viene instanziato. L'instanziazione 
completa di un template richiede la visibiltà del codice sorgente.
Max


Sto usando VC++ .NET 2003...nn posso ancora provare sotto 
linuccio....non ora....cmq e' codice standard (credo) e poi sto 
prendendo a riferimento lo stroustrup...


Curiosita' circa questo: la parola chiave 'export' dovrebbe essere la 
soluzione a questo stramaledetto problema dei template? Nel caso, quanto 
e' supportata al momento?
-- 
/**
  * Mattia Belletti - Undergraduate student @ 
cs.unibo.it
  * ICQ: 33292311   - email: 
mbel...@cs.unibo.it
  * IRC: BluShine   - site(s): 
http://cs.unibo.it/~mbellett
  * Linux registered user 299762 @ Linux registered machine 213003
  */

Mattia Belletti wrote:
[ cut ]
 > ...stramaledetto problema dei template...
Allora non sono l'unico a cui da fastidio scrivere tutto in un unico 
file.... :)


A me sta *tremendamente* sul cazzo :P. Il fatto che qualcosa che 
concettualmente e' possibile, e nella pratica non lo e', mi innervosisce :)


 e' supportata al momento?
<cite from="
http://www.comeaucomputing.com/techtalk/templates/
">
 Some compilers require that all function templates need to be made
 available in every translation unit that it is used in. In effect, for
 those compilers, the bodies of template functions must be made available
 in a header file. To repeat: that means those compilers won't allow them
 to be defined in non-header files such as .cpp files. Furthermore, some
 compilers also require that some functions be defined inline inside a
 class, and not outside of one.
 Note that not all compilers require this. For instance, Comeau C++ does
 not in all cases (check out
 
http://www.comeaucomputing.com/4.0/docs/userman/ati.html
 for details on
 our current setup). In short, Comeau C++ supports many models, including
 one which comes close to what the export keyword's intentions are (as an
 extension).
 And on this point, note that the C++ export keyword is intended to
 alleviate the original question. However, currently Comeau C++ is the
 only compiler known to support export. Therefore, some compilers use such
 extensions referred to in the previous paragraph, or you need to put the
 bodies of your functions in headers, if you are using a compiler which
 does not support export.
</cite>
-- 
sbirish

 concettualmente e' possibile, e nella pratica non lo e', mi innervosisce
Io non lo trovo un grosso fastidio. Anzi, trovo utile tenere distinto il 
codice "normale", che deve essere compilato una-tantum, dal codice 
template, che sarà di fatto ricompilato per ogni diversa instanziazione.
L'unico inconveninete è che, se una certa instanziazione è utilizzata in 
più unità di compilazione (come accade normalmente), lo stesso codice verrà 
ricompilato più volte anche se i parametri del template sono i medesimi.
Se possibile, io colloco la dichiarazione e l'implementazione di un 
template in file distinti. (La mia personalissima convenzione è 
usare l'estensione ".hxx" per i file che contengono prevalentemente 
implementazioni di template, e il consueto ".h" per quelli che contengono 
prevalentemente dichiarazioni.)
Questo mi consente, spesso, di ridurre in numero di inclusioni. Ad esempio, 
se A.cpp e B.cpp fanno uso della stessa instanziazione di un template, 
posso, se sussistono certe condizioni, includere il file 
dell'implementazione soltanto in A.cpp. In fase di linking, basteranno i 
simboli definiti dalla compilazione di A.cpp.
Questo non funziona sempre, però. Ad esempio, se una classe template ha due 
funzioni membro e una soltanto è usata in A.cpp, l'instanziazione del 
template in A.cpp non sarà completa, e non sarà sufficiente se in B.cpp 
viene utilizzata l'altra funzione membro.
Max

 sono i medesimi.
non sarebbe un'idea malvagia avere un unico sorgente master che includa 
tutti gli altri: unitŕ di compilazione unica, ottimizzazioni globali su 
ogni compilatore. Ho giŕ visto un progetto adottare questo espediente
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.5. C, C++ and ASM developers
                               and beta testers are welcome!

 concettualmente e' possibile, e nella pratica non lo e', mi innervosisce :)
Ma compilare separatamente i template *non* e' possibile nemmeno
concettualmente, quindi dov'e' il problema? :-P
Ciao,
Nicola