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

[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

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

15 Nov '10

Have u installed MPI or open MPI ? I think u need to install it first. Regards On Mon, Nov 15, 2010 at 8:08 PM, <> wrote: > Hello, > > 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. > How can I configure the build process so that it can find mpi.h? > Thansk, > > Juan Farré > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > -- Manish Gupta Bioinformatics Software Developer Synamatix Sdn Bhd. Kulalumpur, Malaysia

1 0

[netlib] 0.8-beta now available!
by Dean Michael Berris 15 Nov '10

15 Nov '10

Hi Everyone, advanced apologies for cross-posting. I've just tagged and uploaded archives of the cpp-netlib 0.8-beta which features: * An asynchronous server template, allowing for server-side streaming of data, asynchronous writing and reading facilities for server-side handlers, and a thread pool implementation that's temporarily using Boost.Asio's io_service for application-specific asynchronous handlers to run from. * A `ready(...)` wrapper to check for whether an asynchronous client's response is ready. The documentation has also been updated to feature a brand-new reference manual detailing the implementation, caveats, and public API of the HTTP client and server templates. You can go ahead and download the 0.8-beta and report issues you find either directly to me or through the mailing lists (Boost.User, Boost.Devel, and the cpp-netlib developers mailing lists). The target release for 0.8 will be this Friday, November 19, 2010. As usual, you can download the 0.8-beta package from GitHub at: https://github.com/cpp-netlib/cpp-netlib/downloads You can also check out the documentation for 0.8-beta at: http://cpp-netlib.github.com/0.8-beta Thanks everyone and I look forward to most appreciated feedback! -- Dean Michael Berris deanberris.com

1 0

asio UDP async receive question - seems to lose packets?
by Ákos Maróy 15 Nov '10

15 Nov '10

Hi, I have a question about boost asio UDP async receive. For me, it seems to silently not receive packets, even on localhost. I have a small sample here: http://pastebin.com/NnbK1T7G , which is based on one of the asio examples. the sample code is quite simple: - it allows sync sending of messages (strings) - it allows async reception of such messages - it will put each received message into a vector, which is guarded by a mutex - another thread will process messages from this vector on a regular basis, which processing is also guarded by a mutex. if I compile & run the sample, I get: ./async_asio b sent 20000 messages a received 1981 messages which is a profound loss of packets. as seen in the sample, after the receive handler is called, the recieved message is copied over, and socket::async_receive_from() is called ASAP. I don't see what else would need to be done to have all messages received. If I remove the processing of messages in threa_func(), the results are markedly better: ./async_asio b sent 20000 messages a received 19963 messages increasing the sleeping time at the end does no good - it seems the messages were lost already. I wonder what the proper pattern is to receive messages, store them, and process them in an async manner? Akos

1 0