[serialization] Patch : Borland workarounds for shared_ptr_132.hpp

The following patches compile for bcc 0x564 - I don't have a version of the library built to link against to verify the run time nature of the test. cvs diff -w shared_ptr_132.hpp (in directory D:\Projects\boost\boost\serialization\detail) Index: shared_ptr_132.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/serialization/detail/shared_ptr_132.hpp,v retrieving revision 1.2 diff -w -r1.2 shared_ptr_132.hpp 42a43,44
#if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) )
43a46
#endif 123a127,130 #if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) template<class Y> explicit shared_ptr(Y * p): px(p), pn(p, boost::checked_deleter<Y>()) // Y must be complete #else 125a133 #endif
and cvs diff -w shared_count_132.hpp (in directory D:\Projects\boost\boost\serialization\detail) Index: shared_count_132.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/serialization/detail/shared_count_132.hpp,v retrieving revision 1.1 diff -w -r1.1 shared_count_132.hpp 46a47,48
#if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) )
47a50
#endif 86a90 #if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) 87a92 #endif 92a98,100 #if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) typedef boost::detail::lightweight_mutex mutex_type; #else 93a102 #endif
-- AlisdairM

Hmmm, before I paste this in, I'm wondering a little. shared_ptr_132.hpp is different from shared_ptr.hpp in version 1.32 in that it uses a null deleter. Its not clear to me that this change doesn't nullify this feature. This feature is key to being able to recover 1.32 pointers and convert them to the new setup. Robert Ramey AlisdairM wrote:
The following patches compile for bcc 0x564 - I don't have a version of the library built to link against to verify the run time nature of the test.
cvs diff -w shared_ptr_132.hpp (in directory D:\Projects\boost\boost\serialization\detail) Index: shared_ptr_132.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/serialization/detail/shared_ptr_132.hpp,v retrieving revision 1.2 diff -w -r1.2 shared_ptr_132.hpp 42a43,44
#if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) )
43a46
#endif 123a127,130 #if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) template<class Y> explicit shared_ptr(Y * p): px(p), pn(p, boost::checked_deleter<Y>()) // Y must be complete #else 125a133 #endif
and
cvs diff -w shared_count_132.hpp (in directory D:\Projects\boost\boost\serialization\detail) Index: shared_count_132.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/serialization/detail/shared_count_132.hpp,v retrieving revision 1.1 diff -w -r1.1 shared_count_132.hpp 46a47,48
#if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) )
47a50
#endif 86a90 #if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) 87a92 #endif 92a98,100 #if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) typedef boost::detail::lightweight_mutex mutex_type; #else 93a102 #endif

Robert Ramey wrote:
Hmmm, before I paste this in, I'm wondering a little. shared_ptr_132.hpp is different from shared_ptr.hpp in version 1.32 in that it uses a null deleter. Its not clear to me that this change doesn't nullify this feature. This feature is key to being able to recover 1.32 pointers and convert them to the new setup.
Not sure I understand correctly here. If you are referring to my using checked_deleter, all I did was qualify the existing detail::checked_deleter as boost::checked_deleter. If this was supposed to be a null deleter, I would check the code in CVS. For reference, the Borland workarounds consisted of removing 2 "using namespace boost;" statements inside namespace boost_132, and then adding an explicit boost:: qualifier on the front of the couple of names that were being dragged in from the global boost namespace. I did not change any other functionality. It is possible you were expecting name-lookup to resolve more symbols in the boost namespace, but I only found these 2 or 3. AlisdairM

Hmm I patched these in but now my test_shrare_ptr_132 doesn't compile. I'm can't see what we're doing differently. Robert Ramey AlisdairM wrote:
The following patches compile for bcc 0x564 - I don't have a version of the library built to link against to verify the run time nature of the test.
cvs diff -w shared_ptr_132.hpp (in directory D:\Projects\boost\boost\serialization\detail) Index: shared_ptr_132.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/serialization/detail/shared_ptr_132.hpp,v retrieving revision 1.2 diff -w -r1.2 shared_ptr_132.hpp 42a43,44
#if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) )
43a46
#endif 123a127,130 #if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) template<class Y> explicit shared_ptr(Y * p): px(p), pn(p, boost::checked_deleter<Y>()) // Y must be complete #else 125a133 #endif
and
cvs diff -w shared_count_132.hpp (in directory D:\Projects\boost\boost\serialization\detail) Index: shared_count_132.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/serialization/detail/shared_count_132.hpp,v retrieving revision 1.1 diff -w -r1.1 shared_count_132.hpp 46a47,48
#if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) )
47a50
#endif 86a90 #if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) 87a92 #endif 92a98,100 #if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) typedef boost::detail::lightweight_mutex mutex_type; #else 93a102 #endif

