Re: [boost] Re: Re: Re: [string algo formal review]

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
> news:20031027204619.GM4718_at_lenin.felcer.sk...

[snip]

> > 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
> like
> 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
library.

You can easily provide both, and making the substring class constructable from 
an iterator_range, you can easily fulfill all the tasks you require. 

Regards,

Pavol