Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-09 18:14:07


Hmmm - now this is very interesting to me. To me, the syntax below is very
obvious and transparent - even elegant. In fact, its the feature I like
most about the whole proposal. It lets me compose iterators at compile time
with mininal runtime cost. It also permits composition at compile time in
what I see is a natural manner

typedef amended::filter_iterator<
    from_ro_f,
    std::vector<employee>::const_iterator
> romainians_t;

typedef amended::transform_iterator<
    get_empl_name_f,
    romainians_t
> romanian_names_t;

In the serialization library it permitted me to make a set of "relatively"
simple single purpose iterators like mb_from_wchar, remove_spaces,
transform_width<8,6> etc and compose them in various ways to make things
like from_base64, xml_escape, etc. In some cases, the input end wasn't so
easy to handle. This included trnaslation from 8 bit octets to 6 bit ?,
input from input iterators. I did consider the idea of ranges but didn't
see it working for me here. - I don't remember the details. The extreme
rigor and formality of the new boost itertator was both a curse and a
blessing. Making the "dataflow" iterators seemingly harder to make. But
all the compositions (some fairly deep) worked as expected with no
debugging. I'm extremely interested in seeing this idea explored more in
the future.

"Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
news:cmrgnj$6lu$1_at_sea.gmane.org...

> If you are going to convince me iterators are easy to use, you have to
come up
> with something better than
>
> typedef amended::transform_iterator<
> get_empl_name_f,
> amended::filter_iterator<
> from_ro_f,
> std::vector<employee>::const_iterator
> >
> > romanian_names_t;
>

> std::copy(
> romanian_names_t(empls.begin()),
> romanian_names_t(empls.end()),
> std::ostream_iterator<std::string>(std::cout," ")
> );
>

note: I'm presuming that you have no problem with std::copy ... syntax here

> Seriously, this is so ugly and hard to write that I predict less than 1%
of
> the community will ever use it.

LOL- I think just the opposite. I guess its in the eye of the beholder.
The funnest part of this is that I specifically crafted the code to permit
exactly this syntax. I'm amazed there there exists even one person that has
a negative reaction to it. Its immensly intriguing to me that we can have
exact opposite reactions to this. I'll be curious to hear what others
think.

Robert Ramey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk