- Boost-users - lists.boost.org

[BGL] setS as an edge container
by Datalurkur 01 Jan '11

01 Jan '11

I'm attempting to set up pathfinding using Dijkstra's algorithm, and decided to use setS since I need to add/remove edges frequently and don't want to worry about adding parallel edges. My typedefs are such: typedef property<edge_weight_t, int> Weight; typedef adjacency_list<vecS, setS, undirectedS, no_property, Weight> Graph; typedef graph_traits<Graph>::vertex_descriptor VertexDescriptor; typedef graph_traits<Graph>::edge_descriptor EdgeDescriptor; However, when trying to actually call dijkstra_shortest_paths, like so: std::vector<VertexDescriptor> predecessorMap(num_vertices(*_graph)); std::vector<int> distanceMap(num_vertices(*_graph)); dijkstra_shortest_paths(*_graph, startVertex, predecessor_map(&predecessorMap[0]).distance_map(&distanceMap[0])); I wind up with a bunch of compile errors within boost. Some examples: .../Boost.framework/Headers/graph/dijkstra_shortest_paths.hpp:377: error: no matching function for call to 'put(int*&, void* const&, int&)' .../Boost.framework/Headers/graph/two_bit_color_map.hpp:77: error: invalid cast from type 'boost::detail::error_property_not_found' to type 'size_t' .../Boost.framework/Headers/graph/dijkstra_shortest_paths.hpp:139: error: no matching function for call to 'get(int*&, void*)' I suspect it has something to do with the index map, but I assumed that vertex mappings that used vecS didn't need to be supplied with an index map. I followed the dijkstra example as closely as possible, but since they have a static set of edges and use vecS to store the edge map, I'm pretty certain that's where the discrepancy lies. Any other examples, advice?

4 4

[netlib] Preparing for 0.9 and 0.8.1 Release, Help Wanted; Readying for Boost Submission
by Dean Michael Berris 01 Jan '11

01 Jan '11

