From: Oscar Fuentes (ofv_at_[hidden])
Date: 2002-02-07 16:47:00
Jaakko Jarvi <jajarvi_at_[hidden]> writes:
> > Well, I was unable to compile with gcc 3.0.3 (cygwin) and 2.95.3
> > (mingw). All test I've tried gave the same errors:
> > The offending line in actions.hpp is
> > BOOST_STATIC_CONSTANT(bool, value =
> > (boost::is_base_and_derived<protectable, T>::value));
> > I'm using boost v 1.26.0. Do I need the current CVS sources?
> Oh yes. is_base_and_derived was only added in January. :(
I've reported some hours ago that it works with 1.27.0. Somehow my
e-mail doesn't appear on the list so far. Just in case it was lost, I
repeat that gcc 3.0.3 (cygwin) gives this warning:
In file included from /t/boost/boost/lambda/lambda.hpp:19,
/t/boost/boost/lambda/core.hpp:61: warning: identifier name `_1'
conflicts with GNU C++ internal naming strategy
Same for _2, _3.
No problem with gcc 2.95.3-6 (mingw) apart from the ones you detected.
> > " ... the lambda expression _1 + 1 can be seen as syntactic sugar
> > for the pseudo code bind(operator+, _1, 1). "
> > Should be "... the lambda expression 1 + _1 ...". This way the order
> > of arguments is the same for both expressions. Note that you later
> > define an asymmetric operator+ in another example.
> Can you elaborate this? I can't see what is wrong with the argument
_1 + 1 ---> operator+(?, 1)
bind(operator+, _1, 1) ---> operator+(1, ?)
If operator+ is not symmetrical you have an inconsistency. (You define
an assymetric operator+ later:
However, there are cases when the return type cannot be deduced. For
example, suppose you have defined:
C operator+(A, B);
As you can see, this is a cheap correction. If you know C++ enough to
use the LL, you don't get caught by this :-)
> > "for_each(v.begin(), v.end(), _1 = bind(foo, _1));"
> > 'for_each' is a non-mutating algorithm. 'transform' is better for this
> > case.
> Yes, for_each only requires the iterators to be InputIterators and I guess
> that is why it is listed as non-modifying sequence operation.
> I'm not sure what to do with this. To me code like this
> for_each(a.begin(), a.end(), ++_1);
> compared to this
> transform(a.begin(), a.end(), a.begin(), _1 + 1);
> looks more intuitive.
> Both will work, but the former may be (mis)using for_each in a
> non-conformant way.
Right. As Gary Powell pointed out, that 'for_each' requirement is a
> We can always define
> with a less constraining requirements to go around this :)
Oh, yes. Simply copy & paste std::for_each and omit the constraining
from the docs :-)
> > (1) Having recursion would be great.
> > > (2) Having some kind of 'let' form
> Something to think about :)
Hope this is not too difficult. It would open a new dimension for LL's
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk