type_info, vtable

**Ivan Vecerina** · Jul 19 '05, 04:30 PM

Re: type_info, vtable

"sks_cpp" <sksjava@hotmai l.com> wrote in message
news:Nnf0b.3242 4$Ij4.31849@new s2.central.cox. net...
| What is a type_info function, more particularly, what is a type_info node?
| Are these related to the vtable by any means?

Somewhat. In several implementations , the vtable stores the address of
the type_info data structure.
This data structure is used to implement Run-Time Type Identification
(RTTI),
a feature which is required for exception handling, dynamic_cast calls,
and the implementation of the typeid operator (see header <typeinfo>).

| I have seen linker errors such as:
| "undefined reference to SomeClass type_info node" or
| "undefined reference to SomeClass type_info function"

Some C++ compiler implementations allow to enable/disable support
for RTTI. You probably need to enable it for some files...

hth
--
Ivan Vecerina <> http://www.post1.com/~ivec
Brainbench MVP for C++ <> http://www.brainbench.com

**Rolf Magnus** · Jul 19 '05, 04:30 PM

Re: type_info, vtable

Ivan Vecerina wrote:
[color=blue]
> This data structure is used to implement Run-Time Type Identification
> (RTTI), a feature which is required for exception handling,[/color]

RTTI isn't need for exception handling, neither would it be sufficient.

**Ivan Vecerina** · Jul 19 '05, 04:30 PM

Re: type_info, vtable

"Rolf Magnus" <ramagnus@t-online.de> wrote in message
news:bhsr18$crk $03$1@news.t-online.com...
| Ivan Vecerina wrote:
|
| > This data structure is used to implement Run-Time Type Identification
| > (RTTI), a feature which is required for exception handling,
|
| 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?

Regards,
Ivan
--

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

**Alf P. Steinbach** · Jul 19 '05, 04:30 PM

Re: type_info, vtable

On Tue, 19 Aug 2003 15:29:37 +0200, "Ivan Vecerina" <ivec@myrealbox .com> wrote:
[color=blue]
>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) {[/color]

Preferably use

catch( std::exception const& x )

[color=blue]
> std::cerr << "Failure: "<<x.what()<<st d::endl;
> }
> }
>
>How would the C++ run-time handle a failure of this memory allocation
>without RTTI?[/color]

The actual types are not needed at run-time, only the compatibility
matrix of catches and throws.

That abstract matrix can be optimized in umpteen ways.

One way, but not the only way, is to use RTTI.

**Risto Lankinen** · Jul 19 '05, 04:32 PM

Re: type_info, vtable

"Alf P. Steinbach" <alfps@start.no > wrote in message
news:3f4226d5.4 14481453@News.C IS.DFN.DE...[color=blue]
> On Tue, 19 Aug 2003 15:29:37 +0200, "Ivan Vecerina" <ivec@myrealbox .com>[/color]
wrote:[color=blue][color=green]
> >
> >How would the C++ run-time handle a failure of this memory allocation
> >without RTTI?[/color]
>
> The actual types are not needed at run-time, only the compatibility
> matrix of catches and throws.
>
> That abstract matrix can be optimized in umpteen ways.
>
> One way, but not the only way, is to use RTTI.[/color]

Furthermore, exception handling uses compile-time types,
not run-time (e.g. dynamic) types. Try this example:

#include <iostream.h>

struct Base
{
virtual ~Base()
{
}
};

struct Derived : public Base
{
};

int main()
{
Base *p = new Derived;

try
{
throw *p;
}
catch( const Derived & )
{
cout << "Derived" << endl;
}
catch( const Base & )
{
cout << "Base" << endl;
}
catch( ... )
{
cout << "<unknown>" << endl;
}

delete p;

return 0;
}

This program prints "Base".

Cheers!

- Risto -

**Alf P. Steinbach** · Jul 19 '05, 04:32 PM

Re: type_info, vtable

