Se I # include un file, devo avere un percorso valido per qualsiasi intestazione # incluso nel file incluso [chiuso]

Question

Se I # include un file, devo avere un percorso valido per qualsiasi intestazione # incluso nel file incluso [chiuso]

#1 da (1 voti)
#2 da (1 voti)

-1

Ad esempio, se ho creato una libreria, libcommon, che utilizza un'altra libreria personalizzata, ma ampiamente utilizzata in un campo specifico (some_other), come questa:

libcommon.h

#ifndef LIBCOMMON_H
#define LIBCOMMON_H

#include "some_other.h"

void do_something1();
void do_something2();

#endif  /* LIBCOMMON_H */

Quindi se voglio usare la libreria, e ho qualcosa di simile nel mio main.c

#include "libcommon.h"

int main() {
    do_something1();
    do_something2();
}

Poi nel mio progetto ottengo

fatal error C1083: Cannot open include file: 'some_other.h': No such file or directory.

Ora posso risolvere questo problema fornendo il percorso di inclusione a some_other.h nel mio progetto, ma preferirei rendere la vita più facile agli utenti di libcommon. Come faccio?

Suppongo di dover essere sicuro di non utilizzare alcun tipo o funzione definita in some_other.h perché funzioni correttamente? È un approccio comune? O è abbastanza spesso il caso che per esempio una libreria di helper che usa un'altra libreria standard, la stessa libreria some_other, quindi rendere l'utente del set di lib include percorsi per alcuni_altri header è ok?

Sto cercando di avere un'idea di come altre persone risolvono questo problema e i buoni approcci.

c coding-standards headers

posta user619818 10.06.2015 - 18:03

fonte

2 risposte

1

Sì, il compilatore deve essere in grado di raggiungere tutti i file referenziati nel progetto, comprese le intestazioni per altri moduli che puoi usare.

Ci sono 2 tecniche per ottenere questo:

specifica un percorso Include al compilatore, passando in INCLUDE = istruzioni di stile sulla riga di comando / makefile per ogni directory che contiene intestazioni rilevanti.
copia tutte le intestazioni in una singola directory 'include' e fai riferimento a quella.

Quale preferisci usare dipende dal tuo sistema di costruzione e dalle tue preferenze. Io uso un mix di questi, tipicamente copiando tutti i miei file header in una singola directory come parte dei passi di compilazione (proprio come copio binari o librerie in una directory comune una volta che sono compilati) ma fai riferimento esplicitamente al modulo di terze parti.

risposta data 10.06.2015 - 18:30

fonte

Leggi altre domande sui tag c coding-standards headers

sviluppo di un'applicazione DESKTOP basata su GUI multipiattaforma con HTML5 / CSS [chiuso] Permutare e combinare i valori in base alla chiave

score 1 · Accepted Answer

Se libcommon.h non può essere compilato senza some_other.h, allora chiunque desideri compilare una chiamata a doSomething1 () deve avere #include some_other.h così come libcommon.h, altrimenti il compilatore semplicemente non ha abbastanza informazioni per fare il suo lavoro Non c'è un modo magico intorno a questo. Come altri hanno sottolineato, quando questa dipendenza è corretta di solito fai qualcosa come impostare i tuoi strumenti di costruzione per guardare tutti i file .h in una speciale directory "include" in modo da non doverli elencare singolarmente sulla riga di comando .

La vera domanda che dovresti porci è se libcommon.h ha bisogno di per dipendere da some_other.h, o se è solo libcommon.c a preoccuparsi di cosa c'è in some_other.h. Una firma di funzione come void do_something1() non richiede alcuna informazione speciale da compilare, quindi nel tuo esempio di giocattolo dovresti essere in grado di spostare semplicemente l'istruzione #include "some_other.h" nel file .c. Se le tue firme di funzioni reali si basano su definizioni di tipo in some_other.h, potresti essere sfortunato, o questo potrebbe essere un motivo per prendere in considerazione la modifica di tali firme di funzioni.

Si noti che tutti gli utenti di libcommon devono ancora collegarsi al codice oggetto di some_other al momento del collegamento, a prescindere da cosa, ma a causa di come funziona il collegamento statico, è probabile che libcommon.o includa il codice oggetto some_other, quindi potrebbe non esserci qualsiasi disturbo equivalente lì. Se hai bisogno di ulteriore aiuto con il materiale di collegamento, questa dovrebbe essere una domanda a parte.