Related
I have 2 issues in a template class I'm building. I've included example code below. First question is whether I can coerce the auto type deducted for a templated class. i.e.:
auto p = myvar;
where myvar is T<...>, could I force auto to detect Q<...>? This is simplified. Read on for a more clear explanation.
Edited for clarity: Let me explain what I'm doing. And I'd also like to indicate that this style code is working on a large-scale project perfectly well. I am trying to add some features and functions and in addition to smooth out some of the more awkward behaviors.
The code uses templates to perform work on n-dimensional arrays. The template has a top-level class, and a storage class underneath. Passing the storage class into the top level class allows for a top level class which inherits the storage class. So I start with NDimVar, and I have NDimStor. I end up with
NDimVar<NDimStor>
The class contains NO DATA except for the buffer of data:
class NDimStor<size_t... dimensions> {
int buffer[Size<dimensions...>()]
}
This makes the address of the class == the address of the buffer. This is key to the whole implementation. Is this an incorrect assumption? (I can see this works on my system without any issues, but perhaps this isn't always the case.)
When I create NDimVar<NDimStor<10,10>> I end up with a 10x10 array.
I have functions for getting pieces of the array, for example:
NDimVar<NDimStor<dimensions...>>::RemoveDim & get(int index);
This creates a new 1d array of 10 elements out of the 2d 10x10 array:
NDimVar<NdimStor<10>>
In order to return this as a reference, I use a reinterpret_cast at the location of the data I want. So in this example, get(3) would perform:
return reinterpret_cast<NDimVar≤NDimStor<dimensions...>>::RemoveDim&>(buffer[index * DimensionSumBelow<0>()]);
DimensionSumBelow<0> returns the sum of elements at dimensions 1+, i.e. 10. So &buffer[30] is the address of the referenced 1d NDimVar.
All of this works very well.
The only issue I have is that I would like to add on overlays. For example, be able to return a reference to a new class:
NDimVar<NDimPermute<NDimStor<10,10>,1,0>>
that points to the same original location along with a permutation behavior (swapping dimensions). This also works well. But I would like for:
auto p = myvar.Permute<1,0>()
to create a new copy of myvar with permuted data. This would work if I said:
NDimVar<NDimStor<10,10>> p = myvar.Permute<1,0>().
I feel that there is some auto type deduction stuff I could do in order to coerce the auto type returned, but I'm not sure. I haven't been able to figure it out.
Thanks again,
Nachum
What I want is:
1. Create temporary overlay classes on my storage, e.g. A_top<A_storage> can return a type called A_top<A_overlay<A_storage>> without creating a new object, it just returns a reference to this type. This changes the way the storage is accessed. The problem is upon a call to auto. I don't want this type to be instantiated directly. Can I modify the return to auto to be an original A_top?
#include <iostream>
using namespace std;
class A_storage {
public:
float arr[10];
A_storage () {
}
float & el (int index) {
return arr[index];
}
};
template <typename T> class A_overlay : T {
private:
A_overlay () {
cout << "A_overlay ()" << endl;
}
A_overlay (const A_overlay &) {
cout << "A_overlay (&)" << endl;
}
public:
using T::arr;
float & el (int index) {
return arr[10 - index];
}
};
template <typename T> class A_top;
template <typename T> class A_top : public T {
public:
A_top () {
}
A_top<A_overlay<A_storage>> & get () {
return reinterpret_cast<A_top<A_overlay<A_storage>>&>(*this);
}
};
using A = A_top<A_storage>;
int main (void) {
A a;
auto c = a.get(); // illegal - can i auto type deduce to A_top<A_storage>?
return 0;
}
If a function accepts (A_top<A_storage> &) as a parameter, how can I create a conversion function that can cast A_top<A_overlay<A_storage>>& to A_top<A_storage>& ?
Thanks,
Nachum
First, your design doesn't look right to me, and I'm not sure if the behaviour is actually well-defined or not. (Probably not.)
In any case, the problem is not with auto. The error is caused by the fact that the copy constructor of A_overlay is private, while you need it to copy A_top<A_overlay<A_storage>> returned by a.get() to auto c.
(Note that the auto in this case obviously gets deduced to A_top<A_overlay<A_storage>>, I assume you made a typo when said that it's A_top<A_storage>.)
Also note that A_storage in A_top::get() should be replaced with T, even if it doesn't change anything in your snippet because you only have T == A_storage.
If a function accepts (A_top &) as a parameter, how can I create a conversion function that can cast A_top> to A_top& ?
Ehm, isn't it just this:
return reinterpret_cast<A_top<A_storage>&>(obj);
reinterpret_cast should almost never be used. It essentially remove any compiler validation that the types are related. And doing unrelated cast is essentially undefined behavior as it essentially assume that derived classes are always at offset 0...
It does not make any sense to write such code. It is not maintainable and hard to understand what you are trying to achieve. It look like you want to pretend that your A_top<A_storage> object is a A_top<A_overlay<A_storage>> object instead. If this is what you want to do, then declare A alias as that type.
In your code, it look like you want to invert the indexing so that item at position 10 is returned when you ask item at position 0 and vice versa. Do you really think, that it is obvious from your obfuscated code? Never write such bad code.
Something like
class A_overlay {
public:
float & el (int index) { return arr[10 - index]; }
private:
A_storage arr;
};
would make much more sense than your current code.
No cast needed.
Easy to understand.
Well defined behavior.
You might keep your job.
And obviously, you would update the following line as appropriate:
using A = A_top<A_storage>;
Also, if A_top has no useful purpose, then why not using A_overlay directly? And why are you using template if A_storage is not a template? Do you really want to reuse such mess elsewhere in your code base.
Obviously, your code inheritance does not respect IS-A relationship if your write such code. So it is clearly a bad design!
I check this slides but still didn't get :
1) what problem does Handle sovled?
2) what is the benefit to add the Handle class?
From its source code, I cannot get any clue either:
template <class Type>
class Handle {
protected:
class Link : public Observable, public Observer {
public:
explicit Link(const shared_ptr<Type>& h =
shared_ptr<Type>());
void linkTo(const shared_ptr<Type>&);
bool empty() const;
void update() { notifyObservers(); }
private:
shared_ptr<Type> h_;
};
boost::shared_ptr<Link<Type> > link_;
public:
explicit Handle(const shared_ptr<Type>& h =
shared_ptr<Type>());
const shared_ptr<Type>& operator->() const;
const shared_ptr<Type>& operator*() const;
bool empty() const;
operator boost::shared_ptr<Observable>() const;
};
template <class Type>
class RelinkableHandle : public Handle<Type> {
public:
explicit RelinkableHandle(const shared_ptr<Type>& h =
shared_ptr<Type>());
void linkTo(const boost::shared_ptr<Type>&);
};
Could someone give a better example?
Thanks.
The short answer: the Handle class is a smart pointer to pointer.
What is it good for? Take, for example, an instance of an interest-rate index such as Euribor6M. Right now, its constructor takes a handle to a yield term structure from which it forecasts its future fixings. What would change if we used a shared_ptr instead?
Let's look at a use case. Warning: I'm simplifying things to avoid writing too much code, but it's a legitimate use case we have. Let's say we initialized the index with a flat curve to begin with:
shared_ptr<SimpleQuote> r = make_shared<SimpleQuote>(0.01);
shared_ptr<YieldTermStructure> curve =
make_shared<FlatForward>(today, r, Actual360());
shared_ptr<InterestRateIndex> index = make_shared<Euribor6M>(curve);
(in a real use case, curve would be an Euribor curve bootstrapped over a set of quoted rates). The constructor of index takes a copy of the passed shared_ptr<YieldTermStructure> and makes a copy of it to store as a data member. After it's built, we'll pass the index to other instruments (swaps, floating-rate bonds, whatever).
In case the interest rate changed, and given we still have a hold of the r quote, our client code can write
r->setValue(0.015);
Since r and curve are shared pointers, this will also change the rate in the copy of the curve inside the index (because both curve and its copy inside index point to the same object). As a result, the index fixings and the depending instrument values will also change.
However, let's say we want to start using another curve. In this case, we might want to switch to an interpolated curve instead of a flat one:
vector<Date> dates = ... ;
vector<Rate> rates = ... ;
shared_ptr<YieldTermStructure> curve2 =
make_shared<ZeroCurve>(dates, rates, Actual360());
(in a real case, we might want to bootstrap the curve on a different set of quotes or to use another way to model rates).
How can we tell index that it should start using curve2? Using shared_ptr, we can't. Even if we say:
curve = curve2;
this will cause curve to point to the interpolated curve, but the copy of curve inside index will keep pointing to the old one. This is not a problem with shared_ptr, but with pointers in general. How do you solve it? By adding another layer of indirection. If you were using raw pointers, you'd start using pointers to pointers. In our code, Handle does the same thing: it "points" to a shared_ptr, and is implemented so that two copies of the same handle point to the same shared_ptr. This way, if you write:
shared_ptr<SimpleQuote> r = make_shared<SimpleQuote>(0.01);
shared_ptr<YieldTermStructure> curve =
make_shared<FlatForward>(today, r, Actual360());
RelinkableHandle<YieldTermStructure> h(curve);
shared_ptr<InterestRateIndex> index = make_shared<Euribor6M>(h);
you can later write:
h.linkTo(curve2);
and both the handle you hold and its copy inside index will point to the new curve.
As for the difference between RelinkableHandle and Handle: you can only call linkTo on the former. The idea is that you instantiate a RelinkableHandle, pass around copies as just Handle, and so you ensure that nobody but you can change what it points to (using const wouldn't work, since constness can be cast away by a simple copy).
I was wondering whether it was a good practice to define algorithm parameter settings as an independent class. I illustrate my question with the following codes:
using namespace std;
class Parameters
{
public:
Parameters():a_para_(0),b_para_(0) {};
~Parameters() {};
Parameters(const Parameters ¶)
{
a_para_ = para.a_para_;
b_para_ = para.b_para_;
}
void set_a_parameter(int a)
{
a_para_ = a;
}
void set_b_parameter(int b)
{
b_para_ = b;
}
private:
int a_para_;
int b_para_;
};
class Algorithm
{
public:
Algorithm() {};
~Algorithm() {};
void set(const Parameters ¶)
{
para_ = para;
}
void run()
{
}
private:
Parameters para_;
};
int main()
{
Parameters para;
para.set_a_parameter(3);
para.set_b_parameter(4);
Algorithm fun;
fun.set(para);
fun.run();
return 0;
}
The philosophy behind is that the parameter setting and algorithm implementation can be separated. I discussed this design strategy with an experienced programmer, and it seems that he prefer that the parameter setting and the algorithm should be mixed together as one class. I am therefore writing here for your advice: which one is better? Thanks!
Your question is very general, and there's no general answer. It depends on the situation.
Often times you want to be able to decide at compile time the parameters of your algorithm (for instance, the size of a given buffer, or the dimension of a matrix, or the arity of a tree nodes). Usually these parameters don't change for the lifetime of your algorithm "instance", so to speak. In this context, it is usually good practice to turn your algorithm class into a template, and make these parameters the template parameters.
If the parameters must change during the algorithm lifetime, but their implementation are trivial, there's no need to externalize them. If they are non trivial, and their implementation details may change the algorithm performance (ex: a matrix implementation based on arrays for dense matrices, or on linked lists for sparse ones), then I suppose that you could externalize that parameter.
I think you should ask a more specific question if you want to get a better answer.
What I would like to do (in C++) is create a 'Parameter' data type which has a value, min, and max. I would then like to create a container for these types.
E.g. I have the following code:
template <typename T>
class ParamT {
public:
ParamT() {
}
ParamT(T _value):value(_value) {
}
ParamT(T _value, T _vmin, T _vmax):value(_value), vmin(_vmin), vmax(_vmax) {
}
void setup(T vmin, T vmax) {
this->vmin = vmin;
this->vmax = vmax;
}
void setup(T value, T vmin, T vmax) {
setup(vmin, vmax);
setValue(value);
}
T operator=(const T & value) {
setValue(value);
}
void setValue(T v) {
value = v;
}
T getValue() {
return value;
}
operator T() {
return getValue();
}
protected:
T value;
T vmin;
T vmax;
};
typedef ParamT<int> Int;
typedef ParamT<float> Float;
typedef ParamT<bool> Bool;
In an ideal world my Api would be something like:
std::map<string, Param> params;
params["speed"] = PFloat(3.0f, 2.1f, 5.0f);
params["id"] = PInt(0, 1, 5);
or
params["speed"].setup(3.0f, 2.1f, 5.0f);
params["id"].setup(0, 1, 5);
and writing to them:
params["speed"] = 4.2f;
params["id"] = 1;
or
params["speed"].setValue(4.2f);
params["id].setValue(1);
and reading:
float speed = params["speed"];
int id = params["id"];
or
float speed = params["speed"].getValue();
int id = params["id"].getValue();
Of course in the code above, ParamT has no base class so I cannot create a map. But even if I create a base class for it which ParamT extends, I obviously cannot have different getValues() which return different types. I thought about many solutions, including setValueI(int i), setValuef(float f), int getValueI(), float getValueF(), or a map for ints, a map for floats etc. But all seem very unclean. Is it possible in C++ to implement the above API?
At the moment I am only concerned with simple types like int, float, bool etc. But I would like to extend this to vectors (my own) and potentially more.
It's a tough concept to implement in C++, as you're seeing. I'm always a proponent of using the Boost library, which has already solved it for you. You can typedef the complex boost variant template class to something more usable in your specific domain, so
typedef boost::variant< int, float, bool > ParamT;
class Param
{
public:
// initialize the variants
Param(ParamT min, ParamT max, ParamT value)
: m_Min(min), m_Max(max), m_Value(value) {}
// example accessor
template<typename OutT>
const ParamT& value()
{
return boost::get<OutT>(m_Value);
}
// other accessors for min, max ...
private:
ParamT m_Min, m_Value, m_Max;
};
Param speed(-10.0f, 10.0f, 0.0f);
float speedValue = speed.value<float>();
Now, to add another type to your variant (eg, long, std::string, whatever) you can just modify the typedef of ParamT; The catch, here, is that the burden of checking the types is on you - it'll throw an exception if you store a float and try to receive an int, but there's no compile-time safety.
If you want to get really crazy, you can implement an overloaded cast operator on a proxy object....
class ProxyValue
{
public:
ProxyValue(ParamT& value) : m_Value(value) {}
template<typename ValueT>
operator ValueT()
{
return boost::get<ValueT>(m_Value);
}
private:
ParamT& m_Value;
};
You'd return this from a non-templated value() function in Param, instead of the variant itself. Now you can assign a value without the template call..
Param speed(-10.0f, 0, 10);
float speedValue = speed.value();
Though fair warning, you're stepping into meta-programming hell here. Here thar be dragons. And as always, this is not a complete solution, just a pointer. YMMV.
Heres a roughly working version showing how to use it, and the failures that are easy to hit.
Ok, I'm bored at work (just waiting for something to compile), so here's another solution. Just have one type Param that stores three Values. Those values can by dynamically typed and can store ints and floats (and anything else you want them to).
class Value
{
private:
union
{
int i,
float f
} val;
DataTypeCode dtc;
public
Value() : val.i(0), dtc(INT) {}
Value(int i) : val.i(i), dtc(INT) {}
Value(float f) : val.f(f), dtc(FLOAT) {}
Value& operator=(int i)
{
val.i=i;
dtc=INT;
return *this;
}
Value& operator=(float f)
{
val.f=f;
dtc=FLOAT;
return *this;
}
operator int()
{
switch (dtc)
{
case INT: return val.i;
case FLOAT: return (int)val.f;
}
return 0;
}
operator float()
{
switch (dtc)
{
case INT: return (float)val.i;
case FLOAT: return val.f;
}
return 0;
}
}
class Param
{
private:
Value value, min, max
public:
Param(Value value, Value min, Value max) : value(value), min(min), max(max) {}
}
note, this still requires that DataTypeCode enum that I have in my other answer.
Now to access it, all you have to do is this:
std::map<string:Param> Params;
Params["speed"]=Param(1.4,0.1,5.6)
float speed=Params["speed"]
the cast operators along with the overloaded constructors and operator= functions will automatically convert among the types for you.
You can use either boost::any (to be able to store any type) or boost::variant (to store any type from a fixed set of prespecified types); however, the boost::program_options library largely already does what you want. I would strongly advise that you use boost::program_options rather than rolling this library yourself. I should point out that there is a major downside to what you are doing; you are validating types manually at runtime, which makes it easy for various errors to slip through. I strongly recommend using protocol buffers as a configuration language, as you get stronger type-checking that way.
A question I have about your design is why do you need to support all these value types? Performance, type safety, numeric accuracy, or simplicity/ease of use? It's going to be tough to get your interface to support all of these.
One simple way to solve the question, as you posed it, would be to pick a single numeric type that supports all the values you are interested in. In general, a double should suffice. It will be obvious to users what is going on under the hood, and you don't need to do anything weird with your implementation.
If you need perfect storage, you could implement your own numeric type that can do conversions (implicit or explicit) to various numeric types, and maintain perfect storage if you convert to/from the same type. If you're really concerned about perfect storage, you could also make it throw if you try to do a conversion back to the wrong type. This is like a strongly typed union. I believe the boost library has a type like this. Edit: Nicholas M T Elliott's answer already mentions this - boost variant.
If you like the even-more-explicit interface that you have here, with your GetValueAsInt/SetValueAsInt interface, you can still make it slightly simpler. Combine the setters, since C++ supports function overloading for parameters: void SetValue(int value) void SetValue(float value). C++ does not support function overloading for return types, though, so you cannot combine the getters.
Edit:
No matter which of these you pick, you're going to have a problem making it generic, or adding new types to it later. You must modify the property map's value type every time you want to support an new class.
The simplest way around this in C++ is to use a void* as your value type, and do casts to convert it to and from your target type. Your library could provide a template wrapper to do this cast, and throw if the cast fails.
This is similar to using "object" in Java/C#
Edit:
As Michael Aaron Safyan suggested, you could use boost::any.
In the end, you need to think about this: must your design include property dictionaries? If it doesn't have to have it, then you could benefit from the compiler's static analysis if you abandon this idea. Any behavior you push off to runtime will cause bugs that you won't find at compile time. It does make it faster to get the code running, but it makes your runtime error handling harder, and can hurt perf.
Well, it's easy to make a container store just about anything. As you said, you could make a common base class and have the map just store a pointer to that. The hard part is knowing what data type they are when you're retrieving them and using it. I have something like this in my main project where I'm mixing compile-time type determined c++ code and run-time type determined code from another language. So I embed into the class it's datatype code so that I can do a switch() statement on it. You could have something like this:
enum DataTypeCode
{
UNKNOWN,
INT,
FLOAT
};
template <class DataType>
DataTypeCode GetDataTypeCode()
{
return UNKNOWN;
}
template <>
DataTypeCode GetDataTypeCode<int>()
{
return INT;
}
template <>
DataTypeCode GetDataTypeCodE<float>(
{
return FLOAT;
}
class BaseParam
{
public:
virtual ~BaseParam() {}
virtual DataTypeCode GetDataTypeCode()=0;
};
template <class DataType>
class Param : public BaseParam
{
public:
DataTypeCode GetDataTypeCode()
{
return ::GetDataTypeCode<DataType>();
}
}
and you have to store it as a pointer to take care of polymorphism:
std::map<string,BaseParam*> Params
Params["speed"]=new Param<float>(...)
BaseParam* pMyParam=Params["speed"];
switch (pMyParam->GetDataTypeCode())
{
case INT:
//dosomething with int types
case FLOAT:
//dosomething with float types
}
It's not pretty, but it'll get the job done. Normally, I'll end up wrapping the std::map<string, BaseParam*> inside of another class to hide the fact that it's storing a pointers. I like to make my APIs hide the use of pointers as much as possible, it makes it easier for the junior programmers on my team to deal with it.
I've got way too much information to work with, so for now I'll consider this question answered until I can sort it all out and decide on the final implementation! Thanks a ton gf and Simon Buchan. I wish I could accept both of your answers, since they're both definite possibilities!
Additional / Revised Conceptual Information as suggested:
What I am aiming to do;
I am making a game. In this game every object used is an instance of the DOBJ class. The TUR class extends the DOBJ class. The SHO class extends the TUR class.
Each TUR class has an array of SHO's stored in it's SHOARR array. Each SHO instance needs to be given a set of instructions.
I know for a fact I could make 1000's of different SHO classes that have their instructions set during construction.
However, considering I will have so many different acting SHO instances, I was interested in another way to pass a set of instructions. Through the contruction of the SHO would be the ideal.
The instructions I am attempting to pass to each SHO are simple if statements;
if(frame > 64) { rotation += 4; };
if(state == 0 && frame < 32) { xs = 12; ys = 12; state = 1; };
Original question
Migration from ActionScript3.0 to C++ is proving to be a trial indeed. Thanks to those who have answered my questions thus far and also to those who opened stackoverflow in the first place. Onto the question... (TL;DR near the bottom to get straight to the question)
I'm attempting to apply the same logic that I could apply in AS3.0 to my project in C++ and it's just not going very well.
In AS3.0 I was used to slapping any and every datatype into an Array. It made things pretty simple. Now that I've run into C++ dev, I realized that I can't exactly do that anymore.
So now I'm stuck with this problem of rewriting a little AI system in a new language, where the driving point of the system isn't even compatible!
Here's an example of a piece of the code I was writing in AS3.0;
AI[NUM][1]( OBJ, AI[NUM][2], AI[NUM][3] );
AI being an array, NUM being an integer, OBJ being an instance of a class.
This line obviously called the function in the second element of the first array in the main array with the arguments being a class in which to perform the function on, whatever was in the third element of the first array of the main array, and likewise the fourth element.
In this case;
AI[NUM][1] would be a function
AI[NUM][2] would be a variable
AI[NUM][3] would be a number
Generally, my AI was run on calling a function to change or compare the variable with a number.
An example would be;
CompareST( someObject, "x", 500 );
and return true if someObject's x variable was smaller than (ST) 500.
The AI array itself was just filled with arrays of calls similar to this.
Quite new to C++ I had no idea how to go about this, so I did a bit of searching and reading of many different websites and came to the conclusion that I should look into function pointers.
However, after reading a bit into them, I've come to the conclusion that it won't help me realize my goal. While it did help me call functions like I wanted to call them, it doesn't help me stack different datatypes into one large array of arrays.
TL;DR
EDIT++:
What I need for each object is a set of instructions to be checked every frame. However, for each instance of the class, the instructions have to be different.
I plan on having a LOT of different instances, so making a class for each one is unreasonable.
Thus, I needed a way to pass a set of instructions to each one through it's constructor and read + execute them at any time their think() function is called.
My ultimate goal (aside from finding out about a better way to go about this) would be to be able to have an array of function calls, like;
A[n][0]( O, A[n][1], A[n][2] );
Where;
O is the instance the function is altering
A[n][0] is a function (Equality or Comparison)
A[n][1] is the variable, eg; "x", O["x"] (or a pointer to that variable in the case of C++)
A[n][2] is the value to alter the variable by, or compare it to.
And I'm not sure how I would rewrite this into C++, or alter it to work in another way.
Aftermath / Additional Information
What I'm actually aiming to do is be able to give an object a set of instructions at the time of it's creation, through the constructor. For example upon creation give an object instructions to wait 64 frames, and then rotate in the opposite direction, would have been something like this;
t.AI = [ [ 1, AIF.CompareET, "STATE", 0, AIF.CompareGT, "FRAME", 64, 0, AIF.EqualityAT, "baseRotation", 180, AIF.EqualityET, "STATE", 1 ] ];
In pseudocode;
(The 1 in the array denotes how to read the rest of the array, in this case everything before the odd 0 [ The one that comes after 64 ] is a comparison. If any of those fail, anything after the 0 will not be looked at )
Compare STATE is equal to (ET) 0, if true
Compare FRAME is greather than (GT) 64, if true
Add 180 to (AT) baseRotation, Set STATE equal to 1
Sorry that this turned out really long. I hope it's understandable, and I'm not asking something stupidly difficult to explain.
You can store functions using function pointers or functors. Variant types though are not natively supported by C++, you have to use custom solutions there.
One possibility would be to use Boost.Any (or better, Boost.Variant if you only use a fixed set of types):
typedef void (*Function)(Object*, const std::string&, boost::any&);
std::vector<Function> functions;
Given some function:
void f(Object* obj, const std::string& name, boost::any& value) {
// ...
}
you could store and call it similar to your example:
functions.push_back(&f);
functions[0](obj, "x", boost::any(500));
To utilize a declarative syntax, there are three options that come to my mind:
you use a similar approach and have central "interpreter" function, e.g. based on a switch (don't forget to switch to integers or pointers-to-members instead of strings if you need performance)
you invent your own language and generate C++ code from description files
you compose function objects in a declarative way
To do composition, you could use Boost.Bind or something like custom objects that represent operations:
struct Operation {
virtual ~Operation() {}
virtual bool operator()(Object&) = 0;
};
template<class T>
struct GreaterThen : Operation {
typedef T Object::*Member;
Member member;
const T value;
CompareGT(Member member, const T& value) : member(member), value(value) {}
bool operator()(Object& obj) { return (obj.*member > value); }
};
template<class T>
struct SetTo : Operation {
typedef T Object::*member;
Member member;
const T value;
SetTo(Member member, const T& value) : member(member), value(value) {}
bool operator()(Object& obj) { obj.*member = value; return true; }
};
Now we can build operation lists:
typedef std::vector<Operation*> OpList;
OpList operation;
operations.push_back(new GreaterThen<int>(&Object::Frame, 64));
operations.push_back(new SetTo<int>(&Object::State, 1));
We can use helper functions to avoid having to specify the template types:
template<class T>
Operation* opGreaterThen(T Object::*mem, const T& val) {
return new GreaterThen<T>(mem, val);
}
Assuming a similar helper for SetTo and using Boost.Assign the above becomes:
OpList operations = boost::assign::list_of
(opGreaterThen(&Object::Frame, 64))
(opSetTo (&Object::State, 1));
Executing the operations becomes the following then:
OpList::iterator it = operation.begin();
for( ; it != operations.end(); ++it) {
Operation& op = *it; // just for readability
if(!op(someObject)) break; // stop if operation returns false
}
Wow.
Reading through that slowly suggests what you're trying to end up with is an array of function calls and you can choose a different function with the same parameters (but different implementation) for different actions and choose the correct one for the correct case.
If that is the case, you're looking for function pointers. Try this tutorial.
You should be able to use a function pointer with an argument set and point it to the correct function based on your needs. You won't need an array of function pointers for this either - any function that matches the definition should do. From the tutorial, declare a function pointer like this:
int (TMyClass::*functptr)(classname, int, int) = NULL; // C++
Then assign it later:
this.functptr = &TMyClass::doitthisway;
While it is possible (although a pain) to have an array of arbitrary types, you pretty much never need it, since you have to know something about what is where to do anything interesting with it: for example, your 'TL;DR' example seems to look something like:
struct AIRule {
// Can only handle comparing ints, see later for more general solution.
typedef bool compare_type(AIObject*, AIObject::*int, int);
compare_type* compare;
AIObject* object;
AIObject::int* member;
int comparand;
};
So now you can do something like:
bool ai_equal(AIObject* object, AIObject::int* member, int comparand) {
return object->*member == comparand;
}
...
ai[n].compare = &ai_equal;
ai[n].object = some_object;
ai[n].member = &AIObject::some_member;
ai[n].comparand = 50;
...
if (ai[n].compare(ai[n].object, ai[n].member, ai[n].comparand)) {
...
}
This just moves the any type problem from the rules array to member though. C++ needs to know at least how many bytes a member is, and a string (for example) can be much bigger than an int. You can get around this by using pointers: which essentially is C++'s version of any, but you then need to delete it yourself (or you will leak memory!), at which point the interface method below becomes simpler.
If I was doing what you seem to want, I would use inheritance:
struct Sprite {
int frame;
double rotation;
Sprite() {
frame = 0;
rotation = 0.0;
}
virtual ~Sprite() {}
virtual void think() {
++frame;
}
virtual void draw() {
...
}
};
struct RotatingSprite : public Sprite {
int state;
MyShape() {
state = 0;
}
void think() {
Sprite::think();
if (state == 0 && frame > 64) {
state = 1;
rotation += 180.0;
}
}
};
Or a function pointer:
struct Sprite {
int frame;
double rotation;
void (*think)(Sprite*);
Sprite() {
frame = 0;
rotation = 0.0;
}
};
void rotate_think(Sprite* sprite) {
if (sprite->state == 0 && sprite->frame > 64) {
sprite->state = 1;
sprite->rotation += 180.0;
}
}
...
sprite->think = &rotate_think;
If you really need to do it dynamically I would recommend using the ++ part of C++. For the predicates (a predicate is just something that returns a boolean, like isLowerCase()) create an AIPredicate interface, and the actions an AIAction interface:
struct AIPredicate {
// "When you delete an AIPredicate, delete the full type, not just this interface."
virtual ~AIPredicate() {}
// "You can treat this as a function (operator()) but I'm not providing an implementation here ( = 0)"
virtual bool operator()(AIObject* object) = 0;
};
struct AIAction {
virtual ~AIAction() {}
virtual void operator()(AIObject* object) = 0;
};
struct AIRule {
// std::auto_ptr (or std::unique_ptr if you can use C++0x) will delete predicate for you.
// Add "#include <memory>" to your includes if it complains (most std headers will include it already)
std::auto_ptr<AIPredicate> predicate;
std::auto_ptr<AIAction> action;
};
Now you can make types like:
struct AIFrame : public AIPredicate {
// Implement the operator() member AICondition promises.
bool operator()(AIObject* object) {
return object->foo < 100;
}
};
...
// Use .reset() instead of = if you use std::unique_ptr.
ai[n].predicate = new AIFooIsLow();
If you want to have a very general predicate type, you can use the very powerful (and complicated) templates feature:
// The naming convention I'm using here is 'T'TitleCase for template parameters, TitleCase for types,
// lower_case for arguments and variables and '_'lower_case for members.
template<typename TMemberType, AIObject::TMemberType* TMember>
struct AIMemberEquals : public AIPredicate {
// Constructor: Initializes a new instance after it is created.
AIMemberEquals(TMemberType comparand) {
// Save comparand argument so we can use it in operator().
_comparand = comparand;
}
bool operator()(AIObject* object) {
return object->*TMember == comparand;
}
// Stores the value to compare.
TMemberType _comparand;
};
Unfortunately, creating templates looks a bit crazy:
ai[n].predicate = new AIMemberEquals<int, &AIObject::some_member>(100);
Read it as "create a new instance of (the type that AIMemberEquals applied to int and (the some_member member of AIObject) creates), with the argument 100".
When you have multiple predicates memory management becomes a bit more difficult without C++0x's unique_ptr or shared_ptr, types that will delete the object for you, since std::auto_ptr doesn't work in containers:
#include <vector>
struct AIData {
// vector is fairly close to AS3's Array type, it is a good default for
// arrays of changing or unknown size.
std::vector<AIPredicate*> predicates;
// Destructor: will be run before the memory for this object is freed.
~AIData() {
for (int i = 0; i != predicates.size(); ++i) {
delete predicates[i];
}
}
};
...
ai[n].predicates.push_back(new AIFooIsLow());
...
for (int i = 0; i != ai[n].predicates.size(); ++i) {
(*ai[n].predicates[i])(ai[n].object);
}
In C++0x:
struct AIData {
// unique_ptr will delete it for you, so no ~AIData() needed.
std::vector<unique_ptr<AIPredicate>> predicates;
};
Your final example could in C++ look something like:
std::auto_ptr<Shape> shape(new Shape());
...
std::auto_ptr<AIRule> rule(new AIRule());
rule->predicates.push(new AIMemberEquals<int, &Shape::state>(0));
rule->predicates.push(new AIMemberGreater<int, &Shape::frame>(64));
rule->actions.push(new AIAddMember<double, &Shape::rotation>(180.0));
rule->actions.push(new AISetMember<int, &Shape::state>(1));
shape->ai.push(rule); // .push(std::move(rule)); if you are using unique_ptr
Certainly not as pretty, but it works and is fairly flexible.