Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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 |
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 | Next — Previous in thread | Find similar
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