- Boost - lists.boost.org

[Boost-announce] Review Conclusion - Futures Library
by Tom Brinkman 21 Apr '09

21 Apr '09

Review Conclusion - Futures Library Braddock Gaskill http://braddock.com/~braddock/future Anthony Williams http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp The lack of examples and documentation made them difficult to review. Nevertheless, Anthony Williams futures library did receive almost unanimous and enthusiastic support. Unfortunately, the depth of the support was very shallow. I just finished my first read of Anthony's book "C++ Concurrency in Action and acknowledge his expertise in the areas of multi threaded and parallel programming. (http://www.manning.com/williams/) Anthony is the maintainer of boost::threads. Anthony's Future library has been approved for the next major release of c++ standard. Conclusion Braddock Gaskill - Rejected Anthony Williams - Approved Anthony's Futures library is approved for inclusion into boost::threads. As he is the maintainer of that library, he should be given maximum latitude about how that is to be done. In the future, if Anthony wants to re-publish the library as a top-level boost library, then he needs to resubmit it again with samples and test cases, which are lacking. Requirements As per the usual boost library requirements, examples and test cases are needed. Anthony should also improve the documentation, which should not be a problem as he is a prolific author in the area of multi threaded programming. Review Manager Tom Brinkman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

3 2

[mpi] Automatically Cascading/Nested Reduce?
by Dean Michael Berris 21 Apr '09

21 Apr '09

Hi Guys, I'm writing quite a number of parallel-distributed applications in the day job, and I'm missing a facility which allows for "automagically" nesting my reductions. The reduction strategy I'm looking for is one of a networked approach where (if you can imagine a tree): 0 |-1 | |-2 | |-3 | |-4 |-5 |-6 Nodes 2 and 3 send their data to node 1, node 5 and 6 send their data to node 4, and eventually node 1 and 4 send their (reduced) data to node 0. My idea is that it should be simple to implement this without having to go through too much trouble with communicators -- or that it could be automagically done by hiding the communicator splits in the special reduce implementation. Would something like this be best implemented within Boost.MPI? Or is there a way of implementing this by composing the functionality already available in Boost.MPI? The reason I ask is that sometimes the reduction step dominates the amount of time the application spends especially when you have quite a number of nodes (around 90ish). Being able to parallelize (or nest) the reduction would definitely help, but the cost of supporting that routine over a number of applications seems to warrant a special implementation of the Boost.MPI reduce. TIA -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

2 3

Problem with write_graphviz
by Josep TORRAS FLAQUER 21 Apr '09

21 Apr '09

Hello, I'm working with boost graph library. I'm creating a graph and i'd like to write its description into a file or to display it on the screen. The properties of Edges and Vertex are bundled, and i'm not able to write them. I have read the doc once and again and i don't get to find a solution. I have looked for examples but i haven't found anything actually useful for me. Could anyone please help me or propose a possible solution? Here is my code: #include <boost/graph/iteration_macros.hpp> #include <string> #include <boost/tuple/tuple.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/visitors.hpp> #include <boost/graph/breadth_first_search.hpp> #include <map> #include <boost/graph/adj_list_serialize.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/multi_array.hpp> #include <cassert> #include <boost/graph/graphviz.hpp> //using namespace boost; struct VertexProperties{ std::string gate_type; int gate_level; int gate_index; int num_input; float prob_err; }; struct edge_properties { std::string name; }; typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, VertexProperties , edge_properties> Graph; typedef boost::graph_traits<Graph>::vertex_descriptor Vertex; typedef boost::graph_traits<Graph>::edge_descriptor Edge; int main() { int i=0; //const char* name = "123"; Graph g; Vertex u1; u1=add_vertex(g); g[u1].gate_type = "Input"; g[u1].gate_level=1; g[u1].gate_index=i; g[u1].num_input=0; g[u1].prob_err=0; i++; Vertex u2; u2=add_vertex(g); g[u2].gate_type = "Input"; g[u2].gate_level=1; g[u2].gate_index=i; g[u2].num_input=0; g[u2].prob_err=0; i++; Vertex u3; u3=add_vertex(g); g[u3].gate_type = "Input"; g[u3].gate_level=1; g[u3].gate_index=i; g[u3].num_input=0; g[u3].prob_err=0; i++; Vertex u4; u4=add_vertex(g); g[u4].gate_type = "XOR"; g[u4].gate_level=2; g[u4].gate_index=i; g[u4].num_input=0; g[u4].prob_err=0.001; i++; Vertex u5; u5=add_vertex(g); g[u5].gate_type = "AND"; g[u5].gate_level=1; g[u5].gate_index=i; g[u5].num_input=0; g[u5].prob_err=0.001; i++; Vertex u6; u6=add_vertex(g); g[u6].gate_type = "XOR"; g[u6].gate_level=1; g[u6].gate_index=i; g[u6].num_input=0; g[u6].prob_err=0.001; i++; Vertex u7; u7=add_vertex(g); g[u7].gate_type = "AND"; g[u7].gate_level=1; g[u7].gate_index=i; g[u7].num_input=0; g[u7].prob_err=0.001; i++; Vertex u8; u8=add_vertex(g); g[u8].gate_type = "OR"; g[u8].gate_level=1; g[u8].gate_index=i; g[u8].num_input=0; g[u8].prob_err=0.001; i++; Edge e1; e1=(add_edge(u1,u4,g)).first; Edge e2; e2=(add_edge(u1,u5,g)).first; Edge e3; e3=(add_edge(u2,u4,g)).first; Edge e4; e4=(add_edge(u2,u5,g)).first; Edge e5; e5=(add_edge(u3,u6,g)).first; Edge e6; e6=(add_edge(u3,u7,g)).first; Edge e7; e7=(add_edge(u4,u6,g)).first; Edge e8; e8=(add_edge(u4,u7,g)).first; Edge e9; e9=(add_edge(u5,u8,g)).first; Edge e10; e10=(add_edge(u7,u8,g)).first; const char* name[] = { "Input 1", "Input 2", "Input 3","XOR","AND","XOR","AND","OR"}; int index[] = {g[u1].gate_index,g[u2].gate_index,g[u3].gate_index,g[u4].gate_index,g[u5].gate_index,g[u6].gate_index,g[u7].gate_index,g[u8].gate_index}; write_graphviz(std::cout, g, boost::make_label_writer(name)); } I am able to write a label, but i can't write all the properties, and that's what i want. Thank you. Josep

2 2

[Math] Making math compile on C99 archs with no long double
by Seth LaForge 21 Apr '09

21 Apr '09

In trying to compile Boost 1.38.0 for arm/gcc-4.1.2, which has no long double support, I ran into the following compile error: ./boost/math/special_functions/expm1.hpp: In function ‘long double boost::math::expm1(long double, const boost::math::policies::policy<boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy>&)’: ./boost/math/special_functions/expm1.hpp:270: error: ‘::expm1l’ has not been declared The fix is simple - the expm1.hpp is trying to use a long double C99 function despite BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS being defined. The following patch (also attached in case gmail mangles it) fixes the problem: diff -r -u boost_1_38_0.orig/boost/math/special_functions/expm1.hpp boost_1_38_0/boost/math/special_functions/expm1.hpp --- boost_1_38_0.orig/boost/math/special_functions/expm1.hpp 2009-01-07 08:37:59.000000000 -0800 +++ boost_1_38_0/boost/math/special_functions/expm1.hpp 2009-04-20 18:24:33.312485307 -0700 @@ -267,10 +267,12 @@ #if defined(BOOST_HAS_EXPM1) && !(defined(__osf__) && defined(__DECCXX_VER)) # ifdef BOOST_MATH_USE_C99 inline float expm1(float x, const policies::policy<>&){ return ::expm1f(x); } +# ifndef BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS inline long double expm1(long double x, const policies::policy<>&){ return ::expm1l(x); } -#else +# endif +# else inline float expm1(float x, const policies::policy<>&){ return ::expm1(x); } -#endif +# endif inline double expm1(double x, const policies::policy<>&){ return ::expm1(x); } #endif

2 1

BoostCon lodging
by Sebastian Redl 20 Apr '09

20 Apr '09

Hi list, Two things. First, a comment at the BoostCon lodging page[1] gave me the impression that lodging for two isn't actually cheaper than for one. Is this correct? Second, is anyone interested in sharing a room at a place where this actually is cheaper? (And do you have recommendations for such a place?) I have to pay for lodging myself and would like to reduce the costs. Regards, Sebastian [1] http://www.boostcon.com/location/lodging#reservations

3 3

[smart_ptr] post 1.34 regression
by Gennadiy Rozental 20 Apr '09

20 Apr '09

