http://en.wikipedia.org/wiki/Pragma_once#Portability
There are some subtleties: If you have two header files with the same content in different locations on disk, pragma once will include both, header guards will (obviously) skip. This may or may not be a benefit :) It used to be that gcc would optimize pragma once, iirc, but it has special handling code for #ifndef guards now (cite stackoverflow). In the grand scheme of things, it really doesn't matter all that much, but it is the 'correct' way to do things, is supported by all compilers we care about, and is marginally cleaner. On Wed, Jan 21, 2015 at 2:31 AM, Alexander Rojas <[email protected]> wrote: > While I understand your concern, I think #pragma once reduces clutter in > the code and improves readability which I think is the important thing > here. However I just see portability could be an issue (however almost all > mayor compilers support this pragma nowadays). > > Do we in general have a list of supported compilers? It would be sad not > to go for this patch because we cannot get compiled in IBM’s compiler only > to find out later on that mesos never compiled there anyway. > > - Alexander > > > > On 21 Jan 2015, at 07:31, John Pampuch <[email protected]> wrote: > > > > Not to be too much of a stickler, but #pragma once is a bit strange. It > > runs slightly counter to: > > > > The ‘#pragma’ directive is the method specified by the C standard for > > providing additional information to the compiler, beyond what is conveyed > > in the language itself. > > > > > > I suppose a directive that says "skip this file under certain conditions" > > is "beyond what is conveyed in the language itself". The problem is that > > code that compiles fine with the pragma could fail (fairly easily) > without, > > which doesn't seem to be the intent of pragmas. > > > > But conceptually, it does seem like a better solution. Of course, > > compliers aren't obligated to support it, so any compiler that probably > > won't work. > > > > It probably doesn't matter much, but IBM's commercial XL C/C++ compiler > > doesn't support this per the venerable Wikipedia. > > > > -John > > > > > > On Tue, Jan 20, 2015 at 6:08 PM, Kapil Arya <[email protected]> wrote: > > > >> On Tue, Jan 20, 2015 at 6:00 PM, Benjamin Hindman < > [email protected]> > >> wrote: > >> > >>> What's the rush on committing this? Let's make sure all of the > committers > >>> get a chance to share their opinion on this please. > >>> > >> > >> This was assuming that most people would agree on the change. However, > if > >> that's not the case, then there is no hurry :-). > >> > >> > >>> I for one would love to hear from others that have used #pragma once in > >>> practice and hear any pros/cons from them. > >>> > >>> Also, while the > > to >> change was meant to preserve some > information, > >>> I'm not convinced that there is any information to preserve by > replacing > >>> all include guards with #pragma once, and otherwise I feel like we're > >> going > >>> to get just as many reviews where people have to tell you to switch to > >>> #pragma once rather than appropriately name the include guard. > >>> > >> > >> Good point. In this case, we can just do a mass update (if we agree to > the > >> change). > >> > >>> > >>> On Tue, Jan 20, 2015 at 5:04 PM, Kapil Arya <[email protected]> > wrote: > >>> > >>>> Hi All, > >>>> > >>>> This issue came up on several occasions. Since people seem to agree on > >>>> using "#pragma once" instead of "#define" guards that we have using, I > >>>> wanted to send a quick email to gather some consensus around it. If > >>>> everyone agrees about the switch, we can update the style guide and > >> start > >>>> using "#pragma once". > >>>> > >>>> The issue is tracked at > >> https://issues.apache.org/jira/browse/MESOS-2211 > >>>> and there is a review request at https://reviews.apache.org/r/30100/. > >>>> > >>>> Please note that this won't be a mass update. We should keep updating > >> the > >>>> files that are created/updated (similar in spirit to "> >" to ">>" > >>> change). > >>>> > >>>> If there are any concerns, please let us know. We would very much like > >> to > >>>> commit this by tomorrow and any feedback before that is highly > >>> appreciated. > >>>> > >>>> Best, > >>>> Kapil > >>>> > >>> > >> > > -- Dominic Hamon | @mrdo | Twitter *There are no bad ideas; only good ideas that go horribly wrong.*
