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

troubles with boost filtering streams
by Daniel Oberhoff 23 Jan '11

23 Jan '11

Hi, I am working on a matlab file reader/writer. Since matlab uses zip to compress variables I was thinking I could use the boost filtering streams with the zip filter to handle that. The use case is that there are zipped blocks inside the file, i.e. not the whole file is zipped but just parts. I am not sure how to handle that with boost, since I would need to start/stop zipping/unzipping at almost arbitrary points in the file. Also I have trouble working with filtering streams at all. As a baseline test I started substituting the fstream I was reading from with a boost filtering istream onto which I pushed the fstream. Reading works fine for a while and then breaks. What I noted is that the fstream tellg always lags behind the actual number of bytes read. also using the fitlering streams tellg breaks the whole stream. also seeking does not seem to work with the filtering stream. I need to seek quite often. seeking only happens when not unzipping. I tried seeking on the fstream instead. that worked up to some point(as stated above). I fear the seeking on the fstream breaks the filtering stream, but seeking on the filtering stream doesn't work. If anyone has pointers that would be great. Best Daniel

1 0

Random permutations using boost::random_number_generator and std::random_shuffle.
by Matthew Gwynne 23 Jan '11

23 Jan '11

Hi, We need the ability to randomly permute some range, and we already have this functionality available in the computer algebra system Maxima. We use Maxima for numerous things, often implementing basic algorithms in it, then later writing more efficient versions in C++. The problem we have is that we'd like to be able to make sure that any function we write to randomly shuffle a range, matches up with the Maxima "random_permutation" function. We believe it uses the Mersenne twister (boost::mt19937) and Knuth shuffle algorithms, and so we thought to implement these in C++ using boost::uniform_distribution, boost:variate_generator etc. However, we have two questions (open problems): 1) How does boost::variate_generator interact with mt19937, and the distribution? Is this documented somewhere? In the attached code, it seems we can construct boost::uniform_distribution with any maximum value, and still the number generator returns values outside of that range? Is this really right? 2) What algorithm does std::random_shuffle implement? (Not boost related specifically but hopefully someone will know) Is this defined by the C++ standard? It doesn't seem to be the simple Knuth shuffle algorithm (starting from top of range to bottom or vice versa) as we implement in the attached code. If anyone could point me in the right direction, I'd very much appreciate it. Thanks Matthew Gwynne http://cs.swan.ac.uk/~csmg/ Code: #include <vector> #include <iostream> #include <algorithm> #include <iterator> #include <cassert> #include <boost/lexical_cast.hpp> #include <boost/random/mersenne_twister.hpp> #include <boost/random/uniform_int.hpp> #include <boost/random/variate_generator.hpp> #include <boost/random/random_number_generator.hpp> namespace { enum { errcode_parameter = 1 }; const std::string program = "RandomShuffle"; const std::string err = "ERROR[" + program + "]: "; const std::string version = "0.0.3"; const int default_seed = 1; typedef boost::mt19937 base_generator_type; base_generator_type base_rand_gen; inline void set_random(const int seed) { assert(seed >= 1); base_rand_gen.seed(seed); } const unsigned int default_N = 10; typedef std::vector<int> vec_t; inline void initialise(vec_t& a) { for (unsigned int i = 0; i < a.size(); ++i) a[i] = i+1; } inline void output(const vec_t& a) { for (unsigned int i = 0; i < a.size(); ++i) std::cout << a[i] << " "; std::cout << "\n"; } template <class RandomAccessIterator, class RandomNumberGenerator> inline void random_shuffle(const RandomAccessIterator first, const RandomAccessIterator last, RandomNumberGenerator& rand) { typedef typename std::iterator_traits<RandomAccessIterator>::difference_type difference_type; difference_type n = last - first; assert(n >= 0); if (n <= 1) return; for (RandomAccessIterator i = first; i != last-1; ++i,--n) { const difference_type r = rand(n); assert(r >= 0); assert(r < n); std::iter_swap(i, i+r); } assert(n == 1); } } int main(const int argc, const char* const argv[]) { if (argc > 3) { std::cerr << err << "\n At most two arguments are allowed " "(the seed for the random-number generator and the number of elements).\n"; return errcode_parameter; } const int seed = (argc == 1) ? default_seed : boost::lexical_cast<int>(argv[1]); const unsigned int N = (argc < 3) ? default_N : boost::lexical_cast<unsigned int>(argv[2]); vec_t V(N); typedef boost::uniform_int<> uniform_distribution_type; uniform_distribution_type uniform_distribution(0,std::numeric_limits<int>::max()); // is this correct??? typedef boost::variate_generator<base_generator_type&, uniform_distribution_type> generator_type; generator_type rand_gen(base_rand_gen, uniform_distribution); typedef boost::random_number_generator<generator_type> RandomNumberGenerator; RandomNumberGenerator rg(rand_gen); set_random(seed); std::cout << "Underlying random sequence:\n"; for (long n = V.size(); n > 1; --n) std::cout << rg(n) << " "; std::cout << "\n\n"; initialise(V); set_random(seed); std::random_shuffle(V.begin(), V.end(), rg); std::cout << "std::random_shuffle:\n"; output(V); initialise(V); set_random(seed); ::random_shuffle(V.begin(), V.end(), rg); std::cout << "::random_shuffle:\n"; output(V); }

