Proposal: move towards #pragma and away from #include guards

[Alex Clemmer <cl...@gmail.com>]

Hey folks.

In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
brought up the issue of moving away from #include guards and towards
`#pragma once`.

As this has been brought up before, I will be brief: we think it's
revisiting because the primary objection in previous threads appears
to be that, though `#pragma once` is a cleaner solution to the
multiple-include problem, it's not so much better that it's worth the
code churn. However, the ongoing Windows integration work means we
have to touch these files anyway, so if we agree this is cleaner and
desirable, then this is an opportunity to obtain that additional code
clarity, without the cost of the churn.

For the remainder of the email, I will summarize the history of our
discussion of this issue, who will do the work, and what the next
steps are.

PROPOSAL: We propose that all new code use `#pragma once` instead of
#include guards; for existing files, we propose that you change
#include guards when you touch them.

HISTORY: This has been discussed before, most recently a year ago on
the mailing list[2]. There is a relevant JIRA[3] and discarded
review[4] that changes style guide's recommendation on the matter.

SUMMARIZED OBJECTIONS:
1. The Google style guide explicitly forbids `#pragma once`.
2. This results in a lot of code churn, but is only marginally better.
3. It's not C++ standardized/it's platform dependent/IBM's compiler
doesn't support it.
4. Popular projects like Chrome don't do `#pragma once` because of
history clutter.
5. Intermediate state of inconsistency as we transition to `#pragma
once` from #include guards.

OUR RESPONSE:
Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
points out in a previous thread that the Google style guide was
canonized when `#pragma once` was Windows-only, and the guidance has
not changed since because of the history churn problem. As noted
above, we think the history churn problem is minimized by the fact
that it can be wrapped up into the Windows integration work.

For objection (3), the consensus seems to be that the vast majority of
compilers we care about (in particular, the ones supporting C++ 11) do
support it.

For objection (5) we believe the inconsistent state is likely to not
be long lived, as long as we commit to wrapping this work up into the
Windows integration work.

SUMMARIZED ADVANTAGES:
* Basically fool-proof. Communicates simply what its function is (you
include this file once). Semantically it is "the right tool for the
job".
* No need for namespacing conventions for #include guards.
* No conflicts with reserved identifiers[5].
* No internal conflicts between include guards in Stout, Process
library, and Mesos (this is one reason we need the namespacing
conventions)
* Reduces preprocessor definition clutter (we should rely on #define
as little as humanly possible).
* Optimized to be easy to read and reason about.

NEXT STEPS:
If we agree that this is the right thing to do, committers would ask
people to use `#pragma once` for new code when presented in code
reviews. For files that exist, I will take point on transitioning as
we complete the Windows integration work. I expect this work to
completely land before the new year.


Thanks,


[1] https://reviews.apache.org/r/39803/
[2] https://www.marc.info/?t=142540100400015&r=1&w=2
[3] https://issues.apache.org/jira/browse/MESOS-2211
[4] https://reviews.apache.org/r/30100/
[5] http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier


-- 
Alex

Theory is the first term in the Taylor series of practice. -- Thomas M
Cover (1992)

Re: Proposal: move towards #pragma and away from #include guards

[Alex Rukletsov <al...@mesosphere.com>]

+1 for #pragma and +1 for Bernd's suggestion.

I normally don't like mass updates because they make it harder to read the
commit history. However in this case all the changes will be located at the
top of the file and shouldn't influence readability of the history.

However, I would limit the scope of this update to the aforementioned
changes only. IMO, including something else, e.g. s/> >/>>/, will do more
harm than good.


On Thu, Nov 5, 2015 at 3:21 PM, haosdent <ha...@gmail.com> wrote:

> +1
>
> On Thu, Nov 5, 2015 at 7:58 PM, Bernd Mathiske <be...@mesosphere.io>
> wrote:
>
> > +1
> >
> > This site has a list of compilers that support #pragma once.
> >
> > https://en.wikipedia.org/wiki/Pragma_once#Portability
> >
> > Clang, MS V C++, GCC as of 3.4. from 2006. OK!
> >
> > (Too bad for Sun/Oracle Studio C++. But you can use GCC on Solaris,
> right?)
> >
> > We could tackle this change at the same time as correcting the copyright
> > notes, then we have the history clutter only once:
> >
> > https://issues.apache.org/jira/browse/MESOS-3581
> >
> > Any other projects of that nature that can be bundled?
> >
> > Bernd
> >
> > On Nov 5, 2015, at 6:36 AM, Alex Clemmer <cl...@gmail.com>
> > wrote:
> >
> > Hey folks.
> >
> > In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> > brought up the issue of moving away from #include guards and towards
> > `#pragma once`.
> >
> > As this has been brought up before, I will be brief: we think it's
> > revisiting because the primary objection in previous threads appears
> > to be that, though `#pragma once` is a cleaner solution to the
> > multiple-include problem, it's not so much better that it's worth the
> > code churn. However, the ongoing Windows integration work means we
> > have to touch these files anyway, so if we agree this is cleaner and
> > desirable, then this is an opportunity to obtain that additional code
> > clarity, without the cost of the churn.
> >
> > For the remainder of the email, I will summarize the history of our
> > discussion of this issue, who will do the work, and what the next
> > steps are.
> >
> > PROPOSAL: We propose that all new code use `#pragma once` instead of
> > #include guards; for existing files, we propose that you change
> > #include guards when you touch them.
> >
> > HISTORY: This has been discussed before, most recently a year ago on
> > the mailing list[2]. There is a relevant JIRA[3] and discarded
> > review[4] that changes style guide's recommendation on the matter.
> >
> > SUMMARIZED OBJECTIONS:
> > 1. The Google style guide explicitly forbids `#pragma once`.
> > 2. This results in a lot of code churn, but is only marginally better.
> > 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> > doesn't support it.
> > 4. Popular projects like Chrome don't do `#pragma once` because of
> > history clutter.
> > 5. Intermediate state of inconsistency as we transition to `#pragma
> > once` from #include guards.
> >
> > OUR RESPONSE:
> > Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
> > points out in a previous thread that the Google style guide was
> > canonized when `#pragma once` was Windows-only, and the guidance has
> > not changed since because of the history churn problem. As noted
> > above, we think the history churn problem is minimized by the fact
> > that it can be wrapped up into the Windows integration work.
> >
> > For objection (3), the consensus seems to be that the vast majority of
> > compilers we care about (in particular, the ones supporting C++ 11) do
> > support it.
> >
> > For objection (5) we believe the inconsistent state is likely to not
> > be long lived, as long as we commit to wrapping this work up into the
> > Windows integration work.
> >
> > SUMMARIZED ADVANTAGES:
> > * Basically fool-proof. Communicates simply what its function is (you
> > include this file once). Semantically it is "the right tool for the
> > job".
> > * No need for namespacing conventions for #include guards.
> > * No conflicts with reserved identifiers[5].
> > * No internal conflicts between include guards in Stout, Process
> > library, and Mesos (this is one reason we need the namespacing
> > conventions)
> > * Reduces preprocessor definition clutter (we should rely on #define
> > as little as humanly possible).
> > * Optimized to be easy to read and reason about.
> >
> > NEXT STEPS:
> > If we agree that this is the right thing to do, committers would ask
> > people to use `#pragma once` for new code when presented in code
> > reviews. For files that exist, I will take point on transitioning as
> > we complete the Windows integration work. I expect this work to
> > completely land before the new year.
> >
> >
> > Thanks,
> >
> >
> > [1] https://reviews.apache.org/r/39803/
> > [2] https://www.marc.info/?t=142540100400015&r=1&w=2
> > [3] https://issues.apache.org/jira/browse/MESOS-2211
> > [4] https://reviews.apache.org/r/30100/
> > [5]
> >
> http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
> >
> >
> > --
> > Alex
> >
> > Theory is the first term in the Taylor series of practice. -- Thomas M
> > Cover (1992)
> >
> >
> >
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Proposal: move towards #pragma and away from #include guards

