- Boost - lists.boost.org

[Feedback] Towards a Better Boost.BloomFilter
by Alejandro Cabrera 30 Aug '11

30 Aug '11

Hello all, The GSoC coding period is over. However, I have every intent to continue to develop, improve, and maintain the Boost.BloomFilter package. Your feedback last time around was very useful, and made me think very carefully about the operations supported by each Bloom filter variant implemented. Thank you. Now, I could use feedback on at least the following aspects: - Are all the operations you need implemented by Boost.BloomFilter? Serialization support is still missing, though at least now it is possible to access the underlying storage for each structure implemented through the data() member function. - Are there are any particular variants you'd like to see implemented sooner? I've gathered together most Bloom filter literature on the bibliography page: http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/libs/bloom_filter… http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/libs/bloom_filter… (Note: twohash_ Bloom filters have been implemented.) - There is much talk of C++11 as of late on the mailing list: do you see anywhere in the implementation where taking advantage of C++11 features may produce a better Bloom filter package? - Regarding compiler support, this Bloom filter has been tested on several compiler suites (gcc-4.6, gcc-4.6 -std=c++0x, clang-2.9, clang-2.9-darwin), but has been primarily developed on Linux. Does the test suite compile and pass on your target compiler? My goal is to produce a review-ready Bloom filter library by the end of the year. Any feedback helps. Thank you for your time! A few links: - repository trunk: http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/ http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/ - documentation: http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/libs/bloom_filter… http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/libs/bloom_filter… Cheers, -Alejandro Cabrera -- View this message in context: http://boost.2283326.n4.nabble.com/Feedback-Towards-a-Better-Boost-BloomFil… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 6

miscompilation: boost.mpi, gcc 4.6 and c++0x
by Christophe Prud'homme 30 Aug '11

30 Aug '11

Dear Boost Developers I created the ticket [1] several month ago regarding an issue between g++-4.6 with option -std=c++0x and boost.mpi I haven't had any feedback yet. Any idea wether boost or gcc is at fault here ? it is easy to fix this by adding the right member function. 1. https://svn.boost.org/trac/boost/ticket/5538 let me recap what is going on consider the following code in t.cpp: #include <boost/mpi.hpp> compile it with g++ -std=c++0x -c -I/usr/include/mpi t.cpp and you get in Debian unstable In file included from /usr/include/c++/4.6/memory:67:0, from /usr/include/boost/mpi/allocator.hpp:18, from /usr/include/boost/mpi.hpp:22, from t.cpp:1: /usr/include/c++/4.6/bits/stl_uninitialized.h: In function 'void std::__uninitialized_default_n_a(_ForwardIterator, _Size, _Allocator&) [with _ForwardIterator = char*, _Size = long unsigned int, _Allocator = boost::mpi::allocator<char>]': /usr/include/c++/4.6/bits/vector.tcc:474:8: instantiated from 'void std::vector<_Tp, _Alloc>::_M_default_append(std::vector<_Tp, _Alloc>::size_type) [with _Tp = char, _Alloc = boost::mpi::allocator<char>, std::vector<_Tp, _Alloc>::size_type = long unsigned int]' /usr/include/c++/4.6/bits/stl_vector.h:592:4: instantiated from 'void std::vector<_Tp, _Alloc>::resize(std::vector<_Tp, _Alloc>::size_type) [with _Tp = char, _Alloc = boost::mpi::allocator<char>, std::vector<_Tp, _Alloc>::size_type = long unsigned int]' /usr/include/boost/mpi/detail/packed_oprimitive.hpp:96:46: instantiated from here /usr/include/c++/4.6/bits/stl_uninitialized.h:576:6: error: no matching function for call to 'boost::mpi::allocator<char>::construct(char*)' /usr/include/c++/4.6/bits/stl_uninitialized.h:576:6: note: candidate is: /usr/include/boost/mpi/allocator.hpp:168:8: note: void boost::mpi::allocator<T>::construct(boost::mpi::allocator<T>::pointer, const T&) [with T = char, boost::mpi::allocator<T>::pointer = char*] /usr/include/boost/mpi/allocator.hpp:168:8: note: candidate expects 2 arguments, 1 provided note that if you remove -std=c++0x, it compiles fine. Best regards C. -- Debian Developer - member of Debian Science http://wiki.debian.org/DebianScience Prof. at Univ. Grenoble in Applied Math. http://ljk.imag.fr/membres/Christophe.Prudhomme/

