Dichiarazioni di dattiloscrizione in avanti, effetti sui tempi di costruzione e convenzioni di denominazione

Question

Sono curioso dell'impatto che il mio approccio typedef ha sulle mie build.

Si prega di considerare il seguente esempio.

#include "SomeClass.h"

class Foo
{
    typedef SomeClass SomeOtherName;

    SomeOtherName* storedPointer;

    void setStoredPointer(SomeOtherName* s);
}

void Foo::setStoredPointer(SomeOtherName* s)
{
    storedPointer = s;
}

Ogni volta che finisco con situazioni come sopra, questo porta il typedef nel file di intestazione e, quindi, richiedo di includerlo # nel file di intestazione. Temo che la mancanza di dichiarazioni a termine possa causare tempi di costruzione più lunghi.

Sulla base dei commenti di questo post:

Dichiarazione a termine di un typedef in C ++

Posso inoltrare dichiarare la classe, digitare un riferimento o un puntatore e quindi #include all'interno del file .cpp. Ciò dovrebbe quindi consentire tempi di costruzione più rapidi. Sono corretto nelle mie conclusioni al riguardo?

In tal caso, finirei con un typedef come questo:

typedef SomeClass* SomeOtherNamePtr;
typedef SomeClass& SomeOtherNameRef;
typedef const SomeClass* SomeOtherNameConstPtr;
typedef const SomeClass& SomeOtherNameConstRef;

Questo non mi sembra un codice molto pulito e penso di aver letto articoli / post (non necessariamente su SO) che mi sconsigliano.

Lo trovi accettabile? Alternative migliori?

---

Aggiornamento: Usando la risposta di Michael Burr, sono stato in grado di risolvere solo il caso di puntatori e riferimenti. Tuttavia, ho riscontrato un problema durante il tentativo di prendere sizeof () nella mia funzione. Ad esempio, supponiamo che la classe abbia la seguente funzione:

//Foo.h
class Foo
{
    typedef class SomeClass SomeOtherName;

    void doSomething(const SomeOtherName& subject)
}

//Foo.cpp
#include "Foo.h"
#include "SomeClass.h"
void Foo::doSomething(const SomeOtherName& subject)
{
    sizeof(subject); //generates error C2027: use of undefined type 'SomeClass';
    sizeof(SomeClass); //generates same error, even though using the sizeof()
                       //the class that has been #include in the .cpp.  Shouldn't
                       //the type be known by now?
}

In alternativa, funzionerebbe.

//Foo.h
class SomeClass;
class Foo
{
    void doSomething(const SomeClass& subject)
}

//Foo.cpp
#include "Foo.h"
#include "SomeClass.h"
void Foo::doSomething(const SomeClass& subject)
{
    sizeof(subject);
    sizeof(SomeClass);
}

Sto usando Microsoft Visual C ++ 6.0. È un bug del compilatore o è in generale contro lo standard?

Nell'esempio che presenta l'errore, si noti che sizeof (SomeClass) è la classe originale che si sta scrivendo, non il nuovo tipo di typedef creato in Foo. Sono sorpreso che facendo una dichiarazione in avanti in un typedef mi limiti la mia capacità di fare qualsiasi cosa con la classe che sta scrivendo.

---

ollowup: Ho appena testato usando il compilatore XCode e credo che la mia domanda sizeof fosse un problema del compilatore Visual C ++ 6.0. Immagino che il compilatore XCode sia probabilmente corretto, ma al momento non ho nient'altro da provare. Quindi, mentre questo è stato informativo, personalmente sono sfortunato per il mio compito attuale poiché la migliore risposta non funziona per la mia situazione.

Answer 1

Sarebbe

typedef class SomeClass SomeOtherName;

fai il trucco per te?

Con ciò, l'unità di compilazione che utilizza il typedef solo per puntatori o riferimenti non deve #include l'intestazione SomeClass .

Answer 2

  

Sono corretto nelle mie conclusioni al riguardo?

Sì. Una delle risposte alla domanda a cui hai fatto riferimento suggerisce che puoi:

//forward declaration instead of #include "SomeClass.h"
class SomeClass;
//now this works even without #include "SomeClass.h"
typedef SomeClass SomeOtherName;

  

Questo non mi sembra un codice molto pulito

Non vedo che i tuoi typedef aggiungano alcun valore; invece probabilmente dichiarerei in anticipo SomeClass e quindi utilizzerei direttamente ' const SomeClass & amp; '.