So I'm getting this error message in QTcreator, undefined reference to table for waypointModel. This seems to be a common problem, and I've tried the solutions suggested on this site. Everything from running Qmake again, rebuilding, cleaning. Going through my makefile and program.pro file. Every header and source file is separated and on its right place in both the makefile and program.pro file. Yet I still get the error.
My waypointModel class isn't the only class being derived from the model Class, could this be the problem?
I also got the error on my destructor, but this disappeared when I initialised it in the header file as so:
virtual ~WaypointModel(){};
Why this suddenly work I don't know, any suggestions as to what may be the problem?
EDIT:
I want to add that the WaypointModel class is almost a direct copy of another class that was already existing, derived from the same class, but with another name, some extra data variables etc. This class does not experience the problems I'm facing now, even tho my class is almost a direct copy of it.
#Header # My derived class, and the source of the problem it seems.
Class WaypointModel: public Model
{
public:
// some functions
private:
//constructor / destructor
WaypointModel(const int unsigned int a_waypointNumber );
virtual ~WaypointModel();
//some data
unsigned int m_waypointNumber;
};
Header2 #
A general class, used as a baseclass for all other model classes.
class Model: public objectclass //
{
public:
//some functions
protected:
//construtor / destructor
Model(const std::string& a_classname);
virtual ~Model();
};
Source file WaypointModel
WaypointModel::WaypointModel(const unsigned int a_waypointNumber )
:Model("Modelname"), m_waypointNumber (a_waypointNumber)
{
// somefunc
}
WaypointModel::~WaypointModel()
{
}
Related
I'm currently working on a project where everything is horribly mixed with everything. Every file include some others etc..
I want to focus a separating part of this spaghetti code into a library which has to be completely independent from the rest of the code.
The current problem is that some functions FunctionInternal of my library use some functions FunctionExternal declared somewhere else, hence my library is including some other files contained in the project, which is not conform with the requirement "independent from the rest of the code".
It goes without saying that I can't move FunctionExternal in my library.
My first idea to tackle this problem was to implement a public interface such as described bellow :
But I can't get it to work. Is my global pattern a way I could implement it or is there another way, if possible, to interface two functions without including one file in another causing an unwanted dependency.
How could I abstract my ExternalClass so my library would still be independent of the rest of my code ?
Edit 1:
External.h
#include "lib/InterfaceInternal.h"
class External : public InterfaceInternal {
private:
void ExternalFunction() {};
public:
virtual void InterfaceInternal_foo() override {
ExternalFunction();
};
};
Internal.h
#pragma once
#include "InterfaceInternal.h"
class Internal {
// how can i received there the InterfaceInternal_foo overrided in External.h ?
};
InterfaceInternal.h
#pragma once
class InterfaceInternal {
public:
virtual void InterfaceInternal_foo() = 0;
};
You can do like you suggested, override the internal interface in your external code. Then
// how can i received there the InterfaceInternal_foo overrided in External.h ?
just pass a pointer/reference to your class External that extends class InterfaceInternal. Of course your class Internal needs to have methods that accept InterfaceInternal*.
Or you can just pass the function to your internal interface as an argument. Something around:
class InterfaceInternal {
public:
void InterfaceInternal_foo(std::function<void()> f);
};
or more generic:
class InterfaceInternal {
public:
template <typename F> // + maybe some SFINAE magic, or C++20 concept to make sure it's actually callable
void InterfaceInternal_foo(F f);
};
I recently decided to export some of my functions to a static library (.lib). I also decided not to give the complete header files to the Users. I kept private and protected variables and methods out of it, as the end-users should not use them and should not have to include other headers for Class declarations.
Unexpectedly I ran into heap-corruption errors when creating instances of the Classes which I exported to the static lib.
This is my original header file:
// Original Header File
class CODBCHelper
{
public:
CODBCHelper();
virtual ~CODBCHelper();
public:
std::vector<UserData> getUserInformation();
private:
SQLHENV m_henv;
SQLHDBC m_hdbc;
SQLHSTMT m_hstmt;
};
Then I decided to take the private variables out, so that users of my .lib do not abuse them and do not have to include unnecessary SQL Header files:
// Minimized Header File
class CODBCHelper
{
public:
CODBCHelper();
virtual ~CODBCHelper();
public:
std::vector<UserData> getUserInformation();
};
I noticed that the sizeof Operation returns different values depending from where it is called.
Called in the .lib:
int size = sizeof(CODBCHelper);
// size is 12
Called in the linking project:
int size = sizeof(CODBCHelper);
// size is 1
Doing the following code in my linking project then causes a heap corruption (which happens probably because of wrong size calculations):
CODBCHelper* helper = new CODBCHelper;
Doing something like
class CODBCHelper
{
[...]
private:
char padding[12];
}
would solve the problem, but i think its really bad behavior and not maintainable at all.
So is there any way to tell the compiler how big the real Object (from the linked library) is going to be? Or is there any easy way of hiding declarations in header files that are not needed by users?
I don't see how "hiding unimportant members" is connected to removing them from class definition.
I guess, that you wanted to eliminate unnecessary dependencies from your code. This is a good technique - it reduces compilation time, makes your code more portable between different versions and much more.
The thing is, that you changed your class completely. If it was designed to have three private members:
SQLHENV m_henv;
SQLHDBC m_hdbc;
SQLHSTMT m_hstmt;
you cannot just remove them. This is not what "hiding implementation details" means.
Or is there any easy way of hiding declarations in header files that are not needed by users?
What you want is to use PIMPL Idiom:
//Minimized header file
class CODBCHelper
{
public:
CODBCHelper();
virtual ~CODBCHelper();
public:
std::vector<UserData> getUserInformation();
private:
struct InternalData;
InternalData* m_internal_data;
};
Then, in your .cpp file:
struct CODBCHelper::InternalData
{
SQLHENV m_henv;
SQLHDBC m_hdbc;
SQLHSTMT m_hstmt;
};
Now you change your implementation to use m_internal_data instead of each component separately. This is especially profitable if your software will be updated - it forbids clients to create code, that depends on implementation details of your types.
You may also want to read point 2. and/or 4. of this answer.
You could expose interfaces instead of classes + a factory class. That way your users don't see the construct of your actual classes and everything works fine.
For example, your users get this:
class ICODBCHelper
{
public:
virtual ~ICODBCHelper();
public:
virtual std::vector<UserData> getUserInformation();
};
class MyFactory
{
public:
ICODBHelper *CreateCODBHelper();
}
and you implement this:
class CODBCHelper : public ICODBHelper
{
public:
CODBCHelper();
virtual ~CODBCHelper();
public:
std::vector<UserData> getUserInformation();
private:
SQLHENV m_henv;
SQLHDBC m_hdbc;
SQLHSTMT m_hstmt;
};
Create an abstract class that is public with pure virtual methods, no data. Then create a factory/accessor to instantiate/access the actual object in your library code that is actually a derived/concrete class of the abstract class.
I am working on a little game engine but I got stuck at something. Explanation : I have two classes, cEntity And ObjectFactory :
cEntity
class cEntity:public cEntityProperty
{
Vector2 position;
Vector2 scale;
public:
cEntity(void);
cEntity(const cEntity&);
~cEntity(void);
public:
void init();
void render();
void update();
void release();
};
ObjectFactory
#include "cEntity.h"
#include <vector>
class ObjectFactory
{
static std::vector<cEntity> *entityList;
static int i, j;
public:
static void addEntity(cEntity entity) {
entityList->push_back(entity);
}
private:
ObjectFactory(void);
~ObjectFactory(void);
};
std::vector<cEntity> *ObjectFactory::entityList = new std::vector<cEntity>();
Now I am adding new cEnity to ObjectFactory in cEntity constructor but facing an error related to circular references: for using ObjectFactor::addEntity() I need to define the ObjectFactory.h in cEntity class but it creates a circular reference.
I think your code might have an underlying architectural issue given how you have described the problem.
Your ObjectFactory should be handling the cEntities, which in turn should be unaware of the "level above". From the description of the problem you are having, it implies that you're not sure what class is in charge of what job.
Your cEntitys should expose an interface (i.e. all the stuff marked "public" in a class) that other bits of code interact with. Your ObjectFactory (which is a bit badly named if doing this job, but whatever) should in turn use that interface. The cEntitys shouldn't care who is using the interface: they have one job to do, and they do it. The ObjectFactory should have one job to do that requires it to keep a list of cEntitys around. You don't edit std::string when you use it elsewhere: why is your class any different?
That being said, there's two parts to resolving circular dependencies (beyond "Don't create code that has circular dependencies in the first place" - see the first part to this answer. That's the best way to avoid this sort of problem in my opinion)
1) Include guards. Do something like this to each header (.h) file:
#ifndef CENTITY_H
#define CENTITY_H
class cEntity:public cEntityProperty
{
Vector2 position;
Vector2 scale;
public:
cEntity(void);
cEntity(const cEntity&);
~cEntity(void);
public:
void init();
void render();
void update();
void release();
};
#endif
What this does:
The first time your file is included, CENTITY_H is not defined. The ifndef macro is thus true, and moves to the next line (defining CENTITY_H), before it moves onto the rest of your header.
The second time (and all future times), CENTITY_H is defined, so the ifndef macro skips straight to the endif, skipping your header. Subsequently, your header code only ever ends up in your compiled program once. If you want more details, try looking up how the Linker process.
2) Forward-declaration of your classes.
If ClassA needs a member of type ClassB, and ClassB needs a member of type ClassA you have a problem: neither class knows how much memory it needs to be allocated because it's dependant on another class containing itself.
The solution is that you have a pointer to the other class. Pointers are a fixed and known size by the compiler, so we don't have a problem. We do, however, need to tell the compiler to not worry too much if it runs into a symbol (class name) that we haven't previously defined yet, so we just add class Whatever; before we start using it.
In your case, change cEntity instances to pointers, and forward-declare the class at the start. You are now able to freely use ObjectFactory in cEntity.
#include "cEntity.h"
#include <vector>
class cEntity; // Compiler knows that we'll totally define this later, if we haven't already
class ObjectFactory
{
static std::vector<cEntity*> *entityList; // vector of pointers
static int i, j;
public:
static void addEntity(cEntity* entity) {
entityList->push_back(entity);
}
// Equally valid would be:
// static void addEntity(cEntity entity) {
// entityList->push_back(&entity);}
// (in both cases, you're pushing an address onto the vector.)
// Function arguments don't matter when the class is trying to work out how big it is in memory
private:
ObjectFactory(void);
~ObjectFactory(void);
};
std::vector<cEntity*> *ObjectFactory::entityList = new std::vector<cEntity*>();
thank you for looking at my problem.
I have an object that is being dynamically created in my program. The creation is part of a loop and the first iteration works fine.
Upon creation, my object base class adds itself to a map.
Here is some sample code :
public class Base {
Base() {
// Add itself to a map
Data::objects[key] = this;
}
}
public class Derived : public Base {
// This ctor only initialize one int field.
Derived() : Base() {};
}
Kinda simple isn't it ?
In my code, I do Derived * d = new Derived(); and for some silly reason, I get a SIGSEGV.
I tried to debug it, but it doesn't even enters the ctor before crashing!
Here is my call stack so you can help me better:
Address: #0x002c0000
ntdll!RtlReleasePebLock()
Address: #0x0000000c at c:...\stl_deque.h:514
msvrct!malloc()
libstdc++-6!_Znwj()
fu87_ZSt4cerr(this=0xbc1ad8, e="//my object name//") at //my object name//.cpp
... Other are my lines.
Thank you, Micael
{enjoy}
Edit: Adding informations about the map
The map is located in a data class, statically.
// Data.h
class Data {
static map<int, Base*> objects;
}
// Data.cpp
#include "Data.h"
map<int, Base*> Data::objects;
// methods implementations
How can you corrupt the heap, how can I find a corruption has occured?
Has Data::objects been initialized prior to the creation of ANY of the usages of Base?
You are not guaranteed that the class object objects had been initialized whenever you have more than one translation unit (read, .cpp file) in the final link target, unless you've gone to special effort to ensure it.
Most people solve this problem by using a static class through which this initialization is guaranteed to have occurred on first use. Something like:
// untested code, typed in by hand, not compiled through a machine compiler.
class Base {
public: static addObject(Base* that);
Base::Base() { Base::addObject(this); }
};
class Derived: public Base {
Derived::Derived() {}
};
//
// and in the .CPP for Base
namespace /* hidden */ {
int object_number = 0;
map<int,Base*> *objects = NULL;
}
void Base::addObject(Base* that) {
// TODO: do something to avoid multi-thread issues if that is ever a concern
if (!objects) {
objects = new map<int,Base*>();
}
(*objects)[++object_number] = that;
}
You've probably corrupted the heap at some point prior to the allocation, which causes the crash. Try running with valgrind to see where you're going wrong
I have been developing this class for loading plugins in the form of shared objects for an application. I currently have thought of 2 ways of loading the file names of all the plugins to be loaded by the app. I have written an interface for loading file names. I have a few questions about how to improve this design. Please help. Thanks.
EDIT: Code change per feedback :D.
#include "Plugin.h"
//This class is an interface for loading the list of file names of shared objects.
//Could be by loading all filienames in a dir, or by loading filenames specified in a file.
class FileNameLoader
{
public:
virtual std::list<std::string>& LoadFileNames() = 0;
};
class PluginLoader
{
public:
explicit PluginLoader(LoadingMethod, const std::string& = "");
virtual ~PluginLoader();
virtual bool Load();
virtual bool LoadPlugins(FileNameLoader&);
virtual bool LoadFunctions();
protected:
private:
explicit PluginLoader(const PluginLoader&);
PluginLoader& operator=(const PluginLoader&);
bool LoadSharedObjects();
list<std::string> l_FileNames;
list<PluginFunction*> l_Functions;
list<Plugin*> l_Plugins;
};
Anything that seems ugly still? Thanks for the feedback anyway.
It looks to me like you have your functionality spread across the enum, FileNameLoader, and the PluginLoader classes.
My suggestion would be to make a PluginLoaderByFile class, and a PluginLoaderByDir class - possibly with one inheriting from another, or possibly with a common base class. This way you can define other subclasses including the necessary additional code, and keep it encapsulated, if necessary, down the track.
This also makes it easier to use e.g. the factory or builder patterns in future.
You created a fine interface, but then you don't use it. And you then store the file names in a private member l_FileNames.
I would change the PluginLoader constructor to accept a FileNameLoader reference and use that reference to load file names. This way you won't need the LoadingMethod in the PluginLoader class.
Write two classes that implement the FileNameLoader interface, one for each loading method.
edit:
class FileNameLoader
{
public:
//RVO will work right? :D
virtual std::list<std::string>& LoadFileNames() = 0;
};
class FileNameLoaderByFile : public FileNameLoader
{
public:
std::list<std::string>& LoadFileNames()
{
// ...
}
}
class FileNameLoaderByDirectory : public FileNameLoader
{
public:
std::list<std::string>& LoadFileNames()
{
// ...
}
}
class PluginLoader
{
public:
explicit PluginLoader(FileNameLoader& loader)
{
fileNames = loader.LoadFileNames()
}
virtual ~PluginLoader();
private:
list<std::string> fileNames;
};
As for your statement of the current problem.
U can use either
vector for params or
since u are using a string u can as well parse it using some delimiter (say " ", ",")
However I wouldn't let the params or method of loading be visible in the PluginLoader.
Instead would use a common/generic interface.