Re: [boost] String Algo Review Results

From: Pavol Droba (droba_at_[hidden])
Date: 2003-11-01 03:57:24

Hi All,

I would like to thank everyone who participated in this review.
Your suggestions, comments and ideas will definitely make this library 
better.

I'd like to add my personal observations to this summary.

1) Combined algorithm library:

This is probably the most important issue, that has been risen in this
review. There are already several libraries under development which
should be combined under one roof. String Algorithm Library is the first
one that has been reviewed. 

There is an obvios need to define the structure and principles
used in the big lirary, so that all sublibraries can coexist and benefit
from each other. There has been several new concepts defined by
string_algo library that should be factored out and possibly adopted
by other algorithmic libraries.

Questionable is what should be the next step. Resolving these
issues can take some time. string_algo library can wait for inclusion
until they are resolved and the it can be changed so it behaves
under these specifications.
However it migth be better to include it in the current for without
namespace/header structure changes and refactoring so it is possible to try new
concepts before finalizing them.

2) iterator_range

One of reusable concepts defined in this library is the iterator_range.
There has been some misunderstandings about this class/concept.

In the string_algo library this class mainly fills the purpose of a
result for find operations. It is basis for definition of Finder/Formatter
concepts.
Given the fact, that a pair of iterators is very well understoop concept,
I assumed, that it might be good to make iterator_range avalilable for
use outside of the library too. This has however brought some problems.
Some people find it useless, because f.e. std::pair can be used instead,
others find it lacking and would like to add more features to it.
Also there is already half_open_range under constuction available in the 
boost, but without any documentation so far.

Question is there what should be the future of the iterator_range?
Posibilities:
- use it only internaly by string_algo library (and possibly rename it
  to find_result)
- move it outside as a separate utility
- replace it with something else. 
  Current possibilities are half_open_range and std::pair.

There are oher issues that has been risen during this review. 
I will address them later, when the library will be ready for inclusion.

Regards,

Pavol