Re: [boost] more problem with functional + projection_iterator

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-10-11 06:57:38

From: "David Abrahams" <david.abrahams_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
>
> > Oh yes, proxy references. vector<bool>. Database containers.
> Distinguishing
> > reads from writes. Copy on write.
> >
> > 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.

> > I'm somewhat on the pessimistic
> > side. We have something - the STL containers/iterators - that works,
more
> or
> > less, and solves real problems. Trying to evolve the ultimate data view
> > model from it may not be worth the effort.
>
> Well, that's a different question, isn't it?
>
> 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.

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.

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

> Also, if we could find
> a place in the framework for vector<bool>::iterator, we'd be able to fix
the
> standard so that algorithms would behave predictably with vector<bool>
> (since vendors don't seem willing to pull the vector<bool> specialization
> out of the standard).

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.

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

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

--
Peter Dimov
Multi Media Ltd.