[haosdent <ha...@gmail.com>]

+1

On Thu, Nov 5, 2015 at 7:58 PM, Bernd Mathiske <be...@mesosphere.io> wrote:

> +1
>
> This site has a list of compilers that support #pragma once.
>
> https://en.wikipedia.org/wiki/Pragma_once#Portability
>
> Clang, MS V C++, GCC as of 3.4. from 2006. OK!
>
> (Too bad for Sun/Oracle Studio C++. But you can use GCC on Solaris, right?)
>
> We could tackle this change at the same time as correcting the copyright
> notes, then we have the history clutter only once:
>
> https://issues.apache.org/jira/browse/MESOS-3581
>
> Any other projects of that nature that can be bundled?
>
> Bernd
>
> On Nov 5, 2015, at 6:36 AM, Alex Clemmer <cl...@gmail.com>
> wrote:
>
> Hey folks.
>
> In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> brought up the issue of moving away from #include guards and towards
> `#pragma once`.
>
> As this has been brought up before, I will be brief: we think it's
> revisiting because the primary objection in previous threads appears
> to be that, though `#pragma once` is a cleaner solution to the
> multiple-include problem, it's not so much better that it's worth the
> code churn. However, the ongoing Windows integration work means we
> have to touch these files anyway, so if we agree this is cleaner and
> desirable, then this is an opportunity to obtain that additional code
> clarity, without the cost of the churn.
>
> For the remainder of the email, I will summarize the history of our
> discussion of this issue, who will do the work, and what the next
> steps are.
>
> PROPOSAL: We propose that all new code use `#pragma once` instead of
> #include guards; for existing files, we propose that you change
> #include guards when you touch them.
>
> HISTORY: This has been discussed before, most recently a year ago on
> the mailing list[2]. There is a relevant JIRA[3] and discarded
> review[4] that changes style guide's recommendation on the matter.
>
> SUMMARIZED OBJECTIONS:
> 1. The Google style guide explicitly forbids `#pragma once`.
> 2. This results in a lot of code churn, but is only marginally better.
> 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> doesn't support it.
> 4. Popular projects like Chrome don't do `#pragma once` because of
> history clutter.
> 5. Intermediate state of inconsistency as we transition to `#pragma
> once` from #include guards.
>
> OUR RESPONSE:
> Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
> points out in a previous thread that the Google style guide was
> canonized when `#pragma once` was Windows-only, and the guidance has
> not changed since because of the history churn problem. As noted
> above, we think the history churn problem is minimized by the fact
> that it can be wrapped up into the Windows integration work.
>
> For objection (3), the consensus seems to be that the vast majority of
> compilers we care about (in particular, the ones supporting C++ 11) do
> support it.
>
> For objection (5) we believe the inconsistent state is likely to not
> be long lived, as long as we commit to wrapping this work up into the
> Windows integration work.
>
> SUMMARIZED ADVANTAGES:
> * Basically fool-proof. Communicates simply what its function is (you
> include this file once). Semantically it is "the right tool for the
> job".
> * No need for namespacing conventions for #include guards.
> * No conflicts with reserved identifiers[5].
> * No internal conflicts between include guards in Stout, Process
> library, and Mesos (this is one reason we need the namespacing
> conventions)
> * Reduces preprocessor definition clutter (we should rely on #define
> as little as humanly possible).
> * Optimized to be easy to read and reason about.
>
> NEXT STEPS:
> If we agree that this is the right thing to do, committers would ask
> people to use `#pragma once` for new code when presented in code
> reviews. For files that exist, I will take point on transitioning as
> we complete the Windows integration work. I expect this work to
> completely land before the new year.
>
>
> Thanks,
>
>
> [1] https://reviews.apache.org/r/39803/
> [2] https://www.marc.info/?t=142540100400015&r=1&w=2
> [3] https://issues.apache.org/jira/browse/MESOS-2211
> [4] https://reviews.apache.org/r/30100/
> [5]
> http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
>
>
> --
> Alex
>
> Theory is the first term in the Taylor series of practice. -- Thomas M
> Cover (1992)
>
>
>


-- 
Best Regards,
Haosdent Huang

Re: Proposal: move towards #pragma and away from #include guards

[Bernd Mathiske <be...@mesosphere.io>]

+1

This site has a list of compilers that support #pragma once.

https://en.wikipedia.org/wiki/Pragma_once#Portability <https://en.wikipedia.org/wiki/Pragma_once#Portability>

Clang, MS V C++, GCC as of 3.4. from 2006. OK!

