- Boost-users - lists.preview.boost.org

Re: [Boost-users] boost::interprocess boost::interprocess xsi_shared_memory
by Daniel Neuberger 12 Jan '11

12 Jan '11

Is there a reason for not finishing the implementation of XSI (System V) shared memory? It seems like most of the work is already done. If there is no reason not to, I might be able to finish the implementation so that it can be included in the next release. I know that POSIX may be sufficient for some, but System V allows for much better control using SELinux since it lives in kernel space. FYI: This is in response to http://thread.gmane.org/gmane.comp.lib.boost.user/64537. Thoughts? Thanks. - Daniel

4 7

memory leak when using shared_from_this
by jochemspek 12 Jan '11

12 Jan '11

hi there, I'm having trouble understanding the cause of a memory leak apparently caused by using 'shared_from_this'. The following is the case: I have a AbstractProperty class with XMLNode as subclass. there exist two typedefs for these classes, namely typedef shared_ptr< XMLNode > XMLNodePtr and similar for AbstractProperty. in the XMLNode class I have the member function 'addChild' that adds a child to the XMLNode instance. I keep a reference to the parent by calling chid->setParent(), *with a shared pointer to this*. This results in a (quite severe) memory leak. I can resolve the problem by using a shared_ptr with a null-deleter ( see f.e. http://lists.boost.org/boost-users/2008/05/36281.php ), but I don't quite understand *why* the leak occurs, as I understand it so that the shared_from_this is a weak_ptr to this. I would much appreciate any comments. thanks, Jochem //---------------------------begin code----------------------------- const XMLNodePtr XMLNode::addChild( const string name ){ XMLNodePtr child( new XMLNode() ); child->setParent( static_pointer_cast< XMLNode, AbstractProperty >( shared_from_this() ) ); m_children.push_back( child ); return( child ); } //---------------------------end code----------------------------- -- View this message in context: http://boost.2283326.n4.nabble.com/memory-leak-when-using-shared-from-this-… Sent from the Boost - Users mailing list archive at Nabble.com.

1 1

Linking Error on WaitForSingleObject
by Anish Chandak 12 Jan '11

12 Jan '11

Hello All, I have a very unusual linking issue. It might be trivial but I could not find any reference after searching on the mailing list and other forums. I wrote a very simple example code (attached at the end of message) for using boost lock and mutex. The same piece of code compiles fine without linking error in one Visual Studio Project and gives the following linking error in another Visual Studio Project. I have made sure that the VS settings for each project match exactly. ERROR: error LNK2019: unresolved external symbol __imp__WaitForSingleObject__USE_VCR_MODE@8 referenced in function "public: void __thiscall boost::detail::basic_timed_mutex::lock(void)" (?lock@basic_timed_mutex@detail@boost@@QAEXXZ) I am using Visual Studio 2010 and boost 1_45_0. The code is linking to libboost_thread-vc100-mt-s-1_45.lib in both the projects. Any suggestions on what could be the possible cause of this or how to fix this will be highly appreciated. Thanks, Anish boost::mutex active_source_mutex; class TESTCLASS { public: void LOOP(int count) { int tcount = 0; for(int j=0; j<count; j++) { for(int k=0; k<10000000; k++) { tcount++; } printf("%d %d\n",j,tcount); } } void THREAD_CALLBACK() { boost::mutex::scoped_lock slock(active_source_mutex); LOOP(10); } }; int main() { TESTCLASS jk; boost::thread thread_1 = boost::thread(&TESTCLASS::THREAD_CALLBACK, &jk); boost::thread thread_2 = boost::thread(&TESTCLASS::THREAD_CALLBACK, &jk); thread_1.join(); thread_2.join(); return 0; }

3 3

[Proto] Non-const First Argument for Nested eval<>'s operator() ()
by Hossein Haeri 12 Jan '11

12 Jan '11

Dear all, In the Proto documentation, is there any reason why in all the specialisations of eval<Expr> for contexts, the first argument to their operator() is of type Expr& as opposed to const Expr&? TIA, --Hossein

2 2

Boost Graph Library: edge retrieval using edge descriptor between square brackets fails
by Nicholas Mario Wardhana 12 Jan '11

