È buona norma inserire le definizioni C ++ nei file di intestazione?

Il mio stile personale con C ++ deve sempre mettere le dichiarazioni di classe in un file include e le definizioni in un file .cpp, proprio come stabilito nella risposta di Loki ai file di intestazione C ++, Separazione del codice . Certo, parte del motivo per cui mi piace questo stile probabilmente ha a che fare con tutti gli anni trascorsi a programmare Modula-2 e Ada, entrambi i quali hanno uno schema simile con file di specifiche e file di body.

Ho un collega, molto più esperto in C ++ di me, che insiste sul fatto che tutte le dichiarazioni C ++ dovrebbero, ove possibile, includere le definizioni proprio lì nel file di intestazione. Non sta dicendo che questo è uno stile alternativo valido, o anche uno stile leggermente migliore, ma piuttosto questo è il nuovo stile universalmente accettato che tutti ora usano per C ++.

Non sono agile come una volta, quindi non sono davvero ansioso di arrampicarmi su questo suo carro finché non vedrò altre persone lassù con lui. Quindi quanto è comune questo idioma?

Giusto per dare una struttura alle risposte: è ora The Way , molto comune, un po 'comune, non comune o fuori di testa?

Il tuo collega ha torto, il modo comune è ed è sempre stato quello di inserire il codice nei file .cpp (o qualunque estensione ti piaccia) e le dichiarazioni nelle intestazioni.

Occasionalmente c'è qualche merito nel mettere il codice nell'intestazione, questo può consentire un allineamento più intelligente da parte del compilatore. Allo stesso tempo, può distruggere i tempi di compilazione poiché tutto il codice deve essere elaborato ogni volta che viene incluso dal compilatore.

Infine, è spesso fastidioso avere relazioni a oggetti circolari (a volte desiderate) quando tutto il codice è rappresentato dalle intestazioni.

In conclusione, avevi ragione, ha torto.

EDIT: Ho pensato alla tua domanda. C'è un caso in cui ciò che dice è vero. modelli. Molte nuove librerie "moderne" come boost fanno un uso pesante di modelli e spesso sono "solo intestazione". Tuttavia, questo dovrebbe essere fatto solo quando si tratta di modelli in quanto è l'unico modo per farlo quando si tratta di loro.

MODIFICARE: Alcune persone vorrebbero un po 'più di chiarimenti, ecco alcuni pensieri negativi a scrivere il codice "solo intestazione":

Se cerchi in giro, vedrai molte persone che cercano di trovare un modo per ridurre i tempi di compilazione quando si tratta di boost. Ad esempio: Come ridurre i tempi di compilazione con Boost Asio , che sta vedendo una compilazione 14s di un singolo file 1K con boost incluso. 14s potrebbe non sembrare "esploso", ma è sicuramente molto più lungo del normale e può sommarsi abbastanza rapidamente. Quando si tratta di un grande progetto. Le librerie solo intestazione influiscono sui tempi di compilazione in modo abbastanza misurabile. Lo tolleriamo solo perché boost è così utile.

Inoltre, ci sono molte cose che non possono essere fatte solo nelle intestazioni (anche boost ha librerie a cui devi collegarti per alcune parti come thread, filesystem, ecc.). Un esempio principale è che non è possibile avere oggetti globali semplici nelle librerie solo dell'intestazione (a meno che non si ricorra all'abominio che è un singleton) poiché si verificheranno errori di definizione multipla. NOTA: le variabili inline di C ++ 17 renderanno possibile questo esempio particolare in futuro.

Come ultimo punto, quando si utilizza boost come esempio di codice solo intestazione, spesso si perde un enorme dettaglio.

Boost è una libreria, non un codice a livello di utente. quindi non cambia così spesso. Nel codice utente, se metti tutto nelle intestazioni, ogni piccola modifica ti costringerà a ricompilare l'intero progetto. È una perdita di tempo monumentale (e non è il caso delle biblioteche che non cambiano da compilazione a compilazione). Quando dividi le cose tra intestazione / sorgente e ancora meglio, usa le dichiarazioni in avanti per ridurre le inclusioni, puoi risparmiare ore di ricompilazione una volta sommate in un giorno.

Il giorno in cui i programmatori C ++ concorderanno su The Way , gli agnelli si sdraieranno con i leoni, i palestinesi abbracceranno gli israeliani e cani e gatti potranno sposarsi.

La separazione tra i file .h e .cpp è per lo più arbitraria a questo punto, una traccia di ottimizzazioni del compilatore di lunga data. A mio avviso, le dichiarazioni appartengono all'intestazione e le definizioni appartengono al file di implementazione. Ma questa è solo un'abitudine, non una religione.

Il codice nelle intestazioni è generalmente una cattiva idea poiché impone la ricompilazione di tutti i file che include l'intestazione quando si modifica il codice effettivo anziché le dichiarazioni. Rallenterà anche la compilazione poiché dovrai analizzare il codice in ogni file che include l'intestazione.

