[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Getting rid of non-existant errors, question about recognition of C++ standard things.
|
Am 21.12.2013 01:51, schrieb Nathan Ridge:
--- From n337 C++11 ---
Note: Although an implementation may provide a mechanism for making
arbitrary source files available to
the <> search, in general programmers should use the <> form for
headers provided with the implementation,
and the " " form for sources outside the control of the implementation.
---
Interesting, I didn't know that.
I know, that's why I started that discussion regarding the wx/* headers,
since they are not part of an C or C++ implementation = compiler.
And I see that also very often.
A lot of libraries do not follow this convention, however. For example,
Boost headers include other Boost headers using the <> syntax.
Yes. Same as above. A lot of developers are not aware of that.
E.g. what happens if you have a library outside of the system include
search path, which on windows is very common.
If your compiler has no option to include to a system header path, you
get in trouble.
There was also some hints on the ##c @irc.freenode.net, system include
headers don't have to be there physically, the compiler could provide
them by other meanings.
Also, I'm not sure if other compilers do the same, but e.g. CodeWarrior
has strange header includes, that e.g. stdio.h includes cstdio and not
the other way around, and the prototypes are in cstdio
and not in stdio.h. I guess, that comes from the early era of C++, where
stdio.h was used and not cstdio defined.
A similar thing I'm afraid of is the support of the "#pragma once" which
is more and more used by developers instead of the common and everywhere
supported preprocessor include guards.
Not every compiler understands #pragma once, #pragma's are compiler
specific.
If we make changes to the way CDT does include resolution, we should
make sure not to break such libaries.
Regards,
Nate
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