On Tue, 19 Aug 2003 19:48:09 +0200, "Ivan Vecerina" <ivec@myrealbox .com> wrote:
[color=blue]
>"Alf P. Steinbach" <alfps@start.no > wrote in message
>news:3f4226d5. 414481453@News. CIS.DFN.DE...
>| On Tue, 19 Aug 2003 15:29:37 +0200, "Ivan Vecerina" <ivec@myrealbox .com>
>wrote:
>| > try {
>| > std::vector<std ::string> tooBig(1UL<<31, "just some string");
>| > }
>| > catch(std::exce ption& x) {
>|
>| Preferably use
>|
>| catch( std::exception const& x )
>Agreed.
>
>| > std::cerr << "Failure: "<<x.what()<<st d::endl;
>| > }
>| > }
>| >
>| >How would the C++ run-time handle a failure of this memory allocation
>| >without RTTI?
>|
>| The actual types are not needed at run-time, only the compatibility
>| matrix of catches and throws.
>|
>| That abstract matrix can be optimized in umpteen ways.
>|
>| One way, but not the only way, is to use RTTI.
>
>Actually, the exact same thing can be said of dynamic_cast:
>you only need a compatibility matrix of source and destination types.[/color]

I see where the confusion stems from now.

No, dynamic cast is a very different. With 'throw' the compiler knows
the exact type of the argument. 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).

[color=blue]
>Clearly, Exception Handling does require a form of run-time type
>identificati on (albeit this RTTI does not formally need to
>rely on a data structure known to the linker as 'type_info').[/color]

Nope.

[color=blue]
>Let's just put things in the context of the OP, who was requesting
>information on why his linker reported missing 'type_info' nodes.
>I explained which language features may "require" them, and that
>enabling RTTI is probably the way to have them generated.
>
>Was this incorrect?[/color]

That I don't know...

**Ivan Vecerina** · Jul 19 '05, 04:32 PM

Re: type_info, vtable

"Alf P. Steinbach" <alfps@start.no > wrote in message
news:3f433e86.4 86081828@News.C IS.DFN.DE...
| On Tue, 19 Aug 2003 19:48:09 +0200, "Ivan Vecerina" <ivec@myrealbox .com>
wrote:
| >"Alf P. Steinbach" <alfps@start.no > wrote in message
| >news:3f4226d5. 414481453@News. CIS.DFN.DE...
| >| The actual types are not needed at run-time, only the compatibility
| >| matrix of catches and throws.
| >|
| >| That abstract matrix can be optimized in umpteen ways.
| >|
| >| One way, but not the only way, is to use RTTI.
| >
| >Actually, the exact same thing can be said of dynamic_cast:
| >you only need a compatibility matrix of source and destination types.
|
| I see where the confusion stems from now.
|
| No, dynamic cast is a very different. With 'throw' the compiler knows
| the exact type of the argument.

Yes, just as when a new object is created (e.g. with the 'new' operator).

| 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).

And when a catch clause is encountered during stack unwinding, the
dynamic type of the exception being thrown (and eventually re-thrown)
needs to be matched with the type of the catch clause.

For dynamic_cast as well, the compiler could make some static program
analysis and establish that the provided object has to be of a specific
type. The fact is, in practice, this would be too difficult.
And it would be about as difficult to pre-match try and catch clauses.

When compiling a throw clause, the catch handlers that will be on the
call stack are not known. Reciprocally, when compiling a try-catch block,
the throw statements that may be invoked are unknown. So the matching
of these two types somehow has to happen at run-time.

For dynamic_cast, RTTI involves the matching of a type identifier
which is defined during object creation (and typically stored within
the vtbl of an object, with a locally known type.
For Exception Handling, RTTI involves the matching of a type identifier
somehow defined at an unknown throw point, with the locally known
type of a catch clause (or reciprocally).
It just isn't that much different. And as far as I know (from the last
time I checked the internals of a C++ runtime core), the same kind of
type information is typically used to implement both these mechanisms.

Kind regards,
Ivan
--

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

**Alf P. Steinbach** · Jul 19 '05, 04:32 PM

Re: type_info, vtable

On Wed, 20 Aug 2003 16:30:22 +0200, "Ivan Vecerina" <ivec@myrealbox .com> wrote:
[color=blue]
>"Alf P. Steinbach" <alfps@start.no > wrote in message
>news:3f433e86. 486081828@News. CIS.DFN.DE...
>| On Tue, 19 Aug 2003 19:48:09 +0200, "Ivan Vecerina" <ivec@myrealbox .com>
>wrote:
>| >"Alf P. Steinbach" <alfps@start.no > wrote in message
>| >news:3f4226d5. 414481453@News. CIS.DFN.DE...
>| >| The actual types are not needed at run-time, only the compatibility
>| >| matrix of catches and throws.
>| >|
>| >| That abstract matrix can be optimized in umpteen ways.
>| >|
>| >| One way, but not the only way, is to use RTTI.
>| >
>| >Actually, the exact same thing can be said of dynamic_cast:
>| >you only need a compatibility matrix of source and destination types.
>|
>| I see where the confusion stems from now.
>|
>| No, dynamic cast is a very different. With 'throw' the compiler knows
>| the exact type of the argument.
>
>Yes, just as when a new object is created (e.g. with the 'new' operator).
>
>| 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).
>
>And when a catch clause is encountered during stack unwinding, the
>dynamic type of the exception being thrown (and eventually re-thrown)
>needs to be matched with the type of the catch clause.[/color]

At run-time there is no need for _type_ matching to determine the relevant
catch-clause, if any; only compatibility is relevant, and as mentioned the
compatibility matrix can be optimized and implemented in umpteen ways.

RTTI means "Run-Time Type Information", which isn't necessarily involved.

**tom_usenet** · Jul 19 '05, 04:32 PM

Re: type_info, vtable

On Wed, 20 Aug 2003 14:50:01 GMT, alfps@start.no (Alf P. Steinbach)
wrote:
[color=blue][color=green]
>>And when a catch clause is encountered during stack unwinding, the
>>dynamic type of the exception being thrown (and eventually re-thrown)
>>needs to be matched with the type of the catch clause.[/color]
>
>At run-time there is no need for _type_ matching to determine the relevant
>catch-clause, if any; only compatibility[/color]

Do you mean type compatibility? Or what?

is relevant, and as mentioned the[color=blue]
>compatibilit y matrix can be optimized and implemented in umpteen ways.[/color]

This is true for dynamic cast too - you only need to check the
compatibility of the source and destination types. In practice, may
dynamic_cast calls can be realized using a "compatibil ity matrix",
since the compiler can sometimes statically determine the type of the
object. Just as with exceptions, when it can *sometimes* statically
determine the call stack associated with a particular throw.
[color=blue]
>RTTI means "Run-Time Type Information", which isn't necessarily involved.[/color]

Some processing has to be done at runtime that involves types. What do
you call it?

Tom

**Alf P. Steinbach** · Jul 19 '05, 04:32 PM

Re: type_info, vtable

On Wed, 20 Aug 2003 15:51:53 GMT, tom_usenet@hotm ail.com (tom_usenet) wrote:
[color=blue]
>On Wed, 20 Aug 2003 14:50:01 GMT, alfps@start.no (Alf P. Steinbach)
>wrote:
>[color=green][color=darkred]
>>>And when a catch clause is encountered during stack unwinding, the
>>>dynamic type of the exception being thrown (and eventually re-thrown)
>>>needs to be matched with the type of the catch clause.[/color]
>>
>>At run-time there is no need for _type_ matching to determine the relevant
>>catch-clause, if any; only compatibility[/color]
>
>Do you mean type compatibility? Or what?[/color]

That was further up the tread. From the programmer's point of view
it is type compatibility. But wrt. to what happens at run-time it
is throw/catch statement compatibility; no types _need_ to be
examined or compared at run-time.

