On 2014-02-12 11:26, Alex Rousskov wrote:
On 02/11/2014 04:48 AM, Kinkie wrote:
The topic I'm thinking of is the policy of autoconf-detecting some
system headers we use. While this is undoubtably good for C- and
system- headers, it doesn't make much sense for pure C++ headers,
which are very strongly defined by the standard and for which there is
no compatilibty wrapper. In these cases, making the include
conditional will only result in a less-readable error message when the
build eventually fails.
What do you think?
I agree that there is little point in guarding standard headers that
provide required classes that we do not provide a replacement for.
IIRC,
I have not been adding _new_ guards for such header files for a while.
Deciding which headers qualify may get a little tricky sometimes, but
the danger is small, and most cases like <set> and <vector> are
probably
clear.
Cheers,
Alex.
These provide some very useful info:
http://stackoverflow.com/questions/2027991/list-of-standard-header-files-in-c-and-c
http://www.cplusplus.com/reference/
I would draw the line at ANSI C-style and C++ headers.
Proposal:
* system C headers (with a .h suffix):
- always include with <>
- mandatory HAVE_FOO_H wrapper
- avoid where C++ alternative is available
* system C++ headers (without any extension suffix):
- always include with <>
- omit any HAVE_ wrapper
- if the file is not portable, do not use it
* custom headers provided by Squid:
- omit wrappers
- always include with ""
- use full path (only src/ prefix may be omitted)
Also, for now restricting ourselves to the C++98 set of headers since we
have not made C++11 support mandatory yet.
Amos
