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

Re: [Boost-users] Serialization problem
by christophe loustaunau 20 Feb '08

20 Feb '08

That's it ! Many thanks Sebastian ! 2008/2/20, MOSS Sebastian <Sebastian.MOSS(a)murex.com>: > > Hi Christophe, > > At a first guess, could you try creating your fstreams with > std::ios::binary? > > s > > > -----Original Message----- > > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > > bounces(a)lists.boost.org] On Behalf Of christophe loustaunau > > Sent: Wednesday, February 20, 2008 11:27 AM > > To: boost-users(a)lists.boost.org > > Subject: [Boost-users] Serialization problem > > > > Hello, > > > > I try to use serialization of boost. I have started with the exemple > of > > bus stop in XML : > > http://www.boost.org/libs/serialization/example/demo_xml.cpp > > > > I have added to this example a map of 1000 bus_schedule. Then I save > this > > map in a file. > > And I relaod this file in a new map. > > This works perfectly in XML, but if I try : binary_iarchive I got an > > boost::archive::archive_exception at memory location 0x00dfdb40.. > > > > I don't understand why It woks in XML and not in binary. > > I have attached to the mail the source file. > > > > If someone could help me It would be great ! > > > > Thanks. > > > > -- > > Christophe Loustaunau. > > ******************************* > This e-mail contains information for the intended recipient only. It may > contain proprietary material or confidential information. If you are not > the intended recipient you are not authorised to distribute, copy or use > this e-mail or any attachment to it. Murex cannot guarantee that it is virus > free and accepts no responsibility for any loss or damage arising from its > use. If you have received this e-mail in error please notify immediately > the sender and delete the original email received, any attachments and all > copies from your system. > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > -- Christophe Loustaunau.

1 0

question on boost package
by Machiel Richards 20 Feb '08

20 Feb '08

Hi Everyone...I am now asking about a package that I do not know at all. We are running Suse enterprise linux 9 and I am trying to install a plugin for nagios but I am getting the message that libboost.thread could not be found. I tried to look for the package on the system but could not find. I then tried looking for it on the net but no luck in finding the install packages. Can anyone please assist? *** Disclaimer *** The information contained in this e-mail is confidential and legally privileged and is intended solely for the addressee and to others who have the authority to receive it. Access to this e-mail by anyone else is unauthorized and as such, any disclosure, copying, distribution or any action taken or omitted in reliance on it is unlawful. If you have received this e-mail in error, please notify the sender immediately. The views expressed in this e-mail are the views of the individual sender and should in no way be construed as the views of the Company. The Company is not liable to ensure that outgoing e-mails are virus-free. The Company is not liable, should information or data, for whatever reason, be corrupted or fail to reach its intended addressee. The Company is not liable for any loss or damage of whatsoever nature and howsoever arising resulting from the opening or the use of the information in this e-mail, including its attachments and links. The sender of this e-mail is subject to and bound by the terms and conditions of Company’s Electronic Communications Usage Policy.

2 2

Pairing ptr_containers with zip iterators
by Charles Brockman 20 Feb '08

20 Feb '08

