Re: std::max(unsigned, size_t), amd64 and C++0x
Gabriel Dos Reis ha scritto:
Alberto Ganesh Barbati <AlbertoBarbati@libero.it> writes:
|
| I think I found a better case, which, I believe, could actually be
| considered a defect in the current wording. Consider this:
|
| using Dur1 = std::time_duration<int>;
| using Dur2 = std::time_duration<unsigned>;
|
| Dur1 d1(-1);
| Dur2 d2(0);
|
| assert(d1 > d2); // ??? should be the opposite!
Yes, but this code looks very dubious to me. Reading the code leads
me to ask more questions than I would if the code were comparing
values of the same type. For me, that plays against readability.
Readable codes should be dull, and maintainable codes should not
require excessive cleverness.
Of course the code is dubious, it's a stripped down example! I don't
expect any user to write that. The fact is that time_duration<> promises
to be very clever about choosing automatically the representation type
and the period, yet it stumble on the mixed sign case. Let's make a real
life example, then. Suppose you have a vector of time points, with a
resolution of one second, stored as longs:
using my_time_points
= std::time_point<std::high_resolution_clock,
std::time_duration<long>>;
std::vector<my_time_points> v;
/* fill v with values */
std::sort(v.begin(), v.end());
to see in which interval we are now, we might use this:
auto it = std::lower_bound(v.begin(), v.end(),
std::high_resolution_clock::now());
that looks very nice and I challenge you to say that this code is not
readable. We don't even need to know the period of the clock, the code
performs all conversions automatically... but here's the pitfall: the
representation type of high_resolution_clock is unspecified and could
well be an unsigned type. On the other hand, our vector v might contain
a time point with a negative time_since_epoch() (it's uncommon, but
there is nothing wrong with it). In this case, the code will produce a
wrong result, without providing any meaningful diagnostic and it's not
obvious how to change the code to get it right.
| This is because common_type<int, unsigned>::type is unsigned, so
| common_type<Dur1, Dur2>::type is Dur2. operator< converts both arguments
| to the common type (i.e. Dur2) but when you convert d1 to Dur2 the
| integer -1 is converted to 2^n-1 for some n, which is greater than 0.
For me that speaks more against common_type, than a killer argument to
put common_type and the mixed max() in the standard library.
Just to be clear: I do *not* propose to add the mixed max to the
library. That example was there just to answer a specific question of
the OP. On the other hand, common_type is *already* in the draft (as it
was voted in Sophia), but the current wording is broken in my opinion.
You actually seem to agree with me when you say "that speaks more
against common_type" because my sentence was precisely about a problem
with the current wording. With my post, I am just proposing one possible
way to fix it.
Ganesh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]