discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Converting from #ifndef/#define include guards to #pragma once globally
Date: Thu, 27 Feb 2014 14:57:53 -0500

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...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]