(Too bad for Sun/Oracle Studio C++. But you can use GCC on Solaris, right?)

We could tackle this change at the same time as correcting the copyright notes, then we have the history clutter only once:

https://issues.apache.org/jira/browse/MESOS-3581 <https://issues.apache.org/jira/browse/MESOS-3581>

Any other projects of that nature that can be bundled?

Bernd

> On Nov 5, 2015, at 6:36 AM, Alex Clemmer <cl...@gmail.com> wrote:
> 
> Hey folks.
> 
> In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> brought up the issue of moving away from #include guards and towards
> `#pragma once`.
> 
> As this has been brought up before, I will be brief: we think it's
> revisiting because the primary objection in previous threads appears
> to be that, though `#pragma once` is a cleaner solution to the
> multiple-include problem, it's not so much better that it's worth the
> code churn. However, the ongoing Windows integration work means we
> have to touch these files anyway, so if we agree this is cleaner and
> desirable, then this is an opportunity to obtain that additional code
> clarity, without the cost of the churn.
> 
> For the remainder of the email, I will summarize the history of our
> discussion of this issue, who will do the work, and what the next
> steps are.
> 
> PROPOSAL: We propose that all new code use `#pragma once` instead of
> #include guards; for existing files, we propose that you change
> #include guards when you touch them.
> 
> HISTORY: This has been discussed before, most recently a year ago on
> the mailing list[2]. There is a relevant JIRA[3] and discarded
> review[4] that changes style guide's recommendation on the matter.
> 
> SUMMARIZED OBJECTIONS:
> 1. The Google style guide explicitly forbids `#pragma once`.
> 2. This results in a lot of code churn, but is only marginally better.
> 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> doesn't support it.
> 4. Popular projects like Chrome don't do `#pragma once` because of
> history clutter.
> 5. Intermediate state of inconsistency as we transition to `#pragma
> once` from #include guards.
> 
> OUR RESPONSE:
> Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
> points out in a previous thread that the Google style guide was
> canonized when `#pragma once` was Windows-only, and the guidance has
> not changed since because of the history churn problem. As noted
> above, we think the history churn problem is minimized by the fact
> that it can be wrapped up into the Windows integration work.
> 
> For objection (3), the consensus seems to be that the vast majority of
> compilers we care about (in particular, the ones supporting C++ 11) do
> support it.
> 
> For objection (5) we believe the inconsistent state is likely to not
> be long lived, as long as we commit to wrapping this work up into the
> Windows integration work.
> 
> SUMMARIZED ADVANTAGES:
> * Basically fool-proof. Communicates simply what its function is (you
> include this file once). Semantically it is "the right tool for the
> job".
> * No need for namespacing conventions for #include guards.
> * No conflicts with reserved identifiers[5].
> * No internal conflicts between include guards in Stout, Process
> library, and Mesos (this is one reason we need the namespacing
> conventions)
> * Reduces preprocessor definition clutter (we should rely on #define
> as little as humanly possible).
> * Optimized to be easy to read and reason about.
> 
> NEXT STEPS:
> If we agree that this is the right thing to do, committers would ask
> people to use `#pragma once` for new code when presented in code
> reviews. For files that exist, I will take point on transitioning as
> we complete the Windows integration work. I expect this work to
> completely land before the new year.
> 
> 
> Thanks,
> 
> 
> [1] https://reviews.apache.org/r/39803/
> [2] https://www.marc.info/?t=142540100400015&r=1&w=2
> [3] https://issues.apache.org/jira/browse/MESOS-2211
> [4] https://reviews.apache.org/r/30100/
> [5] http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
> 
> 
> --
> Alex
> 
> Theory is the first term in the Taylor series of practice. -- Thomas M
> Cover (1992)

Re: Proposal: move towards #pragma and away from #include guards

[Jan Schlicht <ja...@mesosphere.io>]

+1 (non-binding) for an all-at-once change to #pragmas.

On Fri, Nov 6, 2015 at 2:30 AM, Joris Van Remoortere <jo...@mesosphere.io>
wrote:

> +1 with all-at-once
>
> —
> *Joris Van Remoortere*
> Mesosphere
>
> On Thu, Nov 5, 2015 at 9:37 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>
> > +1.
> >
> > I think we should do it all at once as Artem mentioned. This doesn't
> really
> > affect the history (git-blame, etc.) because we are not touching code per
> > se.
> >
> > On Thu, Nov 5, 2015 at 12:29 PM, Artem Harutyunyan <ar...@mesosphere.io>
> > wrote:
> >
> > > Hi Alex,
> > >
> > > While I agree with the idea in general, I strongly believe that we
> should
> > > either leave it as it is or fix everything in one go (i.e. three
> > > consecutive commits). Having both #include guards and #pragmas in the
> > > codebase will be confusing and untidy. We have done code sweeps like
> this
> > > in the past when we had to introduce changes to the style guide, so if
> > > folks agree you just need to find a shepherd and do it :).
> > >
> > > Cheers,
> > > Artem.
> > >
> > > On Wed, Nov 4, 2015 at 9:36 PM, Alex Clemmer <
> > clemmer.alexander@gmail.com>
> > > wrote:
> > >
> > > > Hey folks.
> > > >
> > > > In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> > > > brought up the issue of moving away from #include guards and towards
> > > > `#pragma once`.
> > > >
> > > > As this has been brought up before, I will be brief: we think it's
> > > > revisiting because the primary objection in previous threads appears
> > > > to be that, though `#pragma once` is a cleaner solution to the
> > > > multiple-include problem, it's not so much better that it's worth the
> > > > code churn. However, the ongoing Windows integration work means we
> > > > have to touch these files anyway, so if we agree this is cleaner and
> > > > desirable, then this is an opportunity to obtain that additional code
> > > > clarity, without the cost of the churn.
> > > >
> > > > For the remainder of the email, I will summarize the history of our
> > > > discussion of this issue, who will do the work, and what the next
> > > > steps are.
> > > >
> > > > PROPOSAL: We propose that all new code use `#pragma once` instead of
> > > > #include guards; for existing files, we propose that you change
> > > > #include guards when you touch them.
> > > >
> > > > HISTORY: This has been discussed before, most recently a year ago on
> > > > the mailing list[2]. There is a relevant JIRA[3] and discarded
> > > > review[4] that changes style guide's recommendation on the matter.
> > > >
> > > > SUMMARIZED OBJECTIONS:
> > > > 1. The Google style guide explicitly forbids `#pragma once`.
> > > > 2. This results in a lot of code churn, but is only marginally
> better.
> > > > 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> > > > doesn't support it.
> > > > 4. Popular projects like Chrome don't do `#pragma once` because of
> > > > history clutter.
> > > > 5. Intermediate state of inconsistency as we transition to `#pragma
> > > > once` from #include guards.
> > > >
> > > > OUR RESPONSE:
> > > > Objections (1), (2), and (4) are essentially the same -- Dominic
> Hamon
> > > > points out in a previous thread that the Google style guide was
> > > > canonized when `#pragma once` was Windows-only, and the guidance has
> > > > not changed since because of the history churn problem. As noted
> > > > above, we think the history churn problem is minimized by the fact
> > > > that it can be wrapped up into the Windows integration work.
> > > >
> > > > For objection (3), the consensus seems to be that the vast majority
> of
> > > > compilers we care about (in particular, the ones supporting C++ 11)
> do
> > > > support it.
> > > >
> > > > For objection (5) we believe the inconsistent state is likely to not
> > > > be long lived, as long as we commit to wrapping this work up into the
> > > > Windows integration work.
> > > >
> > > > SUMMARIZED ADVANTAGES:
> > > > * Basically fool-proof. Communicates simply what its function is (you
> > > > include this file once). Semantically it is "the right tool for the
> > > > job".
> > > > * No need for namespacing conventions for #include guards.
> > > > * No conflicts with reserved identifiers[5].
> > > > * No internal conflicts between include guards in Stout, Process
> > > > library, and Mesos (this is one reason we need the namespacing
> > > > conventions)
> > > > * Reduces preprocessor definition clutter (we should rely on #define
> > > > as little as humanly possible).
> > > > * Optimized to be easy to read and reason about.
> > > >
> > > > NEXT STEPS:
> > > > If we agree that this is the right thing to do, committers would ask
> > > > people to use `#pragma once` for new code when presented in code
> > > > reviews. For files that exist, I will take point on transitioning as
> > > > we complete the Windows integration work. I expect this work to
> > > > completely land before the new year.
> > > >
> > > >
> > > > Thanks,
> > > >
> > > >
> > > > [1] https://reviews.apache.org/r/39803/
> > > > [2] https://www.marc.info/?t=142540100400015&r=1&w=2
> > > > [3] https://issues.apache.org/jira/browse/MESOS-2211
> > > > [4] https://reviews.apache.org/r/30100/
> > > > [5]
> > > >
> > >
> >
> http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
> > > >
> > > >
> > > > --
> > > > Alex
> > > >
> > > > Theory is the first term in the Taylor series of practice. -- Thomas
> M
> > > > Cover (1992)
> > > >
> > >
> >
>



-- 
*Jan Schlicht*
Distributed Systems Engineer, Mesosphere

Re: Proposal: move towards #pragma and away from #include guards

[Joris Van Remoortere <jo...@mesosphere.io>]

+1 with all-at-once

—
*Joris Van Remoortere*
Mesosphere

On Thu, Nov 5, 2015 at 9:37 AM, Kapil Arya <ka...@mesosphere.io> wrote:

> +1.
>
> I think we should do it all at once as Artem mentioned. This doesn't really
> affect the history (git-blame, etc.) because we are not touching code per
> se.
>
> On Thu, Nov 5, 2015 at 12:29 PM, Artem Harutyunyan <ar...@mesosphere.io>
> wrote:
>
> > Hi Alex,
> >
> > While I agree with the idea in general, I strongly believe that we should
> > either leave it as it is or fix everything in one go (i.e. three
> > consecutive commits). Having both #include guards and #pragmas in the
> > codebase will be confusing and untidy. We have done code sweeps like this
> > in the past when we had to introduce changes to the style guide, so if
> > folks agree you just need to find a shepherd and do it :).
> >
> > Cheers,
> > Artem.
> >
> > On Wed, Nov 4, 2015 at 9:36 PM, Alex Clemmer <
> clemmer.alexander@gmail.com>
> > wrote:
> >
> > > Hey folks.
> > >
> > > In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> > > brought up the issue of moving away from #include guards and towards
> > > `#pragma once`.
> > >
> > > As this has been brought up before, I will be brief: we think it's
> > > revisiting because the primary objection in previous threads appears
> > > to be that, though `#pragma once` is a cleaner solution to the
> > > multiple-include problem, it's not so much better that it's worth the
> > > code churn. However, the ongoing Windows integration work means we
> > > have to touch these files anyway, so if we agree this is cleaner and
> > > desirable, then this is an opportunity to obtain that additional code
> > > clarity, without the cost of the churn.
> > >
> > > For the remainder of the email, I will summarize the history of our
> > > discussion of this issue, who will do the work, and what the next
> > > steps are.
> > >
> > > PROPOSAL: We propose that all new code use `#pragma once` instead of
> > > #include guards; for existing files, we propose that you change
> > > #include guards when you touch them.
> > >
> > > HISTORY: This has been discussed before, most recently a year ago on
> > > the mailing list[2]. There is a relevant JIRA[3] and discarded
> > > review[4] that changes style guide's recommendation on the matter.
> > >
> > > SUMMARIZED OBJECTIONS:
> > > 1. The Google style guide explicitly forbids `#pragma once`.
> > > 2. This results in a lot of code churn, but is only marginally better.
> > > 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> > > doesn't support it.
> > > 4. Popular projects like Chrome don't do `#pragma once` because of
> > > history clutter.
> > > 5. Intermediate state of inconsistency as we transition to `#pragma
> > > once` from #include guards.
> > >
> > > OUR RESPONSE:
> > > Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
> > > points out in a previous thread that the Google style guide was
> > > canonized when `#pragma once` was Windows-only, and the guidance has
> > > not changed since because of the history churn problem. As noted
> > > above, we think the history churn problem is minimized by the fact
> > > that it can be wrapped up into the Windows integration work.
> > >
> > > For objection (3), the consensus seems to be that the vast majority of
> > > compilers we care about (in particular, the ones supporting C++ 11) do
> > > support it.
> > >
> > > For objection (5) we believe the inconsistent state is likely to not
> > > be long lived, as long as we commit to wrapping this work up into the
> > > Windows integration work.
> > >
> > > SUMMARIZED ADVANTAGES:
> > > * Basically fool-proof. Communicates simply what its function is (you
> > > include this file once). Semantically it is "the right tool for the
> > > job".
> > > * No need for namespacing conventions for #include guards.
> > > * No conflicts with reserved identifiers[5].
> > > * No internal conflicts between include guards in Stout, Process
> > > library, and Mesos (this is one reason we need the namespacing
> > > conventions)
> > > * Reduces preprocessor definition clutter (we should rely on #define
> > > as little as humanly possible).
> > > * Optimized to be easy to read and reason about.
> > >
> > > NEXT STEPS:
> > > If we agree that this is the right thing to do, committers would ask
> > > people to use `#pragma once` for new code when presented in code
> > > reviews. For files that exist, I will take point on transitioning as
> > > we complete the Windows integration work. I expect this work to
> > > completely land before the new year.
> > >
> > >
> > > Thanks,
> > >
> > >
> > > [1] https://reviews.apache.org/r/39803/
> > > [2] https://www.marc.info/?t=142540100400015&r=1&w=2
> > > [3] https://issues.apache.org/jira/browse/MESOS-2211
> > > [4] https://reviews.apache.org/r/30100/
> > > [5]
> > >
> >
> http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
> > >
> > >
> > > --
> > > Alex
> > >
> > > Theory is the first term in the Taylor series of practice. -- Thomas M
> > > Cover (1992)
> > >
> >
>

