dynamic_cast

maybe you didn't do the casting right

the idea is that you can make casting from father to son or father pointer to son pointer

the idea is that if you got a based1 class and a drived1 class

then you can
do
based1 *p1;
drived1 *p2;
.....
p1=dynamic_cast<based1*>p2;

that way you can make containers
that are an array of pointers to the father that you can cast to pointers to one of the sons

and if you can't make the cast the dynamic_cast will return NULL

to nietod
you trying to say that it won't work without a virtual function in the calss??

>> that it won't work without a virtual function in the calss??
It MIGHT not work if it doesn't have any virtual functions.   That is, the C++ standard says that the compiler doesn't have to make dynamic cast work on objects that don't have virtual functions.  However, if the class contains virtual functions (perhaps defined in a base class) then the compiler must make the dynamic cast work.

here i won't agree with you when you enable RTTI the typeid and dynamic_cast should work

I don't see where you disagree actually.
Borland will by default not add RTTI to POD like types, like nietod says, unless you tell it to do so anyway. But that basically changes the 'It MIGHT not work' into 'it will always work' by changing the compiler.

From the answers, I understand that dynamic_cast will work only when virtual functions are invloved. I wanted to know why wont they work when no virtual functions are present.

>> I wanted to know why wont they work
>> when no virtual functions are present.

For a dynamic cast to work, the computer needs some way of actually determining what type of object has been supplied to the dynamic cast.  In general, this is impossible to tell.  the dynamic cast just has a pointer to some location in memory, how can it tell what object is stored in tha location?  

One way that compilers can make it work is that they can place information  at the start of an object that helps it identify the object's type.  In that case the pointer suplied to dynamic cast will point to information that helps identify the object's type and allows the dynamic cast to function correctly.

However, the compiler is not always allowed to add to an object like that.  For example, the C++ standard specifically states that if an object has no virtual functions and no base classes, then a pointer to the object is also a pointer to the furst data member in the object.  (This is to help insure compatiblity with C structures).  So the compiler can't place this extra identification data in an object that has no virtual functons.   (Although apparently BCB does this if you elect it???)

Makes sense now?

Not sure this has been said. RTTI has to be stored somewhere, what better place then together with info on virtual functions (the VTable). You could seperate them off course, but that would not add more overhead and you may still have a problem where the langauge demands that the object layout is compatible with C structures.

Yes, usually the virtual table pointer points to the start of an array of function pointers and imediately before that table is the typeinfo structure.  Usually.

dynamic_cast requires runtime type identification (rtti)

rtti requires the type information be stored for each object.  This usually (read always) requires storing the information somewhere in the object

rtti is usually (read always) stored in the vtable (ie. it is a predefined virtual 'function').

turning on rtti simply always adds the rtti info to the vtable (if any) of object.

if there are no virtual functions already, then there is no vtable and C++ will not add one, so there is no dynamic runtime type information.

that means only the static type is available.


for the example you give, dynamic cast is not appropriate anyway because there are no classes involved.

what you want here is a static_cast (or a function-style cast is good ie:)

double dDividend = double(exDays*2);

sorry for my last comment you're right nietod

No applogy needed.

You don't KNOW that they won't work, however you are GUARANTEED that they will work.

------------------------------------

Brilliant!!   Just simply brilliant!!


On the surface it may look contradictory, but upon closer examination, it is actually repetitive (not to mention, FALSE).

------------------------------------

To say something is FALSE, is saying, it is NOT TRUE.

Therefore, to say something is NOT(NOT TRUE), is saying, it is TRUE.

(Sort of like,  -(-x) = +x  or simply  x)

Therefore, to say, 'You don't know(they won't work)' is like saying, 'You know they will work'.

Therefore, if you know they will work, there is no need to repeat "however you are GUARANTEED that they will work."

The entire statement then reads, "You know they will work, however you are GUARANTEED that they will work."

But since the beginning of the statement asserts that, "You know they will work," there is no included statement of condition under which you know (for sure) this will occur.

It doesn't say, "This will occur, if and only if, ... (the condition)"

Without a condition to validate the statement's truthfulness, the statement is automatically FALSE.

Try -- i think it was a typo. It thnk he was trying to say "you are not GUARANTEED that they will work".

Yes, it was definitely a typo!!  I just missed the "not" which is a mere three letters and a world of difference.

All this stuff about trues and false is interesting.  But I've never seen anything like it before.  Do you think it could be useful to me as a programmer?

not :-)