|
Boost : |
From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-12 15:51:13
Dave is saying what I just posted in response to Peter, only much, much
better ;-)
Thanks, Dave!
-Dave
----- Original Message -----
From: "Dave Gomboc" <dave_at_[hidden]>
> > From: "Peter Dimov" <pdimov_at_[hidden]>
> >
> > But for_each is not map, AFAIK. for_each can change the sequence it's
> > applied to. Functional languages don't. Even transform is not map.
>
> I agree that for_each != map, but whenever I use for_each/transform I
> use it like I would use map, which is why I make the association.
> There's this disconnect where functional programming languages do not
> permit binding a new value to a variable, but C++ does.
>
> // standard ml
>
> fun map' (f, nil) = nil
> | map' (f, h::t) = (f h) :: map' (f, t)
>
> map' (fn x => x+1, [1,2,3,4])
>
> ( => [2,3,4,5] )
>
> // pseudo-c++
>
> int main(void) {
> std::vector<int> x = {1,2,3,4}; // remember, pseudo ;-)
> class f {
> int operator()(int a) { return a+1; };
> };
> transform(x.begin(), x.end(), x.begin(), f);
> };
>
> ( x = {2,3,4,5} )
>
> Sure, in C++ x is bound to a new value, while this doesn't happen in the
> SML version, but the intent of the developer is the same. If the C++
> writer didn't want the optimisation of an in-place update, they'd have
> used a different third argument to transform. It's even possible that
> under the hood, an SML compiler would do the in-place optimisation, if
> it could deduce that x wasn't needed anywhere else and was therefore
> garbage afterward.
>
> I still think that for the purposes of naming, the name used with C++
> metaprogramming should be the same as the name used with C++ non-meta
> programming, when the intent is the same. (And if the C++ term is
> accumulate as opposed to for_each, so be it.) But the cons operation
> deserves to be called push_front in compile-time C++, even if run-time
> C++'s push_front isn't exactly the same.
>
> Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk