[bind] Borland 2006 patch

The following workaround needs to be updated for BCB2006. Note I have also switched T const to const T. This does not show up in any of the regression tests, but should make a difference (to Borland) when T is a reference type. Don't ask!! cvs diff -u -wb -- boost\ref.hpp (in directory E:\sourceforge\devel\boost\) Index: boost/ref.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/ref.hpp,v retrieving revision 1.23 diff -u -w -b -r1.23 ref.hpp --- boost/ref.hpp 28 Nov 2004 03:20:58 -0000 1.23 +++ boost/ref.hpp 27 Feb 2006 07:57:50 -0000 @@ -54,7 +54,7 @@ T* t_; }; -# if defined(__BORLANDC__) && (__BORLANDC__ <= 0x570) +# if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT(0x581) ) # define BOOST_REF_CONST # else # define BOOST_REF_CONST const @@ -65,9 +65,9 @@ return reference_wrapper<T>(t); } -template<class T> inline reference_wrapper<T const> BOOST_REF_CONST cref(T const & t) +template<class T> inline reference_wrapper< const T > BOOST_REF_CONST cref(const T & t) { - return reference_wrapper<T const>(t); + return reference_wrapper< const T >(t); // Test this with const T before submitting patch } # undef BOOST_REF_CONST -- AlisdairM

AlisdairM wrote:
The following workaround needs to be updated for BCB2006. Note I have also switched T const to const T. This does not show up in any of the regression tests, but should make a difference (to Borland) when T is a reference type. Don't ask!!
T can't be a reference type in this context, as it's being deduced from a T const & t parameter.
-template<class T> inline reference_wrapper<T const> BOOST_REF_CONST cref(T const & t) +template<class T> inline reference_wrapper< const T > BOOST_REF_CONST cref(const T & t) {

AlisdairM wrote:
Peter Dimov wrote:
T can't be a reference type in this context, as it's being deduced from a T const & t parameter.
Is that true for the Borland compiler as well? ;?)
I've never encountered a Borland compiler that would deduce a reference type for T in this context.

Peter Dimov wrote:
I applied this part of your patch; for the rest, I'd rather wait for a test case.
Thanks, and a fair request. Since I discovered add_const< add_ref< T > > produces a different type to add_ref< add_const< T > > on this compiler, I have a defensive coding practice of preferring const T over T const. The former should always produce a valid C++ type, the latter is strange with references. I will see if I can produce a test case for this specific example, or if my alarm bells are simply ringing in a lase alarm. -- AlisdairM

Since I discovered add_const< add_ref< T > > produces a different type to add_ref< add_const< T > > on this compiler, I have a defensive coding practice of preferring const T over T const. The former should always produce a valid C++ type, the latter is strange with references.
Just in case you hadn't realised: add_const< add_ref< T > > and add_ref< add_const< T > > *should* produce different results :-) John.

John Maddock wrote:
Just in case you hadn't realised: add_const< add_ref< T > > and add_ref< add_const< T > > should produce different results :-)
I took the ::type as read ;?) Unless that is not what you are referring to, in which case I really do need educating! i.e: I assume the following are the same type (and not just equivalent) typedef typename add_ref< add_const< T > >::type ref_const_t; typedef typename add_const< add_ref< T > >::type const_ref_t; -- AlisdairM

On Tue, 28 Feb 2006 12:42:01 +0000 (UTC), "AlisdairM" <alisdair.meredith@uk.renaultf1.com> wrote:
John Maddock wrote:
Just in case you hadn't realised: add_const< add_ref< T > > and add_ref< add_const< T > > should produce different results :-)
I took the ::type as read ;?)
Unless that is not what you are referring to, in which case I really do need educating!
i.e: I assume the following are the same type (and not just equivalent)
typedef typename add_ref< add_const< T > >::type ref_const_t;
Should give const T&
typedef typename add_const< add_ref< T > >::type const_ref_t;
Should give T& If I am right, both types are different regards, Zara

AlisdairM wrote:
John Maddock wrote:
Just in case you hadn't realised: add_const< add_ref< T > > and add_ref< add_const< T > > should produce different results :-)
I took the ::type as read ;?)
Unless that is not what you are referring to, in which case I really do need educating!
i.e: I assume the following are the same type (and not just equivalent)
typedef typename add_ref< add_const< T > >::type ref_const_t; typedef typename add_const< add_ref< T > >::type const_ref_t;
add_ref( add_const( int ) ) == int const & add_const( add_ref( int ) ) == int & const == int &

Peter Dimov wrote:
add_ref( add_const( int ) ) == int const & add_const( add_ref( int ) ) == int & const == int &
Thanks for all the replies and my re-education <g> Spend too long hanging around the wrong compiler, and I guess it is inevitable to pick up some bad habits. Well, that's my excuse and I'm sticking to it ;?) -- AlisdairM

Unless that is not what you are referring to, in which case I really do need educating!
Adding a cv-qualifier to a reference type has no effect: typedef int& ref; typdef const ref cref; here ref and cref are actually the same type. The bug in Borland's compiler is that the above produces "int&const" for cref which is *not* a legal type in the C++ type system and is distinct from "const int&". This is in contrast to pointers, where "int*const" is a legal type (and distinct from "int const*"). So: add_const<add_reference<int>::type>::type is "int&" add_reference<add_const<int>::type::type is "const int &" John.

AlisdairM wrote:
i.e: I assume the following are the same type (and not just equivalent)
typedef typename add_ref< add_const< T > >::type ref_const_t; typedef typename add_const< add_ref< T > >::type const_ref_t;
Ok, I REALLY need to get a better proof-reader: I assume the following are the same type (and not just equivalent) typedef typename add_ref< add_const< T >::type >::type ref_const_t; typedef typename add_const< add_ref< T >::type >::type const_ref_t; Instead I get 2 distinct types with all Borland compiler I have access to: T const & T & const The latter does not look like a valid C++ type to me, and I have recently filed a bug report with Borland about this. I am sure they would like to hear I am wrong, and their compiler is correct ;?) --- AlisdairM

AlisdairM wrote:
typedef typename add_ref< add_const< T > >::type ref_const_t; typedef typename add_const< add_ref< T > >::type const_ref_t;
Aren't these types T const & and T& const Which aren't equivelant (for T& const, the const is unnecessary IIUC)? But I'm easily confused so my jump out of this conversation now! Cheers Russell
participants (5)
-
AlisdairM
-
John Maddock
-
Peter Dimov
-
Russell Hind
-
Zara