Is it possible to use Boost ptr_containers with Boost zip iterators? I switched from std::map to boost::ptr_map in my application and received numerous complaints from the Microsoft Visual Studio C++ 2008 compiler. As a small test I compiled \trunk\libs\iterator\test\zip_iterator_test.cpp from Boost SVN which worked fine. Then I added the necessary ptr_container include file, disabled a lot of extra tests and changed the definition of the two vectors from std::vector<double> vect1(3); to boost::ptr_vector<double> vect1(3); and std::vector<double> vect2(3); to boost::ptr_vector<double> vect2(3); Here is the error reported: c:\boost svn\trunk\boost\tuple\detail\tuple_basic.hpp(373) : error C2664: 'std::_Vector_const_iterator<_Ty,_Alloc>::_Vector_const_iterator(const std::_Vector_const_iterator<_Ty,_Alloc> &)' : cannot convert parameter 1 from 'const boost::void_ptr_iterator<VoidIter,T>' to 'const std::_Vector_const_iterator<_Ty,_Alloc> &' with [ _Ty=double, _Alloc=std::allocator<double> ] and [ VoidIter=std::_Vector_iterator<void *,std::allocator<void *>>, T=double ] and [ _Ty=double, _Alloc=std::allocator<double> ] Reason: cannot convert from 'const boost::void_ptr_iterator<VoidIter,T>' to 'const std::_Vector_const_iterator<_Ty,_Alloc>' with [ VoidIter=std::_Vector_iterator<void *,std::allocator<void *>>, T=double ] and [ _Ty=double, _Alloc=std::allocator<double> ] No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called c:\boost svn\trunk\boost\tuple\detail\tuple_basic.hpp(626) : see reference to function template instantiation 'boost::tuples::cons<HT,TT>::cons<T0,boost::tuples::cons<T0,boost::tuples::detail::map_tuple_to_cons<boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::type>>(const boost::tuples::cons<T0,boost::tuples::cons<T0,boost::tuples::detail::map_tuple_to_cons<boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::type>> &)' being compiled with [HT=std::_Vector_const_iterator<double,std::allocator<double>>,TT=boost::tuples::cons<std::_Vector_const_iterator<double,std::allocator<double>>,boost::tuples::detail::map_tuple_to_cons<boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::type>, T0=boost::void_ptr_iterator<std::_Vector_iterator<void *,std::allocator<void *>>,double> ] c:\documents and settings\chuck\my documents\visual studio 2005\projects\zip ptr container test\zip_ptr_container_test.cpp(267) : see reference to function template instantiation 'boost::tuples::tuple<T0,T1>::tuple<boost::void_ptr_iterator<VoidIter,T>,boost::tuples::cons<HT,TT>>(const boost::tuples::cons<HT,boost::tuples::cons<HT,TT>> &)' being compiled with [ T0=std::_Vector_const_iterator<double,std::allocator<double>>, T1=std::_Vector_const_iterator<double,std::allocator<double>>, VoidIter=std::_Vector_iterator<void *,std::allocator<void *>>, T=double, HT=boost::void_ptr_iterator<std::_Vector_iterator<void *,std::allocator<void *>>,double>, TT=boost::tuples::detail::map_tuple_to_cons<boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::type ] The line 267 (line 295 in the original version) referred to is: boost::zip_iterator< boost::tuples::tuple< std::vector<double>::const_iterator, std::vector<double>::const_iterator > > zip_it_begin( boost::make_tuple( vect1.begin(), vect2.begin() ) ); Is it the void pointer in the ptr_vector which causes the problem? Can this marriage be saved? -- Chuck

4 10

xpressive: set vs standard alternation compile problems
by Zachary 20 Feb '08

20 Feb '08

Hi, I'm a new user of xpresssive and I'd like to first give a big thank you for this wonderful tool. I'm having problems with the syntax for static regexes. The cheat sheet in the documentation says that |(set= 'a','b','c')| and |as_xpr('a') | 'b' |'c'| are equivalent yet the example sregex parentheses; parentheses = '(' >> *(keep(+~(boost::xpressive::set='(',')'))|by_ref(parentheses)) >> ')'; compiles while sregex parentheses; parentheses = '(' >> *(keep(+~(as_xpr('(')|')'))|by_ref(parentheses)) >> ')'; fails to do so (code and abbreviated errors attached). Additionally, combining the original lines into one construction, like so: sregex parentheses = '(' >> *(keep(+~(boost::xpressive::set='(',')'))|by_ref(parentheses)) >> ')'; compiles but running the code fails with: regnestest: /usr/include/boost/xpressive/detail/utility/tracking_ptr.hpp:457: const boost::shared_ptr<T>& boost::xpressive::detail::tracking_ptr<Type>::get_(bool) const [with Type = boost::xpressive::detail::regex_impl<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >]: Assertion `!this->has_deps_()' failed. and using as_xpr for the first term: sregex parentheses = as_xpr('(') >> *(keep(+~(boost::xpressive::set='(',')'))|by_ref(parentheses)) >> ')'; also compiles but causes a seg fault when run! All this is using g++ 4.2.3 and boost 1.34 as packaged with Debian testing. These seem like library errors to me, but like I said, I'm new to xpressive, and I'd be even happier to have my understanding improved. Zachary g++ -MMD regnestest.cpp -o regnestest /usr/include/boost/xpressive/detail/static/productions/complement_compiler.hpp: In instantiation of ‘boost::xpressive::detail::complement<boost::proto::binary_op<boost::proto::unary_op<boost::xpressive::detail::literal_placeholder<char, false>, boost::proto::noop_tag>, boost::proto::unary_op<char, boost::proto::noop_tag>, boost::proto::bitor_tag>, boost::xpressive::detail::xpression_visitor<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, mpl_::bool_<false>, boost::xpressive::cpp_regex_traits<char> > >’: /usr/include/boost/xpressive/detail/static/productions/complement_compiler.hpp:227: instantiated from ‘boost::xpressive::detail::complement_transform::apply<boost::proto::unary_op<boost::proto::binary_op<boost::proto::unary_op<boost::xpressive::detail::literal_placeholder<char, false>, boost::proto::noop_tag>, boost::proto::unary_op<char, boost::proto::noop_tag>, boost::proto::bitor_tag>, boost::proto::complement_tag>, boost::xpressive::detail::static_xpression<boost::xpressive::detail::true_matcher, boost::xpressive::detail::no_next>, boost::xpressive::detail::xpression_visitor<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, mpl_::bool_<false>, boost::xpressive::cpp_regex_traits<char> > >’ /usr/include/boost/xpressive/proto/compiler/transform.hpp:65: instantiated from ‘boost::proto::transform_compiler<boost::xpressive::detail::complement_transform, boost::xpressive::detail::seq_tag, void>::apply<boost::proto::unary_op<boost::proto::binary_op<boost::proto::unary_op<boost::xpressive::detail::literal_placeholder<char, false>, boost::proto::noop_tag>, boost::proto::unary_op<char, boost::proto::noop_tag>, boost::proto::bitor_tag>, boost::proto::complement_tag>, boost::xpressive::detail::static_xpression<boost::xpressive::detail::true_matcher, boost::xpressive::detail::no_next>, boost::xpressive::detail::xpression_visitor<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, mpl_::bool_<false>, boost::xpressive::cpp_regex_traits<char> > >’ /usr/include/boost/xpressive/proto/compiler/transform.hpp:74: instantiated from ‘boost::proto::transform_compiler<boost::proto::arg_transform, boost::xpressive::detail::seq_tag, void>::apply<boost::proto::unary_op<boost::proto::unary_op<boost::proto::binary_op<boost::proto::unary_op<boost::xpressive::detail::literal_placeholder<char, false>, boost::proto::noop_tag>, boost::proto::unary_op<char, boost::proto::noop_tag>, boost::proto::bitor_tag>, boost::proto::complement_tag>, boost::proto::unary_plus_tag>, boost::xpressive::detail::static_xpression<boost::xpressive::detail::true_matcher, boost::xpressive::detail::no_next>, boost::xpressive::detail::xpression_visitor<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, mpl_::bool_<false>, boost::xpressive::cpp_regex_traits<char> > >’ /usr/include/boost/xpressive/proto/compiler/branch.hpp:37: instantiated from ‘boost::proto::branch_compiler<boost::xpressive::detail::simple_repeat_branch<true, 1u, 4294967294u>, boost::xpressive::detail::ind_tag>::apply<boost::proto::unary_op<boost::proto::unary_op<boost::proto::binary_op<boost::proto::unary_op<boost::xpressive::detail::literal_placeholder<char, false>, boost::proto::noop_tag>, boost::proto::unary_op<char, boost::proto::noop_tag>, boost::proto::bitor_tag>, boost::proto::complement_tag>, boost::proto::unary_plus_tag>, boost::xpressive::detail::static_xpression<boost::xpressive::detail::true_matcher, boost::xpressive::detail::no_next>, boost::xpressive::detail::xpression_visitor<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, mpl_::bool_<false>, boost::xpressive::cpp_regex_traits<char> > >’ /usr/include/boost/xpressive/proto/compiler/conditional.hpp:40: instantiated from ‘boost::proto::conditional_compiler<boost::xpressive::detail::use_simple_repeat_predicate, boost::proto::branch_compiler<boost::xpressive::detail::simple_repeat_branch<true, 1u, 4294967294u>, boost::xpressive::detail::ind_tag>, boost::proto::transform_compiler<boost::proto::compose_transforms<boost::proto::arg_transform, boost::xpressive::detail::repeater_if_transform<true, 1u, 4294967294u> >, boost::xpressive::detail::seq_tag, void> >::apply<boost::proto::unary_op<boost::proto::unary_op<boost::proto::binary_op<boost::proto::unary_op<boost::xpressive::detail::literal_placeholder<char, false>, boost::proto::noop_tag>, boost::proto::unary_op<char, boost::proto::noop_tag>, boost::proto::bitor_tag>, boost::proto::complement_tag>, boost::proto::unary_plus_tag>, boost::xpressive::detail::static_xpression<boost::xpressive::detail::true_matcher, boost::xpressive::detail::no_next>, boost::xpressive::detail::xpression_visitor<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, mpl_::bool_<false>, boost::xpressive::cpp_regex_traits<char> > >’ --snipped for brevity-- regnestest.cpp:10: instantiated from here --subsequent errors omitted for brevity--

