- Boost - lists.boost.org

gcc4.3 warning for multiple scope_exits
by Kim Barrett 14 Jul '09

14 Jul '09

Boost.ScopeExit uses a tricky bit of code (from Steven Watanabe) to allow a macro expansion to contain code which will declare a variable exactly once, regardless of how many times the macro is used in a given scope. Unfortunately, gcc4.3 -Wall generates a warning for this code in the second and later uses of the macro in the same scope. The warning is comparisons like X<=Y<=Z do not have their mathematical meaning It is complaining about a statement that gets parsed as identifier < 0 > variable; Valid code, and correct in this particular case, but the warning is there never the less. I realize that boost doesn't have a no-warnings policy (dealing with compiler variations that lead to actual errors is hard enough), but since my team has a general policy of using -Werror and I've been proselytizing the use of scope_exit within our group, I was motivated to find a way to kill this warning. After studying Steven's trick (ouch! my brain hurts) I've come up with an extension of the same technique which avoids the warning, using the time honored approach of adding another level of indirection. Here's my patch: ---------- --- scope_exit.hpp.orig 2009-07-09 13:19:36.000000000 -0400 +++ scope_exit.hpp.new 2009-07-09 13:20:04.000000000 -0400 @@ -36,14 +36,21 @@ typedef void* declared; struct undeclared { declared dummy[2]; }; + template<int> + struct holder + { + declared value; + static const int apply_value = 0; + friend void operator>(int, const holder&) {} + }; + template<> struct declare<sizeof(undeclared)> { template<int> struct apply { - declared value; - friend void operator>(bool, const apply&) {} + static const int apply_value = 0; }; }; @@ -214,8 +221,9 @@ BOOST_PP_SEQ_FOR_EACH_I(BOOST_SCOPE_EXIT_AUX_MEMBER, id, seq) \ BOOST_SCOPE_EXIT_AUX_PARAMS_T_CTOR(id, seq) \ } BOOST_SCOPE_EXIT_AUX_PARAMS(id) BOOST_SCOPE_EXIT_AUX_PARAMS_INIT(id, seq)\ - boost::scope_exit::aux::declare<sizeof(boost_scope_exit_args)> \ - ::apply<0> boost_scope_exit_args; \ + boost::scope_exit::aux::holder< \ + boost::scope_exit::aux::declare<sizeof(boost_scope_exit_args)> \ + ::apply<0>::apply_value> boost_scope_exit_args; \ boost_scope_exit_args.value = &BOOST_SCOPE_EXIT_AUX_PARAMS(id); \ struct BOOST_SCOPE_EXIT_AUX_GUARD_T(id) { \ BOOST_SCOPE_EXIT_AUX_PARAMS_T(id)* boost_se_params_; \

2 4

[task] new version 0.2.2
by k-oli＠gmx.de 13 Jul '09

13 Jul '09

Hello, I've added boost.task-0.2.2 to boost.vault: - allow user-defined execution policies - private inheritance from noncopyable removed from task< R > and static_pool< R > copy-ctor and assignment-op private and unimplemented allowing correct move-semantics - worker_group removes all worker-threads in join_all() static_pool< R > does contain zero worker-threads after shutdown() or shutdown_now() - reintroduction of make_task() - internal refactoring/rework - documentation updated - tests updated - examples updated best regards, Oliver

1 0

MS VC 2010 Beta 1
by Dennis Yurichev 13 Jul '09

13 Jul '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi. Somebody already had a success on building Boost with new MS VC 2010 Beta 1? - -- My PGP public key: http://yurichev.com/dennis.yurichev.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpXG0UACgkQ1YPmFmJG++N68gCg2YD+xA03lNt4AKnKBd435h/C JP8AnRXr+MRktAzGLIFTWRUQJMHmySGl =ctCu -----END PGP SIGNATURE-----

2 1

program_options custom validators
by Zachary Turner 13 Jul '09

13 Jul '09

Hello, recently I was faced with a situation of writing a custom validator for a certain command line option I wanted to handle. The validator was supposed to check whether the value on the command line was in a certain range. After some head scratching, I realized there's no elegant way to do this with the current validation overload function. In the end I just ended up doing the validation after the options had been parsed. I was thinking about a good way to support this, and I thought that maybe the best way is to add an additional value semantic so that the validate function could instead be: template<class T, class validation_data> void validate(boost::any& v, const std::vector<std::string>& values, const validation_data& data, T* target_type, int); and we could write add_options() ("test", value<int>()->validate(boost::interval<int>(1, 10)) ); this would require the user to provide the following overload: void validate(boost::any& v, std::vector<std::string>& values, const boost::interval<int>& data, int* target_type, int); the default implementation of validate would all use some dummy type for validation_data, this way compilation would fail if user calls validate but does not provide the appropriate overload. And if the user does not want to provide additional validation data he can simply use the current syntax, but instead would provide the following validate() overload void validate(boost::any& v, const std::vector<std::string>& values, const no_validation_data& data, T* target_type, int); Thoughts? Zach

