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

[Martin Braun]

On 02/28/2014 10:02 AM, Marcus Müller wrote:
> Hi Martin,
> 
> "optimizable guards": #ifndef at start, matching #endif at semantic
> end-of-file; sorry to be unclear on that.
> These are the include guards gcc cpp recognizes as such, which
> suppresses repeated opening & parsing of that header. Agreeing, though,
> that this is least priority. Also, almost all our include guards are
> like this.
> 
> I think you're right on the "enough energy put into this" -- maybe I
> should've been more careful when explicitely asking for discussion...
> I guess  this kind of ends the discussion, then :) I'll put up a github
> repo for the tools I've generated so far, and leave the GR tree alone
> (as long as I don't find anything wildly disturbing).

Hey, I don't want to discourage discussions of any kind! Nothing wrong
at all with bringing things like this up.

M

> 
> Thank you all for your thought, extensive feedback and time!
> 
> Greetings,
> Marcus
> 
> 
> On 02/28/2014 08:58 AM, Martin Braun wrote:
>> On 02/27/2014 11:42 PM, Marcus Müller wrote:
>>> 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.
>> I think we're already putting more energy into this than it deserves :)
>> At least for blocks, gr_modtool creates header guards that consist of
>> the module- and the block name, which you should choose wisely anyway.
>> Little chance of collisions here.
>>
>> A script that would check for unique header guards wouldn't hurt. But
>> what are "optimizable guards"? I think we have much bigger cookies to
>> bake right now.
>>
>> M
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio