What runtime support is needed for RTTI?

From what I understand RTTI is implemented via some larger V-Table, containing some type_id instance.

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Zeljko Vrba Sent: Wednesday, August 13, 2008 10:43 To: boost-users@lists.boost.org Subject: Re: [Boost-users] [exception] RTTI On Wed, Aug 13, 2008 at 10:25:58AM -0600, peter_foelsche@agilent.com wrote:

I don't see any possible reason to disable RTTI

How about, for example, developing code for an embedded platform which does not provide the necessary run-time support? _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Emil Dotchevski schrieb:

To disable the Boost Exception integration in boost::throw_exception, #define BOOST_EXCEPTION_DISABLE. Because Boost Exception requires RTTI, #defining BOOST_NO_TYPEID has the same effect.

I.e. it disables the use of Boost::Exception, but exceptions are still thrown? The documentation does not state whether defining BOOST_EXECPTION_DISABLE will have any ill effects on the rest of Boost, just that boost::throw_exception will fall back to plain throw. Cheers, Anteru

Emil Dotchevski wrote:

A small piece of Boost Exception is integrated in boost::throw_exception, so any Boost library that throws exceptions introduces this dependency by default.

To disable the Boost Exception integration in boost::throw_exception, #define BOOST_EXCEPTION_DISABLE. Because Boost Exception requires RTTI, #defining BOOST_NO_TYPEID has the same effect.

Hmmm, so how does Boost exception behave on systems which don't support RTTI? That is, can one assume that it's functionality will degrade gracefully in environments where RTTI is not supported? Robert Ramey

Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

Emil Dotchevski schrieb:

Isn't this a rare configuration anyway, that disables RTTI but enables exceptions? I mean, some form of RTTI is needed for exception handling anyway so it's not completely turned off as long as exceptions are enabled.

Well, with VC++ at least, you can have exceptions without enabling RTTI. If you have your own RTTI rolled out, having the standard RTTI enabled is not that useful (for example, MFC comes with a custom RTTI implementation). Cheers, Anteru

Emil Dotchevski:

On Wed, Aug 13, 2008 at 12:48 PM, Anteru wrote:

...

Emil Dotchevski schrieb:

...

Isn't this a rare configuration anyway, that disables RTTI but enables exceptions? I mean, some form of RTTI is needed for exception handling anyway so it's not completely turned off as long as exceptions are enabled.

Well, with VC++ at least, you can have exceptions without enabling RTTI. If you have your own RTTI rolled out, having the standard RTTI enabled is not that useful (for example, MFC comes with a custom RTTI implementation).

You may disable RTTI as much as you want, if you enable exception handling, something like typeid is in ur code, catching ur eksepshons. :)

In practice, the reason to disable RTTI is simple: it leads to smaller executables. Most of the size penalty comes from the typeid().name() strings, which need to be emitted conservatively for every polymorphic type. Even on compilers such as MSVC that use type string comparisons to allow exceptions to be caught across a DLL boundary, type strings only need to be emitted for every base class of the operand of throw when RTTI is off.

On Thu, Aug 14, 2008 at 10:56 AM, Anteru wrote:

Peter Dimov schrieb:

...

In practice, the reason to disable RTTI is simple: it leads to smaller executables. Most of the size penalty comes from the typeid().name() strings, which need to be emitted conservatively for every polymorphic type.

Some numbers: I enabled RTTI testwise now, and my binaries are now 10% larger. (800 -> 880 kb). I had previously only exceptions enabled, but no RTTI. Compiler is VC9/x64

RTTI does have overhead, but if you want to use Boost Exception you have to enable RTTI. It uses it because it needs it. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Wed, Aug 13, 2008 at 2:32 PM, Robert Ramey wrote:

Emil Dotchevski wrote:

...

Isn't this a rare configuration anyway,

Why does it matter whether its rare or not?

...

that disables RTTI but enables exceptions? I mean, some form of RTTI is needed for exception handling anyway

I don't see this, could you expand up this?

...

so it's not completely turned off as long as exceptions are enabled.

what's not completely turned off? RTTI?. what does "completely" mean here?

What I mean is that even if you turn RTTI off, as long as exceptions are enabled, some (most?) RTTI functionality remains enabled because it is needed for catch() to do its magic. This is why the argument that it's a rare configuration has some merit.

If I understand correctly, the "old" exception didn't require this - now all programs which which don't use RTTI but use Boost Exception are now broken. Am I wrong here?

If either BOOST_NO_TYPEID or BOOST_EXCEPTION_DISABLE is defined, throw_exception.hpp reverts to its pre-1.36 behavior that does not require typeid. This does not disable exception handling, only disables Boost Exception, which is a new library introduced in 1.36. As it is now, an old program that disables RTTI can not take advantage of Boost Exception. I guess the confusion stems from the name of the BOOST_EXCEPTION_DISABLE define. Unfortunately it's too late to rename it in time for the 1.36 release. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Thu, Aug 14, 2008 at 9:53 AM, Robert Ramey wrote:

Emil Dotchevski wrote:

...

I guess the confusion stems from the name of the BOOST_EXCEPTION_DISABLE define. Unfortunately it's too late to rename it in time for the 1.36 release.

I understand that. Can it be adjusted in the next version so that the new features the require RTTI are enabled only if BOOST_NO_RTTI is not defined but that it still works for the rest of us. Or do we have to sprinkle our own #ifdef .. through our our code? Or now make our own private copy of boost::exception to fix this?

Boost Exception has two main components: - The ability to transport arbitrary data to the catch site, as demonstrated here: http://svn.boost.org/svn/boost/trunk/libs/exception/doc/tutorial_transportin.... This requires RTTI. - The ability to transport exceptions between threads, as explained here: http://svn.boost.org/svn/boost/trunk/libs/exception/doc/tutorial_exception_p.... In principle, this does not require RTTI but at this time it can not be enabled independently. This can be fixed in a future release. Does this answer your question? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode