Se sto creando una classe con piccole funzioni che non fanno molto, è accettabile semplicemente inserirle tutte nel file di intestazione? Quindi, per una particolare classe, è solo il .h senza .cpp ad andare con esso.(C++) Tutta la classe nel file .h?
Sì, è accettabile. Compilerà sicuramente. Ma anche, se rende l'organizzazione del codice più pulita, allora può andare bene. La maggior parte delle definizioni di template sono già così per necessità, quindi non stai facendo nulla di insolito. Ci possono essere alcuni inconvenienti di quella classe si basa su altre classi però. Se si finisce per dover includere l'intera definizione in altri file che utilizzano la classe, potrebbe verificarsi un ulteriore tempo di compilazione rispetto alla sola dichiarazione di una breve lezione.
È possibile misurare i tempi di compilazione se questo sembra essere un problema reale.
Se è possibile ottenere una copia, The c++ Programming Language (e molti altri libri) hanno una sezione dettagliata sull'organizzazione del codice sorgente e i vantaggi specifici della separazione del codice nei file .h e .cpp.
Sì, è accettabile. Inoltre, se si creano modelli e non si dispone di un compilatore con il supporto export, non si ha scelta.
Tuttavia, si noti che può aumentare le dipendenze e quindi rallentare la compilazione.
Sarebbe perfetto se si usasse quel file di intestazione nei futuri codici o progetti e se si desidera condividerlo con gli altri.
Dipende da come si sta collegando. Per evitare di dover vedere messaggi come la ridefinizione di blah, la precedente definizione nel file blah.h sulla riga 13 ha appena messo tutto tranne la dichiarazione in un file .cpp.
Dipende da cosa si sta puntando.
Per un progetto per animali domestici, è accettabile, ma poi tutto è veramente.
Per un vero e proprio progetto, è necessario porsi una serie di domande:
Se le risposte ti soddisfano, quindi vai avanti.
Si tratta principalmente di gestione delle dipendenze. Inserendo la definizione dei metodi all'interno dell'intestazione, è probabile che vengano richiamati dal compilatore, il che significa che ogni volta che cambiano dovrai ricompilare tutto ciò che dipende da questa classe.
I modelli lo fanno, tuttavia i modelli generalmente hanno poche dipendenze (altri include) e sei relativamente obbligato a procedere in questo modo (anche se puoi esternalizzare il codice dipendente da un modello per ridurre le dipendenze).
Per i veri e propri grandi progetti in cui la gestione delle dipendenze è il primo, allora sconsiglierei. In questi progetti un ABI stabile e la capacità di promuovere modifiche compatibili binarie sono salvavita in caso di problemi e valgono il "lieve" inconveniente per lo sviluppatore.
In ogni caso, non definire i metodi nel mezzo della classe. Anche in linea puoi definirli dopo la dichiarazione della classe. Questo rende più facile per le persone leggerlo (te stesso in pochi mesi) per capire rapidamente l'interfaccia.
IMO, se i metodi sono principalmente one-liner, la definizione del metodo all'interno della classe non distrae molto e talvolta aumenta la comprensibilità del codice; e infatti l'unico motivo per cui qualcuno non vorrebbe creare un file .cpp separato è perché la classe è piccola ei metodi sono tutti banali. –
@Lie Ryan: Sono d'accordo che le one-liner (come 'empty' /' size') possono essere definite nel mezzo della classe senza disturbarne troppo ... ma poi è difficile definire il limite tra un one-liner Fodera, una fodera che è avvolta perché non si adatta allo schermo, una doppia fodera che è più corta della fodera avvolta, ... Dopo di che, tutti chiamano. –
Ma non è necessario definire un limite rigido, basta seguire i tuoi sentimenti istintivi. Alla fine, il compilatore produrrebbe comunque lo stesso output o equivalente. Molte guide allo stile di programmazione promuovono uno stile coerente solo perché la coerenza è facile da quantificare, se qualcosa sembra sempre la stessa allora è coerente; tuttavia, in molti casi, questa ossessione per la coerenza ha il costo di ignorare potenziali benefici difficili da quantificare. La leggibilità e Comprensione non è così facile da quantificare; e come risultato, ottengono spesso linee guida sullo stile. –