redundant header guard in token.h

[ollydbg]

In the new svn 5621, there are *two* header guards in token.h.

Code

#ifndef HEADER_799C3ACA6BDBCBC9
#define HEADER_799C3ACA6BDBCBC9

/*
 * This file is part of the Code::Blocks IDE and licensed under the GNU General Public License, version 3
 * http://www.gnu.org/licenses/gpl-3.0.html
 */

#ifndef TOKEN_H
#define TOKEN_H

Any comments?

[MortenMacFly]

In the new svn 5621, there are *two* header guards in token.h.

I realised that, too. Will be "fixed" in a future commit (although it doesn't hurt). Thomas' auto-header plugin does not take comments at the beginning of a file into account.

[thomas]

...which is the correct thing to do. Said include guard is not the problem, but the comment line is.

Although gcc incidentially does remove comments before doing include guard optimisation, it isn't required to do so, and not all compilers do that. For include optimisation to work reliably, the only thing that is allowed to appear before and after the header guards is whitespace.

[MortenMacFly]

For include optimisation to work reliably, the only thing that is allowed to appear before and after the header guards is whitespace.

While in theory this is true, in practice (as you see) it works with comments on all compiler I know and the plugin does this "mistake" by far too often. I regularly disable it if I am working on 3rd party code.

So still: It would be nice if the plugin did it "wrong" and take comments into consideration. ;-)

[rcoll]

Although gcc incidentially does remove comments before doing include guard optimisation, it isn't required to do so, and not all compilers do that. For include optimisation to work reliably, the only thing that is allowed to appear before and after the header guards is whitespace.

Sorry for pushing in, since this is not really my area, but according to both the C and C++ standards (all versions), isn't a comment considered "whitespace"?

Ringo

[thomas]

Sorry for pushing in, since this is not really my area, but according to both the C and C++ standards (all versions), isn't a comment considered "whitespace"?

Didn't know that, but yes, after searching the standards, this actually seems to be the case.

[MortenMacFly]

Didn't know that, but yes, after searching the standards, this actually seems to be the case.

Sorry... but I have to...: :lol:
So Thomas... time to fix the bug in your nifty plugin. I'd love to keep it enabled all the time. I am your Fan #1 (as you know)... ;-)

[thomas]

So Thomas... time to fix the bug in your nifty plugin.

Feel free to do it then, but do it right.
I'll continue using it as it is, as I'm having no issues with the way it is now. But sure, feel free to write a fully fledged parser that will catch all special cases

[tigerbeard]

Sorry to revive this old topic, but after installing the Nightly April2021 the function of the OP somehow came to life keeps adding addtional head guards to files that already had them (after the initial comment).
I got rid of the unwanted feature by disabling the plugin "HeaderFixup". But there must be another way, because I never disabled any plugin before.

I would like to know if there is a setting that I can use to disable this behavior, so I can keep the plugin enabled. I tried Settings/editor/CodeCompletion/EnableHeaderCodeCompletion, but this did not do it. 

[Miguel Gimenez]

disabling the plugin "HeaderFixup"

Are you sure?. The plugin that adds the guards is "Header guard", and it is not configurable.

Code

/*
* Header guards for the lazy. Adds a header guard to every ".h" file that doesn't have one when saving.
* Filenames are hashed to a 64-bit hex number to support umlaut characters (and Kanji, Cyrillic, or whatever)
* regardless of file encoding, and regardless of what's legal as a C/C++ macro name
* Thomas sez: uz tis at yar own risk, an dun blam me.
*/

[tigerbeard]

Right, my bad.
Checking back, by accident I did not disable HeaderFixup but HeaderGuard just one line below.

Knowing that I wonder why this thread is from 2009 and my last version I used (2017) did not have that HeaderGuard.dll at all.
That  of couse explaines that I did not note that behaviour before.

Strange, but thanks.

[Miguel Gimenez]

That plugin, and some more I don't remember, were in the source tree in 2009, but they weren't part of the workspace until about a year ago (possibly after 20.03 release), so they weren't compiled by default.

EDIT: HeaderGuard, LogHacker, ModPoller and TidyCmt were added by revision 11935 on january 2020.