#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
In the new svn 5621, there are *two* header guards in token.h. :DI 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.
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.
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"?Didn't know that, but yes, after searching the standards, this actually seems to be the case.
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.Feel free to do it then, but do it right. :)
disabling the plugin "HeaderFixup"
/*
* 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.
*/