[color=blue]
> is relevant, and as mentioned the[color=green]
>>compatibili ty matrix can be optimized and implemented in umpteen ways.[/color]
>
>This is true for dynamic cast too - you only need to check the
>compatibilit y of the source and destination types.[/color]

That disregards when (compile time, run time) the check wrt. type
needs to be done, which is the question debated.

[color=blue]
>In practice, may
>dynamic_cast calls can be realized using a "compatibil ity matrix",
>since the compiler can sometimes statically determine the type of the
>object. Just as with exceptions, when it can *sometimes* statically
>determine the call stack associated with a particular throw.
>[color=green]
>>RTTI means "Run-Time Type Information", which isn't necessarily involved.[/color]
>
>Some processing has to be done at runtime that involves types.[/color]

Nope. Unless you mean that information is used that the compiler derived
from types. Everything in the compiled program is in some way derived
from or associated with types, so that is a meaningless argument.

[color=blue]
>What do you call it?[/color]

Exception handling?

**Ivan Vecerina** · Jul 19 '05, 04:33 PM

Re: type_info, vtable

"Alf P. Steinbach" <alfps@start.no > wrote in message
news:3f438a06.5 05409921@News.C IS.DFN.DE...[color=blue]
> On Wed, 20 Aug 2003 16:30:22 +0200, "Ivan Vecerina" <ivec@myrealbox .com>[/color]
wrote:
....[color=blue][color=green]
> >| 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).
> >
> >And when a catch clause is encountered during stack unwinding, the
> >dynamic type of the exception being thrown (and eventually re-thrown)
> >needs to be matched with the type of the catch clause.[/color]
>
> At run-time there is no need for _type_ matching to determine the relevant
> catch-clause, if any; only compatibility is relevant, and as mentioned the
> compatibility matrix can be optimized and implemented in umpteen ways.[/color]

Can you clarify the fundamental difference you see between the type
compatibility tests performed by calls to dynamic_cast, and the type
compatibility tests required by EH to find catch handlers ?
[color=blue]
> RTTI means "Run-Time Type Information", which isn't necessarily involved.[/color]

Given separate compilation and dynamically linked library, can you
explain how an exception thrown by one library can be matched with
a catch handler in another library without performing a run-time
test based on some type of type identifier ?

Do you know of a compiler where dynamic_cast and EH do not share a
common infrastructure for checking the compatibility of types ?

Have you heard that RTTI had been adopted by the C++ committee in
spite of Stroustrup's reservations (leads to bad coding style...),
and that one of the strong arguments in favor of RTTI's adoption
was that the underlying mechanisms where required by EH anyway ?

Sincerely,
Ivan
--

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

**Ivan Vecerina** · Jul 19 '05, 04:33 PM

Re: type_info, vtable

"Alf P. Steinbach" <alfps@start.no > wrote in message
news:3f44052a.7 120312@News.CIS .DFN.DE...[color=blue]
> On Thu, 21 Aug 2003 00:58:45 +0200, "Ivan Vecerina"[/color]
<ivecATmyrealbo xDOTcom> wrote:[color=blue][color=green]
> >Can you clarify the fundamental difference you see between the type
> >compatibilit y tests performed by calls to dynamic_cast, and the type
> >compatibilit y tests required by EH to find catch handlers ?[/color]
>
> I thought I did: the former can only be performed at run-time, hence
> "Run Time Type Information", because no compiler can even _in principle_
> predict the dynamic type of *p in the general case. The latter,[/color]
compatibility[color=blue]
> between throw statements and catch statements, can in principle be[/color]
computed[color=blue]
> at compile time as a huge matrix. The huge matrix is not very practical[/color]
so[color=blue]
> various optimizations are used, including RTTI, but that does not make
> RTTI _required_; it's just one option among many.[/color]

