RE: [boost] Re: string algorithms review

From: Paul A. Bristow (boost_at_[hidden])
Date: 2003-10-24 03:38:09

These seems acceptable to me, but I would still like to see a large number of
overcommented examples/tests of how they would work in practice. (The examples
should include some that don't work). These would be a most valuable part of the
documentation (a vital part of selling the code to the majority of users who are
novices).  And it might reveal some disadvantages that are not yet apparent.

Overall I feel these string handling things are essential and this library will
be  acceptable.

A couple of very minor observations:

1  I don't think that abbreviating to 'algo' is in keeping with Boost preference
for clarity over curtness.

2  The suffix should be _copy and _copyto.

Paul

PS I feel this long dialog may be showing a weakness in the review process.  I
can (from experience) understand authors' reluctance to put a lot of work into
the documentation (or redoing code) unless one can be sure that the code is
going to be accepted.  Do we need to accept a proposal in principle, then have a
revision period, and then finally review and accept as 'official' release
version (1st version anyway)?

Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
[phone]   Mobile [phone]
mailto:pbristow_at_[hidden]

| -----Original Message-----
| From: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]]On Behalf Of Pavol Droba
| Sent: Thursday, October 23, 2003 6:42 AM
| To: Boost mailing list
| Subject: Re: [boost] Re: string algorithms review
|
|
| On Thu, Oct 23, 2003 at 11:19:18AM +1000, Thorsten Ottosen wrote:
|
| [snip]
|
| Whats is the problem with the current proposal? It declares three
| variants for each
| algorithm:
|
| 1. _copy version, the result is copied to an output iterator
|    - This variant, has least requirement on the input.
|    - It is semantical equivalent of algorithms in STL
| 	- has no side effects
|
| 2. _copy version, the result is a copy of the input
|    - Allows chaining
|    - Has more requirements on the input-type, because it is used for result
| 	- has no side effects
|
| 3. inplace version. Input is modified
| 	- optimized implementation
|    - returns void, to avoid a possibiliy of missuse
| 	- Has strongest requiremnts on the input type
|
|
| Given these three variants we cover all the important cases. We have
| fast and safe inplace version.
| We have copy version whith the chaining ability, and we have a
| version for an arbitrary input.
|
| I'd like to close this issue. There were several supporters of this
| proposals. Is this acceptable for whole boost?
|
| Pavol