This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re : ...


Nathan Myers <ncm-nospam@cantrip.org> writes:
> On Sat, Jan 22, 2005 at 07:16:28AM +0100, Gabriel Dos Reis wrote:
> > From the perspective that iterators are "generalizations" of pointers,
> > there is a missing value, the analogous of null pointer and its
> > ability to serve as "sentinal" or special (not singular) value.
> > If T is a pointer type, then T() is a null pointer and it can be used
> > as a special value.  That guarantee is missing for general iterators.
> > I hope Sylvain would step in and explain the various occasions where
> > that irregularity gets into the way.
> 
> As I recall, the notion of a null iterator was deliberately omitted
> as tending to make both implementations and user code more complicated, 
> with no overarching benefit.  Manifestly, we get along fine without.
> 
> However, I do seem to recall also that when the STL was proffered, 
> T() notation didn't work as it does now when T was a pointer.

As Gaby said, I contacted him 4 months ago in order to know the procedure
for submitting a DR about this issue.  I was also encouraged to do so by
David Abrahams (more time ago) following a discussion on this issue on a
C++ newsgroup.  I hope I'll find the time to do so soon enough, so that the
issue can be debated at the next C++ meeting.

My use-case is the following : I want to store the nodes of a graph in a
container (std::list or std::vector mostly).  Adjacency relations between
nodes are usually coded in C by pointers.  Here, you want to use the
containers' iterator instead, otherwise you can't call erase() on a element
anymore, if you know only the pointer to that element.  Now, it is quite
common in C to use NULL as a sentinel value in some graphs to specify that
there is no adjacent node to a node.  This is where there comes a need
for such a similar constant value for the iterator.  There are several ways to
solve this problem of course :
- you can use a static iterator value, but it is heavy, and probably slightly
  slower to compare against than 0.  Doesn't require STL changes.
  Requires access to the container's type in a context where you could
  only have the iterator type.
- Containers could provide a static data value null_const_iterator, which you
  can copy and compare against, is guaranteed to be unique, but need not be
  dereferencable. 
  Also requires access to the container's type in a context where you could
  only have the iterator type.
- the ideal solution to me would be to have the default constructed iterator
  provide this NULL-like value.  It is natural in the sense that pointers
  already have it.  So in a sense, not having it makes Iterators less powerful
  than pointers.

In practice, what we do (in CGAL, where we encounter this problem), is to
rewrite the containers to fit this need, hence my motivation.

-- 
Sylvain


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]