2 3

intrusive_ptr design question
by Zachary Turner 13 Jul '09

13 Jul '09

I was wondering from a design perspective, why was it decided that intrusive_ptr should rely on user-defined free functions intrusive_ptr_add_ref and intrusive_ptr_release to handle the reference counting? This makes it somewhat inconvenient, for some constant type T, to support having two different instances of intrusive_ptr<T>, each of which use a different reference counting strategy. If there's a clever way to allow this that I'm missing please advise.

9 20

type_traits/call_traits and function_traits : Why are they separate
by joel 12 Jul '09

12 Jul '09

Is there anything that prevent those three libraries (type_traits,call_traits and function_traits) to be merged in a single traits library ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

1 0

Re: [boost] [serialization][trunk] Latest patch for void_cast.cpp causes segfaults
by Hartmut Kaiser 11 Jul '09

11 Jul '09

> apparently the latest patch to > boost/libs/serialization/src/void_cast.cpp > (rev.53078, svn:date: 2009-05-18T06:25:56.023190Z, svn:author: ramey, > svn:log: fix errors in extended_type_info management) causes an > existing application to segfault during cleanup. The application was > working properly before. The attached patch fixes the issue. > > Ok to commit? Ping? Regards Hartmut

3 8

Debug Assertion Failed while trying to use read_graphviz
by Anna Kazeykina 11 Jul '09

11 Jul '09

Hello, I tried to compile and run in VS 2008 the following example illustrating how to use read_graphviz() function: #include <boost/graph/graphviz.hpp> #include <boost/graph/adjacency_list.hpp> #include <string> #include <sstream> using namespace boost; using namespace std; int main() { // Vertex properties typedef property < vertex_name_t, std::string, property < vertex_color_t, float > > vertex_p; // Edge properties typedef property < edge_weight_t, double > edge_p; // Graph properties typedef property < graph_name_t, std::string > graph_p; // adjacency_list-based type typedef adjacency_list < vecS, vecS, directedS, vertex_p, edge_p, graph_p > graph_t; // Construct an empty graph and prepare the dynamic_property_maps. graph_t graph(0); dynamic_properties dp; property_map<graph_t, vertex_name_t>::type name = get(vertex_name, graph); dp.property("node_id",name); property_map<graph_t, vertex_color_t>::type mass = get(vertex_color, graph); dp.property("mass",mass); property_map<graph_t, edge_weight_t>::type weight = get(edge_weight, graph); dp.property("weight",weight); // Use ref_property_map to turn a graph property into a property map boost::ref_property_map<graph_t*,std::string> gname(get_property(graph,graph_name)); dp.property("name",gname); // Sample graph as an std::istream; std::istringstream gvgraph("digraph { graph [name=\"graphname\"] a c e [mass = 6.66] }"); bool status = read_graphviz(gvgraph,graph,dp,"node_id"); return 0; } When I run the program I get the Debug Assertion Failed message (when I delete the line with read_graphviz everything is OK). Could you please help me with this problem? Thank you, Anna.

2 1

Build changes for 1.40
by Vladimir Prus 11 Jul '09

11 Jul '09

FYI, I've merged Boost.Build from trunk to release branch. The most important change is that now, on Unix, default build with act as if --layout=system is specified, creating libraries with no decoration that can be conveniently used. Other changes are documented at: http://beta.boost.org/users/news/version_1_40_0 Let me know if this causes any problems. - Volodya

1 0

Boost.Range too focused on iterators?
by j j 11 Jul '09

11 Jul '09

The boost range library makes ranges similar to the to the STL Container<http://www.sgi.com/Technology/STL/Container.html>concept. A Range provides *iterators* for accessing a half-open range [first,one_past_last) of elements and provides information about the number of elements in the Range. Wouldn't it be better if it could use *values* and iterators? eg template<class access> ostream& operator<<(ostream& out,const range<access>& in){ for(x temp=in.a;temp!=in.b;temp++)cout<<access()(temp); return out; } //Later on in code //prints a range of numbers cout<<Range<no_deref >(0,8); //no_deref is a function object that returns a reference to its argument. //prints the contents of a range of iterators. string a="Hello World!"; cout<<Range(a.begin(),a.end()) //defaults to deref which is a function object that derefences its argument with *

2 1