- Boost - lists.boost.org

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

[quickbook] broken on 64bit ubuntu
by Daniel Pfeifer 24 Feb '11

24 Feb '11

Hi, Quickbook version 1.5.4 (that is included in Boost 1.46) reports the following error: > error: Unknown version of quickbook: quickbook 1.32741 The reported version number is different on each run. On a 32 bit install, quickbook works. I get this error only on 64 bit. cheers, Daniel

3 3

[local] Simplifying the parenthesized syntax
by Lorenzo Caminiti 24 Feb '11

24 Feb '11

On Sun, Feb 6, 2011 at 10:26 AM, Vicente Botet <vicente.botet(a)wanadoo.fr> wrote: > The fact that you can not use variadic macros at work doesn't means that > your library can not provide in addition variadic macros on compilers > supporting them. I have no idea the work that this suppose, but if the > interface could be more appealing your library will have much more people > interested in. > > Have you an idea of how the interface could be simplified if variadic macros > were used? The purpose of this email if to brainstorm possible ideas to simplify the parenthesized syntax. Sorry in advance if not all that I say is correct -- I haven't implemented it yet so I might be saying inaccurate/unfeasible things here and there. As always, your feedback is very welcome :) PRELIMINARY IDEAS TO SIMPLIFY THE PARENTHESIZED SYNTAX Consider the following parenthesized syntax for local functions: (void) (f)( (int)(x) (double&)(y) (const bind)((a)(&b)) (bind)((&c)(d)) ) // [0] The followings are possible ways to simply this syntax. 1 MERGING PARAMETER TYPES AND NAMES (C++ preprocessor) Parameter names can be passed to function types so I can transform `int x` into `int` at compile-time: int x --[make function type]--> void (int x) --[get 1st parm type]--> int This should allow me to simplify the parenthesized syntax [0] to: (void) (f)( (int x) (double& y) (const bind)((a)(&b)) (bind)((&c)(d)) ) // [1] Note that the (unbound) parameter type and name are merged into a single sequence element. The following should also be possible: (void) (f)( (int x) (double& y) (const bind a) (const bind& b) (bind& c) (bind d) ) // [1a] Is [1a] simpler than [1]? Maybe it is... 2 TOWARD THE NORMAL PARAMETER LIST SYNTAX (C99 preprocessor) Using variadic macros I _might_ be able to use a variable length tuple (can I? I am not very familiar with these yet...) instead of a sequence to represent the function parameters: (void) (f)(int x, double& y, const bind a, const bind& b, bind& c, bind d) // [2] I think, this is a great simplification over [0] because it is the exact same syntax used by C++ to declare function parameters! Note that `const bind` and `bind` have been distributed to all the bound parameters. Given that sequences are best avoided here (to reduce extra parenthesis), I do not think there is a less verbose way to enumerate the bound parameters. The followings could also be possible: (void) (f)(int x, double& y, const bind (a, &b), bind (&c, d) ) // [3] (void) (f)(int x, double& y) (const bind)(a, &b) (bind)(&c, d) // [4] But I think enumerating every bound variable separately as in [2] makes the parameter list syntax look the closet to normal C++ syntax even if it requires the repetition of `const bind` and `bind` as the types of the bound variables. Therefore, I would prefer [2] over both [3] and [4]. 3 RETURN TYPE AND FUNCTION NAME (C++ and C99 preprocessors) I don't know how/if I can simplify the passing of the return type and function name because I do need the function name as a separate token within the preprocessor to do token concatenation and generate unique names that refer to the function name... Something like this should be possible (using tuples instead of sequences): void, f, ( (int)(x) (double&)(y) (const bind)((a)(&b)) (bind)((&c)(d)) ) // [5] void, (f)( (int)(x) (double&)(y) (const bind)((a)(&b)) (bind)((&c)(d)) ) // [6] And again, on C99: void, f, (int x, double& y, const bind a, const bind& b, bind& c, bind d) // [7] void, (f)(int x, double& y, const bind a, const bind& b, bind& c, bind d) // [8] However, I don't see how these are simpler than [0] and [2]. I need to think about this more to see if other syntaxes are possible... 4 DEFAULT PARAMETER VALUES (C++ and C99 preprocessors) Currently local functions support default parameters via the following parenthesized syntax: (void) (f)( (int)(x)(default)(-1) (double)(y)(default)(1.23) ) // [9] I think this could be simplified to (note the removal of the parenthesis around the default value): (void) (f)( (int)(x)(default -1) (double)(y)(default 1.23) ) // [10] An additional simplification could be to merge parameter types and names together as in [1]: (void) (f)( (int x)(default -1) (double y)(default 1.23) ) // [10a] Plus using C99 variadics as in [2]: (void) (f)(int x, default -1, double y, default 1.23) // [11] I am not a big fan of this because `default` is separated from its parameter by the comma `,`... but I don't think I can do better than this. 5 OTHERS CONSIDERATIONS These considerations are not directly relevant to local functions but the parenthesized syntax [0] was designed as a general syntax that makes *all* the elements of a function declaration available for preprocessor metaprogramming. Instead, syntaxes [1] and [2] cannot separate the parameter type token from the parameter name token at preprocessing time. Therefore: a) I don't think [1] and [2] allow to generate a parameter with the specified name but a different type. For example, say I want to add `const&` to `int x`, how can I do that unless `int x` is specified as `(int)(x)` or `(int, x)`? int x --[how can I do this??]--> add_reference<add_const<int>::type>::type x (I have to double check, but I don't think local functions need to manipulate parameter types retaining instead the parameter names so I don't think this is an issue for local functions.) b) Having the parameter names as separate tokens (which is possible with [0] but not with [1] or [2]) could be useful to generate unique names to handle function overloading (even if with some limitations). For example, in another library, I concatenate the function name token with the parameter name tokens to generate unique names for overloaded functions. As long as the overloaded functions use different parameter names (and not just different parameter types) this mechanism works. (Overloading is not supported for local functions -- see Rationale in library docs -- so this is not an issue for local functions.) Therefore, *IF* there was an interest in defining the parenthesized syntax to be as general as possible so it could be adopted everywhere macros spoil function definitions (to avoid requiring programmers to learn different syntaxes for the different macros), [0] is more general because it separates the parameter types from their names (at the cost of the extra parenthesis of course). Of all of these syntaxes, I _personally_ like [0] because it is pure C++ preprocessor and it is the most general (maybe with simplification [10] for default parameters). I also would like to provide [2] if the C99 preprocessor is detected -- ideally, the same parsing macros will be smart enough to accept both [2] and [0] on C99 and just [0] on pure C++ preprocessors. -- Lorenzo

8 19