🚀 go-pugleaf

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

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