One Variable --> Different Data Types

[troloo]

Hello, I hope you can help me :)) The story goes as follows:
I have a class with different methods and member variables. I store
pointers to objects of this class inside a vector. Now, I would like to
have a variable 'window' which could contain pointers to different
objects (like 'class t1', 'class t2', etc.).

I tried to use templates to create variable 'T* window' but I had some
troubles later storing pointer to such a template-enabled class inside
my vector :(.

Do you think that I could store 'void *' pointers and then just use
'reinterpret_cast<type-id>(pointer)' to return to my 'class t1', 'class
t2', etc. types? Would it be safe?
I hope it's moreless clear what I want to do :))

Greetings,

TroLoo

[Victor Bazarov]

tr****@gmail.com wrote:

Hello, I hope you can help me :)) The story goes as follows:
I have a class with different methods and member variables. I store
pointers to objects of this class inside a vector. Now, I would like to
have a variable 'window' which could contain pointers to different
objects (like 'class t1', 'class t2', etc.).

I tried to use templates to create variable 'T* window' but I had some
troubles later storing pointer to such a template-enabled class inside
my vector :(.

Do you think that I could store 'void *' pointers and then just use
'reinterpret_cast<type-id>(pointer)' to return to my 'class t1', 'class
t2', etc. types? Would it be safe?
I hope it's moreless clear what I want to do :))

It's moreless clear that you've not designed it verywell. Why do you
think you need to keep those pointers to [unrelated?] types in that
object [window]? If they are later to be worked on by that object,
then perhaps they should have a common base class and be polymorphic
(just like many OO things are). If that object ('window') only works
as temporary storage for them and somebody else is going to work on
those objects, you could, of course use void*. But that, again, is
a definite violation of the idea of design. Why does the "window"
store the pointers? Is there an association between the "window" and
the object? If there is, it probably can be expressed in terms of
some interface, and you get your base class. If there is no known
association, why is the a "window" used to keep that pointer? Maybe
you should keep that pointer elsewhere, with somebody who knows how to
use that pointer?...

Of course, all those things cannot be simply answered in terms of C++.
If you just need a plain answer, then here it is: use void* and
reinterpret_cast it back to the object when you need to dereference it.

V

[troloo]

Well, I have to say that I thought about polymorphism. Maybe I will
explain exactly why do I need such a variable. I'm working on a program
which is a MFC Application. I didn't choose this technique and didn't
have any opportunity to influence this choice.

Now, I have this nice window which is containing several Dialogs. So I
created a class which contains the pointer to a Dialog. I store all
those classes in a vector. Sometimes I need to reposition or do
anything with, for instance, 'dialog no 3' and I need a handle to this
dialog. I call 'my_vector[3]->window' and I have Dialog handle which is
moreless exactly the same as the rest of Dialog handles (differences
are non-relevant to me) but it represents different data type.

I'm sorry for this mess but english is not my mother language. It's
hard for me to write clearly what's my problem :(( I hope you can
understand that.

Greetings,

TroLoo

[Victor Bazarov]

tr****@gmail.com wrote:

Well, I have to say that I thought about polymorphism.
And what result did you arrive at?
Maybe I will
explain exactly why do I need such a variable. I'm working on a program
which is a MFC Application. I didn't choose this technique and didn't
have any opportunity to influence this choice.

Now, I have this nice window which is containing several Dialogs. So I
created a class which contains the pointer to a Dialog. I store all
those classes in a vector. Sometimes I need to reposition or do
anything with, for instance, 'dialog no 3' and I need a handle to this
dialog. I call 'my_vector[3]->window' and I have Dialog handle which is
moreless exactly the same as the rest of Dialog handles (differences
are non-relevant to me) but it represents different data type.

Why do you say that it represents a different data type? It's a handle
to some OS-specific structure. How do you use it? You send a message
to that window using OS-specific method, no?

In MFC and many other UI frameworks, dialogs are windows, and classes that
define (describe, represent) dialogs usually derive from a common base
class that defines (describes, represents) a window. That way, if you
need to do something window-specific, you just tell the object to do that
using a member of the window class. Like reposition, show/hide, resize,
refresh, et cetera.

So, you have a main window that does something to those dialogs. What
does it do to them? Is it the same operation for all of them? Is it
different for each of them? If it's the same set of operations, collect
those operations in a class and make that class common base class for
all your 'dialog' classes. If it's different for each 'dialog' type,
what business do they have being in the same window? See my point?

An example of a common base class in MFC is CToolBar. You can either
instantiate it (it's a concrete class) or you could derive from it and
make your own, customized "toolbar". Then you can have both "native"
toolbars and your new, customized, one in the same main frame window.
All the operations you can perform on a regular toolbar is OK for your
custom one too because it "is-a" CToolBar, it derives from one.

I don't want to continue this discussion here because it's not really
relevant to C++. It's all essentially about knowing your library (MFC
in your example) well and designing your classes correctly using that
framework. You definitely need more time on that.

First of all, figure out what is common between those "different" data
types. Perhaps not that little. If they have a common class, store
a pointer to that. Use those pointers because that's the only way you
will get to the common functionality of those classes. If you can't
_find_ anything in common between them, you probably didn't put it in,
since there _must_ be something in common. So, revisit the hierarchy
of classes you have, and _give_ all those "different data types" the
common base class that will contain the functionality they all need to
implement.

V

[troloo]

Ok, I found a solution thanks to your advices. I keep pointers to base
classes and it is enough for me.
Thank you very much for you time!!!

--
Greetings,

TroLoo