Re: [Discuss-gnuradio] Converting from #ifndef/#define include guards to #pragma once globally

[Marcus Müller]

Hi Tom, hi fellow GR crowd,

thanks for your feedback and being so considerate :)
Ok, I see all your points and in fact, by now, agree to them.
By the way, to add to your argumentative advantage here:
I didn't expect *any* compile time decrease; in fact, GCC documentation says that iff the 
#ifndef is the first and the #endif the last statement or preprocessor directive, then 
the preparse/compile time is *identical* to using #pragma once*, and my only indication 
for it improving compile speed is boost using it conditionally *only* when compiled with 
MSVC. To be honest, I did not benchmark gcc/cmake build times yet, but "they felt 
the same" before and after.

As I see things now, I'd just not convert the files to #pragma once. However, I 
do see usefulness in the possibility to analyze headers to find 'convertible' 
include guards, because it is a feasible method of ensuring that files don't 
have erroneous include guards.
Basically, with a little tweaking my conversion script could be used to do some 
QA on header files (and generate a report, or be run in a post-receive hook etc)
- checking for include guards (are there any headers that shouldn't have 'em?)
- checking for unique include guard names
- checking if include guards GCC-optimizable.

Greetings,
Marcus


*because the fact that the file is include-protected then is noted, and the 
file is never read again
On 02/27/2014 08:57 PM, Tom Rondeau wrote:
> On Sun, Feb 23, 2014 at 3:22 PM, Marcus Müller <address@hidden> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi Moritz,
> >
> > thanks :) I agree on the "let's not break builds for the pure beauty
> > of #pragma once" approach. I tried this only to find existing bugs,
> > and actually found very little; however, they could be completely
> > avoided by #pragma once, and therefore I do see value in using it. So
> > I humbly and slightly disagree with the "my editor does that for me"
> > approach.
> >
> > Since I couldn't find info on which compilers are minimally necessary
> > to build GR, I tried to figure out on my own(0). So far, I've not
> > quite come to any useful point. Boost uses the classical include
> > guards, but adds a #pragma once only for MSVC compilers(1) so those
> > might really profit from that. Reading the gcc 3.4 release notes (2)
> > suggests that prior to 3.4, #pragma once was but deprecated -- showing
> > a few warnings in an ancient compiler doesn't seem to be too bad ;)
> >
> > So I read on (3) and found out that in fact, #pragma once had problems
> > in gcc < 3.4 (3.2 being the oldest gcc I've actually witnessed in the
> > wild, these are not many) due to it not dealing with hard- and
> > symlinks properly. However, with our current source tree and build
> > methodology, this will not be critical. The only versions that would
> > actually produce warnings were some early gcc 3.3, after the problem
> > was found and before the pragma was un-deprecated again, so I think
> > you will hardly find someone using a compiler where this would do as
> > much as warn you that there is an deprecated pragma in use in the GNU
> > toolchain world.
> >
> > So. The question stays the same: just *how* weird can build platforms
> > for GR be? I don't have a raging clue what people use on their
> > embedded devices where they'd actually try to compile GR 3.7 for, so I
> > can't really make a stand here.
> >
> > Greetings,
> > Marcus
> >
> >
> > (0) If anyone knows how to get a non-interfering but working gcc3.2 on
> > a current fedora, let me know.
> > (1) o.O
> > (2) http://gcc.gnu.org/gcc-3.4/changes.html, search for #pragma once
> > (3) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11569
> > (4) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11569#c12
> > On 23.02.2014 20:03, Moritz Fischer wrote:
> > > Hi Marcus,
> > >
> > > some quick Google research found several contradictory sources.
> > > [1] calls it 'non standard but widely supported'. Since we build on
> > > weird platforms I think we should make absolutely sure that this is
> > > the way things should be done ^{TM}. Some other sources listed this
> > > as a potential speedup for compilation on Visual Studio. Discuss.
> > >
> > > Personally I don't have an issue with header guards because there
> > > exist plenty of plugins for {vim,emacs, whatever}, to do it for
> > > you.
> > >
> > > Happy hacking,
> > >
> > > Moritz
> > >
> > > [1] http://en.wikipedia.org/wiki/Pragma_once
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iQEcBAEBAgAGBQJTCliDAAoJEAFxB7BbsDrLieEH/1a76Tckl2wxu7Km8C3pwT5q
> > MkKlL0x9/z7NnxpKsiehHG3dQvE6w2Gt4VfS/CICDsVcU7jxYfVJHnOx7l+RLJ5w
> > ipU9ICKImQa+2Hn5L/2PYvwpW0JrkivGntJeiCt2UGP+Z/rBNLwuHUtSs8BR0FHO
> > uDCC8kvMIx9qUOBvNYwYAkRuXlFlxZHzpkNFfzzIK6gIMhN5mjRvKb93x3mJtfkd
> > dJR85OtxaKVFAz8kD9LEeKDLPa6DQtatfp2m07ghAlhdhyPbX+vyzqEfHhVq2p0Z
> > uDa3a5GqrWaA4hRn+Ypx6kB0gBN4nSycdM8cT3A5ad7cKf8jtarNOm1vYUhC/Ac=
> > =/8RU
> > -----END PGP SIGNATURE-----
>
> Ok, I wanted to wait until the conversation died down on this to see
> what everyone's thoughts were. From my perspective, because it's
> non-standard behavior, we aren't going to switch to using #pragma
> once. Because we are working on embedded systems, trying to use
> co-processors like DSPs, FGPAs, and GPUs, we don't want to find
> ourselves in a situation where a compiler or tool messes us up because
> we aren't using a standards-define way of handling these things. It's
> unlikely that will actually be a problem, but I don't want to add
> another potential problem for us to deal with.
>
> The #ifdefs aren't perfect, obviously, but it's easy to fix them if a
> problem occurs. So I don't find this to be broken behavior.
>
> On the other hand, I won't discourage the use of both. But until the
> standard changes, we'll continue with the #ifdef method of doing
> things.
>
> Thanks for the great discussion and feedback, though!
>
> Tom
>
> P.S. is compile time really that much of an issue? What are we talking
> about shaving off? Seconds over the course of the entire build? If the
> pragma method reduced our swig build times, now that would suddenly be
> a compelling argument...