Un motivo per avere codice nei file di intestazione è che in genere è necessario che la parola chiave inline funzioni correttamente e quando si utilizzano modelli istanziati in altri file cpp.

Ciò che potrebbe informare il tuo collega è l'idea che la maggior parte del codice C ++ dovrebbe essere modellata per consentire la massima usabilità. E se è basato su modelli, allora tutto dovrà essere in un file di intestazione, in modo che il codice client possa vederlo e crearne un'istanza. Se è abbastanza buono per Boost e STL, è abbastanza buono per noi.

Non sono d'accordo con questo punto di vista, ma potrebbe essere da dove viene.

Penso che il tuo collega sia intelligente e anche tu abbia ragione.

Le cose utili che ho scoperto che mettere tutto nelle intestazioni è che:

1. Non è necessario scrivere e sincronizzare intestazioni e fonti.

2. La struttura è semplice e nessuna dipendenza circolare costringe il programmatore a creare una struttura "migliore".

3. Portatile, facile da integrare in un nuovo progetto.

Sono d'accordo con il problema del tempo di compilazione, ma penso che dovremmo notare che:

1. È molto probabile che il cambiamento del file sorgente cambi i file di intestazione che porta a ricompilare l'intero progetto.

2. La velocità di compilazione è molto più veloce di prima. E se hai un progetto da costruire a lungo e ad alta frequenza, ciò potrebbe indicare che il design del tuo progetto ha dei difetti. Separare le attività in diversi progetti e moduli può evitare questo problema.

Infine, voglio solo supportare il tuo collega, solo dal mio punto di vista personale.

Metterò spesso banali funzioni membro nel file header, per consentire loro di essere incorporate. Ma per mettere lì tutto il codice, solo per essere coerenti con i template? È semplice.

Ricorda: una consistenza insensata è il folletto delle piccole menti .

Come diceva Tuomas, l'intestazione dovrebbe essere minima. Per essere completo espanderò un po '.

Personalmente uso 4 tipi di file nei miei C++progetti:

• Pubblico:
• Intestazione di inoltro: in caso di modelli ecc., Questo file ottiene le dichiarazioni di inoltro che verranno visualizzate nell'intestazione.
• Intestazione: questo file include l'eventuale intestazione di inoltro e dichiara tutto ciò che desidero essere pubblico (e definisce le classi ...)
• Privato:
• Intestazione privata: questo file è un'intestazione riservata per l'implementazione, include l'intestazione e dichiara le funzioni / strutture dell'helper (ad esempio Pimpl o predicati). Salta se non necessario.
• File di origine: include l'intestazione privata (o l'intestazione se nessuna intestazione privata) e definisce tutto (non modello ...)

Inoltre, abbino questo ad un'altra regola: non definire ciò che puoi dichiarare in avanti. Anche se ovviamente sono ragionevole lì (usare Pimpl ovunque è piuttosto una seccatura).

Significa che preferisco una dichiarazione in avanti rispetto a un #include direttiva nelle mie intestazioni ogni volta che riesco a cavarmela.

Infine, utilizzo anche una regola di visibilità: limito il più possibile gli ambiti dei miei simboli in modo che non inquinino gli ambiti esterni.

Mettendo tutto insieme:

// example_fwd.hpp
// Here necessary to forward declare the template class,
// you don't want people to declare them in case you wish to add
// another template symbol (with a default) later on
class MyClass;
template <class T> class MyClassT;

// example.hpp
#include "project/example_fwd.hpp"

// Those can't really be skipped
#include <string>
#include <vector>

#include "project/pimpl.hpp"

// Those can be forward declared easily
#include "project/foo_fwd.hpp"

namespace project { class Bar; }

namespace project
{
  class MyClass
  {
  public:
    struct Color // Limiting scope of enum
    {
      enum type { Red, Orange, Green };
    };
    typedef Color::type Color_t;

  public:
    MyClass(); // because of pimpl, I need to define the constructor

  private:
    struct Impl;
    pimpl<Impl> mImpl; // I won't describe pimpl here :p
  };

  template <class T> class MyClassT: public MyClass {};
} // namespace project

// example_impl.hpp (not visible to clients)
#include "project/example.hpp"
#include "project/bar.hpp"

template <class T> void check(MyClass<T> const& c) { }

// example.cpp
#include "example_impl.hpp"

// MyClass definition

Il salvavita qui è che la maggior parte delle volte l'intestazione in avanti è inutile: necessaria solo in caso di typedefo templatecosì è l'intestazione di implementazione;)

Per aggiungere più divertimento è possibile aggiungere .ippfile che contengono l'implementazione del modello (che è incluso in .hpp), mentre .hppcontiene l'interfaccia.

A parte il codice templatizzato (a seconda del progetto questo può essere la maggioranza o la minoranza dei file) c'è un codice normale e qui è meglio separare le dichiarazioni e le definizioni. Fornire anche dichiarazioni a termine laddove necessario, ciò potrebbe influire sui tempi di compilazione.

Generalmente, quando scrivo una nuova classe, inserirò tutto il codice nella classe, quindi non devo cercarlo in un altro file. Dopo che tutto funziona, rompo il corpo dei metodi nel file cpp , lasciando i prototipi nel file hpp.

Se questo nuovo modo è davvero The Way , avremmo potuto correre in direzioni diverse nei nostri progetti.

Perché cerchiamo di evitare tutte le cose inutili nelle intestazioni. Ciò include evitare la cascata dell'intestazione. Il codice nelle intestazioni avrà probabilmente bisogno di qualche altra intestazione da includere, che avrà bisogno di un'altra intestazione e così via. Se siamo costretti a utilizzare i modelli, proviamo a evitare di sporcare troppo le intestazioni con elementi del modello.

Inoltre usiamo il modello "puntatore opaco" quando applicabile, .

Con queste pratiche possiamo fare build più veloci della maggior parte dei nostri colleghi. E sì ... la modifica del codice o dei membri della classe non causerà enormi ricostruzioni.

Personalmente lo faccio nei miei file di intestazione:

// class-declaration

// inline-method-declarations

Non mi piace mescolare il codice per i metodi con la classe in quanto trovo difficile cercare rapidamente le cose.

Non aggiungerei TUTTI i metodi nel file di intestazione. Il compilatore (normalmente) non sarà in grado di incorporare metodi virtuali e (probabilmente) solo inline metodi piccoli senza loop (dipende totalmente dal compilatore).

Fare i metodi nella classe è valido ... ma da un punto di vista della leggibilità non mi piace. Mettere i metodi nell'intestazione significa che, quando possibile, verranno allineati.

IMHO, ha merito SOLO se sta facendo modelli e / o metaprogrammi. Ci sono molte ragioni già menzionate per limitare i file di intestazione a sole dichiarazioni. Sono solo ... intestazioni. Se si desidera includere il codice, compilarlo come libreria e collegarlo.

Ho messo tutta l'implementazione fuori dalla definizione di classe. Voglio avere i commenti doxygen fuori dalla definizione di classe.

Penso che sia assolutamente assurdo inserire TUTTE le definizioni delle funzioni nel file di intestazione. Perché? Perché il file di intestazione viene utilizzato come interfaccia PUBLIC per la tua classe. È l'esterno della "scatola nera".

Quando devi guardare una classe per fare riferimento a come usarla, dovresti guardare il file header. Il file di intestazione dovrebbe fornire un elenco di ciò che può fare (commentato per descrivere i dettagli su come utilizzare ciascuna funzione) e dovrebbe includere un elenco delle variabili membro. NON DOVREBBE includere COME COME viene implementata ogni singola funzione, perché è un carico di informazioni non necessarie e ingombra solo il file di intestazione.

Non dipende davvero dalla complessità del sistema e dalle convenzioni interne?

Al momento sto lavorando a un simulatore di rete neurale che è incredibilmente complesso e lo stile accettato che dovrei usare è:

Definizioni di classe in classname.h
Codice di classe in classnameCode.h
codice eseguibile in classname.cpp

Ciò divide le simulazioni create dall'utente dalle classi di base create dallo sviluppatore e funziona meglio nella situazione.

Tuttavia, sarei sorpreso di vedere le persone fare questo, ad esempio, in un'applicazione grafica o in qualsiasi altra applicazione che abbia lo scopo di non fornire agli utenti una base di codice.

Il codice modello deve essere solo nelle intestazioni. A parte questo, tutte le definizioni tranne quelle in linea dovrebbero essere in .cpp. L'argomento migliore per questo sarebbe l'implementazione della libreria std che segue la stessa regola. Non saresti in disaccordo sul fatto che gli sviluppatori di std lib avrebbero ragione su questo.

Penso che il tuo collega abbia ragione purché non entri nel processo per scrivere il codice eseguibile nell'intestazione. Il giusto equilibrio, penso, è seguire il percorso indicato da GNAT Ada in cui il file .ads fornisce una definizione dell'interfaccia perfettamente adeguata del pacchetto per i suoi utenti e per i suoi figli.

A proposito Ted, hai dato un'occhiata a questo forum alla recente domanda sull'associazione di Ada alla libreria CLIPS che hai scritto diversi anni fa e che non è più disponibile (le pagine Web pertinenti sono ora chiuse). Anche se realizzato con una vecchia versione di Clips, questa associazione potrebbe essere un buon esempio di partenza per qualcuno disposto a utilizzare il motore di inferenza CLIPS all'interno di un programma Ada 2012.