- Boost-users - lists.boost.org

Meeting C++ - Full Program + Early Bird
by Jens Weller 08 Aug '12

08 Aug '12

Hi C++ & boost Community, just a short note to those who are interested in C++ conferences: The Schedule of Meeting C++ is online: http://meetingcpp.com/index.php/schedule.html The Keynote "Good C++11 Coding Style" is held by Michael Wong, the focus is on C++11 and boost. Early Bird Tickets are still available for one week until next wednesday! regards, Jens Weller

1 0

[boost.serialization] shared object plugin
by Giampiero Gabbiani 08 Aug '12

08 Aug '12

Hi together, inside the application I'm writing is defined a base class and a factory for the creation of instances through a number of plugins. The plugins auto registers when theis shared objects are dynamically loaded from the application. Each plugin instance is derived from a pure abstract interface defined in the application and used from the plugins through an header. The application maintains a list of these plugins as a member of an object. I would like use boost.serialization library in order to serialize the application container object with all the plugins contained. The library reference mentions a plugin case among its 'special considerations', but I couldn't obtain nothing working till now, so that I wonder if I should use instead the 'PIMPL' idiom (mentioned in the 'Case Studies'). I'm neither sure if the PIMPL idiom is the right waym since it would imply the definition of the base class in every plugin (so in every shared object), that means a replication of the same coding. So far, is there a complete example of boost.serialization of plugins with private implementation in shared object? Many thanks in advance Giampiero

3 5

serialization error : boost_serialization not closed
by simone pilozzi 08 Aug '12

08 Aug '12

Dear Users, I am often incurring in an error when I try to load the xml objects serialized with boost with an xml reader (notepad 2007 for example) . The error message is always the following "The following elements are not closed: boost_serialization". In the case of vector<double> the serialized file reads like this: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="9"> <Index_values> <count>777</count> <item_version>0</item_version> <item>0.654941</item> <item>0.61598900000000001</item> <item>0.051253</item> <item>0.03968</item> ... </Index_values> Then apparently there is boost_serialization is not closed (however, the deserialization with boost will work). Am I wrong somewhere or is it truly an issue? Thanks in advance

1 0

Compiler errors when using Boost::Spirit
by Evan Driscoll 07 Aug '12

07 Aug '12

Hey all, I'm new to Spirit and trying to put a parser together for a very simple language of S expressions. [Note: while I'm new to Spirit, I'm not new to parsers or parser combinators.] This is sort of an obnoxious email because it's basically "here, solve my problem for me even though I haven't read the docs as well as I could", but I figured I'd ask anyway; so if you take a look, I'm much appreciative. I define some tokens template <typename Lexer> struct tokens : lex::lexer<Lexer> { tokens() { this->self.add ("(", Tokens::L_Paren) (")", Tokens::R_Paren) ("\"...\"", Tokens::String_Literal) ("[0-9]+", Tokens::Integer_Literal) ("[a-zA-Z]+", Tokens::Symbol) ; } }; Then a grammar: template <typename Iterator> struct sexp_grammar : qi::grammar<Iterator, SExp::Ptr(), space_type> { qi::rule<Iterator, SExp::Ptr(), space_type> sexp; qi::rule<Iterator, vector<SExp::Ptr>(), space_type> sexp_list; sexp_grammar() : sexp_grammar::base_type(sexp) { using qi::token; using namespace Tokens; sexp_list = *sexp; sexp = token(String_Literal) | token(Integer_Literal) | token(Symbol) | (token(L_Paren) >> sexp_list >> token(R_Paren) ); } }; (SExp is a class, and SExp::Ptr is a typedef to shared_ptr<SExp>.) If I change the also tried removing the template parameters other than Iterator in the rules, and that let it compile (albeit with a warning). I get oodles of errors (compiling with GCC 4.6 with g++ -o src/parser.os -c -std=c++0x -g -Wall -Wextra -Wnon-virtual-dtor -fPIC -Iinclude src/parser.cc) which I'm not even going to try to paste into this email and you can look at pastebin instead: http://pastebin.com/R5Hk9gJ0 The full code can be seen at https://github.com/EvanED/simple_sexp/blob/master/src/parser.cc Evan

1 1

[iostream] Problems opening large mapped_file
by Heiko Klein 07 Aug '12

07 Aug '12

Hi, I wanted to test the mapped_file_source iostream device. My code is working well with a normal file_source device and files >= 6GB. When I change the constructor to a mapped_file_source, it works still well for smaller files (e.g. 150MB), but for files > 2GB I get (tested with 2.5GB): exception occured: failed getting file size: Value too large for defined data type And for files > 4GB (tested with 6GB) I get: exception occured: failed opening file: Bad file descriptor My constructor is as follows: using namespace boost::iostreams; typedef stream<mapped_file_source> mmStream; mmStream* mmistream = new mmStream(); mmistream->open(mapped_file_source(fileName)); I've tested against boost 1.44 and a 32bit linux (Ubuntu 10.04). Are these general mmap problems, or am I missing some flags for mapped_file_source? Best regards, Heiko

3 4

[xpressive] questions about semantic actions
by Nathan Ridge 06 Aug '12

06 Aug '12

Hello, I am trying to use semantic actions in Boost.Xpressive, and I have a couple of questions: 1. When a semantic action is attached to a subexpression of a regex, what is the meaning of _, s1, s2 etc. in the semantic action? For example, suppose you have the following regex: ((s1 = xpr1)[action]) >> (s2 = xpr2) Inside 'action': - is it valid to use '_'? - if so does it refer to just the portion matched by xpr1? - is it valid to use 's1'? - is it valid to use 's2'? 2. Is there a way to access the regex_id of the regex to which a semantic action belongs from the semantic action? More generally, can a semantic action be written as a custom function object that takes as argument some sort of environment (perhaps a match_results<>)? Thanks, Nate

2 6

boost.Iostream OpenSSL Filter
by exocoder 05 Aug '12

05 Aug '12

I am currently looking at using OpenSSL to write information to an encrypted file on-the-fly so to speak. I have been researching my options for doing this, and have come across the Boost.Iostream library, which promises to be a very elegant solution (The documentation even suggests that filters can be written to provide encryption/decryption using OpenSSL). It would seem that my best approach would be to use the BIO_f* interface to encrypt a memory buffer, which could be written by overloading write(). However the OpenSSL documentation is particularly sparse when it comes to file/memory encryption and I would appreciate any advice on how to do this. Thank you in advance for any help proffered.

1 0

[boost] [review] Multiprecision review results
by Jeffrey Lee Hellrung, Jr. 04 Aug '12

04 Aug '12

Summary -------- John Maddock and Christopher Kormanyos' Multiprecision library is ACCEPTED for inclusion into Boost, with 8 YES votes, 1 NO vote, and 1 CONDITIONAL vote. Details -------- Most reviewers noted that this was a sufficiently good first step toward extended precision arithmetic for inclusion into Boost. I think John and Chris will agree that there remains quite a bit of work left to do, but as one reviewer noted, John has an excellent track record regarding Boost development and Chris has been extremely dedicated during the pre-review development, review process, and post-review development, so I think this bodes well for the library's future. I'm going to highlight what I perceive to be some of the bigger issues raised by various individuals involved with in discussion, but I will share all my notes via Google Docs [1], and of course even further details are available in the mailing list archive. I note that many of the issues raised during the review have already been addressed by John and Chris. Mixed-Type Arithmetic -------- This has come up over and over again, especially in the context of allowing extended precision types within the same "family" to interoperate, which I think is tractable. Removing my review manager hat for a moment, perhaps a tag dispatching system similar to Boost.MPL or Boost.Fusion could be used, where all arithmetic types within the same family have the same tag, and hence only allow mixing types with the same tag. Most types will have a unique tag (which, I don't know, could default precisely to the arithmetic type?), but, e.g., Vicente's family of fixed-precision (and maybe even fixed-point) types would all be identifiable as being in the same family, and a traits class would determine the result types of the various arithmetic operations. Mixed-type arithmetic outside the above scope seems more tricky, but some users seem to still desire this in some form. Actual desired use cases will undoubtedly help here. Naming -------- Several commented on the redundancy of "mp_" prefix for identifiers already residing the boost::mp namespace. Narrowing Conversions -------- cpp_dec_float should round rather than truncate on narrowing conversions. Review manager hat off: I wonder if a radix-2 implementation of an arbitrary precision float should ultimately be prioritized and recommended over the present radix-10 implementation? It sounds like conversions in general should be reviewed, but I'm entirely sure myself where they all stand. If possible, narrowing conversions should be explicit while others (that would guarantee no loss of precision) may be implicit. This would be a departure from C++ builtin types. Performance -------- Phil, the lone NO vote, lamented that the scope of the library was evidently beyond simple fixed-precision (e.g., 128-bit or 256-bit) integral types, which is his desired use case. Indeed, at least in an earlier version of MP, expression templates seemed to give a performance penalty relative to using the raw back-end types; in theory, expression templates should give no performance hit, but compilers just may not be there yet. In any case, several reviewers requested that the scope of the library be clarified up front in the documentation. Regularization/Normalization of Back-End Behavior via Front-End -------- As Edward pointed out, different back-ends generally have different behavior on some "exceptional" cases, making use of the corresponding front-ends in generic contexts at times cumbersome (specifically when the generic context needs to handle said exceptional cases). A couple examples given were division-by-zero and conversion from a string with invalid characters. It is by no means *necessary* to regularize/normalize *all* such differences, but as many as possible and practical should be identified, considered, and documented. Separation of Data Structures and Algorithms -------- Though requested, John and Steven have maintained that this simply isn't very practical. I've gathered that there are too many special cases that (1) would make implementations a nightmare; and (2) would have be addressed very carefully (i.e., in a likely not-very-readable way) to avoid any performance hits. Since this has come up a few times, maybe something could be said in the documentation about this. Thanks to everyone who submitted reviews and participated in the discussion. Let me know if I left out anything you feel is particularly significant or inaccurate. - Jeff [1] https://docs.google.com/document/d/19YgtWBQt0lpjJoJDOtAlScZAZyOwzbHimiYTi-g…

