#pragma once usage to prevent unwanted inclusions from happening even once

[datadiode]

This implements the idea behind #159 (comment) in a generic way.
It works by allowing #pragma once to take a wildcard expression to sort out the unwanted include files.

Example from some project of mine, to prevent some inclusions which would otherwise cause cppcheck to abort prematurely:

#ifdef CPPCHECK
#   pragma once "boost/*"
#   pragma once "google/protobuf/*"
#   pragma once "*.pb.h"
#endif

Going with Cppcheck's --include option is particularly convenient for the purpose.

[firewave]

It is not possible to use C++11 since simplecpp still needs to support C++03.

Also using std::regex is highly discouraged because it is so slow that is essentially unusable in any production code.

[datadiode]

Would SRELL be an acceptable replacement for std::regex?

[firewave]

I guess it is sure to say that any third-party dependency is out of the question.

[datadiode]

That seems plausible.
Then I'd rather go for a simplistic wildcard match, preferably by reusing the fnmatch() from https://compressionratings.com/d_archiver_template.html.

[Tal500]

Would SRELL be an acceptable replacement for std::regex?

@datadiode @firewave FYI: this library is the state of the art solution for compile-time-baking of regexp engine in c++ (source: cppcon first presentation of Herb):
https://github.com/hanickadot/compile-time-regular-expressions

[danmar]

FYI: this library is the state of the art solution for compile-time-baking of regexp engine in c++

Thanks for the suggestion.

I think CTRE is awesome!! but it requires modern compilers. and minimum c++17 as far as I know.

[danmar]

I feel this Mask class is not very elegant imho.

• I don't feel it should inherit from std::string, it's not used as a std::string.
• I dont see the point to read the i flag from the string in the constructor like that instead of passing a parameter. Will there be unintentional case matching if the string contains a random "i" somewhere or not.
• the fnmatch shouldn't be a template function
• I don't see why match a const char* instead of a std::string.. seems redundant to call .c_str()

[danmar]

well it could be std::set<std::string> pragmaOnceMasks; .. instead of creating a Mask class what would be the downside to just provide a regular function like:

bool match(const std::string& mask, const std::string& value, bool i);

[danmar]

I don't see that #159 talks about pragma once Ideally it would be better to preprocess the macros properly instead... but I don't know how difficult it would be to reach that point.

I reopened the #159 I think I was too quick to close it before.

I have never seen this pragma once mask syntax was it something you invented? I would rather not add this if you invented this syntax.

[datadiode]

The invented extension to the #pragma once behavior intends to avoid a need to follow the last-resort idea of hardcoding the exclusion of boost headers like so, as mentioned in said comment:

+        if (header.rfind("boost/", 0) == 0)
+            continue;
+

#pragma isn't standardized. I don't think it is too wrong to overload it with some esoteric feature which is meaningless to other preprocessors. #pragma ignore_include may feel less wrong though.

[danmar]

to follow the last-resort idea of hardcoding the exclusion of boost headers like so, as mentioned in said comment:

That hardcoding does feel worse. However this simplecpp hack is not the ideal solution.

When I read #159 it does seem that we have many problems but missing defines is a major one. That is not a simplecpp bug. It should be the responsibility of the tool (i.e. cppcheck) to provide proper defines. We have some cppcheck ticket(s) about teaching cppcheck defines better.

If cppcheck command --library=boost is used can that somehow prevent that the boost headers are included? It could remove the boost include path(s) maybe. Using --library=boost is something we recommend already for cppcheck users.

[datadiode]

I did think of proposing them a command line option to tell cppcheck to ignore any include paths it picks up from a project file if they match some regular expression. Will go ahead with that idea.

[firewave]

I did think of proposing them a command line option to tell cppcheck to ignore any include paths it picks up from a project file if they match some regular expression. Will go ahead with that idea.

That already exists. It is the -i option.

[datadiode]

I did think of proposing them a command line option to tell cppcheck to ignore any include paths it picks up from a project file if they match some regular expression. Will go ahead with that idea.

That already exists. It is the -i option.

According to the usage information, -i applies only to source files so header files included by source files are not matched.

[firewave]

According to the usage information, -i applies only to source files so header files included by source files are not matched.

You are of course right. I might have been thinking of something else (and maybe something I needed at some point).

It might also play into https://trac.cppcheck.net/ticket/12359 and https://trac.cppcheck.net/ticket/13204.