Robert Ramey wrote:
Hmm I patched these in but now my test_shrare_ptr_132 doesn't compile. I'm can't see what we're doing differently.
Can you post the compiler errors you are seeing? [I presume it is only the Borland compiler failing still, as I protected all updates with BOOST_WORKAROUND tests] -- AlisdairM

Borland C++ 5.6 for Win32 Copyright (c) 1993, 2002 Borland c:\BoostMainCVS\libs\serialization\test\test_shared_ptr_132.cpp: Error E2238 C:\BoostMainCVS\boost/serialization/detail/shared_count_132.hpp 75: Multiple declaration for 'bad_weak_ptr' Error E2344 C:\BoostMainCVS\boost/detail/bad_weak_ptr.hpp 39: Earlier declaration of 'bad_weak_ptr' Error E2238 C:\BoostMainCVS\boost/serialization/detail/shared_count_132.hpp 95: Multiple declaration for 'sp_counted_base' Error E2344 C:\BoostMainCVS\boost/detail/sp_counted_base_w32.hpp 36: Earlier declaration of 'sp_counted_base' Error E2238 C:\BoostMainCVS\boost/serialization/detail/shared_count_132.hpp 320: Multiple declaration for 'shared_count' Error E2228 C:\BoostMainCVS\boost/serialization/detail/shared_count_132.hpp 320: Too many error or warning messages *** 6 errors in Compile *** AlisdairM wrote:
Robert Ramey wrote:
Hmm I patched these in but now my test_shrare_ptr_132 doesn't compile. I'm can't see what we're doing differently.
Can you post the compiler errors you are seeing?
[I presume it is only the Borland compiler failing still, as I protected all updates with BOOST_WORKAROUND tests]
correct Robert Ramey

