avoiding if statements on a static boolean for logic decision making - c++

I have a class whose member itemType is only set once and never modified but it is used in many if-statements to decide which function to call.
Since itemType is only set once is there way to avoid the if statements else where in the class. This will simplify and clean the code and as a bonus will also save the overhead of if checks.
I was thinking about function a pointer taht I can initiatlize in the constructor based on the itemType value.
Is there any alternate and a better way of doing that?
Please note the original class and code base is large and I cant go around creating child classes based on itemtype.
enum ItemTypes
{
ItemTypeA,
ItemTypeB,
};
class ItemProcessing
{
public:
//This function is called hundreds of times
void ProcessOrder(Order* order)
{
//This member itemType is set only once in the constructor and never modified again
//Is there a way to not check it all the time??
if (itemtype == ItemTypes::ItemTypeA )
{
ProcessTypeA(order)
}
else if (itemtype == ItemTypes::ItemTypeB )
{
ProcessTypeB(order)
}
}
ItemProcessing(ItemTypes itype)
{
itemtype = itype; //can I do something here like setting a function pointer so I dont have to check this property in ProcessOrder() and call the relevant function directly.
}
private:
ItemTypes itemtype;
void ProcessTypeA(Order*);
void ProcessTypeB(Order*);
};

Use an array of function pointers, indexed by itemtype, like this:
typedef void(*ProcessType_func_t)(Order *);
ProcessType_func_t processType_f[] = {
ProcessTypeA,
ProcessTypeB
};
Then you can do:
void ProcessOrder(Order *order) {
ProcessType_f[itemtype](order);
}
If you have lots of different functions that need to be dispatched like this, you can use a structure.
struct {
ProcessType_func_t processType_f,
OtherType_func_t otherType_f,
...
} dispatchTable[] = {
{ ProcessTypeA, OtherTypeA, ... },
{ ProcessTypeB, OtherTypeB, ... }
};
Then you would use it as:
dispatchTable[itemtype].processType_f(order);
Finally, you could do the fully object-oriented method, by defining new classes:
class Processor { // abstract base class
public:
virtual void Process(Order *order) = 0;
};
class ProcessorA {
public:
void Process(Order *order) {
ProcessTypeA(order);
}
}
class ProcessorB {
public:
void Process(Order *order) {
ProcessTypeB(order);
}
}
Then you can have a member variable
Processor *processor;
and you initialize it when you set itemtype
ItemProcessing(ItemTypes itype)
{
itemtype = itype;
if (itemtype == ItemTypeA) {
processor = new ProcessorA;
} else {
processor = new ProcessorB;
}
}
Then you would use it as:
processor->Process(order);
This is easily expanded to support more functions that need to dispatch on itemtype -- they all become methods in the classes.
I hope I got the syntax right, I don't actually do much C++ OO programming myself.

You can consider to use either a couple of pointers to member methods or the state pattern.
The former solution has probably higher performance, while the latter is more elegant and flexible (at least from my point of view).
For further details on the state pattern, see here. This pattern fits well with your problem, even though you have to refactor a bit your classes.
I guess the first suggestion is indeed quite clear and does not require further details.

In c++ pointer to function should be mimic with virtual function and inheritance. (Polymorphism)
Define a virtual class including a pure virtual methods
processOrder ( Order* ordre);
And define subclass for each value of your enum.
You can use abstract factory pattern to creat those object or either if needed.
I can write the code if wish.

Related

Going around in circles with Pure Virtual Functions