But again: if you assume global program analysis, dynamic_cast may also
rely on a compatibility matrix between the locations were object instances
are created, and the calls to dynamic_cast. A huge matrix which may also
be 'optimized' in various ways.
The mechanism is still the same: some source type needs to be checked
for compatibility with some destination type, and a pointer offset has
to be applied.
The only difference I see is that, for dynamic_cast, the object's type
is typically stored with the object (e.g. in the vtbl). For EH, the
thrown type needs to be stored somewhere so that it can be matched
during stack-unwinding (to be accessible to catch()-handling code).
Or reciprocally, try-catch() blocks that are on the call stack need
to somehow be identified at run-time -- as you can't always know at
compile time where a throwing function has been called from.
[color=blue][color=green][color=darkred]
> >> RTTI means "Run-Time Type Information", which isn't necessarily[/color][/color][/color]
involved.[color=blue][color=green]
> >
> >Given separate compilation and dynamically linked library, can you
> >explain how an exception thrown by one library can be matched with
> >a catch handler in another library without performing a run-time
> >test based on some type of type identifier ?[/color]
>
> No. Dynamically linked libraries are not part of C++. In a C++
> implementation that supports dynamically linked libraries the most
> natural way would be to use some form of RTTI, but I fail to see
> any proof that RTTI is required in this case (with some more constraints
> imposed, e.g. current linker technology, such a proof may be possible).[/color]

The reality of C/C++ today is separate compilation and limited
support for whole program optimization. But I agree that the standard
says very little about separate compilation.
Maybe in the informative annex about C compatibility (C1.6/2):
"When comparing types in different compilation units, C++ relies on
name equivalence when C relies on structural equivalence."
[color=blue][color=green]
> >Have you heard that RTTI had been adopted by the C++ committee in
> >spite of Stroustrup's reservations (leads to bad coding style...),[/color][/color]
....[color=blue][color=green]
> >and that one of the strong arguments in favor of RTTI's adoption
> >was that the underlying mechanisms where required by EH anyway ?[/color][/color]
....[color=blue]
> Do you have any references for that rumour?[/color]

I have no concrete information about what these 'reservations' were.
But I remember reading about the common underlying mechanism in
several instances.
What a quick google search brings:

Bruce Eckel's Thinking in C++, 2nd ed., Volume 2, Revision 2:
About RTTI:
"When exception handling was added to C++, it required the exact type
information about objects. It became an easy next step to build access
to that information into the language."

http://nicolas.blancpain.free.fr/Documents/Cpp/onlinev2/Chapter08.html

Some random web doc:
"Why might RTTI be useful?
Input of objects (what kind is it?), OODBs, debugging
Despite Stroustrup's reservations, RTTI adopted by
ANSI/ISO committee (Borland 4.0)
Why is RTTI already implied by exception handling?
catch needs to discriminate types"

http://www.eecs.lehigh.edu/~glennb/oose/13exRTTI.doc

NB: BS actually proposed RTTI in the form of dynamic_cast:
"BS: Yes, I was the one who invented the dynamic_cast syntax to
parallel the syntax for explicitly qualified template function calls.
Together with Dmitry Lenkov from HP, I was the proposer of the
runtime type identification (RTTI) mechanisms.
RTTI is easily overused. However, ...."

Access Denied

http://www.research.att.com/~bs/omo_interview.html

Nothing that authoritative indeed. I don't have BS's D&E
or his other books here to look for a quote.
Maybe some committee member could help here...

Kind regards,
Ivan
--

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

**Alf P. Steinbach** · Jul 19 '05, 04:33 PM

Re: type_info, vtable

