Re: type/value mismatch error in template
Re: type/value mismatch error in template
- Subject: Re: type/value mismatch error in template
- From: Andreas Grosam <email@hidden>
- Date: Fri, 14 Oct 2005 14:41:46 +0200
On 14.10.2005, at 10:19, Ulrich Frotscher wrote:
On 13.10.2005, at 20:25, Andreas Grosam wrote:
Try to use unique names for headers,
*ensure* unique names for guard macros,
prefere to use "qualified include headers":
#include <Bar/string.h>
assuming you have a header search path set to /my/path/to/MyProject
where a sub folder Bar exists where your own header file string.h is
located. The more "qualified" the include directive the better - it's
pretty unlikely that Bar/string.h exists in any other header search
path.
Thanks to the good explanation of the header search mechanism, that
explains a lot of trouble I have had with includ paths in Xcode as
well. I have found that the only reliable way of fixing all the header
search issues is to make sure that no header file that is part of the
projects has the same name as any of the std header. Another soultion
is not to put the header files into the project, because in this case
it will not be listed in the header-map-file as described by Andreas.
I wouldn't do this. Put *all* your own headers into the project (for
several other reasons).
There is another way to get rid of the troubles, possibly:
Firstly, you need to know that projects search paths have precedence
over system search paths.
So - regardless of having header maps - if you have a local file
String.h, and also specified a header search path in your project so
that this header can be located from within a file:
#include <String.h>
then you *never* can include the system header string.h, say
#include <String.h>
#include <string.h> // does not include string.h, but String.h!!
The general solution to this problem is to use:
#include "String.h"
#include <string.h>
and *NOT* providing a header search path which may find a file String.h
through #include <string.h>
The #include "String.h" will work *only* if the String.h file is
located in the same folder than the including file.
This was the standard way how it worked for years - but now comes Xcode:
Xcode uses a so-called header-map. Essentially, these are header-search
paths, which have precedence over project search path and system search
paths (in that order). The header map contains the search paths for
header files put into the project.
*Not* defining a header search path for String.h does not help anymore,
since - if String.h is put into the project - the header-map implicitly
defines a search path. So the second method will not work anymore.
However, here is the help:
There is a build-setting named USE_SEPERATE_HEADERMAPS which changes
the behavior of the header-map mechanism:
Per default, the Apple-compiler (more precisely, the preprocessor)
searches headers included with
#include <String.h> or
#include "String.h"
using the header-map, in *both* cases.
If you set the value of this build setting to YES, the compiler only
searches in header-maps when using the
#include "String.h"
style directive.
Well assuming you have a local String.h, and set
USE_SEPARATE_HEADERMAPS = YES, and furthermore did not exlicitly
specify a search path to the location for yor local String.h, the
following include directives
#include "String.h"
#include <string.h>
would now work.
Well, having said this - I also have to say that I do not know the
internal details how header-map work exactly.
A directive like
#include "String.h"
should *always* bypass the header-map file in the first place. This
directive is meant to locate headers *relative* to their including file
- and exactly this should be done. Only after the file can not be
found, the other search paths should be applied.
I guees, this is also performed correctly in the Apple-compiler.
Even if you use qualified include directives like #include
"/MyStringLib/String.h" in your own sources you will probably have
problems because somewhere in the std headers an #include <string.h>
will be present which will be "resolved" by XCode to
/MyStringLib/String.h and end up with a nightmare of compiler errors.
XCode (and gcc) does not distinguish between "..." and <...> includes
and file name matching is not case sensitive.
Yup, the error still occures, since when Srting.h is in your project -
a search path to
/my/path/to/MyProject/MyStringLib/
might be defined in the header-map.
When there is anywhere a #include <string.h>
/my/path/to/MyProject/MyStringLib/String.h will be found. Bummer.
Note also that a #include <MyStringLib/String.h> will NOT be found,
unless you defined an explicit search path to /my/path/to/MyProject/.
That also means, when using qualified paths for project headers, this
renders header-maps pointless.
But qualified headers are commonly used to avoid header conflicts!
Define a USE_SEPARATE_HEADERMAPS in your target build settings (note,
there is no entry, per default) and set it to YES.
This should solve your problem.
see also: Xcode's Help -> Show Build Settings Notes
Really, dear Apple team, re-think the header maps please!
What about USE_HEADERMAPS = NO ??
It turned out that header-maps often cause more trouble than may help
the developr. Each action which is performed implicitly by a tool may
confuse an experienced programmer, who does normally care about these
things themself - and often needs more fine-grained control.
Now, since it is possible to specify recursively search paths,
header-maps become even more useless.
Instead of defining implicit search paths based on the location of
project headers, XCode should rather only make *suggestions* when
editing the header search paths in the build settings pane.
In my experience, i have to specify only one or two header search path
per target which point to my own headers. Furthermore, header maps do
not help in locating headers of third party libs anyway. So, if i link
to third party libraries - I have to specify the header search path to
them anyways.
Regards
Andreas
Ulrich
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden