November 2010 - Boost-users

Valgrind false positive in make_shared
by Dave Steffen 17 Nov '10

17 Nov '10

Hi Folks I've been tracking down some almost-certainly-false-positives from Valgrind. Consider the following code: #include <iostream> #include <boost/shared_ptr.hpp> #include <boost/make_shared.hpp> using namespace std; using boost::make_shared; struct StateSpace { public: StateSpace(int spaceType) { if (spaceType == 4) cout << "Some Output" << endl; } }; class State { public: State() : m_rep(make_shared<StateSpace>(0) ) {} boost::shared_ptr<StateSpace> m_rep; }; int main() { State state; } Valgrind 3.6 reports this: ==8198== Memcheck, a memory error detector ==8198== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==8198== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==8198== Command: testState ==8198== ==8198== Conditional jump or move depends on uninitialised value(s) ==8198== at 0x401659: StateSpace::StateSpace(int) (testState.cpp:14) ==8198== by 0x401796: boost::shared_ptr<StateSpace> boost::make_shared<StateSpace, int, >(int&&, ) (make_shared.hpp:150) ==8198== by 0x4016BD: State::State() (testState.cpp:22) ==8198== by 0x401317: main (testState.cpp:29) ==8198== ==8198== ==8198== HEAP SUMMARY: ==8198== in use at exit: 464 bytes in 5 blocks ==8198== total heap usage: 240 allocs, 236 frees, 45,162 bytes allocated ==8198== ==8198== LEAK SUMMARY: ==8198== definitely lost: 0 bytes in 0 blocks ==8198== indirectly lost: 0 bytes in 0 blocks ==8198== possibly lost: 0 bytes in 0 blocks ==8198== still reachable: 464 bytes in 5 blocks ==8198== suppressed: 0 bytes in 0 blocks ==8198== Reachable blocks (those to which a pointer was found) are not shown. ==8198== To see them, rerun with: --leak-check=full --show-reachable=yes ==8198== ==8198== For counts of detected and suppressed errors, rerun with: -v ==8198== Use --track-origins=yes to see where uninitialised values come from ==8198== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 5 from 5) Interestingly, if I change State() : m_rep(make_shared<StateSpace>(0) ) {} to State() : m_rep(new StateSpace(0)) {} the Valgrind error goes away. This is, of course, a greatly boiled-down version of our actual code, which we're very confident works correctly. Any ideas about why Valgrind doesn't like the call to make_shared? Any ideas about how to silence this warning (other than adding it to Valgrind's suppressions file)? Thanks very much. -- Dave Steffen, Ph.D. - Software Engineer Numerica Corporation <http://www.numerica.us> 4850 Hahns Peak Drive, Suite 200 Loveland, Colorado 80538 main (970) 461-2000 x 227 direct (970) 612-2327 Email: dave.steffen(a)numerica.us fax (970) 461-2004

3 5

[BGL] Getting/deducing type of custom (internal) properties
by Cedric Laczny 17 Nov '10

17 Nov '10

