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

[Property Tree] Compilation issue with Boost 1.37.0 Beta 1 issue
by Johan Råde 23 Nov '08

23 Nov '08

The property tree version in the trunk works with Boost 1.36 but not with 1.37 Beta 1. When I compile the following code istream is; ptree pt; read_xml(is, pt); with MSVS 9.0 I get the following error: 3>C:\Boost\include\boost-1_37\boost/iterator/iterator_adaptor.hpp(230) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' 3> with 3> [ 3> x=false 3> ] 3> C:\Boost\include\boost-1_37\boost/iterator/iterator_adaptor.hpp(335) : see reference to function template instantiation 'void boost::detail::iterator_adaptor_assert_traversal<boost::forward_traversal_tag,boost::random_access_traversal_tag>(void)' being compiled 3> C:\Boost\include\boost-1_37\boost/iterator/iterator_adaptor.hpp(334) : while compiling class template member function 'void boost::iterator_adaptor<Derived,Base,Value,Traversal>::advance(__w64 int)' 3> with 3> [ 3> Derived=boost::spirit::position_iterator<std::_Vector_const_iterator<Ch,std::allocator<char>>>, 3> Base=std::_Vector_const_iterator<Ch,std::allocator<char>>, 3> Value=const char, 3> Traversal=boost::forward_traversal_tag 3> ] 3> C:\Boost\include\boost-1_37\boost/spirit/home/classic/iterator/position_iterator.hpp(156) : see reference to class template instantiation 'boost::iterator_adaptor<Derived,Base,Value,Traversal>' being compiled 3> with 3> [ 3> Derived=boost::spirit::position_iterator<std::_Vector_const_iterator<Ch,std::allocator<char>>>, 3> Base=std::_Vector_const_iterator<Ch,std::allocator<char>>, 3> Value=const char, 3> Traversal=boost::forward_traversal_tag 3> ] 3> C:\Program Files\Boost\Unofficial\boost/property_tree/detail/xml_parser_read_spirit.hpp(709) : see reference to class template instantiation 'boost::spirit::position_iterator<ForwardIteratorT>' being compiled 3> with 3> [ 3> ForwardIteratorT=std::_Vector_const_iterator<Ch,std::allocator<char>> 3> ] 3> C:\Program Files\Boost\Unofficial\boost/property_tree/xml_parser.hpp(45) : see reference to function template instantiation 'void boost::property_tree::xml_parser::read_xml_internal<Ptree>(std::basic_istream<_Elem,_Traits> &,Ptree &,int,const std::string &)' being compiled 3> with 3> [ 3> Ptree=boost::property_tree::ptree, 3> _Elem=char, 3> _Traits=std::char_traits<char> 3> ] 3> .\GeneAuxParser.cpp(33) : see reference to function template instantiation 'void boost::property_tree::xml_parser::read_xml<boost::property_tree::ptree>(std::basic_istream<_Elem,_Traits> &,Ptree &,int)' being compiled 3> with 3> [ 3> _Elem=char, 3> _Traits=std::char_traits<char>, 3> Ptree=boost::property_tree::ptree 3> ] --Johan Råde

2 3

Random: Using random generators with runtime parameters
by Hans Mull 23 Nov '08

23 Nov '08

Hi! How can I use random generators with multiple parameters such as linear_congruential with parameters that are only known at runtime? Thanks in advance, Hans

3 4

[test] new g++ compilation warnings on trunk
by Robert Mecklenburg 21 Nov '08

21 Nov '08

Compiling against the boost trunk I'm getting hundreds of these: g++ -Wall -Wextra -Wno-missing-braces -g -ftrapv -DBOOST_1_36_0 -Iboost-1_37 -MMD -MP -DUSE_TRAPV -c -o src/test/BlobTest.o src/test/BlobTest.cpp boost/test/floating_point_comparison.hpp:224: warning: 'boost::test_tools::<unnamed>::check_is_close' defined but not used boost/test/floating_point_comparison.hpp:246: warning: 'boost::test_tools::<unnamed>::check_is_small' defined but not used Any chance we can fix this? If you need a tester for g++ 4.2.3, I can do it. Thanks, -- Robert

