Re: [boost] Re: iterator ranges; eliminating private member functions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-12-04 04:51:16

brangdon_at_[hidden] wrote:
> > This is embarassing/inelegant. Consider writing
> > container_algorithms::sort(.....), and repeating that prefix in
> > everywhere....
>
> Using a shorter name would help. Eg:
>    seq::sort(...);
>
> Or more likely:
>    boost::seq::sort(...);
>
> But here the "boost::" part is the bulk of it.
Yes.

> I don't see what else we can do. The std algorithms have such general
> signatures. 
If we give up completeness, container versions of many algorithm can be 
written without ambiguitating std:: versions.

> I don't think seq_sort() (or similar) is an improvement. 
Neither do I.
> I
> don't like to get terseness from abbreviation, but the name "std" is a
> precedent.

> > > In my view, sequence objects should be mutable in much the same way
> > > that iterators are mutable. They should not be passed by reference.
> > > Then there is no problem with temporaries.
> >
> > In this case, directly passing vector to an algorithm is very
> > inefficient.
>
> Currently the std algorithms act on sequences, not containers, and I think
> we should stick with that. We should just change how they are represented
> without changing what they are. I tried to explain why in my messages to
> Aleksey Gurtovoy (eg on the 5th Nov; if there's a reply I missed it). Your
> objection applies to his ideas rather than mine. I hope it is still an
> open issue.
Open issue indeed. Can we formulate our positions afresh?
1. vectors (strictly speaking, models of Sequence) are passed to containers 
without any extra verbosity:
  + Aleksey reports positive experience with this approach, supposedly   
     meaning simplicity (Aleksey?). I'd agree.
  - Problem with mutating algorithms
2. special classes used for sequences:
  + No problem with mutating algorithms
  - Problems mixing with existing code & extra verbosity. Suppose I use some
    view library. Then, I'd have to write something like .... 
        max_element(seq::make_seq(filter(seq::make_seq(v), some_predicate)))
   ? You previously talked about better support for sentinel values with
    sequence objects, but I still don't think this is very important.

> This will mean even more verbosity, unfortunately:
>
>     seq::sort( seq::make_seq(v) );
Actually, 
        sort( seq::make_seq(v) );
should work due to argument-dependent lookup.

- Volodya