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 >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
