August 2012 - Boost-users - lists.preview.boost.org

[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

[boost] [type_erasure] Review started (July 18-27, 2012)
by Lorenzo Caminiti 04 Aug '12

04 Aug '12

Hello all, *** The review of Steven Watanabe's proposed Boost.TypeErasure library begins on July 18, 2012 and ends on July 27, 2012. *** 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! The review manager. --Lorenzo

7 14

boost fusion dynamic at_n
by Niitsuma Hirotaka 04 Aug '12

04 Aug '12

I made boost fusion dynamic at_n usage boost::fusion::vector<int,double,std::string,char> vec(9 ,2.2 ,"aaa" ,'b'); std::cout << at_n_dynamic<double>(vec, 1) << std::endl; //=> 2.2 detail http://d.hatena.ne.jp/niitsuma/20120803/1343979718

1 0

How to create array of boost::interprocess::interprocess_mutex in maped file
by Alan Bus 04 Aug '12

04 Aug '12

I think here may be the good place to get some help or instruction. So I post my question here. Thanks in advance. I'd like to create array interprocess_mutex in mapped file, but don't know how to do that. Could you give some hints are highly appreciated? Thanks in advance! Following is my code snippet, typedef boost::interprocess::interprocess_mutex TMutex; managed_mapped_file *pMapFile = new managed_mapped_file(open_or_create, "/tmp/test.bin",1024UL*64UL*4096UL); TMutex *pMutex = pMapFile->construct<TMutex>("MyMutex")[50](); // Not sure here is right or not? TMutex **? How to declare for mutex array? //If I'd like to refer to 2nd element of this array, how can I use it? //pMutex[2] ? for example, scoped_lock<TMutex> lock<pMutex[2]>; // it crashed Could you give some instruction on how to create mutex array and how to access it by [] or other ways? Thank you very much. -- sincerely, Alan

1 0

Using single-pass ranges.
by Robert Jones 03 Aug '12

03 Aug '12

I have a class that hands out a sequence of Things through a getNextThing() interface, ie., struct Thing { }; struct ThingFeed { Thing * getNextThing( ); }; returning null when there's no more things. I'd like to be able to feed this into the Boost range-based algorithms, something like boost::for_each( thingFeedProxy | filter( someCondition ), doSomething ); But it's not clear to me how or if I can represent my ThingFeed as a range. Any thoughts or advice appreciated. Thx, Rob

4 6

Connecting signals2::signal to another signals2::signal: trackable?
by Chris Stankevitz 03 Aug '12

03 Aug '12

class A { boost::signals2::signal<void()> Signal; } class B { boost::signals2::signal<void()> Signal; } boost::shared_ptr<A> pA = boost::make_shared<A>(); boost::shared_ptr<B> pB = boost::make_shared<B>(); === Q1: Is it possible to connect A's signal to B? A1: Yes: void f() { pA->Signal.connect(pB->Signal); pA->Signal(); } === Q2: Will I get a crash if pB is subsequently released? A2: Yes void f() { pA->Signal.connect(pB->Signal); pB.reset(); pA->Signal(); // crash! } === Q3: Is it possible to use signals2::signal::slot_type::track to avoid the crash? A3: [I do not know the answer, please help me here] === Thank you, Chris

3 5