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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-10-29 04:38:16

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

how do they fit into the string algo lib? AFAICT, every string iterator has
to come from
a string of some kind.

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

I agree generality is lost.

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

make_pair() works just as good and it's already standard. With container
traits, it will behave
just a well.

> > 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( ... );

yeah, <g> what an example :-) From a documentation view,
it might be much clearer for many (espicially newbies) to read

  template<typename StringT, typename SearchStringT>
    basic_substring< StringT >
    find_first( StringT&, const SearchStringT &);

than

  template<typename InputContainerT, typename SearchContainerT>
    iterator_range< typename string_algo::container_result_iterator<
InputContainerT >::type >
    find_first(InputContainerT &, const SearchContainerT &);

but examples will help a lot here.

over and out

Thorsten