Conversion Operator in Template Class

[joecook]

Hmm... Why doesn't this work and use the conversion operator? (It
doesn't compile)

template<typename T>
class Foo
{
};

template<typename T>
void bar(Foo<T>& a){}

template<typename T>
class Goo
{
public:
operator Foo<U>(){return m_foo;}

Foo<U> m_foo;
};

int main()
{
Goo<float> g;
bar(g); // why doesn't this convert to Foo<U> ??
}

Thanks

 

[joecook]

Victor said:
Because the Standard prohibits it.  When deducing template arguments
from a function call, the conversions are not applied to the function
arguments.

Is there any way to get similar capability that you know of? What if
i wanted to have a class that behaved in everyway as say a
std::vector<T>, but I didn't want to inherit from std::vector<T> ? I
still want to pass this new class to functions that accept
std::vector<T>

Joe C

 

[SG]

Because the Standard prohibits it.  When deducing template arguments
from a function call, the conversions are not applied to the function
arguments.

In addition: The conversion would result in an rvalue which is not
allowed to bind to an lvalue reference to non-const.

Cheers!
SG

 

[James Kanze]

Hmm... Why doesn't this work and use the conversion operator?
(It doesn't compile)

template<typename T>
class Foo
{
};

template<typename T>
void bar(Foo<T>& a){}

template<typename T>
class Goo
{
public:
operator Foo<U>(){return m_foo;}

What's U?

Foo<U> m_foo;

Same question?

};

int main()
{
Goo<float> g;
bar(g); // why doesn't this convert to Foo<U> ??
}

Your class template Goo shouldn't compile, since there is no
symbol U defined anywhere. If you replace the U with T, it
still won't compile, because the compiler doesn't know which
specialization of bar to use, and it can't do overload
resolution before bar has been specialized.

 

[James Kanze]

Not in templates; you'd have to be explicit, and introduce a cast or a
function, like "as_vector":

template<class T> class Goo {
...
Foo<T>& as_Foo() { return m_foo; }
};

Goo<float> g;
bar(g.as_Foo());

. I am not sure why such requirements are imposed, probably
to allow compilers actually be reasonable with respect to time
they take to compile templates.

If by reasonable, you mean finite, yes. If you allowed all of
the conversions allowed for non template functions, in some
cases, you would end up with an infinite set of possibilities to
evaluate.

Imagine how many functions/class would have to be instantiated
if the compiler started applying all possible conversions,
especially in the cases with built-in types...

Type deduction always yields a single function (for a given
function template). What you would likely end up in such cases
is a large number of equally good choices, which no way to
choose (ambiguous), or in some extreme cases, the necessity to
check an infinite set of possibilities just in case one was
better.