I have handles of different types inside a hierarchy.
class Handle { common data }
class HandleA : Handle { data specific to a }
class HandleB : Handle { data specific to b }
Most parts of the code only deal with handles. But some parts ( the "managers" for HandleA/HandleB ) need access to the data in the child classes.
eg:
void ManagerA::DoSomething(Handle handle)
{
// needs access to data in handleA
}
Are there any solutions to this that don't involve casting?
My ideas so far:
- Save the additional data inside a map in ManagerA/B and use the handle to lookup that data (additional hashtable lookup)
- Have polymorphic methods in the handles ( handle.DoSomething()) that call the appropiate manager methods (needs an additional pointer in every handle)
- Screw it and use casts
Any ideas? Am I missing something?
Thanks
Receiving an argument by value, as you're doing in:
void ManagerA::DoSomething(Handle handle)
WILL "slice away" anything in the passed-in argument beyond what a Handle instance holds, so your handle argument will have NO "extra data". You absolutely need to pass by pointer or reference (possibly const if the data does not need to be modified, of course).
That being said, the normal polymorphic approach involves defining virtual methods within the base class and overriding them appropriately in the subclasses. Why not follow such a perfectly normal architecture rather than fighting against the OO approach? There may be valid reasons (which justify e.g. adopting some variant on a visitor pattern, etc), but you just don't explain enough of the forces in play for us to be able to help along those lines; on the information as presented I'd have to suggest "rearchitect to use virtual methods".
If it's data specific to only one -- and only one type, use dynamic_cast<T>, that's what it's there for. Otherwise declare a virtual function in the base class.
EDIT: It's unlikely that any solution is going to result in measurable performance differences at runtime.
I wouldn't use polymorphism for handles - being handles rather than pointers, they are supposed to absolutely hide the implementation of the referenced object. If you use virtual functions, the user of the handle could call those functions, which is surely a bad idea.
The two common solutions are casting and using a map. If the later, your handle doesn't even have to be a class - it could just as well be an int or so. On Windows, handles are void* pointers. I have no idea what's really behind the pointer, but I really don't care. And that's the point of handles, as far as I'm concerned.
What about changing the signature for DoSomething to:
void ManagerA::DoSomething(HandleA handle)
Your first and third ideas would work. Another idea is to use double-dispatch (I don't know if that Wikipedia article is understandable: the original article/explanation in Meyer's More Effective C++ is 20-odd pages long), which means implementing a virtual method like Handle::DoSomething(Manager&).
Another possibility is storing the concrete type in each handle, possibly as an integer or an enum. You either hard-code all the possible concrete handle types, or use some sort of type registration mechanism. Obviously this approach has its own drawbacks, but it is another possibility, one you didn't mention. It's the approach X-Windows used for event types. The event data structure was a union of all possible event data, with a type variable indicating the true data type of a particular event. Not saying it's good, just saying it's an option, one that doesn't require dynamic casting.
enum HandleType
{
HANDLE_TYPE_A,
HANDLE_TYPE_B
};
class Handle
{
private:
HandleType _type;
protected:
Handle(HandleType type) :
_type(type)
{}
public:
HandleType get_type() const
{ return _type; }
};
class HandleA
{
HandleA() :
Handle(HANDLE_TYPE_A)
{}
};
void ManagerA::DoSomething(Handle& handle)
{
if (handle.get_type() == HANDLE_TYPE_A)
do_something();
}
Related
TL;DR version:
I am designing a class in C++14 to be generic. Below I describe a design problem, and I would be grateful for a solution to implement what I'm trying, or a suggestion for a redesign.
Say the class I'm designing is called Algo. Its constructor is passed a unique_ptr to a type, say Business, which implements an interface (i.e., inherits from a pure virtual class) and does most of the serious work.
I want an object of type Algo to be able to return a pointer (or even a copy) of a data member from the Business object that it owns. But it can't know the type that Business will want to return. I expect the owner of Algo to know what will come out based on what Business he passed in.
In my C days, I would blow off the type system by passing around void* and casting as needed. But that sort of thing now wreaks to me.
More detail:
So, a sort of pseudo-C++14 implementation of the above situation might look like:
// perhaps a template here?
class AbstractBusiness {
. . .
public:
?unknownType? result();
};
class Algo {
//Could be public if needbe.
unique_ptr<AbstractBusiness> concreteBusiness_;
public:
Algo(std::unique_ptr<AbstractBusiness> concreteBusiness);
auto result() {return concreteBusiness_.result();}
};
class Business : public AbstractBusiness {
. . .
public:
std::valarray<float> data_;
std::valarray<float> result() {return data_;}
};
:::
auto b = std::unique_ptr<AbstractBusiness>{std::move(new Business())};
Algo a(std::move(b));
auto myResult = a.result();
In this example, myResult will be a std::valarray<float>, but I don't want Algo or the AbstractBusiness interface to have to know that! The creator of b and a should be in charge of knowing what should come out of a.result().
If I am taking a wrong turn in this design, don't hesitate to let me know. I'm a bit green at this point and very open to suggestions.
I've tried...
I obviously can't use auto for a virtual method, nor have a template in a virtual class. These are the only things that stood out.
I'm playing with the idea of making a container interface for whatever Business.result() returns, and just passing pointers to abstract type up to Algo.result(). But I'm starting to feel like there may be a better way, so I'm on here begging for suggestions.
You haven't actually described a design problem. You've described some
implementation choices that you've gone with and a roadblock you've
run into, but we don't know the reasons for the choices.
You tell us that Algo takes ownership of a business via a pointer to a
polymorphic interface AbstractBusiness and must provide a getter for
that business's data, though it doesn't know the concrete type of that
data (because it doesn't know the concrete type of the business).
Neither of these questions have evident answers:-
Why should Algo acquire a business via a polymorphic interface?
Why should Algo provide a getter for the data of its business?
But deciding it must be so leads to the roadblock.
The polymorphic pothole and how to get out it
Q1. leads us to wonder what is the motivation for AbstractBusiness? Platitudinously, it's safe to say you want it to provide a uniform interface for manipulating and querying all sorts of businesses of concrete types that may be determined at runtime.
To be fully fit for that purpose, AbstractBusiness will encapsulate a necessary and sufficient interface for discharging all of the operations and queries on concrete businesses that applications (including but not limited to your own) can reasonably be expected to need. Call that Plan A. What you have discovered is that it isn't fully fit for Plan A. If the application needs at times to manipulate or query "the data" of a business that is represented to it via an AbstractBusiness, then the AbstractBusiness interface needs to provide polymorphic methods to discharge all of those manipulations and queries, and each concrete business class needs to implement them appropriately for the type of data it contains.
Where your AbstractBusiness has the problematic:
?unknownType? result();
you need to code virtual methods that address all of the convincing answers to the question: What might an application want to know about the notional result() , or do to it?
In this light, the suggestion that has been canvassed to introduce another polymorphic interface, AbstractData, ancestral to all of the concrete data types of all the concrete businesses, may be viewed as a suggestion to compensate for the necessary methods that are missing from AbstractBusiness by separately encapsulating them in a rescue abstraction. Better to finish the unfinished AbstractBusiness.
This is all good and scriptural perhaps, but maybe what has actually stopped you from finishing AbstractBusiness already is the perception that the data of BusinessX can be essentially different from that of BusinessY, so that it is impossible to devise a single set of polymorphic methods that is necessary and sufficient to manage both.
If this is the case, it tells you that businesses cannot all be managed through a single abstract interface. AbstractBusiness can't be fully fit for that purpose and, if it has a role, its role can only be to manage polymorphic objects that represent more specialized abstractions, BusinessTypeX, BusinessTypeY, etc., within each of which the variety, if any, of concrete types can be accommodated by a single polymorphic interface.
AbstractBusiness will then present only the interface that is shared
by all businesses. It will have no result() at all and a caller who obtains a pointer to AbstractBusiness with the intention of doing something with
with the thing returned by BusinessTypeX::result() will proceed by dynamically casting the source pointer to BusinessTypeX *, and calling result() through the target pointer only if its not null.
We still do not know what is the motivation of AbstractBusiness. We've just pursued the fairly plausible thought that you have "textbook" ambitions for it - Plan A - and have either failed to realize that you just haven't finished it, or you have grasped that the diversity of the data you're dealing with prevents you from finishing it per Plan A, and don't have a Plan B. Plan B is: Deepen the polymorphic hierarchy and use dynamic_cast<LowerType *>(HigherType *) to secure safe access to the LowerType interface when it outruns the HigherType one. [1]
The turn of Q2. now. Most likely, the reason for Algo::result() is simply: Because it's the done thing for a class to provide getters that directly
answer the client's natural queries, and in this case a natural query is for the data owned by the business that is owned by the Algo. But if the Algo knows its business only as an AbstractBusiness, then it just can't return the data owned by its business, because the reasons already seen mean that AbstractBusiness can't return "the data" to the Algo, or to anything else.
Algo::result() is misconceived identically as AbstractBusiness::result() is misconceived. Given that BusinessXs data and BusinessYs data might need to be queried either through some repertoire of virtual methods that are still TODO in AbstractBusiness (Plan A), or perhaps through methods of BusinessX and BusinessY that are not inherited from AbstractBusiness at all (Plan B), the only query that Algo certainly can and should support with respect to its business is to return the AbstractBusiness pointer
through which it owns its business, leaving it to the caller to query through the pointer or downcast it, if they can, to a lower-type interface they want query. Even if it is possible to finish AbstractBusiness per Plan A, the idea that the missing reportoire of methods should all be duplicated in the interface of Algo just so that a caller never has to receive and downcast an AbstractBusiness pointer is uncompelling. Would every type that manages an AbstractBusiness pointer follow suit?
Summarizing thus far, if AbstractBusiness has a good reason to exist, then you need either to finish it per Plan A, and work through the repercussions of so doing, or else curtail it short of attempting to be a sufficient interface for managing all businesses and bolster it with an enriched polymorphic hierarchy that clients negotiate by dynamic casting, per Plan B; and in either case you should be content for Algo and similar jobsworths in the AbstractBusiness trade just to return their AbstractBusiness pointer to clients who have specialized uses for it.
Better than that, don't go there
But the question of whether AbstractBusiness has a good reason to exist is still dangling, and should you find yourself driven to Plan B that in itself will make the question more pointed: when it transpires that an abstract interface, cast as the root class of a single inheritance hierarchy, cannot deliver Plan A then a doubt arises about the wisdom of the architecture it figures it. Dynamic casting to detect and acquire interfaces is a clunky and expensive mode of flow control and especially vexatious when - as you tell us is your situation - a scope that will have to perform the downcasting rigmarole already knows the type it should "get out" is the type it "put in". Do all the types that are imperfectly descended from the root abstraction need to have a single ancestor, for a reason other than uniformity of interface (since it doesn't give them that)? The economies of generic interfaces are an ever-present goal, but is runtime polymorphism
the right means, or even one of the right means, to realize them in the context of your project?
In your code-sketch, AbstractBusiness serves no end purpose but to furnish a
type that can uniformly fill certain slots in class Algo, with the effect that Algo can operate correctly on any type that exhibits certain traits and
behaviours. As sketched, Algos only requirement of a qualifying type is
that it shall have a result() method that returns something: it doesn't care what. But the fact that you express Algos requirements upon a qualifying type by specifying that it shall be an AbstractBusiness prohibits it from not caring what is returned by result(): AbstractBusiness cannot do that result() method, although any of its descendants might do.
Suppose in that case that you sack AbstractBusiness from the job of enforcing the generic attributes of types on which Algo can operate and let Algo itself do that instead, by making it a template? - since it looks as if what AbstractBusiness is doing for Algo is serving the purpose of a template parameter but sabotaging that very purpose:
#include <memory>
template<class T>
class Algo {
std::unique_ptr<T> concreteBusiness_;
public:
explicit Algo(T * concreteBusiness)
: concreteBusiness_{concreteBusiness}{};
auto result() { return concreteBusiness_->result(); }
};
#include <valarray>
#include <algorithm>
struct MathBusiness {
std::valarray<float> data_{1.1,2.2,3.3};
float result() const {
return std::accumulate(std::begin(data_),std::end(data_),0.0);
}
};
#include <string>
struct StringBusiness {
std::string data_{"Hello World"};
std::string result() const { return data_; }
};
#include <iostream>
int main()
{
Algo<MathBusiness> am{new MathBusiness};
auto ram = am.result();
Algo<StringBusiness> as{new StringBusiness};
auto ras = as.result();
std::cout << ram << '\n' << ras << '\n';
return 0;
}
You see that in this way of transferring the genericity from AbstractBusiness to Algo, the former is left completely redundant, and so removed. This is a nutshell illustration of how the introduction of templates changed the game of C++ design root and branch, making polymporhic designs obselete for most of their prior applications to the crafting of generic interfaces.
We are working from a sketch of your problem context: perhaps there remain good reasons not in sight for AbstractBusiness to exist. But even if there are, they don't per se constitute reasons for Algo not to be a template or to have any dependency on AbstractBusiness. And perhaps they can one by one be eliminated by similar treatments.
Making Algo into a template still might not be a viable solution for you, but if it isn't then there is essentially more to the problem than we have seen. And anyhow take away this rule of thumb: Templates for generic interfaces; polymorphism for runtime adaptation of an interface's behaviour.
[1] What might look like another plan is to encapulate "the data" of each concrete
business in a boost::any or std::experimental::any. But you can probably
see straightaway that this is essentially the same as the idea of encapsulating
the data in a rescue abstraction, using an off-the shelf Swiss Army abstraction,
rather than crafting your own. In either guise, the idea still leaves
callers to downcast the abstraction to the type of real interest to find out
if that's what they've got, and in that sense is a variant of Plan B.
There are several ways to go at this. The easiest way is to not pass the ownership but call Algo by reference:
Business b;
Algo(b);
auto result = b.get_result();
However, sometimes this is not possible. In that case various options open up that can become quite complicated. Let me start with the most versatile and complicated one:
If you know all the types that derive from AbstractBusiness you could use the visitor pattern:
First we declare an abstract method accept in AbstractBusiness that takes a BusinessVisitor. This visitor will be responsible to handle the different types and perform an action based on which type it is visiting:
class BusinessVisitor;
struct AbstractBusiness {
virtual ~AbstractBusiness() = default;
virtual void accept(BusinessVisitor&) const = 0;
};
The BusinessVisitor looks like this:
class BusinessOne;
class BusinessTwo;
struct BusinessVisitor {
virtual ~BusinessVisitor() = default;
virtual void on_business_one(const BusinessOne&) {};
virtual void on_business_two(const BusinessTwo&) {};
};
Some people prefer to call all methods in the visitor visit and let overload resolution do the rest but I prefer more explicit names.
struct BusinessOne {
void accept(BusinessVisitor& v) const {
v.on_business_one(*this);
}
};
struct BusinessTwo {
void accept(BusinessVisitor& v) const override {
v.on_business_two(*this);
}
};
Now we can add an accept method to Algo as well. This one will simply dispatch to the contained AbstractBusiness object.
class Algo {
std::unique_ptr<AbstractBusiness> b_;
public:
Algo(std::unique_ptr<AbstractBusiness> b);
void accept(BusinessVisitor& visitor) const override {
return b_->accept(visitor);
}
};
To get the result for a specific business type we need to define a visitor that handles this type:
struct BusinessOneResult : public BusinessVisitor {
void on_business_one(const BusinessOne& b) {
// save result;
}
/* ... */ get_result() const;
};
Now we can run Algo and retrieve the result:
auto b = std::unique_ptr<AbstractBusiness>(new BusinessOne());
Algo a(std::move(b));
BusinessOneResult visitor;
a.accept(visitor);
auto result = visitor.get_result();
The real power of this approach unfolds if you don't want extract a specific value from Algo but if you want to trigger an action. In that case the action is usually different depending on the business type, thus the whole action can be specified in the visitor.
A different and quite elegant way would be to use a std::future:
struct Business {
std::future</*...*/> get_future_result() {
return promise_.get_future();
}
void some_method() {
// ...
promise_.set_value(...);
}
private:
std::promise</*...*/> promise_;
};
// Must use Business here (AbstractBusiness doesn't know about the
// type of the future).
auto b = std::unique_ptr<Business>(new Business());
auto future = b.get_future_result();
Algo a(std::move(b));
auto result = future.get();
Another way would be to wrap the type in a class derived from a tag class (no methods or data members) and dynamic_cast it to the type you know it contains. Using dynamic_cast it's usually frowned upon but it has it's uses.
std::any or boost::any would be another way to go.
Note: I dropped the std::move for the argument of the std::unique_ptr constructor, it doesn't do a thing there: The result of the new operation is already an rvalue and moving a pointer is as efficient as copying it.
I've been searching all through the web and I seem to not find any alternate way of doing comparing if two polymorphic objects are the same type, or if a polymorphic object IS a type. The reason for this is because I am going to implement a Entity System inside of my game that I am currently creating.
I have not found another way of doing this other than with the use macros or a cast (the cast not being a portable method of doing so). Currently this is how I am identifying objects, is there a more efficient or effective way of doing this? (without the use of C++ RTTI)
I pasted it on pastebin, since pasting it here is just too much of a hassle.
http://pastebin.com/2uwrb4y2
And just incase you still do not understand exactly what I'm trying to achieve, I'll try to explain it. An entity in a game is like an object inside of the game (e.g. a player or enemy), it have have components attached to it, these components are data for an entity. A system in the entity system is what brings the data and logic of the game together.
For example, if I wanted to display a model up on the screen it would be similar to this:
World world; // Where all entities are contained
// create an entity from the world, and add
// some geometry that is loaded from a file
Entity* e = world.createEntity();
e->add(new GeometryComponent());
e->get<GeometryComponent>()->loadModel("my_model.obj"); // this is what I want to be able to do
world.addSystem(new RenderingSystem());
// game loop
bool isRunning = true;
while(isRunning)
{
pollInput();
// etc...
// update the world
world.update();
}
EDIT:
Here's a framework, programmed in Java, that does mainly what I want to be able to do.
http://gamadu.com/artemis/tutorial.html
See std::is_polymorphic. I believe boost has it too.
If T is a polymorphic class (that is, a class that declares or inherits at least one virtual function), provides the member constant value equal true. For any other type, value is false.
http://en.cppreference.com/w/cpp/types/is_polymorphic
Edit:
Why can't you just do this in your example?
Entity* e = world.createEntity();
GemoetryComponent* gc = new GeometryComponent();
gc->loadModel("my_model.obj");
e->add(gc);
Create the structure before stripping the type information.
If you're determined not to use C++'s built-in RTTI, you can reimplement it yourself by deriving all classes from a base class that contains a virtual method:
class Base {
public:
virtual string getType() = 0;
};
Then every derived class needs to overload this method with a version that returns a distinct string:
class Foo : public Base {
public:
string getType() { return "Foo"; }
};
You can then simply compare the results of calling getType() on each object to determined if they are the same type. You could use an enumeration instead of a string if you know up front all the derived classes that will ever be created.
Entity* e = world.createEntity();
e->add(new GeometryComponent());
e->get<GeometryComponent>()->loadModel("my_model.obj");
// this is what I want to be able to do
First the simple: there is a base type to all of the components that can be added, or else you would not be able to do e->add(new GeometryComponent()). I assume that this particular base has at least one virtual function, in which case the trivial solution is to implement get as:
template <typename T>
T* get() {
return dynamic_cast<T*>(m_component); // or whatever your member is
}
The question says that you don't want to use RTTI, but you fail to provide a reason. The common misundertandings are that RTTI is slow, if that is the case, consider profiling to see if that is your case. In most cases the slowness of dynamic_cast<> is not important, as dynamic_casts should happen rarely on your program. If dynamic_cast<> is a bottleneck, you should refactor so that you don't use it which would be the best solution.
A faster approach, (again, if you have a performance bottleneck here you should redesign, this will make it faster, but the design will still be broken) if you only want to allow to obtain the complete type of the object would be to use a combination of typeid to tests the type for equality and static_cast to perform the downcast:
template <typename T>
T* get() {
if (typeid(*m_component)==typeid(T))
return static_cast<T*>(m_component);
else
return 0;
}
Which is a poor man's version of dynamic_cast. It will be faster but it will only let you cast to the complete type (i.e. the actual type of the object pointed, not any of it's intermediate bases).
If you are willing to sacrifice all correctness (or there is no RTTI: i.e. no virtual functions) you can do the static_cast directly, but if the object is not of that type you will cause undefined behavior.
I need to find the type of object pointed by pointer.
Code is as below.
//pWindow is pointer to either base Window object or derived Window objects like //Window_Derived.
const char* windowName = typeid(*pWindow).name();
if(strcmp(windowName, typeid(Window).name()) == 0)
{
// ...
}
else if(strcmp(windowName, typeid(Window_Derived).name()) == 0)
{
// ...
}
As i can't use switch statement for comparing string, i am forced to use if else chain.
But as the number of window types i have is high, this if else chain is becoming too lengthy.
Can we check the window type using switch or an easier method ?
EDIT: Am working in a logger module. I thought, logger should not call derived class virtual function for logging purpose. It should do on its own. So i dropped virtual function approach.
First of all use a higher level construct for strings like std::string.
Second, if you need to check the type of the window your design is wrong.
Use the Liskov substitution principle to design correctly.
It basically means that any of the derived Window objects can be replaced with it's super class.
This can only happen if both share the same interface and the derived classes don't violate the contract provided by the base class.
If you need some mechanism to apply behavior dynamically use the Visitor Pattern
Here are the things to do in order of preference:
Add a new virtual method to the base class and simply call it. Then put a virtual method of the same name in each derived class that implements the corresponding else if clause inside it. This is the preferred option as your current strategy is a widely recognized symptom of poor design, and this is the suggested remedy.
Use a ::std::map< ::std::string, void (*)(Window *pWindow)>. This will allow you to look up the function to call in a map, which is much faster and easier to add to. This will also require you to split each else if clause into its own function.
Use a ::std::map< ::std::string, int>. This will let you look up an integer for the corresponding string and then you can switch on the integer.
There are other refactoring strategies to use that more closely resemble option 1 here. For example,if you can't add a method to the Window class, you can create an interface class that has the needed method. Then you can make a function that uses dynamic_cast to figure out if the object implements the interface class and call the method in that case, and then handle the few remaining cases with your else if construct.
Create a dictionary (set/hashmap) with the strings as keys and the behaviour as value.
Using behaviour as values can be done in two ways:
Encapsulate each behaviour in it's
own class that inherit from an
interface with"DoAction" method that
execute the behavior
Use function pointers
Update:
I found this article that might be what you're looking for:
http://www.dreamincode.net/forums/topic/38412-the-command-pattern-c/
You might try putting all your typeid(...).name() values in a map, then doing a find() in the map. You could map to an int that can be used in a switch statement, or to a function pointer. Better yet, you might look again at getting a virtual function inside each of the types that does what you need.
What you ask for is possible, it's also unlikely to be a good solution to your problem.
Effectively the if/else if/else chain is ugly, the first solution that comes to mind will therefore to use a construct that will lift this, an associative container comes to mind and the default one is obviously std::unordered_map.
Thinking on the type of this container, you will realize that you need to use the typename as the key and associate it to a functor object...
However there are much more elegant constructs for this. The first of all will be of course the use of a virtual method.
class Base
{
public:
void execute() const { this->executeImpl(); }
private:
virtual void executeImpl() const { /* default impl */ }
};
class Derived: public Base
{
virtual void executeImpl() const { /* another impl */ }
};
It's the OO way of dealing with this type of requirement.
Finally, if you find yourself willing to add many different operations on your hierarchy, I will suggest the use of a well-known design pattern: Visitor. There is a variation called Acyclic Visitor which helps dealing with dependencies.
Is it bad design to check if an object is of a particular type by having some sort of ID data member in it?
class A
{
private:
bool isStub;
public:
A(bool isStubVal):isStub(isStubVal){}
bool isStub(){return isStub;}
};
class A1:public A
{
public:
A1():A(false){}
};
class AStub:public A
{
public:
AStub():A(true){}
};
EDIT 1:
Problem is A holds a lot of virtual functions, which A1 doesn't override but the stub needs to, for indidicating that you are working on a stub instead of an actual object. Here maintainability is the question, for every function that i add to A, i need to override it in stub. forgetting it means dangerous behaviour as A's virtual function gets executed with stub's data. Sure I can add an abstract class ABase and let A and Astub inherit from them. But the design has become rigid enough to allow this refactor.
A reference holder to A is held in another class B. B is initialized with the stub reference, but later depending on some conditions, the reference holder in B is reinitialized with the A1,A2 etc.. So when i do this BObj.GetA(), i can check in GetA() if the refholder is holding a stub and then give an error in that case. Not doing that check means, i would have to override all functions of A in AStub with the appropriate error conditions.
Generally, yes. You're half OO, half procedural.
What are you going to do once you determine the object type? You probably should put that behavior in the object itself (perhaps in a virtual function), and have different derived classes implement that behavior differently. Then you have no reason to check the object type at all.
In your specific example you have a "stub" class. Instead of doing...
if(!stub)
{
dosomething;
}
Just call
object->DoSomething();
and have the implemention in AStub be a empty
Generally yes. Usually you want not to query the object, but to expect it to BEHAVE the proper way. What you suggest is basically a primitive RTTI, and this is generally frowned upon, unless there are better options.
The OO way would be to Stub the functionality, not check for it. However, in the case of a lot of functions to "stub" this may not seem optimal.
Hence, this depends on what you want the class to really do.
Also note, that in this case you don't waste space:
class A
{
public:
virtual bool isStub() = 0;
};
class A1:public A
{
public:
virtual bool isStub() { return false; };
};
class AStub:public A
{
public:
virtual bool isStub() { return true; };
};
... buuut you have a virtual function -- what usually is not a problem, unless it's a performance bottleneck.
If you want to find out the type of object at runtime you can use a dynamic_cast. You must have a pointer or reference to the object, and then check the result of the dynamic_cast. If it is not NULL, then the object is the correct type.
With polymorphic classes you can use the typeofoperator to perform RTTI. Most of the time you shouldn't need to. Without polymorphism, there's no language facility to do so, but you should need to even less often.
One caveat. Obviously your type is going to be determined at construction time. If your determination of 'type' is a dynamic quantity you can't solve this problem with the C++ type system. In that case you need to have some function. But in this case it is better to use the overridable/dynamic behavior as Terry suggested.
Can you provide some better information as what you are trying to accomplish?
This sort of thing is fine. It's generally better to put functionality in the object, so that there's no need to switch on type -- this makes the calling code simpler and localises future changes -- but there's a lot to be said for being able to check the types.
There will always be exceptions to the general case, even with the best will in the world, and being able to quickly check for the odd specific case can make the difference between having something fixed by one change in one place, a quick project-specific hack in the project-specific code, and having to make more invasive, wide-reaching changes (extra functions in the base class at the very least) -- possibly pushing project-specific concerns into shared or framework code.
For a quick solution to the problem, use dynamic_cast. As others have noted, this lets one check that an object is of a given type -- or a type derived from that (an improvement over the straightforward "check IDs" approach). For example:
bool IsStub( const A &a ) {
return bool( dynamic_cast< const AStub * >( &a ) );
}
This requires no setup, and without any effort on one's part the results will be correct. It is also template-friendly in a very straightforward and obvious manner.
Two other approaches may also suit.
If the set of derived types is fixed, or there are a set of derived types that get commonly used, one might have some functions on the base class that will perform the cast. The base class implementations return NULL:
class A {
virtual AStub *AsStub() { return NULL; }
virtual OtherDerivedClass *AsOtherDerivedClass() { return NULL; }
};
Then override as appropriate, for example:
class AStub : public A {
AStub *AsStub() { return this; }
};
Again, this allows one to have objects of a derived type treated as if they were their base type -- or not, if that would be preferable. A further advantage of this is that one need not necessarily return this, but could return a pointer to some other object (a member variable perhaps). This allows a given derived class to provide multiple views of itself, or perhaps change its role at runtime.
This approach is not especially template friendly, though. It would require a bit of work, with the result either being a bit more verbose or using constructs with which not everybody is familiar.
Another approach is to reify the object type. Have an actual object that represents the type, that can be retrieved by both a virtual function and a static function. For simple type checking, this is not much better than dynamic_cast, but the cost is more predictable across a wide range of compilers, and the opportunities for storing useful data (proper class name, reflection information, navigable class hierarchy information, etc.) are much greater.
This requires a bit of infrastructure (a couple of macros, at least) to make it easy to add the virtual functions and maintain the hierarchy data, but it provides good results. Even if this is only used to store class names that are guaranteed to be useful, and to check for types, it'll pay for itself.
With all this in place, checking for a particular type of object might then go something like this example:
bool IsStub( const A &a ) {
return a.GetObjectType().IsDerivedFrom( AStub::GetClassType() );
}
(IsDerivedFrom might be table-driven, or it could simply loop through the hierarchy data. Either of these may or may not be more efficient than dynamic_cast, but the approximate runtime cost is at least predictable.)
As with dynamic_cast, this approach is also obviously amenable to automation with templates.
In the general case it might not be a good design, but in some specific cases it is a reasonable design choice to provide an isStub() method for the use of a specific client that would otherwise need to use RTTI. One such case is lazy loading:
class LoadingProxy : IInterface
{
private:
IInterface m_delegate;
IInterface loadDelegate();
public:
LoadingProxy(IInterface delegate) : m_delegate(delegate){}
int useMe()
{
if (m_delegate.isStub())
{
m_delegate = loadDelegate();
}
return m_delegate.useMe();
}
};
The problem with RTTI is that it is relatively expensive (slow) compared with a virtual method call, so that if your useMe() function is simple/quick, RTTI determines the performance. On one application that I worked on, using RTTI tests to determine if lazy loading was needed was one of the performance bottlenecks identified by profiling.
However, as many other answers have said, the application code should not need to worry about whether it has a stub or a usable instance. The test should be in one place/layer in the application. Unless you might need multiple LoadingProxy implementations there might be a case for making isStub() a friend function.
I'm sorry if my question is so long and technical but I think it's so important other people will be interested about it
I was looking for a way to separate clearly some softwares internals from their representation in c++
I have a generic parameter class (to be later stored in a container) that can contain any kind of value with the the boost::any class
I have a base class (roughly) of this kind (of course there is more stuff)
class Parameter
{
public:
Parameter()
template typename<T> T GetValue() const { return any_cast<T>( _value ); }
template typename<T> void SetValue(const T& value) { _value = value; }
string GetValueAsString() const = 0;
void SetValueFromString(const string& str) const = 0;
private:
boost::any _value;
}
There are two levels of derived classes:
The first level defines the type and the conversion to/from string (for example ParameterInt or ParameterString)
The second level defines the behaviour and the real creators (for example deriving ParameterAnyInt and ParameterLimitedInt from ParameterInt or ParameterFilename from GenericString)
Depending on the real type I would like to add external function or classes that operates depending on the specific parameter type without adding virtual methods to the base class and without doing strange casts
For example I would like to create the proper gui controls depending on parameter types:
Widget* CreateWidget(const Parameter& p)
Of course I cannot understand real Parameter type from this unless I use RTTI or implement it my self (with enum and switch case), but this is not the right OOP design solution, you know.
The classical solution is the Visitor design pattern http://en.wikipedia.org/wiki/Visitor_pattern
The problem with this pattern is that I have to know in advance which derived types will be implemented, so (putting together what is written in wikipedia and my code) we'll have sort of:
struct Visitor
{
virtual void visit(ParameterLimitedInt& wheel) = 0;
virtual void visit(ParameterAnyInt& engine) = 0;
virtual void visit(ParameterFilename& body) = 0;
};
Is there any solution to obtain this behaviour in any other way without need to know in advance all the concrete types and without deriving the original visitor?
Edit: Dr. Pizza's solution seems the closest to what I was thinking, but the problem is still the same and the method is actually relying on dynamic_cast, that I was trying to avoid as a kind of (even if weak) RTTI method
Maybe it is better to think to some solution without even citing the visitor Pattern and clean our mind. The purpose is just having the function such:
Widget* CreateWidget(const Parameter& p)
behave differently for each "concrete" parameter without losing info on its type
For a generic implementation of Vistor, I'd suggest the Loki Visitor, part of the Loki library.
I've used this ("acyclic visitor") to good effect; it makes adding new classes to the hierarchy possible without changing existing ones, to some extent.
If I understand this correctly...
We had a object that could use different hardware options. To facilitate this we used a abstract interface of Device. Device had a bunch of functions that would be fired on certain events. The use would be the same but the various implementations of the Device would either have a fully-fleshed out functions or just return immediately. To make life even easier, the functions were void and threw exceptions on when something went wrong.
For completeness's sake:
it's of course completely possible to write an own implementation of a multimethod pointer table for your objects and calculate the method addresses manually at run time. There's a paper by Stroustrup on the topic of implementing multimethods (albeit in the compiler).
I wouldn't really advise anyone to do this. Getting the implementation to perform well is quite complicated and the syntax for using it will probably be very awkward and error-prone. If everything else fails, this might still be the way to go, though.
I am having trouble understanding your requirements. But Ill state - in my own words as it were - what I understand the situation to be:
You have abstract Parameter class, which is subclassed eventually to some concrete classes (eg: ParameterLimitedInt).
You have a seperate GUI system which will be passed these parameters in a generic fashion, but the catch is that it needs to present the GUI component specific to the concrete type of the parameter class.
The restrictions are that you dont want to do RTTID, and dont want to write code to handle every possible type of concrete parameter.
You are open to using the visitor pattern.
With those being your requirements, here is how I would handle such a situation:
I would implement the visitor pattern where the accept() returns a boolean value. The base Parameter class would implement a virtual accept() function and return false.
Concrete implementations of the Parameter class would then contain accept() functions which will call the visitor's visit(). They would return true.
The visitor class would make use of a templated visit() function so you would only override for the concrete Parameter types you care to support:
class Visitor
{
public:
template< class T > void visit( const T& param ) const
{
assert( false && "this parameter type not specialised in the visitor" );
}
void visit( const ParameterLimitedInt& ) const; // specialised implementations...
}
Thus if accept() returns false, you know the concrete type for the Parameter has not implemented the visitor pattern yet (in case there is additional logic you would prefer to handle on a case by case basis). If the assert() in the visitor pattern triggers, its because its not visiting a Parameter type which you've implemented a specialisation for.
One downside to all of this is that unsupported visits are only caught at runtime.