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

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-28 11:38:54

On Wed, Oct 29, 2003 at 02:10:06AM +1100, Thorsten Ottosen wrote:

[snip]
 
> > Operations like + and find, are also quite separable ... So what is the
> > real
> > benefit of this substring?
> > 
> clean concepts. A string algorihtm search a "string" for a "substring" and
> this returned
> "substring" integrates seemlessly with its associated string type and
> behaves in most
> ways as its associated string type.
>

Problem is that this association is added ad-hoc. It it not a natural property
of the iterator_range.
 
> > 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.
> > 
> there not much difference; a container can exist without an iterator; the
> converse is not true.
>

Actualy you are not quite right. What about ostream_iterator or tokenizer iterator?

> > 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.
> > 
> yeah, that's  a minus. Howeverm, I implemented it with an overloaded
> constructor that takes a mutable version.
>

Honestly, when you use complicated iterators like those from iterator adaptor
library, the link to the underlying container is easily lost.
For instance zip iterator works on two different iterators ...

Addind this addtional dependencies lowers the generality. 

In addition, how would you implement make_range?
You would have to specify the container type explicitly, what realy is not
nice, because it brings overhead also when you don't want it.

> > Or what if you are not working with an container iterator, but with some
> > adapted iterator,
> > what will be the container_type?
> > 
> I kind think so far as to say what the problem is here. I have to see some
> example.
> 

[snip]

> it is messy to have too many classes/names flying around in your head, but I
> don't think its a big pain here.

It is always better to have two different classes then one big-one, which
is suitable for anything, but nothing.

 
> Anyway, what would you choose of these:
> 
> iterator_range< string::const_iterator > match = find( ... );
> const_substring match = find( ... );
> iterator_range< string::iterator > match = find( ... );
> substring match = find( ... );

this is not very good example. your substring is a typedef and the same typedef
can be defined for the iterator_range.

so I can also write:

strrange match = find(...);
basic_substring<const std::string> match = find( ... );

> string s = copy_range<string>( find( ... ) );

I see nothing wrong with this. At least to conversion is explicit.

> string s = find( ... );

Substring alone can provide many additional features which could be
noncompatible with the iterator_range concept. I still don't see
any good reason why to put these concepts into one class.

Cheers,

Pavol