12 Jan '11

Hi all, I am wrapping the Boost Graph Library with a thin class, and I am having a problem in retrieving the edge. I use a mechanism similar to the one in here: http://stackoverflow.com/questions/3100146/adding-custom-vertices-to-a-boos… For testing, I add two vertices (suppose pNode1 and pNode2) successfully, and they can be retrieved as well by passing in their vertex descriptors. However, this is not the case for the edges: when I add an edge from pNode1 to pNode2, the edge is correctly stored as the out_edge of pNode1, but when I retrieve the edge using its edge descriptor, which is the (valid) return value of the add_edge() function, the pointer value is NULL. Also, when I debug the code, I find that inside the graph, there are two variables m_edges and m_vertices. The m_vertices correctly contains two vertex descriptors, but the m_edges is empty. So, do I make a mistake here? I have been looking for some information in Boost's archive and other sources (StackOverflow, ...), but so far haven't found anything helpful. I include a snippet at the end of this e-mail. I am using Visual Studio 2008 SP1 on Windows Vista SP2, and Boost 1.44.0 (haven't upgraded yet to 1.45, but the latter doesn't seem to address this issue). Thank you! Best regards, Nicholas Mario Wardhana //--------------------------- snippet ----------------------------- template <class NodeData, class EdgeData> class BoostGraphWrapper : public Graph<NodeData, EdgeData> { typedef boost::adjacency_list<boost::listS, boost::listS, boost::directedS, Node<NodeData>*, Edge<NodeData, EdgeData>*, boost::listS> BoostGraph; typedef typename boost::graph_traits<BoostGraph>::vertex_descriptor BoostVertexDescriptor; typedef typename boost::graph_traits<BoostGraph>::edge_descriptor BoostEdgeDescriptor; //... public: void AddNode(Node<NodeData>* pNode); Edge<NodeData, EdgeData>* AddEdge(Node<NodeData>* pNode1, Node<NodeData>* pNode2); //... private: BoostGraph m_graph; //... }; template <class NodeData, class EdgeData> void BoostGraphWrapper<NodeData, EdgeData>::AddNode(Node<NodeData>* pNode) { Graph<NodeData, EdgeData>::AddNode(pNode); // 1. Get the descriptor BoostVertexDescriptor vertexDescriptor = boost::add_vertex(m_graph); // 2. Fill with the node m_graph[vertexDescriptor] = pNode; // ... } template <class NodeData, class EdgeData> Edge<NodeData, EdgeData>* BoostGraphWrapper<NodeData, EdgeData>::AddEdge( Node<NodeData>* pNode1, Node<NodeData>* pNode2 ) { Graph<NodeData, EdgeData>::AddEdge(pNode1, pNode2); // 1. Get vertex descriptors of the nodes BoostVertexDescriptor vertexDescriptor1 = GetBoostVertexDescriptor(pNode1); BoostVertexDescriptor vertexDescriptor2 = GetBoostVertexDescriptor(pNode2); Node<NodeData>* tempNode = m_graph[vertexDescriptor1]; Node<NodeData>* tempNode2 = m_graph[vertexDescriptor2]; // 2. Add an empty edge BoostEdgeDescriptor edgeDescriptor; bool inGraph = false; boost::tie(edgeDescriptor,inGraph) = boost::add_edge(vertexDescriptor1, vertexDescriptor2, m_graph); if(!inGraph) { return NULL; } assert(BoostEdgeSize() == 1); // successful // 3. Fill the edge with the vertices Edge<NodeData, EdgeData>* temp = m_graph[edgeDescriptor]; assert(NULL != temp); // fails here //.... return pEdge; } void SomeFunction() { BoostGraphWrapper<int, int> graphWrapper; Node<int>* pNode1 = new Node<int>(); Node<int>* pNode2 = new Node<int>(); Edge<int, int>* pEdge; graphWrapper.AddNode(pNode1); graphWrapper.AddNode(pNode2); pEdge = graphWrapper.AddEdge(pNode2, pNode1); // fails here }

2 6

[proto] learning proto slowly, a small (math)complex library
by alfC 12 Jan '11

