The reason I want to do this is because I use the current class (assuming class Hoge) as a singleton, but only the functions in the next line of public: refer to Hoge.cpp, and the subsequent lines refer to main.cpp.Go to Definition (F12) to confirm.That's why I get scolded for not finding a function definition (but I don't get LINL2019 errors and I can run them).
More mysterious is that there are classes where this problem occurs and classes where it does not occur, and although the name of the class is different, sometimes the exact same description does not occur, so the mystery only deepens.
Also, the singleton class name uses the macro defined in define as follows:
#define SINGLETON_CLASS(T)classT
Class Hoge without this macro worked fine.
However, due to various circumstances, this specification must be done, and it is not necessary to write class Hoge, or it is also a mystery why problems occur or do not occur when you are simply replacing it with class T.
I tried using class view (class diagram) as a solution to the subject, but I have not been able to confirm the problem because there is no problem in class view.
[Resolution and results]
·Re-create the whole project: Failed
·Delete suo file ->Regenerate: Failed
·Change the order of functions: Failed (public: OK only next line)
·Change class name: Failed
Due to the above circumstances, we have reached the subject.
Thank you for your cooperation.
Dear @sayuri,Could you please provide me with the simplest code possible to reproduce the phenomenon?
//Hoge.h
#define DEFINETEST(T)class T
DEFINETEST (Hoge)
{
template<typename T>
class HogeTemplate
{
// Abbreviated
};
public:
void TestFunc1();// This line looks at function definitions successfully
voidTestFunc2();// Cannot find function definition after this line
};
// Hoge.cpp should have only TestFunc1 and TestFunc2 functions
F12 fails to move to definition, but compilation is successful.
#define SINGLETON_CLASS(T)classT
This coding convention seems to be the cause.The compiler parses the source code faithfully, but the IDE skips some analysis to balance it with the speed of analysis.
#define SINGLETON_CLASS class
and the coding convention, or if that is difficult, why don't you consider using an editor other than Visual Studio?
I was able to confirm the symptom.As I pointed out, IDE is just breaking the analysis.
// Question Status
#define SINGLETON_CLASS(T)class T
SINGLETON_CLASS(A){};
// Answer 1…Not resolved
#define SINGLETON_CLASS class
SINGLETON_CLASSA {};
// Answer 2…ANALYSISABLE
#define SINGLETON
SINGLETON class A {};
Please revise the coding convention around here (if possible) and if not, give up or use another editor.
Quoted from Comments:
"It says ""LINL2019 errors do not appear and can be executed,"" but does the purpose of the question mean that the IDE (Visual Studio) intelligence reports errors, although the program behavior can be compiled and linked as expected?"
Yes, you can compile, link, and run as expected, but if you say "Function definition not found", you will see a green wavy line in that area.
Short Answer: IntelliSense is not a complete C++ compiler.Simply ignore the IntelliSense error or give up using the Visual Studio editor.
As a precondition, Visual Studio's C++ Compiler (cl.exe) and IntelliSense are independent processing systems.There are cases where one side reports an error, but the other side has no problem.IntelliSense is often useless when deploying complex macros such as code during questioning.
To be honest, I don't recommend it, but you can use the macro __INTELLISE__ to determine if the IntelliSense process is in progress or if it is a normal C++ compilation process.
#define DEFINETEST(T)class T
# ifdef__INTERLISE__
class Hoge
# else
DEFINETEST (Hoge)
#endif
{
//...
};
Also see the Visual C++ Team Blog article Troubleshooting Tips for IntelliSense Slowness:
The IntelliSense compiler is not the build compiler
It is important, here, to call out that the IntelliSense compiler is different from the build compiler. We have made every effort to give these two compilers parity. (For more information about how this works with C++/CLI please check this blog post.)
However, there are still differences, and occasionally, a file that compiles without error using our build compiler will not compile properly with our IntelliSense compiler. Often, this is because the IntelliSense compiler has a more strict interpretation of the C++ standard than the build compiler. In these cases, you can usually work around this problem by fixing the error reported by the IntelliSense compillar. (In most cases, the build compiler will accept the more-conforming code being required by the IntelliSense compiler.)
Additionally, if you are targeting an architecture other than x86, you may notice that the IntelliSense compiler is always operating in x86 mode. This can produce errors that are very different to work around, and while these errors will not give you a present from the cause.
If you are unable to find a code workaround for your problems, there is one further stopgap measure that can help: the compiler macro __INTELLISENSE__, which is only defined when using the IntelliSense compiler. You can use this macro to guard code the IntelliSense compiler does not understand, or use it to toggle between the build and IntelliSense compiler.
First of all, if the cause can be identified as a target macro,
I omit it, but there are many reasons why it is reasonable to exclude it.
Regarding the symptoms,
1. You can predict that both class view and intelligence refer to the same symbol DB(pdb), so the result will be the same.
2. From my experience, I have an impression that I am not good at moving to definition especially for #define macros.You can write anywhere as long as it's the same.
If you want to know which header you're looking at,
3. The header file line you want to disclose, e.g.
# Right-click on the line such as include "foo.h" and select "Open document "foo.h" from the context menu that appears to open the appropriate file in the include path. You can find the location of the file by trying to "keep it as."
If possible,
4. I couldn't guess the meaning of this unnatural macro well, but if you can replace it with typeef, template, etc., it's more natural in C++ language.
Personally, I feel very uncomfortable replacing the language's essential identifiers (although I allow them to be debugged).
© 2024 OneMinuteCode. All rights reserved.