2 4

[Boost 1.34] Unsatisfied symbol "boost::thread::~thread()
by Alexander Vinokur 23 Jan '11

23 Jan '11

Hi, I have the following problem. Boost 1.34 HP-UX B.11.23 U ia64 aCC: HP C/aC++ B3910B A.06.25.01 [May 16 2010] // ------ vvv1.cpp ------ #include <boost/thread.hpp> void tproc() {} int main() { boost::thread t(tproc); t.join(); return 0; } // ----------------------- Compilation-1. > aCC +DD64 -AA -mt -I$BOOST_HOME vvv1.cpp ld: Unsatisfied symbol "boost::thread::~thread()(complete)" in file vvv1.o ld: Unsatisfied symbol "boost::thread::thread(boost::function0<void,std::allocator<boost::function_base> > const&)(complete)" in file vvv1.o ld: Unsatisfied symbol "boost::thread::join()" in file vvv1.o 3 errors. Compilation-2. > aCC +DD64 -AA -mt -lboost_thread-mt -I$BOOST_HOME vvv1.cpp ld: Can't find library for -lboost_thread-mt Fatal error. What is wrong? Thanks Alex Vinokur This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp

2 1

serialization binary file backwards compatibility issue 1.42 -> 1.45
by Jake Brownson 23 Jan '11

23 Jan '11

