Why is the return type of count_if() "signed" rather than "unsigned"?
in [C++]
|
Prev: Why is the return type of count_if() "signed" rather than "unsigned"?
Next: Accessor Functions (getter) for C String (Character Array) Members
From: Daniel Krügler on 22 Jun 2010 23:08 On 23 Jun., 01:32, xmllmx <xml...(a)gmail.com> wrote: > As we know, count_if() will never return a negative number. So, it > seems evident that the return type of count_if() should be "unsigned > integral type" rather than existing "signed integral type". I agree, from the perspective of an algorithm without any relation to the iterator concept in C++, an unsigned return type would be more adequate for these kind of functions. > However, to my surprise, the C++ standard should define the return > type is "signed integer type", which causes a lot of conceptual > confusions and annoying compiling warnings such as "signed/unsigned > mismatch". > > What's the rationale for the C++ standard committee to do so ? The rationale is that the iterator requirements don't have any unsigned type as part of it's associated types (available via std::iterator_traits). They only have type difference_type, which is a signed type (which makes sense). You could argue, that this is a design-weakness of the iterator concept and there is some truth in that. On the other side you can easily work-around this limitation with the new type trait std::make_unsigned from the <type_traits> header (see the FCD draft). The latter trait did not exist when the algorithm count[_if] became part of the standard library, so the current state is mostly based on the history of the standard library of C++.[1] HTH & Greetings from Bremen, Daniel Kr�gler [1] Interestingly the original inability to express the return type of count and count_if was the actual reason to invent the iterator_traits. Looking backward it is amusing to observe that it was considered as less relevant to have an unsigned return type at that time. To be fair, for iterator types, the difference_type is more often needed than an unsigned "size_type". -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Daniel Krügler on 24 Jun 2010 09:38
On 24 Jun., 12:59, Pedro Lamar�o <pedro.lama...(a)ccppbrasil.org> wrote: > Daniel Kr gler wrote: > > [1] Interestingly the original inability to express the return > > type of count and count_if was the actual reason to invent the > > iterator_traits. Looking backward it is amusing to observe that > > it was considered as less relevant to have an unsigned return > > type at that time. To be fair, for iterator types, the difference_type > > is more often needed than an unsigned "size_type". > > Where can we find reference to an iterator type for which it is _not_ > appropriate to return size_t from std::count and std::count_if? What about an iterator type with a difference_type equal to std::intmax_t from header <cstdint> ? There is no guarantee that size_t can represent all positive values of this type, but std::intmax_t would still satisfy the requirements for iterator_traits<>::difference_type and those of the Container requirements. Similarly there is no guarantee that std::size_t has a sufficiently large value range that is OK for all Container types. HTH & Greetings from Bremen, Daniel Kr�gler -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |