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

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-28 09:04:34

On Tue, Oct 28, 2003 at 11:25:04PM +1100, Thorsten Ottosen wrote:
> "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*.
>

Ok, I have looked at your code once more and precisely. So what is exactly
the difference between basic_substring and iterator_range, except, that
basic_substring class needs a container as a parameter?

This parameter is then not used anyway. 

Operations like + and find, are also quite separable ... So what is the real
benefit of this substring?

This container type is a burden which has to be taken everywhere. While currently,
if an algorithm needs to use iterator_range, it can be parametric only in regards,
to an iterator, basic_substring needs also a container.

Other issue is that there is not 1-1 mapping between a container type and an iterator type.
What it you have a mutable container, but you want to use only a const_iterator.
You will have to specify this explicitly of provide two alternatives of the container.

Or what if you are not working with an container iterator, but with some adapted iterator,
what will be the container_type?

There are too many open questions, that would have to be answered to make the substring
you are proposing as general as iterator_range and the benefits are IMHO very questionable,
especialy when they can be implemented in the separation with the same effect.
 
> > > 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 :-)

It can belong to a string library, but it is highly questionable if it belongs to
the "string algorithm" 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.
> 
This is only an implementation detail, important is the separaion of concepts.

Regards,

Pavol