0

I have a header file, let's call it SomeClass.h in which a class is defined as usual:

class SomeClass {
...
};

The implementation of SomeClass is in another file, say SomeClass.cpp.

Then I have another header file, say AnotherClass.h which tries to use the SomeClass class to define another class, as shown below.

#include <SomeClass.h>

class AnotherClass {
...
protected:
  std::unique_ptr<SomeClass> s;  // (*)
};

when I try to compile, I get the following error:

error: 'SomeClass' was not declared in this scope

but this is quite surprising, since CLion is not detecting this error and when I click on SomeClass in the instruction commented with // (*) above, CLion correctly goes to the definition of SomeClass in SomeClass.h

So the question is:

why is CLion seeing SomeClass while the compiler is not seeing it?

Community
  • 1
  • 1
Kubuntuer82
  • 1,128
  • 1
  • 14
  • 35
  • 2
    Does `SomeClass.h` include `Anotherclass.h` or include other headers that include it? – François Andrieux Jun 06 '18 at 18:01
  • You mean there might be a cyclic inclusion? – Kubuntuer82 Jun 06 '18 at 18:03
  • 1
    Yes, that's the most common cause of this type of problem. If this is the case, see https://stackoverflow.com/questions/625799/resolve-build-errors-due-to-circular-dependency-amongst-classes. – François Andrieux Jun 06 '18 at 18:05
  • Many thanks for this! It was difficult to see it because there was a chain of headers which at the end formed a loop (I could not write everything here because I needed to simplify the problem). But thanks to your suggestion I checked deeply and finally it's fixed... – Kubuntuer82 Jun 06 '18 at 18:15
  • Are you sure this is a duplicate? The difference here is that an IDE (in this case CLion) was capable of navigating to the class, which created the confusion. I am just curious, if you think it is a duplicate it's fine for me. – Kubuntuer82 Jun 06 '18 at 18:17
  • 1
    An IDE will be able to resolve types some of time despite the circular inclusion, depending on how it parses the headers. I understood the question as asking how to fix your problem, and the fact that CLion was able to determine the type being interesting but unimportant context information. If what you are actually asking about is how CLion manages to resolve your types, then it's not a duplicate and I'll retract the close. – François Andrieux Jun 06 '18 at 18:21
  • You understood correctly, the main purpose was to fix the problem, but I also was curious of why CLion was not detecting any error, but you already gave a good explanation in your last comment, which may even be considered as a general answer to my curiosity (about behaviour of IDEs in general). Thanks again... – Kubuntuer82 Jun 06 '18 at 18:25

0 Answers0