I am using a simple inheritance structure to try and simplify code structure and reduce common code usage across a number of classes.
The idea is to allow a simple linked list structure within the class to allow the entire set of instances to be iterated.
EDIT:
To elaborate, this is intended to support a bunch of classes that can be aggregated by type and then iterated by type. Hence the decision to use a linked list with a static "first member" held in the class.
The actual application is support classes for switches, buttons, lights, parsers inside an embedded platform (Arduino).
When I create 20 switch instances of cSwitch (for instance)
cSwitch cSwitchA(_pin,callback);
cSwitch cSwitchB(_pin,callback);
I can then use
loop() {
cSwitch::checkAll();
}
inside my "loop" function, rather than having to do:
void loop() {
cSwitchA::check();
cSwitchB::check();
...
}
...
extending this to other classes, I can do:
loop() {
cSwitch::checkAll();
cLight::checkAll();
cParser::checkAll();
}
all of the members are declared with pins, parameters and callback functions.
I think that the problem is not specific to Arduino, but a little more abstract in that it could probably arise in any similar scenario.
class cGroup {
public:
cGroup(){cGroup::register_instance(this);}
~cGroup();
static void register_instance(cGroup * _inst) {
cGroup pInstance=nullptr;
if (_inst->getFirstInstance()==nullptr) {
_inst->setFirstInstance(_inst);
return;
} else {
pInstance=_inst->getFirstInstance();
}
while (1) {
if (pInstance->getNextInstance() == nullptr) {
pInstance->setNextInstance(_inst);
return;
} else {
pInstance=_inst->getNextInstance();
}
}
}
static void checkAll(cGroup * firstInstance);
virtual cGroup* getFirstInstance()=0;
virtual void setFirstInstance(cGroup*)=0;
};
class cMemberA: public cGroup {
public:
cMemberA():cGroup(){}
static void checkAll() {cGroup::checkAll(cMemberA::firstInstance);}
static cGroup * _firstInstance;
cGroup* getFirstInstance() {return cMemberA::firstInstance;}
void setFirstInstance(cGroup* _firstInstance){cMemberA::firstInstance = _firstInstance;}
};
cGroup * cMemberA::_firstInstance = nullptr;
class cMemberB: public cGroup {
... etc
};
The main need to do it this way stems from the fact that if I push the static "firstInstance" variable up into the cGroup class, it only allows for one long list containing many different types of Member classes. What I want is one list per type of Member class, meaning that I need to scope the static "firstInstance" variable into the Member class itself.
The problem I am finding is that I am going around in circles trying to figure out how to invoke getFirstInstance() and setFirstInstance from within the member class while only having a cGroup* pointer to play with.
If I have pure virtual classes inside of cGroup with cGroup * declarations, then these are not satisfied by declarations in the subclass of cMemberA * (and cMemberB *, cMemberC etc...)
declaring the "first-instance" members as "cMemberA*" leads to compilation issues (abstract class), but declaring them as cGroup* leads to an inability to invoke the required members in the cMemberA instances.
Is there another way to do this, or am I fundamentally going about this the wrong way? Please be gentle, it's been about 10 years since my last rodeo with C++ and I'm not a professional programmer.
Of course I can get around this issue by dispensing with cGroup entirely and just putting everything into cMemberA, cMemberB etc. but then that's where I was last week and as far as I recall, that's not the best way with C++ as the whole idea is to reduce code duplication.
The code you posted does have a problem, but I think it's different from the ones you mentioned.
The problem I see is that you call register_instance from the cGroup constructor, and then call virtual functions, eg. getFirstInstance() from that. Virtual calls don't work as expected at construction time (because the vtable isn't properly initialized yet). Basically you need to construct your object first, and you can call register once the object is fully constructed, in a second step.
The usual way around this would be to use a factory function instead of directly the constructors. The factory function would first create a new instance, then register that fully created instance, then return it. BUT, your factory function would need to create the instance on heap and return a pointer (if it returned by value, then it would register an instance, return a copy of it, then destruct the registered instance). Usually this isn't a problem, types with virtual functions are usually used as reference types (not value types) anyway, but in your particular embedded case that may be a problem.
Another way is to create intermediate classes between cGroup and cMemberX, eg. cMemberA: cMemberABase: cGroup. first_instance and getFirstIntsnace() etc. would be defined in cMemberABase. Then cMemberA's constructor could call cGroup::register, because by that time the vtable for cMemberABase is already constructed (but not yet for cMemberA!). In other words, when in the subclass constructor, the base subobject's virtuals can already be used, but not the virtuals defined in the subclass.
class cGroup {
protected:
cGroup(){}
public:
template <class G> static G* make() {
G* instance = new G();
cGroup::register_instance(instance);
return instance;
}
~cGroup() {}
static void register_instance(cGroup * _inst) {
cGroup* pInstance=nullptr;
if (_inst->getFirstInstance()==nullptr) {
_inst->setFirstInstance(_inst);
return;
} else {
pInstance=_inst->getFirstInstance();
}
while (1) {
if (pInstance->getNextInstance() == nullptr) {
pInstance->setNextInstance(_inst);
return;
} else {
pInstance=_inst->getNextInstance();
}
}
}
static void checkAll(cGroup * firstInstance) {
}
virtual cGroup* getFirstInstance()=0;
virtual void setFirstInstance(cGroup*)=0;
cGroup* getNextInstance() { return nextInstance; }
void setNextInstance(cGroup* nextInstance) { this->nextInstance = nextInstance; }
cGroup* nextInstance = nullptr;
};
class cMemberABase: public cGroup {
protected:
friend class cGroup;
cMemberABase():cGroup(){}
public:
static void checkAll() {cGroup::checkAll(cMemberABase::firstInstance);}
static cGroup * firstInstance;
cGroup* getFirstInstance() {return cMemberABase::firstInstance;}
void setFirstInstance(cGroup* _firstInstance){cMemberABase::firstInstance = _firstInstance;}
};
cGroup* cMemberABase::firstInstance = nullptr;
class cMemberBBase: public cGroup {
protected:
friend class cGroup;
cMemberBBase():cGroup(){}
public:
static void checkAll() {cGroup::checkAll(cMemberBBase::firstInstance);}
static cGroup * firstInstance;
cGroup* getFirstInstance() {return cMemberBBase::firstInstance;}
void setFirstInstance(cGroup* _firstInstance){cMemberBBase::firstInstance = _firstInstance;}
};
cGroup* cMemberBBase::firstInstance = nullptr;
class cMemberA: cMemberABase {
public:
cMemberA(): cMemberABase() {
cGroup::register_instance(this);
}
};
class cMemberB: cMemberBBase {
public:
cMemberB(): cMemberBBase() {
cGroup::register_instance(this);
}
};
It is much simpler and idiomatic to let the outer code organize objects into containers as needed:
cSwitch cSwitches[2] = {{_pin,callback}, {_pin,callback}};
loop() {
for (auto& switch : cSwitches)
switch.check();
}
If you want "names" for the elements, add an enum:
enum cSwitchNames { A, B, count };
cSwitches[A].check(); // if you need to check just one

