type_info, vtable

[Risto Lankinen]

Re: type_info, vtable

Hi!

"tom_usenet " <tom_usenet@hot mail.com> wrote in message
news:3f4b45d0.4 41533437@news.e asynet.co.uk...
[color=blue]
> RTTI has neither the word dynamic nor the work static in it - it is
> the runtime bit that is important, and also the "informatio n" bit.[/color]

Would you therefore call the _static_ selection of overloaded
functions...

void Catch( int );
void Catch( void * );

.... a type of RTTI? Why, or why not? If not, what would you
call it instead?
[color=blue]
> I suppose my point is really that RTTI should be reserved for
> type_info and typeid, and that a new term should be invented for
> dynamic_cast and exception handling, such as "Runtime type
> compatibility checking", or RTCC, since neither of them involve
> information about the type, only about the compatibility of types.[/color]

Like it has been explained, the implementation details of
dynamic_cast and exception handling do not necessarily
intersect. Attempting to define a descriptive term for what
does not exist is a futile exercise.

On the other hand, if the new term is to describe the union
(rather than intersection) of the two, then things like virtual
methods where the compiler selects a method at run-time
based on the actual type of a polymorphic reference or
pointer, and even overloaded methods where the compiler
selects a method _seemingly_ at run-time based on the
static type of its argument also fall in the domain of this
new term.

Cheers!

- Risto -

[Ron Natalie]

Re: type_info, vtable


"tom_usenet " <tom_usenet@hot mail.com> wrote in message news:3f4b1e4d.4 31418531@news.e asynet.co.uk...
[color=blue]
> The static type is known at the throw site, just as the static type of
> an object is known at its creation site.
>
> The point is that the static type isn't known at the catch site,
> except through matching of catch blocks, which happens in a similar
> way to resolution to dynamic_casts (via implicit conversions from
> actual type to cast-to type).[/color]

No it does NOT work that way. There's no dynamic typing involved.
It uses the equivelent of calling typeinfo on a non-pointer/non-reference.
It's entirely static.

[Alf P. Steinbach]

Re: type_info, vtable

On Tue, 26 Aug 2003 08:57:04 GMT, tom_usenet@hotm ail.com (tom_usenet) wrote:
[color=blue]
>I still think catch blocks are a type of RTTI (along with
>dynamic_cast , typeid, etc.), since they allow you to get information
>about the type of an exception at runtime.
>
>This is different from saying that
>1. Exception handling requires RTTI
>2. Exception handling requires type_info
>3. Exception handling requires dynamic_cast.
>
>IMHO, all of the above are false.[/color]

I'd just like to clear up a little point. Long after we agreed that
RTTI involves storing some type descriptor in each object, I continued
to meet your arguments with (essentially) the simple assertion that
exception handling does not require RTTI. It didn't occur to me to say
right out that


Exception handling does not require storing a type descriptor in
each object.


since, after all, we'd agreed that that was was RTTI was, and you could
not be _that_ blind, could you?

Now, perhaps, can you see that at least the claim that exception handling
is a _form_ of RTTI is inconsistent with the above definition?

Perhaps even, when you think really Really REALLY hard about it (hold your
pants!), _if_ exception handling is a form of RTTI, then (a) all exception
handling involves RTTI, and so (b) exception handling is not possible to have
without also having RTTI, and so -- from (b) -- (c) exception handling
_requires_ RTTI, in contradiction with your stm that (2) is false?

[tom_usenet]

Re: type_info, vtable

On Tue, 26 Aug 2003 10:07:40 -0400, "Ron Natalie" <ron@sensor.com >
wrote:
[color=blue]
>
>"tom_usenet " <tom_usenet@hot mail.com> wrote in message news:3f4b1e4d.4 31418531@news.e asynet.co.uk...
>[color=green]
>> The static type is known at the throw site, just as the static type of
>> an object is known at its creation site.
>>
>> The point is that the static type isn't known at the catch site,
>> except through matching of catch blocks, which happens in a similar
>> way to resolution to dynamic_casts (via implicit conversions from
>> actual type to cast-to type).[/color]
>
>No it does NOT work that way.[/color]

What way?
[color=blue]
> There's no dynamic typing involved.[/color]

