Re: [boost] more problem with functional + projection_iterator

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-11 09:04:23

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>

> From: "David Abrahams" <david.abrahams_at_[hidden]>
> > From: "Peter Dimov" <pdimov_at_[hidden]>
> > > Do you think that this can be made to work?
> >
> > Absolutely.
>
> I should have added "within the context of the existing STL framework."
and
> perhaps phrased the question as: "Do you think it's worth the effort to
make
> them work?"
>
> Isn't it possible that this category of data containers would be better
> handled by another, radically different, access model; like
checkout/commit,
> or lock/operate/unlock, for example.

It is possible, but it is also a fact that most of the existing algorithms
can be trivially made to work with the broader range of iterators allowed by
a new conceptual framework for the iterator access model. It would be a
shame to duplicate the logic of all of those algorithms for a radically
different access model.

> >
> > Personally, I think it is worth the effort to evolve it at least a
little.
>
> Yes, no doubt; the question is, what direction should this evolution take.
>
> In my opinion, the STL has attempted to generalize too many things. There
> are the 'pointer' and 'reference' typedefs that can't be anything else
than
> a reference and a pointer to the value type.

That's only true for iterators >= ForwardIterator. Part of the reason it is
that way for containers (actually they are /allowed/ to be different -- see
20.1.5/4) is that the commitee realized that there were problems with a
broader model that we didn't have time to solve.

> There is that size_type thing where std::vector<int>::size_type can in
> theory differ from std::vector<long>::size_type but how many
implementations
> do this? Also, let's not forget difference_type.

Granted. Overgeneralization is a bugbear of all programmers.

> > When Jeremy and I worked on the Iterator Adaptor library we kept finding
> > places where we had to make pessimistic assumptions about underlying
> > iterators that compromised functionality (e.g. operator[] has to return
> > by-value). A better system of concepts for iterators, which separated
> > traversal from data access, would have helped a lot.
>
> Yes, I agree. There should be a way to identify lvalue, const lvalue, and
> rvalue returning iterators.

In our case, the problem is iterators whose references don't persist past
the lifetime of the iterators (the value is held within the iterator).

> It's only proxy-returning iterators that I'm not
> sure about. And of course we'd need two kinds of proxy iterators,
> proxy-with-rvalue-conversion and proxy-with-const-lvalue-conversion. :-)
(Or
> perhaps proxy-with-mutable-lvalue conversion as well?)

Yep.

> vector<bool> is evil. It has to die. vector<T> must be able to act as a
> replacement for new T[]; this is an important aspect.

Agreed, but I don't have much hope for its execution.

> Why are people so opposed to the std::vector_bool idea? I don't get it.

Some of their customers rely on it. That's all I can tell you; you'll have
to ask the vendors in question for more info.

> > BTW, I don't think "STL containers" works, at least not in the generic
> > sense. I know of no significant and successful libraries that treat
> > containers generically; do you?
>
> This would be a good thing. It means that the iterator concept works. :-)

I guess you're just joking, but I'll take you seriously anyway. Iterators
mostly do work, but they don't provide everything that is provided by
containers. It would still be useful to have a generic model for containers
that worked.

-Dave