Coding style change proposal: #pragma once

[Ehsan Akhgari]

I'd like to switch our coding style to use #pragma once instead of #include
guards. #pragma once is supported on all compilers than can build our
source code, it is more concise, and it avoids possible name clashes in
#include guards (or adopting silly conventions for avoiding them), and it
can be used in both C and C++.

Does anybody have any concerns with that change? If not, I'll edit the
coding style and will file bugs to switch the in-tree usages of #include
guards with #pragma once.

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>

[Justin Lebar]

Not a concern, but the obvious question is: Do you have any idea how
this affects compile times?

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Ehsan Akhgari]

On 2012-10-29 7:56 PM, Justin Lebar wrote:
> Not a concern, but the obvious question is: Do you have any idea how
> this affects compile times?

It probably won't have any meaningful improvements, since all decent
compilers already seem to special case #include guards.

Ehsan

[Nicholas Nethercote]

On Mon, Oct 29, 2012 at 4:44 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> I'd like to switch our coding style to use #pragma once instead of #include
> guards.

http://stackoverflow.com/questions/787533/is-pragma-once-a-safe-include-guard/1946730#1946730
says:

"#pragma once does have one drawback (other than being non-standard)
and that is if you have the same file in different locations (we have
this because our build system copies files around) then the compiler
will think these are different files"

Is that a problem for Mozilla code?

Nick

[Robert O'Callahan]

On Tue, Oct 30, 2012 at 1:13 PM, Nicholas Nethercote <n.neth...@gmail.com
> wrote:

> "#pragma once does have one drawback (other than being non-standard)
> and that is if you have the same file in different locations (we have
> this because our build system copies files around) then the compiler
> will think these are different files"
>
> Is that a problem for Mozilla code?
>

It could be. On Windows files get copied from the source directory to
dist/include. So it seems to me that if "." is on the include path before
dist/include, it would be easy for some files to be included twice.

Rob
--
Jesus called them together and said, “You know that the rulers of the
Gentiles lord it over them, and their high officials exercise authority
over them. Not so with you. Instead, whoever wants to become great among
you must be your servant, and whoever wants to be first must be your
slave — just
as the Son of Man did not come to be served, but to serve, and to give his
life as a ransom for many.” [Matthew 20:25-28]

[Gregory Szorc]

On 10/29/12 5:52 PM, Robert O'Callahan wrote:
> On Tue, Oct 30, 2012 at 1:13 PM, Nicholas Nethercote <n.neth...@gmail.com
>> wrote:
>
>> "#pragma once does have one drawback (other than being non-standard)
>> and that is if you have the same file in different locations (we have
>> this because our build system copies files around) then the compiler
>> will think these are different files"
>>
>> Is that a problem for Mozilla code?
>>
>
> It could be. On Windows files get copied from the source directory to
> dist/include. So it seems to me that if "." is on the include path before
> dist/include, it would be easy for some files to be included twice.

In my ideal world, all include paths (actually, all paths given to the
compiler) are absolute, not relative. This is ideal because it saves the
build system from requiring execution within a specific directory. This
simplifies implementation and avoids ambiguity. It also has the nice
side-effect that you can execute compiler commands from anywhere and it
just works.

So, if part of this transition is normalizing all include paths to
absolute paths, +1 from me.

[Ehsan Akhgari]

How much work is that going to be? The work involved is not clear to me.

Ehsan

[Gregory Szorc]

I'm not sure. It might be easier to wait until the new build system
frontend files land and to convert include paths when we port C/C++
compilation to the new world: once we dynamically create make files, it
will be much easier to normalize everything to absolute paths.

[Mike Hommey]

On Mon, Oct 29, 2012 at 06:11:04PM -0700, Gregory Szorc wrote:
> On 10/29/12 5:52 PM, Robert O'Callahan wrote:
> >On Tue, Oct 30, 2012 at 1:13 PM, Nicholas Nethercote <n.neth...@gmail.com
> >>wrote:
> >
> >>"#pragma once does have one drawback (other than being non-standard)
> >>and that is if you have the same file in different locations (we have
> >>this because our build system copies files around) then the compiler
> >>will think these are different files"
> >>
> >>Is that a problem for Mozilla code?
> >>
> >
> >It could be. On Windows files get copied from the source directory to
> >dist/include. So it seems to me that if "." is on the include path before
> >dist/include, it would be easy for some files to be included twice.

Include path order doesn't even need to be involved. See below.

> In my ideal world, all include paths (actually, all paths given to
> the compiler) are absolute, not relative. This is ideal because it
> saves the build system from requiring execution within a specific
> directory. This simplifies implementation and avoids ambiguity. It
> also has the nice side-effect that you can execute compiler commands
> from anywhere and it just works.
>
> So, if part of this transition is normalizing all include paths to
> absolute paths, +1 from me.

It's not a problem of include paths being absolute or not, it's a
problem of files of identical content but with different inode being
included. A typical case would be:

Foo.cpp:
#include "Bar.h"
#include "mozilla/Foo.h"

Bar.h:
#include "Foo.h"

with Foo.h, Bar.h and Foo.cpp in the same source directory, and
mozilla/Foo.h is Foo.h, installed in dist/include/mozilla.

In such cases, that you use -I. or -I/full/path/to/the/src/dir doesn't
change anything.

Mike

[Ehsan Akhgari]

On 2012-10-30 2:23 AM, Mike Hommey wrote:
> It's not a problem of include paths being absolute or not, it's a
> problem of files of identical content but with different inode being
> included. A typical case would be:
>
> Foo.cpp:
> #include "Bar.h"
> #include "mozilla/Foo.h"
>
> Bar.h:
> #include "Foo.h"
>
> with Foo.h, Bar.h and Foo.cpp in the same source directory, and
> mozilla/Foo.h is Foo.h, installed in dist/include/mozilla.
>
> In such cases, that you use -I. or -I/full/path/to/the/src/dir doesn't
> change anything.

Well, in that case I think we can't really do much about this. So, I
guess this proposal is canned.

Ehsan

[Rafael Ávila de Espíndola]

> Well, in that case I think we can't really do much about this. So, I
> guess this proposal is canned.

I guess we could normalize how we include our own headers, but yes, it
does make the proposal quiet a bit harder.

>
> Ehsan

Cheers,
Rafael