I see in the changelog (http://www.boost.org/doc/libs/1_45_0/libs/serialization/doc/release.html) that files serialized with 1.42's binary serialization will have problems opening in 1.45. This is exactly what I'm experiencing. Luckily we have only used 1.42 in our project up to this point when we are testing for a release including boost 1.45, so we know all of our previous files were saved using 1.42. We should be able to automatically apply the fix_six fix when loading old files (I can tell by the filename when it's an old one). However I'm confused because fix_six bumps the version from 6 to 7, but in my copy of boost 1.42 serialization is already saving files w/ a library version of 7. Did 1.42 get patched to fix this issue already, or am I misunderstanding something? I found a recent thread where Robert Ramey asked someone to try trunk. I just did this and without the fix_six fix the files seem to be loading properly. Thanks, Jake

2 2

[Fusion] Building parameter list for fusion::invoke
by Vivek 23 Jan '11

23 Jan '11

I am building a library in which users pass in function pointers of any type. I would like the library to determine the function's signature (using function_types), build a fusion vector for the function's arguments, populate the vector with data from a particular source, and then invoke the function using fusion::invoke. The kicker is that the argument types may not be default constructible. Therefore I need a way of initializing a fusion vector from a source as it is being created. For example, the following won't work namespace ft = ::boost::function_types; namespace bf = ::boost::fusion; struct non_def_type { private: non_def_type(); }; void my_func(non_def_type); template <typename FPTR> void my_invoker(FPTR f) { typedef typename ft::parameter_types<FPTR>::type parameter_types; typedef typename bf::result_of::as_vector<parameter_types>::type parameter_vector; parameter_vector params; // error if FPTR contains a parameter_type that is not default-constructible // // ... do something to populate params from data source // bf::invoke(f, params); } int main() { my_invoker(my_func); } Any idea how I might initialize the fusion vector as it is being created? I feel like there might be a way to transform parameter_types into a version in which each type is wrapped in a default-constructible wrapper, then transform that list into the final boost fusion list while at the same time populating it with data, but I can't seem to get the functors to work. E.g.: template <typename T> struct type_wrapper { type_wrapper() {} }; template <typename T> struct wrap { typedef type_wrapper<T> type; }; // Metafunction to unwrap types, and function to populate data // (data should never need to be default-constructible) struct fill { template <typename SIG> struct result; template <typename T> struct result<fill(const type_wrapper<T>&)> { typedef T type; }; // Reference type needed for bf::transform_view template <typename T> struct result<fill(type_wrapper<T>&)> { typedef T type; }; // Non-reference type needed for bf::vector template <typename T> struct result<fill(type_wrapper<T>)> { typedef T type; }; template <typename T> T operator()(const type_wrapper<T>&) const {return data_source<T>().pop();} }; template <typename FPTR> void my_invoker(FPTR f) { typedef typename ft::parameter_types<FPTR>::type parameter_types; // Conversion 1: create a fusion vector with types wrapped in a // default-constructible wrapper typedef mpl::transform<parameter_types, wrap<mpl::_1>, mpl::back_inserter<mpl::vector<> > >::type wrapped_parameter_types; typedef typename bf::result_of::as_vector<wrapped_parameter_types>::type wrapped_parameter_vector; // Conversion 2: create a fusion vector with the unwrapped types // that is also populated with the data from the data_source // (without having to ever default_construct any of the parameter_types) typedef typename bf::result_of::transform<const wrapped_params, fill>::type params_view; typedef typename bf::result_of::as_vector<const params_view>::type params_t; // Finally: invoke the function with arguments bf::invoke(f, bf::as_vector(bf::transform(params_view(), fill()))); } I can't seem to get the meta-function calls or the 'fill' metafunction itself quite right, instead getting vast reams of compiler complaints. Am I missing something? Or alternatively, is there a direct way to initialize a fusion vector? Many thanks, Vivek

3 2

[boost.thread] function call and functor in thread creation: performance
by Boost lzw 22 Jan '11

22 Jan '11

Hi, everyone, A new thread can be created using boost thread either from a function or a functor as the entry point of the new thread, as: void thread_function(); boost::thread thrd(&function); class functor { public: inline void operator()(); }; functor f; boost::thread thrd(f); Is there a performance difference between these two? In an ordinary C++ program, can I claim that calling f() 1000 times gives better performance than calling thread_function() 1000 times, because the functor is hinted "inline" even the hint is igored by my compiler? Is f() the same as a function call in term of performance? Thanks in advance. Robert

3 3

boost.iterators - iterator_facade issue with aligned types.
by Christoph Heindl 21 Jan '11

21 Jan '11

Hi, It seems to me that boost::iterator_facade cannot cope with aligned types when the 'Reference = use_default' template argument is not a reference, which can happen if transform_iterator is used to return the result of a temporay calculation (by value of course). Inside iterator_facade.hpp struct operator_arrow_result { //... static type make(Reference x) { return implicit_cast<type>(&x); } }; Reference here is passed by value. Since Reference has alignment the compiler reports an error. The issue was resolved once i changed that code to struct operator_arrow_result { //... typedef typename mpl::if_< is_reference<Reference> , Reference , typename add_reference<Reference>::type >::type input_type; static type make(input_type x) { return implicit_cast<type>(&x); } }; I wonder about any side effects this would cause? My lousy research is based boost 1.43. That part of the code seems to be unchanged for the current trunk. Best regards, Christoph

2 4

Re: [Boost-users] Assertion `__null != bpos' failed in /inclu de/boost/archive/detail/oserializer.hpp:436
by ktomaszewski＠zunit.com 21 Jan '11

21 Jan '11

2 1

Re: [Boost-users] Assertion `__null != bpos' failed in /inclu de/boost/archive/detail/oserializer.hpp:436
by ktomaszewski＠zunit.com 21 Jan '11

21 Jan '11

1 0

Re: [Boost-users] Assertion `__null != bpos' failed in /inclu de/boost/archive/detail/oserializer.hpp:436
by ktomaszewski＠zunit.com 21 Jan '11

21 Jan '11

1 0

Assertion `__null != bpos' failed in /inclu de/boost/archive/detail/oserializer.hpp:436
by ktomaszewski＠zunit.com 20 Jan '11

20 Jan '11

2 1

Thread-specific pointers versus MFC (Microsoft)
by Stephen Nuchia 20 Jan '11

20 Jan '11

I see a thread about this issue from 2009, with no resolution. A possible patch was mentioned but there was never a followup. We picked up the thread-specific pointer goodness with 1.35, under Visual Studio 2008. We stayed with that combination ever since, for stability. Now I'm looking at VS2010 and 1.44. To support Microsoft's thread model in DLL (dynamically linked libraries) in 1.35 required the user to intercept library unload events. Shortly after 1.35, the boost thread library was enhanced to take care of this for you. The hook it uses, however, conflicts with the use of that same hook by Microsoft's MFC library, when you are building an "MFC Extension DLL" specifically. We have a bunch of that going on. The conflict ends up being detected at link time, like this: 1>libboost_thread-vc100-mt-gd-1_44.lib(tss_pe.obj) : error LNK2005: _pRawDllMain already defined in Table.obj The archive discussion http://thread.gmane.org/gmane.comp.lib.boost.user/46509/focus=46706 What is the current thinking on this issue? I don't see any #ifdef logic in the boost headers that looks like it might be intended to address this, do I need to hack it myself or is there an established work-around? And don't dog me about MFC. Some of the code I'm dealing with is still in FORTRAN, and some is 25-year-old C. Thanks! -swn

1 0

[BGL] Threshold for betweenness_centrality_clustering()
by Cedric Laczny 20 Jan '11

20 Jan '11

Hi, I would like to use boost::betweenness_centrality_clustering() to search a graph for specific clusters. The documentation talks about a "Done" object, which I assume is a functor, similar to the predicates used in filtered_graph(). So in order to decide whether the algorithm should stop the clustering, it probably needs a threshold to decide if it should further iterate and remove edges to decompose the graph. My questions now are: - Does someone perhaps have an example for the usage of this algorithm? I only found documentation on "betweenness.centrality.clustering {RBGL}" for Gnu R, which doesn't bring me very far. - Is there some sort of rule-of-thumb to start with for finding this termination threshold or if there is some more-or-less methodical way of finding out a reasonable threshold? Best, Cedric

4 4

regex __sync_fetch_and_add_4 issue when compiling to 32 bit Linux
by Ákos Maróy 20 Jan '11

20 Jan '11

Hi, I seem to have a problem when trying to link C++ code that refers to the boost regex library, when this is done so that it is compiled on a 64 bit Linux system, but for a 32 bit target. I get the following error: libboost_regex.so: undefined reference to `__sync_fetch_and_add_4' collect2: ld returned 1 exit status I wonder what needs to be done to fix this. steps to reproduce: - compile boost for 32 bit, by: ./bjam architecture=x86 address-model=32 --prefix=/path/to/boost install - try to compile & link a very simple sample code (see the end of the mail) g++ -m32 -L//path/to/boost/lib -I/path/to/boost/include -lboost_regex -o hello hello.cxx /path/to/boost/lib/libboost_regex.so: undefined reference to `__sync_fetch_and_add_4' collect2: ld returned 1 exit status when compiling the same code for 64 bit, it compiles fine. seeing this thread: http://lists.boost.org/Archives/boost/2008/04/135586.php I also tried the following: g++ -m32 -DBOOST_SP_USE_PTHREADS -L//path/to/boost/lib -I/path/to/boost/include -lboost_regex -o hello hello.cxx g++ -m32 -DBOOST_SP_DISABLE_THREADS -L//path/to/boost/lib -I/path/to/boost/include -lboost_regex -o hello hello.cxx but I got the same results :( any help would be appreciated. Akos details: platfrom: Ubuntu 10.10 64 bit compiler: g++ 4.4.4 boost: 1.45.0 the sample code I used is very minimalistic: #include <boost/regex.hpp> int main(void) { boost::regex LF("\\\\n"), CR("\\\\r"), TAB("\\\\t"); return 0; }

4 8

[polygon] Quadratic performance when handling any angle polygons
by Josh Pieper 19 Jan '11

19 Jan '11

Hello, First: we are using boost 1.45.0 with gcc -O3 on Ubuntu 10.04. (Although similar problems appear with VS2008 on Windows 7). We have been observing performance with boost::polygon that is significantly worse than we were expecting when working with any angle polygons. Namely quadratic instead of the expected O(n log n). While profiling, I noticed that most of the time is spent in the overload of line_intersection::validate_scan at detail/scan_arbitrary.hpp:154 which is commented as: "//quadratic algorithm to do same work as optimal scan for cross checking". I have inlined our test program below, and some performance results measured by instruction count under "valgrind --tool=callgrind". Is this poor performance because our data is degenerate, or because a vestigal quadratic double check is still being applied? Regards, Josh Pieper Performance results for n=10..110 measured in instructions to complete the following test program: 10 2363923 20 4427849 30 8695564 40 15642559 50 25530188 60 39081335 70 57151093 80 79278939 90 107261217 100 140674559 110 164340087 -------------------------- #include <boost/lexical_cast.hpp> #include <boost/type.hpp> #include <boost/polygon/polygon.hpp> #include <boost/polygon/gmp_override.hpp> int main(int argc, char** argv) { typedef boost::polygon::point_data<int32_t> point_type; typedef boost::polygon::polygon_set_data<int32_t> polygon_set; typedef polygon_set::value_type value_type; int32_t sample_data[] = { -15417, -53418, 0, 0, -1, -15417, -53418, 37998, -68834, 1, 37998, -68834, 53415, -15416, 1, 0, 0, 53415, -15416, -1, -20188, -37532, 15869, 4788, -1, -20188, -37532, 22129, -73587, 1, 22129, -73587, 58187, -31268, 1, 15869, 4788, 58187, -31268, -1, -12388, -58060, -4666, -3001, -1, -12388, -58060, 42669, -65781, 1, 42669, -65781, 50390, -10722, 1, -4666, -3001, 50390, -10722, -1, -16452, -51370, 2015, 1078, -1, -16452, -51370, 35988, -69834, 1, 35988, -69834, 54455, -17386, 1, 2015, 1078, 54455, -17386, -1, -9812, -61108, -7737, -5548, -1, -9812, -61108, 45744, -63182, 1, 45744, -63182, 47819, -7623, 1, -7737, -5548, 47819, -7623, -1, -19695, -27418, 25940, 4341, -1, -19695, -27418, 12063, -73050, 1, 12063, -73050, 57697, -41291, 1, 25940, 4341, 57697, -41291, -1, -11871, -58680, -5330, -3460, -1, -11871, -58680, 43338, -65220, 1, 43338, -65220, 49879, -10000, 1, -5330, -3460, 49879, -10000, -1, -12303, -10547, -4768, -65638, 1, -4768, -65638, 50314, -58104, 1, 42779, -3013, 50314, -58104, -1, -12303, -10547, 42779, -3013, -1, -10105, -60739, -7415, -5202, -1, -10105, -60739, 45425, -63428, 1, 45425, -63428, 48115, -7891, 1, -7415, -5202, 48115, -7891, -1, -9937, -60912, -7600, -5360, -1, -9937, -60912, 45609, -63249, 1, 45609, -63249, 47946, -7697, 1, -7600, -5360, 47946, -7697, -1, -20348, -32184, 16794, -73555, 1, 16794, -73555, 58164, -36414, 1, 21022, 4957, 58164, -36414, -1, -20348, -32184, 21022, 4957, -1, -10796, -8606, -6653, -64049, 1, -6653, -64049, 48788, -59906, 1, 44644, -4463, 48788, -59906, -1, -10796, -8606, 44644, -4463, -1, -16263, -16858, 1613, -69511, 1, 1613, -69511, 54257, -51638, 1, 36381, 1014, 54257, -51638, -1, -16263, -16858, 36381, 1014, -1, -20298, -33057, 17817, -73534, 1, 17817, -73534, 58292, -35421, 1, 20177, 5056, 58292, -35421, -1, -20298, -33057, 20177, 5056, -1, -11941, -9961, -5271, -65159, 1, -5271, -65159, 49923, -58490, 1, 43253, -3292, 49923, -58490, -1, -11941, -9961, 43253, -3292, -1, -19046, -44168, 28939, -72250, 1, 28939, -72250, 57020, -24267, 1, 9035, 3815, 57020, -24267, -1, -19046, -44168, 9035, 3815, -1, -10926, -8703, -6528, -64127, 1, -6528, -64127, 48893, -59729, 1, 44495, -4305, 48893, -59729, -1, -10926, -8703, 44495, -4305, -1, -19113, -43924, 28699, -72304, 1, 28699, -72304, 57076, -24496, 1, 9263, 3883, 57076, -24496, -1, -19113, -43924, 9263, 3883, -1, -18256, -21581, 6351, -71437, 1, 6351, -71437, 56204, -46832, 1, 31598, 3024, 56204, -46832, -1, -18256, -21581, 31598, 3024, -1, -20282, -31991, 16756, -73456, 1, 16756, -73456, 58219, -36421, 1, 21181, 5045, 58219, -36421, -1, -20282, -31991, 21181, 5045, -1, -19379, -25528, 10293, -72546, 1, 10293, -72546, 57309, -42875, 1, 27637, 4143, 57309, -42875, -1, -19379, -25528, 27637, 4143, -1, -16209, -16633, 1396, -69371, 1, 1396, -69371, 54130, -51767, 1, 36526, 970, 54130, -51767, -1, -16209, -16633, 36526, 970, -1, -18570, -22483, 7245, -71726, 1, 7245, -71726, 56484, -45912, 1, 30669, 3330, 56484, -45912, -1, -18570, -22483, 30669, 3330, -1, -19900, -40189, 24948, -73049, 1, 24948, -73049, 57806, -28203, 1, 12958, 4657, 57806, -28203, -1, -19900, -40189, 12958, 4657, -1, -20322, -36011, 20774, -73460, 1, 20774, -73460, 58220, -32367, 1, 17124, 5082, 58220, -32367, -1, -20322, -36011, 17124, 5082, -1, -555, -68328, 53079, -53671, 1, 38424, -43, 53079, -53671, -1, -15210, -14699, 38424, -43, -1, -15210, -14699, -555, -68328, 1, 21671, -61840, 21718, -61835, 1, 14689, -61655, 21718, -61835, -1, 14689, -61655, 42185, -65881, 1, 42185, -65881, 50629, -10931, 1, 23134, -6705, 50629, -10931, -1, 16104, -6524, 23134, -6705, -1, 16057, -6529, 16104, -6524, -1, 16057, -6529, 21671, -61840, 1, -7903, -63005, 47680, -60927, 1, 45602, -5370, 47680, -60927, -1, -9981, -7449, 45602, -5370, -1, -9981, -7449, -7903, -63005, 1, }; value_type edge_list; size_t num_elements = sizeof(sample_data) / (sizeof(*sample_data) * 5); if (argc > 1) { num_elements = std::min(num_elements, boost::lexical_cast<size_t>(argv[1])); } for (size_t i = 0; i < num_elements; i++) { value_type::value_type edge_plus; int32_t* record = &sample_data[i * 5]; edge_plus.first.first = point_type(record[0], record[1]); edge_plus.first.second = point_type(record[2], record[3]); edge_plus.second = record[4]; edge_list.push_back(edge_plus); } polygon_set pset; pset.set(edge_list); pset.clean(); }

2 2

Re: [Boost-users] [boost] Distributed Development Process (was Re: Development Practices (Proposal Progress))
by Dean Michael Berris 19 Jan '11

19 Jan '11

Update: There is more information on the Wiki page now, pertaining to a few more definitions and the beginnings of the process discussion. Please see: https://svn.boost.org/trac/boost/wiki/DistributedDevelopmentProcess You may have to refresh the page to get the latest version. Basically, the changes there now include: - Definition for the role of a Review Manager - Definition for the role of a Review Manager Assistant (lifted from Joachim's suggestion) - Definition for the "Boost Community" - The definition of a lower barrier to entry style Acceptance Review process - The hint of a Maintenance Review process Feedback on the contents -- both old and new -- would be most appreciated. Thanks in advance and I hope to hear from the community soon! -- Dean Michael Berris about.me/deanberris

1 0

Boost.Pool - Are you using this library, please can we have your input?
by Paul A. Bristow 19 Jan '11

19 Jan '11

Boost.Pool is the subject of a 'make-over' by Boost.Guild. (This is some of a test-bed for a process of revision of older, perhaps orphaned, libraries using the relative safety of the sandbox). In order to permit any modification, the original (hand-written?) html documentation has been converted to Quickbook (and somewhat revised) at http://svn.boost.org/svn/boost/sandbox/guild/pool/libs/pool/doc/ You can build the html docs using the jamfile.v2 in the normal way, but you will probably find it more convenient to go direct to the pdf version http://svn.boost.org/svn/boost/sandbox/guild/pool/libs/pool/doc/pool.pdf This is fairly fully hyperlinked, and includes a reference section using Doxygen. Doxygen comments have been added to the header files (from the original html docs). (If you are a Doxygen fan, there is also a Doxyfile for generating Doxygen-style docs in the /doc/Doxygen/ folder). We are now considering some better tests, and perhaps some enhancements to the code. We'd like input from users about: 1 Things missing or wrong from the docs. More up to date references? 2 Things missing (or don't work well) from Pool. 3 New things that you would like (this is not a promise!). 4 Examples of your use. Perhaps you built some during your development that could be used? 5 Better tests. Thanks. Paul PS Don't panic - the release version will not be changed without a mini-review. --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

7 8

Time Series lib
by Peter Godino 19 Jan '11

19 Jan '11

I've found there is a boost lib called Time Series. It is not yet in SVN. Is it possible access this library? Thanks, Peter

2 2

Having program_options generate a round-trippable config file?
by Rhys Ulerich 19 Jan '11

19 Jan '11

Hi all, I'm using program_options to combine arguments from the command line, the environment, and one or more input files. As you'd expect, it works very well. However, I have an additional requirement that I'm unsure how to implement cleanly atop the library: Given instances of program_options::options_description and program_options::variables_map, I'd like to save a program_options::parse_config_file-friendly file containing the final values obtained. Such a config file could be given back to the program and would identically reproduce the options used. The need is for some scientific software where I want a precise record of what a user has chosen for reasons of scientific repeatability. I see several ways to go about achieving this need, but all of them are ugly, brittle hacks: 1) Accessing the information directly from variables_map seems difficult due to variables_map's use of type erasure and the fact that it does not save the tokens from which values are derived. 2) Obtaining the tokens from the intermediate program_options::parsed_options instances is a possibility but requires me to effectively reimplement the logic contained within program_options::store. It also fails to account for defaulted values. 3) Looping over each program_options::value_semantic found in the options_description instance and adding a notify() callback again runs into type erasure troubles. 4) Adding a notify() to each option_description at its point of declaration avoids type erasure but makes the code impact O(n) where n is the number of options. Has anyone built such a feature atop program_options? Can anyone lend some wisdom? Thanks, Rhys

2 1

boost.type_traits - is_convertible issue with aligned types
by Christoph Heindl 19 Jan '11

19 Jan '11

Hi, consider the following simple example struct aligned_type { __declspec(align(16)) float vals[4]; }; BOOST_STATIC_ASSERT((boost::is_convertible<aligned_type , aligned_type >::value)); It fails on MSVC 9.0 with boost 1.43 with the following error type_traits/is_convertible.hpp(254) : error C2719: 'unnamed-parameter': formal parameter with __declspec(align('16')) won't be aligned References won't help either BOOST_STATIC_ASSERT((boost::is_convertible<aligned_type &, aligned_type &>::value)); as it breaks with a similar error type_traits/is_convertible.hpp(263) : error C2718: 'const vec_aligned': actual parameter with __declspec(align('16')) won't be aligned A bug database search did not bring up any relevant matches, so I wonder if that is a new issue or just by design? Best regards, Christoph

2 7

[Proto] Returns double
by Hossein Haeri 18 Jan '11

18 Jan '11

Dear all, I am working in an application where I use Proto to evaluate an expression template like _1 >> f >> g to g(f(x)) once x is assigned to _1. (Please note that f and g are not necessarily functions -- they might be function objects too.) I am interested in putting a compile-time sanity check to ensure that the functions/function objects f and g do indeed return a double (or something convertible to it). For that, I wrote the following grammar which GCC 4.5.1 (Boost 1.42, MinGW32, WinXP, SP3) doesn't like, with the error messages being at the P.S. section: struct EmtnRet2DblChk: or_ < terminal<_>, and_ < shift_right<EmtnRet2DblChk, terminal<_> >, if_ < typename boost::is_convertible < typename boost::result_of<(_value(_right))(double)>::type, double >::type > > > {}; (The above code starts in my line 81 and ends in my line 98.) Any idea please? TIA,--Hossein P.S. Compiling: main.cpp main.cpp:98:2: error: a cast to a type other than an integral or enumeration type cannot appear in a constant-expression main.cpp:98:2: error: template argument 1 is invalid main.cpp:92:22: error: wrong number of template arguments (1, should be 2) /boost/type_traits/is_convertible.hpp:418:1: error: provided for 'template<class From, class To> struct boost::is_convertible' main.cpp:90:21: error: template argument 1 is invalid main.cpp:88:4: error: template argument 2 is invalid 85:3: error: template argument 2 is invalid main.cpp:98:3: error: expected '{' before ';' token

1 0

[asio] io_service hang on stop
by Daniele Barzotti 18 Jan '11

18 Jan '11

Hi, I designed a library to start a io_service background thread when the first object is created (these objects use serial_port) and to terminate it when the last object is destroyed. This is the io_worker_thread: void io_worker_thread(void) { io_service.reset(); io_service.run(); p_work.reset(); io_service.stop(); thread_started = false; }; All seems to work, when the last object is destroyed the io_service.run() returns...but the calling application hang! I noted that the win_thread::join() (in win_thread.ipp) is still running and waiting on "::WaitForSingleObject(thread_, INFINITE);" Follow I post the threads and the call stack when the application is ended: ----------------------------------------------- Main Thread Main Thread boost::asio::detail::win_thread::join Worker Thread _threadstartex `io_worker_thread'::`2'::com_init::~com_init Worker Thread _threadstartex _endthreadex Worker Thread _TppWaiterpThread@4 _ZwWaitForMultipleObjects@20 Worker Thread _TppWorkerThread@4 _NtWaitForWorkViaWorkerFactory@8 Worker Thread _TppWorkerThread@4 _NtWaitForWorkViaWorkerFactory@8 RPC Thread RPC Callback Thread _NtDelayExecution@8 Worker Thread _TppWorkerThread@4 _ZwWaitForSingleObject@12 ----------------------------------------------- ntdll.dll!_ZwWaitForSingleObject@12() ntdll.dll!_ZwWaitForSingleObject@12() kernel32.dll!_WaitForSingleObjectExImplementation@12() kernel32.dll!_WaitForSingleObject@8() AxEuroATLib_debug.dll!boost::asio::detail::win_thread::join() AxEuroATLib_debug.dll!boost::asio::detail::win_iocp_io_service::shutdown_service() AxEuroATLib_debug.dll!boost::asio::detail::service_registry::~service_registry() AxEuroATLib_debug.dll!boost::asio::detail::service_registry::`scalar deleting destructor'() AxEuroATLib_debug.dll!boost::asio::io_service::~io_service() AxEuroATLib_debug.dll!`dynamic atexit destructor for 'io_service''() AxEuroATLib_debug.dll!_CRT_INIT(void * hDllHandle=0x5b880000, unsigned long dwReason=0, void * lpreserved=0x00000000) AxEuroATLib_debug.dll!__DllMainCRTStartup(void * hDllHandle=0x5b880000, unsigned long dwReason=0, void * lpreserved=0x00000000) AxEuroATLib_debug.dll!_DllMainCRTStartup(void * hDllHandle=0x5b880000, unsigned long dwReason=0, void * lpreserved=0x00000000) ntdll.dll!_LdrpCallInitRoutine@16() ntdll.dll!_LdrpUnloadDll@8() ntdll.dll!_LdrUnloadDll@4() KernelBase.dll!_FreeLibrary@4() ole32.dll!77229562() [Frames below may be incorrect and/or missing, no symbols loaded for ole32.dll] ole32.dll!77229593() ole32.dll!772295a7() ole32.dll!772298bf() ole32.dll!77229805() ole32.dll!77229a8c() msvbvm60.dll!7294b681() msvbvm60.dll!72946299() msvbvm60.dll!7294613e() user32.dll!_InternalCallWinProc@20() + 0x23 bytes user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes user32.dll!_SendMessageWorker@24() + 0x112 bytes user32.dll!_SendMessageA@16() + 0x4c bytes msvbvm60.dll!7294b5f6() msvbvm60.dll!7294a9cf() user32.dll!_NtUserPeekMessage@20() + 0x15 bytes msvbvm60.dll!7294a95c() msvbvm60.dll!7294a8e2() msvbvm60.dll!7294a6cf() msvbvm60.dll!7294a63f() msvbvm60.dll!7294a5e1() msvbvm60.dll!7294a51d() msvbvm60.dll!7294a4e8() msvbvm60.dll!72943644() EuroATLibTest.exe!___vbaS() + 0xa bytes BASIC ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes How can I solve? Regards, Daniele.

1 0

[asio] Problem implementing a line-based protocol
by Hannes Brandstätter-Müller 18 Jan '11

18 Jan '11

I am trying to write a server and client that use a line-based text protocol for communication. It works rather well now, but there is some weird problem: One of my messages loses the first 4 characters. (reproducible, but I don't do anything special in that one case, I think) boost::asio::async_read_until is used to read the line into a boost::asio::streambuf the socket is a boost::asio::local::stream_ protocol::socket std::string msg; std::istream is(&buffer); std::getline(is, msg); I looked at the buffer.size(), the size reported to the handler function and compared it to the length of the message, which looks consistant, so I don't assume that the read call read some characters over the \n. (but that would be the only logical explanation) * there are no multiple read operations on the socket * I reuse the same buffer for multiple async_read_until calls Does anyone have a code snippet that can help me figure out what could be stuck and lost in the buffer, or where else the problem could be?

2 7

issue when using boost::tokensizer with std::wstring.
by Sean Farrow 18 Jan '11

18 Jan '11

Hi: I'm trying to use boost::tokenizer and have included boost/tokenizer.hpp. I get the errors below when trying to compile the following code: std::wstring TokensStr(Item); boost::tokenizer<> Tokens(TokensStr); Item, is defined as a BSTR. the errors are: 1>c:\program files\boost\boost\tokenizer.hpp(59): error C2664: 'std::_String_const_iterator<_Elem,_Traits,_Alloc>::_String_const_iterator(const std::_String_const_iterator<_Elem,_Traits,_Alloc> &)' : cannot convert parameter 1 from 'std::_String_const_iterator<_Elem,_Traits,_Alloc>' to 'const std::_String_const_iterator<_Elem,_Traits,_Alloc> &' with [ _Elem=char, _Traits=std::char_traits<char>, _Alloc=std::allocator<char> ] and [ _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, _Alloc=std::allocator<wchar_t> ] and [ _Elem=char, _Traits=std::char_traits<char>, _Alloc=std::allocator<char> ] Reason: cannot convert from 'std::_String_const_iterator<_Elem,_Traits,_Alloc>' to 'const std::_String_const_iterator<_Elem,_Traits,_Alloc>' with [ _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, _Alloc=std::allocator<wchar_t> ] and [ _Elem=char, _Traits=std::char_traits<char>, _Alloc=std::allocator<char> ] No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called d:\work\access for everyone\sibelius access\sibeliusaccessserver\sibeliusaccess.cpp(231) : see reference to function template instantiation 'boost::tokenizer<>::tokenizer<std::wstring>(const Container &)' being compiled with [ Container=std::wstring ] 1>c:\program files\boost\boost\tokenizer.hpp(59): error C2664: 'std::_String_const_iterator<_Elem,_Traits,_Alloc>::_String_const_iterator(const std::_String_const_iterator<_Elem,_Traits,_Alloc> &)' : cannot convert parameter 1 from 'std::_String_const_iterator<_Elem,_Traits,_Alloc>' to 'const std::_String_const_iterator<_Elem,_Traits,_Alloc> &' with [ _Elem=char, _Traits=std::char_traits<char>, _Alloc=std::allocator<char> ] and [ _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, _Alloc=std::allocator<wchar_t> ] and [ _Elem=char, _Traits=std::char_traits<char>, _Alloc=std::allocator<char> ] Reason: cannot convert from 'std::_String_const_iterator<_Elem,_Traits,_Alloc>' to 'const std::_String_const_iterator<_Elem,_Traits,_Alloc>' with [ _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, _Alloc=std::allocator<wchar_t> ] and [ _Elem=char, _Traits=std::char_traits<char>, _Alloc=std::allocator<char> ] No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called Does anyone know how I can solve these errors. Any help appreciated. Regards Sean.

2 3

[boost::python] iterator from member container
by Ralf Goertz 18 Jan '11

18 Jan '11

Is ist possible to have a class that has a map as member like struct Foo { std::map<string,int> bar; }; and then something like class_<Foo>("Foo") .def("__iter__", iterator<std::map<string,int>()); so that in python an object foo of type Foo can be used like this for i in foo: <do something with the bar iterator i> ? Ralf

2 1