- Boost-users - lists.boost.org

Latex
by Dmitry Bufistov 01 Sep '09

01 Sep '09

\renewcommand{\baselinestretch}{0.98}

1 1

[MPL] Front of a set of types
by Marco Guazzone 01 Sep '09

01 Sep '09

Dear all, Consider this: ---[code]--- #include <boost/mpl/front.hpp> #include <boost/mpl/set.hpp> #include <boost/type_traits/is_same.hpp> #define BOOST_TEST_MODULE "boost::mpl::set tests" #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE( mpl_set ) { typedef boost::mpl::set<int,long,char> s; BOOST_CHECK( (boost::is_same<int, boost::mpl::front<s>::type>::value) ); // Test #1 BOOST_CHECK( (boost::is_same<long, boost::mpl::front<s>::type>::value) ); // Test #2 BOOST_CHECK( (boost::is_same<char, boost::mpl::front<s>::type>::value) ); // Test #3 } ---[/code]--- Reading the docs http://www.boost.org/doc/libs/1_40_0/libs/mpl/doc/refmanual/set.html the "front" of a set<t1,t2,...,tn> return the first element type in s which for me is t1 So what I expect is the test to fail on tests #2 and #3 and hence to succeed on test #1 Instead the test fails on tests #1 and #2 and succeeds on test #3. Looking inside the code I find out this is OK since a setN<T1,..,TN> is defined from TN and set{N-1}<T1,...,T{N-1}>, resulting in TN be the very front element Anyway, in my opinion this is counterintuitive. Maybe a note in the document would be helpful. What do you think? Thank you very much! Cheers, -- Marco

2 7

problem with asio
by pedro chaparro 01 Sep '09

01 Sep '09

hi everyone, i'm new with boost, i've try some examples and they work well but spacifically with programs that use asio libraries i've got some error when i try to compile them, below the line i use to compile, ill apreciate some help thnaks pdro7@ubuntu:~/Desktop$ c++ -I /home/pdro7/Desktop/boost_1_40_0 asio1.cpp -o asio1 /usr/lib/libboost_system-gcc43-mt-1_35.a /usr/lib/libboost_thread-gcc43-mt-1_35.a /usr/lib/libboost_date_time-gcc43-mt-1_35.a /usr/lib/libboost_regex-gcc43-mt-1_35.a /usr/lib/libboost_serialization-gcc43-mt-1_35.a // timer.cpp // ~~~~~~~~~ // // Copyright (c) 2003-2008 Christopher M. Kohlhoff (chris at kohlhoff dot com) // // Distributed under the Boost Software License, Version 1.0. (See accompanying // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) // #include <iostream> #include <boost/asio.hpp> #include <boost/date_time/posix_time/posix_time.hpp> int main() { boost::asio::io_service io; boost::asio::deadline_timer t(io, boost::posix_time::seconds(5)); t.wait(); std::cout << "Hello, world!\n"; return 0; } -- Ing Pedro Alonso Chaparro Valero Ciudad Politecnica de la Innovación iTEAM - Mobile Communications Group Polytechnic University of Valencia C\ Camino de Vera S/N, Edificio 8G 46022 Valencia, Spain

2 1

[Math] Fractional binomial_coefficient
by Ralf M. 01 Sep '09

01 Sep '09

Hi, the binomial coefficients are usually used with integers, but it is also possible to get the binomial coefficient of real values (cf. http://en.wikipedia.org/wiki/Binomial_coefficient ). Maybe this could be added to the boost math library. Here's a sample implementation using standard g++: template <class T> T Choose(T n, T k) { return exp(lgamma(n + 1.0) - lgamma(k + 1.0) - lgamma(n - k + 1.0)); } Examples using double or long double type: C(10.000000, 3.000000) = 120.000000000000 C(10.000000, 3.250000) = 143.236519908866 C(10.000000, 3.500000) = 166.719334273254 C(10.000000, 3.750000) = 189.361086655990 C(10.000000, 4.000000) = 210.000000000000 C(10.500000, 3.000000) = 141.312500000000 C(10.500000, 3.250000) = 171.461136142499 C(10.500000, 3.500000) = 202.979003906250 C(10.500000, 3.750000) = 234.620815915449 C(10.500000, 4.000000) = 264.960937500000

2 1

[BGL] backward warning
by Ralf Goertz 01 Sep '09

01 Sep '09

When compiling with gcc4.3 I get a backward warning from adjacency_list.hpp because it includes hash_set instead of unordered_set (Boost 1.39.0). Will this be fixed soon? Ralf

2 2

[serialization] binary archiver with generic primitive types
by Florent Teichteil 31 Aug '09

31 Aug '09

Hi all, The binary_oarchive and binary_iarchive classes serialize an object to a stream whose buffer type is streambuf=basic_streambuf<char>. It means that the serialized object is translated into an array of chars. It is fine if you can work with an array containing chars. Unfortunately, some libraries need serialized objects that are translated into arrays whose type is different from char. For instance, I'm using a library that requires an array of unsigned chars. For that reason, I have defined generic (templated) tbinary_oarchive and tbinary_iarchive classes based on the ones provided by the boost serialization library. It is straightforward since the original boost serialization classes use the std::ostream type that is just an instantiation of the generic basic_ostream class with the char type (ostream=basic_ostream<char>). For instance, the tbinary_oarchive class is now defined as follows: // CODE BEGIN template <class Tdata> class tbinary_oarchive : public binary_oarchive_impl< tbinary_oarchive<Tdata>, typename std::basic_ostream<Tdata>::char_type, typename std::basic_ostream<Tdata>::traits_type > { public: tbinary_oarchive(std::basic_ostream<Tdata> & os, unsigned int flags = 0) : binary_oarchive_impl< tbinary_oarchive, typename std::basic_ostream<Tdata>::char_type, typename std::basic_ostream<Tdata>::traits_type >(os, flags) {} tbinary_oarchive(std::basic_streambuf<Tdata> & bsb, unsigned int flags = 0) : binary_oarchive_impl< tbinary_oarchive, typename std::basic_ostream<Tdata>::char_type, typename std::basic_ostream<Tdata>::traits_type >(bsb, flags) {} }; // CODE END Then, when I need to use a binary archiver with the type unsigned char, I just put the following lines in my code: // CODE BEGIN typedef boost::archive::tbinary_oarchive<unsigned char> BinaryOBArchive; typedef boost::archive::tbinary_iarchive<unsigned char> BinaryIBArchive; BOOST_SERIALIZATION_REGISTER_ARCHIVE(BinaryOBArchive) BOOST_SERIALIZATION_REGISTER_ARCHIVE(BinaryIBArchive) // CODE END This compiles fine except that I get some linker errors concerning the basic_binary_oarchive and the basic_binary_oprimitive classes. For instance: undefined reference to `boost::archive::basic_binary_oprimitive<boost::archive::tbinary_oarchive<unsigned char>, unsigned char, std::char_traits<unsigned char> >::~basic_binary_oprimitive()' It seems that parts of the serialization library's code is outside the definition classes, preventing to extend it with different binary types... Is there a workaround? Thank you very much for your patience reading this e-mail entirely, Florent.

4 4

[Graph] Error in cuthill_mckee_ordering in 1.40
by Ryan W. Frenz 31 Aug '09

31 Aug '09

I am attempting to upgrade to boost 1.40 and have found an issue with cuthill_mckee_ordering.hpp. The following code demonstrates the issue. #include <boost/graph/adjacency_matrix.hpp> #include <boost/graph/cuthill_mckee_ordering.hpp> int main() { typedef boost::property<boost::vertex_name_t, std::string> VertexProperty; typedef boost::adjacency_matrix<boost::undirectedS, VertexProperty> MyGraph; typedef boost::graph_traits<MyGraph>::vertex_descriptor Vertex; MyGraph graph(0); // Fill graph with nodes, etc.... // Perform reverse cuthill mckee... std::vector<Vertex> inv_perm(boost::num_vertices(graph)); { boost::cuthill_mckee_ordering(graph, inv_perm.rbegin()); // 'has_no_vertices' error... // do stuff with ordered graph... } return 0; } This code builds cleanly against 1.36 (my previous version) but fails when built against 1.40 with the following: ....boost/graph/cuthill_mckee_ordering.hpp(172): 'has_no_vertices': identifer not found Looking at the code, the function boost::cuthill_mckee_ordering is calling has_no_vertices (with no specified namespace). has_no_vertices (in graph_utility.hpp) lives in the boost::graph namespace. Changing the line to graph::has_no_vertices fixes the compiler error. Is this possibly a bug in 1.40 or am I doing something wrong? Thanks, Ryan

2 2

fast_pool_allocator, std::multi_map and purge_memory
by Soeren Meyer-Eppler 31 Aug '09

31 Aug '09

Hi, I have written a small test program to measure the performance benefit of using a boost::fast_pool_allocator vs the default system allocator in conjunction with a std::multi_map. Memory overhead is ~16% lower and the boost allocator is ~4x faster - sweet. However, I can't release the allocated memory via the singleton_pool interface as described in the documentation. In my test program quoted below the call to purge_memory always returns 0 and according to window's task manager the memory has not been released. An even simpler test just using an allocator for ints and allocating/relasing/purging 10.000.000 ints works as expected. What am I doing wrong? cheers, Sören PS: I'm using boost 1.39 with MSVC2008 #include <map> #include <iostream> #include <boost/pool/pool_alloc.hpp> int main( int, char ** ) { typedef boost::fast_pool_allocator< std::pair< int, void * > > TPoolAllocator; typedef std::multimap< int, void *, std::less< int >, TPoolAllocator > TMap; { TMap map; for ( int i = 0; i < 10000000; ++i ) map.insert( std::make_pair( rand() % 100, (void *)0 )); } std::cout << boost::singleton_pool< boost::fast_pool_allocator_tag, sizeof( TPoolAllocator::value_type ) >::purge_memory(); return 0; }

2 2

Cannot file tickets for 1.40
by Roland Bock 31 Aug '09

31 Aug '09

Hi, I would like to file a few tickets for version 1.40, but TRAC does not know version 1.40 yet. Regards, Roland

2 1

Linker errors with boost's threading and python libs, OSX
by Shamyl Zakariya 31 Aug '09

31 Aug '09

Hi, Yesterday I upgraded boost to 1.4, from 1.36. A big jump, but hey why not. I'm running OSX, 10.6 with the most recent dev tools ( Xcode 3.2, GCC 4.2, etc ) and used the bjam build system as described on the website. Vanilla install to /usr/local/ giving me the static and dynamic libs in /usr/local/lib. Two (related) questions: 1) My project ( built in Xcode ) uses mostly header-based libs, but does link against libboost_thread.a -- and now it throws all sorts of linker errors when it worked just fine linking against 1.36 For example: "boost::thread::~thread()", referenced from: void boost::checked_delete<boost::thread>(boost::thread*)in QTFrameTransfer.o /// many many more And for reference, I really *am* linking against libboost_thread.a 2) My related followup question -- I've *never* been able to link against libboost_python.a. So in the past I added the full source from $BOOST/libs/python/src to a sub-target of my project and manually build my own libboost_python.a which I then linked against. That worked fine. But I don't understand why I can't link against /usr/ local/lib/libboost_python.a I have to assume something's wonky with the way bjam is building these libraries. But I'm following the out-of-the-box install instructions. Finally, I assume I could just build my own local boost the way I used to build boost's python. But I'd rather use the versions in /usr/local/ lib... shamyl zakariya - squamous and rugose

3 2