Why is the return type of count_if() "signed" rather than "unsigned"?
in [C++]
|
Prev: a bit of reflection (doesn't work)
Next: Why is the return type of count_if() "signed" rather than "unsigned"?
From: xmllmx on 22 Jun 2010 15:26 { Please include some quoting to establish the context. -mod } I want to know why rather than what and how. Much to my surprise, why does not the C++ standard define the return type as "unsigned integral type"? What's the fundamental reason to define it as "signed"? distance() may return negative number, it is imaginable. However, I cannot imagine count() returns a negative number. So, it is rather counterintuitive that its return type is "signed". Code illustration will be highly appreciated. Thanks. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Pedro Lamarão on 23 Jun 2010 19:59 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? -- P. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Pedro Lamarão on 25 Jun 2010 17:23
Alf P. Steinbach /Usenet wrote: > * Pedro Lamarão, on 24.06.2010 12:59: > > 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? > > Whether such an example exists depends on your definition of "appropriate". I would consider appropriate that the result type of std::count is capable of expressing all results that make sense, such as for example the last element before the end of the range. > I expected that perhaps std::input_iterator would have a special associated > difference type, since a file or stream can easily be larger than can be encoded > using ptrdiff_t, yet it turned out to be ptrdiff_t (by default). I understand that this is good enough in practice; I'm just trying to find the lesson learned about these design decisions in retrospect. In my little world, all ranges are memory ranges, and I assume size_t is big enough to hold the position of anything in a memory range. Now, I imagine there is a larger world out there where ranges stored in strange places may be larger than what a size_t can deal with. But my best attempt to search for it ended with notions of infinite ranges where size_type is some kind of "big num" class. This is where I come from with my question: for what iterator type size_t is not appropriate as result type of std::count ? Or perhaps: what range type might have size larger than std::numeric_limits<size_t> ? -- P. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |