Re: common_type result dependent on order or template parameters
Howard Hinnant ha scritto:
On Jul 5, 9:34 am, Chris Fairles <chris.fair...@gmail.com> wrote:
struct C { }:
struct B : C { };
struct A : C { };
It is intended that clients who wish for common_type<A, B> to be well
defined to define it themselves:
namespace std
{
template <>
struct common_type<A, B> {typedef C type;};
template <> struct common_type<B, A>
: public common_type<A, B> {};
} // std
Now this client can ask for common_type<A, B, C> in any order (and get
the same answer).
Mmm... Let's forget the order for a moment. The problem I see is that
one might expect common_type<A,B>::type to be C without any intervention
from the user, but the current specification doesn't grant that. All in
all, both A and B are implicitly convertible to C. Is the expectation
wrong? Maybe. common_type<> is designed as a framework for deducing
common types of value-type classes (like arithmetic types, duration<>,
etc.) used in mathematical computations. Values of the source types are
expected to be exactly representable in the common type, so that
operations in the common type don't involve a loss of information.
common_type wasn't meant to traverse class hierarchies. In fact I would
dare say that there might be sense in requiring that common_type<A,
C>::type should also be ill-formed, rather than be C, because the
implicit conversion from A to C might involve slicing and so it might
cause a loss of information. The principle of exact representation would
be violated.
However, when we come to pointers, things are a bit different. Consider
the case common_type<A*,B*>::type. Shouldn't it be C*? I would say yes,
in this case, but the current specification make it ill-formed.
The fact is that the default implementation of common_type<T,U> returns
the common type between T and U only if it either T or U (after
promotions). That is good for arithmetics types, but it's not for
pointers. Requiring the user to provide explicitly all pointer
conversions seems a bit too much to me.
I fear that if we require common_type to go to extraordinary means
such as the search of an N! solution space, compile times will swell
unacceptably.
I definitely agree on this point.
Ganesh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]