type_info, vtable

[Rolf Magnus]

Re: type_info, vtable

Ivan Vecerina wrote:
[color=blue]
> | RTTI isn't need for exception handling, neither would it be
> | sufficient.
>
> I did not claim it was sufficient.
>
> But RTTI is needed to match catch handlers with exceptions.
> Consider:
>
> #include <vector>
> #include <string>
> #include <iostream>
> #include <exception>
> int main()
> {
> try {
> std::vector<std ::string> tooBig(1UL<<31, "just some string");
> }
> catch(std::exce ption& x) {
> std::cerr << "Failure: "<<x.what()<<st d::endl;
> }
> }
>
> How would the C++ run-time handle a failure of this memory allocation
> without RTTI?[/color]

I don't know. Maybe you should ask the gcc developers, since you can
disable RTTI and still use exceptions in g++.

[tom_usenet]

Re: type_info, vtable

On Thu, 21 Aug 2003 10:44:37 GMT, alfps@start.no (Alf P. Steinbach)
wrote:
[color=blue]
>On Thu, 21 Aug 2003 09:34:53 GMT, tom_usenet@hotm ail.com (tom_usenet) wrote:
>[color=green]
>>On Wed, 20 Aug 2003 18:10:34 GMT, alfps@start.no (Alf P. Steinbach)
>>wrote:
>>[color=darkred]
>>>> is relevant, and as mentioned the
>>>>>compatibil ity matrix can be optimized and implemented in umpteen ways.
>>>>
>>>>This is true for dynamic cast too - you only need to check the
>>>>compatibili ty of the source and destination types.
>>>
>>>That disregards when (compile time, run time) the check wrt. type
>>>needs to be done, which is the question debated.[/color]
>>
>>Exception checks cannot in general be made at compile time - this
>>seems to be the error you are making.
>>
>>e.g.
>>
>>struct A
>>{
>> virtual ~A(){}
>>};
>>
>>struct B: A{};
>>
>>void throwA()
>>{
>> throw A();
>>}
>>
>>void throwB()
>>{
>> throw B();
>>}
>>
>>#include <iostream>
>>
>>int main()
>>{
>> int i;
>> std::cin >> i;
>> void (*fptr)() = i > 0? throwA: throwB;
>> try
>> {
>> fptr();
>> }
>> catch(B const&)
>> {
>> std::cout << "B\n";
>> }
>> catch(A const&)
>> {
>> std::cout << "A\n";
>> }
>>}
>>
>>How do you suggest that the check be made at compile time in general,
>>with whole program analysis or otherwise?[/color]
>
>It seems your thinking is _very_ confused here. Am I right in assuming
>that the term 'check', as used above, includes stack unwinding?
>
>Stack unwinding cannot be done at compile time; there is no stack at
>that time.[/color]

I assumed you misunderstood this. Your posts seemed to imply that you
thought that the catch associated with each throw could be resolved at
compile time, given whole program analysis.
[color=blue]
>
>Stack unwinding has nothing to do with RTTI.[/color]

No, of course not.

Now, I think I have the source of our misunderstandin g. You seem to
think that the fact that the compiler knows the type of an object at
the throw site is somehow different from the compiler knowing the type
when it calls a constructor to create an object.

The only difference is that for exceptions, you only have one active
exception at a time (well, per thread), whereas you can have any
number of active objects at a time. The nature of the checking
required to match that global exception type against a catch block
though is identical to the checking required in a dynamic cast.

So, it seems that all you are saying is that you don't need to embed
type information in your exception objects, and I don't think anyone
has disagreed with this.

Tom

[Alf P. Steinbach]

Re: type_info, vtable

On Thu, 21 Aug 2003 14:06:47 GMT, tom_usenet@hotm ail.com (tom_usenet) wrote:[color=blue]
>[color=green]
>>Stack unwinding cannot be done at compile time; there is no stack at
>>that time.[/color]
>
>I assumed you misunderstood this. Your posts seemed to imply that you
>thought that the catch associated with each throw could be resolved at
>compile time, given whole program analysis.
>[color=green]
>>
>>Stack unwinding has nothing to do with RTTI.[/color]
>
>No, of course not.
>
>Now, I think I have the source of our misunderstandin g. You seem to
>think that the fact that the compiler knows the type of an object at
>the throw site is somehow different from the compiler knowing the type
>when it calls a constructor to create an object.[/color]

