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

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

"Pavol Droba" <droba_at_[hidden]> wrote in message
news:20031028140434.GF5420_at_lenin.felcer.sk...

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

it would be if there should be implicit conversion to the string and if
concatenation operators
was provided inline in the class so one only overleaded this set of
operators.

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

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

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

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

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

there's some, but not many :-)

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

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

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( ... );
string s = copy_range<string>( find( ... ) );
string s = find( ... );

?

cheers

Thorsten