12 Jan '11

Hi, I find proto pretty intriguing and I can see the power in it but I am still not able to create a context in which it can help in my design. I also find the Boost.Proto examples very confusing and not usually in the context I always imagine to use the library. There are several concepts that I don't yet fully understand like "context" and "grammars". Also besides the power I see in the library sometimes the resulting syntax in the examples is pretty disappointing, with all those "eval" functions. In general I can't see whether this is a result of limitations of the library or a tool to make the examples more pedagogical. If someone is kind enough to follow me and help me during this discovery of the library along these posts I will continue. The idea of this post is try to bring a simple example of boost at a context that I am able to understand. In order to be useful for many other people I will try to bring proto to a purely mathematical level. Suppose I want to build a new (kind of mathematical) library. Typically I would start defining a lots of arithmetical objects and members and friends operators, all of them eager (member)functions, lots of operators (many bugs also), also use boost.operators (to make less bugs) and then realise that the library has not any real deep mathematical structure on it, not to the compile-time/programmer level. Yes, the program will be able to do a lot of mathematics at runtime via numerical representations but there will be no insight from the point of view of the program code or the "type system". Let's start by an example, I define a complex type, after a lot of work I would have made the equivalent of std::complex<T>. Then the program replaces T by double and the program can (at runtime) do some "math". The problem is that I as a programmer can not do any math with that type. Let me give a concrete example, the complex_unit_circle is a set of complex numbers with modulus =1. One is tempted to implement complex_unit_circle in terms of the "complex type" or some parameterisation (angle). >From a mathematical point of view the complex z is a complex number of course, and z/|z| (z/abs(z)) is not only also a complex number but also potentially a complex_unit_circle element with very spefic properties. For example the product of two elements of the unit circle can be interpreted as a unit circle element again. The only way to express this potentiality at compile time is by expression templates, i.e. in its most glorious state by Boost.Proto. z/abs(z) is really an expression that eventually can be used to construct either another complex number (as type) or a unit circle number (as type). But lets start slower than that, lets build an expression that can be used (potentially) to build a complex number instead. The concrete question of this post will be how to obtain the desired syntax by adding layers to the original posted code. This is what I have done so far: #include <boost/proto/core.hpp> namespace pretty{ namespace proto = boost::proto; struct i_tag{}; proto::terminal< i_tag >::type const i = {{}}; } int main(){ using namespace pretty; 4. + 5.*i; //this will be a complex number (in some sense) return 0; } of course this program does nothing, it is just to show that I can create a expression template with a symbol called "i", this symbol will have properties that will eventually make it equivalent to one of the roots of -1 (mathematically speaking) (but not yet). Note that I didn't define any so called "grammar" or "context" yet. Since the first concern is to be able to use the new code with old code at all intermediate steps in the development, duppose I want to use this kind of expression to construct (in the c++ sense) an existing type, namely std::complex<double>. i.e. I want to be able to write: std::complex<double> z = 4. + 5.*i; or std::complex<double> z(4. + 5.*i); (forget about alternative notations, like 5.*i + 4. or 4. + i*5) The only ways I see this is possible is by adding either a constructor to std::complex<double> or a cast operator of the "expression of type 4.+5.*i" to std::complex<double>. The question for this post, 1) is this true? 2) if yes, then that means that one of the 2 types (type complex or typeof(4.+5.*i) ), will have to be modified (or extendended) in other to accept this syntax. 3) if no , how can I allow this syntax? 4) if the std::complex type is not modifiable, what is the mechanism in proto to define a cast over a certain set of expressions, e.g. of the type of 4.+5.*i. 5) if not, is this syntax not possible at all? is it here where we need to introduce those "eval" functions such as std::complex<double> z = eval_as_complex(4. + 5.*i). The idea is that once I resolve this general questions about the library I will continue building up. (And excuse me for these naive questions along the way). (Note: I know that std::complex<double> had constructor std::complex<double>(4.,5.) and that should be the preferred use, but this post is all about "syntax" and how to use proto, these are just examples). Thank you, Alfredo

4 11

issues with the latest boost numeric bindings
by Simon Mpasi 11 Jan '11

