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

[units] Automatic Physical Units in Mathematica and Boost.Units
by alfC 03 Jan '11

03 Jan '11

Since there are not many computer software that handles units seriously, except possibly for Boost.Units and Mathematica`Units in my opinion, I just wanted to point out to this post: Automatic Physical Units in Mathematica http://blog.wolfram.com/2010/12/09/automatic-physical-units-in-mathematica/ Interesting discussion in terms of features. One of the reasons I hated Mathematica units handling so far was due to the lack of a typing system which C++ and boost.Units have naturally, the other reason was that the physical quantites didn't seem to play well with other parts of the system. Now it seems that Mathematica Units is discovering "types". One of the features that it mentions is the ability to perform automatic conversions upon arithmetic operations of mixed units. In fact I was working in a way to perform automatic conversion in Boost.Units inside arithmetic formulas, since Mathematica has unbounded precision arithmetic by default the automatic conversions are not a real problem. An exact matching of this feature can not be achieved with a limited precision representation (like double). I'll take the opportunity ask two broad general questions: Does any body have experience with using boost.units quantity with a underlying type that are not double, e.g. multiple precision, or vector (geometric) objects? Does it work well? Are there future planned developments for Boost.Units, in terms of external features (e.g. automatic conversion, better interaction with boost.phoenix) or internal implementation? Thank you, Alfredo

5 7

[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

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