Could you translate that to English?

I fail to see any difference between statically knowing the type of
an object and statically knowing the type of an object.

Furthermore, I fail to see any connection to the question of whether
RTTI is necessary for exception handling.



[color=blue]
>The only difference is that for exceptions, you only have one active
>exception at a time (well, per thread), whereas you can have any
>number of active objects at a time.[/color]

Heya, "Tom Usenet", I used to think that you were a rational being,
perhaps someone well-known in the C++ community. But I can't make
head or tail of this statement. Since when did active objects become
part of standard C++ (yes, I do know there are extensions)?


[color=blue]
>The nature of the checking
>required to match that global exception type against a catch block
>though is identical to the checking required in a dynamic cast.[/color]

That's incorrect, because one can be done at compile time, the other
not.

N'th recap: for exception handling the only necessary information is
whether any given 'throw' is compatible with any given 'catch', and that
information can be deduced at compile time; abstractly it's a boolean
matrix indexed by 'throw'-statements and 'catch'-statements; a bit more
concretely it's a matrix of stubs indexed the same way.

To be even more clear (I strive, I strive), consider what must happen
when an exception is thrown. The run-time support must first of all
determine the dynamically innermost enclosing matching 'catch'. One
way to do that is to walk the stack frames and for each frame, check
whether that frame has a compatible and enclosing 'catch'. To do each
such check it can use RTTI. Alternatively, it can simply check a compile-
time generated table that does not involve types at all, just machine
code addresses for 'throw' and 'catch' statements; no RTTI.

Having found a handler (assuming one exists), the stack must be unwound,
calling destructors of local objects. This does not involve RTTI.

Then, the thrown object (or a copy of it) must be passed to the handler.

Again, this does not or need not involve RTTI.

For a dynamic cast source/destination compatibility can in general not
be established at compile time, even _in principle_, and so run-time
type information, RTTI, is required for that, different from exception
handling.


[color=blue]
>So, it seems that all you are saying is that you don't need to embed
>type information in your exception objects, and I don't think anyone
>has disagreed with this.[/color]

What I'm saying is that RTTI is not necessary for exception handling.

If that parses the same as the intended meaning of the above statement,
then we're in agreement.

If not, then what does that statement mean (in clear English)?

[tom_usenet]

Re: type_info, vtable

On Thu, 21 Aug 2003 16:19:41 GMT, alfps@start.no (Alf P. Steinbach)
wrote:
[color=blue]
>So in your view the similarity of a possible implementation of one
>aspect of RTTI, one the one hand, and the requirements of exception
>handling, on the other, makes RTTI necessary for exception handling?
>
>How?[/color]

A runtime lookup, best implemented on types, is required to implement
exception handling. This is also true of dynamic_cast.

I'm not saying that dynamic_cast is used to implement exception
handling, but that the implementation of both will no doubt use common
facilities, since matching a catch block is very similar to checking a
dynamic_cast. Do you agree?
[color=blue]
>I just have to say it, because it's so appropriate: since the doll is
>so similar to the person, sticking needles into the doll will harm the
>person. *Sticking needle into a Tom Usenet doll*. Uh, troll?[/color]

And you think I'm trolling!?
[color=blue]
>[color=green]
>>...[color=darkred]
>>>For a dynamic cast source/destination compatibility can in general not
>>>be established at compile time, even _in principle_, and so run-time
>>>type information, RTTI, is required for that, different from exception
>>>handling.[/color]
>>
>>But at compile time you cannot determine the destination catch of
>>every throw statement. What's the difference? You still need to do a
>>runtime lookup, in a matrix or otherwise.[/color]
>
>Yeah, yeah, similarity: something happens at run-time in both cases,
>hence, RTTI is necessary for exception handling.[/color]