2 1

[C++0x] ISO/IEC approves C++0x standard!
by Beman Dawes 30 Aug '11

30 Aug '11

The C++0x standard has been approved by ISO/IEC. The vote was unanimous; all 21 National Bodies voting were in favor. That means the dozen or so Boost libraries that were in TR1 are now part of the standard itself. Good work, Boosters! --Beman

10 12

BOOST_STRONG_TYPEDEF conflicting defs in 1.47
by Michael Goldshteyn 30 Aug '11

30 Aug '11

There seem to be conflicting definitions for the BOOST_STRONG_TYPEDEF macro: 11>e:\dev\devel\libs\boost\boost_1_47_0\boost\strong_typedef.hpp(45) : warning C4005: 'BOOST_STRONG_TYPEDEF' : macro redefinition 11> e:\dev\devel\libs\boost\boost_1_47_0\boost\serialization\strong_typedef.hpp(45) : see previous definition of 'BOOST_STRONG_TYPEDEF' They are slight different, but function identically (i.e., the one in serialization has an explicit default constructor call on the member variable t). Are both of these necessary, or should serialization just use the default one from the boost directory? Thanks, Michael Goldshteyn

2 2

[conversion] conversion domains
by Gordon Woodhull 30 Aug '11

30 Aug '11

Hi Vicente, all, I've been thinking a bit about Conversion's ODR problems and the annoyance of headers that customize something globally (using e.g. template specialization) when they are included. I think I would prefer a design that allowed to define sets of conversions, or conversion domains. When creating a converter, you would specify the list of conversions which you want. That way a conversion domain is specified in one place, and not because you #include something. Of course it also means there's no default domain, for better or worse. I tried a number of approaches but only found one way that would work. This uses function overloading over an inheritance chain of converter classes, each of which brings its parent's convert() function(s) into scope with 'using'. Yes, it is requires ugly, specific code to define a converter (and mpl::quoting the converters when specifying the domain yuk), and I wonder if anyone could find a better way to do this. (I would prefer if it were possible to use partial specialization of template classes, but I guess there is no way to combine specializations of a nested template using inheritance, and it invokes a weird bug in gcc [1] if you try to do so.) Vicente, have you considered similar approaches? Cheers, Gordon [1] http://stackoverflow.com/questions/1413158/partial-specialization-of-a-clas… This cites a claim that the bug was fixed in 4.5.0 but I am still seeing it in 4.5.3 - have not tried more recent. #include <iostream> #include <string> #include <boost/mpl/vector.hpp> #include <boost/mpl/fold.hpp> #include <boost/mpl/apply_wrap.hpp> #include <boost/lexical_cast.hpp> #include <boost/utility.hpp> #include <boost/numeric/conversion/cast.hpp> #include <boost/icl/type_traits/is_numeric.hpp> namespace mpl = boost::mpl; template<typename T> struct wrap {}; struct converter_start { struct dummy; dummy convert(dummy, wrap<dummy>); }; template<typename Tail> struct x2string : Tail { using Tail::convert; template<typename Source> std::string convert(Source const& x, wrap<std::basic_string<char> >) { return boost::lexical_cast<std::string>(x); } }; template<typename Tail> struct string2x : Tail { using Tail::convert; template<typename Target> Target convert(std::string const& s, wrap<Target>) { return boost::lexical_cast<Target>(s); } }; template<typename Tail> struct numeric : Tail { using Tail::convert; template<typename Target, typename Source> typename boost::enable_if_c<boost::icl::is_numeric<Target>::value && boost::icl::is_numeric<Source>::value, Target> ::type convert(Source const& x, wrap<Target>) { return boost::numeric_cast<Target>(x); } }; typedef mpl::vector<mpl::quote1<string2x>, mpl::quote1<x2string>, mpl::quote1<numeric> > my_conversions; struct my_converter : mpl::fold<my_conversions, converter_start, mpl::apply_wrap1<mpl::_2, mpl::_1> >::type { template<typename Target, typename Source> Target cast(Source const& source) { return convert(source, wrap<Target>()); } }; int main() { my_converter cvt; std::cout << cvt.cast<std::string>(1.7) << " " << cvt.cast<int>(std::string("17")) << std::endl; std::cout << cvt.cast<int>(1.7) << " " << cvt.cast<float>(17)/10.f << std::endl; return 0; }

2 2

The Lonely Song of the MPL Maintainer -- or Boost support for antediluvian compiler and the future supprot of C++11
by Joel falcou 30 Aug '11

30 Aug '11

This is meant to be a serious thread and not some trollfest about w/e compilers. I am currently fixing bugs and applying feature request in MPL and it just happens I spend more time deciphering the web of compatibility #ifdefs than doing actual code. A rough guestimate tells me that on a 100 lines MPL files, 80 of them are #ifdef for compatibility. It could fine and dandy if those #ifdefs where not, for a majority, targeted at compiler i didnt even knew hwere standard conformant (ICC 5, really) or still in serious use (Borland whatever). Some other are more debatable (like MSVC 6 or such). Considering such compilers are so broken that upgrading boost is out of question for these users and that C++11 and its new set of supporting compilers are around the corner, also taking into account my limited amount of sanity (IRC people can testify on this), can't we start some support clean up in this library ? <radical> Going further, shouldn't we start thinking at boost 2.0 which will definitevely let c++03 die its peaceful death and start, on a voluntary effort, move boost component toward C++11. I know we have a fully working Fusion for 0x only. mpl, proto and other strategic infrastructure libraries should benefit from that. Some are a trivial port like Boost.PP and all the TR1 boost library that will just either disappear or forward the C++11 version. </radical> Here is the status of the thingy. Letting Boost 2.0 aside, what should be the status of MPL and its sharazadian list of supported compiler ?

23 41

problems with grammar using spirit
by McJaml 30 Aug '11

30 Aug '11

