templates: separate interface from implementation (.inl, .tcc) #2094
Comments
|
Hello @pcasenove,
Regards, |
|
Hi, Regards, |
|
Hello @pcasenove,
Regards, |
|
With debug info on, I get: When I remove the ifdef (or provide the define HEADER_IMPL through sonar.cxx.defines) : I couldn't find any error or warning in the log From my understanding of the log: |
|
Hi @pcasenove, What I understood so far:
How are your settings:
Regards |
|
Hi, The hpp file is an inline implementation file. For gcc it is considered as a header. |
|
Hi, the plugin iterates over all source code files and analyze one after the other. If a source code file includes a header file this is also analyzed. In your case it seems that a cpp file calls With your compiler: How is Regards, |
|
Hi @guwirth I'm working with @pcasenove on this, let me clarify. We have a classical implementation of a template function (could be the same for any inline function) in a dedicated inline implementation file header.hpp. The function is declared in header.h and used in some main.cpp, like so: // header.h
#ifndef HEADER
#define HEADER
template<typename T>
void f();
#define HEADER_IMPL // The macro is set before including header.hpp
#include "header.hpp"
#undef HEADER_IMPL
#endif
// header.hpp
#ifdef HEADER_IMPL // This is an ifdef, not an ifndef!
template<typename T>
void f() {
// do something...
}
#endif
// main.cpp
#include "header.h"
int main(int argc, char *argv[]) {
f<int>();
return 0;
}Therefore, main.cpp includes header.h which itself includes header.hpp. The macro is set in header.h and tested in header.hpp, so the contents of header.hpp is usable. |
|
Hi, thx. I missed the Regards, |
|
In SonarQube UI, the LOC is set to 0. It seems that no analysis is done at all on the hpp file also. |
|
@pcasenove @wawane do you have the possibility to test cxx plugin 2.0. think the problem is solved with 2.0. You can download latest snapshot from here https://ci.appveyor.com/project/SonarOpenCommunity/sonar-cxx/branch/master/artifacts |
|
Hi Thanks |
|
Hi @pcasenove, we are testing cxx plugin 2.0 currently always with 7.9 LTS and latest 8.x (you see this in LOG files of Travis). End of April SonarSource is planning to release next LTS 8.9. So easiest would be to use 2.0. We didn't plan to do another 1.3 release. If no other possibility we have to verify if backport of bugfix is possible - but can take awhile. Focus is currently on next LTS. https://github.com/SonarOpenCommunity/sonar-cxx/wiki/Upgrade-the-Plugin Regards, |
|
Hi, If I comment the ifdef the file gets analyzed and I have a log like: No error or warning in the log file, only DEBUG messages Pierre |
|
@pcasenove thanks for the feedback, will verify it this week. |
|
Hello @pcasenove, I did a first test #2101 with your provided sample. What you can see in the LOG file: all three files are indexed main.cpp, header.h and header.hpp.
This explains also why you "see" the source code in case you set a global macro Regards, |
|
Hi @pcasenove and @wawane, did a short search https://stackoverflow.com/questions/1208028/significance-of-a-inl-file-in-c Others are using mostly a different file extension like Sample:
Regards, |
guwirth
changed the title
|
Dear @guwirth I would expect the extension to have no impact, but we can give a try to renaming the inline file to e.g. header.tcc. |
|
Hi, Pierre |
@pcasenove with 1.3 in |
|
Hi @wawane,
You are right, that the cxx plugin doesn't behave different. The point is that users can see from the file extension that they should not include the file directly. I had a look to GCC STL and Microsoft ATL/MFC library: Both don't add an inverted include guard. My question is still if this is really needed?
It also works exactly like in C++. If you compile My first idea was also to simply ignore the preprocessor directives ( #ifdef WIN32
void sample(uint32)
#else
void sample(uint64)
#endif
{
}My poposals:
// header.h
#ifndef HEADER
#define HEADER
template<typename T>
void f();
#define HEADER_IMPL // The macro is set before including header.hpp
#include "header.hpp"
#undef HEADER_IMPL
#endif
// header.hpp
#if defined(HEADER_IMPL) || defined(__CXX__) // This is an ifdef, not an ifndef!
template<typename T>
void f() {
// do something...
}
#endif
// main.cpp
#include "header.h"
int main(int argc, char *argv[]) {
f<int>();
return 0;
}Other ideas are welcome! Regards, |
|
Hi, I lost a bit of time (2 hours....) trying to make it work on the file on which sonar-cxx crashes... (but I saw opened bugs on this): As the parsing of the .h was failing, the hpp was not taken into account... |
|
Hi @pcasenove, template issue should be solved with #2102. please try it and give feedback.... Regards |
|
We've finally implemented |
|
@wawane explanation: In order for SonarQube to display source code, it must be assigned to a programming language, which is done via the file extension. Then SonarQube works through one file after the other and assigns "metrics" (LOC, Line is Executable, ...). To parse a source code file correctly, the cxx plugin must also read the header files to extract the macros from them. But the #include files are not treated as source code files in this step. In this case: main.cpp
header.h // #define HEADER_IMPL
header.hpp // #if defined(HEADER_IMPL)
header.hpp // #if defined(HEADER_IMPL)The cxx plugin works as it should. Securing the .tcc files via include guards is unusual? It also seems to make little sense to use different include-guards for the .tcc-files, since they are only temporarily valid. |
|
Hi |
|
I close this one. From cxx point of view everything is correct. Please reopen it if you have an idea how to improve plugin. |
Hello,
I'm looking for some guidance on how to configure sonar-cxx on a specific setup with template implementation.
Here is the setup:
In header.h, I have:
In header.hpp, I have:
#ifdef HEADER_IMPLThe issue I encounter is quite simple: when I launch sonar-scanner, it doesn't parse header.hpp at all.
If I add sonar.cxx.defines=HEADER_IMPL to the command line (or comment it), it is correctly parsed.
But this is not scalable: I have multiple headers files and can't update the sonar.cxx.defines to list all.
What is the best option or way to use sonar-scanner is such case ?
Thanks in advance for you help,
The text was updated successfully, but these errors were encountered: