I have been developing a C++ game engine for a long time. I have never had any issues with the compiler, or anything like that, until I update to Xcode 8.3.1!
Suddenly, it appears that a default setting was changed when I updated that made it so that the compiler simply cannot handle circular references.
Does anyone know how to set this back, (I tried downgrading Xcode, and it still doesn't work!)
My circular referencing looks something like this:
I have a class called "Object" defined in my code
"Object" includes another class called "Renderer2D"
"Renderer2D" includes another class called "Renderable2D"
"Renderable2D" extends "Object"
My "Object" class:
#pragma once
#include "Graphics/2D/Renderer2D.h"
namespace kineticengine {
class Object {
public:
Object();
virtual ~Object() {}
virtual void render(graphics::Renderer2D* renderer) const;
};
}
My "Renderer2D" class:
#pragma once
#include "Renderable2D.h"
namespace kineticengine {
namespace graphics {
class Renderer2D {
protected:
Renderer2D() {}
public:
virtual void submit(const Renderable2D* renderable) {}; // Error here, "Unknown type name 'Renderable2D', did you mean 'Renderer2D'?"
};
}
}
My "Renderable2D" class:
#pragma once
#include "Renderer2D.h"
#include "../../Object.h"
namespace kineticengine {
namespace graphics {
class Renderable2D : public Object {
public:
Renderable2D() : Object() {}
virtual ~Renderable2D() {}
void render(Renderer2D* renderer) const override {
renderer->submit(this); // Error here "Cannot initialize parameter of type 'const kineticengine::graphics::Renderer2D *' with an rvalue of type 'const kineticengine::graphics::Renderable2D *'"
}
};
}
}
All of my errors are basically variations of "Unknown class [x]" where x is one of the other classes.
Any help would be appreciated!
Renderable2D.h is including Renderer2D.h before defining class Renderable2D, so when Renderer2D.h refers to class Renderable2D, it is not yet defined. Clang is behaving correctly.
One way to break this cycle is to not include headers if you're only going to refer to a class by pointer or reference. You then put a forward declaration for the class in instead of the include directive. This has the added bonus of speeding up compile time as well.
Related
i am on a vtk project
I wanted to write my own mouse interactor style
i writed this class
vtkInteractorStyleZoom.h
#include <vtkSmartPointer.h>
#include <vtkInteractorStyleTrackballCamera.h>
class vtkInteractorStyleZoom: public vtkInteractorStyleTrackballCamera
{
public:
static vtkInteractorStyleZoom* New();
vtkTypeMacro(vtkInteractorStyleZoom , vtkInteractorStyleTrackballCamera);
virtual void OnLeftButtonDown();
};
vtkInteractorStyleZoom.cpp
#include "vtkInteractorStyleZoom.h"
vtkStandardNewMacro(vtkInteractorStyleZoom);
void vtkInteractorStyleZoom::OnLeftButtonDown()
{
this->StartDolly();
}
and this the functions where i use this class
void ReadDICOMSeriesQt::on_ZoomButton_clicked()
{
vtkSmartPointer<vtkInteractorStyleZoom> Style =
vtkSmartPointer<vtkInteractorStyleZoom>::New();
ui->qvtkWidget->GetRenderWindow()->GetInteractor()-
>SetInteractorStyle(Style);
}
and when i compiled my project with cmake i had a this problem
CMakeFiles\ReadDICOMSeriesQt.dir/objects.a(ReadDICOMSeriesQt.cxx.obj): In function ZN15vtkSmartPointerI22vtkInteractorStyleZoomE3NewEv':
C:/VTK/VTK-7.0.0/Common/Core/vtkSmartPointer.h:117: undefined reference tovtkInteractorStyleZoom::New()'
i dont know if there is any problem with cmake (maybe i must change somethings in my CMakeLists.txt)
is there anyone who can help me ?
What you are missing is the constructor definition. The constructor must take no arguments, so that the object factory mechanism works. Make it private, because noone should call it directly.
You should also disable copy semantic of your class. I.e.
class vtkInteractorStyleZoom : public vtkInteractorStyleTrackballCamera
{
public:
static vtkInteractorStyleZoom* New();
vtkTypeMacro(vtkInteractorStyleZoom, vtkInteractorStyleTrackballCamera);
virtual void OnLeftButtonDown();
private:
vtkInteractorStyleZoom() { /* definition, if any */ }
vtkInteractorStyleZoom(const vtkInteractorStyleZoom&) = delete;
void operator =(const vtkInteractorStyleZoom&) = delete;
};
Also, you should #include <vtkObjectFactory.h> in the .cpp file -- that's where vtkStandardNewMacro() is defined.
Then make sure that the caller module (ReadDICOMSeriesQt) links against the library which vtkInteractorStyleZoom is part of.
I have some shared files that I want to use between two programs A and B that have the same compile target and are very identical.
So, I tried to separate them into two namespaces and create a shared namespace for the shared files
Interfaces.h
namespace ns_s {
class SomeClass;
class IFoo {
virtual void bar(SomeClass*) = 0;
};
}
SomeHeaderinA.h
#include "Interfaces.h"
namespace ns_a {
using namespace ns_s;
class Foo : public IFoo {
virtual void bar(SomeClass* p) override { ... }
};
}
However the compiler is complaining now that my member function bar does not override anything, so it seems to not see the interface implementation.
Why is that the case? And why does the compiler not already complain about a missing class IFoo?
EDIT:
Looks like I missed an essential part that contributes to the problem. I pre-declared a class that is a parameter of the interface method. Now that I ahve a pre-declaration in namespace shared and an actual declaration in namsepace A those things are not the same anymore.
Is there a good way to fix this? Only a small subset of interfaces have arguments that are defined in one or the other namesapce (A or B), so I could leave different implementations in each of them, but it would be nice to have it all in the shared space if possible in a clean fashion.
Here is a link
http://coliru.stacked-crooked.com/a/79fa58e50e7b8637
Problem
As shown in the linked code, the problem is caused by SomeClass.
The line
class SomeClass{};
declares and defines SomeClass in namespace ns_a. It does not define SomeClass in namespace ns_s.
The declaration of class ns_s::IFoo::bar uses ns_s::SomeClass.
The declaration of class ns_a::IFoo::bar uses ns_a::SomeClass.
That's the override is an error.
Solution
You can fix it by:
Removing the definition of SomeClass from ns_a, or
Using ns_s::SomeClass in the declaration of ns_a::IFoo::bar.
namespace ns_a {
using namespace ns_s;
class Foo : public IFoo {
virtual void bar(SomeClass* p) override {}
};
}
or
namespace ns_a {
using namespace ns_s;
class SomeClass{};
class Foo : public IFoo {
virtual void bar(ns_s::SomeClass* p) override {}
};
}
I am jumping through hoops to reduce inheritance.
I read one similar question here. It shows how the issue can be resolved using a base class. I try to loose inheritance, so I am looking for something different - more along the lines of annotation.
I create and compile a template class with one specialisation (normal). The method that requires the template is in the header (Mixer.hpp). The method that does not require the template is in the cpp file (Mixer.cpp). When compiled into a static library, the cpp part only gets compiled as one specialisation (Mixer<normal>). The compiler does not know about (awsome) at that time. Importing the resulting static library into another project and attempting to create a different generic (awsome) class results in a linker error because obviously the library does not contain that method identifier (Mixer<awesome>::noTemplateInvolved). However the code for the normal implementation is as good as any so really the linker could just link to the existing source of the other template version (Mixer<?dontcare?>::noTemplateInvolved). All that the compiler has to do is to mark it appropriately for the linker.
Here is source code that results in a linker error:
//Target compiled to Provider.lib
//Mixer.hpp
#pragma once
#include <iostream>
using namespace std;
struct normal { static void log() { cout << "normal\n"; } };
template<typename output = normal>
class Mixer
{
public:
void callingTemplate();
void noTemplateInvolved();
};
template<typename output>
void Mixer<output>::callingTemplate() { output::log(); }
//Mixer.cpp
#include "Mixer.hpp"
void Mixer<>::noTemplateInvolved()
{
cout << "noTemplateInvolved\n";
}
//Target Compiled to User.exe
//This target imports Provider.lib
#include <Provider\Mixer.hpp>
#pragma comment(lib, "Provider.lib")
struct awsome { static void log() { cout << "awsome\n"; } };
int main()
{
Mixer<> n;
n.callingTemplate();
n.noTemplateInvolved();
Mixer<awsome> a;
a.callingTemplate();
a.noTemplateInvolved(); //linker error here
return 0;
}
The class Mixer<awsome> can link to the method callingTemplate because its definition is in the header and the compiler creates that function. At User.exe compile time the definition of noTemplateInvolved is hidden from the compiler. The compiler can not create that method and linking has to fail.
There are three solutions that I am aware of.
move the definition of noTemplateInvolved to the header.
include the cpp file
inherit from a baseclass
I am looking for another solution. The body of noTemplateInvolved really has nothing to do with the template. I would like to annotate the method in the header. I want the compiler to know it should always use the same base implementation regardless of the template.
Is that at all possible?
EDIT: Annotated that boring paragraph at the beginning a bit.
The answer turns out to be a base class as suggested in the comments. One of the reasons I wanted a base class is that I did not want to refactor. Refactoring using a base class is actually really simple.
Rename the original class to original_base.
Inherit from original_template inherits from original_base. Make sure to copy the contructor and pass through all the arguments to the base class.
The statement using original = original_template<your default case here> ensures that no other source code has to be modified just yet.
Applied to the example above I ended up doing something like this:
//Target compiled to Provider.lib
//Mixer.hpp
#pragma once
#include <iostream>
using namespace std;
struct normal { static void log() { cout << "normal\n"; } };
class Mixer_Base
{
private:
int mixcount;
public:
Mixer_Base(int count);
void noTemplateInvolved();
};
template<typename output = normal>
class Mixer_tempalte : public Mixer_Base
{
public:
Mixer_tempalte(int count) : Mixer_Base(count)
{}
void callingTemplate();
};
template<typename output>
void Mixer_tempalte<output>::callingTemplate()
{
output::log();
}
using Mixer = Mixer_tempalte<>;
//Mixer.cpp
#include "Mixer.hpp"
void Mixer_Base::noTemplateInvolved()
{
cout << "noTemplateInvolved\n";
}
Mixer_Base::Mixer_Base(int count) : mixcount(count)
{}
//Target Compiled to User.exe
//This target imports Provider.lib
#include <Provider\Mixer.hpp>
#pragma comment(lib, "Provider.lib")
struct awsome { static void log() { cout << "awsome\n"; } };
int main()
{
Mixer n(4);
n.callingTemplate();
n.noTemplateInvolved();
Mixer_tempalte<awsome> a(3);
a.callingTemplate();
a.noTemplateInvolved();
return 0;
}
In a way an annotation feels just like the base class feels. Everything in the base class is now annotated the way I wanted it to be, though this does not reduce inheritance.
I'm trying to build a solution which has three files. With main.cpp it is four files.
Entity.h
#pragma once
#include "SystemBase.h"
namespace Engine {
class Entity {
public:
Entity() { }
void s(SystemBase* sb) { }
};
}
SubscribersList.h
#pragma once
#include "SystemBase.h"
#include "Entity.h"
namespace Engine {
class SubscribersList {
friend SystemBase;
public:
SubscribersList() { }
void f(Entity* e) { }
};
}
SystemBase.h
#pragma once
#include "SubscribersList.h"
#include "Entity.h"
namespace Engine {
class SystemBase {
public:
SystemBase() { }
void g(Entity* e) { }
private:
SubscribersList m;
};
}
Don't focus on the body's of methods in the headers. It is just to keep things simple. I found two ways to build the solution.
1. Write the word class before all class names. But it crashes when I try to separate the realization from prototypes.
2. Write all code in one file.
I don't/won't write the keyword class before all class names to build the solution, and certainly I don't/won't write a big project in one file. So why I can't build it? What is the magic?!
To understand the problem of cyclic header dependency we first need understand the difference between a class declaration and definition and the concept of incomplete types.
A prototype or forward declaration of a type Type is written as:
class Type;
Such a forward declaration allows you to create pointers and reference to that type.
You cannot however instantiate, dereference pointers to or use a reference to Type until its full type is declared.
A declaration for Type could be written as:
class AnotherType;
class Type {
public:
void aMemberFunc();
private:
AnotherType *m_theOtherThing;
};
Now we have the declaration instances can be created and pointers to Type can be dereferenced.
However before m_theOtherThing is dereferenced or instanciated AnotherType must be fully declared.
class AnotherType {
Type m_aType;
}
Should do, which gives us both the full declaration and definition of AnotherType.
That allows to continue on to write the definition of Type::aMemberFunc:
void Type::aMemberFunc() {
m_theOtherThing = new AnotherType();
}
If instead of presenting this code to the compiler in this order we instead presented the full declarations of Type and AnotherType up front:
class Type {
public:
void aMemberFunc();
private:
AnotherType *m_theOtherThing;
};
class AnotherType {
Type m_aType;
}
Then AnotherType *m_theOtherThing; will fail to compile as AnotherType has not been declared or forward declared by that point.
Switching the order gives:
class AnotherType {
Type m_aType;
}
class Type {
public:
void aMemberFunc();
private:
AnotherType *m_theOtherThing;
};
Now Type m_aType; will not compile as Type has not been declared. A forward declaration would not do in this case.
Using #pragma once instead of header guards does not in anyway change the problem. #pragma once only ensures the header is include just once it does not effect the order the compiler processes the code otherwise. It certainly does not allow the compiler to ignore undefined types when it reaches them.
For this kind of class structure there is no way for the compiler to be able to process it without the use for forward declarations.
So, i started learning C++ about a year ago, i learned Java C# and VB.NET before it.
As it is now, i would consider myself a advanced C++ coder. However, theres one thing i dont quite get. The linking process. And heres the problem.
Right now, im coding a XNA-like library for Game development, with a basic Component System -
but i get Compiler errors when building it, C++ pretending it doesnt know a specific type, in this case, the GameComponent class doesnt know the ComponentSelector class (and vice versa), although its correctly included and typed. Im gonna show you my two header files, hopefully you can help me out.
ComponentSelector.hpp:
#ifndef COMPONENTSELECTOR_HPP
#define COMPONENTSELECTOR_HPP
#include<sem/System/Types.hpp>
#include<sem/System/GameComponent.hpp>
#include<vector>
namespace sem
{
class ComponentSelector
{
public:
GameComponent* getComponent1(); //GameComponent does not name a type
GameComponent* getComponent2(); //GameComponent does not name a type
GameComponent* getComponent3(); //GameComponent does not name a type
void addComponent(GameComponent* item); //GameComponent does not name a type
void removeComponent1();
void removeComponent2();
void removeComponent3();
void clearList();
private:
std::vector<GameComponent*> m_Components;
protected:
};
}
#endif // COMPONENTSELECTOR_HPP
GameComponent.hpp:
#ifndef GAMECOMPONENT_HPP
#define GAMECOMPONENT_HPP
#include<sem/System/ComponentSelector.hpp>
#include <sem/System/Types.hpp>
namespace sem
{
class GameComponent
{
public:
virtual void load() = 0;
virtual void unload() = 0;
virtual void update() = 0;
virtual void draw() = 0;
ComponentSelector* m_Selector; //ComponentSelector does not name a type
SEMlong getID();
SEMstring getName();
SEMstring getType();
private:
SEMlong m_ComponentID;
SEMstring m_ComponentName;
SEMstring m_ComponentType;
protected:
};
}
#endif // GAMECOMPONENT_HPP
Any solution and tips would be greatly appreciated.
You need a forward declaration for class ComponentSelector in your GameComponent class declaration:
// Remove this: #include<sem/System/ComponentSelector.hpp>
#include <sem/System/Types.hpp>
namespace sem
{
class ComponentSelector; // Note the forward declaration added!
class GameComponent
{
// ...
ComponentSelector* m_Selector; // Compiles now!
// ...
I'd recommend to do the same in the ComponentSelector declaration header vice versa. Include the full class declarations then, where you are going to use any members (this is in the compilation units i.e. .cpp-files usually).