Hi! I'm new using spirit and I'm having trouble with the parser. I already make this scanner and parser using CocoR but I have had no succes with spirit. Patito2011 is the main grammar but when I read the input file it doen't follows this grammar it goes directly to the Vars grammar. I don't know what is wrong help is appreciated. Patito2011 = tok.plan >> tok.id >> ';' >> -Vars >> Parvada >> tok.end_; Thanks in advance. Heres the code ************************************************ #include <boost/config/warning_disable.hpp> #include <boost/spirit/include/qi.hpp> #include <boost/spirit/include/lex_lexertl.hpp> #include <iostream> #include <fstream> #include <string> using namespace boost::spirit; using boost::phoenix::val; inline std::string read_from_file( const char* infile ) { std::ifstream instream( infile ); if( !instream.is_open() ) { std::cerr << "Could not open file: \"" << infile << "\"" << std::endl; exit( -1 ); } instream.unsetf( std::ios::skipws ); return( std::string( std::istreambuf_iterator< char >( instream.rdbuf() ), std::istreambuf_iterator< char >() ) ); } template<typename Lexer> struct LangLexer : lex::lexer<Lexer> { LangLexer() { id = "[a-zA-Z_][a-zA-Z0-9_]*"; cte_i = "[0-9]+"; cte_f = "([0-9]+)|([0-9]*\\.[0-9]+)"; cte_string = "\".\""; si = "if"; sino = "else"; plan = "plan"; end_ = "end"; junta = "junta"; quack = "quack"; variable = "variable"; int_ = "int"; float_ = "float"; notEqual = "<>"; this->self = lex::token_def<>('(') | ')' | '=' | ';' | '[' | ']' | ',' | '+' | '-' | '<' | '>' ; this->self += plan | si | sino | end_ | junta | quack | variable | int_ | float_ | notEqual; this->self += id | cte_i | cte_string | cte_f; this->self("WS") = lex::token_def<>("[ \\t\\n]+") | "\\/\\*[^*]*\\*+([^/*][^*]*\\*+)*\\/" ; } lex::token_def<> si, sino, plan, end_, junta, quack, variable, int_, float_, notEqual; lex::token_def<std::string> id, cte_string; lex::token_def<unsigned int> cte_i; lex::token_def<float> cte_f; }; template< typename Iterator, typename Lexer > struct LangGrammar : qi::grammar< Iterator, qi::in_state_skipper<Lexer> > { template< typename TokenDef > LangGrammar(TokenDef const& tok ) : LangGrammar::base_type(Patito2011) { Vars = tok.variable >> B >> C >> *( B >> C ); B = tok.id >> *(',' >> tok.id); C = ':' >> Tipo >> ';'; Tipo = tok.int_ | tok.float_; Parvada = '[' >> *Estatuto >> ']'; Estatuto = Copiar | Preguntar | Graznido | Juntar; Copiar = tok.id >> '=' >> Expresion >> ';'; Graznido = tok.quack >> '(' >> (Expresion | tok.cte_string) >> *(',' >> (Expresion | tok.cte_string)) >> ')'; Expresion = Exp >> -(('>' >> Exp) | ('<' >> Exp) | (tok.notEqual >> Exp)); Exp = Termino >> -(('+' >> Exp) | ('-' >> Exp)); Termino = Factor >> -(('*' >> Termino) | ('/' >> Termino)); Var_cte = tok.id | tok.cte_i | tok.cte_f; Factor = ('(' >> Expresion >> ')') | Var_cte | ('+' >> Var_cte | '-' >> Var_cte ); Preguntar = tok.si >> '(' >> Expresion >> Parvada >> -(tok.sino >> Parvada) >> ';'; Juntar = tok.junta >> '(' >> D >> ',' >> D >> ';'; D = Var_cte | tok.cte_string; Patito2011 = tok.plan >> tok.id >> ';' >> -Vars >> Parvada >> tok.end_; Patito2011.name("patito"); Vars.name("vars"); B.name("B"); C.name("C"); D.name("D"); Parvada.name("parvada"); Termino.name("termino"); Factor.name("factor"); Estatuto.name("est"); Copiar.name("copiar"); Graznido.name("graznido"); Juntar.name("juntar"); Preguntar.name("preguntar"); Expresion.name("expresion"); Exp.name("exp"); Var_cte.name("varcte"); Tipo.name("tipo"); debug(Patito2011); debug(Vars); debug(B); debug(C); debug(Tipo); debug(D); debug(Parvada); debug(Juntar); debug(Copiar); debug(Graznido); debug(Expresion); debug(Exp); debug(Preguntar); debug(Estatuto); debug(Var_cte); debug(Factor); debug(Termino); } qi::rule<Iterator, qi::in_state_skipper<Lexer> > Vars, B, C, Tipo, Parvada, Preguntar, Estatuto, Copiar, Expresion, Var_cte, Exp, Termino, Factor, Graznido, Juntar, D, Patito2011;; }; int main( int argc, char** argv ) { typedef std::string::iterator base_iterator_type; typedef lex::lexertl::token< base_iterator_type, boost::mpl::vector<float, unsigned int, std::string> > token_type; typedef lex::lexertl::lexer<token_type> lexer_type; typedef LangLexer<lexer_type> LangLexer; typedef LangLexer::iterator_type iterator_type; typedef LangGrammar<iterator_type, LangLexer::lexer_def> LangGrammar; LangLexer lexer; LangGrammar grammar(lexer); std::string str(read_from_file(argv[1])); base_iterator_type strBegin = str.begin(); iterator_type tokenItor = lexer.begin(strBegin, str.end()); iterator_type tokenItorEnd = lexer.end(); bool result = qi::phrase_parse( tokenItor, tokenItorEnd, grammar, qi::in_state("WS")[ lexer.self ] ); if( result ) { std::cout << "Parsing successful" << std::endl; } else { std::cout << "Parsing error" << std::endl; } return( 0 ); } ***************************** and here is a sample input file plan adsadsad; variable x,y,z : int; t,a,b,c : float; [ si ( 2 > 1) [ junta("string", "hola"; x = 1; t = 1.23; y = (1 - 2) < (1 + 3); y = (1 - 2) <> (1 + 3); y = (1 - 2) > (1 + 3); quack("quack", 1); quack("quack", "hola"); quack("quack", (1 + 2)); ] sino http://boost.2283326.n4.nabble.com/file/n3775416/patito.txt patito.txt http://boost.2283326.n4.nabble.com/file/n3775416/LexerParser.cpp LexerParser.cpp [ junta("string", "hola"; x = 1; t = 1.23; y = (1 - 2) < (1 * 3); y = (1 - 2) <> (1 / 3); y = (1 - 2) > (1 + 3); quack("quack", 1); quack("quack", "hola"); quack("quack", (1 + 2)); ]; ] end ************************************************** -- View this message in context: http://boost.2283326.n4.nabble.com/problems-with-grammar-using-spirit-tp377… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 3

