[boost] Re: potential problem with indirect_iterator (GCC 3.3.2)

From: David Abrahams (dave_at_[hidden])
Date: 2004-03-02 13:52:05

Tom Widmer <tom_usenet_at_[hidden]> writes:

> On Tue, 02 Mar 2004 09:23:36 -0500, David Abrahams
> <dave_at_[hidden]> wrote:
>
>>Tom Widmer <tom_usenet_at_[hidden]> writes:
>>
>>>>If I'm misusing the code, is there some reason for this?  It's
>>>>inconvenient that the default constructor doesn't initialize pointers
>>>>to some consistent value; the problem goes away when I change the
>>>>indirect_iterator default constructor:
>>>>
>>>>    94c94,96
>>>>    <       indirect_iterator() {}
>>>>    ---
>>>>    >       indirect_iterator()
>>>>    >         : super_t( Iterator() )
>>>>    >       {}
>>>
>>> That gives you a false sense of safety. Default initializing many
>>> iterator types is a no-op - they are still unusable (e.g.
>>> std::list::iterator).
>>
>>or, in the same way, int*.
>
> Default initializing an int* isn't a no-op, and you can equality
> compare such int*s. The same isn't true for std::list::iterator, which
> is why I chose it.
>
> e.g.
> It i = It();
> It j = It();
> bool b = (i == j);
>
> That's well defined for It=int* (and It=istream_iterator<T>), but UB
> for It=std::list<int>::iterator (since i and j are singular).

Right; I misread your point.  I meant:

  int* p1;
  int* p2;
  bool b = (p1 == p2); // undefined behavior

Same thing if we replace the int* by std::list::iterator.  I guess
std::list::iterator is a bit worse in some sense because of the point
you're making.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com