11 Jan '11

To boost users: Greetings! I do not know if this the correct format but here are the issues that I am running into: /boost/numeric/bindings/lapack/detail/ The file clapack.h includes itself causing an error /boost/numeric/bindings/blas/detail/ The file cblas.h includes itself causing an error I changed them to lapack.h and blas.h respectively but I got several errors. I checked out the latest version of numeric bindings from boost.svn this morning. I am using Microsoft Visual Studio 2008 without a Fortran compiler (I need to use clapack) The issues here are that the l lapack routines come with 2 underscores, i.e. _sgesvd_ instead of sgesvd_ I declared BOOST_NUMERIC_BINDINGS_USE_CLAPACK in my driver. Thank you very much in advance for your assistance. Simon N. Mpasi

2 1

[Build] Mimicking my Fedora13 Boost installation.
by Robert Jones 11 Jan '11

11 Jan '11

I have Boost installed as part of my Fedora13/64-bit system, at Boost 1.41. I now want install Boost 1.45, but need to keep the original around for backwards compatibility issues, so I'm putting my 1.45 build somewhere else, and and I want it look as much like the original 1.41 build as possible, but be 1.45. So I built with this command > ./bjam --prefix=/usr/local/boost_1_45_0 threading=single --runtime-link=shared --link=shared --layout=tagged install then listing all the Boost regex (regex chosen at random) I find > find /usr -name 'libboost_regex*' 187532 0 lrwxrwxrwx 1 root root 24 Sep 21 16:25 /usr/lib64/libboost_regex.so -> libboost_regex.so.1.41.0 142821 972 -rwxr-xr-x 1 root root 994792 Jun 4 2010 /usr/lib64/libboost_regex.so.1.41.0 540038 2356 -rw-r--r-- 1 root root 2410606 Jan 11 11:56 /usr/local/boost_1_45_0/lib/libboost_regex.a 540030 1132 -rwxr-xr-x 1 root root 1156757 Jan 11 11:55 /usr/local/boost_1_45_0/lib/libboost_regex.so.1.45.0 540031 0 lrwxrwxrwx 1 root root 24 Jan 11 11:55 /usr/local/boost_1_45_0/lib/libboost_regex.so -> libboost_regex.so.1.45.0 which seems to show an extra .a compared to my Fedora 'default' installation. How come? Do I need it? Can I determine the bjam flags that Fedora used originally? Thx, - Rob.

2 2

[Iterator] advance and random_access_traversal iterators
by Anthony Foglia 11 Jan '11

11 Jan '11

What happened to the patch to add a boost::advance function designed to work with Boost.Iterator's concepts? Three years ago there was a thread pointing out the problem with std::advance not treating random access traversal iterators as random access (because of the reference type). Sebastian Redl posted a patch to add a boost::advance (and boost::distance) function. <http://lists.boost.org/Archives/boost/2007/09/127785.php> I don't see any proof of this patch ever being applied. Someone filed a bug report two years ago to bring attention to the patch, and it still hasn't been applied. <https://svn.boost.org/trac/boost/ticket/2539> Is there a reason it hasn't been applied (the collision with the boost::distance supplied by Boost.Range?) or has it just fallen through the cracks? -- Anthony Foglia Princeton Consultants (609) 987-8787 x233

2 1

Problem compiling under Codegear
by jose perez 10 Jan '11

10 Jan '11

Hello. I’m using CodeGear compiler with Boost 1.39 and Boost 1.45. In both of them I have found an error in mpl\base.hpp line 25 (typedef typename T::base type;) [BCC32 Error] base.hpp(25): E2404 Dependent type qualifier 'na' has no member type named 'base' The code is: namespace boost { namespace mpl { template< typename BOOST_MPL_AUX_NA_PARAM(T) // find in mpl\aux_\na_spec.hpp, line 152: #define BOOST_MPL_AUX_NA_PARAM(param) param = na > struct base { typedef typename T::base type; // <------- ERRORRR BOOST_MPL_AUX_LAMBDA_SUPPORT(1,base,(T)) }; BOOST_MPL_AUX_NA_SPEC(1, base) }} Help will be appreciated. Thanks!

1 0