Not just something, but something very similar happens in both cases.
I never said that RTTI is required to implement exception handling
(Ivan did at first, although he clarified that he wasn't referring to
the specific features of type_info and dynamic_cast), just that the
two involve very similar concepts, and can share a lot of
implementation.
[color=blue][color=green]
>>...
>>I think we have a disagreement about what RTTI means.[/color]
>
>Perhaps, if you're not just trolling.[/color]

No.
[color=blue]
>
>In my view, RTTI means "Run-Time Type Information":[/color]

No disagreement there.

having available[color=blue]
>at run-time the following functionality:
>
> - dynamic_cast
> - std::typeinfo[/color]

And typeid.
[color=blue]
>
>How is dynamic_cast, in your view, necessary for exception handling?
>Consider that we've already established that it's not necessary for
>finding an exception handler.
>
>Alternativel y, how is std::typeinfo necessary for exception handling?
>
>Alternativel y, how is a mechanism that for all practical purposes make
>this functionality trivial, _necessary_ for exception handling?[/color]

I was simply disagreeing with your earlier assertions that matching
throws with catches, and using dynamic_cast, are completely different
(something about compile time vs runtime that Ivan and I disagreed
with). They aren't - they are conceptually very similar, and
implementing the infrastructure for one should give you quite a lot of
the infrastructure required by the other.

Tom

[Ivan Vecerina]

Re: type_info, vtable

"Alf P. Steinbach" <alfps@start.no > wrote in message
news:3f44eceb.6 6448968@News.CI S.DFN.DE...[color=blue]
> On Thu, 21 Aug 2003 15:48:04 GMT, tom_usenet@hotm ail.com (tom_usenet)[/color]
wrote:[color=blue][color=green]
> >Right, I agree with that. But, fairly similarly, every constructor
> >call in a program can be matched with every dynamic_cast statement,
> >and a matrix produced. This matrix is indexed by constructor call
> >statements and dynamic_cast statements. Each object stores the
> >statement (code address) that created it (not necessarily inside the
> >object).[/color]
>
> So in your view the similarity of a possible implementation of one
> aspect of RTTI, one the one hand, and the requirements of exception
> handling, on the other, makes RTTI necessary for exception handling?[/color]

dynamic_cast and type matching in EH both require that instances of
types that derive from each other can be identified.
As both of these very similar mechanisms require type identification
at run time, is it unreasonable to call them both "RTTI mechanisms" ?
[color=blue]
> How is dynamic_cast, in your view, necessary for exception handling?
> Consider that we've already established that it's not necessary for
> finding an exception handler.
>
> Alternatively, how is std::typeinfo necessary for exception handling?[/color]

And how is std::typeinfo necessary for dynamic_cast ?

You seem to have your very own specific definition of what RTTI is.
Somehow it seems to include dynamic_cast, but excludes the
equivalent mechanism needed to support exception handling.

Since "RTTI" is not a term formally defined in the standard,
I think it is just pointless to keep arguing.


Regards,
--

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

[Ivan Vecerina]

Re: type_info, vtable

"Rolf Magnus" <ramagnus@t-online.de> wrote in message
news:bi2aav$qnn $04$2@news.t-online.com...[color=blue]
> Ivan Vecerina wrote:[color=green]
> > How would the C++ run-time handle a failure of this memory allocation
> > without RTTI?[/color]
>
> I don't know. Maybe you should ask the gcc developers, since you can
> disable RTTI and still use exceptions in g++.[/color]

From what I saw on google, there seems to have been some bugs with
EH when RTTI was disabled. And it's for the best if these were
fixed.

An implementation could also offer a compile mode where dynamic_cast
is supported, but not type_info.

But yes, it would be nice if a compiler writer/maintainer could tell
us if run-time type identification in EH and dynamic_cast share
some common code...


Regards,
--

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

[Alf P. Steinbach]

Re: type_info, vtable

On Thu, 21 Aug 2003 17:22:38 GMT, tom_usenet@hotm ail.com (tom_usenet) wrote:
[color=blue]
>On Thu, 21 Aug 2003 16:19:41 GMT, alfps@start.no (Alf P. Steinbach)
>wrote:
>[color=green]
>>So in your view the similarity of a possible implementation of one
>>aspect of RTTI, one the one hand, and the requirements of exception
>>handling, on the other, makes RTTI necessary for exception handling?
>>
>>How?[/color]
>
>A runtime lookup, best implemented on types[/color]

Pascal is "better" than Java. So there!


[color=blue]
>is required to implement exception handling. This is also true of
>dynamic_cast .[/color]

Similarity again. Yada yada yada. Did you know, both the earthworm and
George W. are lifeforms, and even more surprising, both are (to the best
of my knowledge) based on an incredibly complex molecule called DNA?


[color=blue]
>I'm not saying that dynamic_cast is used to implement exception
>handling, but that the implementation of both will no doubt use common
>facilities, since matching a catch block is very similar to checking a
>dynamic_cast . Do you agree?[/color]

Of course not, since it's illogical.

If you replace "will no doubt" with "can", and "is very similar to" with
"has some similarity with", then yes.


[color=blue][color=green]
>>I just have to say it, because it's so appropriate: since the doll is
>>so similar to the person, sticking needles into the doll will harm the
>>person. *Sticking needle into a Tom Usenet doll*. Uh, troll?[/color]
>
>And you think I'm trolling!?[/color]

Yep, I'm 99% sure now. ;-)


[color=blue]
>...
>I was simply disagreeing with your earlier assertions that matching
>throws with catches, and using dynamic_cast, are completely different
>(something about compile time vs runtime that Ivan and I disagreed
>with).[/color]

As we have established, they are very different.

Matching a throw with a catch involves a stack walk; using a dynamic_cast
does not. Checking whether a given throw is compatible with a given catch
can always be done at compile time. That is not the case for a dynamic_cast.
And so on and so forth. How can this be so difficult to grasp?

You'll have to quote the statement of mine which was sufficiently
unclear about that that it could be interpreted as something else.


[color=blue]
>They aren't - they are conceptually very similar[/color]

No. See immediately above, and the thread in general. However, checking
whether a given throw is compatible with a given catch is conceptually
somewhat similar to a dynamic_cast.

But again, similarity at an abstract level between a part of A and
a part of B does not make A necessary for B.


[color=blue]
>and
>implementing the infrastructure for one should give you quite a lot of
>the infrastructure required by the other.[/color]

No. It can, but won't necessarily. In particular, a simple throw/catch
compatibility table, computed from compile-time symbol table information,
is presumably of little or no use in implementing dynamic_cast.

[Alf P. Steinbach]

Re: type_info, vtable

On Thu, 21 Aug 2003 19:40:36 +0200, "Ivan Vecerina" <ivecATmyrealbo xDOTcom> wrote:
[color=blue]
>"Alf P. Steinbach" <alfps@start.no > wrote in message
>news:3f44eceb. 66448968@News.C IS.DFN.DE...[color=green]
>> On Thu, 21 Aug 2003 15:48:04 GMT, tom_usenet@hotm ail.com (tom_usenet)[/color]
>wrote:[color=green][color=darkred]
>> >Right, I agree with that. But, fairly similarly, every constructor
>> >call in a program can be matched with every dynamic_cast statement,
>> >and a matrix produced. This matrix is indexed by constructor call
>> >statements and dynamic_cast statements. Each object stores the
>> >statement (code address) that created it (not necessarily inside the
>> >object).[/color]
>>
>> So in your view the similarity of a possible implementation of one
>> aspect of RTTI, one the one hand, and the requirements of exception
>> handling, on the other, makes RTTI necessary for exception handling?[/color]
>
>dynamic_cast and type matching in EH both require that instances of
>types that derive from each other can be identified.[/color]

That's correct.

[color=blue]
>As both of these very similar mechanisms require type identification
>at run time,[/color]

That's incorrect.

[color=blue]
> is it unreasonable to call them both "RTTI mechanisms" ?[/color]

Yes.

[Ivan Vecerina]

Re: type_info, vtable


