[exception] Patch to improve support of CodeGear C++Builder 2009

[Nicola Musatti]

The attached patch fixes workarounds for the latest CodeGear (ex Borland) compiler.

[Emil Dotchevski]

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]

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]

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

[Nicola Musatti]

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]

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]

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]

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]

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