about return type of an overloaded operator

[benben]

Given a class template Vector<>, I would like to overload operator +.
But I have a hard time deciding whether the return type should be
Vector<U> or Vector<V>, as in:
template <typename U, typename V>
Vector<U_or_V> operator+ (
const Vector<U>&,
const Vector<V>&);
Naturally, I would like U_or_V to be the type of (U() + V()), but,
pardon my limited knowledge, I have no idea how to achieve that.

Currently I am defaulting U_or_V just to U. But this has some subtle
implications. For example, the breach of the commutative law:

Vector<int> vi(0, 0, 0);
Vector<double> vd(1.1, 1.2, 1.3);

assert((vi + vd) == (vd + vi));

The above innocent code may not even compile depending on how operator==
is declared. If it did, it is again up to the details of operator== to
decide whether the assertion would succeed or fail. Ideally, both
addition expressions should give Vector<double> because (int() + double
()) is a double.

Any thought will be appreciated!

Ben

[Shark]

> The above innocent code may not even compile depending on how operator==

is declared. If it did, it is again up to the details of operator== to
decide whether the assertion would succeed or fail. Ideally, both
addition expressions should give Vector<double> because (int() + double
()) is a double.

if you are faced with a dilemma like this, consider how C++'s double
and int may behave in this situation. That helps keep code consistent
and you don't have to parse your mental design each time. Scott Meyer's
book Effective C++ has some insights on overloading. Try it at your
local B&N or Borders.

My 0.000002 cents!

[benben]

> if you are faced with a dilemma like this, consider how C++'s double

and int may behave in this situation. That helps keep code consistent
and you don't have to parse your mental design each time. Scott Meyer's
book Effective C++ has some insights on overloading. Try it at your
local B&N or Borders.

Thanks for your advices!

As to your first advice, please see that I did make an effort to keep
the semantic consistent with that with C++'s native types. This is
exactly why I want:

// pseudo C++ code
template <typename U, typename V>
Vector<typeof(U ()+V())> operator+ (
const Vector<U>&,
const Vector<V>&);

My problem is how to write typeof(U()+V()) in a way that the compiler
would understand. I have considered a traits class but specializations
will be endless in that case.

I will seriously consider your second advice.

Yours,
Ben

[Shark]

benben wrote:

if you are faced with a dilemma like this, consider how C++'s double
and int may behave in this situation. That helps keep code consistent
and you don't have to parse your mental design each time. Scott Meyer's
book Effective C++ has some insights on overloading. Try it at your
local B&N or Borders.

Thanks for your advices!

As to your first advice, please see that I did make an effort to keep
the semantic consistent with that with C++'s native types. This is
exactly why I want:

// pseudo C++ code
template <typename U, typename V>
Vector<typeof(U ()+V())> operator+ (
const Vector<U>&,
const Vector<V>&);

My problem is how to write typeof(U()+V()) in a way that the compiler
would understand. I have considered a traits class but specializations
will be endless in that case.

Ok, I'm a beginner too since the last 4 years or so!

How about you declare an abstract base class B from which U and V
derive, and in operator+ you can have a factory design pattern return
the appropriate type.

Once you have the type returned, you can then overload == to accept
parameters of type base B, which will therefore work in all cases, and
can do comparisons too. I think this should work.

Form wikipedia this is a sample factory pattern:

#include <memory>
using std::auto_ptr;

class Control { };

class PushControl : public Control { };

class Factory {
public:
// Returns Factory subclass based on classKey. Each
// subclass has its own getControl() implementation.
// This will be implemented after the subclasses have
// been declared.
static auto_ptr<Factor y> getFactory(int classKey);
virtual auto_ptr<Contro l> getControl() const = 0;
};

class ControlFactory : public Factory {
public:
virtual auto_ptr<Contro l> getControl() const {
return auto_ptr<Contro l>(new PushControl());
}
};

auto_ptr<Factor y> Factory::getFac tory(int classKey) {
// Insert conditional logic here. Sample:
switch(classKey ) {
default:
return auto_ptr<Factor y>(new ControlFactory( ));
}
}

[Alf P. Steinbach]

* benben:

My problem is how to write typeof(U()+V()) in a way that the compiler
would understand. I have considered a traits class but specializations
will be endless in that case.

Consider something like

template< unsigned Id > struct IdToType;
template<> struct IdToType<1> { typedef char T; };
template<> struct IdToType<2> { typedef unsigned char T; };
...

template< typename T > struct TypeToId;
template<> struct TypeToId<char> { enum{ id = 1 }; };
...

template< unsigned Id > struct MyTypeId { char sizer[Id]; };

template< typename T > MyTypeId< TypeToId<T>::id > typeOfArg( T );

template< typename U, typename V >
typename IdToType<sizeof (typeOfArg(U()+ V()).sizer)>::T
operator+( U const& u, V const& v )
{
...
}

I don't know whether it'll work as written.

But I think it better that you use the time to check it all out with a
compiler, than that I should do that... ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Shark]

Shark wrote:

How about you declare an abstract base class B from which U and V
derive, and in operator+ you can have a factory design pattern return
the appropriate type.

I forgot to add, that B should be a wrapper around your types. It makes
sense to me, if I understand the problem correctly.

[John Carson]

"benben" <be******@yahoo .com.au> wrote in message
news:43******** **************@ news.optusnet.c om.au

Given a class template Vector<>, I would like to overload operator +.
But I have a hard time deciding whether the return type should be
Vector<U> or Vector<V>, as in:
template <typename U, typename V>
Vector<U_or_V> operator+ (
const Vector<U>&,
const Vector<V>&);
Naturally, I would like U_or_V to be the type of (U() + V()), but,
pardon my limited knowledge, I have no idea how to achieve that.

Currently I am defaulting U_or_V just to U. But this has some subtle
implications. For example, the breach of the commutative law:

Vector<int> vi(0, 0, 0);
Vector<double> vd(1.1, 1.2, 1.3);

assert((vi + vd) == (vd + vi));

The above innocent code may not even compile depending on how
operator== is declared. If it did, it is again up to the details of
operator== to decide whether the assertion would succeed or fail.
Ideally, both addition expressions should give Vector<double> because
(int() + double ()) is a double.

Any thought will be appreciated!

Ben

The obvious, though somewhat laborious, solution is to specialize the
template for particular (U,V) combinations. Make U the return type in the
general case, and make it V (or perhaps something else --- say complex if U
is real and V is imaginary) for the special cases that need it.

Thus you have the general:

template <class U, class V>
Vector<U> operator+ (const Vector<U>&, const Vector<V>&);

and the specialized:

template <>
Vector<double> operator+ (const Vector<int>&, const Vector<double>& );
Somewhat more elegant would be to define an extra class to indicate the
return type. You can make that class depend on U and V. First we define
the usual case where Vector<U> is satisfactory as the return type.

template<class U, class V>
struct ReturnType
{
typedef Vector<U> type;
};

You can then specialize this for mixed cases that need special handling,
e.g.,

template<>
struct ReturnType<int, double>
{
typedef Vector<double> type;
};
To illustrate its use, consider:
#include <iostream>
using namespace std;

template<class T>
class Vector;

template<class U, class V>
struct ReturnType
{
typedef Vector<U> type;
};

template<>
struct ReturnType<int, double>
{
typedef Vector<double> type;
};
template<class T>
class Vector
{
T array[3];
public:
template<class U, class V>
friend typename ReturnType<U,V> ::type
operator+(const Vector<U>&, const Vector<V>&);
Vector()
{
array[0]=T();
array[1]=T();
array[2]=T();
}
Vector(T first, T second, T third)
{
array[0] = first;
array[1] = second;
array[2] = third;
}
T operator[](int index) const
{
return array[index];
}
T &operator[](int index)
{
return array[index];
}
};

template <class U, class V>
typename ReturnType<U,V> ::type
operator+(const Vector<U>&lhs, const Vector<V>&rhs)
{
typename ReturnType<U,V> ::type sum;
sum[0] = lhs[0]+rhs[0];
sum[1] = lhs[1]+rhs[1];
sum[2] = lhs[2]+rhs[2];
return sum;
}

int main()
{
Vector<int> i(4,2,5);
Vector<double> d(1.2, 2.4, 7.2);

Vector<double> result = i+d;

cout << result[0] << ',' << result[1] << ',' << result[2] << '\n';
return 0;
}
--
John Carson

[andy]

benben wrote:

Given a class template Vector<>, I would like to overload operator +.
But I have a hard time deciding whether the return type should be
Vector<U> or Vector<V>, as in:
template <typename U, typename V>
Vector<U_or_V> operator+ (
const Vector<U>&,
const Vector<V>&);
Naturally, I would like U_or_V to be the type of (U() + V()), but,
pardon my limited knowledge, I have no idea how to achieve that.

Seriously take a look at Boost.Typeof typeof emulation in the latest
version of the boost libraries. It is very comprehensive and great for
just this situation.

Useage would be something like:

template <typename U, typename V>
Vector< BOOST_TYPEOF_TP L(U() + V())> operator+ (
const Vector<U>&,
const Vector<V>&);

You may have to do some work to 'register' U and V though Boost.Typeof
can make use of compiler extensions in some cases too. 'registration'
is covered in the documentation. There are some differences between use
with templates and non_templates too, but its probably the nearest to
true language support.

Check it out.

regards
Andy Little

[benben]

Alf P. Steinbach wrote:

* benben:

My problem is how to write typeof(U()+V()) in a way that the compiler
would understand. I have considered a traits class but specializations
will be endless in that case.

Consider something like

template< unsigned Id > struct IdToType;
template<> struct IdToType<1> { typedef char T; };
template<> struct IdToType<2> { typedef unsigned char T; };
...

template< typename T > struct TypeToId;
template<> struct TypeToId<char> { enum{ id = 1 }; };
...

template< unsigned Id > struct MyTypeId { char sizer[Id]; };

template< typename T > MyTypeId< TypeToId<T>::id > typeOfArg( T );

Thanks for your reply alf! But I am very confused with the code,
especially the line immediately above.

template< typename U, typename V >
typename IdToType<sizeof (typeOfArg(U()+ V()).sizer)>::T
operator+( U const& u, V const& v )
{
...
}

I don't know whether it'll work as written.
It will take some time before I can fully digest the code above. I am
under the impression this method relies on type size to work out the
resultant type. Please pardon my impoliteness but I don't see the above
could select, for example, double from a int-double pair.

But I think it better that you use the time to check it all out with a
compiler, than that I should do that... ;-)

Thank you! I will.

Ben

[Alf P. Steinbach]

* benben:

Alf P. Steinbach wrote:

* benben:

My problem is how to write typeof(U()+V()) in a way that the compiler
would understand. I have considered a traits class but specializations
will be endless in that case.

Consider something like

template< unsigned Id > struct IdToType;
template<> struct IdToType<1> { typedef char T; };
template<> struct IdToType<2> { typedef unsigned char T; };
...

template< typename T > struct TypeToId;
template<> struct TypeToId<char> { enum{ id = 1 }; };
...

template< unsigned Id > struct MyTypeId { char sizer[Id]; };

template< typename T > MyTypeId< TypeToId<T>::id > typeOfArg( T );

Thanks for your reply alf! But I am very confused with the code,
especially the line immediately above.

It's meant to be a function, not implemented anywhere, returning a
struct where the size of that struct's 'sizer' identifies the argument
type. This struct is then passed to sizeof (so that the function is
never actually called), the result of sizeof used to obtain the type
from TypeToId mapping. The point being that you only have to define
O(n) type mapping classes for n supported types, instead of O(n^2).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?