Re: Proposal: move towards #pragma and away from #include guards

[Kapil Arya <ka...@mesosphere.io>]

+1.

I think we should do it all at once as Artem mentioned. This doesn't really
affect the history (git-blame, etc.) because we are not touching code per
se.

On Thu, Nov 5, 2015 at 12:29 PM, Artem Harutyunyan <ar...@mesosphere.io>
wrote:

> Hi Alex,
>
> While I agree with the idea in general, I strongly believe that we should
> either leave it as it is or fix everything in one go (i.e. three
> consecutive commits). Having both #include guards and #pragmas in the
> codebase will be confusing and untidy. We have done code sweeps like this
> in the past when we had to introduce changes to the style guide, so if
> folks agree you just need to find a shepherd and do it :).
>
> Cheers,
> Artem.
>
> On Wed, Nov 4, 2015 at 9:36 PM, Alex Clemmer <cl...@gmail.com>
> wrote:
>
> > Hey folks.
> >
> > In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> > brought up the issue of moving away from #include guards and towards
> > `#pragma once`.
> >
> > As this has been brought up before, I will be brief: we think it's
> > revisiting because the primary objection in previous threads appears
> > to be that, though `#pragma once` is a cleaner solution to the
> > multiple-include problem, it's not so much better that it's worth the
> > code churn. However, the ongoing Windows integration work means we
> > have to touch these files anyway, so if we agree this is cleaner and
> > desirable, then this is an opportunity to obtain that additional code
> > clarity, without the cost of the churn.
> >
> > For the remainder of the email, I will summarize the history of our
> > discussion of this issue, who will do the work, and what the next
> > steps are.
> >
> > PROPOSAL: We propose that all new code use `#pragma once` instead of
> > #include guards; for existing files, we propose that you change
> > #include guards when you touch them.
> >
> > HISTORY: This has been discussed before, most recently a year ago on
> > the mailing list[2]. There is a relevant JIRA[3] and discarded
> > review[4] that changes style guide's recommendation on the matter.
> >
> > SUMMARIZED OBJECTIONS:
> > 1. The Google style guide explicitly forbids `#pragma once`.
> > 2. This results in a lot of code churn, but is only marginally better.
> > 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> > doesn't support it.
> > 4. Popular projects like Chrome don't do `#pragma once` because of
> > history clutter.
> > 5. Intermediate state of inconsistency as we transition to `#pragma
> > once` from #include guards.
> >
> > OUR RESPONSE:
> > Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
> > points out in a previous thread that the Google style guide was
> > canonized when `#pragma once` was Windows-only, and the guidance has
> > not changed since because of the history churn problem. As noted
> > above, we think the history churn problem is minimized by the fact
> > that it can be wrapped up into the Windows integration work.
> >
> > For objection (3), the consensus seems to be that the vast majority of
> > compilers we care about (in particular, the ones supporting C++ 11) do
> > support it.
> >
> > For objection (5) we believe the inconsistent state is likely to not
> > be long lived, as long as we commit to wrapping this work up into the
> > Windows integration work.
> >
> > SUMMARIZED ADVANTAGES:
> > * Basically fool-proof. Communicates simply what its function is (you
> > include this file once). Semantically it is "the right tool for the
> > job".
> > * No need for namespacing conventions for #include guards.
> > * No conflicts with reserved identifiers[5].
> > * No internal conflicts between include guards in Stout, Process
> > library, and Mesos (this is one reason we need the namespacing
> > conventions)
> > * Reduces preprocessor definition clutter (we should rely on #define
> > as little as humanly possible).
> > * Optimized to be easy to read and reason about.
> >
> > NEXT STEPS:
> > If we agree that this is the right thing to do, committers would ask
> > people to use `#pragma once` for new code when presented in code
> > reviews. For files that exist, I will take point on transitioning as
> > we complete the Windows integration work. I expect this work to
> > completely land before the new year.
> >
> >
> > Thanks,
> >
> >
> > [1] https://reviews.apache.org/r/39803/
> > [2] https://www.marc.info/?t=142540100400015&r=1&w=2
> > [3] https://issues.apache.org/jira/browse/MESOS-2211
> > [4] https://reviews.apache.org/r/30100/
> > [5]
> >
> http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
> >
> >
> > --
> > Alex
> >
> > Theory is the first term in the Taylor series of practice. -- Thomas M
> > Cover (1992)
> >
>

Re: Proposal: move towards #pragma and away from #include guards

[Artem Harutyunyan <ar...@mesosphere.io>]

Hi Alex,