Hi, this is to substitute the thread: [BGL] Accessing internal properties and returning a "template"-type I think I can now deliver even more details on my problem. Again, I have the following concept: template < class GRAPH, class EDGE_PREDICATE, class VERTEX_PREDICATE > class FilteredGraph { public: /// Defines an alias type to represent the filtered_graph typedef filtered_graph< GRAPH, EDGE_PREDICATE, VERTEX_PREDICATE > FilteredGraphContainer; // // some c'tors, member functions etc. // template< class VERTEXPROPERTIES > VERTEXPROPERTIES& properties(const Vertex& v) const { typename property_map<FilteredGraphContainer, vertex_properties_t>::const_type param = get(vertex_properties, graph_); return (param[v]); } // // some more stuff // private: FilteredGraphContainer graph_; }; The compiler can't obviously deduce the type of the return-value of properties( Vertex v) as this type is not specified in the argument list. This is what I understood so far by finding this: http://www.parashift.com/c++-faq-lite/templates.html#faq-35.4 I have the same properties-function in my Graph-class, which uses custom properties as in http://live.boost.org/doc/libs/1_43_0/libs/graph/doc/using_adjacency_list.h… list-properties The definition of this class basically is: enum vertex_properties_t { vertex_properties }; enum edge_properties_t { edge_properties }; namespace boost { BOOST_INSTALL_PROPERTY(vertex, properties); BOOST_INSTALL_PROPERTY(edge, properties); } /* the graph base class template */ template < typename VERTEXPROPERTIES, typename EDGEPROPERTIES > class Graph { public: /// an adjacency_list like we need it typedef adjacency_list< setS, // disallow parallel edges vecS, // vertex container undirectedS, // undirected graph property<vertex_properties_t, VERTEXPROPERTIES>, property<edge_properties_t, EDGEPROPERTIES> > GraphContainer; // //... // private: GraphContainer graph_; }; This is all, more or less, similar to the template-definitions used in the BGL, or at least that was my intention. Interestingly, when I have a function: template< class GRAPH > void some_function( const GRAPH& g){ GRAPH::Vertex v; // Get some included vertex out of g and assign it to v; v = someVertexFromG( g ); filtered_graph< GRAPH, keep_all, keep_all > fg(g, keep_all(), keep_all()); get(vertex_properties, fg, v); } it works without any problem. Now the question, is it possible to solve this issue for FilteredGraph and keep the same concept as for Graph, or do I need to specify the type of VERTEXPROPERTIES somewhere _beforehand_ in order to let the compiler get this type (not preferred, for obvious reasons)? Best, Cedric

1 1

[StateChart] event processing order in async machine
by Igor R 16 Nov '10

16 Nov '10

Hello, I've got an async. state machine (1.44, MSVC10), and sometimes I observe a very strange behavior: events being processed not in the order they are queued. I spent some time trying to investigate this issue, but due to the asynchronous nature of the processing, it's quite not trivial. So, before I start sinking too deep, I'd like to ensure I don't miss something trivial. Unfortunately, I don't have at the moment any self-contained code, but a very simplified model of my FSM is as follows. Assume there are 2 events: Ev1, Ev2. The both are queued to the FMS from the same thread, always in the same order: Ev1, Ev2. The FSM processes them in another thread. The FMS has some "entry" chain of states that defer the both events: S1 /[defer(Ev1, Ev2)] --> S2 /[defer(Ev1, Ev2)] and finally 2 orthogonal sub-states, one of them ignores the both events, and the other processes the both: ...S2 --> S3<S3_1, S3_2>, S3_1 /[custom_reaction(Ev1), in_state_reaction(Ev2)] What I see is that *sometimes* the reaction for Ev2 is invoked *before* the reaction for Ev1. This "sometimes" really puzzles me: I'm absolutely sure that the order of queuing is always the same - so where can be a "race"? Any idea would be appreciated!

2 19

[BGL] Accessing internal properties and returning a "template"-type
by Cedric Laczny 16 Nov '10

16 Nov '10

Hi, I have the following concept: template < class GRAPH, class EDGE_PREDICATE, class VERTEX_PREDICATE > class FilteredGraph { public: /// Defines an alias type to represent the filtered_graph typedef filtered_graph< GRAPH, EDGE_PREDICATE, VERTEX_PREDICATE > FilteredGraphContainer; // // some c'tors, member functions etc. // template< class VERTEXPROPERTIES > VERTEXPROPERTIES& properties(const Vertex& v) const { typename property_map<FilteredGraphContainer, vertex_properties_t>::const_type param = get(vertex_properties, graph_); return (param[v]); } // // some more stuff // }; When I want to use this code to access the properties of a vertex of the FilteredGraph, the compiler says that it can't find this function. I searched around and found some notes about returning a template. The most prevalent is that the compiler simply does not know which type the function should return and thus can't find a valid signature and complains. Is there a way to let it find the type via the property_map? Or some other ideas how to solve this issue? I experimented with: template< class VERTEXPROPERTIES > VERTEXPROPERTIES& properties(const Vertex& v) const { typename property_map<FilteredGraphContainer, vertex_properties_t>::const_type param = get(vertex_properties, graph_); property_traits< typename property_map<FilteredGraphContainer, vertex_properties_t>::const_type > prop_trait; return prop_trait.reference(param[v]); } but with no success. Except for this, I have no reason to include a template for VERTEXPROPERTIES generally to the class. So I would really like to keep that concept as it is. Thank you. Best, Cedric

1 0

Re: [Boost-users] MPI build problems in Fedora 14 x64
by Riccardo Murri 16 Nov '10

16 Nov '10

On Tue, Nov 16, 2010 at 6:52 PM, <> wrote: > The workaround you suggest didn't work. > I reported this as a bug to Fedora bugzilla and I got the following answer: > > > This sounds like you didn't load the openmpi environment module prior to > > attempting to compile. The openmpi package is compliant with the new mpi > > packaging guidelines which state that there is no system wide mpi by default > > and the user must select the mpi they wish to compile with by use of the > > environment modules supplied by the mpi package. That module includes the > > necessary modifications to the environment to allow compilation of mpi > > programs. Can you please confirm if you see this problem after the proper > > environment is loaded? > > I really don't know how to check that, but looks like the packager's oppinion is that > this isn't a packaging but of mpic++. May be this is something new of openmpi that > hasn't been taken into account in boost build process? You might want to ask on a Fedora mailing list what's the correct way to select an "environment module" with their new package. I think this has nothing to do with the Boost build process -- you probably just need to set some environment variables or run a command that does some kind of environment setup for you. I don't use Fedora myself and I have no access to any machine running it, so I'm afraid I cannot be of any help here. Best regards, Riccardo

1 0

[parameter] Boost.Parameter Constructors in Template Classes
by Dean Michael Berris 16 Nov '10

16 Nov '10

Hi Everyone, I'm not sure whether this is more appropriate for the users list or the developers list so I sent the email to both. I'm using Boost's SVN Trunk r66609 and I tried to compile the (attached) file to follow the pattern described by the Boost.Parameter tutorial (http://www.boost.org/doc/libs/1_44_0/libs/parameter/doc/html/index.html#par…) but unfortunately I get an error deep in the preprocessor code that Boost.Parameter uses. What I'm trying to do is to make a template class support parameterized constructors, and only have optional parameters and no required ones. The idea is: template <class Tag> struct base; template <class Tag> struct derived : base<Tag> { BOOST_PARAMETER_CONSTRUCTOR(...); }; Has anybody been able to make this work? Thanks and I definitely hope to hear from you soon. PS. I am also going to file this as a bug in Boost.Parameter so that it doesn't get lost in the mailing list churn. ;) -- Dean Michael Berris deanberris.com

2 3

[Proto] typeof in Hello World example
by Hossein Haeri 15 Nov '10

15 Nov '10

Dear all, I have recently started reading about Proto and am only crawling through the user guide. So, sorry if the question is too newbie... I see in the Hello World example at the Getting Started section http://boost.org/doc/libs/1_44_0/doc/html/proto/users_guide.html#boost_prot… in the Hello World example, the following header is also included: <boost/typeof/std/ostream.hpp> I was suspicious that this is not needed for this very example. So, I removed it and GCC 4.5.1 compiled it happily. I see also that this header is not included in the same example in the Example section of the user guide: http://boost.org/doc/libs/1_44_0/doc/html/proto/users_guide.html#boost_prot… Am I right in guessing that this header is not needed then? TIA, --Hossein

2 3

Re: [Boost-users] MPI build problems in Fedora 14 x64
by Riccardo Murri 15 Nov '10

15 Nov '10

> > 1. Try to compile with `mpicxx -c` a file consisting of the single > > line `#include ` ; if this fails, your `mpicxx` is not > > installed properly. > > This test fails. Is there any workaroud? Try reinstalling the openmpi package(s); if the problem persists, it could be a packaging problem, e.g., `mpicxx` configured with the wrong paths. Possibly, `mpicxx` is instructing the compiler to look for the MPI include files under `/usr/include/openmpi` instead of `/usr/include/openmpi-x86_64` (where you reported `mpi.h` is located). A symlink *could* be a workaround. Best regards, Riccardo -- Riccardo Murri Grid Computing Competence Centre, http://www.gc3.uzh.ch/ Organisch-Chemisches Institut, University of Zurich Winterthurerstrasse 190, CH-8057 Zürich (Switzerland) Tel: +41 44 635 4222 Fax: +41 44 635 6888

1 0

Boost Process Library Status
by Carla Strembicke 15 Nov '10

15 Nov '10

Hello, I was looking for a Boost Process Library that would allow for the creation of a child process. The only resource I have found is an unofficial Version of Boost.Process. What is the status of this library? Is it still being worked on? Has it been reviewed or is it ever planning on being reviewed? Thanks Carla Strembicke Software Developer [cid:image81041f.jpg@c9e526b4.f17d4f0b] SUBNET Solutions Inc. www.SUBNET.com<http://www.subnet.com/> Making Substations More Intelligent T: 403.270.8885 F: 403.270.9631 #100, 4639 Manhattan Road SE, Calgary, Alberta, Canada; T2G 4B3 CONFIDENTIAL INFORMATION NOTICE: The information contained in this e-mail is privileged, confidential and intended solely for the use of the addressee named above. If the reader of this e-mail is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you received this in error, please contact the sender and destroy all copies of this e-mail. Thank you.

2 1

Re: [Boost-users] MPI build problems in Fedora 14 x64
by Riccardo Murri 15 Nov '10

15 Nov '10

On Mon, Nov 15, 2010 at 1:08 PM, <> wrote: > I'm building boost libraries in a Fedora 14 x64. > In this Linux distribution, mpi.h is located in /usr/include/openmpi-x86_64 > and the build process complains about not finding mpi.h. This usually indicates that either `bjam` cannot find the MPI compiler (`mpicxx` or `mpic++` both should work on OpenMPI), or that the MPI library is not correctly installed so that `mpicxx` does not look for `mpi.h` in the correct place. To debug, I'd try out the following: 1. Try to compile with `mpicxx -c` a file consisting of the single line `#include <mpi.h>` ; if this fails, your `mpicxx` is not installed properly. 2. Try to append to `project-config.jam` (in the top-level Boost source directory) the line `using mpi : /path/to/mpicxx ;` where `mpicxx` is the one you tried in step 1. -- if this fails, there is possibly some issue with Boost autodetection of the MPI library. Best regards, Riccardo

1 0