The static type of an exception isn't known at the site at which it is
caught. It depends how you define "static" and "dynamic". If you
define "static type" as a type known by the compiler at compile time
at a particular line of code, then exception types are dynamic except
at the throw site. Normal object types are dynamic except at their
creation site.
[color=blue]
>It uses the equivelent of calling typeinfo on a non-pointer/non-reference.
>It's entirely static.[/color]

Again, what do you mean by static? The static type of an exception is
only known at the throw statement.

The bit that dynamic_cast and catch have in common is the need to
determine whether type A (unknown at the point of the check at compile
time, in one case held in the object, in the other case held in the
stack frame?) is derived from type B (known at the point of the check
at compile time).

Tom

[Ron Natalie]

Re: type_info, vtable


"tom_usenet " <tom_usenet@hot mail.com> wrote in message news:3f4b6ce1.4 51534156@news.e asynet.co.uk...
[color=blue][color=green][color=darkred]
> >> The point is that the static type isn't known at the catch site,
> >> except through matching of catch blocks, which happens in a similar
> >> way to resolution to dynamic_casts (via implicit conversions from
> >> actual type to cast-to type).[/color]
> >
> >No it does NOT work that way.[/color]
>
> What way?[/color]

By looking at the same stuff dynamic_cast (i.e., vtable).

[color=blue]
>[color=green]
> >It uses the equivelent of calling typeinfo on a non-pointer/non-reference.
> >It's entirely static.[/color]
>
> Again, what do you mean by static? The static type of an exception is
> only known at the throw statement.[/color]

By static, I mean that there is no reason that the object needs to be tagged
with some type information so that the object type can be detected when you
only have a pointer or reference to a possible base class..
[color=blue]
> The bit that dynamic_cast and catch have in common is the need to
> determine whether type A (unknown at the point of the check at compile
> time, in one case held in the object, in the other case held in the
> stack frame?) is derived from type B (known at the point of the check
> at compile time).[/color]

Nope. Dynamic cast needs additional help because it has no clue what
the object that the pointer/reference actually is (only that it knows what a
permissable base class is). It needs to inspect the object to determine
what the t ype really is.

Throwing execptions is different. At compile time essentially the throw code
only has to remember the static type (you can't throw polymorphically ) of the
experssion thrown. This is then checked at runtime against the various
catch blocks as it's unwinding the stack. However the value actually thrown
is immaterial, the exception handling code doesn't EVER need to look at it
until it has already found the catch block and needs it to initalize the local
variable there.

[Erik]

Re: type_info, vtable

Exception handling does obviously not require RTTI.

Proof:

class A {};
class B : public A {};

void f() {
throw B();
}

A *g() {
return B;
}

int good() {
try {
f();
}
catch (A &a) {
cout << "Here";
}
}

int bad() {
A *a = g();
B *b = dynamic_cast<B *>(a);
}

good() is valid according to the example in The C++ Programming Language,
3rd ed, section 14.2.
<Quote>
class Matherr {};
class Overflow : public Matherr {};
class Underflow : public Matherr {};
class Zerodivide : public Matherr {};
// ..

This allows us to handle anny Matherr without caring precisely which kind it
is. For example:

void f()
{
try {
// ...
}
catch (Overflow) {
// handle overflow or anything derived from Overflow
}
catch (Matherr) {
// handle any Matherr that is not Overflow
}
}

<End quote>

bad() is invalid according to the same book, section 15.4.1: "A dynamic_cast
requires a pointer
or a reference to a polymorphic type to do a downcast or a crosscast". A ->
B is a downcast,
B is not polymorphic.

However, I have no idea how EH is implemented. Please tell me if you find
out, I'm interested.

/ Erik

[Ron Natalie]

Re: type_info, vtable


"Erik" <no@spam.com> wrote in message news:big6f2$85g $1@news.lth.se. ..
[color=blue]
> However, I have no idea how EH is implemented. Please tell me if you find
> out, I'm interested.
>[/color]
Well in the case of the Sun compiler (which I havehandy). It passes the value
(possibly a pointer to it) and a constant which appears to be the type_info
value for the static type thrown and then calls a function CrunIex_throw.
Presumably this hunts for the catch blocks with a matching type_info on
their argument.

[tom_usenet]

Re: type_info, vtable

On Tue, 26 Aug 2003 12:22:28 -0400, "Ron Natalie" <ron@sensor.com >
wrote:
[color=blue]
>
>"tom_usenet " <tom_usenet@hot mail.com> wrote in message news:3f4b6ce1.4 51534156@news.e asynet.co.uk...
>[color=green][color=darkred]
>> >> The point is that the static type isn't known at the catch site,
>> >> except through matching of catch blocks, which happens in a similar
>> >> way to resolution to dynamic_casts (via implicit conversions from
>> >> actual type to cast-to type).
>> >
>> >No it does NOT work that way.[/color]
>>
>> What way?[/color]
>
>By looking at the same stuff dynamic_cast (i.e., vtable).
>
>[color=green]
>>[color=darkred]
>> >It uses the equivelent of calling typeinfo on a non-pointer/non-reference.
>> >It's entirely static.[/color]
>>
>> Again, what do you mean by static? The static type of an exception is
>> only known at the throw statement.[/color]
>
>By static, I mean that there is no reason that the object needs to be tagged
>with some type information so that the object type can be detected when you
>only have a pointer or reference to a possible base class..[/color]

That isn't the definition of static type:

1.3.11 static type
the type of an expression (3.9), which type results from analysis of
the program without considering execution semantics. The static type
of an expression depends only on the form of the program in which the
expression appears, and does not change while the program is
executing.

In addition, an exception does have to be tagged with some "type
information" to allow matching catch blocks to be chosen. The
exception object itself won't contain this information (it may not
have a vtable), but it is there nevertheless, held globally. Some
implementations choose the obvious implementation of holding the
(statically determined) type_info object for the thrown exception.
Others might just hold the lesser information required to check
compatibility with catch blocks.
[color=blue]
>[color=green]
>> The bit that dynamic_cast and catch have in common is the need to
>> determine whether type A (unknown at the point of the check at compile
>> time, in one case held in the object, in the other case held in the
>> stack frame?) is derived from type B (known at the point of the check
>> at compile time).[/color]
>
>Nope. Dynamic cast needs additional help because it has no clue what
>the object that the pointer/reference actually is (only that it knows what a
>permissable base class is). It needs to inspect the object to determine
>what the t ype really is.[/color]

Yes, that pretty obviously (I thought) what I meant by "in one case
held in the object".
[color=blue]
>Throwing execptions is different. At compile time essentially the throw code
>only has to remember the static type (you can't throw polymorphically ) of the
>experssion thrown. This is then checked at runtime against the various
>catch blocks as it's unwinding the stack. However the value actually thrown
>is immaterial, the exception handling code doesn't EVER need to look at it
>until it has already found the catch block and needs it to initalize the local
>variable there.[/color]

Yes, I don't (and haven't) disagreed with any of that. The dynamic
type and static type of an exception are the same at the throw site
(since whatever the dynamic type of the object thrown, a copy is made
of the static type). At the catch site they can be different of
course.

I think this thread might come to a close quicker if I clarified.

1. dynamic_cast checks to see whether the dynamic type of the passed
object *is a subclass of* the cast-to type.
2. catch blocks check to see whether the thrown exception type *is a
subclass of* the caught type.
3. Both these checks must occur at runtime. The dynamic type of an
object is not generally known at compile time. The type of an
exception caught by a particular catch is not known at compile time.
4. Exceptions don't need to have any information stored inside them
about their dynamic type, since the compiler can store it in a "global
datum" at the throw point. Some compilers store the statically
determined type_info object for the thrown type, but their are many
alternatives, such as storing an index into a throw/catch
compatibility matrix.
5. Objects (with virtual functions) do need to have information stored
along with them in order to implement dynamic_cast. This is because
their are many objects in existence at once, so you can't store a
single "global datum" to tell you the type as you can with exceptions
(of which there is only one at a time). Most compilers store a pointer
to the type_info for an object in the type's vtable, but alternative
implementations , such as storing an index into an object creation/cast
target compatibility matrix directly in the object, are possible.
6. Some descriptive definitions of RTTI exclude dynamic_cast. Others
include exception handling.

The points of others that I have disagreed with:

