Re: RFC: change in policy for include guards

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
Received on Tue Feb 11 2014 - 22:53:21 MST