Hi, Following snippet compiles fine with 1.34.1 -------------------------- #include "boost/shared_ptr.hpp" class Base { public: virtual ~Base() {} }; class Derived; boost::shared_ptr<Base> foo() { return boost::shared_ptr<Derived>(); } class Derived : public Base {}; -------------------------- It fails though with boost 1.36: a.cpp: In function `boost::shared_ptr<Base> foo()': a.cpp:13: error: conversion from `boost::shared_ptr<Derived>' to non-scalar type `boost::shared_ptr<Base>' requested Looks like it caused by additional argument in template constructor sp_enable_if_convertible. Is it intentional? Can we still support old use case? Gennadiy

2 1

[SCOPE_EXIT] compiler errors for structure members
by Sid Sacek 20 Apr '09

20 Apr '09

struct { int one; } test ; test.one = 55; BOOST_SCOPE_EXIT( ( test.one ) ) { } BOOST_SCOPE_EXIT_END The above code gives me lots of compiler errors. Is there a special syntax I have to provide to be able to use structure members? Thanks, -Sid Sacek The errors I get using MSVC 2008 are: error C2065: 'boost_se_tag_0_12' : undeclared identifier error C2144: syntax error : 'int' should be preceded by ')' error C2059: syntax error : ')' error C2065: 'boost_se_tag_0_12' : undeclared identifier error C2143: syntax error : missing ')' before 'constant' error C2039: 'type' : is not a member of '`global namespace'' error C2653: 'boost_se_wrapped_t_0_12' : is not a class or namespace name error C2143: syntax error : missing ';' before '{' error C2065: 'boost_se_param_t_0_12' : undeclared identifier error C2065: 'boost_se_tag_0_12' : undeclared identifier error C2065: 'boost_se_tag_0_12' : undeclared identifier error C2143: syntax error : missing ',' before 'constant' C2143: syntax error : missing ',' before ')' error C2653: 'boost_se_params_t_12' : is not a class or namespace name error C2143: syntax error : missing ';' before '{' error C2143: syntax error : missing ';' before '}' error C2143: syntax error : missing ';' before '}' error C2143: syntax error : missing ',' before ')'

2 6

[graph] a patch for dominator_tree.hpp
by Jongsoo Park 20 Apr '09

20 Apr '09

Hi all, Recently, I've got few mails concerning about the performance of my dominator tree implementation in the boost graph library, which can be solved by a simple modification. The attached file is my patch on that problem which is based on the most recent version in the subversion repository. Could somebody who has a permission to modify the code apply this patch? The patch has only 5 lines difference and I've double checked it works correctly. Thanks, Jongsoo

2 2

[math] merge of signbit(-NaN) fix?
by Francois Barel 20 Apr '09

20 Apr '09

Hi, Boost.Math had some changes on trunk a few months ago, on the implementation of signbit, to fix the invalid result of signbit(-NaN) (fixed by using Johan Rade's fp_traits library). Currently, in order to work with multiple Boost releases, Spirit2x uses: - a custom version of signbit when compiled against an older Boost release, - the Boost.Math implementation when compiled against Boost 1.39 or later (on the assumption that those changes will be in Boost 1.39). But looking at the schedule sent by Beman, we're nearing the 1.39 beta (some time this week), and those changes have not been merged to release branch. I was wondering, is it planned to merge them for 1.39, or will it only be done in a later release? Thanks, François

1 0

Building stage by default, pt. 2
by Vladimir Prus 19 Apr '09

19 Apr '09

Hi, previously, we discussed that building the 'stage' target by default would be a good idea -- since some users forget that and don't have an easy way to get at built libraries. See: http://thread.gmane.org/gmane.comp.lib.boost.devel/182787 I've now implemented the change, taking into account the comments in that thread. In particular: - the message now uses absolute paths - the location of headers is explicitly specified Here's an example of the message that is output if you do "./bjam" in Boost root: Building C++ Boost. After the build, the headers will be located at /home/ghost/Work/Boost/boost-svn The libraries will be located at /home/ghost/Work/Boost/boost-svn/stage/lib Use 'bjam install --prefix=<path>' if you wish to install headers and libraries to a different location and remove the source tree. I was considering outputting a 'summary' at the end of the build, as opposed at the beginning, but that would require some Boost.Jam changes and therefore cannot be accomplished at this point of release cycle. Anybody wishes to comment on the wording before this gets merged to release branch? - Volodya

3 6