Re: conversion operator ambiguity
Your point is taken regarding the multiple assignment operators. My
example was not very well constructed either. But I get the same
error when I change int to double in the example. Why would the
compiler go to the trouble of trying to convert a double to a char?
But here is a little more context to what I was trying to do (all of
this to avoid the need for an explicit cast):
I have a variant class that holds a union of types (char const*, int,
double and a few other fundamental types). I allow the assignment of
the variant using std::string (in this case the char const* member of
the union will be set). So it is not unreasonable to ask for the
reverse assignment : variant to std::string.
So the relevant parts of my class might look like:
struct variant {
...
template<T>
operator T() const
{
return blah;
}
...
};
While this works for my fundamental types, it did not work for
std::string due to the existence of multiple string assignment
operators.
So I tried:
struct variant {
...
template<T>
operator T() const
{
return blah;
}
std::string operator() const
{
return blah;
}
...
};
This made no difference. Finally I tried enabling the template only
for fundamental types.
struct variant {
...
template<T>
operator typename boost::enable_if<is_fundamental<T>, T>::type()
const
{
return blah;
}
std::string operator() const
{
return blah;
}
...
};
While this assigns to std::string correctly, the assignments to
fundamental types no longer work. (And I have scoured this group site
for why SFINAE does not kick in for conversion operator function
templates. While that appears to be the case, I found no workarounds.)
thanks
On Feb 11, 12:17 pm, Seungbeom Kim <musip...@bawi.org> wrote:
On 2011-02-10 22:02, Ian Collins wrote:
Maybe the output from a more friendly compiler will help:
Such as STLFilt <http://www.bdsoft.com/tools/stlfilt.html>.
If you're not used to the cryptic diagnostics, it's worth trying.
Error: Overloading ambiguity between "std::string::operator=(const
std::string &)" and "std::string::operator=(char)".
In other words either conversion operator yields a type assignable to
std::string.
The problem is that std::string has assignment operators that take
either a std::string or a char, and int is convertible to char,
so either std::string or int fits in an assignment operator.
In this case, the cure is:
s = static_cast<std::string>(c);
This works because static_cast forces a context of construction,
and std::string has a constructor that takes a std::string but not
one that takes an integer type alone. (An assignment operator cannot
take multiple arguments anyway, but the committee probably felt that
it's safer for the constructor not to take a single integer type:
std::string::string(char) would allow things like 'string s = 42;'.)
Had std::string had a constructor that took a single integer type,
you could have used this last possible choice:
s = c.operator string();
Either of these solutions is not very elegant-looking. The example looks
very abstract and I don't know the exact context of your original problem,
but it could be better to replace conversion operators with normal named
functions (such as as_string(), as_int()) and ask for one explicitly:
s = c.as_string();
i = c.as_int();
Conversion operators always carry the risk of unwanted implicit
conversions, and you are advised to use them with caution, and
avoid them except when they make the most obvious sense.
If you have more than one of those, it means more risk and more caution.
--
Seungbeom Kim
[ Seehttp://www.gotw.ca/resources/clcm.htmfor info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]