We've now had a user request that could be solved by adding a BOOST_NO_RTTI macro, that (when set) would disable Boost's use of constructs that use run-time type information (dynamic_cast, typeid, etc.), similar to our BOOST_NO_EXCEPTIONS. http://lists.boost.org/MailArchives/boost-users/msg09240.php I'll plan to add it unless there is violent disagreement. Doug
Douglas Gregor wrote:
We've now had a user request that could be solved by adding a BOOST_NO_RTTI macro, that (when set) would disable Boost's use of constructs that use run-time type information (dynamic_cast, typeid, etc.), similar to our BOOST_NO_EXCEPTIONS.
http://lists.boost.org/MailArchives/boost-users/msg09240.php
I'll plan to add it unless there is violent disagreement.
I thought BOOST_NO_XXX macros, where XXX is as standard C++ feature, were supposed to be _detection_ macros (?) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Jan 7, 2005, at 10:01 AM, David Abrahams wrote:
Douglas Gregor wrote:
We've now had a user request that could be solved by adding a BOOST_NO_RTTI macro, that (when set) would disable Boost's use of constructs that use run-time type information (dynamic_cast, typeid, etc.), similar to our BOOST_NO_EXCEPTIONS.
http://lists.boost.org/MailArchives/boost-users/msg09240.php
I'll plan to add it unless there is violent disagreement.
I thought BOOST_NO_XXX macros, where XXX is as standard C++ feature, were supposed to be _detection_ macros (?)
Okay, so let's have BOOST_NO_RTTI defined when the compiler/environment does not support RTTI, and we can use it to turn off use of RTTI in some Boost components :) But Peter is right, there are macros here... perhaps BOOST_NO_RTTI and BOOST_NO_DYNAMIC_RTTI, with the former implying the latter. Doug
Well, my last reply does not seem to get through... ----- Original Message ----- From: "Doug Gregor" <dgregor@cs.indiana.edu> Newsgroups: gmane.comp.lib.boost.devel Sent: Friday, January 07, 2005 10:42 AM Subject: Re: Re: BOOST_NO_RTTI?
On Jan 7, 2005, at 10:01 AM, David Abrahams wrote:
Douglas Gregor wrote:
We've now had a user request that could be solved by adding a BOOST_NO_RTTI macro, that (when set) would disable Boost's use of constructs that use run-time type information (dynamic_cast, typeid, etc.), similar to our BOOST_NO_EXCEPTIONS.
http://lists.boost.org/MailArchives/boost-users/msg09240.php
I'll plan to add it unless there is violent disagreement.
I thought BOOST_NO_XXX macros, where XXX is as standard C++ feature, were supposed to be _detection_ macros (?)
Okay, so let's have BOOST_NO_RTTI defined when the compiler/environment does not support RTTI, and we can use it to turn off use of RTTI in some Boost components :)
Well, I think that we should first ensure we never uses RTTI if we don't need it so if it is possible to determine it at compile-time, we should then uses specialization for each case (RTTI needed and RTTI not needed). In that case if we try to uses the specialization that require RTTI and RTTI is not enabled, we should force a compile-time assertion. If RTTI is uses for some optimizations but is not strictly necessary, then we should not used it if it is not available (as we can determine from compiler specific defines). Finally, my compiler only giving me a warning (CodeWarrior when using boost::function with RTTI disabled). It might be good to add a comment in the code and a note in the documentation that explain why RTTI is used and the effect of turning it off. Also, the program seems to run correctly when I try it. Philippe
On Jan 7, 2005, at 8:25 PM, Philippe Mori wrote:
Finally, my compiler only giving me a warning (CodeWarrior when using boost::function with RTTI disabled). It might be good to add a comment in the code and a note in the documentation that explain why RTTI is used and the effect of turning it off. Also, the program seems to run correctly when I try it.
I'm guessing that you aren't actually using RTTI anywhere (because you probably haven't called the type() or target() member functions of boost::function), although you compiler complains because it will see one "typeid" use in the code (in dead code, but it can't tell that). Doug
Okay, so let's have BOOST_NO_RTTI defined when the compiler/environment does not support RTTI, and we can use it to turn off use of RTTI in some Boost components :)
But Peter is right, there are macros here... perhaps BOOST_NO_RTTI and BOOST_NO_DYNAMIC_RTTI, with the former implying the latter.
Sounds reasonable to me, but do we ever use RTTI in non-dynamic situations anyway? John.
John Maddock wrote:
Okay, so let's have BOOST_NO_RTTI defined when the compiler/environment does not support RTTI, and we can use it to turn off use of RTTI in some Boost components :)
But Peter is right, there are macros here... perhaps BOOST_NO_RTTI and BOOST_NO_DYNAMIC_RTTI, with the former implying the latter.
Sounds reasonable to me, but do we ever use RTTI in non-dynamic situations anyway?
I don't know, but Boost.Python could be set up to use a reduced set of capabilities when only "static" RTTI was available. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Jan 8, 2005, at 6:00 AM, John Maddock wrote:
Okay, so let's have BOOST_NO_RTTI defined when the compiler/environment does not support RTTI, and we can use it to turn off use of RTTI in some Boost components :)
But Peter is right, there are macros here... perhaps BOOST_NO_RTTI and BOOST_NO_DYNAMIC_RTTI, with the former implying the latter.
Sounds reasonable to me, but do we ever use RTTI in non-dynamic situations anyway?
Well, Function does. You can get the static type of the target function object. Doug
John Maddock wrote:
Okay, so let's have BOOST_NO_RTTI defined when the compiler/environment does not support RTTI, and we can use it to turn off use of RTTI in some Boost components :)
But Peter is right, there are macros here... perhaps BOOST_NO_RTTI and BOOST_NO_DYNAMIC_RTTI, with the former implying the latter.
Sounds reasonable to me, but do we ever use RTTI in non-dynamic situations anyway?
We do. get_deleter<> only needs typeid(T), for instance.
Douglas Gregor wrote:
We've now had a user request that could be solved by adding a BOOST_NO_RTTI macro, that (when set) would disable Boost's use of constructs that use run-time type information (dynamic_cast, typeid, etc.), similar to our BOOST_NO_EXCEPTIONS.
http://lists.boost.org/MailArchives/boost-users/msg09240.php
I'll plan to add it unless there is violent disagreement.
There are two types of "no RTTI". Everything except dynamic_cast and typeid on polymorphic types works; or everything involving RTTI fails in compile time. The practical difference is that there is code that works on the first type of "no RTTI" (get_deleter, function<>::target) and fails on the second.
participants (6)
-
David Abrahams -
Doug Gregor -
Douglas Gregor
-
John Maddock -
Peter Dimov -
Philippe Mori