Re: Conversion operators: different behaviour for built-in types
"Igor Tandetnik" wrote:
There is a whole bunch of templated operator== implementations in scope. When deducing template parameters from arguments, user-defined conversions are not considered, and so none of them match.
On the other hand, a built-in == operator is treated essentially as a non-template function for the purposes of overloading resolution, and can accept user-defined conversions.
I forgot that
....bool operator ==(const ...string<...>&, const ...string<...>&)
....bool operator ==(const charT*, const ...string<...>&)
....bool operator ==(const ...string<...>&, const charT*)
are all templates.
Why do you want to make it work? What are you trying to achieve? Is there any practical purpose for this?
For this particular case, instead of a conversion operator, you could define three overloads of operator==, taking (Sref, string), (string, Sref) and (Sref, Sref).
I had this implementation in mind:
class Message {
typedef std::map<int, std::string> Fields;
public:
class Fref;
//...
Fref operator [](int tag);
const std::string& operator [](int tag) const;
private:
std::string m_empty;
Fields m_fields;
};
class Message::Fref {
friend class Message;
Message& message;
int tag;
Fref(Message& m, int t) : message(m), tag(t) {}
Fref(const Fref& r) : message(r.message), tag(r.tag) {}
void operator =(const Fref&);
public:
operator const std::string&() const { return const_cast<const
Message&>(message)[tag]; }
void operator =(const std::string& v) { if (!v.empty())
message[tag] = v; }
};
inline Message::Fref Message::operator [](int tag)
{
return Fref(*this, tag);
}
inline const std::string& Message::operator [](int tag) const
{
Fields::const_iterator p = m_fields.find(tag);
return p != m_fields.end() ? p->second : m_empty;
}
and the idea, as in Stroustrup, was to use different semantics to read and
to write. Reading would just return a const std::string& to field data whilst
writing would check the value to write was not empty and would perform some
calculations (not shown) on the field being added or modified.
Thank you, Igor.