pratica di avere un colpo di testa "Comune"

Question

di comune non intendo utilità, voglio dire un colpo di testa che contiene le enumerazioni che più tipi desiderano utilizzare, ecc

Per esempio, se più tipi possono avere un Color , che è un enum, vorresti renderlo disponibile. Alcune persone direbbero di metterlo nella classe che "si adatta meglio con", ma questo può creare problemi di dipendenza dell'intestazione.

Non mi piace davvero creare un'intestazione che contiene cose come questa, perché sembra che rende il codice più complesso. Sto cercando i pensieri degli altri su quali tecniche impiegano quando si imbattono in una situazione come questa. Se usano un'intestazione "Comune", ecc.

Answer 1

Uso sempre un file Common.h che non cambia quasi mai e contiene definizioni che sono estremamente probabilmente necessarie in quasi tutti i file. Penso che aumenti la produttività in modo da non dover aprire un altro file .cpp e copiare l'elenco di tutte le intestazioni che sai che avrai sicuramente bisogno.

Per esempio, qui ci sono due brani del mio COMMON.H:

typedef unsigned char uint8; 
typedef signed char int8; 
typedef unsigned char uint08; 
typedef signed char int08; 
typedef unsigned short uint16; 
typedef signed short int16; 
typedef unsigned int uint32; 
typedef signed int int32; 
typedef unsigned long long uint64; 
typedef signed long long int64; 
typedef const char cchar; 
typedef const bool cbool; 
typedef char Byte; 

#ifdef ASSERT 
/* Re-defining assert */ 
#undef ASSERT 
#endif 

#ifdef DEBUG 
#ifndef ASSERTIONS 
#define ASSERTIONS 
#endif 
#endif 

#define ASSERT_ALWAYS(Expression) if (!(Expression)) FatalError(ErrorInfo("Assertion Failure", #Expression, FUNCTION_NAME, __FILE__, __LINE__)) 

#ifdef ASSERTIONS 
#ifdef DEBUG 
#define ASSERT(Expression) ASSERT_ALWAYS(Expression) 
#else 
#define ASSERT(Expression) if (!(Expression)) ErrorLog("[Release Assertions]: The following assertion failed: " # Expression) 
#endif 
#else 
#define ASSERT(Expression) 
#endif 

Answer 2

L'intestazione comune è ok finché ci sono poche persone che lavorano al progetto. Una volta che più di 20 persone modificano quel file e uniscono le modifiche avanti e indietro, inizi ad avere un incubo.

Forse un'alternativa sarebbe avere un color.h o un file common/color.h, che imporrebbe una certa struttura sui file.

Answer 3

intestazioni IMO comuni sono le buone pratiche se li si limita a contenere le cose che cambiano raramente come

typedef unsigned int UINT32; 

Se ti ritrovi a modificare questo file molto, allora ci sono cose che non ci appartengono.

Answer 4

Personalmente non sono un fan.

1. I significa che quando si modifica una costante (o tipo) che viene utilizzato in un solo luogo, è necessario ricompilare l'intero progetto.
2. Il valore della costante (o definizione del tipo) e l'uso di detta costante (o tipo) sono in due posizioni diverse.

In generale, mi piace definire una costante che viene utilizzato una sola volta, accanto a dove viene utilizzato. Ciò significa che se voglio sapere quale valore tiene la costante, è proprio lì che devo guardare. Significa anche che ho bisogno di ricompilare un file solo quando la costante cambia.

C'è un caso per un file di intestazione costante se la costante o il tipo è utilizzato estesamente o se una costante o un tipo è condivisa tra i moduli.

Answer 5

Se si desidera l'enumerazione "globale", inserirli nel proprio spazio dei nomi anziché inquinare lo spazio dei nomi globale, ad es.:

// Types.h 

namespace MyTypes 
{ 
    enum Color 
    { 
     RED, 
     BLUE, 
     GREEN, 
    }; 
} 

Personalmente preferisco mantenere l'enumerazione associata a una classe ma YMMV.

Answer 6

Preferisco essere esplicito su ciò che ogni file cpp ha bisogno. Trovo che sia più facile a lungo termine e che impedisca che le intestazioni "comuni" causino la ricostruzione dei file quando non è necessario. Man mano che un progetto cresce, avere una politica "includi solo ciò di cui hai bisogno" può aiutarti a ridurre i tempi di costruzione. Il prezzo di questo è un piccolo pensiero quando inizialmente stai costruendo una nuova classe. Ho spesso file di intestazione solo per un singolo enum o typedef e arrivo persino ad avere una configurazione di build speciale che costruisce senza intestazioni precompilate e (dato che lavoro con Visual Studio) uso #pragma hdrstop per definire le intestazioni precompilate piuttosto che avere ogni file è necessario includere un file comune per questo scopo.

Nel corso degli anni ho trovato che funziona molto bene a mantenere i tempi di compilazione e consente di spostare il codice (nelle librerie o in altri progetti) o costruito per i cablaggi di test.

Vedo le intestazioni comuni come accoppiamenti non necessari che devono essere rimossi e, per essere onesti, un segno di pigrizia e mancanza di attenzione ai dettagli.