1. Exception handling doesn't require a runtime check for
compatibility of types.
2. The compatibility check required for exception handling is
substantially different to the check required by dynamic_cast. I have
stated the differences (need to store information associated with each
object for dynamic_cast), but this seemed to be disagreed with.
3. Various definitions of RTTI. There is no formal definition that
I've been able to find. Possibilities include prescriptive ones
(dynamic_cast, typeid, the contents of <typeinfo> (and catch block
matching according to some)), descriptive ones (constructs requiring
checking or identification of types at runtime, constructs requiring
information to be stored in each object relating to its type). I have
pointed out the inadequacy of some vague descriptive definitions,
since they either include catch block matching or exclude dynamic_cast
from RTTI, which I assume wasn't the intent (since the poster in
question was insisting that exception handling has nothing to do with
RTTI, yet dynamic_cast is RTTI). Other definitions talk in terms of
implementation (constructs requiring information to be stored in each
object relating to its type), and therefore seem to me to be poor
definitions.
4. Comments that "is a type of" is the same as "requires".

Tom

[Ivan Vecerina]

Re: type_info, vtable

"tom_usenet " <tom_usenet@hot mail.com> wrote in message
news:3f4c6e85.5 17491171@news.e asynet.co.uk...
[ a nice summary ]

Amen!

Ivan
--

http://www.post1.com/~ivec

[Ron Natalie]

Re: type_info, vtable


"tom_usenet " <tom_usenet@hot mail.com> wrote in message news:3f4c6e85.5 17491171@news.e asynet.co.uk...
[color=blue]
> In addition, an exception does have to be tagged with some "type
> information" to allow matching catch blocks to be chosen. The
> exception object itself won't contain this information (it may not
> have a vtable),[/color]

Even if it had a vtable, it wouldn't be useful. It's the static type of
the object thrown that matters not it's dynamic type.
[color=blue]
> but it is there nevertheless, held globally.[/color]

I don't know what you mean by "held globally" but I suspect you're wrong.
The type info is typically a static value that's passed along with the value
of the expression in some generic form to the runtime exception handler.
[color=blue]
> Yes, I don't (and haven't) disagreed with any of that. The dynamic
> type and static type of an exception are the same at the throw site[/color]
[color=blue]
> I think this thread might come to a close quicker if I clarified.
>
> 1. dynamic_cast checks to see whether the dynamic type of the passed
> object *is a subclass of* the cast-to type.[/color]

By examining the value.
[color=blue]
> 2. catch blocks check to see whether the thrown exception type *is a
> subclass of* the caught type.[/color]

Because it must be told the type thrown. Looking at the value of the
expression will not provide the correct answer (nor will it work for non
class types anyhow).
[color=blue]
> 3. Both these checks must occur at runtime. The dynamic type of an
> object is not generally known at compile time.[/color]

The compiler cares not one whit about the runtime dynamic type of
the object. Consider it to be one gigantic static switch statement. Only
the static types matter.
[color=blue]
> The type of an
> exception caught by a particular catch is not known at compile time.[/color]

It will always be the type of the catch or something implicitly convertable
to it. The dynamic type is NOT used to match arguments to catch blocks.
[color=blue]
> 4. Exceptions don't need to have any information stored inside them
> about their dynamic type, since the compiler can store it in a "global
> datum" at the throw point.[/color]

They NEED the global datum as you call it because the dynamic type
has no meaning to catch. Catch doesn't match on dynamic type. It
catches based on the static type thrown (this compiled into the code
at compile time). It is never necessary for the compiler to examine the
argument passed at runtime to find the catch block.
[color=blue]
> 5. Objects (with virtual functions) do need to have information stored
> along with them in order to implement dynamic_cast. This is because
> their are many objects in existence at once, so you can't store a
> single "global datum" to tell you the type as you can with exceptions[/color]

It matters because they actually can be different types at run time.
Thrown objects are always known at compile time.
[color=blue]
> 1. Exception handling doesn't require a runtime check for
> compatibility of types.[/color]

It doesn't require a runtime examination of the thrown value.
It runtime checks the static type thrown against possible blocks.
[color=blue]
> 2. The compatibility check required for exception handling is
> substantially different to the check required by dynamic_cast.[/color]

It's nothing like it. I think you are finally seeing the like. Exception
handling and dynamic_cast have nothing at all to do with each other.