<string.h> conflicting with my own String.h

Asked 2010-06-26T18:43:28.700

I have a project that was compiling ok within g++(I can't see the version right now) and now on xCode it is not.
I think that I got the problem now... I have a String.h file in my project and it seems tha the xCode compiler(that is gcc) is trying to add my own string file from the < cstring >... I am not sure of it, but take a look at this picture
http://www.jode.com.br/Joe/xCode1.png

from what it looks like, it is including my own instead of the system file, I was wondering... shouldn't #include < file > be a system include? because of the < > ? and shouldn't the system include a file within its own path and not the original path of my application?
As I said, I am not sure if this is what happening because I am just migrating to osx these past 2 days...
I was going to change my class and file name to not conflict, so it would work, if this is really the problem, but I was wondering, there should be another way to do this, because now my project isn't that big so I can do this in some time, but what if the project was bigger? it would be dificult to change all includes and class names...

Any help is appreciated

Thanks,
Jonathan

Edit Report

3 Answers

Naming your headers with the same name as standard headers like string.h and including them simply with #include <String.h> is asking for trouble (the difference in casing makes no difference on some platforms).

As you said, however, it would be difficult to try to figure out what those are in advance when naming your headers. Thus, the easiest way to do this is to set to set your include path one directory level outside of a sub-directory in which your headers reside, ex:

#include <Jonathan/String.h>

Now you don't have to worry about whether the String.h file name conflicts with something in one the libraries you are using unless they happen to also be including <Jonathan/String.h> which is unlikely. All decent third-party libraries do this as well. We don't include <function.hpp> in boost, for instance, but instead include <boost/function.hpp>. Same with GL/GL.h instead of simply GL.h. This practice avoids conflicts for the most part and you don't have to work around problems by renaming String.h to something like Text.h.

answered 2010-06-27T05:23:12.907

Yes, if you use

#include "file"

the local directory is looked first and

#include <file>

only the system include folders are looked.

Notice the word first only in the first case. This means that every time is included your local version should never be reached (unless you have included your source path within the INCLUDE directive).

Said that, my dummy suggestion is to rename your local file with an unambiguous name...

answered 2010-06-26T18:55:16.550

it worked by changing the name from String.h to Text.h

but that makes no sense, since the std library is including it's own string.h and not mine.
I mean, makes no sense for a developer to create his files thinking of what names he can't use, for an instance, lets say I change my String.h to Text.h(I already did, I need to work and this is not letting me) ad somehow I had to include another templated library that has a include called Text.h, would I have to change my text.h again or not use this new library? there should be an alternative.
Or shouldn't it?

thanks for the help so far,
Jonathan

answered 2010-06-26T22:47:32.513

<string.h> conflicting with my own String.h

3 Answers

Your Answer