Robert Ramey wrote:
Borland C++ 5.6 for Win32 Copyright (c) 1993, 2002 Borland
c:\BoostMainCVS\libs\serialization\test\test_shared_ptr_132.cpp:
Error E2238 C:\BoostMainCVS\boost/serialization/detail/shared_count_132.hpp 75: Multiple declaration for 'bad_weak_ptr'
Error E2344 C:\BoostMainCVS\boost/detail/bad_weak_ptr.hpp 39: Earlier declaration of 'bad_weak_ptr'
Error E2238 C:\BoostMainCVS\boost/serialization/detail/shared_count_132.hpp 95: Multiple declaration for 'sp_counted_base'
Error E2344 C:\BoostMainCVS\boost/detail/sp_counted_base_w32.hpp 36: Earlier declaration of 'sp_counted_base'
Error E2238 C:\BoostMainCVS\boost/serialization/detail/shared_count_132.hpp 320: Multiple declaration for 'shared_count'
Error E2228 C:\BoostMainCVS\boost/serialization/detail/shared_count_132.hpp 320: Too many error or warning messages
*** 6 errors in Compile ***
Strange, those are the exact same errors I was getting *before* I applied the patch. Can you confirm that the first workaround in shared_count_132.hpp looks like this: namespace boost_132 { #if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) using namespace boost; #endif Note the unsual '!' in the BOOST_WORKAROUND test. I am compiling against the latest CVS repositoy, and it appears fine to me. See my reply to Tobias for the precise cause of the problem. But basically we have to remove all 'using namespace boost' directives from the Borland view of the files. If you have any more usings on your local copy, they might be the cause an need similar wrapping. -- AlisdairM

I used patch in merger your patch into my copy. I've also checked that I have on line 44: #if !BOOST_WORKAROUND( _BORLANDC_, BOOST_TESTED_AT( 0x564) ) using namespace boost; #endif Note the ! I got my free borland 5.6? from a borland website. I'm really sure whether I should have 0x564 or ox560 above. Hmm - a mystery to me. Robert Ramey AlisdairM wrote:
Robert Ramey wrote:
Borland C++ 5.6 for Win32 Copyright (c) 1993, 2002 Borland
c:\BoostMainCVS\libs\serialization\test\test_shared_ptr_132.cpp:
Error E2238 C:\BoostMainCVS\boost/serialization/detail/shared_count_132.hpp 75: Multiple declaration for 'bad_weak_ptr'
Error E2344 C:\BoostMainCVS\boost/detail/bad_weak_ptr.hpp 39: Earlier declaration of 'bad_weak_ptr'
Error E2238 C:\BoostMainCVS\boost/serialization/detail/shared_count_132.hpp 95: Multiple declaration for 'sp_counted_base'
Error E2344 C:\BoostMainCVS\boost/detail/sp_counted_base_w32.hpp 36: Earlier declaration of 'sp_counted_base'
Error E2238 C:\BoostMainCVS\boost/serialization/detail/shared_count_132.hpp 320: Multiple declaration for 'shared_count'
Error E2228 C:\BoostMainCVS\boost/serialization/detail/shared_count_132.hpp 320: Too many error or warning messages
*** 6 errors in Compile ***
Strange, those are the exact same errors I was getting *before* I applied the patch.
Can you confirm that the first workaround in shared_count_132.hpp looks like this:
namespace boost_132 {
#if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) using namespace boost; #endif
Note the unsual '!' in the BOOST_WORKAROUND test.
I am compiling against the latest CVS repositoy, and it appears fine to me.
See my reply to Tobias for the precise cause of the problem. But basically we have to remove all 'using namespace boost' directives from the Borland view of the files. If you have any more usings on your local copy, they might be the cause an need similar wrapping.

Robert Ramey wrote:
I used patch in merger your patch into my copy. I've also checked that I have on line 44:
#if !BOOST_WORKAROUND( BORLANDC, BOOST_TESTED_AT( 0x564) ) using namespace boost; #endif
Note the !
I got my free borland 5.6? from a borland website. I'm really sure whether I should have 0x564 or ox560 above.
Hmm - a mystery to me.
OK, now you have committed to CVS I can see the problem <g> The __BORLANDC__ macro that is tested for should have two underscores either side, i.e. _ _ B O R L A N D C _ _ The version in CVS uses singe underscores, so will not be detected. I suspect this will be an artefact of newsreaders or email clients. I know mine 'helpfully' translates underscores into requests to underline instead, so I guess we need to be extra careful when handling these identifiers in mailed code. AlisdairM

"AlisdairM" <alisdair.meredith@uk.renaultf1.com> writes:
Robert Ramey wrote:
I used patch in merger your patch into my copy. I've also checked that I have on line 44:
#if !BOOST_WORKAROUND( BORLANDC, BOOST_TESTED_AT( 0x564) ) using namespace boost; #endif
Note the !
I got my free borland 5.6? from a borland website. I'm really sure whether I should have 0x564 or ox560 above.
Hmm - a mystery to me.
OK, now you have committed to CVS I can see the problem <g>
The __BORLANDC__ macro that is tested for should have two underscores either side, i.e. _ _ B O R L A N D C _ _
The version in CVS uses singe underscores, so will not be detected.
I suspect this will be an artefact of newsreaders or email clients. I know mine 'helpfully' translates underscores into requests to underline instead, so I guess we need to be extra careful when handling these identifiers in mailed code.
Generally speaking, mailing code as an attachment prevents these sorts of 'helpful' substitutions. -- Dave Abrahams Boost Consulting www.boost-consulting.com

AlisdairM wrote:
Robert Ramey wrote:
Hmm I patched these in but now my test_shrare_ptr_132 doesn't compile. I'm can't see what we're doing differently.
Can you post the compiler errors you are seeing?
[I presume it is only the Borland compiler failing still, as I protected all updates with BOOST_WORKAROUND tests]
Feel free to ask me if you need some testing -- I currently have a little BCC farm installed (5.5.0, 5.5.1, 5.6.4, 5.6.5). Regards, Tobias

Tobias Schwinger wrote:
Feel free to ask me if you need some testing -- I currently have a little BCC farm installed (5.5.0, 5.5.1, 5.6.4, 5.6.5).
Thanks. The Borland bug we are trying to work around can be seen in the following example: namespace A { struct duplicate {}; } namespace B { using namespace A; struct duplicate {}; } The compiler will erroneously complain that B::duplicate is a redefinition of A::duplicate. In this case, the using namesspace boost; inside namespace boost_132 is causing duplicates of the shared_ptr classes, which are #included inside Test library. The patch I gave yesterday solved the problem for me, I am not sure why it does not work for Robert. I am now looking for more places I might have missed namespace using directives. If you can apply my patch and try the shared_ptr_132 tests, I'd be interested in the results. -- AlisdairM

AlisdairM wrote:
Tobias Schwinger wrote:
Feel free to ask me if you need some testing -- I currently have a little BCC farm installed (5.5.0, 5.5.1, 5.6.4, 5.6.5). <snip>
namespace A { struct duplicate {}; }
namespace B { using namespace A; struct duplicate {}; }
This code breaks with 5.5.0, 5.5.1, 5.6.4, and 5.6.5. My guess is that it breaks with Kylix and older versions too. Regards, Tobias
participants (4)
-
AlisdairM
-
David Abrahams
-
Robert Ramey
-
Tobias Schwinger