2 2

Trying to use the Math Toolkit
by Johan Råde 19 Feb '08

19 Feb '08

John, I have some trouble getting the Math Toolkit to work. I downloaded Boost 1.35, using CVS with the path -d:pserver:anonymous@boost.cvs.sourceforge.net:/cvsroot/boost, as described on the Boost home page. I selected the HEAD branch. This version did not include the Math Toolkit. (Did I download the right version?) So then I downloaded the Math Toolkit from the Vault, and combined the two source trees. I included the header boost/math/distributions/fisher_f.hpp in my code. I compiled the code with VC 7.1. I got the following error: ../Boost\boost\math\special_functions\log1p.hpp(195) : error C2785: 'tools::promote_args<T>::type boost::math::log1p(T)' and 'double boost::math::log1p(double)' have different return types ../Boost\boost\math\special_functions\math_fwd.hpp(246) : see declaration of 'boost::math::log1p' ../Boost\boost\math\special_functions\log1p.hpp(182) : see declaration of 'boost::math::log1p' ../Boost\boost\math\special_functions\log1p.hpp(195) : error C2912: explicit specialization; 'double boost::math::log1p<double>(double)' is not a specialization of a function template ../Boost\boost\math\special_functions\log1p.hpp(183) : fatal error C1903: unable to recover from previous error(s); stopping compilation Thank you, Johan

2 2

Template instantiation, function arguments and Boost.Preprocessor
by Hicham Mouline 19 Feb '08

19 Feb '08

hi, i have a template function, the arguments of which i wish to have depend on a non-type int template argument: template<int n> double f<n>( double arg0, double arg1, ..., double argn ) // ... is not the variadic notation for var number of args { // for(int i=0; i<n; i++) // code return sum; } int main() { return x = f<3>( 1.0, 2.0, 3.0 ); } BOOST_PP_REPEAT can't seem to do the job as the template argument n needs to be known at the preprocessing stage, which happens before the template instantiation stage ( this is part of compilation) PS: I did some perf tests comparing inline f(double a0, double a1, double a2) calls in an intensive loop, vs inline f(double a[3]) // degenrates to pointer with intel compiler and max optim, and the top version is faster... regards,

4 14

Boost.Python dynamic library requested by auto-linker?
by Robert Dailey 19 Feb '08

19 Feb '08

IDE: Visual Studio 9 (MSVC Compiler) Platform: Windows I have built the boost static libraries by calling the following command line at the boost trunk directory: *bjam --toolset=msvc link=static debug stage* This successfully builds all of the libboost_*.lib header files. However, when I build my application (that uses boost), it spits out the following linker error: *LINK : fatal error LNK1104: cannot open file 'boost_python-vc90-mt-gd-1_35.lib'* Note that I do not define BOOST_ALL_DYN_LINK or any other boost-related preprocessor directive. Any reason why boost is looking for a dynamic library for Boost.Python instead of the static one?

2 3

Re: [Boost-users] [pool] pool allocator: customizing and memory usage
by Lang Stefan 19 Feb '08

19 Feb '08

> There is a bug in pool that causes it to severely leak memory if > sizeof(T) is not aligned on bounds of at least sizeof(void*). This > could be the reason. > > -- > Cory Nelson Thanks Cory for your response. The leaks I observed were on lists with sizes of 16 and 24 bytes respectively. I doubt there is any alignment problem with these. The tests I am currently running use nodes of 12 bytes (list type is std::list<int> : two pointers plus one int per node) and I am experiencing similar problems: after constructing a list of 1000 nodes (12000 bytes needed) the amount of allocated storage is 48480 bytes! In response to my own questions, since I think I found the answers to some - this is what I found so far: Q: Why does pool<>::release_memory() not work for lists using fast_pool_allocator? A: Two reasons: First of all, release_memory() requires the free list (list of free chunks) to be ordered. This in turn requires the allocater being used to call the methods ordered_malloc() and ordered_free() respectively - fast_pool_allocator does not. Secondly, release_memory() can only be accessed via the singleton_pool underlying the implementation of fast_pool_allocator - which is hidden from the public interface. This means it should not be used! (Or that is my impression) It is probably possible to work around this problem by writing another allocator, or just by specializing the implementations of fast_pool_allocator<>::allocate() and fast_pool_allocator<>::deallocate() for the allocator types being used. However, this is likely to severely impact performance, and I'm not entirely sure this is a safe route to go. Q: Why does pool<>::purge_memory() cause run_time errors occasionally (when used on lists using fast_pool_allocator)? A: Some (or all?) implementations of std:list<> allocate one llist node to represent the list head. This node will be destructed once the list is explicitely destructed, or once a list constructed on the stack runs out of scope. This list head is stored within the same singleton_pool as it's nodes are. This means, even after removing all elements from a list, one node is still stored in the pool: the list's head. If pool<>::purge_memory() is called on this pool before the list itself is destructed, the destruction of the list will provoke a memory access error. As an aside, purge_memory() is available only over the pool interface and since the singleton_pool underlying fast_pool_allocator is hidden from the public interface, this function is not supposed to be used for fast_pool_allocator. In short: singleton_pool is probably not meant to support purge_memory, especially when you are using it for different types that might share the same pool instance. Releasing memory might make more sense, but is expensive because it requires ordered_malloc and ordered_free. Since singleton_pool might be shared by different types there's no way to guarantee the ordered allocation and deallocation routines will always be used, so release_memory() is probably not a good idea either! The only way to make releasing memory from singleton_pool feasible, is to provide a garbage collection function that does not require the free list to be ordered. A trivial solution would be O(n^2) - definitely not a good idea - but with a little more sophistication this could be achieved at O(n). (it will be considerably slower than ordered_release though) Looks like I'm out of luck here, unless I start writing my own pool_allocator... Cheers, Stefan

2 1

[spirit] Grammar/Action problems
by ope 19 Feb '08

19 Feb '08

Hi, my first parser and problems :-) Well, obviously I didn't understood the translation of BNF in spirit (probably BNF also); attached the code. The result is: $ g++ spirit.cpp -o spirit && ./spirit [Date] = "[Data Ver] 3.4 " ^-- error ("D") [Data Ver] = 0 "[File Name] foo.csv" ^-- error ("F") [File Name] = [Notes] = y Can anybody help? Further more I need to replace the comment symbol rule dynamically ("[Comment Char]") for the data self (not displayed here). Thanks, Olaf ---8<--- #include <boost/spirit/core.hpp> #include <boost/spirit/symbols/symbols.hpp> #include <boost/spirit/utility/chset.hpp> #include <boost/spirit/utility/escape_char.hpp> #include <boost/spirit/utility/confix.hpp> #include <boost/spirit/actor.hpp> #include <iostream> #include <iomanip> namespace sp = ::boost::spirit; struct data { std::pair<int, int> data_ver; // major,minor std::string comment_char; std::string file_name; std::string file_rev; std::string date; std::string notes; }; struct grammar : public sp::grammar<grammar> { explicit grammar( data& data ) : m_data( data ) { } template <typename ScannerT> struct definition { definition( const grammar& self ) { typedef sp::chset<char> chset_t; using sp::comment_p; using sp::int_p; using sp::anychar_p; using sp::blank_p; using sp::lexeme_d; using sp::as_lower_d; using sp::assign_a; using sp::strlit; data& data = self.m_data; chset_t COMMENT_SYMBOL_CHSET( "!\"#$%&'()*,:;<>?@\\^`{|}~" ); chset_t FILE_NAME_CHSET( "abcdefghijklmnopqrstuvwxyz0123456789_^$~!#%&-{})(@'`" ); std::pair<int, int> v( 0, 0 ); document = comment | data_ver | comment_char | file_name | file_rev | date | notes ; comment = comment_p('|') ; data_ver = ( lexeme_d[strlit<>("[Data Ver]")] >> int_p[assign_a(v.first)] >> '.' >> int_p[assign_a(v.second)] )[assign_a( data.data_ver, v )] ; comment_char = lexeme_d[strlit<>("[Comment Char]")] // FixMe: dynamic rule for comment !!! >> COMMENT_SYMBOL_CHSET[assign_a( data.comment_char )] >> "_char" ; file_name = ( lexeme_d[strlit<>("[File Name]")] >> ( +FILE_NAME_CHSET >> "." >> ( as_lower_d[".csv"] | as_lower_d[".txt"] ) ) )[assign_a( data.file_name )] ; file_rev = lexeme_d[strlit<>("[File Rev]")] >> ( // treated as string +anychar_p )[assign_a( data.file_rev )] ; date = "[Date]" >> ( // treated as string +anychar_p[assign_a( data.date )] ) ; notes = "[Notes]" >> ( // treated as string +anychar_p[assign_a( data.notes )] ) ; } sp::rule<ScannerT> const& start() const { return document; } sp::rule<ScannerT> document, comment, data_ver, comment_char, file_name, file_rev, date, notes ; }; private: data& m_data; }; template <typename GrammarT> static void parse(GrammarT const& grammar, std::string expr) { std::string::iterator first = expr.begin(); sp::parse_info<std::string::iterator> result = sp::parse(first, expr.end(), grammar); if ( !result.hit ) { std::cerr << "\"" << expr << "\"" << std::endl; std::cerr << std::setw(result.stop - expr.begin() + 1) << "^-- error (" << "\"" << *result.stop << "\")" << std::endl; } else if ( !result.full ) { first = result.stop; } } int main() { data d; grammar g( d ); parse( g, "[Date] 19.03.2008 | yeah " ); std::cout << "[Date] = " << d.date << std::endl; parse( g, "[Data Ver] 3.4 " ); std::cout << "[Data Ver] = " << d.data_ver.first << std::endl; parse( g, "[File Name] foo.csv" ); std::cout << "[File Name] = " << d.file_name << std::endl; parse( g, "[Notes] Use this section for any special notes related to the file." " This information is for modeling purposes only, and is not" " guaranteed. | May vary"); std::cout << "[Notes] = " << d.notes << std::endl; } --->8---

