[shared_ptr][exception] Support for disabled RTTI
Using boost with RTTI disabled was recently discussed on the user list, and I had a quick look into it. It seems that shared_ptr added support for the BOOST_NO_TYPEID macro in 1.35: http://svn.boost.org/trac/boost/ticket/1108 But because it now depends on the new exception library, which requires RTTI, it no longer works. Would it be possible to support the macro in Boost.Exception? Daniel
The exception library uses std::type_info objects as keys for accessing the values transported by boost::exception objects, and that's where typeid is needed. It is possible to disable the data-transporting functionality only, leaving the exception_ptr functionality available even with BOOST_NO_TYPEID, but compilers need some RTTI functionality to implement exception handling so I am not sure if an exception handling library makes sense at all when RTTI is disabled. I think the best option is to #define BOOST_EXCEPTION_DISABLE if BOOST_NO_TYPEID is defined. What is the correct way to do this, or should I directly #ifdef based on either BOOST_EXCEPTION_DISABLE / BOOST_NO_TYPEID? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode On Tue, Jul 1, 2008 at 7:46 AM, Daniel James <daniel_james@fmail.co.uk> wrote:
Using boost with RTTI disabled was recently discussed on the user list, and I had a quick look into it. It seems that shared_ptr added support for the BOOST_NO_TYPEID macro in 1.35:
http://svn.boost.org/trac/boost/ticket/1108
But because it now depends on the new exception library, which requires RTTI, it no longer works. Would it be possible to support the macro in Boost.Exception?
Daniel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 01/07/2008, Emil Dotchevski <emil@revergestudios.com> wrote:
It is possible to disable the data-transporting functionality only, leaving the exception_ptr functionality available even with BOOST_NO_TYPEID, but compilers need some RTTI functionality to implement exception handling so I am not sure if an exception handling library makes sense at all when RTTI is disabled.
Exceptions seem to work in g++ with RTTI disabled.
I think the best option is to #define BOOST_EXCEPTION_DISABLE if BOOST_NO_TYPEID is defined.
This seems very disruptive. If that's the only solution then, at this stage in the release cycle, it might be better to just leave things as they are and live with the regression (it's for an undocumented feature, so I don't think it's a show stopper). Daniel
On Tue, Jul 1, 2008 at 1:53 PM, Daniel James <daniel_james@fmail.co.uk> wrote:
On 01/07/2008, Emil Dotchevski <emil@revergestudios.com> wrote:
It is possible to disable the data-transporting functionality only, leaving the exception_ptr functionality available even with BOOST_NO_TYPEID, but compilers need some RTTI functionality to implement exception handling so I am not sure if an exception handling library makes sense at all when RTTI is disabled.
Exceptions seem to work in g++ with RTTI disabled.
Catch needs to discriminate between different exception types in a way similar to dynamic_cast, except that unlike dynamic_cast, it needs to work for objects of non-polymorphic types as well. That's what I was referring to.
I think the best option is to #define BOOST_EXCEPTION_DISABLE if BOOST_NO_TYPEID is defined.
This seems very disruptive. If that's the only solution then, at this stage in the release cycle, it might be better to just leave things as they are and live with the regression (it's for an undocumented feature, so I don't think it's a show stopper).
It seems pretty straight forward to me, my only question was what's the right way to do this since I don't know much about configuring Boost. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
2008/7/1 Emil Dotchevski <emil@revergestudios.com>:
On Tue, Jul 1, 2008 at 1:53 PM, Daniel James <daniel_james@fmail.co.uk> wrote:
Exceptions seem to work in g++ with RTTI disabled.
Catch needs to discriminate between different exception types in a way similar to dynamic_cast, except that unlike dynamic_cast, it needs to work for objects of non-polymorphic types as well. That's what I was referring to.
Sorry if my email wasn't very clear. I was just pointing out that exceptions work with the -fno-rtti compile option, which is what BOOST_NO_TYPEID supports. So disabling exceptions when it's defined might be the wrong thing to do. The situation might be different for other compilers. You'll know better than me.
I think the best option is to #define BOOST_EXCEPTION_DISABLE if BOOST_NO_TYPEID is defined.
This seems very disruptive. If that's the only solution then, at this stage in the release cycle, it might be better to just leave things as they are and live with the regression (it's for an undocumented feature, so I don't think it's a show stopper).
It seems pretty straight forward to me
But doesn't it change the behaviour of any library which uses your library? That's why I said it seems disruptive.
my only question was what's the right way to do this since I don't know much about configuring Boost.
Well, I'm no expert on this. I agree that if you've disabled exceptions, you probably should define BOOST_DISABLE_EXCEPTIONS. If someone uses it badly (checking for it in a header without first including your headers) it could cause an ODR violation, but that's a minor concern. You could possibly have two separate macros - one user settable one which tells Boost.Exception to disable exceptions, and one which Boost.Exception sets when exceptions are disabled or aren't available. But that's probably too complicated, no one would ever know which one to use. Also, looking at Boost.Config, there are user settable options to which BOOST_DISABLE_EXCEPTIONS could be added (since it's fairly universal): http://www.boost.org/doc/libs/1_35_0/libs/config/doc/html/index.html#boost_c... Daniel
2008/7/2 Daniel James <daniel_james@fmail.co.uk>:
It seems pretty straight forward to me
But doesn't it change the behaviour of any library which uses your library? That's why I said it seems disruptive.
Sorry, I just took another look at your library - and I realized that BOOST_EXCEPTION_DISABLE doesn't do what I thought it does. I'd assumed that it disabled exceptions but I now see that it doesn't. Ignore everything I wrote, what you suggested is very sensible. And you probably should define it. Daniel
Would it be useful (or correct) to add the following to config/compiler/visualc.hpp: // // check for RTTI support: #ifndef _CPPRTTI # define BOOST_NO_TYPEID #endif (eg around line 106, after the test for exceptions) ? I'm using MSVC 7.1 (SP1) with STLport 5.1.5 (latest) - With the new Boost.Exception I get a drizzle of C4541 warnings. I don't want to force BOOST_NO_TYPEID in config/user.hpp because some projects do have RTTI. re
on Sun Aug 17 2008, rasmus ekman <m11048-AT-abc.se> wrote:
Would it be useful (or correct) to add the following to config/compiler/visualc.hpp:
// // check for RTTI support: #ifndef _CPPRTTI # define BOOST_NO_TYPEID #endif
(eg around line 106, after the test for exceptions) ?
I'm using MSVC 7.1 (SP1) with STLport 5.1.5 (latest)
- With the new Boost.Exception I get a drizzle of C4541 warnings. I don't want to force BOOST_NO_TYPEID in config/user.hpp because some projects do have RTTI.
Looks good to me; maybe you should add a patch against Boost.Config to http://svn.boost.org/trac/boost. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
rasmus ekman:
Would it be useful (or correct) to add the following to config/compiler/visualc.hpp:
// // check for RTTI support: #ifndef _CPPRTTI # define BOOST_NO_TYPEID #endif
(eg around line 106, after the test for exceptions) ?
I'm using MSVC 7.1 (SP1) with STLport 5.1.5 (latest)
No, because MSVC 7.1 does have typeid in no-RTTI mode. That is why the macro is called BOOST_NO_TYPEID, not BOOST_NO_RTTI.
participants (5)
-
Daniel James -
David Abrahams -
Emil Dotchevski -
Peter Dimov -
rasmus ekman