Hi Guys! (Apologies in advance for the cross-post) I've just pushed the master, 0.8-devel, and 0.9-devel branch onto the cpp-netlib repository -- please take the time to test all these branches as I work on getting the documentation up to speed on the 0.9-devel branch preparing for the release and submission for review on the Boost developers mailing list. I'm also welcoming contributions in the form of: * Website help, the current documentation look is OK, but if you have time to fix up some of the issues like the fonts, adding anchors and maybe reformatting the API pages so that it's easier indexed, that would be *sweet*. Also, we need a landing page on cpp-netlib.github.com which introduces the library, hosts stats, and maybe has other goodies that are specifically for a website and not necessarily for documentation. * Documentation -- please, if you have example use cases that you want to contribute, now is the time to contribute them. If you have real world use cases where you're actually using cpp-netlib, now would be a good time to have your use case highlighted in the documentation. * More string implementations -- currently I need help with supporting Qt strings, MS CString, and wide strings in the implementation of the HTTP Clients. Those who are using wide strings and unicode strings natively and who have more experience with them (I only ever deal with the "C" locale) would be most welcome to contribute to getting the HTTP client to either do conversions or natively support different string implementations. I can help with the integration part by introducing the extension points that may not be obvious from the design (as it is still largely undocumented). * Examples -- the current set of examples are a little trivial, and if you have some interesting examples you want to build on (or would like to implement some of the examples highlighted here: https://github.com/cpp-netlib/cpp-netlib/issues/labels/Examples) your contribution would be most welcome. There are some things that I've pushed out for later releases, as I would like to concentrate at the moment to making the HTTP implementations more robust and support a wider range of use-cases. I'm looking for people with experience with ESMTP 1.0 who would like to contribute to implementing a simple client implementation that we can build along the same design as the HTTP client implementation. There's already a MIME parser/generator library in cpp-netlib thanks to Marshall Clow (which he presented in BoostCon 2010) also being developed for inclusion into Boost -- hopefully we can get that baked into the ESMTP client implementation early on to make it more immediately useful. At any rate, please expect a slightly delayed release of 0.9 which would be the first release which defaults to non-header-only, while 0.8.1 will be the first patch update version for 0.8. Appropriate changelogs to follow as soon as the releases are ready. In the meantime, please feel free to test out the code already in GitHub: http://github.com/cpp-netlib/cpp-netlib/ -- the stabilization effort for 0.9 and 0.8.1 will happen on this repository. Feedback would be most appreciated. Thanks everyone! -- Dean Michael Berris about.me/deanberris

1 0

boost asio tcp::socket assign
by Lloyd 01 Jan '11

01 Jan '11

Hi, I have a boost::asio::ip::tcp::socket variable (reference) in a class, and it is initialized at the object construction time. At a later time I need to assign a new socket to this "socket reference variable". I think boost::assign is meant for that. But when I use assign, get the following error... (or is there any other method available?) .....cannot convert parameter 2 from 'boost::asio::ip::tcp::socket' to 'const boost::asio::detail::win_iocp_socket_service<Protocol>::native_type &' The code snippet is as follows... class MyClass { .... ..... private: tcp::socket& Socket; } void MyClass::SetSocket(tcp::socket& s) { Socket.assign(boost::asio::ip::tcp::v4(),s); } What could be the reason? Thanks in advance, Lloyd

2 4

boost::mpl -- compiler running out of memory
by Peter Foelsche 31 Dec '10

31 Dec '10

I've some code, which is extensively using boost::mpl. It does not compile with g++ 4.5 or Visual C++ 2010 within 8GB of RAM -- always runs out of memory or runs into swapping (of course 64bit compiler). Is there any way to find out, how I can change this code to avoid needing so much memory?

2 1

Problems compiling Boost_1_45_0
by Alex Biddulph 31 Dec '10

31 Dec '10

Hi all, I recently decided to try and compile/install Boost for my MSYS/MinGW64 system. I downloaded the lastest sources for both bjam (3.1.18) and Boost itself (1.45.0). (More precise details of my sytem are below). I compiled my own bjam with no hassle and got a bin.ntx86_64 version and copied it to /mingw/bin. I used the generic command to build it (./build.sh) and let it auto-detect the toolset (gcc). However, the compilation started to fall over once I started to build Boost itself. Using the command /mingw/bin/bjam --prefix=/mingw/boost toolset=gcc address-model=64 variant=release link=shared threading=multi --build-type=complete stage I first received the following error (attachment: error1.txt) After some googling I found a bug report where someone mention the workaround of just removing the 'ignore-minus-q' part of the statement, this removed the errors and allowed me to continue with the build. Is this an acceptable workaround or is there something else that I should be doing here? Anyways, I know receive the following errors (attachment: boost.txt and attachment: boostd2.txt) I did some googling again and found a bug report that is very similar to what I am getting (almost identical except for versions and setup). Here is the link to the bug report https://svn.boost.org/trac/boost/ticket/4839. The attachment boostd2 uses the exact same build command as above but with -d2 tacked on the end. Can anyone tell me why I am getting this and how I might fix it? Regards Bidski System details: OS: Windows 7 Home Premium x64 MinGW64: TDM64-GCC-4.5.1 $ gcc -v Using built-in specs. COLLECT_GCC=c:\mingw\bin\g++.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.1/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../src/gcc-4.5.1/configure --prefix=/crossdev/prefix-tdm64 --build=x86_64-w64-mingw32 --enable-targets=all --enable-libgomp --enable-lto --enable-libstdcxx-debug --enable-languages=c,c++,fortran,objc,obj-c++ --disable-werror --disable-nls --disable-win32-registry --enable-version-specific-runtime-libs --enable-fully-dynamic-string --with-pkgversion=tdm64-1 --with-bugurl=http://tdm-gcc.tdragon.net/bugs Thread model: win32 gcc version 4.5.1 (tdm64-1)

2 3

[Pool] Call for bug reports
by John Maddock 31 Dec '10

31 Dec '10

A small but intrepid band of volunteers will be updating Boost.Pool in the near future, so if there are any bug reports or feature requests you've been holding back... hold back no longer and please file these on the Trac. Wait too long to file though and you may have to wait another 10 years for an update.... although we certainly hope not! Regards, John.

1 0

[preprocessor] extending loop limit >> 256
by Martin Pasdzierny 31 Dec '10

31 Dec '10

Hi boost experts, using BOOST_PP_LOCAL_ITERATE() and friends I found the maximum number of iterations to be limited to 256. The according values seemed to be defined in .../preprocessor/config/limits.hpp But changing these values does *not* have any effect on the maximum number of iterations ... #define BOOST_PP_LOCAL_MACRO(n) g(n); #define BOOST_PP_LOCAL_LIMITS (1, 300 ) #include BOOST_PP_LOCAL_ITERATE() #undef BOOST_PP_LOCAL_MACRO #undef BOOST_PP_LOCAL_LIMITS ... still creates: g(1); g(2); g(3); ... g(255); g(256); the expected: g(257); g(258); ... g(299); g(300); are *not* generated. Stepping through the libraries code I found the mechanisms far more complicated than expected. Now my question: is there any recommended procedure to increase the iteration limitation to values like 10000 ? I found a couple of code locations explicitly repeating code with hard coded values from 1 ... 256. I guess at least this code needs to be extended, but probably consistent with some other changes. I am thinking of a perl script to generate stuff like that, but before working on that I'd like to get some qualified recommendations ;) Thanks in advance, Martin.

3 3

serialization: 2-arg template free function serialize
by Hicham Mouline 30 Dec '10

30 Dec '10

Robert, I have a number of types for which I've implemented the free serialize template function. I have also a number of fusion sequences. This is the code I came up with: namespace boost { namespace serialization { template <typename Archive> class SerializeMemberOfFusionSeq; /// fwd decl template <typename Archive, typename Seq> typename boost::enable_if_c<boost::fusion::traits::is_sequence<Seq>::value, void>::type serialize(Archive& ar, Seq& seq, unsigned int) { boost::fusion::for_each(seq, SerializeMemberOfFusionSeq<Archive>(ar)); } template <typename Archive> class SerializeMemberOfFusionSeq { public: SerializeMemberOfFusionSeq(Archive& ar) : ar_(ar) {} template <typename T> void operator()(T& t) const { ar_ & t; } private: Archive& ar_; }; } } Is the serialization library able to find the serialize() function this way? regards,

1 0

Mingw64 Boost Threads Build
by Dustin T. Clifford 30 Dec '10

30 Dec '10

Good Afternoon, We have been using boost-threads for our native APIs and, thus far, Boost has been a godsend! We had a recent request to build a 64-bit version of this API. To accomplish this we have attempted to build using MinGW64. Unfortunately, I have had zero luck getting boost-threads to build. I can build the 32-bit address model without a problem but 64-bit continues to elude me. I first tried Boost 1.35.0 and have now moved on to 1.45.0. I believe that the environment is set up correctly (see below). This build is being performed on a Windows 7 64-bit using MinGW64 from Cygwin. export CC=x86_64-w64-mingw32-gcc.exe export CXX=x86_64-w64-mingw32-g++.exe export LD=x86_64-w64-mingw32-ld.exe I have, also, modified my PATH to use the appropriate 64-bit bintools and aliased gcc, g++ and ld to the 64-bit MinGW64 compilers and linkers. To build Boost I have used the following with no success. boostrap.sh address-model=64 -prefix=<install> --with-libraries=thread; bjam -a install; boostrap.sh -prefix=<install> --with-libraries=thread; bjam -a address-model=64 install; boostrap.sh -prefix=<install> --with-libraries=thread; bjam -a install; The last build attempt succeeds but appears to have built 32-bit binaries. The previous two fail in building boost-threads complaining that 'address-model-64' is not found for certain build artifacts. I have, also, tried the above with a prebuilt bjam with the same results. I have tried much more than what I have cited here (including MSVC builds) with no success (some built but resulted in 32-bit binaries). I have scoured Google and found many talking about this but most either had no resolution or contained instructions that conflicted or made no sense. Does anybody have any insight into how I can produce a 64-bit boost-threads archive? Any help would be greatly appreciated. Thanks in advance, Dustin P.S. If I have missed any information or you need more (build logs are attached), please, let me know.

1 0

taking the subgraph of a boost graph
by Ryan Lewis 30 Dec '10

30 Dec '10

Hi, Lets say your handed an arbitrary boost graph and an iterator to a subset of it's vertices. You want to induce a subgraph of this graph. How do you do this? I looked at the boost docs and found the Subgraph < Graph > page: http://www.boost.org/doc/libs/1_36_0/libs/graph/doc/subgraph.html Indeed there exists a subgraph member function: subgraph<Graph>& create_subgraph(); However this suggests, as does the example, that you want to take an induced subgraph of a graph whose type is Subgraph < Graph >. However my graph is just of type Graph. What is the right way to deal with this? I've tried asking at #boost, but no one seems to be awake there. Thanks, -rhl

4 15