- Boost-users - lists.boost.org

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

[BGL] Access bundle graph properties
by Ioannis Nousias 19 Feb '08

19 Feb '08

How does one access a bundle graph property in adjacency_list ? for example struct VertexProperties { int index; bool status; }; struct EdgeProperties { int index; bool status; }; struct GraphProperties { int something; }; boost::adjacency_list < boost::listS, boost::vecS, boost::directedS, VertexProperties, EdgeProperties, GraphProperties > graph; if 'v' is a vertex then I can do 'grap[v].status' to get that vertex property. But what about the graph properties? I've tried 'graph.something' but that didn't work :( Any suggestions ? regards, Ioannis

4 4

[program option] Unicode support
by Hector C 19 Feb '08

19 Feb '08

Hi fellow boost fans, I cannot find the appropriate class to produce Unicode messages in boost::program_options::options_description. I'm looking for something like: woptions_description(const std::wstring &, unsigned = m_default_line_length); Any pointers? (no pun intended) Is there a library similar to boost::program_options with full Unicode support? Cheers, ++Hector C.

3 3

boost vs libboost naming problem with bjam compile for vc90
by Phelps Williams 19 Feb '08

19 Feb '08

I am a first time boost user and I am interested in playing with some of the regex features. I am forced to compile boost from svn because I'm using ms visual c++ 9.0. I looked into this process and it appears that no modifications are necessary for a successful compilation. With bjam.exe in the boost root directory I execute the following command to compile: bjam.exe -toolset=msvc debug stage The compilation completes without any errors and all expected lib and dlls are present in $BOOST_ROOT\stage\lib as expected. I then setup a simple regex project to test things out: #include "stdafx.h" #include <boost/regex.hpp> #include <iostream> #include <string> int main() { std::string line; boost::regex pat( "^Subject: (Re: |Aw: )*(.*)" ); while (std::cin) { std::getline(std::cin, line); boost::smatch matches; if (boost::regex_match(line, matches, pat)) std::cout << matches[2] << std::endl; } } Additionally, I have configured my boost root directory as an Additional Include Directory under Properties -> C/C++ -> General I have also configured my compiled libraries under (Properties -> Linker -> General) Additional Library Directories to the location where the compiled libs were placed. $BOOST_ROOT\stage\lib During compilation of this project I receive link errors: LINK : fatal error LNK1104: cannot open file 'libboost_regex-vc90-mt-gd-1 _35.lib' The confusing part is in the stage\lib directory all the libs are titled in the following format "boost_libname_vc90-mt-gd.lib" or ".dll" For some reason the libraries are missing the *lib* in front of the name...for example "libboost_regex-vc90-mt-gd-1_35.lib" I tried to rename this boost_regex example to libboost_regex but I ran into runtime exceptions. Specifically that "boost_regex-vc90-mt-gd-1_35.dll" was not found. I then copied this dll into the Debug folder where the compiled exe is being executed from and everything executed properly. Why are the static libraries not named properly? Thanks -Phelps

4 4