Probably one reason would be that we would
need to do it by hand (i.e., it could not
be inferred from the the ternary operator)

  However, defining std::common_type<int32_t, uint32_t>::type as
int64_t seems to be more consistent for me.

   Am I missing something?

              walter.


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 2013-05-29 09:45, Walter Mascarenhas wrote:
>    Probably one reason would be that we would
> need to do it by hand (i.e., it could not
> be inferred from the the ternary operator)
>
>    However, defining std::common_type<int32_t, uint32_t>::type as
> int64_t seems to be more consistent for me.
>
>     Am I missing something?

std::common_type was intentionally defined in terms of a rather simple
rule based on operator?:. This rule *is* consistent, because it reflects
how the core language works. If you don't like it, just define your own
form of common_type that matches better your intentions. You are neither
required to use std::common_type nor do you need to use it directly. For
example std::duration_cast uses a more complex logic to deduce a
reasonable guess for an effective common type:

"Let CF be ratio_divide<Period, typename ToDuration::period>, and CR be
common_type<typename ToDuration::rep, Rep, intmax_t>::type"

You could (for example) provide your own extended common_type_ext trait
that is built on top of std::common_type (or not at all) and that
attempts to impose further constraints such as attempting to return a
type that always has a larger value representation compared to the
operands or that attempts to impose such rules at least for
unsigned/signed type combinations.

HTH & Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In general, the Subject: header should be a summary of what's in your
message, it should not be the sole location where a key part of your
message is written.

On 05/29/2013 03:45 AM, Walter Mascarenhas wrote:

[from Subject: why not to define std::common_type<int32_t,
uint32_t>::type as int64_t?]

>   Probably one reason would be that we would
> need to do it by hand (i.e., it could not
> be inferred from the the ternary operator)

Yes, that strikes me as a very strong reason.

>   However, defining std::common_type<int32_t, uint32_t>::type as
> int64_t seems to be more consistent for me.

Consistent with what? The definition as it is currently written is
consistent with the way ?: works, which, for arithmetic types, boils
down to being consistent with the way the usual arithmetic conversions
work. That's how it was intended to be, and that's what it should be,
for the purposes for which it was designed.

>    Am I missing something?

Well, one thing your question is missing is an argument supporting your
proposed change. "it seems more consistent for me" is not an argument,
at least, not unless it's supplemented by an explanation of the
consistency issue you perceive.

Why should this one particular case be the only exception to the rules
that govern all other type pairs? Why shouldn't a similar exception
apply to std::common_type<int16_t, uint16_t>::type, or
std::common_type<int_least32_t, uint_least32_t>::type? I think that if
you have any half-way plausible reason that applies to your case, it
should also apply to one or the other of those two.

Furthermore, if there is a good reason to make an exception, doesn't
that reason apply equally strongly to the usual arithmetic conversions?
If so, the right way to fix this would be to change the usual arithmetic
conversions; a change to the result of std::common_type<> would
automatically follow.



--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]