1 2

[pool] pool allocator: customizing and memory usage
by Lang Stefan 19 Feb '08

19 Feb '08

Hello all, I've been trying to integrate pool allocators for lists within our project, but early test runs turned up quite a surprising number of questions and problems. I've tried to resolve those issues by closely regarding the documentation, debugging, and - finally - checking this list for threads that potentially answer my questions, but unfortunately I found that on this list more questions were raised than answered. Specifically, I noticed that Stephen Cleary doesn't seem to frequent this list, or has stopped doing so some 5 or 6 years ago. Nevertheless maybe there are other people out there who can answer one or more of my questions, so here I go: 1. When using fast_pool_allocator for std::list<> I see no way to influence the blocksize being used for the next allocation. Since our application handles huge lists I cannot have fast_pool_allocator always simply double the next block's size ad infinitum! The pool class does offer methods to inquire and set the next_size property, but unfortunately, the singleton_pool underlying fast_pool_allocator is not accessible through the allocator interface! Is there a recommended way to set or limit next_size for pool allocators? I have found a workaround to achieve this (see below) but am not very comfortable doing it this way. 2. I am under the impression fast_pool_allocator heavily leaks memory! As far as I can tell, it works properly in the beginning, but uses up to 7 times the memory a std::list<T,std::allocator<T> of the same size uses! I am talking millions of list nodes and gigabytes of required memory here, when it should be only some 200 MB of used memory. I've ran a test to find out how much memory exactly was being allocated in comparison to the amount being requested by inserting into the list and found the factor to be exactly 7.0 . Can anyone confirm this observation? Is there a fix, or anything I can do to prevent it? 3. Also the release_memory method doesn't appear to work reliably, locking up huge amounts of memory even after the list using the pool ran out of scope! How can I force a singleton_pool to reliably release memory - short of stopping the application!? 4. The purge_memory method occasionally throws runtime errors, and when it does not it also doesn't appear to release any memory. It is possible this is due to inaccurate usage, but I really haven't delved into this, because release_memory() is what I actually need. Any specific things I need to do, any conditions I need to check, before a call to purge_memory? Workarounds: I defined my own allocators and then specialized the pool<>::malloc_need_resize() method to get more control and info on what was happening internally. So far all the problems I noticed (and more) have been confirmed. I am also quite sure I used all the pool and pool allocator interfaces properly (except maybe purge_memory, as noted above), and yes, I am aware that pool<> does allocate blocks in multiples of a size that is big enough to contain several instances of the object being managed (list nodes in this case). I have considered fixing one or more of the issues above by similarily defining my own pool<> method specializations, but I am very uncomfortable doing so since I don't fully understand the inner workings of the pool classes, and am not very experienced in metaprogramming. At this point I am about to give up. It is a shame however - I notice an increase of allocation/deallocation speed by a factor of 6-8, although in hindsight this might also be in part due to the fact release_memory simply doesn't work... Is there anyone out there using pool_allocator or fast_pool_allocator, and willing to share advice? Cheers, Stefan

2 1