+2  A: 

First thing that comes to mind is asking what you really want to achieve... but then again the second thought is that you can use the visitor pattern. Runtime type information will implicitly be used to determine at what point in the hierarchy is the final overrider of the accept method, but you will not explicitly use that information (your code will not show any dynamic_cast, type_info, constants...)

Then again, my first thought comes back... since you are asking about the appropriateness of the architecture, what is it that you really want to achieve? --without knowledge of the problem you will only find generic answers as this one.

David Rodríguez - dribeas
I'm trying to describe. Imaging and rpg game and a lot of stuff in it. Each simple kind of stuff has a type, for example weapon, armor, garbage, light, potion, scroll, book, etc. Each type implemented as mix-in class. But many items in a game can have more than one type, for example, it can be a large axe that has a light and a hidden places for small items (weapon, light, container). Skin bag that can be weared on a belt, it can have a 1 armor point and behave like an armor and like a container. In different places of app I want to operate with composite objects like with simple ones.
KneLL
A: 

The usual object oriented way would be to have (pure) virtual functions in the base class that are called in operate() and that get overridden in the derived classes to execute code specific to that derived class.

sth
If I do as you propose than I have all functions prototypes of each mixin class in my base. For now it's about 55 functions in 20 classes. I don't want to have so big Facade in my base class. And I think that base class must not know about children.
KneLL
A: 

Your problem is that you want to decide what to do based on more than one object's type. Virtual functions do this for one object (the one left of the . or ->) only. Doing so for more than one object is called multiple dispatch (for two objects it's also called double dispatch), and in C++ there's no built-in feature to deal with this.

Look at double dispatch, especially as done in the visitor pattern.

sbi
+1  A: 

The real problem here is about what you are trying to achieve.

Do you want something like:

void operate(A-B& ) { operateA(); operateB(); }

// OR

void operate(A-B& ) { operateAB(); }

That is, do you want to apply an operation on each subcomponent (independently), or do you wish to be able to apply operations depending on the combination of components (much harder).

I'll take the first approach here.

1. Virtual ?

class Base { public: virtual void operate() = 0; };

class A: virtual public Base { public virtual void operate() = 0; };
void A::operate() { ++size; } // yes, it's possible to define a pure virtual

class obj1_t: public A, public B
{
public:
  virtual void operate() { A::operate(); B::operate(); }
};

Some more work, for sure. Notably I don't like the repetition much. But that's one call to the _vtable, so it should be one of the fastest solution!

2. Composite Pattern

That would probably be the more natural thing here.

Note that you can perfectly use a template version of the pattern in C++!

template <class T1, class T2, class T3>
class BaseT: public Base, private T1, private T2, private T3
{
public:
  void operate() { T1::operate(); T2::operate(); T3::operate(); }
};

class obj1_t: public BaseT<A,B,C> {};

Advantages:

  • no more need to repeat yourself! write operate once and for all (baring variadic...)
  • only 1 virtual call, no more virtual inheritance, so even more efficient that before
  • A, B and C can be of arbitrary type, they should not inherit from Base at all
  • edit the operate method of A, B and C may be inlined now that it's not virtual

Disadvantage:

Some more work on the framework if you don't have access to variadic templates yet, but it's feasible within a couple dozen of lines.

Matthieu M.
+1, and you can take a look at boost::preprocessor to avoid writing much of the boilerplate if you do not have a variadic template implementation.
David Rodríguez - dribeas
I was going to write it down, but then GMan will pop around and qualify me of preprocessor madman :p
Matthieu M.
Thanks for response, but I wrote that mix-in classes have not any common interface. And I know about Composite but cannot use it because final type can derive from any number of mixin classes. I just want to have a way to use a composite object as a simple.struct TransA{ void operator()(A *pa) { pa->size -= 10; }};void Update(B *pb, Point2 p) { // ... }void Cap(D *pd) { // ... }void f(vector<Base *> o){for_each(o.begin(), o.end(), TransA());Cap(*o.begin());};I can use Visitor pattern, but for now I have more than 20 classes and number of functions is too big.
KneLL
Then you're screwed. They **need** to have a common interface (at the very least an `accept` method for the `Visitor` pattern). As for the remark on `Composite`: you did not understand it >> `Composite` means that the class can indeed be composed of any number of mixins.
Matthieu M.
I thought about Visitor and I decided that it's a good solution. So I'm going to try this pattern and rewrite my code. This will demand a many functions for each class and this fact confusing me, I will need a function per operation in each mixin class, it's too big overhead.
KneLL