Boost C++ Libraries: Ticket #2343: [exception] Patch to improve support of CodeGear C++Builder 2009

attachment set

Nicola Musatti — Thu, 18 Sep 2008 22:21:55 GMT

attachment → boost_exception.patch

Emil Dotchevski — Thu, 18 Sep 2008 22:38:21 GMT

With this patch applied, what is the status of the tests from libs/exception/test on CodeGear?

If those tests don't pass, then instead of this patch, boost/throw_exception.hpp should be modified to disable Boost Exception on this compiler, by implicitly defining BOOST_EXCEPTION_DISABLE just like it is currently done for MSVC < 7.1 and BCC.

Nicola Musatti — Thu, 18 Sep 2008 22:46:35 GMT

Replying to emildotchevski:

With this patch applied, what is the status of the tests from libs/exception/test on CodeGear?

If those tests don't pass, then instead of this patch, boost/throw_exception.hpp should be modified to disable Boost Exception on this compiler, by implicitly defining BOOST_EXCEPTION_DISABLE just like it is currently done for MSVC < 7.1 and BCC.

My current results show 9 failures for CodeGear's 6.1.0 and 18 failures for the last Borland release, 5.9.3 . I can't say at this time whether there's any hope for improvement.

Emil Dotchevski — Thu, 18 Sep 2008 23:04:28 GMT

Replying to nmusatti:

Replying to emildotchevski:

With this patch applied, what is the status of the tests from libs/exception/test on CodeGear?

If those tests don't pass, then instead of this patch, boost/throw_exception.hpp should be modified to disable Boost Exception on this compiler, by implicitly defining BOOST_EXCEPTION_DISABLE just like it is currently done for MSVC < 7.1 and BCC.

My current results show 9 failures for CodeGear's 6.1.0 and 18 failures for the last Borland release, 5.9.3 . I can't say at this time whether there's any hope for improvement.

My gut feeling tells me that there isn't hope for improvement, but you're welcome to give it a try.

Otherwise, let me know how to detect CodeGear 6.1.0 in boost/throw_exception.hpp (or you can directly post a patch for boost/throw_exception.hpp that #defines BOOST_EXCEPTION_DISABLE on CodeGear.)

attachment set

Nicola Musatti — Sat, 20 Sep 2008 13:31:01 GMT

attachment → boost_exception2.patch

attachment set

Nicola Musatti — Sat, 20 Sep 2008 13:31:12 GMT

attachment → exception_ptr.patch

attachment set

Nicola Musatti — Sat, 20 Sep 2008 13:31:26 GMT

attachment → libs_exception.patch

Nicola Musatti — Sat, 20 Sep 2008 13:39:48 GMT

Replying to emildotchevski:

Replying to nmusatti:

My current results show 9 failures for CodeGear's 6.1.0 and 18 failures for the last Borland release, 5.9.3 . I can't say at this time whether there's any hope for improvement.

My gut feeling tells me that there isn't hope for improvement, but you're welcome to give it a try.

Otherwise, let me know how to detect CodeGear 6.1.0 in boost/throw_exception.hpp (or you can directly post a patch for boost/throw_exception.hpp that #defines BOOST_EXCEPTION_DISABLE on CodeGear.)

With the updated patches I just uploaded the failures go down to 5 for CodeGear.

As it is I'd prefer these patches to be applied rather than have the library disabled, so as to pinpoint the remaining problems. Should we get requests to the contrary from users it wouldn't be too complicated to backout.

Note that I have commit rights so I can help with actually applying the changes.

Peter Dimov — Sat, 20 Sep 2008 15:42:49 GMT

With regards to

return typename exception_detail::enable_error_info_return_type<T>::type(x);

I'd suggest

typedef typename exception_detail::enable_error_info_return_type<T>::type Rt;
return Rt(x);

instead of yet another config macro.

Also, <string.h> should have a ::memcpy, why would one need to use the std:: one?

Nicola Musatti — Sat, 20 Sep 2008 17:07:01 GMT

Replying to pdimov:

With regards to

return typename exception_detail::enable_error_info_return_type<T>::type(x);

I'd suggest
typedef typename exception_detail::enable_error_info_return_type<T>::type Rt;
return Rt(x);
instead of yet another config macro.

Well, the config macro is already there and its use documents the presence of a workaround, but I agree that your approach is cleaner. Anyway, I have no strong opinion either way. Emil, let me know which approach you prefer.

Also, <string.h> should have a ::memcpy, why would one need to use the std:: one?

That's the bug for which I'm providing that workaround. The definition in the global namespace isn't seen by the compiler.

Emil Dotchevski — Mon, 22 Sep 2008 18:37:43 GMT

nmusatti, Trunk revision 48918 should address all issues but please test with CodeGear because my changes differ from your patch. Thanks for helping with this and thanks to Peter Dimov for the typedef suggestion.

I did not put in your workarounds for libs/exception/test because I wanted you to try them without defining the tag types. For example, intead of:

13	#if BOOST_WORKAROUND(__CODEGEARC__, BOOST_TESTED_AT(0x610))
14	struct my_tag {};
15	#endif

could you try:

13	#if BOOST_WORKAROUND(__CODEGEARC__, BOOST_TESTED_AT(0x610))
14	struct my_tag;
15	#endif

Thanks, Emil

anonymous — Mon, 22 Sep 2008 19:57:59 GMT

Replying to emildotchevski:

nmusatti, Trunk revision 48918 should address all issues but please test with CodeGear because my changes differ from your patch. Thanks for helping with this and thanks to Peter Dimov for the typedef suggestion.

Your changes work; all relevant tests still pass.

I did not put in your workarounds for libs/exception/test because I wanted you to try them without defining the tag types. For example, intead of:
13	#if BOOST_WORKAROUND(__CODEGEARC__, BOOST_TESTED_AT(0x610))
14	struct my_tag {};
15	#endif
could you try:
13	#if BOOST_WORKAROUND(__CODEGEARC__, BOOST_TESTED_AT(0x610))
14	struct my_tag;
15	#endif

Unfortunately just declaring the tag structs isn't enough; tests fail with linker errors.

Cheers, Nicola

status changed; resolution set

Emil Dotchevski — Mon, 22 Sep 2008 22:55:23 GMT

status new → closed
resolution → fixed