"Alf P. Steinbach" <alfps@start.no > wrote in message
news:3f450733.7 3173546@News.CI S.DFN.DE...[color=blue]
> On Thu, 21 Aug 2003 19:40:36 +0200, "Ivan Vecerina"[/color]
<ivecATmyrealbo xDOTcom> wrote:
....[color=blue][color=green]
> >As both of these very similar mechanisms require type identification
> >at run time,[/color]
>
> That's incorrect.[/color]
....[color=blue][color=green]
> > is it unreasonable to call them both "RTTI mechanisms" ?[/color]
>
> Yes.[/color]

Again, what seems to define type identification for you is
the use of a type identifier associated with an object instance;
using a type identifier associated with a catch block on
the call stack is not.

This is your own definition - feel free:[color=blue][color=green]
> >Since "RTTI" is not a term formally defined in the standard,
> >I think it is just pointless to keep arguing.[/color][/color]

[Alf P. Steinbach]

Re: type_info, vtable

On Fri, 22 Aug 2003 06:42:35 +0200, "Ivan Vecerina" <ivecATmyrealbo xDOTcom> wrote:
[color=blue]
>
>"Alf P. Steinbach" <alfps@start.no > wrote in message
>news:3f450733. 73173546@News.C IS.DFN.DE...[color=green]
>> On Thu, 21 Aug 2003 19:40:36 +0200, "Ivan Vecerina"[/color]
><ivecATmyrealb oxDOTcom> wrote:
>...[color=green][color=darkred]
>> >As both of these very similar mechanisms require type identification
>> >at run time,[/color]
>>
>> That's incorrect.[/color]
>...[color=green][color=darkred]
>> > is it unreasonable to call them both "RTTI mechanisms" ?[/color]
>>
>> Yes.[/color]
>
>Again, what seems to define type identification for you is
>the use of a type identifier associated with an object instance;
>using a type identifier associated with a catch block on
>the call stack is not.[/color]

Funny, we seem to have posted new replies at the same time...

See my other (new) reply here for what I hope is a clarification.

Of course, it may be that it will only muddle waters even more.


[color=blue]
>This is your own definition - feel free:[color=green][color=darkred]
>> >Since "RTTI" is not a term formally defined in the standard,
>> >I think it is just pointless to keep arguing.[/color][/color][/color]

Wasn't that _your_ definition?

[tom_usenet]

Re: type_info, vtable

