--
Thiago
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Do not use #pragma once; instead use the standard Google include guards. The path in the include guards should be relative to the top of your project tree.
When writing header (.h) files, use both standard include guards and #pragma once. See an existing header for the appropriate layout.
Hi,Interesting. According to Google C++ style guide "#pragma once" should not be used: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Windows_Code#Windows_Code:Do not use #pragma once; instead use the standard Google include guards. The path in the include guards should be relative to the top of your project tree.But Chromium style guide requires it to be used: http://dev.chromium.org/developers/coding-style:When writing header (.h) files, use both standard include guards and #pragma once. See an existing header for the appropriate layout.
That's because "#pragma once" can introduce subtle errors and is Windows-only optimization.
Victor Khimenko wrote:That's because "#pragma once" can introduce subtle errors and is Windows-only optimization.That’s not quite true.
GCC and Clang understand #pragma once, although it’s not necessary for them because they understand the #ifndef X #define X … #endif pattern and apply a similar optimization when they find it.
On Tue, Jul 10, 2012 at 12:59 AM, Mark Mentovai <ma...@chromium.org> wrote:
Victor Khimenko wrote:That's because "#pragma once" can introduce subtle errors and is Windows-only optimization.That’s not quite true.What exactly is not true? That it can introduce errors or that it's Windows-only optimization?
Yup. And they do it RIGHT. "#pragma once" does not.
On Tue, Jul 10, 2012 at 12:59 AM, Mark Mentovai <ma...@chromium.org> wrote:
Victor Khimenko wrote:That's because "#pragma once" can introduce subtle errors and is Windows-only optimization.That’s not quite true.What exactly is not true? That it can introduce errors or that it's Windows-only optimization?
Aren't #pragma's ignored by the compiler if they're unrecognized? (Although I've heard some major compilers for other platforms apparently also support it, though I've never tried it.)
GCC supports it - and this is exactly why it's dangerous. It breaks the
#define __need_size_t#include <cstddef>pattern. Which Windows uses very much, too, but there are you are supposed to just cope with the problem somehow.
On Tue, Jul 10, 2012 at 12:58 AM, Mehrdad Niknami <mnik...@chromium.org> wrote:
Aren't #pragma's ignored by the compiler if they're unrecognized? (Although I've heard some major compilers for other platforms apparently also support it, though I've never tried it.)
GCC supports it - and this is exactly why it's dangerous. It breaks the#define __need_size_t#include <cstddef>
pattern. Which Windows uses very much, too, but there are you are supposed to just cope with the problem somehow.
How is that different from regular include guards?
On Mon, Jul 9, 2012 at 2:34 PM, Victor Khimenko <kh...@chromium.org> wrote:
On Tue, Jul 10, 2012 at 12:58 AM, Mehrdad Niknami <mnik...@chromium.org> wrote:
Aren't #pragma's ignored by the compiler if they're unrecognized? (Although I've heard some major compilers for other platforms apparently also support it, though I've never tried it.)
GCC supports it - and this is exactly why it's dangerous. It breaks the#define __need_size_t#include <cstddef>
pattern. Which Windows uses very much, too, but there are you are supposed to just cope with the problem somehow.Breaks the pattern how? We add #pragma once to user-written headers that are meant to be included once and thus also have standard #include guards.
We don't use it in isolation or to change what would otherwise be a multiple-inclusion-safe header (of which there are a couple in Chrome, in the IPC subsystem) into something else.
PK
They work. "#pragma once" does not. Very easy to see.
They work. "#pragma once" does not. Very easy to see.$ cat test.c#define _ONE_#include "test.h"#undef _ONE_#define _TWO_#include "test.h"#undef _TWO_
On Tue, Jul 10, 2012 at 1:41 AM, Peter Kasting <pkas...@chromium.org> wrote:
On Mon, Jul 9, 2012 at 2:34 PM, Victor Khimenko <kh...@chromium.org> wrote:
On Tue, Jul 10, 2012 at 12:58 AM, Mehrdad Niknami <mnik...@chromium.org> wrote:
Aren't #pragma's ignored by the compiler if they're unrecognized? (Although I've heard some major compilers for other platforms apparently also support it, though I've never tried it.)
GCC supports it - and this is exactly why it's dangerous. It breaks the#define __need_size_t#include <cstddef>
pattern. Which Windows uses very much, too, but there are you are supposed to just cope with the problem somehow.Breaks the pattern how? We add #pragma once to user-written headers that are meant to be included once and thus also have standard #include guards.Right. If you know how "#pragma once" works then you can use it and produce correct can working program. Still it can turn correct program to uncompileable or, even worse, incorrect program. And that's dangerous.
Why <windows.h> is testing for something defined in the C file?
More often then not such defines are used not in C files, but in headers which include other headers.
That’s fine. If such a header winds up with #pragma once written into it, it’s an error and a bug, and the #pragma once should be removed immediately. That doesn’t render #pragma once useless.
On Tue, Jul 10, 2012 at 1:54 AM, Mark Mentovai <ma...@chromium.org> wrote:
That’s fine. If such a header winds up with #pragma once written into it, it’s an error and a bug, and the #pragma once should be removed immediately. That doesn’t render #pragma once useless.What makes it useless for Google3 is the fact that it does not improve compilation speed. Add to this the fact that it's dangerous and it's [rightfully] banned.
Where have I said that include guards are NOT "dangerous" or "error-prone"?
How is that different from regular include guards?
On Tue, Jul 10, 2012 at 1:54 AM, Mark Mentovai <ma...@chromium.org> wrote:That’s fine. If such a header winds up with #pragma once written into it, it’s an error and a bug, and the #pragma once should be removed immediately. That doesn’t render #pragma once useless.What makes it useless for Google3 is the fact that it does not improve compilation speed. Add to this the fact that it's dangerous and it's [rightfully] banned.
Situation with Chrome (which cares about MSVC) is different.
It's another problem: versatility. If you insist on saying that include guards must ALWAYS cover the whole file then they, of course, work in the same way as "#pragma once". But they can cover part of the file, too - and such use in incompatible with "#pragma once".
But they can cover part of the file, too
Folks who own remoting/, if you can fix this about your code, that'd be great.
If you're working in Chrome code, and your header is meant to be included only once, please use normal #include guards as well as #pragma once, until such time as someone definitively shows that newer versions of MSVC get no compile speedup from doing so. Folks who own remoting/, if you can fix this about your code, that'd be great. Thanks.
I think what you're misunderstanding is that #include guards guard against the #inclusion of current file, not other files.
As such, they are only called "include guards" if they cover the entire file.
If you're working in Chrome code, and your header is meant to be included only once, please use normal #include guards as well as #pragma once, until such time as someone definitively shows that newer versions of MSVC get no compile speedup from doing so. Folks who own remoting/, if you can fix this about your code, that'd be great. Thanks.
So, instead of adding more #pragma's which nobody is willing to stand up for (and measure), let's *remove* the existing ones, as well as the style guide rule.
And if they are designed to work with only part of the file then why they are not include guards?
Sure, my example omitted include guards for the simplicity, but it's easy to do:#ifdef _ONE_#ifndef TEST_H_ONE
As such, they are only called "include guards" if they cover the entire file.Why not?
--
Sounds to me like we should take it out and update the wiki.
PK
Can we get some data point on machines without SSD before going ahead with the removal? Obviously, this optimization wouldn't benefit us much if disk access was sufficiently fast.
- Ryosuke
On Tue, Jul 10, 2012 at 4:08 PM, Ryosuke Niwa <rn...@google.com> wrote:
Can we get some data point on machines without SSD before going ahead with the removal? Obviously, this optimization wouldn't benefit us much if disk access was sufficiently fast.The buildbots don't have SSDs afaik, and they didn't see a speedup.
Also, the next developer machines will all have SSDs.
Can we get some data point on machines without SSD before going ahead with the removal? Obviously, this optimization wouldn't benefit us much if disk access was sufficiently fast.
As this code actually increases complexity in some places,
On Tue, Jul 10, 2012 at 4:54 PM, Albert J. Wong (王重傑) <ajw...@chromium.org> wrote:As this code actually increases complexity in some places,Could you summarize an example or two?
Files that have comments explicitly explaining why #pragma once would cause issues
On Tue, Jul 10, 2012 at 5:35 PM, Albert J. Wong (王重傑) <ajw...@chromium.org> wrote:Files that have comments explicitly explaining why #pragma once would cause issues
Especially the first one of those confuses me... if the file is supposed to support multiple inclusion why does it have an include guard? Are users expected to manually undef the guard? That seems wrong. Not really your responsibility to fix this -- it's just weird.
(Also, I assume you nuked the portions of comments about #pragma once as part of your patch?)
On Tue, Jul 10, 2012 at 5:38 PM, Peter Kasting <pkas...@google.com> wrote:On Tue, Jul 10, 2012 at 5:35 PM, Albert J. Wong (王重傑) <ajw...@chromium.org> wrote:Files that have comments explicitly explaining why #pragma once would cause issues
Especially the first one of those confuses me... if the file is supposed to support multiple inclusion why does it have an include guard? Are users expected to manually undef the guard? That seems wrong. Not really your responsibility to fix this -- it's just weird.Yeah, I did't get it either and having to worry about #pragma once confused me further.
the revision that checked this in has more info, but basically (might want to hold your nose, these are IPC macros after all, but trust me this is better) the include guard is undef'd in one cc file.
--