Boost logo

Boost :

Subject: Re: [boost] [iterator] UB when implicitly using default constructed counting_iterator<unsigned>
From: Peter Sommerlad (peter.sommerlad_at_[hidden])
Date: 2012-12-01 10:20:17

Hi Jeff

On 01.12.2012, at 02:53, Jeffrey Lee Hellrung, Jr. wrote:

>> And a default
>> initialized scalar type, isn't.
> "isn't"...what, exactly?

it isn't initialized with a defined value.

struct X{
unsigned x;
void foo(){
X y; // -> y.x has an uninitialized value AFAIK if it is local
that is the situation we run into with the default constructed counting_iterator<unsigned>()

> I'm not opposed to giving defined behavior to a default constructed
> counting_iterator< [integral type] >, I'm just not sure what that defined
> behavior should be. Maybe I'm over-analyzing it...

I still believe the most simple change I suggested is enough (at least it would cover my situation well enough). Those input iterators where a default constructed one is the end iterator is IMHO more of an exception, because it is a special case for the stream iterators.
Your idea with std::numberic_limits< Iterator >::max() requires a much more complex solution with template meta programming, i.e., enable_if<is_arithmetic<Iterator>> or similar. And it won't provide the default value of Iterator, which is zero in the case of the built-in arithmetic types, i.e., unsigned().

What do you think?


Prof. Peter Sommerlad
Institut für Software: Bessere Software - Einfach, Schneller!
HSR Hochschule für Technik Rapperswil
Oberseestr 10, Postfach 1475, CH-8640 Rapperswil
tel:+41 55 222 49 84 == mobile:+41 79 432 23 32
fax:+41 55 222 46 29 == mailto:peter.sommerlad_at_[hidden]

Boost list run by bdawes at, gregod at, cpdaniel at, john at