<string.h> en conflicto con mi propio String.h

Question

Tengo un proyecto que estaba compilando bien dentro de g ++ (no puedo ver la versión ahora) y ahora en xCode no lo está.
Creo que tengo el problema ahora ... Tengo un archivo String.h en mi proyecto y parece que el compilador xCode (es decir, gcc) está intentando agregar mi propio archivo de cadena desde < cstring> .. . no estoy seguro de ello, pero echar un vistazo a esta imagen
http://www.jode.com.br/Joe/xCode1.png

de lo que parece, se está incluyendo mi propio lugar del archivo del sistema, me preguntaba ... no debe # include < file> ser un sistema incluido? debido a <>? ¿y el sistema no debería incluir un archivo dentro de su propia ruta y no la ruta original de mi aplicación?
Como dije, no estoy seguro de si esto es lo que sucede porque estoy migrando a osx estos últimos 2 días ...
Iba a cambiar mi clase y nombre de archivo para que no entrara en conflicto, así que funcionaría, si este es realmente el problema, pero me preguntaba, debería haber otra forma de hacerlo, porque ahora mi proyecto no es tan grande, así que puedo hacerlo en algún momento, pero ¿y si el proyecto fuera más grande? sería dificil de cambiar todo incluye y nombres de clase ...

Cualquier ayuda se agradece

Gracias,
Jonathan

Answer 1

Naming sus cabeceras con el mismo nombre que las cabeceras estándar como cadena.h e incluirlos simplemente con #include <String.h> es un problema (la diferencia en la carcasa no hace ninguna diferencia en algunas plataformas).

Como dijiste, sin embargo, sería difícil tratar de averiguar qué están por adelantado al nombrar tus encabezados. Por lo tanto, la manera más fácil de hacer esto es configurar para establecer su ruta de inclusión de un nivel de directorio fuera de un sub-directorio en el que residen sus cabeceras, por ejemplo:

#include <Jonathan/String.h> 

Ahora usted no tiene que preocuparse acerca de si el nombre de archivo String.h entra en conflicto con algo en uno de las bibliotecas que está utilizando, a menos que también incluyan <Jonathan/String.h>, lo que es poco probable. Todas las bibliotecas decentes de terceros hacen esto también. No incluimos <function.hpp> en boost, por ejemplo, sino que incluye <boost/function.hpp>. Lo mismo con GL/GL.h en lugar de simplemente GL.h. Esta práctica evita conflictos en su mayor parte y no tiene que evitar los problemas al renombrar String.h a algo similar a Text.h.

Answer 2

en OSX el sistema de archivos es sensible a mayúsculas - por lo que se puede enrollar string.h hasta con conflictos como ese. String.h == string.h

Answer 3

Sí, si se utiliza

#include "file" 

el directorio local se veía primero y

#include <file> 

sólo el sistema incluye carpetas se miraron.

Observe la palabra primero solo en el primer caso. Esto significa que cada vez que se incluye su versión local nunca se debe alcanzar (a menos que haya incluido su ruta de origen dentro de la directiva INCLUDE).

Dicho esto, mi sugerencia es ficticia para cambiar el nombre del archivo local con un nombre inequívoco ...

Answer 4

funcionó cambiando el nombre de string.h a Text.h

pero eso no tiene sentido , ya que la biblioteca estándar incluye su propia cadena.h y no la mía.
Quiero decir, no tiene sentido que un desarrollador cree sus archivos pensando en los nombres que no puede usar, por ejemplo, digamos que cambio mi String.h a Text.h (ya lo hice, tengo que trabajar y esto no me deja) de alguna manera tuve que incluir otra biblioteca con plantillas que tiene un include llamado Text.h, ¿tendría que cambiar mi texto de nuevo o no usar esta nueva biblioteca? debería haber una alternativa.
¿O no debería?

gracias por la ayuda hasta el momento,
Jonathan

Answer 5

Dos cosas que está ejecutando en:

1. Como se señaló anteriormente, el sistema de archivos en Mac OS es sensible a las mayúsculas a menos que establezca específicamente su sistema de archivos para ser mayúsculas y minúsculas.
2. gcc no distingue demasiado entre las rutas de acceso del encabezado local y del sistema. Cuando especifica un directorio que se agregará a la ruta a través de -I, ese directorio se usará para ubicar las inclusiones locales y del sistema. Solo cuando usa -libra o -I- se omite un directorio para ubicar el sistema incluye. Además, los directorios integrados "system include" en la ruta de búsqueda del compilador son siempre buscado local includes.
   • Tenga en cuenta que el directorio actual se utiliza para local, pero no incluye el sistema. En este caso, creo que está recogiendo String.h porque la configuración del proyecto agrega explícitamente el directorio del proyecto de nivel superior a la ruta de inclusión.

La solución que sugeriría, en lugar de cambiar el nombre incluye, es poner sus utilidades en un directorio cuyo nombre es único para su proyecto, y especificar que el directorio en su directiva include. Por ejemplo:

#include "Josk/String.h" 

y asegúrese Josk/ sí no está en su ruta de búsqueda. De esta forma, no se verá afectado por un cambio de nombre incómodo, aunque es posible que deba barajar algunos archivos en su proyecto. Es posible que también necesite editar la configuración de su proyecto para asegurarse de que el directorio principal de ese directorio de utilidades esté en su ruta de inclusión.

Otra posibilidad para probar es, si ve el directorio del proyecto de nivel superior agregado a la ruta de inclusión de su proyecto, elimínelo. Esto debería evitar que los elementos de su directorio de proyecto de nivel superior sean buscados para el sistema.

Finalmente, también puede evitar este problema en este caso específico cambiando la sensibilidad de mayúsculas y minúsculas de su sistema de archivos. Sin embargo, esto puede romper algunas aplicaciones de Mac, así que investigue el problema antes de embarcarse en esto, o elija un volumen que no use nada más.

Answer 6

tuve el mismo problema y fue difícil de resolver. Me tomó horas arreglar/averiguar. el problema es el encabezado de xcode.y la solución - además de evitar ese tipo de nombres reservados, que es una buena idea en general, pero no siempre es posible con bibliotecas de terceros - es agregar

USE_HEADERMAP = NO 

a sus ajustes definidos por el usuario.

felicitaciones a estos chicos: 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