|
From: | Marcus Müller |
Subject: | Re: [Discuss-gnuradio] Converting from #ifndef/#define include guards to #pragma once globally |
Date: | Fri, 28 Feb 2014 11:24:21 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
Hi Martin,
do not worry: No discouragement took place, and I've just added a few lines of doc to https://github.com/marcusmueller/include-guard-convert, and I'm totally happy about how much constructive feedback I've got from everyone! I really just agree with you that we shouldn't put to much energy in the dead-end discussion whether to migrate to #pragma once, since there are none in favour anymore :) Marcus On 02/28/2014 10:59 AM, Martin Braun wrote: 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. MThank 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_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio |
[Prev in Thread] | Current Thread | [Next in Thread] |