<string.h> in conflitto con il mio String.h

Question

Ho un progetto che stava compilando ok in g ++ (non riesco a vedere la versione in questo momento) e ora su xCode non lo è.
Penso di avere il problema ora ... Ho un file String.h nel mio progetto e sembra che il compilatore xCode (che è gcc) stia cercando di aggiungere il mio file di stringa dal cripting <> .. . non sono sicuro di questo, ma dare un'occhiata a questa immagine
http://www.jode.com.br/Joe/xCode1.png

da quello che sembra, è compreso il mio posto del file system, mi chiedevo ... non dovrebbe #include < file> essere incluso nel sistema? a causa dello <>? e il sistema non dovrebbe includere un file all'interno del proprio percorso e non il percorso originale della mia applicazione?
Come ho detto, non sono sicuro se questo è ciò che accade perché sto solo migrando a OSX in questi ultimi 2 giorni ...
Stavo per cambiare la mia classe e il nome del file in modo che non fosse in conflitto, quindi funzionerebbe, se questo è davvero il problema, ma mi stavo chiedendo, dovrebbe esserci un altro modo per farlo, perché ora il mio progetto non è così grande da poterlo fare in un certo tempo, ma se il progetto fosse più grande? sarebbe malapena sufficiente a cambiare tutto comprende e nomi di classe ...

Ogni aiuto è apprezzato

Grazie,
Jonathan

Answer 1

Naming le intestazioni con lo stesso nome di intestazioni standard come stringa.h e includerli semplicemente con #include <String.h> è un problema (la differenza nell'involucro non fa alcuna differenza su alcune piattaforme).

Come hai detto, tuttavia, sarebbe difficile provare a capire cosa sono in anticipo quando si assegnano le intestazioni. Così, il modo più semplice per farlo è quello di impostare per impostare il percorso di inclusione di un livello di directory al di fuori di un sub-directory in cui risiedono le intestazioni, es:

#include <Jonathan/String.h> 

Ora non c'è bisogno di preoccuparsi se il nome del file String.h è in conflitto con qualcosa in una delle librerie che si sta utilizzando a meno che non includa anche <Jonathan/String.h> che è improbabile. Tutte le librerie decenti di terze parti fanno altrettanto. Ad esempio, non includiamo lo <function.hpp> in boost, ma includiamo lo <boost/function.hpp>. Lo stesso con GL/GL.h invece di semplicemente GL.h. Questa pratica evita i conflitti per la maggior parte e non è necessario aggirare i problemi rinominando String.h in qualcosa come Text.h.

Answer 2

su OSX il filesystem è case insensitive - così string.h si può vento con conflitti del genere. String.h == string.h

Answer 3

Sì, se si utilizza

#include "file" 

la directory locale è guardato prima e

#include <file> 

solo il sistema includono le cartelle sono guardati.

Si noti la parola prima solo nel primo caso. Ciò significa che ogni volta che viene inclusa la versione locale non dovrebbe mai essere raggiunta (a meno che non sia stato incluso il percorso di origine all'interno della direttiva INCLUDE).

Detto questo, il mio suggerimento è quello di manichino rinominare il file locale con un nome univoco ...

Answer 4

ha funzionato cambiando il nome da string.h a Text.h

ma che non ha senso , poiché la libreria std include il proprio string.h e non il mio.
Voglio dire, non ha senso che uno sviluppatore crei i suoi file pensando a quali nomi non può usare, per un'istanza, diciamo che cambio il mio String.h in Text.h (l'ho già fatto, ho bisogno di lavorare e questo non mi sta lasciando) in qualche modo ho dovuto includere un'altra libreria basata su modelli che ha una inclusione chiamata Text.h, dovrei cambiare di nuovo il mio text.h o non usare questa nuova libreria? ci dovrebbe essere un'alternativa.
O non dovrebbe?

grazie per l'aiuto finora,
Jonathan

Answer 5

due cose che si sta eseguendo in:

1. Come notato sopra, il file system su Mac OS è a meno che non specificamente configurato il filesystem di essere sensibili e minuscole maiuscole e minuscole.
2. gcc non distingue molto tra i percorsi di inclusione dell'intestazione locale e di sistema. Quando si specifica una directory da aggiungere al percorso tramite -I, tale directory verrà utilizzata per individuare sia gli accessi locali che di sistema. Solo quando si utilizza -iquote o -I- viene saltata una directory per l'inclusione dei system include. Inoltre, le "directory di sistema incluse" incorporate nel percorso di ricerca del compilatore sono sempre ricercate per include locali da.
   • Si noti che la directory corrente viene utilizzata per locali ma non include il sistema. In questo caso, credo che stia raccogliendo String.h perché le impostazioni del progetto aggiungono esplicitamente la directory di progetto di livello superiore al percorso di inclusione.

La soluzione Vorrei suggerire, invece di rinominare il include, è quello di mettere la vostra utilità in una cartella il cui nome è unico per il progetto, e specificare la directory nella direttiva include. Per esempio:

#include "Josk/String.h" 

e assicurarsi Josk/ sé non è nel vostro percorso di inclusione di ricerca. In questo modo non sei bloccato con un rinominato scomodo, anche se potresti dover mescolare alcuni file nel tuo progetto. Potrebbe inoltre essere necessario modificare le impostazioni del progetto per assicurarsi che la directory principale di tale directory di utilità si trovi nel percorso di inclusione.

Un'altra possibilità da provare è, se si vede la directory di progetto di livello superiore aggiunta al percorso di inclusione del progetto, rimuoverla. Questo dovrebbe mantenere gli elementi nella directory di progetto di livello superiore dalla ricerca di include di sistema.

Infine, potresti anche essere in grado di evitare questo problema in questo caso specifico modificando la distinzione tra maiuscole e minuscole del tuo file system. Tuttavia, questo può rompere alcune applicazioni Mac, quindi cerca il problema prima di intraprenderlo o scegli un volume che nessun altro utilizza.

Answer 6

ho avuto lo stesso problema ed era difficile da risolvere. ho impiegato le mie ore per sistemare/scoprire. il problema è la sigla di xcode.e la soluzione - oltre ad evitare questo tipo di nomi riservati, che è una buona idea, in generale, ma non sempre possibile con librerie di terze parti - è quello di aggiungere

USE_HEADERMAP = NO 

alle impostazioni definite dall'utente.

complimenti a questi ragazzi: http://meidell.dk/archives/2010/05/08/xcode-header-map-files/ http://www.cocoabuilder.com/archive/xcode/262586-header-file-problem-sorry-to-bug-this-list.html