While I agree with the idea in general, I strongly believe that we should
either leave it as it is or fix everything in one go (i.e. three
consecutive commits). Having both #include guards and #pragmas in the
codebase will be confusing and untidy. We have done code sweeps like this
in the past when we had to introduce changes to the style guide, so if
folks agree you just need to find a shepherd and do it :).

Cheers,
Artem.

On Wed, Nov 4, 2015 at 9:36 PM, Alex Clemmer <cl...@gmail.com>
wrote:

> Hey folks.
>
> In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> brought up the issue of moving away from #include guards and towards
> `#pragma once`.
>
> As this has been brought up before, I will be brief: we think it's
> revisiting because the primary objection in previous threads appears
> to be that, though `#pragma once` is a cleaner solution to the
> multiple-include problem, it's not so much better that it's worth the
> code churn. However, the ongoing Windows integration work means we
> have to touch these files anyway, so if we agree this is cleaner and
> desirable, then this is an opportunity to obtain that additional code
> clarity, without the cost of the churn.
>
> For the remainder of the email, I will summarize the history of our
> discussion of this issue, who will do the work, and what the next
> steps are.
>
> PROPOSAL: We propose that all new code use `#pragma once` instead of
> #include guards; for existing files, we propose that you change
> #include guards when you touch them.
>
> HISTORY: This has been discussed before, most recently a year ago on
> the mailing list[2]. There is a relevant JIRA[3] and discarded
> review[4] that changes style guide's recommendation on the matter.
>
> SUMMARIZED OBJECTIONS:
> 1. The Google style guide explicitly forbids `#pragma once`.
> 2. This results in a lot of code churn, but is only marginally better.
> 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> doesn't support it.
> 4. Popular projects like Chrome don't do `#pragma once` because of
> history clutter.
> 5. Intermediate state of inconsistency as we transition to `#pragma
> once` from #include guards.
>
> OUR RESPONSE:
> Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
> points out in a previous thread that the Google style guide was
> canonized when `#pragma once` was Windows-only, and the guidance has
> not changed since because of the history churn problem. As noted
> above, we think the history churn problem is minimized by the fact
> that it can be wrapped up into the Windows integration work.
>
> For objection (3), the consensus seems to be that the vast majority of
> compilers we care about (in particular, the ones supporting C++ 11) do
> support it.
>
> For objection (5) we believe the inconsistent state is likely to not
> be long lived, as long as we commit to wrapping this work up into the
> Windows integration work.
>
> SUMMARIZED ADVANTAGES:
> * Basically fool-proof. Communicates simply what its function is (you
> include this file once). Semantically it is "the right tool for the
> job".
> * No need for namespacing conventions for #include guards.
> * No conflicts with reserved identifiers[5].
> * No internal conflicts between include guards in Stout, Process
> library, and Mesos (this is one reason we need the namespacing
> conventions)
> * Reduces preprocessor definition clutter (we should rely on #define
> as little as humanly possible).
> * Optimized to be easy to read and reason about.
>
> NEXT STEPS:
> If we agree that this is the right thing to do, committers would ask
> people to use `#pragma once` for new code when presented in code
> reviews. For files that exist, I will take point on transitioning as
> we complete the Windows integration work. I expect this work to
> completely land before the new year.
>
>
> Thanks,
>
>
> [1] https://reviews.apache.org/r/39803/
> [2] https://www.marc.info/?t=142540100400015&r=1&w=2
> [3] https://issues.apache.org/jira/browse/MESOS-2211
> [4] https://reviews.apache.org/r/30100/
> [5]
> http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
>
>
> --
> Alex
>
> Theory is the first term in the Taylor series of practice. -- Thomas M
> Cover (1992)
>

Re: Proposal: move towards #pragma and away from #include guards

[Alexander Rojas <al...@mesosphere.io>]

my fault, I started reading at the office and when I came home I thought I had already read your whole email. Still, I have always been in favor or the `#pragma once` solution. So as I said:

+1 (non-binding).

