🚀 go-pugleaf

Joe Buck wrote:
> 
> 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) {}
> >
> >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.

No... an allocator pointer is something that has pointer semantics.
It can only confuse things to bring in Iterators here.  The list of
required semantics for allocator pointers is quite limited.

Conversion from 0 is not required, but conversion to void* and
default construction are.  Arguably the line above should be:

> >       iterator() : current(Allocator::pointer()),
                       first(Allocator::pointer()), 
                       last(Allocator::pointer()),
                       node(Allocator::pointer()) {}

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

The current definition of allocator pointers didn't exist when 
the HP implementation was written, so you can't blame Stepanov
and Lee.  

The implementations of all the standard containers change in response
to changes in Allocator, and std lib vendors have been working feverishly
to get everything consistent.  A non-pointer allocator "pointer" is an
obvious addition to the test suite for a standard library.

Nathan Myers
http://www.cantrip.org/          <-- note: new site
ncm@cantrip.org                  <-- note: new address
---
[ 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. ]