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