> On 05 Nov 2015, at 18:21, Alex Clemmer <cl...@gmail.com> wrote:
> 
> Just because I apparently was not very clear: in the "history" and
> "summarized objections" sections of my original mail, I did attempt to
> capture all of the objections from this thread and previous
> discussions I found (and, just for the sake of thoroughness, I do
> actually explicitly cite this thread in the footnotes). If you don't
> want to dig through the thread yourself, I hope that this will give
> you a good approximation of what happened in that thread.
> 
> I see now that I did fail to mention that this thread ended in
> nonconsensus rather than an explicit decision against. Sorry about
> that. You can also see evidence that the decision was nonconsensus
> directly in the JIRA issues and the review I cite -- for example on
> JIRA, Alex R mentions removing the newbie tag from the issue because
> there is nonconsensus, and the review was discarded, with the cited
> reason being nonconsensus.
> 
> Hopefully this clarifies these issues.
> 
> On Thu, Nov 5, 2015 at 8:32 AM, Alexander Rojas <al...@mesosphere.io> wrote:
>> While I’m all in on the proposal, we did have this discussion almost a year ago [1] at the end I think, the decision was not to use them, though I don’t remember the exact reason. In any case, I vote +1 non-binding.
>> 
>> [1] http://mail-archives.apache.org/mod_mbox/mesos-dev/201501.mbox/%3CCA+fJHLjzxPTk_Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=iJAA@mail.gmail.com%3E <http://mail-archives.apache.org/mod_mbox/mesos-dev/201501.mbox/%3CCA+fJHLjzxPTk_Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=iJAA@mail.gmail.com%3E>
>> 
>> 
>>> On 05 Nov 2015, at 06:36, Alex Clemmer <cl...@gmail.com> wrote:
>>> 
>>> Hey folks.
>>> 
>>> In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
>>> brought up the issue of moving away from #include guards and towards
>>> `#pragma once`.
>>> 
>>> As this has been brought up before, I will be brief: we think it's
>>> revisiting because the primary objection in previous threads appears
>>> to be that, though `#pragma once` is a cleaner solution to the
>>> multiple-include problem, it's not so much better that it's worth the
>>> code churn. However, the ongoing Windows integration work means we
>>> have to touch these files anyway, so if we agree this is cleaner and
>>> desirable, then this is an opportunity to obtain that additional code
>>> clarity, without the cost of the churn.
>>> 
>>> For the remainder of the email, I will summarize the history of our
>>> discussion of this issue, who will do the work, and what the next
>>> steps are.
>>> 
>>> PROPOSAL: We propose that all new code use `#pragma once` instead of
>>> #include guards; for existing files, we propose that you change
>>> #include guards when you touch them.
>>> 
>>> HISTORY: This has been discussed before, most recently a year ago on
>>> the mailing list[2]. There is a relevant JIRA[3] and discarded
>>> review[4] that changes style guide's recommendation on the matter.
>>> 
>>> SUMMARIZED OBJECTIONS:
>>> 1. The Google style guide explicitly forbids `#pragma once`.
>>> 2. This results in a lot of code churn, but is only marginally better.
>>> 3. It's not C++ standardized/it's platform dependent/IBM's compiler
>>> doesn't support it.
>>> 4. Popular projects like Chrome don't do `#pragma once` because of
>>> history clutter.
>>> 5. Intermediate state of inconsistency as we transition to `#pragma
>>> once` from #include guards.
>>> 
>>> OUR RESPONSE:
>>> Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
>>> points out in a previous thread that the Google style guide was
>>> canonized when `#pragma once` was Windows-only, and the guidance has
>>> not changed since because of the history churn problem. As noted
>>> above, we think the history churn problem is minimized by the fact
>>> that it can be wrapped up into the Windows integration work.
>>> 
>>> For objection (3), the consensus seems to be that the vast majority of
>>> compilers we care about (in particular, the ones supporting C++ 11) do
>>> support it.
>>> 
>>> For objection (5) we believe the inconsistent state is likely to not
>>> be long lived, as long as we commit to wrapping this work up into the
>>> Windows integration work.
>>> 
>>> SUMMARIZED ADVANTAGES:
>>> * Basically fool-proof. Communicates simply what its function is (you
>>> include this file once). Semantically it is "the right tool for the
>>> job".
>>> * No need for namespacing conventions for #include guards.
>>> * No conflicts with reserved identifiers[5].
>>> * No internal conflicts between include guards in Stout, Process
>>> library, and Mesos (this is one reason we need the namespacing
>>> conventions)
>>> * Reduces preprocessor definition clutter (we should rely on #define
>>> as little as humanly possible).
>>> * Optimized to be easy to read and reason about.
>>> 
>>> NEXT STEPS:
>>> If we agree that this is the right thing to do, committers would ask
>>> people to use `#pragma once` for new code when presented in code
>>> reviews. For files that exist, I will take point on transitioning as
>>> we complete the Windows integration work. I expect this work to
>>> completely land before the new year.
>>> 
>>> 
>>> Thanks,
>>> 
>>> 
>>> [1] https://reviews.apache.org/r/39803/
>>> [2] https://www.marc.info/?t=142540100400015&r=1&w=2
>>> [3] https://issues.apache.org/jira/browse/MESOS-2211
>>> [4] https://reviews.apache.org/r/30100/
>>> [5] http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
>>> 
>>> 
>>> --
>>> Alex
>>> 
>>> Theory is the first term in the Taylor series of practice. -- Thomas M
>>> Cover (1992)
>> 
> 
> 
> 
> -- 
> Alex
> 
> Theory is the first term in the Taylor series of practice. -- Thomas M
> Cover (1992)

Re: Proposal: move towards #pragma and away from #include guards

[Alex Clemmer <cl...@gmail.com>]

Just because I apparently was not very clear: in the "history" and
"summarized objections" sections of my original mail, I did attempt to
capture all of the objections from this thread and previous
discussions I found (and, just for the sake of thoroughness, I do
actually explicitly cite this thread in the footnotes). If you don't
want to dig through the thread yourself, I hope that this will give
you a good approximation of what happened in that thread.

I see now that I did fail to mention that this thread ended in
nonconsensus rather than an explicit decision against. Sorry about
that. You can also see evidence that the decision was nonconsensus
directly in the JIRA issues and the review I cite -- for example on
JIRA, Alex R mentions removing the newbie tag from the issue because
there is nonconsensus, and the review was discarded, with the cited
reason being nonconsensus.

Hopefully this clarifies these issues.

