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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-10-28 04:43:28

"Pavol Droba" <droba_at_[hidden]> wrote in message
news:20031027204619.GM4718_at_lenin.felcer.sk...
> On Mon, Oct 27, 2003 at 10:49:03AM -0500, Rob Stewart wrote:
 [snip]
>
> > I think this reveals a fundamental issue with this library.  It
> > is called a "string" algorithms library, and that means something
> > like std::string, MFC's CString, etc. to most people.  This
> > library follows the STL convention of treating many things
> > alike.  (If it looks like a duck, and quacks like a duck, we call
> > it a duck.)  Thus, this library generalizes the notion of a
> > "string" beyond what many find comfortable or typical.
> > Recognizing this, the documentation must clearly, loudly, and
> > early set straight the record.
> >
> > On the conversion issue raised above, may I point out that if the
> > underlying "string" container is std::basic_string in some form,
> > then conversions of iterator_ranges to the same string type
> > should be trivial, if not implicit.  Thus, if someone uses the
> > "string" algorithms library on std::string, then they should be
> > able to work with and convert to std::string very easily, with a
> > minimum of fuss.  Extra steps, especially steps that don't read
> > right, should be avoided.  Thus, the suggested copy() mf should
> > at least be named "str" in keeping with the STL, if the
> > conversion to the string type can't safely be made implicitly.
>
> 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?

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

It did not provide explicit conversion, but it might should. Or it can
provide a member function .str() that returns
a copy.

-Thorsten