Dividere le classi C ++ basate su modelli in file .hpp / .cpp: è possibile?

Ricevo errori nel tentativo di compilare una classe template C ++ suddivisa tra un file .hppe .cpp:

$ g++ -c -o main.o main.cpp  
$ g++ -c -o stack.o stack.cpp   
$ g++ -o main main.o stack.o  
main.o: In function `main':  
main.cpp:(.text+0xe): undefined reference to 'stack<int>::stack()'  
main.cpp:(.text+0x1c): undefined reference to 'stack<int>::~stack()'  
collect2: ld returned 1 exit status  
make: *** [program] Error 1  

Ecco il mio codice:

stack.hpp :

#ifndef _STACK_HPP
#define _STACK_HPP

template <typename Type>
class stack {
    public:
            stack();
            ~stack();
};
#endif

stack.cpp :

#include <iostream>
#include "stack.hpp"

template <typename Type> stack<Type>::stack() {
        std::cerr << "Hello, stack " << this << "!" << std::endl;
}

template <typename Type> stack<Type>::~stack() {
        std::cerr << "Goodbye, stack " << this << "." << std::endl;
}

main.cpp :

#include "stack.hpp"

int main() {
    stack<int> s;

    return 0;
}

ldè ovviamente corretto: i simboli non sono presenti stack.o.

La risposta a questa domanda non aiuta, poiché sto già facendo come si dice.
Questo potrebbe aiutare, ma non voglio spostare ogni singolo metodo nel .hppfile: non dovrei farlo, vero?

L'unica soluzione ragionevole è spostare tutto nel .cppfile nel .hppfile e includere semplicemente tutto, invece di collegarlo come un file oggetto autonomo? Sembra terribilmente brutto! In quel caso, potrei anche tornare al mio stato precedente e rinominare stack.cppper stack.hppe da fare con esso.

Non è possibile scrivere l'implementazione di una classe template in un file cpp separato e compilare. Tutti i modi per farlo, se qualcuno afferma, sono soluzioni alternative per imitare l'uso di un file cpp separato ma praticamente se si intende scrivere una libreria di classi modello e distribuirla con file di intestazione e lib per nascondere l'implementazione, semplicemente non è possibile .

Per sapere perché, esaminiamo il processo di compilazione. I file di intestazione non vengono mai compilati. Sono solo preelaborati. Il codice preelaborato viene quindi copiato con il file cpp che viene effettivamente compilato. Ora, se il compilatore deve generare il layout di memoria appropriato per l'oggetto, deve conoscere il tipo di dati della classe template.

In realtà si deve capire che la classe template non è affatto una classe ma un template per una classe la cui dichiarazione e definizione viene generata dal compilatore in fase di compilazione dopo aver ottenuto le informazioni del tipo di dati dall'argomento. Finché non è possibile creare il layout di memoria, le istruzioni per la definizione del metodo non possono essere generate. Ricorda che il primo argomento del metodo di classe è l'operatore "this". Tutti i metodi di classe vengono convertiti in metodi individuali con modifica del nome e il primo parametro come oggetto su cui opera. L'argomento 'this' è che in realtà indica la dimensione dell'oggetto che, in caso di classe template, non è disponibile per il compilatore a meno che l'utente non installi l'oggetto con un argomento di tipo valido. In questo caso, se metti le definizioni del metodo in un file cpp separato e provi a compilarlo, il file oggetto stesso non verrà generato con le informazioni sulla classe. La compilazione non fallirà, genererà il file oggetto ma non genererà alcun codice per la classe template nel file oggetto. Questo è il motivo per cui il linker non riesce a trovare i simboli nei file oggetto e la generazione non riesce.

Qual è l'alternativa per nascondere importanti dettagli di implementazione? Come tutti sappiamo l'obiettivo principale dietro la separazione dell'interfaccia dall'implementazione è nascondere i dettagli dell'implementazione in forma binaria. Qui è dove devi separare le strutture dati e gli algoritmi. Le classi del modello devono rappresentare solo le strutture di dati, non gli algoritmi. Ciò consente di nascondere dettagli di implementazione più preziosi in librerie di classi separate non templatizzate, le classi all'interno delle quali funzionerebbero sulle classi modello o semplicemente le userebbero per contenere dati. La classe template conterrebbe effettivamente meno codice per assegnare, ottenere e impostare i dati. Il resto del lavoro sarebbe svolto dalle classi di algoritmi.

Spero che questa discussione possa essere utile.

Si è possibile, a patto che si sa cosa istanze che si sta per necessità.

Aggiungi il seguente codice alla fine di stack.cpp e funzionerà:

template class stack<int>;

Tutti i metodi di stack non modello verranno istanziati e il passaggio di collegamento funzionerà correttamente.

Puoi farlo in questo modo

// xyz.h
#ifndef _XYZ_
#define _XYZ_

template <typename XYZTYPE>
class XYZ {
  //Class members declaration
};

#include "xyz.cpp"
#endif

//xyz.cpp
#ifdef _XYZ_
//Class definition goes here

#endif

Questo è stato discusso in Daniweb

Anche nelle FAQ ma utilizzando la parola chiave di esportazione C ++.

No, non è possibile. Non senza la exportparola chiave, che a tutti gli effetti non esiste realmente.

Il meglio che puoi fare è mettere le implementazioni delle tue funzioni in un file ".tcc" o ".tpp" e #include il file .tcc alla fine del tuo file .hpp. Tuttavia questo è solo cosmetico; è sempre lo stesso dell'implementazione di tutto nei file di intestazione. Questo è semplicemente il prezzo da pagare per l'utilizzo dei modelli.

Credo che ci siano due ragioni principali per provare a separare il codice basato su modelli in un'intestazione e in un cpp:

Uno è per pura eleganza. A tutti noi piace scrivere codice che sia facile da leggere, gestire e riutilizzabile in seguito.

Altro è la riduzione dei tempi di compilazione.

Attualmente (come sempre) sto codificando un software di simulazione in combinazione con OpenCL e ci piace mantenere il codice in modo che possa essere eseguito utilizzando i tipi float (cl_float) o double (cl_double) secondo necessità a seconda delle capacità HW. In questo momento questo viene fatto usando un #define REAL all'inizio del codice, ma non è molto elegante. La modifica della precisione desiderata richiede la ricompilazione dell'applicazione. Dal momento che non esistono tipi di runtime reali, dobbiamo convivere con questo per il momento. Fortunatamente i kernel OpenCL sono runtime compilati e un semplice sizeof (REAL) ci consente di modificare di conseguenza il runtime del codice del kernel.

Il problema molto più grande è che anche se l'applicazione è modulare, quando si sviluppano classi ausiliarie (come quelle che pre-calcolano le costanti di simulazione) devono essere anche modellate. Queste classi appaiono tutte almeno una volta in cima all'albero delle dipendenze della classe, poiché la simulazione della classe modello finale avrà un'istanza di una di queste classi factory, il che significa che praticamente ogni volta che apporto una piccola modifica alla classe factory, l'intera il software deve essere ricostruito. Questo è molto fastidioso, ma non riesco a trovare una soluzione migliore.

Solo se #include "stack.cppalla fine di stack.hpp. Consiglierei questo approccio solo se l'implementazione è relativamente grande e se rinomini il file .cpp con un'altra estensione, per differenziarlo dal codice normale.

A volte è possibile avere la maggior parte dell'implementazione nascosta nel file cpp, se è possibile estrarre funzionalità comuni da tutti i parametri del modello in una classe non modello (possibilmente non sicura per il tipo). Quindi l'intestazione conterrà le chiamate di reindirizzamento a quella classe. Un approccio simile viene utilizzato quando si combatte con il problema del "template bloat".

Se sai con quali tipi verrà utilizzato il tuo stack, puoi istanziarli esplicitamente nel file cpp e conservare lì tutto il codice pertinente.

È anche possibile esportarli attraverso DLL (!), Ma è piuttosto difficile ottenere la sintassi corretta (combinazioni specifiche di MS di __declspec (dllexport) e la parola chiave export).

L'abbiamo usato in una libreria matematica / geom che utilizzava modelli double / float, ma aveva un bel po 'di codice. (All'epoca ho cercato su Google per questo, ma oggi non ho quel codice.)

Il problema è che un modello non genera una classe reale, è solo un modello dice al compilatore come generare una classe. Devi generare una classe concreta.

Il modo più semplice e naturale è inserire i metodi nel file di intestazione. ma c'è un altro modo.

Nel tuo file .cpp, se hai un riferimento a ogni istanza di modello e metodo di cui hai bisogno, il compilatore li genererà lì per l'uso durante il tuo progetto.

new stack.cpp:

#include <iostream>
#include "stack.hpp"
template <typename Type> stack<Type>::stack() {
        std::cerr << "Hello, stack " << this << "!" << std::endl;
}
template <typename Type> stack<Type>::~stack() {
        std::cerr << "Goodbye, stack " << this << "." << std::endl;
}
static void DummyFunc() {
    static stack<int> stack_int;  // generates the constructor and destructor code
    // ... any other method invocations need to go here to produce the method code
}

Devi avere tutto nel file hpp. Il problema è che le classi non vengono effettivamente create finché il compilatore non vede che sono necessarie a un ALTRO file cpp, quindi deve avere tutto il codice disponibile per compilare la classe basata su modelli in quel momento.

Una cosa che tendo a fare è provare a dividere i miei modelli in una parte generica non basata su modelli (che può essere divisa tra cpp / hpp) e la parte modello specifica del tipo che eredita la classe non basata su modelli.

Poiché i modelli vengono compilati quando richiesto, ciò impone una restrizione per i progetti con più file: l'implementazione (definizione) di una classe o funzione modello deve essere nello stesso file della sua dichiarazione. Ciò significa che non possiamo separare l'interfaccia in un file di intestazione separato e che dobbiamo includere sia l'interfaccia che l'implementazione in qualsiasi file che utilizza i modelli.

Un'altra possibilità è fare qualcosa come:

#ifndef _STACK_HPP
#define _STACK_HPP

template <typename Type>
class stack {
    public:
            stack();
            ~stack();
};

#include "stack.cpp"  // Note the include.  The inclusion
                      // of stack.h in stack.cpp must be 
                      // removed to avoid a circular include.

#endif

Non mi piace questo suggerimento per una questione di stile, ma potrebbe essere adatto a te.

La parola chiave "export" è il modo per separare l'implementazione del modello dalla dichiarazione del modello. Questo è stato introdotto nello standard C ++ senza un'implementazione esistente. A tempo debito solo un paio di compilatori lo hanno effettivamente implementato. Leggere le informazioni approfondite nell'articolo Inform IT sull'esportazione

1) Ricorda che il motivo principale per separare i file .he .cpp è nascondere l'implementazione della classe come codice Obj compilato separatamente che può essere collegato al codice dell'utente che includeva un .h della classe.

2) Le classi non template hanno tutte le variabili concretamente e specificatamente definite nei file .h e .cpp. Quindi il compilatore avrà le informazioni necessarie su tutti i tipi di dati usati nella classe prima di compilare / tradurre  generare l'oggetto / codice macchina Le classi dei modelli non hanno informazioni sul tipo di dati specifico prima che l'utente della classe installi un oggetto che passa i dati richiesti genere:

        TClass<int> myObj;

3) Solo dopo questa istanza, il compilatore genera la versione specifica della classe template per abbinare i tipi di dati passati.

4) Pertanto, .cpp NON può essere compilato separatamente senza conoscere il tipo di dati specifico dell'utente. Quindi deve rimanere come codice sorgente all'interno di ".h" finché l'utente non specifica il tipo di dati richiesto, quindi può essere generato su un tipo di dati specifico e quindi compilato

Il punto in cui potresti volerlo fare è quando crei una libreria e una combinazione di intestazione e nascondi l'implementazione all'utente. Pertanto, l'approccio suggerito consiste nell'utilizzare l'istanza esplicita, poiché si sa cosa dovrebbe fornire il software e si possono nascondere le implementazioni.

Alcune informazioni utili sono qui: https://docs.microsoft.com/en-us/cpp/cpp/explicit-instantiation?view=vs-2019

Per il tuo stesso esempio: Stack.hpp

template <class T>
class Stack {

public:
    Stack();
    ~Stack();
    void Push(T val);
    T Pop();
private:
    T val;
};


template class Stack<int>;

stack.cpp

#include <iostream>
#include "Stack.hpp"
using namespace std;

template<class T>
void Stack<T>::Push(T val) {
    cout << "Pushing Value " << endl;
    this->val = val;
}

template<class T>
T Stack<T>::Pop() {
    cout << "Popping Value " << endl;
    return this->val;
}

template <class T> Stack<T>::Stack() {
    cout << "Construct Stack " << this << endl;
}

template <class T> Stack<T>::~Stack() {
    cout << "Destruct Stack " << this << endl;
}

main.cpp

#include <iostream>
using namespace std;

#include "Stack.hpp"

int main() {
    Stack<int> s;
    s.Push(10);
    cout << s.Pop() << endl;
    return 0;
}

Produzione:

> Construct Stack 000000AAC012F8B4
> Pushing Value
> Popping Value
> 10
> Destruct Stack 000000AAC012F8B4

Tuttavia non mi piace del tutto questo approccio, perché consente all'applicazione di spararsi ai piedi, passando tipi di dati errati alla classe basata su modelli. Ad esempio, nella funzione main, puoi passare altri tipi che possono essere convertiti implicitamente in int come s.Push (1.2); e questo è solo un male secondo me.

Sto lavorando con Visual Studio 2010, se desideri dividere i tuoi file in .h e .cpp, includi la tua intestazione cpp alla fine del file .h