Prev: floating point, how many significant figures?
Next: Is it legal to use maps with refrences ?
From: Alf P. Steinbach /Usenet on 24 Jun 2010 09:40
* Pedro Lamar�o, on 24.06.2010 12: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?

Whether such an example exists depends on your definition of "appropriate".

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).

Anyway, a signed difference_type is absolutely needed in order to be able to
express the distance between two arbitrary iterators, while a size_type is not
absolutely needed and would just introduce additional complexity. For that
matter, with modern desktop computer architectures the standard's support for a
zillion+1 different size types that depend on context and cannot be predicted if
that support is actually used, is nothing but needless complexity. However, I
guess it made sense in the 16-bit days, and today perhaps for embedded stuff.


Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Juan Pedro Bolivar Puente on 27 Jun 2010 00:04
>
>> 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> ?
>

Actually, even in memory you can think also of data structures with such
greater than memory ranges. For example, a multiset can --and should--
be implemented by just counting repeated occurrences of a value,
therefore having a theoretical maximum capacity of ~2^memorysize.

JP

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 | 
Pages: 1
Prev: floating point, how many significant figures?
Next: Is it legal to use maps with refrences ?