# include i file in .h o .cpp

3

Attualmente sto creando un progetto che utilizzava molte dichiarazioni avanzate e così ho trovato un problema in cui il mio #include sembra essere estremamente ridondante.

Esempio:

config.h

#include <Windows.h>
#include <vector>

config.cpp

#include "config.h"
#include "resolve.h"
#include <Windows.h>
#include <vector>
//functions that use extern functions/variables.

resolve.cpp

#include "config.h"
#include "resolve.h"
#include <iostream>
#include <Windows.h>
#include <winternl.h>
#include <TlHelp32.h>
//functions that use extern functions/variables.

main.cpp

#include "config.h"
#include "resolve.h"
#include <iostream>
//functions that use extern functions/variables.

Sarebbe meglio per me fare qualcosa come fluire, quindi non ci sono #inclusi duplicati per qualcosa di simile?

config.h

#include <vector>
#include <iostream>
#include <Windows.h>
#include <winternl.h>
#include <TlHelp32.h>
//declarations for config.cpp

resolve.h

#include "config.h"
//declarations for resolve.cpp

config.cpp

#include "resolve.h"

resolve.cpp

#include "resolve.h"

main.cpp

#include "resolve.h"

Quindi in questo modo tutto ha già le intestazioni di cui hanno bisogno + le dichiarazioni in avanti?

    
posta EndingLegacy 21.09.2016 - 06:20
fonte

2 risposte

8

Normalmente la migliore pratica è che ogni file includa tutti i file di intestazione richiesti, ignorando le direttive #include nei file inclusi. Ogni file di intestazione dovrebbe quindi avere un costrutto come questo in modo che i contenuti siano inclusi solo una volta:

#ifndef _HEADER_FILE_NAME_H
#define _HEADER_FILE_NAME_H

.... header file contents

#endif

Questo si occupa della ridondanza assicurando che i contenuti vengano inclusi solo una volta, la prima volta che il file viene incluso. Le inclusioni successive salteranno il contenuto perché il simbolo di guardia è stato definito durante la prima inclusione.

    
risposta data 21.09.2016 - 06:44
fonte
0

Una volta che hai adottato #include guards o #pragma once come proposto da Todd Knarr nell'altra risposta, le ridondanti includono tecnicamente non sono più un problema.

Tuttavia, la tua domanda rimarrà comunque: le intestazioni dovrebbero essere incluse esplicitamente ovunque siano potenzialmente necessarie? O dovrebbero essere nidificati uno in un altro, come matriochka dolls , al fine di ridurre il numero di include?

Crea intestazioni autarchiche

Se hai bisogno di un risolutore, includi solo resolve.h . Non dovresti preoccuparti di quali altre intestazioni ti occorressero per farlo funzionare.

Quindi se la dichiarazione in resolve.h dipenderà in qualche modo da config.h , includila nella prima intestazione. L'enorme vantaggio è che se un giorno rifatti il risolutore e ti sbarazzi della sua dipendenza a config.h , o se al contrario aggiungerai una nuova dipendenza a resolve_base.h , cambieresti semplicemente un colpo di testa: un ottimo esempio di separazione delle preoccupazioni.

Rafforza l'incapsulamento e mantiene l'accoppiamento al minimo

È possibile che resolve.cpp necessiti di include aggiuntivi, ad esempio windows.h o iostream perché l'implementazione dipende da altre unità di compilazione. Se questi inclusi non sono richiesti da resolve.h sono un dettaglio di implementazione: non creare accoppiamenti non necessari; non includerli lì: gli utenti di resolve.h non hanno bisogno di conoscere queste dipendenze. Includili solo in resolve.cpp . Questo ti dà la flessibilità per cambiare l'implementazione, senza dover propagare le modifiche che non dovrebbero influenzare altri moduli.

Convenienza e velocità

Alcuni sono inclusi in molte unità di compilazione. Potrebbe quindi essere un approccio pragmatico includere questi in un'intestazione comune che verrà quindi inclusa in tutti i file di implementazione:

  • meno dipendenze esplicite
  • ma parecchio digitando meno (ed evitando il messaggio di errore causato dalle intestazioni dimenticate).

Questo può essere ulteriormente giustificato se il compilatore utilizza intestazioni precompilate (ad esempio stdafx.h con MSVC).

Lettura adattiva

risposta data 22.09.2016 - 01:13
fonte

Leggi altre domande sui tag