Re: C++ code compiles with libstdc++ but not libc++
Re: C++ code compiles with libstdc++ but not libc++
- Subject: Re: C++ code compiles with libstdc++ but not libc++
- From: Howard Hinnant <email@hidden>
- Date: Tue, 02 Oct 2012 13:54:32 -0400
On Oct 2, 2012, at 12:31 PM, Jean-Denis MUYS <email@hidden> wrote:
>
> On 2 oct. 2012, at 18:18, Howard Hinnant <email@hidden>
> wrote:
>
>> It is this:
>>
>> template< class T >
>> inline bool
>> operator!=( const T& x, const T& y )
>> {
>> return !( x == y );
>> }
>>
>> that is the trouble maker.
>>
>> Howard
>>
>
>
> Thanks,
>
> If I remove it, other parts of the library fail to compile (classes with no ancestors in the STL for example).
>
> Besides, I can't see any problem with this template function.
Technically, I think it may even be legal. However this probably isn't the last time it will cause you a problem. It will conflict with several C++11 library components including reverse_iterator, shared_ptr, unique_ptr, and probably more.
That being said, there is a way for me to make __wrap_iterator more attractive for vector<T>::iterator in libc++ and I will do that.
> Is there a way for me to resolve the ambiguity, for example by telling the compiler which implementation it should take in priority?
I can't think of a good/sane workaround for you at the moment, sorry.
Here's a slightly insane way of doing it: Add a trait (e.g. use_generic_relops) that defaults to false:
#include <type_traits>
template <class T>
struct use_generic_relops
: public std::false_type
{
};
Restrict your generic ops to those types where use_generic_relops<T>::value is true:
template< class T >
inline
typename std::enable_if
<
use_generic_relops<T>::value,
bool
>::type
operator!=( const T& x, const T& y )
{
return !( x == y );
}
And then for each type where you want to enable the generic operator, specialize the trait to be true:
class Other
{
public:
friend bool operator==(const Other&, const Other&)
{return true;}
};
template <>
struct use_generic_relops<Other>
: public std::true_type
{
};
I'm not sure that this is easier than just adding the extra 4 operators for Other though.
Historical context:
The standards committee tried this (a generic != operator) just before the C++98 standard. At the last minute they ran into the quagmire you now find yourself in. Instead of yanking the operator, it was put into namespace std::rel_ops with the theory that if someone really wanted to use it, they could "using namespace std::rel_ops;". It was subsequently realized that nobody could actually use it that way without the risk of exposing the ambiguity anyway. Now there's a running joke on the committee whenever we decide we need to get rid of a facility: should we deprecate it or just put it into namespace rel_ops? ;-)
Howard
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden