count and count_if algorithms return type seem to insufficient forlarge values

[subramanian100in]

Below is my understanding about count algorithms.

Return type of count and count_if algorithms is
iterator_traits <InputIterator> ::difference_ty pe.

If the container contains more than 'difference_typ e' elements
satisfying the condition, then count and count_if algorithm cannot
return a value greater than 'difference_typ e'.

As an example, suppose maximum value of 'difference_typ e' is INT_MAX.
Then the corresponding maximum value of 'size_type' is UINT_MAX. Now
consider the declaration
vector<charv;
where 'v' contains UINT_MAX elements each of which is 'a'.

Now if I do
count(v.begin() , v.end(), 'a')
then the actual count would be UINT_MAX but it cannot be represented
in 'difference_typ e' which is the return type of count algorithm.

So' won't we get erroneous results from count algorithms ?

I understand that difference_type is same as ptrdiff_t for
pointers(belong ing to the same array) and size_type if same as size_t.
This means that the count algorithms can never return values from
ptrdiff_t + 1 upto size_t.

Is this understanding correct ?

If what I have mentioned is really a problem with count algorithms,
how should I count the elements in a container satisfying the
condition for large number of elements(ie greater than
difference_type ) ?

Kindly clarify.

Thanks
V.Subramanian

[Pete Becker]

On 2008-04-27 17:59:37 -0400, "kwikius" <an**@servocomm .freeserve.co.u ksaid:

>
"Pete Becker" <pe**@versatile coding.comwrote in message
news:2008042711 481916807-pete@versatilec odingcom...

>On 2008-04-27 11:43:09 -0400, "kwikius" <an**@servocomm .freeserve.co.u k>
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_containe r, your_container , f) ; //overloaded or internally adapted

as against

fun(my_containe r.begin(), my_container.en d(), my_container.be gin(),
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)

[kwikius]

"Pete Becker" <pe**@versatile coding.comwrote in message
news:2008042807 104016807-pete@versatilec odingcom...

On 2008-04-27 17:59:37 -0400, "kwikius" <an**@servocomm .freeserve.co.u k>
said:

>>
"Pete Becker" <pe**@versatile coding.comwrote in message
news:200804271 1481916807-pete@versatilec odingcom...

>>On 2008-04-27 11:43:09 -0400, "kwikius" <an**@servocomm .freeserve.co.u k>

<...>

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

Not all containers need to have every element operated on. lookup is an
example. You don't need to iterate a lookup for its main functionality . Now
when you need to iterate over a lookup you can create a listview, and not
just one but many, sorted by key , or key range sorted by value or value
range, arbitrary sort function, and even layer views. You can apply
functionality for the particular purpose when you need it and then discard
it.

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

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
ForEachableCont ainer CountIfAbleCont ainer etc, like the modern move from
"traits blob" to metafunctions.

<...>

>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_contain er, your_container , f) ; //overloaded or internally
adapted

as against

fun(my_contain er.begin(), my_container.en d(), my_container.be gin(),
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.

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

regards
Andy Little

[Pete Becker]

On 2008-04-28 13:31:34 -0400, "kwikius" <an**@servocomm .freeserve.co.u ksaid:

>
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
ForEachableCont ainer CountIfAbleCont ainer 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_contai ner, your_container , f) ; //overloaded or internally
adapted

as against

fun(my_contai ner.begin(), my_container.en d(), my_container.be gin(),
your_containe r.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)