On Thu, Nov 5, 2015 at 8:32 AM, Alexander Rojas <al...@mesosphere.io> wrote:
> While I’m all in on the proposal, we did have this discussion almost a year ago [1] at the end I think, the decision was not to use them, though I don’t remember the exact reason. In any case, I vote +1 non-binding.
>
> [1] http://mail-archives.apache.org/mod_mbox/mesos-dev/201501.mbox/%3CCA+fJHLjzxPTk_Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=iJAA@mail.gmail.com%3E <http://mail-archives.apache.org/mod_mbox/mesos-dev/201501.mbox/%3CCA+fJHLjzxPTk_Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=iJAA@mail.gmail.com%3E>
>
>
>> On 05 Nov 2015, at 06:36, Alex Clemmer <cl...@gmail.com> wrote:
>>
>> Hey folks.
>>
>> In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
>> brought up the issue of moving away from #include guards and towards
>> `#pragma once`.
>>
>> As this has been brought up before, I will be brief: we think it's
>> revisiting because the primary objection in previous threads appears
>> to be that, though `#pragma once` is a cleaner solution to the
>> multiple-include problem, it's not so much better that it's worth the
>> code churn. However, the ongoing Windows integration work means we
>> have to touch these files anyway, so if we agree this is cleaner and
>> desirable, then this is an opportunity to obtain that additional code
>> clarity, without the cost of the churn.
>>
>> For the remainder of the email, I will summarize the history of our
>> discussion of this issue, who will do the work, and what the next
>> steps are.
>>
>> PROPOSAL: We propose that all new code use `#pragma once` instead of
>> #include guards; for existing files, we propose that you change
>> #include guards when you touch them.
>>
>> HISTORY: This has been discussed before, most recently a year ago on
>> the mailing list[2]. There is a relevant JIRA[3] and discarded
>> review[4] that changes style guide's recommendation on the matter.
>>
>> SUMMARIZED OBJECTIONS:
>> 1. The Google style guide explicitly forbids `#pragma once`.
>> 2. This results in a lot of code churn, but is only marginally better.
>> 3. It's not C++ standardized/it's platform dependent/IBM's compiler
>> doesn't support it.
>> 4. Popular projects like Chrome don't do `#pragma once` because of
>> history clutter.
>> 5. Intermediate state of inconsistency as we transition to `#pragma
>> once` from #include guards.
>>
>> OUR RESPONSE:
>> Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
>> points out in a previous thread that the Google style guide was
>> canonized when `#pragma once` was Windows-only, and the guidance has
>> not changed since because of the history churn problem. As noted
>> above, we think the history churn problem is minimized by the fact
>> that it can be wrapped up into the Windows integration work.
>>
>> For objection (3), the consensus seems to be that the vast majority of
>> compilers we care about (in particular, the ones supporting C++ 11) do
>> support it.
>>
>> For objection (5) we believe the inconsistent state is likely to not
>> be long lived, as long as we commit to wrapping this work up into the
>> Windows integration work.
>>
>> SUMMARIZED ADVANTAGES:
>> * Basically fool-proof. Communicates simply what its function is (you
>> include this file once). Semantically it is "the right tool for the
>> job".
>> * No need for namespacing conventions for #include guards.
>> * No conflicts with reserved identifiers[5].
>> * No internal conflicts between include guards in Stout, Process
>> library, and Mesos (this is one reason we need the namespacing
>> conventions)
>> * Reduces preprocessor definition clutter (we should rely on #define
>> as little as humanly possible).
>> * Optimized to be easy to read and reason about.
>>
>> NEXT STEPS:
>> If we agree that this is the right thing to do, committers would ask
>> people to use `#pragma once` for new code when presented in code
>> reviews. For files that exist, I will take point on transitioning as
>> we complete the Windows integration work. I expect this work to
>> completely land before the new year.
>>
>>
>> Thanks,
>>
>>
>> [1] https://reviews.apache.org/r/39803/
>> [2] https://www.marc.info/?t=142540100400015&r=1&w=2
>> [3] https://issues.apache.org/jira/browse/MESOS-2211
>> [4] https://reviews.apache.org/r/30100/
>> [5] http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
>>
>>
>> --
>> Alex
>>
>> Theory is the first term in the Taylor series of practice. -- Thomas M
>> Cover (1992)
>



-- 
Alex

Theory is the first term in the Taylor series of practice. -- Thomas M
Cover (1992)

Re: Proposal: move towards #pragma and away from #include guards

[Alexander Rojas <al...@mesosphere.io>]

While I’m all in on the proposal, we did have this discussion almost a year ago [1] at the end I think, the decision was not to use them, though I don’t remember the exact reason. In any case, I vote +1 non-binding.

[1] http://mail-archives.apache.org/mod_mbox/mesos-dev/201501.mbox/%3CCA+fJHLjzxPTk_Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=iJAA@mail.gmail.com%3E <http://mail-archives.apache.org/mod_mbox/mesos-dev/201501.mbox/%3CCA+fJHLjzxPTk_Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=iJAA@mail.gmail.com%3E>


> On 05 Nov 2015, at 06:36, Alex Clemmer <cl...@gmail.com> wrote:
> 
> Hey folks.
> 
> In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> brought up the issue of moving away from #include guards and towards
> `#pragma once`.
> 
> As this has been brought up before, I will be brief: we think it's
> revisiting because the primary objection in previous threads appears
> to be that, though `#pragma once` is a cleaner solution to the
> multiple-include problem, it's not so much better that it's worth the
> code churn. However, the ongoing Windows integration work means we
> have to touch these files anyway, so if we agree this is cleaner and
> desirable, then this is an opportunity to obtain that additional code
> clarity, without the cost of the churn.
> 
> For the remainder of the email, I will summarize the history of our
> discussion of this issue, who will do the work, and what the next
> steps are.
> 
> PROPOSAL: We propose that all new code use `#pragma once` instead of
> #include guards; for existing files, we propose that you change
> #include guards when you touch them.
> 
> HISTORY: This has been discussed before, most recently a year ago on
> the mailing list[2]. There is a relevant JIRA[3] and discarded
> review[4] that changes style guide's recommendation on the matter.
> 
> SUMMARIZED OBJECTIONS:
> 1. The Google style guide explicitly forbids `#pragma once`.
> 2. This results in a lot of code churn, but is only marginally better.
> 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> doesn't support it.
> 4. Popular projects like Chrome don't do `#pragma once` because of
> history clutter.
> 5. Intermediate state of inconsistency as we transition to `#pragma
> once` from #include guards.
> 
> OUR RESPONSE:
> Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
> points out in a previous thread that the Google style guide was
> canonized when `#pragma once` was Windows-only, and the guidance has
> not changed since because of the history churn problem. As noted
> above, we think the history churn problem is minimized by the fact
> that it can be wrapped up into the Windows integration work.
> 
> For objection (3), the consensus seems to be that the vast majority of
> compilers we care about (in particular, the ones supporting C++ 11) do
> support it.
> 
> For objection (5) we believe the inconsistent state is likely to not
> be long lived, as long as we commit to wrapping this work up into the
> Windows integration work.
> 
> SUMMARIZED ADVANTAGES:
> * Basically fool-proof. Communicates simply what its function is (you
> include this file once). Semantically it is "the right tool for the
> job".
> * No need for namespacing conventions for #include guards.
> * No conflicts with reserved identifiers[5].
> * No internal conflicts between include guards in Stout, Process
> library, and Mesos (this is one reason we need the namespacing
> conventions)
> * Reduces preprocessor definition clutter (we should rely on #define
> as little as humanly possible).
> * Optimized to be easy to read and reason about.
> 
> NEXT STEPS:
> If we agree that this is the right thing to do, committers would ask
> people to use `#pragma once` for new code when presented in code
> reviews. For files that exist, I will take point on transitioning as
> we complete the Windows integration work. I expect this work to
> completely land before the new year.
> 
> 
> Thanks,
> 
> 
> [1] https://reviews.apache.org/r/39803/
> [2] https://www.marc.info/?t=142540100400015&r=1&w=2
> [3] https://issues.apache.org/jira/browse/MESOS-2211
> [4] https://reviews.apache.org/r/30100/
> [5] http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
> 
> 
> -- 
> Alex
> 
> Theory is the first term in the Taylor series of practice. -- Thomas M
> Cover (1992)