From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-28 07:04:56
On Tue, Oct 28, 2003 at 08:43:28PM +1100, Thorsten Ottosen wrote:
> "Pavol Droba" <droba_at_[hidden]> wrote in message
> > Problem is that even thou iterator_range models a substring,
> > it is not a "substring".
> > It is only a kind of "pointer" to
> > a substring. It has no reference to an underlying container,
> > except for the iterators.
> and for user, what is the difference between iterators and a reference here?
Iterators are a referecne. So there is no difference. iterator_range is not
a miracle, it is a simple iterator wrapper.
> > Similary to iterators, it abstracts from the undelying container
> > and allows to simply iterate through the values as the iterator
> > allows to access values.
> > Problem with a conversion to f.e. std::string is that, itertor_range
> > has no information about what the underlying container is and
> > sometimes, it is not even a container (e.g. char*).
> > So it cannot be converted to a container without explicit
> > statement of the container type.
> that's because that information has been thrown away.
> The substring I designed ad hoc did know what the underlying string looked
> which could be used to its advantage.
Problem is that this information cost it too high. Because you have actualy
compromised to usage of types like char*.
> It did not provide explicit conversion, but it might should. Or it can
> provide a member function .str() that returns
> a copy.
Such a member function whould imply more requirements to the underlying type.
But for the operations, the iterator_range was designed, the benefits
you are proposing are not needed.
You are simply proposing to put together two different concepts. One for substring
capable of string-like operations and an iterator_range, which is designed as
a lighweight wrapper for iterator-pair idiom.
I'm not saying that these concepts are not related, they are, but only in one direction.
your substring is a specialization of a generic iterator_range. I think that
it should stay this way. substring should be a separate class, possibly in a separate
You can easily provide both, and making the substring class constructable from
an iterator_range, you can easily fulfill all the tasks you require.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk