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

[Daniel Pitts]

su************* *@yahoo.com, India wrote:

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

In theory, you may be right, but in practice that would be a vector that
contains 4 billion entries, with all the overhead that a vector has per
entry.

Pragmatically speaking, you won't have to worry about overflow problems.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity .net/wordpress/>

[Kai-Uwe Bux]

Daniel Pitts wrote:

su************* *@yahoo.com, India wrote:

>Below is my understanding about count algorithms.

Return type of count and count_if algorithms is
iterator_trait s<InputIterator >::difference_t ype.

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(belon ging 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_typ e) ?

Kindly clarify.

Thanks
V.Subramania n

In theory, you may be right, but in practice that would be a vector that
contains 4 billion entries, with all the overhead that a vector has per
entry.

Actually, in all implementations I know, a vector has no overhead per entry.
It has a small constant overhead since it stores its size and the capacity.

Pragmatically speaking, you won't have to worry about overflow problems.

Agreed.
Best

Kai-Uwe Bux

[Pete Becker]

On 2008-04-26 22:35:48 -0400, "su************ **@yahoo.com, India"
<su************ **@yahoo.comsai d:

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

You can always create unsigned integer values that have no
corresponding signed value. Similarly, you can always create signed
integer values that have no corresponding unsigned value. That's a
well-known and unsolvable limitation of size_t and ptrdiff_t, and
anything else that tries to talk about sizes and differences.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Kai-Uwe Bux]

Pete Becker wrote:

On 2008-04-26 22:35:48 -0400, "su************ **@yahoo.com, India"
<su************ **@yahoo.comsai d:

>Below is my understanding about count algorithms.

Return type of count and count_if algorithms is
iterator_trait s<InputIterator >::difference_t ype.

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

You can always create unsigned integer values that have no
corresponding signed value. Similarly, you can always create signed
integer values that have no corresponding unsigned value. That's a
well-known and unsolvable limitation of size_t and ptrdiff_t, and
anything else that tries to talk about sizes and differences.

In the special case of differences between iterators and sizes of
containers, the problem seems solvable: the standard could require (a) the
existence of a signed type sufficiently big to hold all differences between
iterators that can occur on the given implementation and (b) require that
ptrdiff_t and the various difference_type are typedefs for such signed
type.

On a related note: it is even guaranteed that push_back() on a vector cannot
make its size overflow to 0?
Best

Kai-Uwe Bux

[Pete Becker]

On 2008-04-27 08:05:14 -0400, Kai-Uwe Bux <jk********@gmx .netsaid:

Pete Becker wrote:

>On 2008-04-26 22:35:48 -0400, "su************ **@yahoo.com, India"
<su*********** ***@yahoo.comsa id:

>>Below is my understanding about count algorithms.

Return type of count and count_if algorithms is
iterator_trai ts<InputIterato r>::difference_ type.

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<char v;
where 'v' contains UINT_MAX elements each of which is 'a'.

You can always create unsigned integer values that have no
correspondin g signed value. Similarly, you can always create signed
integer values that have no corresponding unsigned value. That's a
well-known and unsolvable limitation of size_t and ptrdiff_t, and
anything else that tries to talk about sizes and differences.

In the special case of differences between iterators and sizes of
containers, the problem seems solvable: the standard could require (a) the
existence of a signed type sufficiently big to hold all differences between
iterators that can occur on the given implementation and (b) require that
ptrdiff_t and the various difference_type are typedefs for such signed
type.

What that amounts to is artificially limiting the size of a container
to the non-negative values of a signed type. If you do that, surely
someone will complain that they want their containers to be larger, and
don't care about difference_type .

--
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:2008042710 290416807-pete@versatilec odingcom...

On 2008-04-27 08:05:14 -0400, Kai-Uwe Bux <jk********@gmx .netsaid:

>Pete Becker wrote:

>>On 2008-04-26 22:35:48 -0400, "su************ **@yahoo.com, India"
<su********** ****@yahoo.coms aid:

Below is my understanding about count algorithms.

Return type of count and count_if algorithms is
iterator_tra its<InputIterat or>::difference _type.

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

You can always create unsigned integer values that have no
correspondi ng signed value. Similarly, you can always create signed
integer values that have no corresponding unsigned value. That's a
well-known and unsolvable limitation of size_t and ptrdiff_t, and
anything else that tries to talk about sizes and differences.

In the special case of differences between iterators and sizes of
containers, the problem seems solvable: the standard could require (a)
the
existence of a signed type sufficiently big to hold all differences
between
iterators that can occur on the given implementation and (b) require that
ptrdiff_t and the various difference_type are typedefs for such signed
type.

What that amounts to is artificially limiting the size of a container to
the non-negative values of a signed type. If you do that, surely someone
will complain that they want their containers to be larger, and don't care
about difference_type .

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.

regards
Andy Little

[Pete Becker]

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

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

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Bo Persson]

Kai-Uwe Bux wrote:

Pete Becker wrote:

>On 2008-04-26 22:35:48 -0400, "su************ **@yahoo.com, India"
<su*********** ***@yahoo.comsa id:

>>Below is my understanding about count algorithms.

Return type of count and count_if algorithms is
iterator_trai ts<InputIterato r>::difference_ type.

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<char v;
where 'v' contains UINT_MAX elements each of which is 'a'.

You can always create unsigned integer values that have no
correspondin g signed value. Similarly, you can always create signed
integer values that have no corresponding unsigned value. That's a
well-known and unsolvable limitation of size_t and ptrdiff_t, and
anything else that tries to talk about sizes and differences.

In the special case of differences between iterators and sizes of
containers, the problem seems solvable: the standard could require
(a) the existence of a signed type sufficiently big to hold all
differences between iterators that can occur on the given
implementation and (b) require that ptrdiff_t and the various
difference_type are typedefs for such signed type.

Isn't that what happens in practice?

On the most popular 32 bit systems, you would have to try extremely
hard to allocate a vector<charthat uses more than half the available
address space. For any other types, sizes and ptrdiff values are much
smaller.
Bo Persson

[kwikius]

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

Containers can have simpler requirements... easier to fulfill requirements
and create custom containers

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?

The loser may be the library implementor of course, but library author to
user is one to many ratio so total code written reduced.
OTOH the library implementor has more scope to optimise because he doesnt
need necessarily to conform internal to the function to the iterator
paradigm.

regards
Andy Little