Re: count and count_if algorithms return type seem to insufficient for large values
On 2008-04-28 13:31:34 -0400, "kwikius" <andy@servocomm.freeserve.co.uk> said:
Not all containers need to have every element operated on.
In which case they don't have to have iterators.
lookup is an
example. You don't need to iterate a lookup for its main functionality .
Sigh. You have to be able to look at every element, i.e. "operate on"
every element.
Since there is no description here of how this paradigm works, I can't
assess this assertion.
Its about concepts dealing with one single functionality of a type in
expression rather than monolithic concepts covering large amounts of
functionality ( e.g HasPlus preferred to Arithmetic ) think of eg
ForEachableContainer CountIfAbleContainer etc, like the modern move from
"traits blob" to metafunctions.
I'm sorry, I have no idea what that means.
<...>
But the most important point is it removes the necessity of exposing the
blooming iterators in every algorithm, which makes source code less
expressive :
fun(my_container, your_container , f) ; //overloaded or internally
adapted
as against
fun(my_container.begin(), my_container.end(), my_container.begin(),
your_container.end(), f) ; //error?
At the cost of having to pretend that the keyboard, for example, is a
container rather than the source of a sequence of characters.
Oh don't get me started on istream.
Who said anything about istream? Regardless, you have to deal with the
issue of pretending that a keyboard is a container.
Simple console input is a lazy list with customisable terminator... eg for
continuous multiline input, disc istream is array or tuple, database istream
a lookup etc...
That's what I said: you have to pretend that the keyboard is a container.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)