>> So, this deque ctor seems to break the rules. Yet it was written by
>> the inventors of STL.

OK, the deque class of the HP STL is indeed buggy.


          David




[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

David Byrden <100101.2547@compuserve.com> writes:
>In the HP STL, deque::iterator has a default ctor which initialises
>several of its members with the value 0
>
> iterator() : current(0), first(0), last(0), node(0) {}

Checking the code, this initialization to 0 is evidently not used
anywhere.  However, if the members are not initialized at all, tools
like Purify may complain about uninitialized memory reads.  Perhaps
this is why it's there.  The problem is the "default constructor"
for pointers doesn't do anything; it leaves the pointer with a random
value.

Almost seems like what you'd really want for STL is a template for
initializing iterators that would be specialized for pointers; pointers
would be initialized to zero; other class types would just get initialized
by their default constructor (this would need partial specialization, I
think).  But that would in effect create an implicit NIL for all iterators
(well, we could always argue about that question again).  But maybe a NIL
is only needed for allocator pointers and not iterators in general.

>These members have the type deque::pointer, which is a typedef
>for the pointer in deque's allocator.
>An allocator pointer, according to the standard, has exactly the same
>semantics as a random access iterator.

So you're trying to create an allocator that is not based on pointers.

>I can find no place where it says that all random access iterators
>should be constructable from the int value zero, neither in
>documentation from the time of the HP STL, nor the latest draft standard.

Correct.

>So, this ctor seems to break the rules. Yet it was written by the
>inventors of STL.

Well, they goofed, I suppose.  Seems the types of allocators they used
were all pointers, so they didn't test out other cases.


--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

>>>In the HP STL, deque::iterator has a default ctor which initialises
>>>several of its members with the value 0
>>>
>>>       iterator() : current(0), first(0), last(0), node(0) {}

>> Well, they goofed, I suppose.  Seems the types of allocators they
>> used were all pointers, so they didn't test out other cases.


Joe, you're absolutely right. I got a post (through a Compuserve forum)
from someone pointing out that class 'deque' in the HP STL has bugs.

            David



[Moderator's note: discussion of whether the sample code in the free
STL implementation is standard-conforming certainly belongs in
this newsgroup.  Please try to avoid articles that repeat things
that have already been said, though.  mha]

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

I'm trying to define an allocator and I have run into a problem.

In the HP STL, deque::iterator has a default ctor which initialises
several of its members with the value 0

 iterator() : current(0), first(0), last(0), node(0) {}

These members have the type deque::pointer, which is a typedef
for the pointer in deque's allocator.

An allocator pointer, according to the standard, has exactly the same
semantics as a random access iterator.

I can find no place where it says that all random access iterators
should be constructable from the int value zero, neither in
documentation from the time of the HP STL, nor the latest draft standard.

So, this ctor seems to break the rules. Yet it was written by the
inventors of STL.

Any contributions?



             David
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]