How to change a behavior for all instances of a class in a header only class

For a class, which is only defined in a header, I need a special behavior of one method for all instance of the class. It should be depending on a default value, which can be changed any time during runtime. As I do not want a factory class nor a central management class I came up with that idea:
class MyClass
{
public:
void DoAnything() // Methode which should be act depending on default set.
{
// Do some stuff
if(getDefaultBehaviour())
{
// Do it this way...
}
else
{
// Do it that way...
}
}
static bool getDefaultBehaviour(bool bSetIt=false,bool bDefaultValue=false)
{
static bool bDefault=false;
if(bSetIt)
bDefault=bDefaultValue;
return bDefault;
}
};
It works, but it looks a little awkward. I wonder if there is a better way following the same intention.
In the case where I want to use it the software already created instances of that class during startup and delivered them to different parts of the code. Eventually the program gets the information how to treat the instances (for e.g. how or where to make themselves persistent). This decision should not only affect new created instances, it should affect the instances already created.
I'd advise to use a simple method to simulate a static data member, so the usage becomes more natural:
class MyClass
{
public:
// get a reference (!) to a static variable
static bool& DefaultBehaviour()
{
static bool b = false;
return b;
}
void DoAnything() // Methode which should be act depending on default set.
{
// Do some stuff
if(DefaultBehaviour())
{
// Do it this way...
}
else
{
// Do it that way...
}
}
};
where the user can change the default at any time with
MyClass::DefaultBehaviour() = true;
My thanks to Daniel Frey with his answer which I already marked as the best. I wanted to add my final solution which is based on the answer from Frey. The class is used by some c++ beginners. As I told them to use always getter and setter methods, the way described by Frey looks very complex to beginners ("uuuh, I can give a function a value?!?!"). So I wrote the class like followed:
class MyClass
{
public:
// get a reference (!) to a static variable
static bool& getDefaultBehaviour()
{
static bool b = false;
return b;
}
static void setDefaultBehaviour(bool value)
{
getDefaultBehaviour()=value;
}
void DoAnything() // Methode which should be act depending on default set.
{
// Do some stuff
if(getDefaultBehaviour())
{
// Do it this way...
}
else
{
// Do it that way...
}
}
};
for the user, I looks now like a usual getter and setter.

Collection of objects with different interface

I'm writing a decision tree based algorithm (ID3). I use two classess to represent a node. ResultNode, and TestNode. ResultNode is kind of leaf. It simply contains a result with a method to aquire it. TestNode is simply not-leaf. It has an array of children, and test function.
The most basic approach is create more general class Node which would provide interface for both of them, however both test, and getResult are specific to it's classess. Having test function in ResultNode doesn't make any sense, as well as having getResult in TestNode. They should just return any value for opposite classess, and never be used.
class Node {
public: //I don't care about encapsulation in this example
bool is_leaf;
virtual int getResult() { return 0; } //int because, type isn't important here
virtual int test() { return 0; }
}
Then I must be aware to call only functions appropriate to object type (hence boolean variable). The only thing I can do to protect the code is inserting some ugly macro that throws warnings when original functions are called. But all this pattern look very ugly in my opinion.
Of course I can also move those functions to desired subclassess, but as all pointers are Node type I would need to use casting in order to call those methods, which is way more uglier. (even my supervisor says so)
Now I wonder, whether it would be any better if I had used a function that returns a reference of given type:
TestNode& getTestNode() {
return *nodePointer;
}
I am almost sure that there is a design pattern that use such technique, but I looks like a nasty hack to me.
Edit:
After some research I found out that you can deal with casting problem from my second approach using a Visitor or Command design pattern.
In actual use it seems that the concept of a TestNode is that it ultimately allows getting a ResultNode - so Node can have a getResult method that for a TestNode walks down the tree and for a ResultNode returns this -- the test method is likely a private method of TestNode that is used to find the ResultNode.
Something like:
class ResultNode;
class Node
{
public:
virtual ResultNode * getResult() = 0;
};
class TestNode : public Node
{
public:
virtual ResultNode * getResult() {
/* does things to find next TestNode or ResultNode */
return found->getResult();
}
private:
test() { ... }
Node * children; // dynamic array of Nodes (TestNode or ResultNode)
};
class ResultNode : public node
{
virtual ResultNode * getResult() { return this; }
}

Converting objects of base class to derived class