5 5

[spirit2] Trivial parser crashes
by sm4 18 Nov '08

18 Nov '08

Hello, Playing with spirit-2 (boost 1.36 release) I got the following code to ASSERT when compiled on Visual Studio 2008/SP1. Any ideas what's wrong? ---------------------------------------------------------- #include #include #include #include #include #include #include #include #include using namespace boost::spirit; using namespace boost::spirit::qi; using namespace boost::spirit::ascii; using namespace boost::spirit::arg_names; namespace phoenix = boost::phoenix; using phoenix::at_c; struct key_val { std::string key; std::string value; }; BOOST_FUSION_ADAPT_STRUCT( key_val, (std::string, key) (std::string, value) ) template struct my_grammar : grammar { my_grammar() : my_grammar::base_type(start) { quoted_string %= lexeme['"' >> +(char_ - '"') >> '"']; key %= quoted_string; value %= quoted_string; start = key [at_c<0>(_val) = _1] >> ':' >> value [at_c<1>(_val) = _1] ; } rule key; rule quoted_string; rule value; rule start; }; int main() { typedef std::string::const_iterator citerator; std::string str = "\"x\": \"25\" "; citerator iter = str.begin(); citerator end = str.end(); my_grammar my_parser; key_val kv; phrase_parse(iter, end, my_parser, kv, space); // ASSERTs return 0; } -------------------------------------------------------------------------- thanks -- View this message in context: http://www.nabble.com/-spirit2--Trivial-parser-crashes-tp19624910p19624910.… Sent from the Boost - Users mailing list archive at Nabble.com.

5 9

[Proto] Strange behavior with semantic action and custom tag function
by Joel Falcou 16 Nov '08

16 Nov '08

I'm stuck on some problem that may en dup silly. I have a DSL defined by the following grammar : struct dimen_grammar : bp::or_< ////////////////////////////////////////////////////////////////////////// // Terminals are dimensional values or integral values ////////////////////////////////////////////////////////////////////////// bp::or_< bp::terminal< dimensions<bp::_,bp::_> > , integer_grammar > ////////////////////////////////////////////////////////////////////////// // dimen can be added together or scaled by an integer // or shifted left or right by an integer ////////////////////////////////////////////////////////////////////////// ,bp::or_< bp::plus<dimen_grammar,dimen_grammar> ,bp::multiplies<dimen_grammar,integer_grammar> ,bp::multiplies<integer_grammar,dimen_grammar> ,bp::shift_left<dimen_grammar,integer_grammar> ,bp::shift_right<dimen_grammar,integer_grammar> > > {}; I've defined a proper callable_context that take care of my special terminals and built a terminal class. At this point, everythign works perfect : i can build expressions and evaluate them. Now I add a grammar with semantic action that helps me computes an aspect of those expression : struct dimen_size : bp::or_< ////////////////////////////////////////////////////////////////////////// // dimensionnal values terminal contains its own size value ////////////////////////////////////////////////////////////////////////// bp::when< bp::terminal< dimensions<bp::_,bp::_> > , dimension_of< bp::_value>() > ////////////////////////////////////////////////////////////////////////// // integral values has a size of 1 ////////////////////////////////////////////////////////////////////////// , bp::when<integer_grammar, bm::size_t<1>()> ////////////////////////////////////////////////////////////////////////// // size(d1+d2) = max(size(d1),size(d2)) ////////////////////////////////////////////////////////////////////////// , bp::when< bp::plus<dimen_grammar,dimen_grammar> , bm::max<dimen_size(bp::_left),dimen_size(bp::_right)>() > ////////////////////////////////////////////////////////////////////////// // size(d1*i) = size(d1) ////////////////////////////////////////////////////////////////////////// , bp::when< bp::multiplies<dimen_grammar,integer_grammar> , dimen_size(bp::_left) > ////////////////////////////////////////////////////////////////////////// // size(i*d2) = size(d2) ////////////////////////////////////////////////////////////////////////// , bp::when< bp::multiplies<integer_grammar,dimen_grammar> , dimen_size(bp::_right) > ////////////////////////////////////////////////////////////////////////// // size(d1<<i) = size(d1) ////////////////////////////////////////////////////////////////////////// , bp::when< bp::shift_left<dimen_grammar,integer_grammar> , dimen_size(bp::_left) > ////////////////////////////////////////////////////////////////////////// // size(d1>>i) = size(d1) ////////////////////////////////////////////////////////////////////////// , bp::when< bp::shift_right<dimen_grammar,integer_grammar> , dimen_size(bp::_left) > ////////////////////////////////////////////////////////////////////////// // Other returns 0 ////////////////////////////////////////////////////////////////////////// , bp::when<bp::_, bm::size_t<0>()> > {}; This works. If I remove the bp::when<bp::_, bm::size_t<0>()>, it fails to compile when I try to use a hand-overloaded operator<< for displaying expression values on standard output. So, is there anything I missed (like deactivating operator<< in the grammar somehow ?) ? Other question : When defining custom tag to build new function, why does the make_expr tempalte doesn't do check on its argument to see if it's match the grammar of the domain it's bound to use ? Seems I'm forced to add additional layer of SFINAE to prevent those function to get called on w/e types. Thanks in advance for help -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

