[optional] mixed (optional<T>, T)-operator== missing by design?
Hi, In 1.33.1, comparing an optional<T> to it's T fails, since although T implicitly converts to optional<T>, op== being templated, implicit conversions are not considered. Is this by design? If so, what's the rationale for this? I repeatedly find myself in the need to compare an optional<T> member to a passed in T, e.g. in a setT( const T & ), in order to check for a no-op operation and suppress notifications in this case, e.g.: class Foo { boost::optional<T> mT; boost::signal< void(const optional<T>&) > tChangedSignal; void setT( const T & t ) { if ( t == mT ) return; mT = t; tChangedSignal( mT ); // mark cached values dirty, etc, etc... } }; -- Marc Mutz -- marc@klaralvdalens-datakonsult.se, mutz@kde.org Klarälvdalens Datakonsult AB, Platform-independent software solutions
Wouldn't the following work? if( t && *t == mT ) Pablo Aguilar Marc Mutz wrote:
Hi,
In 1.33.1, comparing an optional<T> to it's T fails, since although T implicitly converts to optional<T>, op== being templated, implicit conversions are not considered. Is this by design? If so, what's the rationale for this? I repeatedly find myself in the need to compare an optional<T> member to a passed in T, e.g. in a setT( const T & ), in order to check for a no-op operation and suppress notifications in this case, e.g.:
class Foo { boost::optional<T> mT; boost::signal< void(const optional<T>&) > tChangedSignal; void setT( const T & t ) { if ( t == mT ) return; mT = t; tChangedSignal( mT ); // mark cached values dirty, etc, etc... } };
On Tuesday 14 March 2006 11:13, Pablo Aguilar wrote:
Wouldn't the following work?
if( t && *t == mT )
I guess if ( mT && t == *mT ) would, yes, but what's the point of using deep comparison in the first place, then? I could just use a pointer instead. Granted, optional<> is more efficient (no heap allocation), and I only need to check the incoming. Hmm, come to think of it, maybe the correct thing to do would be to have setT() take an optional<T> const&... Implicit conversion would kick in and the relational operators would be sufficient. So, it can most easily be arranged to work. Still, it would be nice if there was a sentence about this in the design rationale. Thanks, Marc -- Marc Mutz -- marc@klaralvdalens-datakonsult.se, mutz@kde.org Klarälvdalens Datakonsult AB, Platform-independent software solutions
participants (2)
-
Marc Mutz -
Pablo Aguilar