[bcp] Typo in doc/bcp.qbk
by Brian Ravnsgaard Riis 29 Aug '11

29 Aug '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [article BCP [quickbook 1.4] [copyright 2209 John Maddock] ^^^^ Surely not! :-) /Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOWW/IAAoJEKd8gmwzkHPJwNoH/itm6+DnafcZGRoiz+jZleon QJ7S8oSYc59ljr2xsYm5c/S+2v/GWHT81NmMdSM9inwLJ+C3SZNQTouMTKJ1mUqg M9MqPbmL5GtGnWc8ZPDvu3J1eEm8KjX1jiSQHrUrxvTrW8cNQbDswrhJWL6elSCz 2TWcI++JQVgck8gnbQ8UE+shdHqiHFWq5Y8mNn6pdsTO8ULxZFX1gHDsAgyK8N+a tDtdvnq6U6vJWsEVNcrQgl//0nuLFtIepwb/ajahTtY/3uMhzEvUKq1EP0k+ag4U ZTm0byKBhNWJD2p8cHONbnZe3oidvM7En2Qm6g6Iwv85PzxHNbBtdbt6vFOQ9eo= =RyJL -----END PGP SIGNATURE-----

2 1

[Containers Review Result] Boost.Containers is accepted into Boost.
by John Maddock 29 Aug '11

29 Aug '11

This is to announce that the Containers library by Ion Gaztanaga has been accepted into Boost. There were 11 positive reviews and one negative, many making the same points (see summary below). Acceptance is therefore conditional on Ion improving the documentation as the reviewers requested. Review comments summary: ~~~~~~~~~~~~~~~~~~~~~~~~ * Needs a better introduction/overview/tutorial in the docs: # what are stateful allocators, what's currently supported in this area, how is it supported, does it have performance implications. # Needs overview of the new containers - stable_vector, flat_* etc. # Needs description of recursive containers and why this library supports them but not C++03 containers. # Needs to justify why this library and not the std one (probably by mention of the above). * Make clear in the docs (if not already) what the default allocator is. * Make allocator template parameter name consistent. * Add basic_string::shrink_to_fit member function (from C++11). * Typo in range insertion docs (first/last vs i/j) * vector<bool> behavior needs to be documented (and justified either which way). * Need to document conformance to C++0x container requirements, plus use (or not) of new C++0x features such as std::allocator_traits. * Missing documentation for some deque member functions. * Missing Returns/Effects,Complexity or Throws. (ex: after No.23 in basic_string) * The "Acknowledgements" page is currently empty. There are various (c) notices in the source referring to sources from which parts of the code may have come. This page should clarify these sources, including any cases where the original code has now all been replaced, and assert that the licenses are all in order. It should also point out the history of the code in Boost, i.e. that parts were previously in Boost.Interprocess, so that anyone with previous exposure to the Interprocess containers is not confused. * There are some comments that the organisation of the docs makes it unnecessarily hard to jump directly to the info you want. Requests for additional features: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Consider implementing std::forward_list from C++0x. * Consider Boost.Range interoperability and/or range insert support. * Make the flat_* containers container adapters - so that a) the user can choose the underlying implementation and b) they can shoot themselves in the foot if they want to by manipulating the underlying container (mostly for efficient loading of data). Alternatively, provide some other interface enhancements to try to meet most of the use cases given. * Efficient construction of ordered containers from already sorted data. * Investigate Clang's Libc++ std lib performance tests. John Maddock Containers review manager. PS: Ion: if you need any help with quickbook/docbook and AutoIndex ping me and I'll see what I can do to help - there are all sorts of parameters that can be used to tweak the appearance etc.

4 6

[move] Fix for clang.
by Daniel James 29 Aug '11

29 Aug '11

Hi Ion, Clang pretends to be gcc 4.2, but in c++0x mode has the correct c++0x rvalue reference rules introduced in gcc 4.5, so move is incorrectly configured. The attached patch fixes that. Only tested with llvm clang 2.9.. Daniel

2 1