I have two classes:
class Object {
public:
Object();
virtual void update();
virtual void draw();
private:
protected:
int x, y, tick;
}
and
class Unit : public Object {
public:
Unit();
void update();
private:
protected:
}
I then define the constructors and functions in sepparate .cpp files.
Here's the definitions for Object:
Object::Object() {
x = y = 0;
};
Object::update() {
tick ++;
};
Object::draw() {
// All my draw code is in here.
};
And Unit:
Unit::Unit() : Object() {
};
Unit::update() {
Object::update();
// Then there's a bunch of movement related code here.
};
Everything works fine individually, but I run into a problem when trying to call functions from within a vector.
vector<Object> objects;
I then do this in my void main():
for (int i = 0; i < objects.size(); i ++) {
objects[i].update();
objects[i].draw();
};
This draws everything fine, but it only calls the Object verson of update() not the version as defined by the derived class. Do I have to make a vector for each type that I derive from the Object class for it to work, or is there another way to call the derived functions?
Thanks in advance - Seymore
Yes, it calls methods of class Object, because you have a vector of class Object objects:
vector<Object> objects; // stores instances of class Object
The possible solution is to use a vector of pointers:
vector<Object*> objects;
objects.push_back( new Unit() );
and then call though pointers:
for (int i = 0; i < objects.size(); i ++) {
objects[i]->update();
objects[i]->draw();
}
If you want to use object oriented polymorphism in C++ (with the meaning : you have a base class and derived classes and at runtime you can come across any off those) you must use pointers.
vector<Object *> objects;
That means manual memory management (but you can use shared_pointers or http://www.boost.org/doc/libs/1_35_0/libs/ptr_container/doc/ptr_container.html), and possibly a very slight loss of performance (because of one extra dereferencing and v-table, however you shouldn't really care about it). And don't forget to make your methods virtual ;)
I think this is why I rarely use on my daily work object oriented programming as I learned it at school ;) I use heritage, but don't mix mother and daugther classes in the same containers (and I use templates for many interfaces).
Related
So I am quite confused about copy constructors in C++. I have the following code:
class creature /* abstract class*/
{
private:
string name;
int longevity;
creature_society * cs;
public:
creature(int,int,int,creature_society*);
//creature(const creature&);
virtual ~creature();
virtual int is_a_good() =0;
};
class good_creature : public creature
{
public:
good_creature(int,int,creature_society*);
//good_creature(const good_creature&);
~good_creature();
int is_a_good() //returns 1
};
class bad_creature : public creature
{
public:
bad_creature(int,int,creature_society*);
//bad_creature(const bad_creature&);
~bad_creature();
int is_a_good(void); //returns 0
}
So I have an abstract class called creature , a good_creature and a bad_creature which are a children class of creature .
At my program I also have an array called society which has type of creature* objects. If my creature through a condition is defined as good, I allocate space for it and store it in society array as good_creature. The same happens for bad creature. I construct it as described in the following code:
society = new creature*[M];
for(i=0;i<M;i++)
{
if(condition)
society[i] = new good_creature(L,good,this);
else
society[i] = new bad_creature(L,bad,this);
}
So I have to make a pure virtual function: creature::clone(int position) which if it's either a good_creature or a bad_creature, it has to delete the society[pos] and make a copy of the society[pos-1] through a copy constructor.
So for example my good_creature::clone(int position) is like this:
void good_creature::clone(int position)
{
int cop_pos=position -1; //getting the position before that in order to copy it
delete society[pos];
society[pos] = new good_creature( *society[cop_pos] );
//....
}
I get an error because society[cop_pos] is of type creature*. I tried casting it to good creature but unfortunately I keep getting errors. Is it because I am not calling the copy constructor right, is it because I am not casting right? Any ideas? This has been buffling me for 2 days. Keep in mind I' m a newbie and might have done something wrong.
Also I don't need to define my own copy constructor since all the elements in society[i] point at the same object that is defined by creature_society * cs, so I'm trying to use the default constructors since I do not need deep copy.
Thanks for your time.
UPDATE
A class I forgot to mention and the way I construct society
class creature_society
{
private:
int N; // number of the creatures we want to be made in society
creature ** society;
public:
creature_society(int,int);
~creature_society();
};
You don't know if society[cop_pos] is the correct type, so you cannot safely cast. A better solution is to use a virtual function to create a copy
class creature {
public:
virtual creature* clone() const = 0;
...
};
class good_creature {
public:
good_creature* clone() { return new good_creature(*this); }
...
};
//Similar for bad_creature (and any other derived classes)
In your case you'd call it like this:
society[pos] = society[cur_pos]->clone();
There's no need to know the type of the object you're cloning. The virtual function call takes care of that for you. Note that good_creature::clone returns a good_creature* instead of a creature*. This is a valid overload. A virtual function overload is allowed to return a derived class. In this case you could have it return a creature* as well.
Use polymorphism and virtual dispatch to do the work for you.
Define a clone virtual function in creature class.
class creature
{
virtual creature * clone() = 0;
}
and then override it in children:
class good_creature: public creature
{
virtual creature * clone() override
{
return new good_creature(*this);
}
}
and similar for bad_creature.
Then use it:
society[pos] = society[pos - 1]->clone();
Side note: your design seems to influenced by languages like Java. This is not a (modern) C++-style. For example, in modern C++ ownership is better expressed by unique_ptr instead of pointers. This would make code cleaner and much safer.
The problem is that society is an array of creature, not of good creature, so the copy constructor doesn't apply.
You can define a constructor for good_creature and for bad_creature taking as argument a creature:
good_creature(const creature&);
I have a class (Geometry) that implements an interface (LinkList). The code at the bottom of my example is obviously wrong, so I'm looking at implementing std::enable_shared_from_this. Can Geometry safely inherit from std::enable_shared_from_this<LinkList> and can I safely change the getLinkList() method to shared_from_this()? What happens if my Geometry class has multiple interfaces that it inherits, can I do this for all of the interfaces?
class Link
{
public:
std::string getName() { return "the name"; }
};
class LinkList
{
public:
virtual Link* getLink(int id) = 0;
virtual int size() = 0;
};
class Geometry : LinkList
{
private:
int state;
public:
void doSomething() { state = 1; }
virtual Link* getLink(int id) { return new Link(); }
virtual int size() { return 1; }
std::shared_ptr<LinkList> getLinkList() { return std::shared_ptr<LinkList>(this); }
};
void printList(std::shared_ptr<LinkList> linkList)
{
for (int i = 0; i < linkList->size(); i++)
{
std::cout << linkList->getLink(i)->getName() << std::endl;
}
}
void main()
{
Geometry* geom = new Geometry();
printList(geom->getLinkList());
geom->doSomething(); // Error here
}
The code at the bottom of my example is obviously wrong
The code there is not obviously wrong, the bug is in getLinkedList which gives ownership of this to a shared_ptr causing it to be deleted when the printList returns and the last shared_ptr object goes out of scope. So the last line of the example is rather non-obviously wrong, because the previous line subtly deleted the object.
Can Geometry safely inherit from std::enable_shared_from_this<LinkList>
Yes, it's just a base class. It's nearly always safe to inherit from it (that doesn't mean you can use it safely though!)
and can I safely change the getLinkList() method to shared_from_this()?
Only if the Geometry object is owned by a shared_ptr, and in your code it isn't:
Geometry* geom = new Geometry();
You need to store the pointer in a shared_ptr (preferably immediately when you create it) for the enable_shared_from_this base class to be usable, so this should be OK:
auto geom = std::make_shared<Geometry>();
printList(geom->shared_from_this());
geom->doSomething();
(Of course using shared_from_this() is pretty pointless there, because you already have the sahred_ptr anyway and could just do printList(geom)).
What happens if my Geometry class has multiple interfaces that it inherits, can I do this for all of the interfaces?
No, if the class has multiple enable_shared_from_this base classes then the shared_ptr constructors won't know which one to initialize. I think you'll get an error due to ambiguity, or if not the enable_shared_from_this base classes will all hold an empty weak_ptr making them useless.
Update:
You could make Geometry derive from enable_shared_from_this<Geometry> (not from enable_shared_from_this<LinkList> and not from every interface), and define:
shared_ptr<LinkList> Geometry::getLinkList()
{
return shared_from_this();
}
The object returned by shared_from_this() will convert implicitly to shared_ptr<LinkList>. You still need this to be owned by a shared_ptr in the first place though.
i am pretty sure this is a simple question for a long time c++ user, this should be a pattern or the problem should be solved in any other way but given i am Python developer and a total novice with c++ i don't know how it's usually done.
Suppose that i have a class where i want to store a pointer to an object that can be of 1 of two different classes that respects an interface, for example:
class AllPlayers
{
public:
virtual void play();
};
class VlcPlayer: public AllPlayers
{
public:
virtual void play();
};
class Mplayer: public AllPlayers
{
public:
virtual void play();
};
class MyMediaPlayer
{
public:
MyMediaPLayer(int playerType);
AllPlayers m_player;
};
MyMediaPlayer::MyMediaPlayer(int PlayerType)
{
if (PlayerType == 0) {
VlcPlayer tmp_player;
m_player = static_cast<AllPlayers> (tmp_player);
}
else {
Mplayer tmp_player;
m_player = static_cast<AllPlayers> (tmp_player);
}
}
MyMediaPlayer test(0);
test.play();
First, i know this would not work and that it seems pretty normal why but how could i get this effect? i would like to have a member of a class for what i am going to use ever the same methods, implemented using a interface and i would like to avoid trying to cast to every of the derived classes every time i am going to use one of his methods.
C++ is value-based, i.e., if you create an object of a given type you really have an object of this type. This doesn't play nicely with dynamic polymorphism. To get dynamic polymorphism you use a pointer or a reference to the actual object. To also get the life-time straight you typicslly allocate the corresponding object on the stack (make sure your base class has a virtual destructor if you ever release an object of a derived type using a pointer to the base). With this, you should be all set: just call a virtual function of the base class through a pointer to rhe base: When you overridethe function in the derived class this is the function which is called.
If you write
AllPlayers m_player;
that is going to be an instance of AllPlayers and cannot be an instance of a class that derives from it.
You should instead use a pointer and allocate the class on the stack.
For example:
class MyMediaPlayer
{
public:
MyMediaPLayer(int playerType);
~MyMediaPLayer();
AllPlayers m_player;
};
MyMediaPlayer::MyMediaPlayer(int PlayerType)
{
if (PlayerType == 0) {
m_player = new VlcPlayer;
}
else {
m_player = new Mplayer;
}
}
MyMediaPlayer::~MyMediaPlayer()
{
if (0 != m_player) {
delete m_player;
m_player = 0;
}
}
As suggested by #xception use of unique_ptr may relieve you from having to write code to deallocate the instance.
As correctly pointed out by #DietmarKühl you should always declare a virtual destructor in a root class (a base class that does not itself derives from some other class) as is the case with AllPlayers.
class AllPlayers
{
public:
virtual ~AllPlayers();
virtual void play(); // note: this should probably be pure virtual.
};
The reason this will not work is colloquially known as Object Splicing. (Or, for those Harry Potter readers out there, Object Splinching)
Let's look at an example:
class Foo
{
public:
int bob;
float fred;
// Foo(const Foo& otherfoo); // implicit copy constructor
};
class Bar : public Foo
{
public:
double gabe; // gabe newell is fat
char steve; // steve jobs is thin
// Bar(const Bar& otherbar); // implicit copy constructor
};
int main()
{
Foo f;
Bar b;
f.bob = 10;
f.fred = 1.5;
b.bob = 15;
b.fred = 2.5;
b.gabe = 1.77245385091; // sqrt(pi)
b.steve = -4;
f = Foo(b);
return 0;
}
This is legal and valid. Problem is, the implicit copy constructor of Foo is called, and Foo's copy constructor knows nothing about what a Bar is. Only that it contains everything a Foo has, and some extra irrelevant crap. Because of this, only the Foo's data gets preserved; the data unique to the Bar gets spliced off.
It's important to note that this is DEFINED BEHAVIOR: it's doing EXACTLY WHAT YOU TELL IT TO. Casting between a subclass of a base class and a base class is implicit. Furthermore, the behavior of the copy constructor is implicit.
It's also important to note that, under the hood, C++ pointers and references work in the same way. It's perfectly sane to pass the Bar to Foo's copy constructor by reference, this pass by reference does not produce a copy of the object. It's the same as working with a pointer.
The actual splicing takes place as a direct result of the copy constructor biting off more than it can chew. It gets an object with more state than it expected, and its only choice is to ignore the extra state.
With python, this doesn't happen because everything is implicitly stored as a reference type. Since you only work with references (the objects themselves are abstracted away), you never have the opportunity to accidentally splice an object.
So here is the deal, I think I need to go another route regarding the pattern I am using but I thought I would get some expert opinions first.
I have a class (UsingClass) that maintains a dynamic list of Base class pointers. When adding a new object to the list I have to figure out what type of object it is because I can't really make it work in a polymorphic manner. The line below tagged "THIS WILL NOT WORK LIKE I WANT IT TO!!" would ideally polymorphically use the =operator from the Derived class of interest, but unfortunately it only uses the default =operator for the Base class.... probably would work if I made Base pure virtual (basically confine it use to an interface with no data members of its own), but I don't really want to have the Derived classes hold members that are common between both (maybe I need to just cut bait and do it).
I think I may just completely be using the wrong pattern but I don't know what alternatives I should consider.
I know the code does not necessarily compile but please work with me. Thanks in advance!
//code block
class Base {
protected:
int x;
float y;
string type; // default to Derived1 or Dervied2 depending on the object inst
public:
virtual int functionM(int l) = 0;
int functionN(int P);
};
class Derived1 : public Base {
protected:
int a;
public:
int functionM(int l);
float functionR(int h);
};
class Derived2 : public Base {
protected:
int b;
float r;
public:
int functionM(int l);
float functionR(int h);
};
#define MAX_ARRAYSIZE 10
class UsingClass {
private:
Base* myDerived1And2DynamicList[MAX_ARRAYSIZE];
int indexForDynamicList;
public:
void functionAddDerivedToList(*Base myInputPtr) {
if((indexForDyanmicList + 1) < MAX_ARRAYSIZE) {
if(myInputPtr->type == "Derived1") {
myDerived1And2DynamicList[indexForDyanmicList+1] = new Derived1;
*myDerived1And2DynamicList[indexForDyanmicList+1] = *myInputPtr; // THIS WILL NOT WORK LIKE I WANT IT TO!!
} else if (myInputPtr->type == "Derived2") {
myDerived1And2DynamicList[indexForDyanmicList+1] = new Derived2;
*myDerived1And2DynamicList[indexForDyanmicList+1] = *myInputPtr; // THIS WILL NOT WORK LIKE I WANT IT TO!!
}
}
} // end of void function
};
Rather than checking the type you could simply add a virtual function to the class 'Base' and call that. This would simplify void functionAddDerivedToList(*Base myInputPtr) to the following:
void functionAddDerivedToList(*Base myInputPtr)
{
if((indexForDyanmicList + 1) < MAX_ARRAYSIZE) {
myDerived1And2DynamicList[indexForDyanmicList+1] = myInputPtr->clone();
}
}
Clone would always be implemented to call the class's copy constructor. So in Base, add the following:
virtual Base* clone() = 0;
The implementation would always take this form (example is for Derived1, a subclass of Base in your example):
virtual Base* clone() { return new Derived1(*this); }
One problem I see is that you are sing C-style array to contain a list of "Base" objects. Note that the size of the elements in the array in this case will be the sizof(Base), which is different with sizeof(Derived1) and sizeof(Derived2). Both derives may be different as well. What you can do in this case is to have the array contain pointers of Base objects instead of the actual objects. That will make the size uniformed to 4 bytes and you can access the objects in your array as pointers. Because the array now contain pointers you do not have to determine the type if you simply want to insert them in the array.
void functionAddDerivedToList(Base* myInputPtr)
{
if((indexForDyanmicList + 1) < MAX_ARRAYSIZE)
myDerived1And2DynamicList[indexForDyanmicList+1] = myInputPtr;
}
If you want to access the object from the array you can do something like this.
Base* p = myDerived1And2DynamicList[index];
p->MyMethod();
You can trust that the correct MyMethod function will be called based on the actual type of p in this case.
I have a class (UsingClass) that maintains a dynamic list of Base class pointers.
Sorry, but you have not (wrong syntax). But don't go that way.
First, give your Base class a virtual destructor. Otherwise you will experience memory leaks.
Then, redesign your UsingClass container. Give it a vector of shared_pointer to Base member to hold dynamically alocated polymorphic objects. (If you use a non C++0x-compiler, you can use std::tr1::shared_ptr.)
class UsingClass {
private:
std::vector<std::shared_ptr<Base> myList;
// int indexForDynamicList; is now myList.size()
public:
void Add(Base* myInputPtr) {
myList.push_back(myInputptr);
}
// ...
};
To add polymorphic objects, use
UsingClass container;
container.add(new Base);
container.add(new Derived1);
container.add(new Derived2);
You can call all polymorphic methods by iterating
for (size_t i = 0; i < myList.size(); ++i)
{
myList->functionM(); // give the function a more "speaking" name
}
By using shared_ptr you can hold many pointers to one object and don't have to care about freeing memory. Copying the pointers will not copy objects (so called shallow copy). If you really need to copy objects also (so called deep copy), your Base and derived classes will have to implement a virtual clone() method.
I designed a series of related classes, and in order to be able to manage them I made them derive from a single abstract class.
These classes all need access to a series of shared resources, and I found myself creating a vector of pointers in each, all of them identical (they necessarily must be). It seems like making a static member in the base class would give all of the derived classes access to this vector, meaning I need only build it once (it's not going to change either after it's been built, just looked up).
My question is if this is ok, and if so, how can I then build it, without calling a 'fill the vector' method from one of the derived classes?
My thinking was to do something like
class Resource {};
enumR {RES0, RES1};
class AbstractClass
{
public:
virtual void OnInit() = 0;
void static fillVector(Resource* pResource, enumR Resourcename)
{lResource[Resourcename]=pResource;};
protected:
static vector<Resource*> lResource;
};
vector<Resource*> AbstractClass::lResource;
int main()
{
Resource res0, res1;
AbstractClass::fillVector(&res0, RES0);
AbstractClass::fillVector(&res1, RES1);
return 0;
};
Then when I instantiate an object of any class derived from AbstractClass, I'd have access to the lResource vector, which is what I want.
Would this work? Is it horrible? Is it ok?
It would work, where work = compile & run.
However, all child classes will be accessing the same static vector, which means there won't be a different copy of the static vector for each child class.
For a better explanation of what I mean read the following So thread:
Are static fields inherited?
SOLUTION:
One solution is to have your parent class a template class as follows:
template<T>
class Parent<T> {
public:
static std::vector<T> sharedResource_;
}
class ChildA : Parent<ChildA> {
}
class ChildB : Parent<ChildB> {
}
In the above code, you will get a shared resource for all instances of ChildA and another one shared between instances of ChildB.
Is it right?
Well, I think it is not considered good. One of the related discussions to this is in comments to the following SO question and also under my answer to the question:
How to do "static overloaded const" in C#?
The better solution would be to just make an object with the vectors in and then only instantiate it once and give the other classes a pointer or reference to it. Static data should be absolutely avoided unless necessary and this just isn't necessary.
You can add a static function to initialise your static vector:
class AbstractClass
{
private:
// Add this
static vector<Resource*> CreateResources();
protected:
static vector<Resource*> lResource;
};
vector<Resource*> AbstractClass::lResource = CreateResources();
vector<Resource*> AbstractClass::CreateResources()
{
vector<Resource*> resources;
resources[RES0] = new Resource();
resources[RES1] = new Resource();
return resources;
}
You could try boost::assign::list_of, something like this:
vector<Resource*> AbstractClass::lResource = list_of( &res0 )( &res1 );
I have few points here.
Your vectory probably having size of 0. This could lead to some crash. You will have to allocate it before using. You can give a static or global initialize.
Do you really want a vector? Vector is appropriate when you're using some dynamic memory allocation. The enums are static. You can give a simple count and allocate it as an array.
Do you really want a static member? Static member usually used while you're sharing it between the objects of the same class. Can you satisfy the requirement with an external objects which is local/global within the class? Also can you make static function out of the class?
Since you are creataing the vector of "resource pointer" and not reserving the spaces for object in advance ,your sysetem might crash in future. Why?
Vector create a block of memory when you insert element and uses the same block until it hits its capcity. Once it hits its capcality and you inset a new element, vector will allocate a new memory (twice as previous allocated memory) and copies all the existing elements into new memory. Since this is a vector of "pointers", it is going to invaliadate all the refernces.
What I usually do in these cases is add a middle templated layer so I have a structure like this:
Define your abstract interface:
class A
{
public:
virtual ~A(){}
virtual void f() = 0
virtual A* Clone() const = 0
}
Put the resources commonly used by the child in a template and define the boiler-plate function using CRTP if necessary keeping the necessary interface function still abstract
template<class Derived>
class A_T: public A
{
public:
virtual void f() = 0;
virtual A* Clone const
{
return new Derived(dyn_cast<Derived&>(*this))
}
void ManageRes();
private:
vector myResource;
}
Finally the different concrete classes complete the implementation and do something special with those resources if necessary
class Child: public A_T<Child>
{
public:
void foo();
}