Generating an interface without virtual functions? - c++

I'm coding a game engine and I have this class set up for objects:
class SceneManager //controls everything in the "world" game
{
public:
void Add(SceneObject* object); //adds to the vector
private:
vector<SceneObject*> _worldObjects; //the vector that contains all of them
}
And all classes I work on the game inherit from SceneObject:
class SceneObject
{
public:
virtual void Draw() = 0;
}
class Image : public SceneObject
{ }
class Sprite : public SceneObject
{ }
class Model3D : public SceneObject
{ }
So I know I can call Draw() for all objects in my vector.
But I've been working on optimizations and I'm trying to get rid of all inheritance and virtual functions, and use composition instead, since they can't be inlined and seems to be a major performance issue when performed on a per-object basis.
I'm looking for some C++ technique that I can use to be able to store a bunch of SceneObjects in my vector, and then call Draw() on it and it properly draws the object related to it. This will also work for the Update() function I'm using as virtual.
So this code:
void SceneManager::Add(SceneObject* object)
{
_worldObjects.push_back(object);
}
void SceneManager::DrawTheWorld()
{
for(unsigned int i = 0; i < _worldObjects.size(); i++)
{
_worldObjects[i]->Draw(); //SceneObject's being called
}
}
...would become:
void SceneManager::Add(Image* image)
{
SceneObject* object = new SceneObject();
//link object to image somehow, tried to use it as a member of image
_worldObjects.push_back(object);
}
void SceneManager::DrawTheWorld()
{
for(unsigned int i = 0; i < _worldObjects.size(); i++)
{
//_worldObjects[i]->
//I need somehow to be able to get the pointer back to the original class
//It can be an image, sprite, model3d, anything
}
}
I don't think if I add a switch or if/elses and removing the virtual I'd gain any performance, so I'm trying to figure if there's a clean way to deal with this.
Any ideas?

You can use free functions to model the drawable aspect of your objects:
#include <iostream>
class Image { };
class Sprite { };
class Model3D { };
namespace draw_aspect
{
void draw(Image const& image) { std::cout << "drawing image\n"; }
void draw(Sprite const& sprite) { std::cout << "drawing sprite\n"; }
void draw(Model3D const& model3D) { std::cout << "drawing model3D\n"; }
}
Now, either use three separate vectors (this could well be most optimal, depending on the ordering relationship between the objects across collections?), or consider a variant type vector:
1. Using variant types
#include <boost/variant.hpp>
using SceneObject = boost::variant<Image, Sprite, Model3D>;
namespace draw_aspect {
struct draw_visitor : boost::static_visitor<> {
template <typename T> void operator()(T const& t) const { draw(t); }
};
void draw(SceneObject const& sobj) {
static const draw_visitor _vis;
boost::apply_visitor(_vis, sobj);
}
}
A complete proof of concept of the latter: Live on Coliru
#include <vector>
class SceneManager //controls everything in the "world" game
{
public:
void Add(SceneObject v) { _worldObjects.emplace_back(std::move(v)); }
friend void draw(SceneManager const& sm) { return sm.draw(); }
private:
void draw() const {
for(auto& sobj : _worldObjects)
draw_aspect::draw(sobj);
}
std::vector<SceneObject> _worldObjects; //the vector that contains all of them
};
int main()
{
SceneManager sman;
sman.Add(Image());
sman.Add(Sprite());
sman.Add(Model3D());
sman.Add(Image());
draw(sman);
}
Outputs
drawing image
drawing sprite
drawing model3D
drawing image
2. Separate collections
The alternative using separate vectors: Live on Coliru
class SceneManager //controls everything in the "world" game
{
public:
void Add(Image v) { _images .emplace_back(std::move(v)); }
void Add(Sprite v) { _sprites .emplace_back(std::move(v)); }
void Add(Model3D v) { _model3Ds.emplace_back(std::move(v)); }
friend void draw(SceneManager const& sm) { return sm.draw(); }
private:
void draw() const {
for(auto& sobj : _images) draw_aspect::draw(sobj);
for(auto& sobj : _sprites) draw_aspect::draw(sobj);
for(auto& sobj : _model3Ds) draw_aspect::draw(sobj);
}
std::vector<Image> _images;
std::vector<Sprite> _sprites;
std::vector<Model3D> _model3Ds;
};
int main()
{
SceneManager sman;
sman.Add(Image());
sman.Add(Sprite());
sman.Add(Model3D());
sman.Add(Image());
draw(sman);
}
Note that the output is different (ordering):
drawing image
drawing image
drawing sprite
drawing model3D

Solving your specific petition is one thing that others have already done.
However, I think you should take a step back and consider the whole picture. Is this a wise step to take? Any possible alternative to virtual functions will introduce maintainability problems, i.e., difficulty to modify and even to understand code.
The question is: is this really necessary? Will it really compensate?
Virtual functions involve derreferencing two pointers instead of only one. And yes, it is true it won't be inlined. I don't think, however, this being a real issue. I would indeed concentrate in algorithm-level optimization, and waste all other approaches before removing virtual funcions.
Take into account that at least one solution involves converting virtual functions to regular functions (not member functions), removing the well-known advantage of a virtual function (i.e., the class of the object itself) vs. a chain of if's.
That's said, it is your call.

Since you seem to have a fixed number types, it seems a reasonable approach would be the use of one vector per type and applying the operations separately for each type: processing a sequence of heterogeneous objects will amount to some disruption whether it is using virtual functions are not. Putting the framework of how the respective objects are called into a function template will conveniently deal with the commonality.

Related

How to create a wrapper or intermediate layer to access a class, without exposing it?

I use a third party engine, that has a class "Sprite". My classes use sprite, and call its methods.
There is a probability that "Sprite" will be replaced in the future by some other game engine. I would like to have a layer between my class, and Sprite, so that it is easy to swap out Sprite in future.
I figure there are at least two ways to do this:
Implement a wrapper class that has a bridge method for every method in sprite, and that my code uses to access the sprite.
For Example:
Wrapper{
private:
Sprite* foo;
public:
void method1(){
foo->method1();
}
int method2(){
return foo->method2();
}
}
The downside with this approach is that there is a lot of work to write a method for each method in Sprite, even though all it is doing is just calling the method and returning whatever result. It is also a lot of maintenance work each time there is a change in sprite.
Alternative 2 : Some kind of magic by overloading the -> operator.
struct LoggingFoo : public Sprite {
void log() const { } //Just a method for logging.Doesn't matter.
Foo const *operator -> () const { log(); return this; }
Foo *operator -> () { log(); return this; }
};
Not very sure of all the things to keep in mind with this option ? For example, what happens to class methods ? Does it make sense to publicly inherit Sprite for this use case ?
Note: In practice, there is no object that is intended to inherit from Sprite in my code.
EDIT:
What would be the most concise way to create the wrapper, yet expose all public member variables and functions? For example, not having to specify each and every variable and function to expose ?
You just need to create a Wrapper class that publicly inherits from Sprite and use it. It automatically fully inherits all the methods and variables of the Sprite class in the Wrapper class with the same level of visibility:
class Sprite
{
public:
void foo(){};
void bar(){};
int mode = 0;
};
class Wrapper : public Sprite
{
};
int main()
{
Wrapper w;
w.foo();
w.mode = 5;
w.bar();
}
If in the future you switch to another library, you will inherit Wrapper from the new class and implement only removed or changed methods:
class NewSprite
{
public:
void foo(){}; // same interface
void new_bar(int mode){};
};
class Wrapper : public NewSprite
{
public:
void bar() // wrap new method
{
new_bar(mode);
}
int mode = 0;
};
But a better approach would be to build a higher-level Wrapper interface so that when you completely change the library API, you don't have to rewrite every method:
class Wrapper
{
public:
void do_operation() // high-level interface
{
s_.foo();
s_.mode = 5;
s_.bar();
}
protected:
Sprite s_;
};
class Wrapper
{
public:
void do_operation() // high-level interface
{
s_.foo();
mode = 5;
s_.new_bar(mode);
}
int mode = 0;
protected:
NewSprite s_;
};
int main()
{
Wrapper w;
w.do_operation();
}
You could also consider a slightly different implementation to your wrapper using private (i.e., is implemented in terms of) inheritance.
This implementation removes the burden of wrapping every function and instead just add a using statement for every function you want to expose.
#include <iostream>
class Sprite
{
public:
Sprite() : d_value(0) {}
void method1() { std::cout << "Sprite::method1()\n"; }
void method2() { std::cout << "Sprite::method2()\n"; }
int d_value;
};
class Wrapper : private Sprite
{
public:
using Sprite::method1;
using Sprite::method2;
using Sprite::d_value;
};
int main()
{
Wrapper w;
w.method1();
w.method2();
w.d_value = 3;
return 0;
}
Live Example

Command pattern - Commands that execute the task with a "weight"

I'm currently working on designing a base for future projects, more specifically I'm working on the input handling. I'm using the command pattern for handling the input, when creating an input context the programmer can bind a command to a key or mouse button through an invoker that executes the command depending on the different conditions of the application, key pressed, where the mouse is on the window and so on.
I ran into trouble when I got to the part of adding handling of the mouse when in an input context where the cursor is disabled, e.g. when controlling a 3D camera (This is actually the only situation I can think of where this would be useful).
The way I see this working, is the programmer binds a command, one that rotates the camera, to be activeated once an event is created that describes mouse movement. The command would hold a pointer to the camera object and call a function like camera->pan() when executed. This command would be executed when the mouse moved in the X-Axis. However if this was the case, the camera would always pan with a constant speed, no matter how fast or slow the mouse was moved. If the cameras function pan() had a parameter for specifying how much to pan, the Command object would need to have a value for this parameter when executing. If that value is specified on creation of the command and stored as a member, the problem would arise again, since the parameter would have the same value every time the function is called.
My proposed solution to this problem is to simply create a variant of the Command class called something like WeightedCommand that had a parameter in its execute() function. This parameter would be a "weight" passed on to the cameras pan() function. This would allow for the command to be executed with a differen "weight" everytime it's called, or the same "weight", it would be up to the programmer to decide.
For reference, this is an example of the Command pattern, from wikipedia.
class Light {
public:
void TurnOn() { std::cout << "The light is on." << std::endl; }
void TurnOff() { std::cout << "The light is off." << std::endl; }
};
class ICommand {
public:
virtual ~ICommand() = default;
virtual void Execute() = 0;
};
// The Command for turning on the light - ConcreteCommand #1
class FlipUpCommand : public ICommand {
public:
FlipUpCommand(Light* light) : light_(light) { assert(light_); }
void Execute() { light_->TurnOn(); }
private:
Light* light_;
};
An example of the WeightedCommand:
class WeightedCommand
{
public:
virtual ~WeightedCommand() = default;
virtual void execute(double weight) = 0;
};
class PanCamera : public WeightedCommand
{
public:
PanCamer(Camera* cam)
: _camera(cam;
{}
void execute(double weight)
{
_camera->pan(weight);
}
private:
Camera* _camera;
};
Can you see any flaws with this approach. Is there a better solution already available? I tried searching for solutions to similar problems, but couldn't find anything that really fit.
This is rather an opinion based question but here are some suggestions.
You could keep your approach and generalize it a bit more by making ICommand a template.
template <typename ...Args>
class ICommand
{
public:
virtual ~ICommand() = default;
virtual void Execute(Args const& ...args) = 0;
};
class PanCamera : public ICommand<double>
{
void Execute(double const& pan) override
{
_camera->pan(pan);
}
};
If you want to store your commands in a container you need a common type, which wouldn't work with the above example. To avoid this you can replace the double parameter with a std::variant like you've already mentioned.
using CommandArgs = std::variant<double, std::string>;
class PanCamera : public ICommand<CommandArgs>
{
void Execute(CommandArgs const& args) override
{
_camera->pan(std::get<double>(args));
}
};
class SayHello : public ICommand<CommandArgs>
{
void Execute(CommandArgs const& args) override
{
display->sayHello(std::get<std::string>(args));
}
};
You can also ditch your ICommand interface alltogether and use the visitor pattern for std::variant.
struct PanCameraArgs
{
double value = 0;
};
struct SayHelloArgs
{
std::string text;
};
struct RotateCameraArgs
{
double angle = 0;
};
using CommandArgs = std::variant<PanCameraArgs, SayHelloArgs, RotateCameraArgs>;
void dispatchCommand(CommandArgs const& command)
{
std::visit( overloaded {
[&] (PanCameraArgs const& args)
{
_camera->pan(pan.value);
}
[&] (SayHelloArgs const& args)
{
display->sayHello(args.text);
}
[&] (RotateCameraArgs const& args)
{
_camera->rotate(args.angle);
}
}, command);
}

Whether using dynamic cast for providing input for derived class virtual function is recommended?

I read some of the answers in What is the proper use case for dynamic_cast.
The line which best matched my situation here is
#include<iostream>
class Shape
{
public:
virtual void draw()=0;
virtual ~Shape(){};
};
class Rectangle : public Shape
{
public:
int length;
int breath;
void draw()
{
std::cout<<"RECTANGE"<<std::endl;
}
};
class Circle : public Shape
{
public:
int diameter;
void draw()
{
std::cout<<"CIRCLE"<<std::endl;
}
};
/*Abstract Factory*/
Shape* getShapeObj(int type)
{
switch(type)
{
case 1:
return new Rectangle;
case 2:
return new Circle;
/* many types will be added here in future. */
}
return NULL;
};
void drawShapes(Shape *p_shape[],int len)
{
for(int i=0;i<len;i++)
p_shape[i]->draw();
}
int main()
{
Shape *l_shape[2];
l_shape[0]=getShapeObj(1);
l_shape[1]=getShapeObj(2);
Rectangle *l_rec=dynamic_cast<Rectangle*>(l_shape[0]);
if(l_rec)
{
l_rec->length=10;
l_rec->breath=20;
}
Circle *l_circle=dynamic_cast<Circle*>(l_shape[1]);
if(l_circle)
l_circle->diameter=25;
drawShapes(l_shape,2);
}
Essentially, virtual functions only work in some cases, not all of them.
My problem is to pass the input for the virtual function and inputs will vary from type to type. Whether using dynamic cast is recommended here?
The solution is perfect forwarding of function parameters, introduced in c++11.
template<typename ...CtorArgs>
Shape* getShapeObj(int type, CtorArgs&& ctor_args...)
{
switch(type)
{
case 1:
return new Rectangle(std::forward<CtorArgs>(ctor_args)...);
// many types will be added here in future.
}
return NULL;
}
Obviously making the function a template, defeats the purpose of hiding the hierarchy (as well as forcing rather strict requirements on the number of parameters to the constructors). But if the base contains a map of functions that do the construction, which each derived class updates with a pointer to function that constructs it, you can still have information hiding.
I have recently written an answer about storing type erased function pointers in a map, with some static type checking forwarded to run time.
In this particular case, looks like your main function is taking too much responsibility. What if you have Circle, Hexagon, MyFancyFigure types? All of them should be initialized in main in different branches?
It would be much better to move that "initialization" logic to a separate virtual function init in your classes (or even to the constructor). The code would look like this:
class Shape
{
public:
virtual void draw()=0;
virtual void init()=0;
virtual ~Shape(){};
};
class Rectangle : public Shape
{
public:
int length;
int breath;
void draw()
{
//Draw Rectangle
}
void init()
{
length = 10;
breath = 20;
}
};
int main()
{
Shape *l_shape=getShapeObj(1);
// Calls different code of "init" method depending on the actual object type
l_shape->init();
l_shape->draw();
delete l_shape;
}
Also, please note that this initialization logic may be place in some other place, like constructor of the class or the factory method. But main is definitely the wrong place.

Event-based Game engine based on polymorphism of Entities

I would like to create a simple framework for throwing and catching events in a game. Events could be things like a Collision which (according to the type) can take several arguments (note that every Event type may take another amount of arguments, not just two as in the example).
I would then like to implement functions/classes/... to deal with a Collision, based on polymorphism. This example should illustrate the problem:
#include <iostream>
#include <vector>
class Entity {};
class Player: public Entity {};
class Bomb: public Entity {
public:
bool exploded;
};
class MineSweeper: public Entity {};
// For now, I only included Collisions, but I eventually want to extend it to
// more types of Events too (base class Event, Collision is derived class)
void onCollision(Player* p, Bomb* b) {
if (! b->exploded) {
std::cout << "BOOM";
b->exploded = true;
}
}
void onCollision(Entity* e, Entity* f) {
std::cout << "Unhandled collision\n";
}
// Possibility for Collision between Minesweeper and Bomb later
class Game {
public:
std::vector<Entity*> board; // some kind of linear board
Game() {
board = {new Player, new Bomb, new MineSweeper};
}
void main_loop() {
onCollision(board[0], board[1]); // player and bomb!
onCollision(board[1], board[2]);
}
};
int main() {
Game g;
g.main_loop();
}
Note that I understand perfectly well why the above code doesn't work as intended, I included this example solely to illustrate my problem better.
The above example uses functions for the events, but I'm perfectly fine with classes or any other solution that is maintainable.
I hope it is clear that I would like C++ to decide which event handler to use based on the types of the arguments (presumably at runtime).
My question: How can I do this in C++? An example would be appreciated.
(not my question: fix my code please)
user2864740 provided enough clues for me to find a solution myself. Multiple dispatch was indeed the missing piece.
The following code works as intended, making use of dynamic_cast to dispatch correctly.
#include <iostream>
#include <vector>
class Entity {
virtual void please_make_this_polymorphic() {}
// although this function does nothing, it is needed to tell C++ that it
// needs to make Entity polymorphic (and thus needs to know about the type
// of derived classes at runtime).
};
class Player: public Entity {};
class Bomb: public Entity {
public:
bool exploded;
};
class MineSweeper: public Entity {};
// For now, I only included Collisions, but I eventually want to extend it to
// more types of Events too (base class Event, Collision is derived class)
void onCollision(Player* p, Bomb* b) {
if (!b->exploded) {
std::cout << "BOOM\n";
b->exploded = true;
}
}
void onCollision(Entity* e, Entity* f) {
std::cout << "Unhandled collision\n";
}
void dispatchCollision(Entity* e, Entity* f) {
Player* p = dynamic_cast<Player*>(e);
Bomb* b = dynamic_cast<Bomb*>(f);
if (p != nullptr && b != nullptr) {
onCollision(p, b); // player and bomb
} else {
onCollision(e, f); // default
}
}
class Game {
public:
std::vector<Entity*> board; // some kind of linear board
Game() {
board = {new Player, new Bomb, new MineSweeper};
}
void main_loop() {
dispatchCollision(board[0], board[1]); // player and bomb
dispatchCollision(board[1], board[2]);
}
};
int main() {
Game g;
g.main_loop();
}
Although it works, I'd like to point out some problems with this code:
Manual editing of dispatchCollision needed when adding new Collisions.
Currently, the dispatcher using a simple kind of rule-based system. (Does it fit rule 1? What about rule 2? ...) When adding loads of different functions it needs to dispatch, that may have an impact on the performance.
A collision between A and B should be the same as a collision between B and A, but that isn't properly handled yet.
Solving these problems is not necessarily in the scope of this question IMHO.
Also, the example given should work just as well for more than 2 arguments. (Multiple dispatch, not just double dispatch.)
You should decide first what event subscription model you need.
It could be signal/slot mechanism and you can find plenty of libraries:
https://code.google.com/p/cpp-events/ , http://sigslot.sourceforge.net/ and the like.
Or it could be bubbling/sinking events like in HTML DOM when event gets propagated on parent/child chain ( from event source element to its containers).
Or even other schema.
It is quite easy to create whatever you need with std::function holders in modern C++.
Maybe a good structure for your case could be something like this:
class Entity{
public:
virtual int getType() = 0;
};
enum EntityTypes {
ACTOR,
BOMB,
MINESWEEPER,
};
class Actor : public Entity{
public:
virtual int getType() {return int(ACTOR);}
void applyDamage() {
std::cout << "OUCH";
}
};
class Bomb : public Entity{
public:
Bomb() : exploded(false) {}
virtual int getType() {return int(BOMB);}
void explode() {
this->exploded = true;
}
bool isExploded() {
return this->exploded;
}
protected:
bool exploded;
};
class MineSweeper : public Entity{
public:
virtual int getType() {return int(MINESWEEPER);}
};
class CollisionSolver {
public:
virtual solve(Entity* entity0, Entity* entity1) = 0;
};
class ActorBombCollisionSolver : public CollisionSolver {
public:
virtual solve(Entity* entity0, Entity* entity1) {
Actor* actor;
Bomb* bomb;
if (entity0->getType() == ACTOR && entity1->getType() == BOMB) {
actor = static_cast<Actor*>(entity0);
bomb = static_cast<Bomb*>(entity1);
}else if (entity1->getType() == ACTOR && entity0->getType() == BOMB) {
actor = static_cast<Actor*>(entity1);
bomb = static_cast<Bomb*>(entity0);
}else {
//throw error;
}
if (!bomb->isExploded()) {
bomb->explode();
actor->applyDamage();
}
}
};
class CollisionDispatcher {
public:
CollisionDispatcher() {
CollisionSolver* actorBombCollisionSolver = new ActorBombCollisionSolver;
this->solvers[ACTOR][BOMB] = actorBombCollisionSolver;
this->solvers[BOMB][ACTOR] = actorBombCollisionSolver;
// this part wouldn't be necessary if you used smart pointers instead of raw... :)
this->solvers[BOMB][MINESWEEPER] = 0;
this->solvers[MINESWEEPER][BOMB] = 0;
this->solvers[ACTOR][MINESWEEPER] = 0;
this->solvers[MINESWEEPER][ACTOR] = 0;
}
void dispatchCollision(Entity* entity0, Entity* entity1) {
CollisionSolver* solver = this->solvers[entity0->getType()][entity1->getType()];
if (!solver) {
return;
}
solver->solve(entity0, entity1);
}
protected:
unordered_map<int, unordered_map<int, CollisionSolver*> > solvers;
};
class Game {
public:
std::vector<Entity*> board; // some kind of linear board
Game() : dispatcher(new CollisionDispatcher)
{
board = {new Player, new Bomb, new MineSweeper};
}
void main_loop() {
dispatcher->dispatchCollision(board[0], board[1]);
dispatcher->dispatchCollision(board[0], board[2]);
dispatcher->dispatchCollision(board[1], board[2]);
}
protected:
CollisionDispatcher* dispatcher;
};
int main() {
Game g;
g.main_loop();
}
This way you can easily add new collision solvers, just define the class, and register t in the CollisionDispatcher constructor.
If you use smart pointers you won't need to set zeroes in the map entries not registered, but if you use raw pointers you have to set them to zero OR use unordered_map::find method instead of just grabbing the solver using operator []
Hope it helps!

container pattern with specialized children

I have several specialized classes. for example
class Transition_Matrix : public Transition
{
SetMatrix(Matrix* pStartMatrix);
};
class Transition_Vector : public Transition
{
SetVector(Vector* pStartVector);
}
class Transition_Container : public Transition
{
}
I would like to do call SetVector() or SetMatrix() on Animate_Container without declaring the functions for each type of object that needs to be set. For example, I do not want to declare Animate_Container as follows...
class Transition_Container : public Transition
{
SetMatrix(Matrix* pStartMatrix);//loops through all children calling SetMatrix
SetVector(Vector* pStartVector);//loops through all children calling SetVector
}
I don't want Animate_Container to know which children it has. But I want the convenience of calling these functions on the container so I do not have to search through the children and figure out which functions I should call when "transitioning" a matrix or a vector.
What is the correct pattern that I should use here?
Basically I want to set a matrix or vector on the root container and have it propogate down to each child than may want to use it.
ideas?
A basic composite pattern will suffice here. To implement this you declare the member functions as virtual in the base class Transition. This will allow you to maintain a list of Transition objects in Transition_Container, iterate through the list and call the appropriate member function.
#include <vector>
class Transition
{
public:
// default impementation that does nothing
virtual void SetMatrix(Matrix*) {}
};
class Transition_Container : public Transition
{
std::vector<Transition*> transitions_;
public:
virtual void SetMatrix(Matrix* pStartMatrix)
{
for(std::vector<Transition*>::iterator it = transitions_.begin();
it != transitions_.end();
++it)
{
(*it)->SetMatrix(pStartMatrix);
}
}
};
If you do not want Transition to know about the various data types that can be used you can use boost:any and boost:any_cast. This is very similar to the suggestion above but removes the dependency of Matrix and Vector from Transition and places the responsibility of dealing with different types on the implementation of classes that derive from it. I only recommend doing this if there is some requirement that absolutely prevents Transition from knowing about the Matrix and Vector types.
#include <vector>
#include <boost/any.hpp>
class Transition
{
public:
// default impementation that does nothing
virtual void SetValue(boost::any&) {}
};
class Transition_Matrix : public Transition
{
virtual void SetValue(boost::any& value)
{
try
{
Matrix *matrix = boost::any_cast<Matrix*>(value);
// do stuff
}
catch(const boost::bad_any_cast &)
{
return;
}
}
};
class Transition_Container : public Transition
{
std::vector<Transition*> transitions_;
public:
template<Arg>
void SetValueT(Arg* arg)
{
boost::any value = arg;
SetValue(value);
}
virtual void SetValue(boost::any& value)
{
for(std::vector<Transition*>::iterator it = transitions_.begin();
it != transitions_.end();
++it)
{
(*it)->SetValue(value);
}
}
};
I recommend using shared_ptr or unique_ptr from Boost or the C++11 Standard Library for maintaining the list of Transition objects like so.
std::vector<std::shared_ptr<Transition>> transitions_;
I did not include this in the above example as I do not know if you are familiar with using this yet. IF you are not I suggest looking into it.