Re: [boost] Review Request: Creasing (Sequence Properties)

Subject: Re: [boost] Review Request: Creasing (Sequence Properties)
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2010-01-27 18:41:07

2010/1/27 Stewart, Robert <Robert.Stewart_at_[hidden]>:
> Joachim Faulhaber wrote:
>> >
>> > That's an excellent question.  I, too, foresaw its
>> > usefulness in assertions.
>> > I can imagine those doing DBC would like it, too.  However,
>> > I can imagine
>> > examining file, network, or user input to ensure the data
>> > fits some ordering criteria, too.
>>
>> . . . more of the (initially) asserting-the-invariant type of use.
>
> The latter were not, in my mind, assertion uses,
> but rather run-time, production code tests to determine
> whether to accept or reject an input.
ok.

I've looked in boost_1_41_0 . There are four (4) uses of
is_sorted, all in asserts in
graph\distributed\connected_components.hpp

> Because folks will continue to use C++98/03 for some time, it is
> reasonable for Boost to provide a fallback for what's to come.
> Consequently, there's room yet to put this predicate into Boost.
ok.

>> Remains the question, if the variants of
>> is_[strictly_]{in_,de_}creasing
>> are to be added as algorithms, which conjures up another intersting
>> question:
>>
>> Are there criteria to be fulfilled to maintain the minimality
>> of a set of free algorithms?
>
> I understand the desire to keep the set small enough to
> be manageable,

I think the clearness of the library interfaces is very important
and the quest for criteria and guidelines is helpful.

> but it should be large enough to avoid the need to repeat
> (and rediscover) common recipes.  Are those four
> predicates sufficiently useful to justify being documented,
> tested, and maintained in Boost?  If not, they can be
> illustrated as examples for use of is_sorted.

I'd prefer the latter.

Good night from (freezing) Europe
Joachim