On Fri, 22 Aug 2003 05:35:17 GMT, alfps@start.no (Alf P. Steinbach)
wrote:
[color=blue][color=green][color=darkred]
>>> is it unreasonable to call them both "RTTI mechanisms" ?[/color]
>>
>>Yes.[/color]
>
>The question is : what is the defining characteristic/s of RTTI?
>Pure RTTI seems to be exactly equivalent to 'dynamic_downca st', like,
>say, the Eiffel assignment attempt. But what about that is it that
>makes it "Run Time" (which we've had such a hard time pinning down),
>and what about that is it that makes it "Type Information" (ditto)?
>
>That's a bit subtle, and I agree with Tom Usenet that that is probably
>why we have not managed to agree.
>
>As I see it:
>
>
> "Run Time" --> Only _knowable_ at run time, i.e. potentially
> changing over time for the same code snippet.
>
> "Type Info" --> An _explicit representation_ of a type.
>
>
>I think you all agree with the "Run Time" definition, and probably
>associate "potentiall y changing" in the context of exception handling
>with "changing catch statement" depending on how a 'throw' is reached.
>
>The "Type Info" is a bit harder, but here's an example, namely the
>'throw'/'catch' compatibility matrix revisited. This matrix is in its most
>basic form indexed by 'throw' statements and 'catch' statements. But in
>typical code the number of thrown types tends to be very small, a handful
>or so, and likewise for the number of caught types. And so all rows
>representing 'throw' statements of the same type can essentially be
>collapsed into one common row, plus an external vector that maps 'throw'
>statements to rows. And ditto for columns indexed by 'catch' statements.
>
>In this optimization a single row that represents a set of 'throw'
>statements of the same type is in effect an identification of that type
>in the sense that there is a one-to-one mapping between the relevant
>types and corresponding rows. But it is not an explicit representation,
>for given the (index to) a row one cannot obtain any information about
>the type except via additional otherwise unnecessary stored associations,
>nor can the row be used for anything but 'catch'/'throw' compatibility
>checking. And the row is not "only knowable at run-time"; it can be (and
>must, in order to practically useful, be) constructed at compile time.
>
>For columns the situation is more complex, for a column index is only
>available when a stack frame with a containing 'catch' has been found.
>So isn't this column index then both an explicit representation of a
>type (the 'catch' type), and only knowable at run-time? Yes to the last,
>but no to the first: it's not an explicit representation, it cannot be
>used to determine anything about the type involved (except via additional
>and otherwise unnecessary information).
>
>In short, all that's necessary for C++ exception handling is _implicit_
>type representation that cannot be used for any other purpose. And so
>it's not surprising that C++ EH cannot emulate 'dynamic_cast'. Or that
>the functionality of 'dynamic_cast', or basic RTTI, is not required.
>
>The end result of this analysis-by-example is that the concept of RTTI
>hinges crucially on _explicit_ type representation.[/color]

No, you've shown that exception handling *doesn't* hinge on explicit
type representation. This is also true of dynamic_cast. Here's a
rewrite of your example:

The "Type Info" is a bit harder, but here's an example, namely the
'constructor call'/'dynamic_cast' compatibility matrix revisited. This
matrix is in its most basic form indexed by 'constructor call'
statements and 'dynamic_cast' statements. In typical code the number
of created types tends to be quite large, but the number of types
dynamically casted to tends to be small. And so all rows representing
'constructor call' statements of the same type can essentially be
collapsed into one common row, plus an external vector that maps
'constructor call' statements to rows. And ditto for columns indexed
by 'dynamic_cast' statements.

In this optimization a single row that represents a set of
'constructor call' statements of the same type is in effect an
identification of that type in the sense that there is a one-to-one
mapping between the relevant types and corresponding rows. But it is
not an explicit representation, for given the (index to) a row one
cannot obtain any information about the type except via additional
otherwise unnecessary stored associations, nor can the row be used for
anything but 'dynamic_cast' compatibility checking.

For columns the situation is simple. The column index is known for a
particular 'dynamic_cast' statement at compile time. For rows the
situation is more complex. The row index is only found when the object
begin passed to the 'dynamic_cast' statement is known, and this is
only knowable in general at runtime. So isn't this row index then both
an explicit representation of a type (the 'constructor call' type),
and only knowable at run-time? Yes to the last, but no to the first:
it's not an explicit representation, it cannot be used to determine
anything about the type involved (except via additional and otherwise
unnecessary information).

In short, all that's necessary for C++ dynamic_cast is _implicit_
type representation that cannot be used for any other purpose.


Some very thinking-[color=blue]
>circuit-activating books have been written about just that little
>crucial but hard-to-pin-down difference. Hofstadter's "Gödel, Escher,
>Bach" comes to mind, as well as Scott Fahlman's "NETL", not to mention
>Wolfram's "A new kind of physics". It's no wonder that we find it hard
>to agree on the dividing line...[/color]

Your argument is specious, since the fact that exception handling does
not require RTTI can be simply extended to an argument that
dynamic_cast doesn't require RTTI. Either your definition of RTTI is
wrong, or dynamic_cast doesn't require RTTI.

However, neither of these arguments change the fact that matching
catch blocks and performing dynamic_casts both conceptually involve
taking a type, and checking it to see whether it is derived from
another type, and performing this check at runtime.

If your position is simply that you choose not to call that RTTI, we
can agree to disagree.

Tom

[Buster Copley]

Re: type_info, vtable

Dynamic_cast can't be made to work that way.

Exception handling is different. What happens when an exception is
thrown? We know what row of the matrix we need (this information is
encoded in the 'throw', not in the exception object) and we know what
stack frame we are in. We move up a frame until we reach a stack frame
with a catch clause. That gives us a column of the matrix. If the throw
and catch match according to the matrix, we stop. Otherwise we carry on.

Try to use a matrix of object creations to dynamic_casts to emulate
dynamic cast in a similar way. What happens when a constructor is
invoked? What doesn't and couldn't happen is a systematic search for a
dynamic_cast. We know at the point of construction what row of the
matrix to look at, but if we still know that at the dynamic_cast then we
have associated a row-index with each object. Since there is a one-one
correspondence between rows and types, this information can be said to
be type information.

The matrix of object creations and dynamic_casts along with the
row-index to object association could certainly be used to implement
exception handling, but the converse fails. The throw-catch matrix
cannot emulate dynamic_cast, even if extended to include all object
creations and dynamic_casts, because the row-index is not known at the
site of the dynamic_cast.

Corrections are welcome.

Regards,
Buster

[tom_usenet]

Re: type_info, vtable

On Thu, 21 Aug 2003 17:51:55 GMT, alfps@start.no (Alf P. Steinbach)
wrote:
[color=blue]
>As we have established, they are very different.
>
>Matching a throw with a catch involves a stack walk; using a dynamic_cast
>does not. Checking whether a given throw is compatible with a given catch
>can always be done at compile time. That is not the case for a dynamic_cast.[/color]

You can check, at compile time, whether any particular call to an
object constructor is compatible with any particular dynamic_cast.
[color=blue]
>And so on and so forth. How can this be so difficult to grasp?[/color]

Because it is factually incorrect! (the bit about dynamic_cast, not
the bit about exceptions).
[color=blue]
>
>You'll have to quote the statement of mine which was sufficiently
>unclear about that that it could be interpreted as something else.[/color]

To clarify, the statements that you have made that I disagree with:

"With 'dynamic_cast' the argument can be a pointer to an object that
according to the standard must have its dynamic type checked (a
pointer to 'throw' is not checked for dyntype)."

This is inconsistent. The "dynamic type" does not need to be looked up
to perform a dynamic_cast - only an index into a matrix needs to be
computed. According to your definition, this does not count as "having
its dynamic type checked".

Here's another quote (from me and then your response):

"[color=blue]
>What I mean is that there is no fundamental difference between the
>runtime check required by dynamic_cast and the runtime check required
>to select a catch block.
>
>For dynamic cast the compiler could build up a matrix of every use of
>a type in dynamic cast, and every creation of an object.
>
>For exception handling, the compiler could build up a matrix of every
>use of a type in a throw, and every use in a catch.
>
>What's the difference?[/color]

The first is nonsense since the type of *p cannot be predicted in the
general case.
"

I disagree with this too.

Your assertion that the type of *p cannot be predicted at compile time
is true. But why do you think that leads to "the first is nonsense"?

My equivalent statement about your throw/catch matrix would be:
"The second is nonsense since the type caught cannot be predicted in
the general case."

But in fact, neither statement is nonsense.
[color=blue][color=green]
>>They aren't - they are conceptually very similar[/color]
>
>No. See immediately above, and the thread in general. However, checking
>whether a given throw is compatible with a given catch is conceptually
>somewhat similar to a dynamic_cast.
>
>But again, similarity at an abstract level between a part of A and
>a part of B does not make A necessary for B.[/color]

We're agreed there, but that was never what I was disagreeing with.
[color=blue][color=green]
>>and
>>implementin g the infrastructure for one should give you quite a lot of
>>the infrastructure required by the other.[/color]
>
>No. It can, but won't necessarily. In particular, a simple throw/catch
>compatibilit y table, computed from compile-time symbol table information,
>is presumably of little or no use in implementing dynamic_cast.[/color]

On the contrary, the same matrix (with an extra column for each
dynamic_cast target type and an extra row for each created object
type) is fine for dynamic_cast compatibility checks too (ignoring
virtual inheritence for now).

Tom

[Alf P. Steinbach]

Re: type_info, vtable

On Fri, 22 Aug 2003 11:40:23 GMT, tom_usenet@hotm ail.com (tom_usenet) wrote:
[color=blue]
>For columns the situation is simple. The column index is known for a
>particular 'dynamic_cast' statement at compile time. For rows the
>situation is more complex. The row index is only found when the object
>begin passed to the 'dynamic_cast' statement is known, and this is
>only knowable in general at runtime. So isn't this row index then both
>an explicit representation of a type (the 'constructor call' type),
>and only knowable at run-time? Yes to the last, but no to the first:
>it's not an explicit representation, it cannot be used to determine
>anything about the type involved (except via additional and otherwise
>unnecessary information).[/color]

Just to pin down our differences, it's the "but no to the first", and
the following justification, that I don't agree with.

In my view an address of the constructor call stored in each (non-POD)
object _is_ an explicit type representation, RTTI "Type Information".

And it can easily be used to obtain information about the type, namely
via 'dynamic_cast' to various destination types -- I just note in
passing that if it were not so (which it is) it would not be a working
implementation of 'dynamic_cast'.


[color=blue]
>Your argument is specious, since the fact that exception handling does
>not require RTTI can be simply extended to an argument that
>dynamic_cast doesn't require RTTI. Either your definition of RTTI is
>wrong, or dynamic_cast doesn't require RTTI.[/color]

Your assertion that dynamic_cast cannot be used to obtain information
about the dynamic type is incorrect, and so that argument is a fallacy.

But that does not mean that the definitions I know of RTTI are
in some sense "correct".

It does, however, mean that any definition of RTTI that doesn't
require storage of an explicit type representation is a practically
useless definition, void of meaning.


[color=blue]
>However, neither of these arguments change the fact that matching
>catch blocks and performing dynamic_casts both conceptually involve
>taking a type, and checking it to see whether it is derived from
>another type, and performing this check at runtime.[/color]

In my considered opinion George W. requires earthworms, since they
are somewhat similar at the genetic level. Bright insight! Perhaps
he's going fishing?


[color=blue]
>If your position is simply that you choose not to call that RTTI, we
>can agree to disagree.[/color]

That seems to be the case, yes.

[tom_usenet]

Re: type_info, vtable

On Fri, 22 Aug 2003 13:29:03 +0100, Buster Copley <buster@none.co m>
wrote:
[color=blue]
>Dynamic_cast can't be made to work that way.
>
>Exception handling is different. What happens when an exception is
>thrown? We know what row of the matrix we need (this information is
>encoded in the 'throw', not in the exception object) and we know what
>stack frame we are in. We move up a frame until we reach a stack frame
>with a catch clause. That gives us a column of the matrix. If the throw
>and catch match according to the matrix, we stop. Otherwise we carry on.[/color]

Right.
[color=blue]
>
>Try to use a matrix of object creations to dynamic_casts to emulate
>dynamic cast in a similar way. What happens when a constructor is
>invoked? What doesn't and couldn't happen is a systematic search for a
>dynamic_cast .[/color]

Of course not. Two options - either the row number is placed inside
the object, or the address of the object is added to a map of object
address - to row number.

We know at the point of construction what row of the[color=blue]
>matrix to look at, but if we still know that at the dynamic_cast then we
>have associated a row-index with each object. Since there is a one-one
>corresponden ce between rows and types, this information can be said to
>be type information.[/color]

There isn't necessarily such a one-to-one correspondence. If you have
one row per type, then some of the rows may be identical, which makes
the correspondance only many-to-one, strictly speaking.
[color=blue]
>The matrix of object creations and dynamic_casts along with the
>row-index to object association could certainly be used to implement
>exception handling, but the converse fails. The throw-catch matrix
>cannot emulate dynamic_cast, even if extended to include all object
>creations and dynamic_casts, because the row-index is not known at the
>site of the dynamic_cast.[/color]

It is if the row index is placed inside the object (or its vtable), or
if a map of object address to row index is maintained. This was my
point, that the matrix bit that was being bandied around could also
provide the basis of a dynamic_cast implementation, just as it could
provide the basis of an exception handling implementation. This is
because the matrix is just an implementation of type compatibility,
something that is central to both dynamic_cast and throw/catch
matching.

For an exception, you have to walk the stack to find the column index.
For a dynamic_cast you have to lookup the row index for the object in
question (either inside the object, or in an object address indexed
map). There are different operations, but they are both still runtime
operations (hence my disagreement with assertions about exceptions
being compile time, and dynamic_cast being runtime).

Tom