I don't get it

[Jo]

class A {

public:

char text_a[100];

A() { *text_a=0; }
~A() {}
};
//-----------------------------------------------------------------------------
class B {

public:

char text_b[100];

B() { *text_b=0; }
~B() {}
};
//-----------------------------------------------------------------------------
class C : public A, public B {

public:

char text_c[100];

C() { *text_c=0; }
~C() {}
};
//-------------------------------------------------------------------------------
void test() {

B *bp1,*bp2;
C c,*cp1,*cp2,*cp 3;
void *p;

strcpy(c.text_a ,"hello a");
strcpy(c.text_b ,"hello b");
strcpy(c.text_c ,"hello c");
cp1=&c;
p=cp1;
bp1=cp1; // ok
bp2=(B*)p; // resulting bp2 is WRONG!
cp2=(C*)p; // ok
cp3=(C*)bp2; // resulting cp3 is WRONG! Which is logical because bp2
is already wrong.
}
//-----------------------------------------------------------------------------

So the hot spot is the bp2=(B*)p;

What's wrong with that???

I can imagine someone saying "p is not pointing to a B object".
But if you think about it, conceptually, it does, imho.

So is it more a technical matter of compiling this!?

Maybe i'm stupid and/or missing something essential about C++.

If so, please give me a link to where i can study this right.

Cheers,

Jo

[Jo]

James Kanze wrote:

>On Jun 18, 10:17 pm, Jo <j...@mutools.c omwrote:

>>John Harrison wrote:

[...]

>>>dynamic_ca st does do base to derived conversion, that's it's main use.
Where are you getting your information?

>>I got that fromhttp://www.cplusplus.c om/doc/tutorial/typecasting.htm l

>>But i was just reading another webpage where they indeed use
base-to-derived dynamic casts...

>>Did i misunderstand the cplusplus page?

You didn't read the sentence completely. It says: "The second
conversion in this piece of code would produce a compilation
error since base-to-derived conversions are not allowed with
dynamic_cast UNLESS the base class is polymorphic." Note that
final clause, with the unless. In their example, the base class
didn't have any virtual functions, so using dynamic_cast to the
derived would be a compiler error.

I understand.

>Generally speaking, you should avoid using void* as much as
possible, and use dynamic_cast exclusively for moving between
classes in a hierarchy. When you can't avoid void*, e.g.
because of legacy or C interfaces, always cast back to exactly
the type of pointer you originally had, then go from there.
Note that often, this means casting to a specific type before
casting to void*. For example (using pthread_create as an
example, but it could be any C API function that takes a pointer
to function and a void*):

class Thread
{
public:
virtual ~Thread() {}
virtual void* run() = 0 ;
} ;

extern "C"
void*
threadStarter( void* p )
{
Thread* t = static_cast< Thread* >( p ) ;
return t->run() ;
}

void
f()
{
// MyThread derives from Thread...
pthread_t t ;
pthread_create( &t, NULL, &threadStart er, new MyThread ) ;
}

As written, this is undefined behavior. The last code line must
be:

pthread_create(
&t, NULL, &threadStart er, static_cast< Thread* >( new
MyThread ) ) ;

(The problem is, that as it is undefined behavior, it might seem
to work some of the time anyway. On most implementations , for
example, it will seem to work as long as only single inheritance
is involved.)

Indeed, and that's why i was so confused, because i've been using this
many times. (too many it seems now!)

I guess that, by coincidence, i never ran into the combination of using
a void* and multiple inherited objects, and so that's why i only
encountered the errors now.

I'm happy that this has been sorted out, and i completely understand the
reasons beyond it.

All sounds logical.

I'll avoid using void* as much as possible!

And i should use more static_cast / dynamic_cast instead of the old
c-style casts, because they're more error-conscious.
(a pity of that quircky syntax though)

[Andre Kostur]

Jo <[e-mail] wrote in
news:fY******** *************@p hobos.telenet-ops.be:

Andre Kostur wrote:

>>Jo <[e-mail] wrote in
news:6G****** *************** @phobos.telenet-ops.be:

[snip]

>>However, a necessity to using dynamic_cast<te nds to indicate a
potential flaw in your design. You should really be asking yourself
why you need to know the derived type. Couldn't it be better
implemented as a virtual function in the base class? So if the
function you're attempting to call in C is already virtual in A, then
you don't need explicitly know that you're working with a C object.
Just call the function through the A* and let the compiler follow the
virtual dispatch to call the real function.

Thought 1: If every very base class should foresee all virtual
functions that are coming down the hierarchic tree (or do they say
"up" the tree? still confused), then these base classes get much too
much cluttered with non-relevant virtual funcs!

Like most trees in computing, they're usually thought of as growing
downwards. So the most base class is usually written at the top, then
the next derived class below it, etc. Thus the terms "upcasting" and
"downcastin g" through an inheritance hierarchy. Upcasting is free,
downcasting requires a cast.

Note that I said "tends to indicate a potential flaw". There are cases
where it may make sense. I'm not sure I can explain how you'd know when
to use it.

Perhaps you really wanted composition where you're using inheritance?

Thought 2: If class C is derived from class A and B, both having
virtual funcs, and i have an A pointer to a C object, and need to call
a B func of the C object, then do you propose to copy all the virtuals
of B in A? I'm confident the answer is no.

No, but whatever function that's going to use the B functionality should
take a B* (or B&). Or perhaps the A class should really have a B as a
member, not as a parent. If you really need to access it through an A*,
perhaps the design is flawed.

So these are two common situations where i need to know what kind of
object i'm dealing with.

In fact, the two thoughts can be summarized to this common reason to
use RTTI: to avoid "virtual clutter".

My conclusion: If you think about it pure conceptually, i don't see
what's wrong with using RTTI.Using virtuals to avoid RTTI is one good
strategy. Using RTTI to avoid virtuals is another good strategy. It
are two equivalent techniques, imo, one better in situation a, the
other better in situation b.

You're blurring the idea of Object Oriented programming (not to say that
you must use OO, C++ supports multiparadigm programming...) . The idea
behind inheritance and virtual functions is that it should be eliminating
the need to know exactly which derived class you're dealing with.