On Thu, 21 Aug 2003 08:21:53 +0200, "Ivan Vecerina" <ivecATmyrealbo xDOTcom> wrote:
[color=blue]
>"Alf P. Steinbach" <alfps@start.no > wrote in message
>news:3f44052a. 7120312@News.CI S.DFN.DE...[color=green]
>> On Thu, 21 Aug 2003 00:58:45 +0200, "Ivan Vecerina"[/color]
><ivecATmyrealb oxDOTcom> wrote:[color=green][color=darkred]
>> >Can you clarify the fundamental difference you see between the type
>> >compatibilit y tests performed by calls to dynamic_cast, and the type
>> >compatibilit y tests required by EH to find catch handlers ?[/color]
>>
>> I thought I did: the former can only be performed at run-time, hence
>> "Run Time Type Information", because no compiler can even _in principle_
>> predict the dynamic type of *p in the general case. The latter,[/color]
>compatibilit y[color=green]
>> between throw statements and catch statements, can in principle be[/color]
>computed[color=green]
>> at compile time as a huge matrix. The huge matrix is not very practical[/color]
>so[color=green]
>> various optimizations are used, including RTTI, but that does not make
>> RTTI _required_; it's just one option among many.[/color]
>
>But again: if you assume global program analysis, dynamic_cast may also
>rely on a compatibility matrix between the locations were object instances
>are created, and the calls to dynamic_cast.[/color]

That's pure nonsense. After an object is created pointers to it are passed
around in an unpredictable way, and it's the pointers you cast.

Now I just saw Tom Usenet's reply with an example of what could be
unpredictable _control flow_ -- which btw. is irrelevant to RTTI.

Perhaps you're confusing stack unwinding (where information about which
throw statement has been executed is directly available) with checking
the dynamic type of *p?

[color=blue][color=green][color=darkred]
>> >Have you heard that RTTI had been adopted by the C++ committee in
>> >spite of Stroustrup's reservations (leads to bad coding style...),[/color][/color]
>...[color=green][color=darkred]
>> >and that one of the strong arguments in favor of RTTI's adoption
>> >was that the underlying mechanisms where required by EH anyway ?[/color][/color]
>...[color=green]
>> Do you have any references for that rumour?[/color]
>
>I have no concrete information about what these 'reservations' were.
>But I remember reading about the common underlying mechanism in
>several instances.
>What a quick google search brings:
>
>Bruce Eckel's Thinking in C++, 2nd ed., Volume 2, Revision 2:
>About RTTI:
>"When exception handling was added to C++, it required the exact type
>information about objects. It became an easy next step to build access
>to that information into the language."
>http://nicolas.blancpain.free.fr/Doc...Chapter08.html[/color]

Don't rely on such rumors for technical or accurate information.

[color=blue]
>Some random web doc:[/color]

And don't rely on random web documents for what you only need
logic to resolve.

[color=blue]
>Nothing that authoritative indeed.[/color]

And don't rely on authority as a substitute for logic.

[color=blue]
>I don't have BS's D&E
>or his other books here to look for a quote.
>Maybe some committee member could help here...[/color]

Uh, again, don't rely on authority as a substitute for logic.

Hth.,

- Alf

**Rolf Magnus** · Jul 19 '05, 04:33 PM

Re: type_info, vtable

Risto Lankinen wrote:
[color=blue]
> Furthermore, exception handling uses compile-time types,
> not run-time (e.g. dynamic) types. Try this example:
>
> #include <iostream.h>
>
> struct Base
> {
> virtual ~Base()
> {
> }
> };
>
> struct Derived : public Base
> {
> };
>
> int main()
> {
> Base *p = new Derived;
>
> try
> {
> throw *p;
> }
> catch( const Derived & )
> {
> cout << "Derived" << endl;
> }
> catch( const Base & )
> {
> cout << "Base" << endl;
> }
> catch( ... )
> {
> cout << "<unknown>" << endl;
> }
>
> delete p;
>
> return 0;
> }
>
> This program prints "Base".[/color]

I guess that "throw *p;" actually creates a copy of the base class part
of the object (i.e. it slices it off) and throws that. That's why a
Base is caught instead of a Derived. Try this example instead:

#include <iostream>

using namespace std;

struct Base
{
virtual ~Base()
{
}
};

struct Derived : public Base
{
};

int main()
{
Derived d;

try
{
throw d;
}
catch( const Base & b)
{
cout << "reference to Base caught" << endl;
if (typeid(b) == typeid(Derived) )
cout << "but the actual class is Derived" << endl;
}
catch( ... )
{
cout << "not a base" << endl;
}

return 0;
}

type_info, vtable

type_info, vtable

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment