Horribly butchered chat logs :X
<zahlman> <MaulingMonkey> Mmm…. library to implement a new iterator concept for C++ <— I would
prefer to have a real range concept
<MaulingMonkey> zahlman: I'm currently coding industry.concept.is_a_range, which this new
iterator concept would operate on :3
<zahlman> mm
<MaulingMonkey> Which should match against both containers, and anything else implementing
begin/end
<MaulingMonkey> including the already coded industry::range, which works on any iterator pair
:P
<zahlman> I'm thinking along the lines of stuff like template <typename Iterator> {type?}
make_counted_range(Iterator I, int size);
<MaulingMonkey> zahlman: Hmm, not too difficult
<zahlman> or template <typename Container> {type?} whole_container(const Container& c);
<MaulingMonkey> zahlman: I'll add that one as an overload of make_range :D
<zahlman> sounds good
<zahlman> MM: but the thing that makes it useful is re-implementing containers and algorithms
to accept ranges
<zahlman> (consider how much simpler std::string gets when you not only make Sutter's changes,
but also reduce ctors etc. to just the range-taking version)
<zahlman> (all kinds of overload-variation is encapsulated in the range construction process.)
<zahlman> (that should help with some algorithms too :) )
<Washu> foreach(c, arr);
<zahlman> for example, with counted_range, all the _n variants of algorithms disappear, and you
get the non-standard ones reintroduced for free
<Washu> foreach(c | filter(is_odd), arr);
<zahlman> now there's a creative operator overload washu :D
<Washu> zahlman: if you're going to go that far, might as well make the library useful
<zahlman> hehe
<Washu> and have it able to return ranges, which can be iterated over.
<zahlman> I'm imagining 'filter' being a type, with an overloaded operator|(T, const filter&)
<Washu> all your foreach function would require is that the submitted container implement
.begin() and .end() to return forward iterators
<Washu> Eh, I'm imagining filter to be a function that returns a type that implements operator
| internaly, but yes, that's the basic idea zahlman
<MaulingMonkey> Right.
<MaulingMonkey> I'm cracking open boost's iterators to try and avoid overlap
<MaulingMonkey> and instead integrate with that :)
<zahlman> mm, I still like the explicit range construction though, should be more flexible…
foreach (c, <zahlman> we could overload for a container to assume all() should be used
<MaulingMonkey> zahlman: The way I'm thinking would be, the full range is assumed by default
- things like "counted_range" modify the range returned to the algorithm (which
works on the entirety of *that* range)
<MaulingMonkey> So you shouldn't loose any flexibility
<MaulingMonkey> filter() looks like I can just layer atop boost::filter_iterator
<zahlman> I think that will need an overload along the lines of what I said, though. But no
problem :)
<zahlman> hmm what other kinds of iterators do I want :)
<MaulingMonkey> hehehe
<zahlman> dereferenced-nonnull-iterator (convert iterator over pointers to iterator over
references to the pointed-at things, where nulls are skipped)
<zahlman> key_iterator and value_iterator for maps
<zahlman> (actually you should probably only be able to get a key_const_iterator)
<MaulingMonkey> zahlman: They'd convert a pair to a first or last, right?
<zahlman> yes.
- MaulingMonkey creates a brainstorming page for this :D
<zahlman> first or second* :)
<zahlman> MM, I kinda want to revise the containers, though.
<zahlman> in particular, I was thinking (this may be crazy) of string instead being an adapter
for sequential containers
<zahlman> then you could e.g. use string<vector<char> > by default and be sure of being able to
read into it directly; or string<deque<char> > as a poor man's rope