[1.32 Release] MPL has been merged into the main trunk
Everything has been tested locally, so the disturbance should be minimal. I'll post a detailed changelog later today. Metacomm regressions have been restored to run against the main trunk. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Everything has been tested locally, so the disturbance should be minimal. I'll post a detailed changelog later today. Metacomm regressions have been restored to run against the main trunk.
-- Aleksey Gurtovoy MetaCommunications Engineering
Yikes! Where did apply_if go? The docs still talk about apply_if. Is its absence an oversight or by-design? -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> wrote in message news:41374F88.9010100@boost-consulting.com...
Aleksey Gurtovoy wrote:
Everything has been tested locally, so the disturbance should be minimal. I'll post a detailed changelog later today. Metacomm regressions have been restored to run against the main trunk.
-- Aleksey Gurtovoy MetaCommunications Engineering
Yikes! Where did apply_if go? The docs still talk about apply_if. Is its absence an oversight or by-design?
Can I assume it's now 'eval_if'? If so, I like it better, since there's no temptation to confuse apply_if and apply. Jonathan
Jonathan Turkanis wrote:
"Eric Niebler" <eric@boost-consulting.com> wrote in message news:41374F88.9010100@boost-consulting.com...
Aleksey Gurtovoy wrote:
Everything has been tested locally, so the disturbance should be minimal. I'll post a detailed changelog later today. Metacomm regressions have been restored to run against the main trunk.
Yikes! Where did apply_if go? The docs still talk about apply_if. Is its absence an oversight or by-design?
Can I assume it's now 'eval_if'?
If so, I like it better, since there's no temptation to confuse apply_if and apply.
Jonathan
Oh. How do I make my code work with old versions of MPL and new? There is no mpl/version.hpp or a macro I can test for conditional compilation AFAICT. I'll have to avoid both mpl::apply_if and mpl::eval_if and roll my own. :-( Is there a doc to help people migrating from the old to the new MPL? A list of differences? -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler writes:
Oh. How do I make my code work with old versions of MPL and new? There is no mpl/version.hpp or a macro I can test for conditional compilation AFAICT. I'll have to avoid both mpl::apply_if and mpl::eval_if and roll my own. :-(
As Joaquín already replied, you can test BOOST_VERSION.
Is there a doc to help people migrating from the old to the new MPL? A list of differences?
Like I mentioned in my original announcement, yes, it was forthcoming. Posted now. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Eric Niebler writes:
Oh. How do I make my code work with old versions of MPL and new? There is no mpl/version.hpp or a macro I can test for conditional compilation AFAICT. I'll have to avoid both mpl::apply_if and mpl::eval_if and roll my own. :-(
As Joaquín already replied, you can test BOOST_VERSION.
Thanks, Aleksey. Would there be any benefit to having a MPL-specific version macro? The iterator adaptors library has BOOST_ITERATOR_ADAPTORS_VERSION, for instance.
Is there a doc to help people migrating from the old to the new MPL? A list of differences?
Like I mentioned in my original announcement, yes, it was forthcoming. Posted now.
Very helpful, thank you. I hope this doc is part of the 1.32 release. Also, the references to apply_if in the mpl documentation need to be changed to eval_if. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler writes:
Aleksey Gurtovoy wrote:
Eric Niebler writes:
Oh. How do I make my code work with old versions of MPL and new? There is no mpl/version.hpp or a macro I can test for conditional compilation AFAICT. I'll have to avoid both mpl::apply_if and mpl::eval_if and roll my own. :-(
As Joaquín already replied, you can test BOOST_VERSION.
Thanks, Aleksey. Would there be any benefit to having a MPL-specific version macro? The iterator adaptors library has BOOST_ITERATOR_ADAPTORS_VERSION, for instance.
I'm not sure why. Unless the library has its own release cycle (like Spirit), I don't see any benefit in having a library-specific macro.
Is there a doc to help people migrating from the old to the new MPL? A list of differences?
Like I mentioned in my original announcement, yes, it was forthcoming. Posted now.
Very helpful, thank you. I hope this doc is part of the 1.32 release.
Definitely.
Also, the references to apply_if in the mpl documentation need to be changed to eval_if.
The docs are still pending a major upgrade which will reflect all the changes. -- Aleksey Gurtovoy MetaCommunications Engineering
"Jonathan Turkanis" <technews@kangaroologic.com> writes:
"Eric Niebler" <eric@boost-consulting.com> wrote in message news:41374F88.9010100@boost-consulting.com...
Aleksey Gurtovoy wrote:
Everything has been tested locally, so the disturbance should be minimal. I'll post a detailed changelog later today. Metacomm regressions have been restored to run against the main trunk.
-- Aleksey Gurtovoy MetaCommunications Engineering
Yikes! Where did apply_if go? The docs still talk about apply_if. Is its absence an oversight or by-design?
Can I assume it's now 'eval_if'?
If so, I like it better, since there's no temptation to confuse apply_if and apply.
Yes. The problem was that "apply_if" had the wrong implications. mpl::apply applies lambda and then evaluates the resulting metafunction class. mpl::eval_if evaluates one of two nullary metafunctions, based on a condition. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uacw8xwl7.fsf@boost-consulting.com...
"Jonathan Turkanis" <technews@kangaroologic.com> writes:
"Eric Niebler" <eric@boost-consulting.com> wrote in message news:41374F88.9010100@boost-consulting.com...
Yikes! Where did apply_if go? The docs still talk about apply_if. Is its absence an oversight or by-design?
Can I assume it's now 'eval_if'?
If so, I like it better, since there's no temptation to confuse apply_if and apply.
Yes. The problem was that "apply_if" had the wrong implications. mpl::apply applies lambda and then evaluates the resulting metafunction class. mpl::eval_if evaluates one of two nullary metafunctions, based on a condition.
Yeah, that's what I meant. Jusging just by the names, 'apply_if' sounds like a conditional version of 'apply'. Jonathan
On Thu, Sep 02, 2004 at 10:49:33AM -0500, Aleksey Gurtovoy wrote:
Everything has been tested locally, so the disturbance should be minimal. I'll post a detailed changelog later today. Metacomm regressions have been restored to run against the main trunk.
You introduced one or more blanks behind a trailing backslash in boost/serialization/collection_traits.hpp, line 32. That causes a warning from g++ 3.4.1 on i686-pc-linux-gnu when compiling programs that use the serialization library. serialization library. Can you or Robert fix this, please? I ran grep over the whole directory tree. AFAICT, this is the only file where this error crept in. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de> writes:
On Thu, Sep 02, 2004 at 10:49:33AM -0500, Aleksey Gurtovoy wrote:
Everything has been tested locally, so the disturbance should be minimal. I'll post a detailed changelog later today. Metacomm regressions have been restored to run against the main trunk.
You introduced one or more blanks behind a trailing backslash in boost/serialization/collection_traits.hpp, line 32. That causes a warning from g++ 3.4.1 on i686-pc-linux-gnu when compiling programs that use the serialization library. serialization library. Can you or Robert fix this, please?
I ran grep over the whole directory tree. AFAICT, this is the only file where this error crept in.
Fixed. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
--- Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
Everything has been tested locally, so the disturbance should be minimal. I'll post a detailed changelog later today.
Yeeeeeuh... I'll look at it next week and see what changes I need to make to my pet MPL fraction/rational/big_integral sub-library (assuming I still have power to use the computer; this hurricane looks like it will run over my hometown). Cromwell Enage _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
Cromwell Enage writes:
--- Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
Everything has been tested locally, so the disturbance should be minimal. I'll post a detailed changelog later today.
Yeeeeeuh...
I'll look at it next week and see what changes I need to make to my pet MPL fraction/rational/big_integral sub-library
http://www.mywikinet.com/mpl/mpl_1_32_changelog.html might be of some help here, in particular "Numeric metafunctions protocol/infrastructure" subsection.
(assuming I still have power to use the computer; this hurricane looks like it will run over my hometown).
I hope it didn't! -- Aleksey Gurtovoy MetaCommunications Engineering
participants (6)
-
Aleksey Gurtovoy -
Christoph Ludwig -
Cromwell Enage -
David Abrahams -
Eric Niebler -
Jonathan Turkanis