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

X-Received	by 10.66.251.163 with SMTP id zl3mr456394pac.39.1369842602731; Wed, 29 May 2013 08:50:02 -0700 (PDT)
MIME-Version	1.0
Path	csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!c5no37757868pbj.1!news-out.google.com!d5ni20474pbl.0!nntp.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date	Wed, 29 May 2013 10:50:02 -0500
Return-Path	<cppmods@mcgurn.dreamhost.com>
Sender	std-cpp-request@vandevoorde.com
Approved	stephen.clamage@oracle.com
Message-ID	<ko4e1k$a8l$1@dont-email.me> (permalink)
Newsgroups	comp.std.c++
From	Daniel Krügler <daniel.kruegler@googlemail.com>
Subject	Re: why not to define std::common_type<int32_t, uint32_t>::type as int64_t?
Organization	A noiseless patient Spider
References	<0bc7c923-085e-4089-b10a-78f022b41ff7@googlegroups.com>
X-Original-Date	Wed, 29 May 2013 10:29:43 +0200
X-Submission-Address	std-cpp-submit@vandevoorde.com
To	undisclosed-recipients:;
Date	Wed, 29 May 2013 10:43:05 CST
Lines	40
X-Usenet-Provider	http://www.giganews.com
X-Trace	sv3-TgbFvCna24lgs6LCsj9NnLdIyTVUEnibPvYx9rME1/OLh9TXCF2EBdtXLvHGpwOo//ztrtKEAJOfQqz!NrW7THpGJ//cj20Wj7ut9TtOReS+wOz607w/eUvpf23J3EvRjNM=
X-Complaints-To	abuse@giganews.com
X-DMCA-Notifications	http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info	Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info	Otherwise we will be unable to process your complaint properly
X-Postfilter	1.3.40
X-Original-Bytes	3005
Content-Type	text/plain; charset=ISO-8859-1; format=flowed
Xref	csiph.com comp.std.c++:628

Show key headers only | View raw

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                      ]

Back to comp.std.c++ | Previous | Next — Previous in thread | Next 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