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

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

"Pavol Droba" <droba_at_[hidden]> wrote in message
news:20031028120456.GD5420_at_lenin.felcer.sk...
> 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...

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

how? AFAICT, the only extra requirement for char* would be how to return a
copy of type char*
(which should be provided by specialization of that function). Moreover, if
a string is defined
as sequential storage, there's not even a need for a template parameter,
everything can be implemeted in terms of 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.

not more requirement than copy_range<String>.

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

yeah, it definitely don't belong in a string 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.

that's not too bad a hack...but it's still a hack IMO.

cheers

Thorsten