Re: count and count_if algorithms return type seem to insufficient for large values
On 2008-04-27 17:59:37 -0400, "kwikius" <andy@servocomm.freeserve.co.uk> said:
"Pete Becker" <pete@versatilecoding.com> wrote in message
news:2008042711481916807-pete@versatilecodingcom...
On 2008-04-27 11:43:09 -0400, "kwikius" <andy@servocomm.freeserve.co.uk>
said:
The real problem is that containers have excessive requirements. arrays
and
lookups dont in practise need to be iterable at all, but you can still
write
generic algorithms. Remove the iterator paradigm and do for_each
(container)
in parallel for example. STL was a major innovator for generic
programming
but way way far from perfect.... Too many blooming iterators.
Without iterators STL is something entirely different. Container-based
algorithms are nowhere near as flexible as iterator-based ones, because
the sequences that iterators refer to don't need to come from containers.
Most containers arent sequences... except in STL "every container must be a
list". This is a viewpoint imposed by the iterator paradigm.
This is a viewpoint imposed by the need to operate every element in a
container.
Custom conforming containers are very complicated to create as need to
provide full custom iterator shebang.
Rather than creating iterators it is just as possible to create views of
arbitrary entities as containers. You only need to create one container view
( as opposed to 2 iterators to create 2 ends of a container view ).
If you need to operate on every element in a container, you end up
treating the container as a sequence. Creating one container view
versus two iterators doesn't change that.
Containers can have simpler requirements... easier to fulfill requirements
and create custom containers
Since there is no description here of how this paradigm works, I can't
assess this assertion.
It is also possible to view one container type as another.
increases flexibility for the user and also enables the user to create
custom
containers more easily because each container type has fewer requirements.
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.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)