Upwards-casting question

[Leon Mergen]

Hello,

Ok, I'm having a problem when trying to make the classes I make a bit
more generic. Consider this:

I have one class, ClassA. This defines some interface methods, and
ClassB inherits from it, and adds some of its own variables. Now, I'm
making a library, which accepts ClassA.

Now the problem is, this library also creates a lot of threads. I want
each of these threads to contain their own instance of ClassA ( so
indirectly, ClassB ). But since there's no way for each of these threads
to know the size of ClassB, it seems impossible to me to let each of
those classes each have a unique instance of ClassB. Ofcourse, I could
use pointers to solve this problem, but this will only work if I create
a new pointer of ClassB for each of those threads /before/ calling the
library that creates those threads. But this isn't really a solution,
since the number of threads should not be known by the calling class.

Any idea at all how I can solve this problem using a somewhat elegant
solution ?

Thanks in advance for any responses!

Regards,

Leon Mergen
http://www.solatis.com/

[Victor Bazarov]

Leon Mergen wrote:

Ok, I'm having a problem when trying to make the classes I make a bit
more generic. Consider this:

I have one class, ClassA. This defines some interface methods, and
ClassB inherits from it, and adds some of its own variables. Now, I'm
making a library, which accepts ClassA.
What does it means "accepts ClassA"? Functions that have 'ClassA' as
arguments? Passed by _value_? If so, your effort to create 'ClassB' is
wasted. If you pass by value, the portion that is 'ClassB' is removed,
and only 'ClassA' remains.
Now the problem is, this library also creates a lot of threads. I want
each of these threads to contain their own instance of ClassA ( so
indirectly, ClassB ).
No, if it "contains" an _instance_ of 'ClassA', it will certainly *not*
contain 'ClassB' directly or indirectly. Read about *slicing*.
But since there's no way for each of these threads
to know the size of ClassB,
Why do you say that it's impossible? You can tell them, can't you?
it seems impossible to me to let each of
those classes each have a unique instance of ClassB.
That's ridiculous. You just said that _you_ are making that library. You
are free to do as you please, so you can tell that library to use 'ClassB'
instead of 'ClassA', can't you?
Ofcourse, I could
use pointers to solve this problem, but this will only work if I create
a new pointer of ClassB
No, not "create a new pointer", create an object, an instance of 'ClassB'.
for each of those threads /before/ calling the
library that creates those threads.
No, you don't have to do it _before_. You can supply a function that each
thread would call to create a new instance of 'ClassB'.
But this isn't really a solution,
since the number of threads should not be known by the calling class.

Any idea at all how I can solve this problem using a somewhat elegant
solution ?

Use a factory. Let your library (threads) know what function to call to
get another object of type [what they know as] 'ClassA'. Inside that
factory function create an object of type 'ClassB' and return a pointer to
'ClassA'.

V

[Leon Mergen]

On Wed, 2005-09-07 at 13:29 -0400, Victor Bazarov wrote:

Ok, I'm having a problem when trying to make the classes I make a bit
more generic. Consider this:

I have one class, ClassA. This defines some interface methods, and
ClassB inherits from it, and adds some of its own variables. Now, I'm
making a library, which accepts ClassA.

What does it means "accepts ClassA"? Functions that have 'ClassA' as
arguments? Passed by _value_? If so, your effort to create 'ClassB' is
wasted. If you pass by value, the portion that is 'ClassB' is removed,
and only 'ClassA' remains.

Yes, I understood that - and as I also understand it, the only way for a
ClassA to 'save' the additional contents it had from ClassB, is to pass
it as a pointer or reference. And yes, I mean functions that accept
ClassA as arguments.

Now the problem is, this library also creates a lot of threads. I want
each of these threads to contain their own instance of ClassA ( so
indirectly, ClassB ).

No, if it "contains" an _instance_ of 'ClassA', it will certainly *not*
contain 'ClassB' directly or indirectly. Read about *slicing*.

I know about slicing, that's why I'm asking this question.

But since there's no way for each of these threads
to know the size of ClassB,

Why do you say that it's impossible? You can tell them, can't you?

D'oh. That's true.

it seems impossible to me to let each of
those classes each have a unique instance of ClassB.

That's ridiculous. You just said that _you_ are making that library. You
are free to do as you please, so you can tell that library to use 'ClassB'
instead of 'ClassA', can't you?

Yes, but this is a shared library shared between client code and server
code - and heck, I even might want to re-use this library in the future.
That's why I'm doing the generic approach, as I said in the begin of my
message.

Ofcourse, I could
use pointers to solve this problem, but this will only work if I create
a new pointer of ClassB

No, not "create a new pointer", create an object, an instance of 'ClassB'.

Ok, rephrase to "Create a new instance of ClassB, and let the pointer to
that instance of ClassB be casted to a pointer of ClassA".

for each of those threads /before/ calling the
library that creates those threads.

No, you don't have to do it _before_. You can supply a function that each
thread would call to create a new instance of 'ClassB'.

Hmmmm, ok, sounds interesting....

But this isn't really a solution,
since the number of threads should not be known by the calling class.

Any idea at all how I can solve this problem using a somewhat elegant
solution ?

Use a factory. Let your library (threads) know what function to call to
get another object of type [what they know as] 'ClassA'. Inside that
factory function create an object of type 'ClassB' and return a pointer to
'ClassA'.

Ahhh, yes, that sounds like a good solution! Thanks, I'll look into the
factories...

Regards,

Leon Mergen