1 0

[boost] [type_erasure] Review ended
by Lorenzo Caminiti 04 Aug '12

04 Aug '12

Hello all, The review of Boost.TypeErasure ended on Aug 3, 2012. Stay tuned for my decision on the library. Thank you very much to Steven, everyone that submitted a review, and everyone that participated in the discussions. The review manager, --Lorenzo On Fri, Aug 3, 2012 at 11:00 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: > Hello all, > > *** The review of Boost.TypeErasure ends today Aug 3, 2012. If you are > planning to submit a review, please do so by the end of today. *** > > Thank you to all that have participated to the review so far. > > The review manager, > --Lorenzo > > On Jul 27, 2012 1:41 PM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >> >> Hello all, >> >> After consulting the review wizards and Steven, I am extending >> Boost.TypeErasure review of one week, until August 3, 2012. >> >> Thank you to all that have submitted a review already and I am looking >> forward to receiving additional submissions. >> >> The review manager, >> --Lorenzo >> >> On Jul 27, 2012 3:22 AM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >>> >>> Hello all, >>> >>> On Mon, Jul 23, 2012 at 9:09 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> >>> wrote: >>> > On Wed, Jul 18, 2012 at 1:13 AM, Lorenzo Caminiti >>> > <lorcaminiti(a)gmail.com> wrote: >>> >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >>> >> begins on July 18, 2012 and ends on July 27, 2012. *** >>> > >>> > *** Boost.TypeErasure review ends in 5 days. Please submit your reviews >>> > :D *** >>> >>> *** Boost.TypeErasure review ends today July 27, 2012. If you are >>> planning to submit a review, please do so as soon as possible. *** >>> >>> Thank you to everyone who has commented on the library and submitted a >>> review so far! >>> >>> The review manager, >>> --Lorenzo >>> P.S. I am considering extending the review until end of day Sunday >>> July 29, 2012... I will keep you posted. >>> >>> > There have been interesting discussions on the library on the ML but I >>> > have not received any official review yet :( Especially if you are a >>> > user of Boost Any, Function, and Any Iterator, you definitely want to >>> > take a look at Type Erasure as it generalizes solutions provided by >>> > those other libraries. >>> > >>> > Thank you. >>> > >>> > The review manager. >>> > --Lorenzo >>> > >>> >> THE LIBRARY >>> >> >>> >> C++ provides runtime polymorphism through virtual functions. They are >>> >> a very useful feature, but they do have some limitations. >>> >> * They are intrusive. In generic programming, we can design an >>> >> interface which allows third-party types to be adapted to it. >>> >> * They require dynamic memory management. Of course, most of the >>> >> problems can be avoided by using an appropriate smart pointer type. >>> >> Even so, it still acts like a pointer rather than a value. >>> >> * Virtual functions' ability to apply multiple independent concepts to >>> >> a single object is limited. >>> >> The Boost.TypeErasure library solves these problems allowing us to >>> >> mirror static generic programming at runtime. >>> >> >>> >> Library source: >>> >> http://svn.boost.org/svn/boost/sandbox/type_erasure/ >>> >> >>> >> Pre-built documentation: >>> >> >>> >> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ >>> >> >>> >> You can also download archives with pre-built documentation from: >>> >> http://sourceforge.net/projects/steven-watanabe.u/files/ >>> >> >>> >> YOUR REVIEW >>> >> >>> >> Please submit a review to the mailing-list by replying to this email >>> >> ("[boost] [type_erasure] Review ..." should be in the subject). >>> >> >>> >> Please state clearly whether you think this library should be accepted >>> >> as a Boost library. >>> >> >>> >> Other questions you may want to consider: >>> >> 1. What is your evaluation of the design? >>> >> 2. What is your evaluation of the implementation? >>> >> 3. What is your evaluation of the documentation? >>> >> 4. What is your evaluation of the potential usefulness of the library? >>> >> 5. Did you try to use the library? With what compiler? Did you have >>> >> any problems? >>> >> 6. How much effort did you put into your evaluation? A glance? A >>> >> quick reading? In-depth study? >>> >> 7. Are you knowledgeable about the problem domain? >>> >> >>> >> Thanks in advance to all who participate in the review discussion -- >>> >> I'm looking forward to it!

1 0

[Integer] Is size_t as fast as uint_value_t<SIZE_MAX>::fast?
by jsnhblck＠gmail.com 04 Aug '12

04 Aug '12

===================================== #include<boost/integer.hpp> #ifndef SIZE_MAX #define SIZE_MAX ((size_t)-1) #endif /*It is the 'fast' size_t (unsigned integer type of the platform) */ typedef boost::uint_value_t<SIZE_MAX>::fast fsize_t; ===================================== Would the above code make any difference cross-platform? Is size_t as fast (cross-platform) as the above typedef? I believe that the above code converts whatever size_t is defined as into something that is 'fast'- the easiest for the processor to manipulate. However, what I don't know is whether size_t is already that. Also, I noticed that boost::hash returns 'size_t' so was just wondering why. I will be using hashes in different collections so had tried (above) to store them using the 'fast' boost::integer form.

2 1