- Boost - lists.boost.org

[Review] Phoenix V3: Mini-review starts February 20th
by Hartmut Kaiser 26 Feb '11

26 Feb '11

Hi all, Thomas Heller worked hard to address the outstanding issues of the original Phoenix review. He ported Phoenix to Boost.Proto. As mandated by the original Boost review, we will conduct a mini-review of his Phoenix V3 library. This mini-review starts today, February 20th, 2011 and ends on March 2nd, 2011. ------------------ About the library: The Phoenix library enables FP techniques such as higher order functions, lambda (unnamed functions), currying (partial function application) and lazy evaluation in C++. The focus is more on usefulness and practicality than purity, elegance and strict adherence to FP principles. Phoenix is a very important infrastructure library. It is currently a utility library included with Spirit V2 and therefore is already available for years from the latest Boost distributions (headers: $BOOST_ROOT/boost/spirit/home/phoenix, docs: $BOOST_ROOT/libs/spirit/phoenix, or http://www.boost.org/doc/libs/1_45_0/libs/spirit/phoenix/index.html) ------------------ The code of new Phoenix V3 (that's what we mini-review) can be found at: https://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/ the documentation is at: http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/ht ml/index.html ------------------ Here are the questions raised during the initial review of Phoenix in September 2008 (see here: http://thread.gmane.org/gmane.comp.lib.boost.devel/180753) <quote> We will have a mini review before Phoenix gets merged to SVN to make sure whether the feedback from the v2 review was accommodated. Additionally this review will have to discuss: - the breaking interface changes from v2 - the migration path from boost::bind and lambda to Phoenix - how the interoperability with std::bind is solved (result_of semantics) - C++0x features such as rvalue references and variadic templates - the new extensibility mechanism - unified placeholders and interoperability issues with other Proto-based DSELs (such as Spirit.Qi, Spirit.Karma, and Xpressive) - compile times </quote> Please note that Phoenix already has been accepted as a Boost library. We don't vote about that anymore. The purpose of this mini-review is to discuss if the newly rewritten Phoenix V3 addresses the outstanding issues from the main review. In the end I will have to make the decision whether to include the new library into SVN trunk. I really hope to see your participation in the discussions on the Boost mailing lists! Regards Hartmut Review Manager --------------- http://boost-spirit.com

4 15

XInt formal review forthcoming
by Vladimir Prus 25 Feb '11

25 Feb '11

Boosters, the review of Boost.XInt library, by Chad Nelson, is scheduled to start on Wednesday, March 2, and will run through Friday, March 11. I will be serving as review manager. Over the years, arbitrary precision arithmetics has been a hot topic on Boost mailing lists, but now we have a concrete proposal that may become an official Boost library. So, block the time on your calendar, and get ready. Thanks, -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

1 0

svn "Could not read response body"
by Frank Mori Hess 25 Feb '11

25 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does anyone else get errors like the following when trying to do things like "svn update"? "svn: REPORT of '/svn/boost/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.boost.org)" I've seen it occasionally for a while, but it seems to be getting worse now. I can rarely get an svn update to complete. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1nu5kACgkQ5vihyNWuA4We5gCdGZqLMGx2sNMmBs5ihbV4kZJG 4u8An3KpHc22JUMP2KaAqHDtjm18uU6b =62Ci -----END PGP SIGNATURE-----

2 1

[1.46] PDF Build of the docs available
by John Maddock 25 Feb '11

25 Feb '11

A PDF build of Boost's documentation for 1.46 is now available from: http://sourceforge.net/projects/boost/files/boost-docs/1.46.0/ Note that this only includes that subset of Boost which uses quickbook/boostbook/docbook for documentation. Enjoy, John.

4 3

[fusion] Signature Params -> vector
by Daniel Larimer 25 Feb '11

25 Feb '11

I would like to know if there is an existing way to achieve the following: params_to_vector<void(int,double,string)>::type => boost::fusion::vector<int,double,string>

2 3

[ratio] Request to merge to release branche
by Vicente Botet 25 Feb '11

25 Feb '11

Hi, I would like to merge Boost.Ratio to the release branch as soon as possible. Let me know if there is something missing, and if I can do it? Thanks, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/ratio-Request-to-merge-to-release-branch… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 7

[fusion] sequence member pointer
by Daniel Larimer 25 Feb '11

25 Feb '11

I am attempting to use a fusion sequence with a visitor pattern that expects 'member function' or 'member data' pointers. What I would like to do is something like: &fusion::vector<int,double>::m1 But obviously this cannot work because of how fusion::vector<int,double> is implemented with a single vector_n<...> vec data member that is private. So trying to "reflect" a vector in the same way that I "reflect" a struct does not work. Any good ideas? Is there any reason why this 'implementation detail' needs to be hidden? Dan

2 3

[config] request for BOOST_NO_FWD_STD_DECLARATION
by Christopher Jefferson 25 Feb '11

25 Feb '11

libc++ does not allow forward declarations of types for std:: , as it uses inline namespace to allow versioning. Forward declarations occur in many libraries (config, fusion, interprocess). In each case I would like to just include the actual headers. I could just #define all cases for LIBCPP, but other libraries might move to using inline namespaces in future, so I could introduce a macro? Chris

13 38

Google Protocol Buffers library support module
by Rodrigo Souza 25 Feb '11

25 Feb '11

Hello All, I just developed a google protocol buffers library support module for boost build, and I am making this contribution available to everyone under the Boost License. The usage is pretty simple. add the following line in your user-config,jam using pb : /usr/local ; # assuming google protocol buffers is installed in /usr/local and in your Jamfile. import pb ; exe myapp : myapp.cpp messages.proto /pb//protobuflib ; This is the first version, and it doesn't support auto-detection. Enjoy, Rodrigo Pinho Pereira de Souza

1 0

tiny lambda snippet that fails to compile with boost 1.46
by Mark Van Dijk 25 Feb '11

25 Feb '11

I have a question about a particular problem I'm having with boost::lambda. I've distilled it down to a tiny complete app (shown below). The complier is complaining about bl::_1 is a const std::string, but &Map::value_type::second is a member_data_pointer to a non-const string. This line compiles with boost 1.42, but not in 1.46 (using MSVC 2008). I have two questions: 1) is the line of code in question actually valid? I.e. is this a boost::lambda bug or is this my bug? 2) If it is my bug, then to fix the code I need to coerce [&Map::value_type::second] to a CONST - problem is that the only way I can figure out is to use an ugly const_cast<>. Is there a cleaner way to do this? Source code follows: ------------------------------------------------------------------------------------------------------------ #include <iostream> #include <string> #include <map> #include <cassert> #include <boost/assign.hpp> #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> namespace bl = boost::lambda; int main() { // create two simple maps and populate them typedef std::map<long, std::string> Map; Map m = boost::assign::map_list_of(0, "hello ")(1, "world!"); // non-const map Map const cm = boost::assign::map_list_of(0, "hello ")(1, "world!"); // const map // this works: // concatenate the std::string parts of the non-const map and send to std::cout // std::string output; std::for_each( m.begin(), m.end(), output += bl::bind(&Map::value_type::second, bl::_1)); std::cout << output << std::endl; assert(output == "hello world!"); // works with boost 1.42, however it fails to compile with boost 1.46 // concatenate the std::string parts of the const map and send to std::cout // output.clear(); std::for_each( cm.begin(), cm.end(), output += bl::bind(&Map::value_type::second, bl::_1)); // <---- COMPILER ERROR HERE WITH BOOST 1.46 std::cout << output << std::endl; assert(output == "hello world!"); // this compiles, but uses an ugly const_cast<> // concatenate the std::string parts of the const map and send to std::cout // output.clear(); std::for_each( cm.begin(), cm.end(), output += bl::bind(const_cast<std::string const Map::value_type::*>(&Map::value_type::second), bl::_1)); // <---- UGLY std::cout << output << std::endl; assert(output == "hello world!"); return 0; }

1 0