Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c++ > #629

Re: why not to define std::common_type<int32_t, uint32_t>::type as int64_t?

Message-ID <51A63919.8060400@verizon.net> (permalink)
Newsgroups comp.std.c++
From James Kuyper <jameskuyper@verizon.net>
Subject Re: why not to define std::common_type<int32_t, uint32_t>::type as int64_t?
Organization Self
References <0bc7c923-085e-4089-b10a-78f022b41ff7@googlegroups.com>
Date 2013-05-30 13:57 -0600

Show all headers | View raw


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                      ]

Back to comp.std.c++ | Previous | NextPrevious in thread | Find similar


Thread

why not to define std::common_type<int32_t, uint32_t>::type as int64_t? Walter Mascarenhas <walter.mascarenhas@googlemail.com> - 2013-05-29 01:45 -0600
  Re: why not to define std::common_type<int32_t, uint32_t>::type as int64_t? Daniel Krügler <daniel.kruegler@googlemail.com> - 2013-05-29 10:43 -0600
  Re: why not to define std::common_type<int32_t, uint32_t>::type as  int64_t? James Kuyper <jameskuyper@verizon.net> - 2013-05-30 13:57 -0600

csiph-web