2 6

library name for boost 1.36
by Alain Leblanc 16 Nov '08

16 Nov '08

Hi, I just built boost 1.36 for the mac and all the library names have xgcc40 inserted in the middle, such as libboost_iostreams-xgcc40-mt-1_36.dylib. It breaks my makefiles that contain the option " -lboost_iostreams". Is there a reason for the xgcc40 in this version and not the others, and is there a way to instruct bjam not to include it in the filename. Thank, s

4 5

[boost-users][bind, signal] binding a weak_ptr?
by Igor R 12 Nov '08

12 Nov '08

Hello, When using shared_ptr, we usually take an advantage of weak_ptr to break the "cycles". But sometimes the "forth connection" between the objects is by means of shared_ptr, while the "back connection" is by means of signal-slot connection. Like this: shared_ptr<Class1> o1; shared_ptr<Class2> o2; o1->someSignal_->connect(bind(&Class2::responder, o2)); // besides, o2 has a shared_ptr to o1 I'd like this signal-slot to be "weak", i.e. instead of "bind(&Class2::responder, o2)" I wish it could be "bind(&Class2::responder, weak_ptr(o2))" - which is illegal. Of course, I can define (and connect to the signal) a wrapping functor that would store a weak_ptr to the wrapped object, and would try to lock it in operator(). But probably boost already have some off-the-shelf solution for this issue? Thanks!

3 6

ICC and _syn_lock bug again
by Joel Falcou 11 Nov '08

11 Nov '08

As shown here : http://lists.boost.org/Archives/boost/2008/06/138322.php There *was* a bug with intel Compiler and shared_ptr using the __sync_lock intrinsic. It has been fixed on ICC 9.x but today I tried to sue this with latest ICC 10.1.018 on ubuntu linux and got the very same error than in the original topic. Is there something I miss ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

2 4

Boost::Serialize, serializing std::basic_string
by Jacob Holm 06 Nov '08

06 Nov '08

I have a variable which is a basic_string, as I want my own allocator assigned to it. This gives me the following compiler error: "Error 3 error C2039: 'serialize' : is not a member of 'std::basic_string<_Elem,_Traits,_Ax>' ...\boost\serialization\access.hpp 109" I have searched around for this error but have not been able to find a solution. It would be possible to just pass a vector with chars in it, but basic_string is preferred. Has anyone else had this problem and maybe managed to solve it? /Jacob Holm

2 7

Looking for news about boost.process
by Germain BARRET 05 Nov '08

05 Nov '08

I've found this wonderfull branch of Boost (Boost :: process) : http://www.netbsd.org/~jmmv/process/index.html But I don't find it in 1.35 or in 1.36, what is it begun ??? Has it be renamed ? Has it be removed ? Why ? When will it be integrated ? Thanks

4 6