July 2009 - Boost - lists.preview.boost.org

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

[sandbox.move] coexistence issues with boost.interprocess + small suggestion
by Jeffrey Hellrung 09 Jul '09

09 Jul '09

Hi, I suppose this is mostly addressed to Ion. It appears that containers in the move library in the boost sandbox can't coexist with containers from the boost.interprocess library. This isn't a problem for me currently (I can just use the containers from the move library), but it may be an indication of a larger problem with either or both libraries, so I figured it'd be worth sharing. I wasn't sure if this would be an appropriate trac ticket to file under boost.interprocess, as it involves technically non-boost code, but I can certainly do that if desired. So to be specific, the following program fails to compile (MSVC 2009, boost 1.39, include paths are boost root and $(BOOST_SVN)/boost-sandbox/move): -------- #include <boost/interprocess/containers/vector.hpp> #include <boost/container/vector.hpp> int main(int argc, char* argv[]) { boost::interprocess::vector< int > v1; // line 6 boost::container::vector< int > v2; // line 7 return 0; } -------- The compiler output is: -------- 1>.\main.cpp(7) : error C3083: 'container': the symbol to the left of a '::' must be a type 1>.\main.cpp(7) : error C2039: 'vector' : is not a member of 'boost' 1>.\main.cpp(7) : error C2065: 'vector' : undeclared identifier 1>.\main.cpp(7) : error C2062: type 'int' unexpected -------- Removing either the interprocess vector (include directive, variable declaration) pair or the move vector (include directive, variable declaration) pair produces a compilable program. Reversing the order of the include directives gives a different compiler error: -------- 1>E:\boost_1_39_0\boost/interprocess/containers/vector.hpp(24) : error C3083: 'interprocess_container': the symbol to the left of a '::' must be a type 1>E:\boost_1_39_0\boost/interprocess/containers/vector.hpp(24) : error C2039: 'vector' : is not a member of 'boost' 1>E:\boost_1_39_0\boost/interprocess/containers/vector.hpp(24) : error C2873: 'vector' : symbol cannot be used in a using-declaration 1>.\main.cpp(6) : error C2039: 'vector' : is not a member of 'boost::interprocess' 1>.\main.cpp(6) : error C2065: 'vector' : undeclared identifier 1>.\main.cpp(6) : error C2062: type 'int' unexpected -------- Any idea what's going on here? Am I just doing something really boneheaded, e.g., with the include paths? Additionally, I have a small suggestion for the move library. It would be somewhat more convenient if boost::is_movable<T> had a nested type typedef, e.g., if it inherited from mpl::bool_<...> or integral_constant< bool, ...>. As it stands, I don't think it can be used directly in MPL expressions such as mpl::and_. Thanks in advance, - Jeff

2 1

[Tuple] Addressing by named tag?
by Robert Jones 09 Jul '09

09 Jul '09

Am I correct in believing that tuples have to be accessed by element index, as in tuple.get<0>() Multi-Index container has a really nice facility to use named (well typed really) tags in these kind of expressions, but it seems tuples do not. Anyone fancy adding it to tuple? - Rob.

2 1

[convert] coversion between strings with different locales
by vicente.botet 09 Jul '09

09 Jul '09

Hi, I wanted to see how we can convert a double from a locale to another locale? Should I write double d =convert<string>::from(convert<double>::from(str)(_locale=f))(_locale=t); or I need double d = convert<double>::from(str)(_locale=f); convert<string>::from(d)(_locale=d); Or it si a better way? Best, _____________________ Vicente Juan Botet Escribá

2 3

[multi_array] Can only disable range checking by defining BOOST_DISABLE_ASSERTS macro
by John Reid 08 Jul '09

08 Jul '09

Defining BOOST_DISABLE_ASSERTS disables boost asserts over the entire compilation. It would be nice to have finer grained control over the range checking in multi_array via a boost.multi_array specific macro.

1 1