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: Thu, 13 Oct 2005 20:19:19 +0200
On 13.10.2005, at 18:27, John Weeks wrote:
Thanks to those who tried my code and reported that it compiles. As I
said
earlier, I should have tried the test myself.
Encouraged by the knowledge that the code was OK, I tried moving the
reduced function created by Ulrich to various locations within the
list if
#includes in the file and discovered that there is a conflict with an
included file. I have not had time yet to track down what the problem
is
with the included file.
Not sure, which conflicts you mean here. But there are often people
having trouble with the include mechanism in Xcode.
Just a few words:
If you put a header file into the project, Xcode locates it and puts
its location in a socalled header-map-file. Wen compiling, this
header-map-file will be passed to the compiler so that the compiler can
locate headers which are put into the project. Thus, you need not to
provide a header search path for these headers.
However note, that this header-map-file will be searched for headers
*before* otherwise specified header search paths and system paths. So,
if you name a header file String.h, and put it in your project, the
compiler will not find the system header string.h, firstly because
filenames are not case-sensitive and secondly because there is a path
to String.h through the header map file which will be searched first.
(There is a build-setting which tweaks the behavior a bit, though)
Furthermore, if you include a header which is not also part of the
project, you need to provide a header search path, unless this is
located in a system path (e.g. usr/include and such, which are already
implicitly set ).
Also note that headers are inherently ambiguous. If your translation
unit happenly includes headers with the same name, a conflict may arise
which sometimes can not be resolved (except you rename one header file
and/or change a lot of include directives, which is not possible if you
do not own the sources).
Then, even if your compiler would locate your headers in its correct
places, the guard macro might conflict with an already included file in
another location, so that this header's content will be skipped
(without noticing you!).
There also may be a conflict with macros, which often cause
non-obvious, weird and sometimes hard to track errors.
This brings up two thoughts:
1) It is peculiar that Codewarrior doesn't suffer this same conflict.
A conflict may arise or diminish, just after reordering header-search
paths, or having different system headers, or ... many other reasons.
2) C++ with templates encourages putting lots of actual code in .h (or
.hpp) files that are included in other source code. That seems like it
would also encourage conflicts like the one I now need to track down.
Does anyone want to offer advice on how to manage such code to minimize
this problem? I am just getting into heavy template programming, so I
don't
have experience to guide me.
Use namespaces, avoid using namespace xxx declarations, especially std.
Heavily structure your project into several sub folders (as an example,
take a look at boost (www.boost.org) to get an idea how to accomplish
this).
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.
Use
#include "MyFoo.h"
when appropriate - means, if - and only if the header file is in the
same folder than the including file)
I also would like to suggest to use guard macros in this way:
// File: MyProject/Bar/string.h
#ifndef MYPROJECT_BAR_STRING_H
#define MYPROJECT_BAR_STRING_H
...
#endif
If macros are unavoidable, prefix them e.g. with MYPROJECT_
use a toplevel namespace for all your names, e.g. myproj
Hope this helps.
Regards
Andreas
Regards,
John Weeks
WaveMetrics, Inc.
Phone (503) 620-3001
Fax (503) 620-6754
email 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