I asked a couple days ago some clarifications on inheritance, a concept I am still trying to understand. Here is the follow up question, since I am still facing problems.
In my project I have 2 types of objects, Hand and Face, both inheriting from the base class BodyPart. BodyPart is something like this:
class BodyPart
{
public:
typedef boost::shared_ptr<BodyPart> BodyPartPtr;
BodyPart();
virtual ~BodyPart();
private:
int commonMember1;
double commonMember2;
public:
int commonMethod1();
int CommonMethod2();
}
while Hand is something like this:
class Hand : public BodyPart
{
public:
Hand();
~Hand();
private:
int numFingers;
double otherVar;
public:
int getNumFingers();
void printInfo();
}
I also have a vector of BodyPart elements
std::vector<BodyPart::BodyPartPtr> cBodyParts;
composed of Hand or Head objects. In the previous question I was told that this approach makes sense, I just had to cast from the base class to the derived using boost static_pointer_cast
Now, the problem now is that for some of the objects in the vector I don't know whether they are Hand or Head, so at some point in my code I can have in cBodyParts some Hand elements, some Head elements as well as some BodyPart elements. After some further analysis I am able to correctly classify the latter as either Hand or Head and modify accordingly the elements in the vector, but I have no idea on how to make it. Shall I just delete the case class element and create a derived one with the same property? Shall I just avoid inheritance in case like this?
Thanks in advance for the help
EDIT: I have augmented the examples to make them clearer.
Relaying on casts is usually a sign of a bad design. Casts have their place, but this does not look to be it.
You need to ask yourself what do you want to do with the objects stored in cBodyParts. For sure, you will be doing different things with a Hand or with a Head, but you can probably abstract them somehow: this is what virtual functions do. So, in addition to what you have already written for your classes, you would just need an additional virtual function in them:
class BodyPart
{
// Same as you wrote, plus:
public:
virtual void InitialisePart() = 0; // Pure virtual: each body part must say how to process itself
virtual void CalibrateJoints() {} // Override it only if the body part includes joints
}
class Head : public BodyPart
{
// Same as you wrote, plus:
public:
virtual void InitialisePart() {
// Code to initialise a Head
}
// Since a Head has no joints, we don't override the CalibrateJoints() method
}
class Hand : public BodyPart
{
// Same as you wrote, plus:
public:
virtual void InitialisePart() {
// Code to initialise a Hand
}
virtual void CalibrateJoints() {
// Code to calibrate the knuckles in the hand
}
}
And then you no longer need any casts. For instance:
for (BodyPart::BodyPartPtr part : cBodyParts) {
part->InitialisePart();
part->CalibrateJoints(); // This will do nothing for Heads
}
As you can see, no casts at all and everything will work fine. This scheme is extensible; if you later decide that you need additional classes inheriting from BodyPart, just write them and your old code will work correctly:
class Torso : public BodyPart
{
public:
virtual void InitialisePart() {
// Code to initialise a Torso
}
// The Torso has no joints, so no override here for CalibrateJoints()
// Add everything else the class needs
}
class Leg : public BodyPart
{
public:
virtual void InitialisePart() {
// Code to initialise a Leg
}
virtual void CalibrateJoints() {
// Code to calibrate the knee
}
// Add everything else the class needs
}
Now you don't need to change the code you wrote previously: the for loop above will work correctly with and Torso or Leg it finds with no need for an update.
The hip bone's connected to the thigh bone...
I take it you have some composite of all the body parts, maybe a Body class.
What do you want the body to do?
Render itself
Serialise
Ouput its volume, or bounding box, or some other metric
Re-orient itself in response to input
Respond to an inverse-kinematic physical model
The list could probably go on. If you know exactly what you want the Body to do you can put that function in the BodyPart base class, and have Body iterate over the composite hierarchical structure of all the connected body parts, calling render, for example.
An alternative is to use a Visitor, which is effectively a way of dynamically adding methods to a static inheritance hierarchy.
As Kerrek SB pointed out this is not feasible at all, but for the sake of answering the actual question, dynamic_cast is what you are looking for.
Use virtual functions, they will simplify a lot your problem.
Else, you can add some methods to distinguish between different types. However, do it only if you cannot do it another way, ie if you cannot do it via virtual functions.
Example 1:
// in BodyPart; to be reimplemented in derived classes
virtual bool isHand() const { return false; }
virtual bool isHead() const { return false; }
// in Hand (similar to what will be in Head)
bool isHand() const { return true; }
// How to use:
BodyPart::pointer ptr = humanBodyVector[42]; // one item from the array
if(ptr->isHand())
processHand(/*cast to hand*/)
else if(ptr->isHead())
// ...
Example 2: let the derived classes handle the cast
// in BodyPart; to be reimplemented in derived classes
virtual Hand* toHand() const { return 0; }
virtual Head* toHead() const { return 0; }
// in Hand (similar to what will be in Head)
Hand* toHand() const { return this; }

Optional Member Objects

Okay, so you have a load of methods sprinkled around your system's main class. So you do the right thing and refactor by creating a new class and perform move method(s) into a new class. The new class has a single responsibility and all is right with the world again:
class Feature
{
public:
Feature(){};
void doSomething();
void doSomething1();
void doSomething2();
};
So now your original class has a member variable of type object:
Feature _feature;
Which you will call in the main class. Now if you do this many times, you will have many member-objects in your main class.
Now these features may or not be required based on configuration so in a way it's costly having all these objects that may or not be needed.
Can anyone suggest a way of improving this?
EDIT: Based on suggestion to use The Null Object Design Pattern I've come up with this:
An Abstract Class Defining the Interface of the Feature:
class IFeature
{
public:
virtual void doSomething()=0;
virtual void doSomething1()=0;
virtual void doSomething2()=0;
virtual ~IFeature(){}
};
I then define two classes which implement the interface, one real implementation and one Null Object:
class RealFeature:public IFeature
{
public:
RealFeature(){};
void doSomething(){std::cout<<"RealFeature doSomething()"<<std::endl;}
void doSomething1(){std::cout<<"RealFeature doSomething()"<<std::endl;}
void doSomething2(){std::cout<<"RealFeature doSomething()"<<std::endl;}
};
class NullFeature:public IFeature
{
public:
NullFeature(){};
void doSomething(){std::cout<<"NULL doSomething()"<<std::endl;};
void doSomething1(){std::cout<<"NULL doSomething1()"<<std::endl;};
void doSomething2(){std::cout<<"NULL doSomething2()"<<std::endl;};
};
I then define a Proxy class which will delegate to either the real object or the null object depending on configuration:
class Feature:public IFeature
{
public:
Feature();
~Feature();
void doSomething();
void doSomething1();
void doSomething2();
private:
std::auto_ptr<IFeature> _feature;
};
Implementation:
Feature::Feature()
{
std::cout<<"Feature() CTOR"<<std::endl;
if(configuration::isEnabled() )
{
_feature = auto_ptr<IFeature>( new RealFeature() );
}
else
{
_feature = auto_ptr<IFeature>( new NullFeature() );
}
}
void Feature::doSomething()
{
_feature->doSomething();
}
//And so one for each of the implementation methods
I then use the proxy class in my main class (or wherever it's required):
Feature _feature;
_feature.doSomething();
If a feature is missing and the correct thing to do is ignore that fact and do nothing, you can get rid of your checks by using the Null Object pattern:
class MainThing {
IFeature _feature;
void DoStuff() {
_feature.Method1();
_feature.Method2();
}
interface IFeature {
void Method1();
void Method2();
}
class SomeFeature { /* ... */ }
class NullFeature {
void Method1() { /* do nothing */ }
void Method2() { /* do nothing */ }
}
Now, in MainThing, if the optional feature isn't there, you give it a reference to a NullFeature instead of an actual null reference. That way, MainThing can always safely assume that _feature isn't null.
An auto_ptr by itself won't buy you much. But having a pointer to an object that you lazily load only when and if you need it might. Something like:
class Foo {
private:
Feature* _feature;
public:
Foo() : _feature(NULL) {}
Feature* getFeature() {
if (! _feature) {
_feature = new Feature();
}
return _feature;
}
};
Now you can wrap that Feature* in a smart pointer if you want help with the memory management. But the key isn't in the memory management, it's the lazy creation. The advantage to this instead of selectively configuring what you want to go create during startup is that you don't have to configure – you simply pay as you go. Sometimes that's all you need.
Note that a downside to this particular implementation is that the creation now takes place the first time the client invokes what they think is just a getter. If creation of the object is time-consuming, this could be a bit of a shock to, or even a problem for, to your client. It also makes the getter non-const, which could also be a problem. Finally, it assumes you have everything you need to create the object on demand, which could be a problem for objects that are tricky to construct.
There is one moment in your problem description, that actually would lead to failure. You shouldn't "just return" if your feature is unavailable, you should check the availability of your feature before calling it!
Try designing that main class using different approach. Think of having some abstract descriptor of your class called FeatureMap or something like that, which actually stores available features for current class.
When you implement your FeatureMap everything goes plain and simple. Just ensure (before calling), that your class has this feature and only then call it. If you face a situation when an unsupported feature is being called, throw an exception.
Also to mention, this feature-lookup routine should be fast (I guess so) and won't impact your performance.
I'm not sure if I'm answering directly to your question (because I don't have any ideas about your problem domain and, well, better solutions are always domain-specific), but hope this will make you think in the right way.
Regarding your edit on the Null Object Pattern: If you already have a public interface / private implementation for a feature, it makes no sense to also create a null implementation, as the public interface can be your null implementation with no problems whatsoever).
Concretely, you can have:
class FeatureImpl
{
public:
void doSomething() { /*real work here*/ }
};
class Feature
{
class FeatureImpl * _impl;
public:
Feature() : _impl(0) {}
void doSomething()
{
if(_impl)
_impl->doSomething();
// else case ... here's your null object implementation :)
}
// code to (optionally) initialize the implementation left out due to laziness
};
This code only benefits from a NULL implementation if it is performance-critical (and even then, the cost of an if(_impl) is in most cases negligible).