- Boost - lists.preview.boost.org

[documentation/doxygen] Incomplete header files names generated when the path contains twice boost
by Vicente Botet 16 Jun '11

16 Jun '11

Hi, While generating the Boost.Conversion documentation using quickbook and doxygen I have observed that the files named as doxygen boost : [ glob ../../../boost/conversion/boost/*.hpp ] Are expanded in the doc removing the path /boost/conversion. See http://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/h… Could something be done in order to correct this, or should I move the files to a directory that don't contains boost twice in the path? Any other workarounds? Any idea for a better name than boost? Best, Vicente http://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/index… -- View this message in context: http://boost.2283326.n4.nabble.com/documentation-doxygen-Incomplete-header-… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 3

[shared_ptr] Design question about make_shared
by Loïc Joly 16 Jun '11

16 Jun '11

Hello everybody, I recently wondered about the choice to make make_shared a free function, and not a static member function: struct A{...}; struct B:A {...}; shared_ptr<A> ptr = make_shared<B>(arg1,arg2); vs shared_ptr<A> ptr = shared_ptr<B>::make(arg1, arg2); I was wondering if this is just a stylistic choice, or if there are some differences? Thank you for any information. -- Loïc

8 17

[quickbook/doxygen] copydoc from internal header
by Tim Blechmann 16 Jun '11

16 Jun '11

hi all, preparing the docs of boost.heap, i came across one issue with the generation of the class reference: i have an internal header file, that should not be exposed to the class reference, but that needs to be parsed by doxygen (it contains a base class, which should be copied to its derived classes). however if i simply add it to the list of files to be parsed by bjam, it will be included into the reference (see [1]). is there any clean way to parse the file with doxygen but avoid it to be listed in the class reference? thanks, tim [1] http://tim.klingt.org/boost_heap/heap/reference.html

2 2

[gsoc] boost.simd news from the front.
by Mathieu - 16 Jun '11

16 Jun '11

Hi everyone, Last week, we (Joel Falcou my mentor, Mathias Gaunard, and me) had a meeting to decide the courses of action for the future boost.simd library. For those who aren't aware of it, it's a subset of an existing library, namely nt2, which provide an abstraction for simd instructions in C++. Here is what have been decided so far : boost.simd will be composed of several modules mimicking what's done in nt2 (or in phoenix). That is there will be the main operators in a module (add / minus etc) and the extra modules that we provide like bitwise (bitwise_andnot etc) or arithmetic. Second, what will be included? We decided to keep only functions which might have a corresponding intrinsic to exploit. Finally boost.build will come into play later in the process. Final note, despite what I said in a previous mail a few weeks ago, the initial development will happen in the nt2 (available at https://github.com/MetaScale/nt2 : main repository (in a branch) for ease of use (to ease merge process mainly) and in the boost.simd repository. Cheers, Mathieu Masson.

10 44

Fwd: [MSM] exit_ps stuks in case of outer state machine uses Row with event to event base class
by Richard Szabo 15 Jun '11

15 Jun '11

Thanks Christophe I will try it out but we use the queue anyhow because we send signals to our self some cases. It was just a copy paste mistake for the example to disable queues. the real problem is the constructor if I define this : event4 (const event3& evt_) : baseEvent() { } than it works (after enabling the queue). So I don't get it why it is compiles ..... and now I have to figure out what has changed in our real code which hides the copy constructor ..... Thanks for your support PS : We update to latest MSM time to time and even using new features of it like Enqueueing events for later processing Thanks Richard On 15 June 2011 06:42, Christophe Henry <christophe.j.henry(a)googlemail.com> wrote: >> 3. This one is my fault and might be a problem for you as you seek >> performance. I think we discussed this but I forgot it in the doc. Pseudo >> exits require the message queue and you deactivated it with: >> typedef int no_message_queue; > > Thinking again about it, as you have the newest MSM version (time for a bit > of advertisement for the new version ;-) ), there is now a way around the > queue. > The exit point needs the queue because it will process an event4 during > processing of event3, so that MSM has time to update its current state > before processing event4. But this is only because MSM does this after the > transition (the UML standard "forgot" to specify this point). > The newest version allows you to override this and decide that this updating > job will be done for example before the transition is taken (after the guard > chooses the transition of course), or after the exit action, etc. > To do this, add into every state machine: > > typedef msm::active_state_switch_before_transition > active_state_switch_policy; > > Now you don't need the queue. Doc is there: > http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s05.html#backend… > > Regards, > Christophe > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

[math] Empirical distribution function
by Denis Arnaud 15 Jun '11

15 Jun '11

Hello, would there be an interest in adding the Empirical distribution function ( http://en.wikipedia.org/wiki/Empirical_distribution_function) to Boost.Math? The good statistical software projects implement it. For instance, in R, we have the ECDF ( http://stat.ethz.ch/R-manual/R-patched/library/stats/html/ecdf.html) and Python has something like that as well ( http://statsmodels.sourceforge.net/generated/scikits.statsmodels.tools.ECDF… ). Best Denis

5 6

Re: [boost] [math] Empirical distribution function
by Denis Arnaud 15 Jun '11

15 Jun '11

(please disregard my previous message: the subject was not the correct one) Date: Wed, 15 Jun 2011 06:19:49 -0400, From: er <er.ci.2020(a)gmail.com> > I developed one as a Boost.Accumulator here: > https://svn.boost.org/svn/boost/sandbox/statistics/non_parametric/boost/sta… > > While it's been a while I haven't touched these directories, I'd be > happy to do some maintenance & a proper doc/test suite. > It is the ECDF assuming independent sampling (I think identically need > not even be assumed) and derived quantities (such as Kolmogorov Smirnov > statistic) : > F(x) = count of samples below x > The fact that it's an accummulator is just a convenience : the > distribution is updated each time a sample is passed to the acc. > I'm doing maintenance work right not, whether or not this matches the > need of Denis. It shouldn't take too much time (days). That seems to fit my (pretty simple) need. I'm still trying to test it. Indeed, I would find it more logical to have an empirical distribution "function" <http://en.wikipedia.org/wiki/Empirical_distribution_function>part of the set of already existing Boost.Math statistical distributions<http://www.boost.org/doc/libs/1_46_1/libs/math/doc/sf_and_dist/html/math_to…>. But an accumulator is just fine for now. By the way, does it mean that if we have a set of 1 million of distinct real numbers, the corresponding accumulator will store a pretty big number of counters? Denis

2 1

[fusion] Qualification of 'at' and 'deref' in fusion (Ticket #4755)
by Gabriel Redner 15 Jun '11

15 Jun '11

I have just been bitten by a simple issue in fusion. The 'at' and 'deref' functions are used unqualified, which causes conflicts when mpl::at and mpl::deref are also visible. This issue has been reported as Ticket #4755 [1], and a patch was attached eight months ago. Is there anyone I can prod to get this fix committed? I have also updated the ticket with some relevant information. Thanks, -Gabe [1] https://svn.boost.org/trac/boost/ticket/4755

3 4

[intrusive] unordered_set insert/find question
by Tim Blechmann 15 Jun '11

15 Jun '11

hi all, i am a bit confused about the behavior of boost::intrusive::unordered_set. i can insert() an object, but i am unable to find() it: my basic workflow is: // insert: map_type * elem = new map_type(); std::pair<iterator, bool> inserted = slot_resolver_map.insert(*elem); bool success = inserted.second; assert(success); // object has been inserted correctly // verify: iterator this_iterator = inserted.first; iterator found = slot_resolver_map.find(*elem); iterator end = slot_resolver_map.end(); assert(this_iterator == found); // fails assert(found != end); // fails so basically if i insert an element, i cannot find it anymore ... i have a reduced test case, which shows this behavior at [1] ... is this my fault (not using the unordered_set correctly) or is it a bug in boost.intrusive? thanks, tim

3 4

MS VC10 std::numeric_limits<float>::max_digits10 is wrong for float
by Paul A. Bristow 15 Jun '11

15 Jun '11

Inexplicably, MS for VS 10 have chosen std::numeric_limits<float>::max_digits10 == 8 for VS 10 rather than 9, when the formula max_digits10 = 2 + std::numeric_limits<FPT>::digits * 3010/10000; and values have been known for 30 years. std::numeric_limits<T>:: max_digits10; is 'new for C++0X'. Briefly, max_digits10 is the number of decimal digits that you need to output to make sure that a one least significant bit (ULP) change produces a different decimal digit string. Any more digits are just noise with no useful information. Using max_digits10 rather than the formula above may be more efficient, and is certainly very much clearer. "Executive Summary" ================ Don't use max_digits10 for float or floating-point template types for MS VS - yet! You can safely (and very usefully) use cout.precision(std::numeric_limits<double>::max_digits10); when you want to be sure that all significant decimal digits are output. GCC provides the correct values of 9 for float (and 17 for double). The Fuller Story =========== This might affect anyone planning to use VS10 and this new (and very useful numeric_limits value) with built-in *type float, or a floating-point template type*, potentially, for example, with Boost Lexical_cast, Serialization. Round tripping would be 1 bit wrong in perhaps 1/3 of cases! If max_digits10 was used, Boost.Test might detect values that are different, but are reported to be the same, for example. As far as I know, none of these utilities yet try to use max_digits10. Mercifully, this fault only affects type T = float (not the most popular double or long double), and only in new code that uses the 'new for C++0X' numeric_limits<T>:: max_digits10. Other types like double and long double (and possibly user defined types that specialize numeric_limits) are, I believe, correct. So you can safely (and very usefully) use cout.precision(std::numeric_limits<double>::max_digits10); when you want to be sure that all significant decimal digits are output. (If you want this to be 'Boost portable' you will have to use the inscrutably named BOOST_NO_NUMERIC_LIMITS_LOWEST as a proxy for "C++0x numeric_limits before using new-for-C++0X max_digits10. Unless we add yet another macro for max_digits10? Groan.). The workaround is to continue to use the well-tried and test Kahan formula max_digits10 = 2 + std::numeric_limits<FPT>::digits * 3010/10000; Reported and confirmed as https://connect.microsoft.com/VisualStudio/feedback/details/668921/std-nume… ts10-value-of-8-is-wrong-and-should-be-9 (It might help if, you could confirm you can 'reproduce' this too). I trust this mistake will be corrected pronto - but I'm not holding my breath :-( I will post again if it is resolved. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

5 13

[MSM] exit_ps stuks in case of outer state machine uses Row with event to event base class
by Richard Szabo 15 Jun '11

15 Jun '11

Hi Christophe and All after splitting our complicated several level deep contained state machines to small run-time instances. I have to use feature Event Hierarchy (http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s02.html#d0e1176) which is really cool. But this feature in combination with pseudo exits state, breaks the pseudo exit state functionality and the pseudo exit state is entered but never left. I have made a small example where the problem is reproduced see attachment. (the file name is misleading was just lazy to rename it something more appropriate) Here is the output of the execution : entering: Idle MS1_ leaving: Idle Action: MS1::onEvent1 entering: RunningStateMachine MS1_ entering: RunningStateMachine::PseudoEntry1 leaving: RunningStateMachine::PseudoEntry1 entering: Inner1 RunningStateMachine_ entering: InnerState11 leaving: InnerState11 leaving: Inner1 entering: RunningStateMachine::PseudoEntry1 I have tried it in our host test environment only so VC9 compiler and with boost trunk from Friday last week. Cheers Richard.

2 2

[review][assign] Formal review of Assign v2 begins 15th June
by John Bytheway 14 Jun '11

14 Jun '11

The formal review of the Assign v2 library upgrade by Erwann Rogard starts tomorrow, June 15th and is scheduled to continue until June 24th. About Assign v2 =============== Assign v2 is an upgrade of Boost.Assign (1.0) that redefines its functionality, with optional C++0x support and new features. It is a compact interface for executing the repetitive tasks of assigning or inserting container elements. Please see the change log (linked below) for more detail on the motivation for this library and pointers for navigating the documentation. Where to get it =============== The documentation is online at: <http://svn.boost.org/svn/boost/sandbox/assign_v2/libs/assign/v2/doc/html/in…> With the change log at: <http://svn.boost.org/svn/boost/sandbox/assign_v2/libs/assign/v2/doc/html/bo…> The Assign v2 source can be found in the Boost sandbox at: <http://svn.boost.org/svn/boost/sandbox/assign_v2/> or downloaded from: <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=assign…> Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) with '[assign]' in the subject. Or if you don't wish to for some reason, you can send them privately to me. If so, please let me know whether or not you'd like your review to be forwarded to the list. All reviews are appreciated, even if you don't have time for an in-depth study. The Assign v2 library consists of several largely independent components: Reference containers and chaining, container modification and generation, and conversion of ranges to containers. If you wish, feel free to review and even vote on these separately. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. More detail on the review process is available at: http://www.boost.org/community/reviews.html John Bytheway Review Manager

1 0

[documentation/doxygen] Trouble with partial template specializations in documentation
by Vicente Botet 14 Jun '11

14 Jun '11

Hi, I'm having some trouble with partial template specializations documentation while generating the Boost.Conversion documentation. The documentation for the specialization is not generated sometimes. I have added the file type_erasure/any.hpp that specialize the any template class and it works as expected with my Jamfile. I don't know why the specializations in conversion/assign_to.hpp are not all generated. The specialization on conversion/boost and conversion/std don't appear neither. Could someone help me? Thanks in advance, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/documentation-doxygen-Trouble-with-parti… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Holding char arrays in boost variants, what is the correct way?
by Michael Goldshteyn 14 Jun '11

14 Jun '11

What is the correct way of getting several character arrays into a variant: // This doesn't work typedef boost::variant<int,char[256],char[8192]> MyType; // This does, but seems like a lot of work template <int len> struct MyChar { char val_[len]; }; typedef boost::variant<int,MyChar<256>,MyChar<8192> > MyType; What is the best way to do this? Thanks, Michael Goldshteyn

4 7

[container_bptree] updates and performance measurements
by Vadim Stadnik 14 Jun '11

14 Jun '11

Hi all, The code and documentation of the submitted library container_bptree have been updated. The new version can be downloaded using this link: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=contai… 1. For those who do not know this library I’d suggest before opening the documentation to spend some time to the answer the following warm-up question: Is it possible to sum up any N consecutive numbers in less than N-1 operations? 2. The library and tests compile and run correctly on two C++ compilers: MSVC++ 9/10 (tested with Visual Studio 2008/2010, including Express editions), and GCC 4.5.2 (tested with MinGW). 3. Lists of template parameters of class templates have been modified to simplify the generation of classes of STL variants of containers. 4. Performance measurements have been added to the documentation. They show that submitted B+ trees are highly competitive with Red Black trees in basic operations. 5. I would like to thank Beman Dawes for suggestion to adapt and apply map tests from his project [BTree]. Class templates of the namespace container_bptree can be used to generate three types of map containers with bidirectional and random access iterators. All of them pass successfully the adapted tests on Windows systems. At this stage it would be particularly valuable in addition to my own tests to run independent tests for associative containers with random access iterators. This is why I am wondering if there are Boost libraries, which include classes of such associative containers and test code. 6. Since I am a newcomer to Boost community I do not know how the current level of quality of the library container_bptree meets Boost standards. Anyone who tried the code and read the documentation is welcome to make comments and suggestions. I am quite happy to implement another list of improvements before the formal request for interest to this library. Regards, Vadim Stadnik

1 0

fusion concepts
by Robert Ramey 14 Jun '11

14 Jun '11

I'm trying to implement concept checking for at least parts of the boost::fusion library. My motivations are several: a) I'm interested in making another library/program based on fusion and I believe that having implemented concepts will make this job easier. b) I'm interested in the concept checking concept and this is way to pracitice. Attached is the current state of my efforts. I have a few problems with this. I think most of these are specific to fusion but maybe not. a) line 29 of test_misc.cpp invokes concept checking on a fusion vector. lines 28 & 29 of fusion/concepts.hpp are intended to verify that result_of::next<I> have been defined for the for the forward iterator associated with the fusion vector. The BOOST_CONCEPT_ASSERT fails with element 6 from the sequence. I conclude that the recurrsive invocation of concept checking on the result of next<I> is crapping out at the end of the sequence. This makes sense in a practical way - BUT it would voilate the requirements on the return type from result_of::end<vector>. Sooooo i) am I right about this? ii) if so how should it be addressed? fixing the concept implementation (how?) would "hide" the violation. Seems to be that the documentation on forward sequence/iterator should be tweaked and my concept checking code should be fixed up to match. Any thoughts on this? b) lines 34-38 illustrate a different problem. I can't figure out what distance(i,j) is supposed to return. I would think that result_of::distance(i, j) should be a signed integer of some sort. So I'm not understanding why this assertion traps. I not sure if it's a side effect of the problem cited in a) above. c) In another file not included here (test_concepts.hpp). I've attempted to implement archtypes for these types. I managed to do it, but I'm not all that confident that i did it right. After doing this, I came to understand the fusion extension mechanism. I could re-implement the archtypes with this and I'm confident that it would be "correct" BUT I'm wonder if this just wouldn't be a circular conclusion. That is would doing this really be testing the concepts or would generating archetypes in this way just guarentee that things were in some sense internally consistent but not necessarily reflection the concepts as stated in the documentation. Any comments/help would be appreciated. Robert Ramey begin 666 concepts.hpp M(VEF;F1E9B!?0T].0T505%-?#0HC9&5F:6YE(%]#3TY#15!44U\-"@T*+R\@ M35,@8V]M<&%T:6)L92!C;VUP:6QE<G,@<W5P<&]R=" C<')A9VUA(&]N8V4- M"B-I9B!D969I;F5D*%]-4T-?5D52*2 F)B H7TU30U]615(@/CT@,3 R,"D- M"B,@<')A9VUA(&]N8V4-"B-E;F1I9@T*#0H-"B-I;F-L=61E(#QB;V]S="]C M;VYC97!T+V%S<V5R="YH<' ^#0HC:6YC;'5D92 \8F]O<W0O8V]N8V5P=%]C M:&5C:RYH<' ^#0HC:6YC;'5D92 \8F]O<W0O9G5S:6]N+VET97)A=&]R+FAP M<#X-"B-I;F-L=61E(#QB;V]S="]F=7-I;VXO<V5Q=65N8V4N:'!P/@T*#0IN M86UE<W!A8V4@8F]O<W0@>PT*;F%M97-P86-E(&9U<VEO;B![#0H-"G1E;7!L M871E(#QT>7!E;F%M92!)/@T*<W1R=6-T($9O<G=A<F1)=&5R871O<B Z#0H@ M(" @8F]O<W0Z.D5Q=6%L:71Y0V]M<&%R86)L93Q)/BP-"B @("!B;V]S=#HZ M0V]P>4-O;G-T<G5C=&EB;&4\23X-"GL-"G!U8FQI8SH-"B @("!"3T]35%]# M3TY#15!47U5304=%*$9O<G=A<F1)=&5R871O<BD-"B @("![#0H@(" @(" @ M('1Y<&5D968(a)22!*.PT*(" @(" @(" O+R!V97)I9GD@=&AE('1H92!F;VQL M;W=I;F<@97AI<W0-"B @(" @(" @='EP961E9B!T>7!E;F%M92!B;V]S=#HZ M9G5S:6]N.CIR97-U;'1?;V8Z.FYE>'0\23XZ.G1Y<&4@=#$[#0H@(" @(" @ M($)/3U-47T-/3D-%4%1?05-315)4*"@@1F]R=V%R9$ET97)A=&]R/'0Q/B I M*3L-"B @(" @(" @='EP961E9B!T>7!E;F%M92!B;V]S=#HZ9G5S:6]N.CIR M97-U;'1?;V8Z.F5Q=6%L7W1O/$DL($H^.CIT>7!E('0R.PT*(" @(" @("!T M>7!E9&5F('1Y<&5N86UE(&)O;W-T.CIF=7-I;VXZ.G)E<W5L=%]O9CHZ861V M86YC95]C/$DL,#XZ.G1Y<&4@=#,[#0H@(" @(" @('1Y<&5D968@='EP96YA M;64@8F]O<W0Z.F9U<VEO;CHZ<F5S=6QT7V]F.CIA9'9A;F-E/$D(a)+$T^.CIT M>7!E('0T.PT*(" @(" @("!T>7!E9&5F('1Y<&5N86UE(&)O;W-T.CIF=7-I M;VXZ.G)E<W5L=%]O9CHZ9&ES=&%N8V4\22 L2CXZ.G1Y<&4@=#4[#0H@(" @ M(" @('1Y<&5D968@='EP96YA;64@8F]O<W0Z.F9U<VEO;CHZ<F5S=6QT7V]F M.CID97)E9CQ)/CHZ='EP92!T-CL-"B @(" @(" @='EP961E9B!T>7!E;F%M M92!B;V]S=#HZ9G5S:6]N.CIR97-U;'1?;V8Z.G9A;'5E7V]F/$D^.CIT>7!E M('0W.PT*+R\@(" @(" @('0U('@@/2!D:7-T86YC92AI+"!J*3L@#0HO+R @ M(" @(" @0D]/4U1?0T].0T505%]!4U-%4E0H* T*+R\@(" @(" @(" @("!B M;V]S=#HZ4VEG;F5D26YT96=E<CQT>7!E;F%M92!B;V]S=#HZ9G5S:6]N.CIR M97-U;'1?;V8Z.F1I<W1A;F-E/$D(a)+$H^.CIT>7!E/@T*+R\@(" @(" @("DI M.PT*(" @(" @("!S86UE7W1Y<&4H:2 ]/2!J+"!B*3L-"B @(" @(" @<V%M M95]T>7!E*&D@(3T@:BP@8BD[#0H@(" @(" @('-A;65?='EP92AD97)E9BAI M*2P(a)=BD[.PT*(" @(" @("!S86UE7W1Y<&4H*FDL('8I.PT*(" @('T-"B @ M(" -"G!R:79A=&4Z#0H@(" @22!I+"!J.PT*(" @(&)O;VP@8CL-"B @("!T M>7!E;F%M92!B;V]S=#HZ9G5S:6]N.CIR97-U;'1?;V8Z.G9A;'5E7V]F/$D^ M.CIT>7!E('8[#0H@(" @='EP961E9B!B;V]S=#HZ;7!L.CII;G1?/# ^.CIT M>7!E($T[#0H-"B @(" O+R!4>7!E(&1E9'5C=&EO;B!W:6QL(&9A:6P@=6YL M97-S('1H92!A<F=U;65N=',@:&%V92!T:&4@<V%M92!T>7!E+@T*(" @('1E M;7!L871E(#QT>7!E;F%M92!4/@T*(" @('9O:60@<V%M95]T>7!E*%0@8V]N M<W0F+"!4(&-O;G-T)BD[#0I].PT*#0IT96UP;&%T92 \='EP96YA;64@4SX- M"G-T<G5C="!&;W)W87)D4V5Q=65N8V4@>PT*<'5B;&EC.@T*(" @($)/3U-4 M7T-/3D-%4%1?55-!1T4H1F]R=V%R9%-E<75E;F-E*0T*(" @('L-"B @(" @ M(" @+R\@=F5R:69Y('1H92!T:&4@9F]L;&]W:6YG(&5X:7-T#0H@(" @(" @ M('1Y<&5D968@='EP96YA;64@<F5S=6QT7V]F.CIB96=I;CQ3/CHZ='EP92!T M,3L-"B @(" @(" @0D]/4U1?0T].0T505%]!4U-%4E0H*"!&;W)W87)D271E M<F%T;W(\=#$^("DI.PT*(" @(" @("!T,2!X,2 ](&)E9VEN*',I.PT*(" @ M(" @("!T>7!E9&5F('1Y<&5N86UE(')E<W5L=%]O9CHZ96YD/%,^.CIT>7!E M('0R.PT*+R\@(" @(" @($)/3U-47T-/3D-%4%1?05-315)4*"@@1F]R=V%R M9$ET97)A=&]R/'0R/B I*3L-"B @(" @(" @=#(@>#(@/2!E;F0H<RD[#0H@ M(" @(" @('1Y<&5D968@='EP96YA;64@<F5S=6QT7V]F.CIS:7IE/%,^.CIT M>7!E('0S.PT*(" @(" @("!T,R!X,R ]('-I>F4H<RD[#0H@(" @(" @('1Y M<&5D968@='EP96YA;64@<F5S=6QT7V]F.CIE;7!T>3Q3/CHZ='EP92!T-#L- M"B @(" @(" @=#0@>#0@/2!E;7!T>2AS*3L-"B @(" @(" @='EP961E9B!T M>7!E;F%M92!R97-U;'1?;V8Z.F9R;VYT/%,^.CIT>7!E('0U.PT*(" @(" @ M("!T-2!X-2 ](&9R;VYT*',I.PT*(" @('T-"@T*<')I=F%T93H-"B @("!3 M(',[#0H-"B @(" O+R!4>7!E(&1E9'5C=&EO;B!W:6QL(&9A:6P@=6YL97-S M('1H92!A<F=U;65N=',@:&%V92!T:&4@<V%M92!T>7!E+@T*(" @('1E;7!L M871E(#QT>7!E;F%M92!4/@T*(" @('9O:60@<V%M95]T>7!E*%0@8V]N<W0F M+"!4(&-O;G-T)BD[#0I].PT*#0I]("\O(&9U<VEO;@T*?2 O+R!B;V]S= T* M#0HC:6YC;'5D92 \8F]O<W0O9G5S:6]N+VET97)A=&]R+VME>5]O9BYH<' ^ M#0HC:6YC;'5D92 \8F]O<W0O9G5S:6]N+VET97)A=&]R+W9A;'5E7V]F7V1A M=&$N:'!P/@T*(VEN8VQU9&4@/&)O;W-T+V9U<VEO;B]I=&5R871O<B]D97)E M9E]D871A+FAP<#X-"@T*;F%M97-P86-E(&)O;W-T('L-"FYA;65S<&%C92!F M=7-I;VX@>PT*#0IT96UP;&%T92 \='EP96YA;64@23X-"G-T<G5C="!!<W-O M8VEA=&EV94ET97)A=&]R(#H-"B @("!&;W)W87)D271E<F%T;W(\23X-"GL- M"G!U8FQI8SH-"B @("!"3T]35%]#3TY#15!47U5304=%*$%S<V]C:6%T:79E M271E<F%T;W(I#0H@(" @>PT*(" @(" @(" O+R!V97)I9GD@=&AE('1H92!F M;VQL;W=I;F<@97AI<W0-"B @(" @(" @='EP961E9B!T>7!E;F%M92!B;V]S M=#HZ9G5S:6]N.CIR97-U;'1?;V8Z.FME>5]O9CQ)/CHZ='EP92!T,3L-"B @ M(" @(" @='EP961E9B!T>7!E;F%M92!B;V]S=#HZ9G5S:6]N.CIR97-U;'1? M;V8Z.G9A;'5E7V]F7V1A=&$\23XZ.G1Y<&4@=#([#0H@(" @(" @('1Y<&5D M968@='EP96YA;64@8F]O<W0Z.F9U<VEO;CHZ<F5S=6QT7V]F.CID97)E9E]D M871A/$D^.CIT>7!E('0S.PT*(" @(" @("!S86UE7W1Y<&4H9&5R969?9&%T M82AI*2P@8F]O<W0Z.F9U<VEO;CHZ<F5S=6QT7V]F.CID97)E9E]D871A/$D^ M.CIT>7!E*3L-"B @("!]#0H@(" @#0H@<')I=F%T93H-"B @("!)(&D[#0H@ M(" @+R\@5'EP92!D961U8W1I;VX@=VEL;"!F86EL('5N;&5S<R!T:&4@87)G M=6UE;G1S(&AA=F4@=&AE('-A;64@='EP92X-"B @("!T96UP;&%T92 \='EP M96YA;64@5#X-"B @("!V;VED('-A;65?='EP92A4(&-O;G-T)BP@5"!C;VYS M="8I.PT*?3L-"@T*?2 O+R!F=7-I;VX-"GT@+R\@8F]O<W0-"@T*+RH-"D)I M9&ER96-T:6]N86P@271E<F%T;W(-"E)A;F1O;2!!8V-E<W,@271E<F%T;W(- M"D%S<V]C:6%T:79E($ET97)A=&]R#0H-"D9O<G=A<F0@4V5Q=65N8V4-"D)I M9&ER96-T:6]N86P@4V5Q=65N8V4-"E)A;F1O;2!!8V-E<W,@4V5Q=65N8V4- M"D%S<V]C:6%T:79E(%-E<75E;F-E#0H-"D-A;&QA8FQE($]B:F5C= T*4F5G M=6QA<B!#86QL86)L92!/8FIE8W0-"D1E9F5R<F5D($-A;&QA8FQE($]B:F5C M= T*4&]L>6UO<G!H:6,@1G5N8W1I;VX@3V)J96-T#0HJ+PT*#0HC96YD:68@ /+R\@7T-/3D-%4%137PT* ` end begin 666 test_misc.cpp M(VEN8VQU9&4@/'-T<FEN9SX-"B-I;F-L=61E(#QI;W-T<F5A;3X-"@T*(VEN M8VQU9&4@/&)O;W-T+V9U<VEO;B]C;VYT86EN97(O=F5C=&]R+FAP<#X-"B-I M;F-L=61E(#QB;V]S="]F=7-I;VXO=FEE=R]F:6QT97)?=FEE=RYH<' ^#0HC M:6YC;'5D92 \8F]O<W0O9G5S:6]N+W-E<75E;F-E+VEO+FAP<#X-"B-I;F-L M=61E(#QB;V]S="]M<&PO;F]T+FAP<#X-"B-I;F-L=61E(#QB;V]S="]T>7!E M7W1R86ET<R]I<U]C;&%S<RYH<' ^#0H-"G5S:6YG(&)O;W-T.CIM<&PZ.E\[ M#0IU<VEN9R!B;V]S=#HZ;7!L.CIN;W1?.PT*=7-I;F<@8F]O<W0Z.FES7V-L M87-S.PT*=7-I;F<@;F%M97-P86-E(&)O;W-T.CIF=7-I;VX[#0H-"G1Y<&5D M968@=F5C=&]R/'-T9#HZ<W1R:6YG+"!C:&%R+"!L;VYG+"!B;V]L+"!D;W5B M;&4^('9E8W1O<E]T>7!E.PT*='EP961E9B!R97-U;'1?;V8Z.F)E9VEN/'9E M8W1O<E]T>7!E/CHZ='EP92!V96-T;W)?='EP95]I=&5R871O<CL@#0IT>7!E M9&5F(&9I;'1E<E]V:65W/'9E8W1O<E]T>7!E(&-O;G-T+"!N;W1?/&ES7V-L M87-S/%\^(#X@/B!V:65W7W1Y<&4[#0H-"FEN="!M86EN*&EN="!A<F=C+"!C M:&%R("H@87)G=EM=*7L-"B @("!V96-T;W)?='EP92!V*")A+7-T<FEN9R(L M("= )RP@.3@W-C4T+"!T<G5E+" V+C8I.PT*(" @('9I97=?='EP92!V:65W M*'8I.PT*(" @('-T9#HZ8V]U=" \/"!V:65W(#P\('-T9#HZ96YD;#L-"GT- M"@T*#0HC:6YC;'5D92 B9G5S:6]N+V-O;F-E<'1S+FAP<"(-"B-I;F-L=61E M(")S8VAE;6$N:'!P(@T*#0I"3T]35%]#3TY#15!47T%34T525"@H(&)O;W-T M.CIF=7-I;VXZ.D9O<G=A<F1397%U96YC93QV96-T;W)?='EP93X@*2D[#0I" M3T]35%]#3TY#15!47T%34T525"@H(&)O;W-T.CIF=7-I;VXZ.D9O<G=A<F13 897%U96YC93QV:65W7W1Y<&4^("DI.PT* ` end

5 11

Re: [boost] [gsoc] boost.simd news from the front.
by Ivan Le Lann 14 Jun '11

14 Jun '11

----- "David A. Greene" <greened(a)obbligato.org> a écrit : > Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> writes: > > > Making data parallelism simpler is the goal of NT2. And we do that > by > > removing loops and pointers entirely. > > First off, I want to apologize for sparking some emotions. That was > not > my intent. I am deeply sorry for not expressing myself well. > > NT2 sounds very interesting! Does it generate the loops given calls > into generic code? > > Let me try to clarify my thinking about boost.simd a bit. > > - There is a place for boost.simd. It's important that I emphasize > this > upfront. > > - Here is how I see a typical programmer using it, given a loop nest: > > - Programmer tries to run the compiler on it, examines code > - Code sometimes (maybe most of the time) executes poorly > - If not, done > > - Programmer restructures loop nest to expose parallelism > - Try compiler directives first, if available (tell compiler > which > loops to interchange, where to cache block, blocking factors, > which loops to collapse, etc.) > - Otherwise, hand-restructure (ouch!) > > - Programmer tries compiler again on restructured loop nest > - Code may execute poorly > - If not, done > > - Programmer adds directives to tell the compiler which loops > to vectorize, which to leave scalar, etc. > - Code may still execute poorly > - If not, done > > - Programmer uses boost.simd to write vector code at a higher level > than provided compiler intrinsics > > Does that seem like a reasonable use case? > I hope I won't disappoint you, but in my case I'd put boost.simd a few ranks up. Because, from what I've seen in slides, it's a quite easy and really clean way to do things. I've always been taught to dive into dirty things as a last resort, so I'd use boost.simd first, and eventually, if performance is still not met, try hand-written hints. Regards, Ivan

1 0

[foreach][assign] Does foreach work with assign::list_of?
by MaximYanchenko 14 Jun '11

14 Jun '11

This simple example doesn't compile with GCC 4.4 + Boost 1.46.1: #include <boost/assign/list_of.hpp> #include <boost/foreach.hpp> #include <iostream> int main() { BOOST_FOREACH( int i, boost::assign::list_of(3)(1)(4)(1)(5) ) std::cout << i << ' '; } error: operands to ?: have different types 'const boost::foreach_detail_::rvalue_probe<boost::assign_detail::generic_list<int> >' and 'boost::assign_detail::generic_list<int>' I believe both Foreach and Assign library are to ease sequence creation/iteration on the fly, so they should work together smoothly. Thanks, Maxim

4 4

Re: [boost] Is there any interest in a base class which prevents construction during the static initialization phase?
by Ben Robinson 14 Jun '11

14 Jun '11

> > On Jun 12, 2011, at 4:51 PM, Ben Robinson wrote: > > > Because the order of static initialization is undefined, numerous > > difficult > > to detect problems can arise when multiple objects are initialized > > during > > the static initialization phase. This base class would guarantee > > that a > > class will never be unintentionally constructed during static > > initialization. This is the same philosophy behind how > > boost::noncopyable > > guarantees that a class will never be unintentionally copied. > > > > int main() > > { > > nonstaticinitializable::enable_initialization(); // Indicates that > > static initialization is complete. > > Foo foo; // This instance initializes successfully after static > > initialization. > > return 0; > > } // main > > > > What does Boost think about submission::nonstaticinitializable (I > > chose the > > name to mirror noncopyable)? > > The requirement to modify main() is sufficiently burdensome that I > probably wouldn't use this technique, though I admit the failure mode > is an assertion failure that's easy to fix. But also consider that > the unit defining main() might be written in C. > > Josh > Josh, The requirement is that a single call to a static function is made as the first line of executable C++ code, in order to define the boundary between static initialization, and run-time. Usually this is in main(), but it can be elsewhere. Only a single function call is required, even if every single class in the executable load module inherits from it. I also didn't point out that there is zero performance hit in a release build, as asserts become a noop and the empty base class constructor is inlined out. Also, no vtable is introduced, and a total of only one bool of memory is consumed for the entire program, independent of how many classes use it. I believe the time saved by avoiding debugging static initialization order problems greatly outweighs the cost of adding a single function call to the program. The philosophy is the same as for boost::noncopyable, express your intent to the compiler/program, so you don't accidentally use a class in an unintended way. It is preferable to catch these kinds of problems earlier, rather than later. This class is designed to be of general utility, and I intend to make it standard practice for my applications, just how I already inherit from noncopyable as standard practice, unless I specifically need otherwise. Thank you, Ben Robinson

1 0

Re: [boost] Is there any interest in a base class which prevents construction during the static initialization phase?
by Ben Robinson 14 Jun '11

14 Jun '11

> > On Sun, Jun 12, 2011 at 4:51 PM, Ben Robinson <icaretaker(a)gmail.com> > wrote: > > Hello, > > > > Because the order of static initialization is undefined, numerous > difficult > > to detect problems can arise when multiple objects are initialized during > > the static initialization phase. ?This base class would guarantee that a > > class will never be unintentionally constructed during static > > initialization. ?This is the same philosophy behind how > boost::noncopyable > > guarantees that a class will never be unintentionally copied. > > What you probably mean is "initialization of objects with static > storage duration", which can be static and dynamic. All such objects > are first zero initialized. Then the ones that are initialized with a > constant expression are initialized, and this concludes the static > initialization phase. Then the dynamic initialization phase follows. > > Only the dynamic initialization phase can cause problems. > > However, the dynamic initialization phase can cause problems with any > object that uses it. That is, whether or not a compile error is > induced should only depend on whether or not a given object with > static storage duration is initialized during the dynamic > initialization phase. Deriving or not deriving from > nonstaticinitializable doesn't seem to have anything to do with this. > > Don't get me wrong, I agree that using objects with static storage > duration that are initialized dynamically is the source of many > problems, but it seems like it makes more sense to detect and report > such initialization with a lint-type utility rather than relying on a > programmer to derive from a type. > > Emil Dotchevski > Reverge Studios, Inc. > http://www.revergestudios.com/reblog/index.php?n=ReCode > > Emil, > Emil, Thank you for your feedback. You are correct in that I am referring to objects with static storage duration that are initialized dynamically. No compile error is generated if you unintentionally create an object this way, when you inherit from the proposed base class. Instead, the program will assert before nonstaticinitializable::enable_initialization() is called (which should be called as the first line of C++ code), usually in main(). Detecting this unintended behavior via an assert() before main(), is greatly preferred to debugging undefined behavior. In this way, both noncopyable, and nonstaticinitializable communicate intent to the compiler/program, which can then prevents unintended behavior, an objectively desirable quality. Lint like tools are always available, however I thought to detect this unintended behavior directly in the language, without requiring an additional platform specific tool. Since this base class prevents creating an "object with static storage duration that is initialized dynamically", I would welcome improved naming suggestions. :) Thank you, Ben Robinson

1 0

[heap][formal review]
by Thomas Klimpel 13 Jun '11

13 Jun '11

Hi, this is my actual review of Boost.Heap. I took part in this review, because I was interested in the results of Boost.Heap for my old heap test/benchmark (related to the fast marching algorithm). So I decided that trying to use Boost.Heap with the old test code was a good experiment for a review, allowing me to see how helpful the documentation is, how easy it is to use the heaps and how well they perform. - The documentation is easy to read and helpful with respect to the questions it tries to address. The main question it doesn't try to address is how to make effective use of Boost.Heap, i.e. which heap to use for which application and how to use it optimally. - Boost.Heap is easy to use, at least in principle. -- One inconvenience for me was the use of max-heaps instead of min-heaps. Well, one could argue that a priority_queue should return the elements with the highest priority first (but as Wikipedia says: "some conventions consider lower priorities to be higher"), and heap-sort uses a max-heap. Since these are the two application where stl uses a heap, it's clear why stl implements a max-heap. But the applications where it is beneficial to call increase or decrease directly normally use a min-heap. Now I have to call increase even so the key value actually has decreased... -- I was left a bit with the feeling that I hadn't made the most efficient use of Boost.Heap. For example, I quickly found out that calling update just with a handle (as I had implemented it first) was suboptimal for fibonacci_heap. -- The segmentation fault in pairing_heap was unexpected for me. Even more unexpected was Tim's response that it's actually expected. So I tried to inform me a bit. I found statements like "A pairing heaps is a type of heap data structure with relatively simple implementation and excellent practical amortized performance" and "Experimental studies indicate that pairing heaps actually outperform Fibonacci heaps", which are incompatible with pairing_heap segfaulting for a simple testcase (IMHO). My conclusion is that the statement "due to the recursive nature of this data structure, ... beware of stack overflows" is actually misleading. This implementation of pairing_heap actually has a known issue. As long as this issue is not fixed, the structure may be interesting for tests, but "production" use should be strongly discouraged. - The performance numbers for Boost.Heap were neither bad nor outstanding. -- The numbers for b_heap are not convincing -- The numbers for fibonacci_heap seem to be the best. -- The pairing_heap has a smaller compare count than fibonacci_heap, but actually performs worse than fibonacci_heap in this test. Considering statements like "Experimental studies indicate that pairing heaps actually outperform Fibonacci heaps", I wonder whether the implementation of pairing_heap could be improved so that it actually outperforms fibonacci_heap. -- The comparison with TStaticHeap and TSequentialHeap should be taken with a grain of salt. I had first just added fibonacci_heap to the test, which is a node based heap. The test case isn't very favorable for node based heaps. And for the other heaps, I used the same class template, so that .reserve isn't called (it doesn't exist for node based heaps), but the analog function is called for TStaticHeap. And the tuned TSequentialHeap uses "debatable"/"unusual" techniques. > What is your evaluation of the design? I guess it's OK. What makes me a bit nervous is the statement "The library is not targeted in any specific domain nor directly related to any specific libraries". A good interface often is the result from an abstraction over different applications. The other way (coming from the data structure/algorithm) risks bloating the interface with unnecessary functionality. For example, somebody asked during the review for "iteration over the heap in priority order". Is this really something that many applications requiring a heap will benefit from? I heavily doubt this. > What is your evaluation of the implementation? I haven't looked too deep into it, but I think it's OK. I'm not sure whether there isn't a bit too much code reuse and "one size fits all". Was it really possible to implement all the heaps in their optimal form with this approach? But I'm not expert enough to really judge this. I was a bit surprised how pairing_heap::merge_children was implemented (was it just a mistake?), but I don't believe that this is caused by the code reuse or the "one size fits all". It's possible that similar problem also exist in other functions, but that doesn't change the good overall impression. It's only natural that such problems are only brought up when the code is used by more people than just the initial author. > What is your evaluation of the documentation? The documentation is easy to read. It doesn't address the question how to make effective use of Boost.Heap, i.e. which heap to use for which application and how to use it optimally. One benefit of the library would be to educate the user about the different possibilities. An important thing here is worse case performance and amortized performance, why are different heaps needed at all, ... > What is your evaluation of the potential usefulness of the library? There are different use cases I can see: 1) You already have a heap in your software, but you want to see how good it performs with respect to what else is out there. 2) You need a heap as part of a more complex algorithm. 3) You need a priority queue for scheduling something. The library in its current form is actually really well suited for 1, because all the heaps have a very similar interface, which makes it easy to test many different heaps without much effort. The library is also quite useful for 2, even if it would be nice if the documentation would save me some of the required experimentation. I also fear that the uniform interface of the heaps sacrifices some optimality for some algorithms. - Take the fast marching algorithm as an example. I typically have one bulk with the arrival times and one bulk with the speeds. I'm not especially keen on having another bulk with "heap_t::handle_type", as that may double my memory consumption on a 64-bit system, if arrival times and speeds were of type float. - However, the alternative is giving up the uniform interface of the heaps, just for some very questionable savings for some special applications. Because for Dijkstra's algorithm, the memory consumption is dominated by the edges of the graph, so that I don't care about an additional array with "heap_t::handle_type" of the same size as the number of vertices of the graph. I have the impression that std::priority_queue is already sufficient for 3, so that Boost.Heap wouldn't be required for that use case. Overall, I think it is quite useful. > Did you try to use the library? With what compiler? > Did you have any problems? Yes, I used it. gcc-4.3.4 (cygwin), gcc-4.3.3 (win32), gcc-4.4.3 (ubuntu), gcc-4.5.2 (win32), MSVC-9, MSVC-10. There were some minor problems, but all the problems I actually reported have been fixed (except the unexpected segfault for pairing_heap). So may main problem was probably that I felt a bit left alone with respect to the question which heap to use and how to use it optimally. > How much effort did you put into your evaluation? > A glance? A quick reading? In-depth study? More effort than I had actually planed to spend, but I already knew from previous reviews that this would happen. I think I did a reasonably deep study from a user point of view. > Are you knowledgeable about the problem domain? Yes, at least from the user point of view. I have heard of binomial heaps, d_ary heaps and fibonacci heaps before. I didn't knew about b_heap, pairing_heap and skew_heap, but I knew that there are many different heap variants out there. For example I knew about the sequential heap described in "Fast Priority Queues for Cached Memory" by P. Sanders (which doesn't mean that TSequentialHeap is identical to the sequential heap described in that paper, but it isn't too different either). > Do you think the library should be accepted as a Boost library? No, the library should not be accepted unless - The current review either magically goes back on track and at least 3 other persons also submit a proper review, or another (mini?) review with proper participation is held later. - Either pairing_heap is fixed, or non-experimental (="production") use is strongly discouraged in the documentation. - Either a convincing example where b_heap outperforms the other heaps is presented, or it's use should be discouraged in the documentation. - The documentation says a bit more about the different heaps and their trade offs (amortized time <-> worst case), and generally tries to give recommendation to the user which heap will likely best fit his application, and which settings he should try (for example something like that arity<4> is a good compromise for a d_ary heap between cache locality and compare count). I used the negative form of "Yes, the library should be accepted under the following conditions", because I'm unhappy with how the review went. The announcement was sent out too late, without stating the dates of the review, much of the initial discussion was about the code collaborator tool, but I haven't seen any "real" review, despite that fact that there seems to be interest in the library. There were some discussions on Code Collaborator, and the tool was actually not bad in pointing to concrete problems in the actual code. Tim quickly addressed these, but a good review would have some discussions and actual opinions and suggestions. It is also unclear to me how well Boost.Heap performs with respect to boost/graph/detail/d_ary_heap.hpp. I could have tried to also include this heap in my heap test/benchmark, but as the review seemed to have silently died already, I wasn't motivated enough for doing this. Regards, Thomas

4 4

clang type traits
by Bryce Lelbach 13 Jun '11

13 Jun '11

John, Clang has supported GCC style type trait intrinsics (__is_pod, etc) for awhile. The <boost/type_traits/intrinsics.hpp> header doesn't detect this. May I fix this? -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

4 7

[Heaps] Review
by Phil Endecott 13 Jun '11

13 Jun '11

Dear All, Here is my review of the proposed Heaps library. What is your evaluation of the design? Satisfactory. If possible, I think it would be good to provide the new heaps with interfaces as close as possible to the std:: heap, i.e. as algorithms (push, pop, etc.) over arbitrary containers or ranges, as well as the current containers. This would allow: (a) Existing code using std::push|pop_heap could be converted to use one of the alternative designs with just some search-and-replace; (b) Portions of a container could be managed as heaps, with other portions unordered, sorted, etc.; (c) Heaps over raw memory (e.g. memory-mapped files) would be possible. (I posted this suggestion in an email a few days ago but haven't had any replies. It is possible that there is something that I have overlooked that makes this impractical.) What is your evaluation of the implementation? I found one bug, which Tim was able to fix quickly. Although I've not looked in detail at the code, what I have seen appears satisfactory. It does seem to lack either comments or much else in the way of internals-documentation, though. I am concerned about the performance of the B Heap. It seems to execute twice as many instructions as a "traditional" heap, and it's hard to concoct a situation where its improved memory access pattern makes up for that. Some more investigation of this is needed. My past exposure to "B" structures has mainly seen them used for on-disk data. How do cache, main memory, and disk access times compare these days? It would be great to see some real-application benchmarking of this. What is your evaluation of the documentation? It needs some expansion, but it's on the right lines. It suffers, from too many, commas. A table indicating the features and complexity of those features for each heap would be useful at the start. What is your evaluation of the potential usefulness of the library? Personally I currently have no need for those heaps with improved merge performance, and the B-heap doesn't help me because it is slower than the std:: heap. Despite this, I believe it is useful enough to warrant inclusion in Boost. Did you try to use the library? With what compiler? Did you have any problems? Yes, with gcc 4.* on Linux; one bug which Tim says has been fixed. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A few hours. Are you knowledgeable about the problem domain? Not especially, though I have used std heaps in a couple of applications. And finally, every review should answer this question: Do you think the library should be accepted as a Boost library? Yes. Regards, Phil.

2 1

[review] [heap] ending today
by Andrew Sutton 13 Jun '11

13 Jun '11

Today is the last day of the review of Tim Blechmann's Heap library. The review had been extended until today because of an unavoidably late announcement. If you commented on the library, please submit a formal review (i.e., a Yes/No vote). There have been a number of people expressing comments or asking questions, but not voting. I will be preparing a summary of the review over the course of the week so there is a little extra leeway if you absolutely cannot submit a formal review today. I would like to thank all of the reviewers who have have taken time to inspect and comment on Tim's work. I would also like to thank Tim for submitting his library for review and patiently answering our questions and addressing our comments. Andrew

1 0

[Heaps] benchmarks
by Phil Endecott 13 Jun '11

13 Jun '11

Dear All, I have done some quick benchmarks; the code can be found here: http://chezphil.org/tmp/bench.tgz This is a "work queue", i.e. it's a queue of boost::function<void(void)> "work items" with float priorities. It's similar to a real application with fast (burst) fill and gradual drain; the pattern here is 10 pushes and 1 pop, repeated until all the work has been added, and then all of the work is popped in sequence. The priorities are essentially random, and there are 100 000 items in total. Currently my real application uses a std::multimap. I've compared that with a std::vector using std::push|pop_heap, std::priority_queue using std::vector and std::deque, and the proposed heap::priority_queue and heap::b_heap. The columns below are median-of-3 runtimes in seconds for: 1. 50 runs on a 32-bit 3 GHz AMD Athlon II Linux system, using g++ 4.4.4 -O4. 2. 10 runs on a 32-bit 1.2 GHz VIA C7-M Linux syste, using g++4.4.2 -O4. 3. 5 runs on a 1.2 GHz ARMv5 Linux system, using g++ 4.4.2 -O4. std::multimap 3.20 3.69 3.37 std::vector + std::push|pop_heap 2.35 3.36 2.71 std::priority_queue<vector> 2.58 3.48 2.84 std::priority_queue<deque> 4.27 5.77 3.72 heap::priority_queue 2.49 3.37 2.74 heap::b_heap 5.14 7.62 5.82 I was unable to try the proposed d_ary_heap because I couldn't find a working syntax for the arity template parameter - any ideas anyone? The 3 implementations based on std::vector perform similarly, as expected. I'm a bit surprised that my one is fastest, but the difference is small. Also as expected the version using multimap is slower, though maybe not by as much as I had expected. I was expecting the b_heap to be faster, but it is not; it is substantially slower. What is going on there? Does it all come down to size of data, cache size, etc? Ideally, an "improved" implementation like this would be able to fall back to the naive implementation in cases where it does not function any better. Or maybe I'm using it wrongly. My understanding is that the fibonacci, binomial and other heaps only improve things when other operations e.g. merging are needed - is that correct? Regards, Phil.

4 11

Is there any interest in a base class which prevents construction during the static initialization phase?
by Ben Robinson 13 Jun '11

13 Jun '11

Hello, Because the order of static initialization is undefined, numerous difficult to detect problems can arise when multiple objects are initialized during the static initialization phase. This base class would guarantee that a class will never be unintentionally constructed during static initialization. This is the same philosophy behind how boost::noncopyable guarantees that a class will never be unintentionally copied. Usage would appear as follows: #include <submission/nonstaticinitializable.hpp> #include <boost/noncopyable.hpp> namespace { class Foo : private submission::nonstaticinitializable, private boost::noncopyable { public: Foo() : nonstaticinitializable() {} }; // Foo } // unnamed namespace Foo fooThatWillAssert; // This instance asserts during static initialization int main() { nonstaticinitializable::enable_initialization(); // Indicates that static initialization is complete. Foo foo; // This instance initializes successfully after static initialization. return 0; } // main What does Boost think about submission::nonstaticinitializable (I chose the name to mirror noncopyable)? Thank you, Ben Robinson

3 2

Even more Boostcon videos
by Marshall Clow 12 Jun '11

12 Jun '11

Bojan (Thursday): http://blip.tv/boostcon/fast-numerical-computation-in-c-expression-template… Joel (Thursday): http://blip.tv/boostcon/practical-simd-acceleration-with-boost-simd-5261117 Matt (Thursday): http://blip.tv/boostcon/boost-generic-concepts-without-concepts-5262126 I will post a couple more over the weekend, then be on holiday for a couple weeks, then post the rest in early July. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

6 6

Last of the first batch of Boostcon videos
by Marshall Clow 12 Jun '11

12 Jun '11

Gordon (Thursday): http://blip.tv/boostcon/introducing-mpl-graph-5262812 Bryce (Friday): http://blip.tv/boostcon/ast-construction-with-the-universal-tree-5266608 I am looking into why Bartoz' Haskell preso is not showing up. You can download the mp4 directly here: http://blip.tv/file/get/Boostcon-HaskellThePseudocodeLanguageForCTemplateMe… but the conversion to H.264 seems to time out (I've tried several times) I'll be contacting blip.tv about this in the morning. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[release][phoenix] Permission to merge to release
by Thomas Heller 12 Jun '11

12 Jun '11

Hi, I would like to ask for permission of merging to changesets i commited during the last week to trunk. The risks should be very minimal. The first change fixes a bug with MSVC 7.1 not being able to parse nested function types correctly. Thus it needs some help. The second change is a small fix to allow non-const and const references as function paramaters in bound functions. Both changes fix bugs that were only realised this week. The affected Changesets are: http://svn.boost.org/trac/boost/changeset/72485 and http://svn.boost.org/trac/boost/changeset/72548 I hope these changes get merged to release. Thanks, Thomas

2 1

[phoenix] Bind member functions with non-const reference parameters
by Sergiu Dotenco 12 Jun '11

12 Jun '11

Using phoenix bind with member functions that have non-const reference parameters results in compile errors. However, free functions with similar signature seem to be supported. This behavior is inconsistent, especially compared to existing bind incarnations. For instance: #include <boost/bind.hpp> #include <boost/lambda/bind.hpp> #include <boost/phoenix/phoenix.hpp> void foo(int&) { } struct Foo { void bar(int&) { } }; int main() { using boost::phoenix::placeholders::arg1; int i = 0; Foo f; boost::phoenix::bind(foo, arg1)(i); // works boost::lambda::bind(&Foo::bar, &f, boost::lambda::_1)(i); // works boost::bind(&Foo::bar, &f, _1)(i); // works boost::phoenix::bind(&Foo::bar, &f, arg1)(i); // compile error } Tested with VC10 and boost trunk (r72541).

2 1

[fusion] Serialization support
by Christian Holmquist 12 Jun '11

12 Jun '11

Hey all, Unless I'm mistaken, there's no support for serializing fusion sequences using Boost.Serialization. I had an hour over at work today and hacked together something.. It can be accessed from here: git@github.com:cholmquist/fusion-serialize.git I only tested it on MSVC-2005, didn't write any docs, but if there's interest I could do the additional work.. Unless there's something fundamentally flawed with my implementation.. I do wonder why this hasn't been added previously (?). Cheers, Christian

2 1

Re: [boost] Is Boost interested in the Boost-based Base64 library
by Denis Shevchenko 11 Jun '11

11 Jun '11

2011/6/10 Robert Ramey <ramey(a)rrsd.com> > I think you'd find it interesting to see how the serialization library does > it. > ../boost/archive/iterators/base64_from_binary > ../boost/archive/iterators/binary_from_base64 Yes, Robert. :-) I took theese iterators (and 'transform_width') and wrap them in one simple and ready-to-use solution. Simple and ready-to-use even for novices. I need a such solution, for this common task. And I definetly know many developers looking for such solution. Solution they can use immediately, without long studying the documentation. Just few lines of code: int main() { std::string text = "TEXT"; std::string encoded = boost::base64().encode( text ); std::string text_again = boost::base64().decode< std::string >( encoded ); } You think such (or similar) solution is not needed for Boost? Well, probably it is not needed, but I think it's useful. If not - I apologize for troubling. - Denis

4 5

Fwd: [Boost C++ Libraries] #4922: memory leak in boost::iostreams::detail::chain_impl::~chain_impl()
by Виктор Шугаев 11 Jun '11

11 Jun '11

Hi, more than a half year ago I found memory leak in boost.iostreams library. I wrote a patch and created a ticket (#4922). But it seems that nobody mantains this library. It is critical for my work. -- Thanks in advance, Victor -------- Исходное сообщение -------- Тема: [Boost C++ Libraries] #4922: memory leak in boost::iostreams::detail::chain_impl::~chain_impl() Дата: Thu, 02 Dec 2010 12:25:38 -0000 От: Boost C++ Libraries <noreply(a)lists.boost.org> Копия: boost-bugs(a)lists.boost.org #4922: memory leak in boost::iostreams::detail::chain_impl::~chain_impl() --------------------------------------+------------------------------------- Reporter: victor.shugaev@… | Owner: turkanis Type: Patches | Status: new Milestone: To Be Determined | Component: iostreams Version: Boost 1.45.0 | Severity: Problem Keywords: | --------------------------------------+------------------------------------- It appears that there are some cases when the ''chain_impl::close()'' ('''boost/iostreams/chain.hpp''') throws an exception. If it is invoked from {{{ ~chain_impl() { try { close(); reset(); } catch (...) { } } }}} the following ''reset()'' method won't be invoked and it results in memory leak because of there is a ''delete buf;'' invokation in the ''reset()''. Patch file is attached. Also I have managed to produce such a situation (example is attached). Below shows that the ''gzip_decompressor'' was constructed 4 times (1 time by default constructor and 3 times by copy constructor), but destroyed only 3 times. Destructor for object at 0x4e46b98 wasn't invoked. ---- $ valgrind ./leak_example[[BR]] ==18153== Memcheck, a memory error detector[[BR]] ==18153== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.[[BR]] ==18153== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info[[BR]] ==18153== Command: ./leak_example[[BR]] ==18153==[[BR]] '''gzip_decompressor has been constructed at: 0x7ff0007c0[[BR]] gzip_decompressor has been copy constructed from: 0x7ff0007c0 at: 0x7ff000450[[BR]] gzip_decompressor has been copy constructed from: 0x7ff000450 at: 0x7ff000320[[BR]] gzip_decompressor has been copy constructed from: 0x7ff000320 at: 0x4e46b98[[BR]] gzip_decompressor has been destroyed at: 0x7ff000320[[BR]] gzip_decompressor has been destroyed at: 0x7ff000450[[BR]] gzip_decompressor has been destroyed at: 0x7ff0007c0'''[[BR]] ==18153==[[BR]] ==18153== HEAP SUMMARY:[[BR]] ==18153== in use at exit: 51,493 bytes in 13 blocks[[BR]] ==18153== total heap usage: 28 allocs, 15 frees, 69,665 bytes allocated[[BR]] ==18153==[[BR]] ==18153== LEAK SUMMARY:[[BR]] ==18153== '''definitely lost: 216 bytes in 1 blocks'''[[BR]] ==18153== indirectly lost: 51,277 bytes in 12 blocks[[BR]] ==18153== possibly lost: 0 bytes in 0 blocks[[BR]] ==18153== still reachable: 0 bytes in 0 blocks[[BR]] ==18153== suppressed: 0 bytes in 0 blocks[[BR]] ==18153== Rerun with --leak-check=full to see details of leaked memory[[BR]] ==18153==[[BR]] ==18153== For counts of detected and suppressed errors, rerun with: -v[[BR]] ==18153== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)[[BR]] -- Ticket URL:<https://svn.boost.org/trac/boost/ticket/4922> Boost C++ Libraries<http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.

2 1

[thread] Fix compilation with GCC-MinGW64 for 1.47.0?
by Mikko Vainio 11 Jun '11

11 Jun '11

Hi, The trunk version of Boost.Thread compiles with GCC-MinGW64 but the release branch does not[1]. Is the trunk version going to be merged to release for 1.47.0? Cheers, Mikko [1] Here's the error log: gcc.compile.c++ bin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi/win32/thread.o "/usr/bin/x86_64-w64-mingw32-g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -Wno-long-long -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi/win32/thread.o" "libs/thread/src/win32/thread.cpp" In file included from ./boost/thread/win32/basic_timed_mutex.hpp:14:0, from ./boost/thread/win32/mutex.hpp:8, from ./boost/thread/mutex.hpp:14, from ./boost/thread/detail/thread.hpp:13, from ./boost/thread/thread.hpp:22, from libs/thread/src/win32/thread.cpp:10: ./boost/thread/win32/interlocked_read.hpp: In function 'void* boost::detail::interlocked_read_acquire(void* volatile*)': ./boost/thread/win32/interlocked_read.hpp:63:20: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ./boost/thread/win32/interlocked_read.hpp: In function 'void boost::detail::interlocked_write_release(void* volatile*, void*)': ./boost/thread/win32/interlocked_read.hpp:71:13: error: cast from 'void*' to 'long int' loses precision [-fpermissive] ./boost/thread/win32/interlocked_read.hpp:71:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] In file included from ./boost/thread/win32/mutex.hpp:8:0, from ./boost/thread/mutex.hpp:14, from ./boost/thread/detail/thread.hpp:13, from ./boost/thread/thread.hpp:22, from libs/thread/src/win32/thread.cpp:10: ./boost/thread/win32/basic_timed_mutex.hpp: In member function 'void boost::detail::basic_timed_mutex::destroy()': ./boost/thread/win32/basic_timed_mutex.hpp:46:39: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] In file included from ./boost/thread/win32/mutex.hpp:8:0, from ./boost/thread/mutex.hpp:14, from ./boost/thread/detail/thread.hpp:13, from ./boost/thread/thread.hpp:22, from libs/thread/src/win32/thread.cpp:10: ./boost/thread/win32/basic_timed_mutex.hpp: In member function 'void* boost::detail::basic_timed_mutex::get_event()': ./boost/thread/win32/basic_timed_mutex.hpp:183:43: error: cast from 'void*' to 'long int' loses precision [-fpermissive] ./boost/thread/win32/basic_timed_mutex.hpp:183:43: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] In file included from ./boost/thread/shared_mutex.hpp:14:0, from ./boost/thread/detail/thread_group.hpp:9, from ./boost/thread/thread.hpp:24, from libs/thread/src/win32/thread.cpp:10: ./boost/thread/win32/shared_mutex.hpp: In member function 'T boost::shared_mutex::interlocked_compare_exchange(T*, T, T) [with T = boost::shared_mutex::state_data]': ./boost/thread/win32/shared_mutex.hpp:110:103: instantiated from here ./boost/thread/win32/shared_mutex.hpp:50:99: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] ./boost/thread/win32/shared_mutex.hpp:50:99: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] ./boost/thread/win32/shared_mutex.hpp:51:52: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] ./boost/thread/win32/shared_mutex.hpp:51:52: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] ...failed gcc.compile.c++ bin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi/win32/thread.o... ...skipped <pbin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi>libboost_thread_win32-mgw46-mt-1_47.a(clean) for lack of <pbin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi>win32/thread.o... ...skipped <pbin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi>libboost_thread_win32-mgw46-mt-1_47.a for lack of <pbin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi>win32/thread.o... ...skipped <pstage/lib>libboost_thread_win32-mgw46-mt-1_47.a for lack of <pbin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi>libboost_thread_win32-mgw46-mt-1_47.a... ...failed updating 1 target...

1 0

enable_shared_from_this::weak_from_this() request
by Marat Abrarov 11 Jun '11

11 Jun '11

Hi, boost users and experts. I often use boost::enable_shared_from_this. I know - it contains boost::weak_ptr, which is initiated in the details of boost::shared_ptr's constructor. Also sometimes I need function weak_from_this() at the classes derived from boost::enable_shared_from_this. I currently use something like: ... class my_class : public boost::enable_shared_from_this<my_class> , private boost::noncopyable { ...somewhere in my_class details... private: typedef my_class this_type; typedef boost::weak_ptr<this_type> this_type_weak_ptr; this_type_weak_ptr weak_from_this() { return this_type_weak_ptr(shared_from_this()); } }; // my_class ... But as I know restoring shared_ptr from weak_ptr (done in shared_from_this()) is quite expensive. So my_class::weak_from_this() does unnecessary work instead of just copy internal weak_ptr stored in enable_shared_from_this. So the question is - why there is no weak_from_this() member function in boost::enable_shared_from_this class? May be it would be useful to add such member function? Regards, Marat Abrarov.

1 0

[heap] A few questions
by Andrew Hundt 10 Jun '11

10 Jun '11

I was looking through the Boost.Heap documentation, and I came up with a couple questions: 1) Is it possible to iterate through the heap in order of priority with an iterator? 2) What advantages to the increase() and decrease() functions provide? I also have a few suggestions for improving the documentation: In http://tim.klingt.org/boost_heap/heap/concepts.html the note: boost.heap implements priority queues as max-heaps. While many textbooks and papers are formulated for min-heaps. Using max-heaps is consistent with the STL heap functions, though. would be better written as: boost.heap implements priority queues as max-heaps to be consistent with the STL heap functions. This is in contrast with the typical textbook design, which uses min-heaps. http://tim.klingt.org/boost_heap/heap/data_structures.html Can you provide runtime complexity constraints for each of these data structures? Particularly if the mutable version has different performance from the standard version of each. spelling: For a low arity, the h[e]ight of the heap is larger improved wording: In analogy to d-ary heaps, boost-heaps also provides an mutable version at the cost of an indirection. would be better as: The b_heap_mutable<http://tim.klingt.org/boost_heap/boost/heap/d_ary_heap_mutable.html> class stores the values inside a std::list in order to achieve mutability. You mentioned: | please note, that you *have* to call update before modifying any other node. This should be made more explicit in the documentation Overall this library looks extremely useful. Good work! Cheers! Andrew Hundt

4 7

[Serialization] serialize from and to an already instantiated object.
by nico 10 Jun '11

10 Jun '11

Hello. I've already posted this topic in the boost-user mailing list, but no reply: maybe this boost list is more active... ? Anyway: I use boost.serialization to perform save and load to files. If a class is serializable through the boost mechanism, I'd like to easily add the "savable" feature (through serialization and boost archives). Here how I do, and then I've got 2 questions. I don't post all the #include statements. Let's have a serializable class (I only use text archive for this example) ---------MyClass.h--------- class MyClass { friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version); int data_; public: MyClass(); virtual ~MyClass(); }; BOOST_CLASS_EXPORT_KEY(MyClass) ---------MyClass.cpp--------- MyClass::MyClass() : data_(123) {} MyClass::~MyClass() {} template<class Archive> void MyClass::serialize(Archive & ar, const unsigned int version) { ar & data_; } // instanciate the serialize function for text archives #include "boost/archive/text_iarchive.hpp" #include "boost/archive/text_oarchive.hpp" template void MyClass::serialize(boost::archive::text_iarchive & ar, const unsigned int version); template void MyClass::serialize(boost::archive::text_oarchive & ar, const unsigned int version); BOOST_CLASS_EXPORT_IMPLEMENT(MyClass) --------- Now I define a FileSavable class. Its purpose is to add the "save-to-file" feature to a class that can be serialized in a text archive, making the latter inherting from FileSavable, and adding a line in its serialize function, I write it below). ---------FileSavable.h--------- class FileSavable { friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version); public: virtual ~FileSavable() {} void SaveToFile(std::string path); void LoadFromFile(std::string path); }; BOOST_CLASS_EXPORT_KEY(FileSavable) ---------FileSavable.cpp--------- template<class Archive> void FileSavable::serialize(Archive & ar, const unsigned int version) {} void FileSavable::SaveToFile(std::string path) { std::ofstream ofs(path.c_str()); assert(ofs.good()); boost::archive::text_oarchive oa(ofs); oa & this; } void FileSavable::LoadFromFile(std::string path) { std::ifstream ifs(path.c_str()); assert(ifs.good()); boost::archive::text_iarchive ia(ifs); FileSavable* p; ia & p; *this = *p; delete p; } // instanciate the serialize function for text archives #include "boost/archive/text_iarchive.hpp" #include "boost/archive/text_oarchive.hpp" template void FileSavable::serialize(boost::archive::text_iarchive & ar, const unsigned int version); template void FileSavable::serialize(boost::archive::text_oarchive & ar, const unsigned int version); BOOST_CLASS_EXPORT_IMPLEMENT(FileSavable) ---------Modification to MyClass--------- It now inherit from FileSavable: class MyClass : public FileSavable The serialize function call the base class: template<class Archive> void MyClass::serialize(Archive & ar, const unsigned int version) { ar & boost::serialization::base_object<FileSavable>(*this); ar & data_; } --------- Thanks if you read me until here, now my questions: 1) I don't care the FileSavable part of MyClass being serialized, but if I don't call it with boost::serialization::base_object, I have a runtime error: terminate called after throwing an instance of 'boost::archive::archive_exception' what(): unregistered void cast 7MyClass<-11FileSavable Do you see a way to avoid having to add this line in MyClass? Ideally, just having to inheriting from FileSavable would be great: a simple way to add a feature. 2) As you can see, my LoadFromFile function first creates a new MyClass object in p, by de-serializing an archive, and then copies this newly created object into "*this", and finally deletes the object created by the archive d-eserialization. I didn't find a way to avoid this temporary and de-serialize directly in this. Moreover, my solution is not exception-safe, but I didn't manage to de-serialize in a temporary auto_ptr nor boost::shared_ptr. Thanks in advance for replies. Nicolas.

3 3

[multi_array]inner_product interest?
by Larry Evans 10 Jun '11

10 Jun '11

Attached is code to calculate the inner product of 2 multi_arrays. As indicated in comments, the code was adapted from the Budd book. It may be faster than doing subscripting to get the array elements; however, I've done no benchmarks, but I'd guess it would be faster since there's no calls to subscripting operators. Instead, there's just one div call and 3 multiplications per element of the result array. The .txt attachment shows relevant quotes from the book and reasons why changes were made to the book's code to accommodate multi_array's different storage orders. I've not done too much testing, but did do a simple test for 2 by 2 arrays whose output seems correct. Any interest? -regards, Larry

1 1

Re: [boost] Is Boost interested in the Boost-based Base64 library
by Denis Shevchenko 10 Jun '11

10 Jun '11

> Hmmm - so you are proposing that something like the following header > be added to boost? > > ... Yes, Robert, something like this. > a) where in the directory/namespace would this be? boost, boost/utility, or? For example, in boost/base64 directory and in boost namespace. I think it CAN be in boost namespace. So we have boost/base64 directory with docs, examples and base64.hpp file. In main boost directory will be file with same name base64.hpp with: #include <boost/base64/base64.hpp> > c) All this for one small special purpose function? Yes, Robert, for one small, concrete and frequent task. > d) How is a user going to find this pair of functions in the boost libraries. As well as he going to find boost::mem_fn, for example... :-) > e) As soon as someone puts this in, imediately some else will ask - great > but it needs a parameter to so I can change the line width. Then someone > asks for someother tweak. This is the result of making a "simple solution". > It's easy enough to make a simple solution - it's very hard to keep it simple. I understand you. My solution is simple and will be simple. Without "line width", special formatting, etc. Base64 encoding/decoding, nothing else. - Denis

1 0

Re: [boost] Is Boost interested in the Boost-based Base64 library
by Sean Chittenden 09 Jun '11

09 Jun '11

I'm assuming folks have looked at using: > http://code.google.com/p/stringencoders/ Pretty simple API: > char buf[100]; > char result[10]; > char endian[] = {(char)0, (char)0, (char)1}; > int d = modp_b64_encode(buf, endian, 3); And very fast: > http://code.google.com/p/stringencoders/#Why With some neat, very platform specific tricks: > http://code.google.com/p/stringencoders/#How_It_Works Don't get me wrong, I'd definitely like to see Boost have something because that extreme of performance isn't always necessary, but FYI for those interested in the discussion. -sc -- Sean Chittenden sean(a)chittenden.org

1 0

Re: [boost] [Boost-users] More boostcon videos
by Marshall Clow 09 Jun '11

09 Jun '11

On Jun 9, 2011, at 9:05 AM, Ovanes Markarian wrote: > On Thu, Jun 9, 2011 at 5:53 PM, Marshall Clow <mclow.lists(a)gmail.com> wrote: > Bartoz (Tuesday): > http://blip.tv/boostcon/haskell-the-pseudocode-language-for-c-template-meta… > > Tony (Wednesday): > http://blip.tv/boostcon/lockfree-programming-part-2-data-structures-5258064 > > Cliff (Wednesday); > http://blip.tv/boostcon/design-journeys-with-skoot-a-peer-oriented-generic-… > > > I'm hoping to get about half of the videos up before I go on holidays next week. > > Hello Marshall, > > seems like both videos > http://blip.tv/boostcon/lockfree-programming-part-2-data-structures-5258064 > http://blip.tv/boostcon/design-journeys-with-skoot-a-peer-oriented-generic-… > > contain Cliff's presentation. D'oh! I fat-fingered the upload. New link for Tony's preso: http://blip.tv/boostcon/lockfree-programming-part-2-data-structures-5258642 -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[Accumulators + Signals2] Compilation error with GCC when both are used
by sguazt 09 Jun '11

09 Jun '11

Hello, It seems that Accumulators and Signals2 have problems to coexist. For instance, look at the following simple C++ program: --- [c++] --- #include <boost/accumulators/accumulators.hpp> #include <boost/accumulators/statistics/stats.hpp> #include <boost/accumulators/statistics/mean.hpp> #include <boost/signals2.hpp> int main() { } --- [/c++] --- If I compile it with GCC 4.6.0 (under Fedora Linux 15 x86_64): $ g++ -Wall -Wextra -pedantic -ansi -I,/boost-trunk -o boost_signals2_accumulators boost_signals2_accumulators.cpp I get the following errors: --- [error] --- In file included from ./boost-trunk/boost/signals2.hpp:20:0, from boost_signals2_accumulators.cpp:4: ./boost-trunk/boost/signals2/signal_type.hpp:29:2: error: #error This header requires BOOST_PARAMETER_MAX_ARITY to be defined as 7 or greater prior to including Boost.Parameter headers In file included from ./boost-trunk/boost/signals2.hpp:20:0, from boost_signals2_accumulators.cpp:4: ./boost-trunk/boost/signals2/signal_type.hpp:78:9: error: wrong number of template arguments (6, should be 5) ./boost-trunk/boost/parameter/parameters.hpp:714:8: error: provided for ‘template<class PS0, class PS1, class PS2, class PS3, class PS4> struct boost::parameter::parameters’ ./boost-trunk/boost/signals2/signal_type.hpp:83:9: error: ‘parameter_spec’ is not a class or namespace ./boost-trunk/boost/signals2/signal_type.hpp:83:29: error: expected unqualified-id before ‘<’ token ./boost-trunk/boost/signals2/signal_type.hpp:99:11: error: ‘args’ was not declared in this scope ./boost-trunk/boost/signals2/signal_type.hpp:105:9: error: template argument 1 is invalid ./boost-trunk/boost/signals2/signal_type.hpp:108:31: error: ‘args’ was not declared in this scope ./boost-trunk/boost/signals2/signal_type.hpp:108:67: error: template argument 1 is invalid ./boost-trunk/boost/signals2/signal_type.hpp:111:31: error: ‘args’ was not declared in this scope ./boost-trunk/boost/signals2/signal_type.hpp:111:94: error: template argument 1 is invalid ./boost-trunk/boost/signals2/signal_type.hpp:115:31: error: ‘args’ was not declared in this scope ./boost-trunk/boost/signals2/signal_type.hpp:115:97: error: template argument 1 is invalid ./boost-trunk/boost/signals2/signal_type.hpp:121:13: error: ‘args’ was not declared in this scope ./boost-trunk/boost/signals2/signal_type.hpp:124:11: error: template argument 1 is invalid ./boost-trunk/boost/signals2/signal_type.hpp:128:31: error: ‘args’ was not declared in this scope ./boost-trunk/boost/signals2/signal_type.hpp:128:69: error: template argument 1 is invalid --- [/error] --- I've tried both with last Boost devel version and Boost 1.46.0. Note, I have no problem if one of the two libraries are not used (e.g. if I comment either the first 3 #includes or the last one). Any idea? Thank you very much!! Best, -- Marco

3 3

[config][hp-ux] UTF-8 codecvt_facet.cpp failing on HP-UX
by Beman Dawes 09 Jun '11

09 Jun '11

There is a Filesystem bug report, 5048, that actually affects any library using ...\libs\detail\utf8_codecvt_facet.cpp The problem is line 255: #elif WCHAR_MAX > 0x10000 On HP-UX, WCHAR_MAX is defined like this: # if defined(_INCLUDE_STDCSOURCE_199901) # define WCHAR_MAX UINT_MAX /* max value of an unsigned integer */ # define WCHAR_MIN 0 # else # define WCHAR_MAX (wchar_t)UINT_MAX /* max value of an unsigned integer */ # define WCHAR_MIN (wchar_t)0 # endif An obvious fix is to add #define _INCLUDE_STDCSOURCE_199901 to ...\boost\config\platform\hpux.hpp, and that's been confirmed by the user who originated the bug report. I'm guessing that this fix doesn't work if the user includes <stdint.h> before <boost/config.hpp>, but can't think of anything better. Any objections to committing the change to ...\boost\config\platform\hpux.hpp? --Beman

2 2

[MPL] map size must not be > 19, sunCC vs. gcc
by Bartosz Marcinkiewicz 09 Jun '11

09 Jun '11

Hello, This is on Solaris 11 Express (gcc version 4.3.3, Sun C++ 5.11 SunOS_i386 2010/08/13). When boost::mpl::map<> has more than 19 entries Sun CC does not compile my code. G++ compiles it, even when there are more than 19 entries. [bma@sol11e ~/c++]$ CC -I ~/opt/include -o m3 mpl_map3.cpp && ./m3 "mpl_map3.cpp", line 80: Error: value is not a member of boost::mpl::next<int>. 1 Error(s) detected. [bma@sol11e ~/c++]$ g++ -I ~/opt/include -o m3 mpl_map3.cpp && ./m3 -> 1 -> 2 MPL map size: 20 Both compilers can handle boost::mpl::map with 19 entries. [bma@sol11e ~/c++]$ g++ -I ~/opt/include -o m3 mpl_map3.cpp && ./m3 -> 1 -> 2 MPL map size: 19 [bma@sol11e ~/c++]$ CC -I ~/opt/include -o m3 mpl_map3.cpp && ./m3 -> 1 -> 2 MPL map size: 19 I am attaching code. Is it compiler error in Sun Studio or error in code attached? Thank you for any help. Best regards, bm. -- Bartosz Marcinkiewicz tel. (+48) 516 034 243 e-mail: bma(a)epcon.pl EPCON Sp. z o.o. www.epcon.pl adres: 53-407 Wroclaw, ul. Gajowicka 114/116 tel. (+48) 71 361 75 55 ext. 36 fax (+48) 71 361 74 44

1 1

First Boostcon videos available....
by Marshall Clow 09 Jun '11

09 Jun '11

Keynote: http://blip.tv/boostcon/hans-boehm-threads-and-shared-variables-in-c-0x-key… Chris Kohloff (Monday): http://blip.tv/boostcon/thinking-asynchronously-designing-applications-with… Hartmut (Monday): http://blip.tv/boostcon/phoenix-v3-an-overview-5250984 -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

10 10

More Boostcon videos available
by Marshall Clow 08 Jun '11

08 Jun '11

Sumant (Mondau): http://blip.tv/boostcon/toward-native-xml-processing-using-multi-paradigm-d… Justin (Tuesday): http://blip.tv/boostcon/intel-s-c-software-transactional-memory-compiler-an… Robert Stewart (Tuesday): http://blip.tv/boostcon/spirit-qi-in-the-real-world-5254335 ( I'm not going to be able to keep up this pace, btw...... ) -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

2 1

Re: [boost] First Boostcon videos available....
by Ralf Globisch 08 Jun '11

08 Jun '11

Marschall, thank you so much! It's really cool for those of us who couldn't attend boostcon... >>> Jarrad Waterloo 06/08/11 3:34 PM >>> How do I download the videos? I don't see the download option like past boostcon videos. @Jared, if you use Firefox, there's a plugin called DownloadHelper that you can use to download the videos. On 6/7/2011 8:39 PM, Marshall Clow wrote: > Keynote: http://blip.tv/boostcon/hans-boehm-threads-and-shared-variables-in-c-0x-key… > Chris Kohloff (Monday): http://blip.tv/boostcon/thinking-asynchronously-designing-applications-with… > Hartmut (Monday): http://blip.tv/boostcon/phoenix-v3-an-overview-5250984 > > -- Marshall > > Marshall Clow Idio Software > > A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). > -- Yu Suzuki > > _______________________________________________ > Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

Re: [boost] First Boostcon videos available....
by Marat Abrarov 08 Jun '11

08 Jun '11

Marshall, > Keynote: http://blip.tv/boostcon/hans-boehm-threads-and-shared-variables-in-c-0x-key… > Chris Kohloff (Monday): http://blip.tv/boostcon/thinking-asynchronously-designing-applications-with- > boost-asio-5250947 > Hartmut (Monday): http://blip.tv/boostcon/phoenix-v3-an-overview-5250984 Long awaited videos! Why not youtube? blip.tv is rather slow (at least in Russia). Regards, Marat Abrarov.

3 2

[Heaps] Compiler error: ‘optional’ was not declared in this scope
by Phil Endecott 08 Jun '11

08 Jun '11

Dear All, I'm trying to do some simple tests with the proposed Heaps library, but I get a mountain of compiler errors that start like this: ./boost_heap-HEAD-449f378/boost/heap/priority_queue.hpp:32: error: ‘optional’ was not declared in this scope ./boost_heap-HEAD-449f378/boost/heap/priority_queue.hpp:32: error: template argument 1 is invalid ./boost_heap-HEAD-449f378/boost/heap/priority_queue.hpp:32: error: expected unqualified-id before ‘,’ token I thought this was probably due to me having a too-old boost installation, but I believe I'm now compiling with 1.46.1 and I get the same error (though I need to verify that my paths are all set correctly). Any ideas anyone? (I've arrived late to this review having been away, but I'd like to do some quick benchmarks if I have time.) Thanks, Phil.

3 5

Re: [boost] Gauging interest in new library re: multiscale/multigranular containers
by nathaniel＠tierblend.org 07 Jun '11

07 Jun '11

Thanks to the two comments (so far). I am happy to provide a more detailed discussion but thought it appropriate to keep my original posting shortish if possible. For a little backstory, although I have been working on code related to my original posting for a while, I decided to formally submit a "gauging interest" after some emails to Barry Smith, the head of the National Center for Ontological Research, who sent me a stack of research papers with new data structures and algorithms relevant to "multiscale" analysis. This gave me a range of functions or algorithms to implement on top of those I was already working on. There's going to be a conference on biomedical ontology in about six weeks' time, so I decided to assign myself the task of completing at least part of a library in preparation for that. NCOR seems to be working on a "partition theory" which takes a top-down approach to scale. I'll base my comments on "A Theory of Granular Partitions": http://ontology.buffalo.edu/smith/articles/partitions.pdf. Partitions are defined as collections of "cells" which can be nested, including one "maximal cell". For lack of a more elegant term, suppose a collection class is called cell_set, as in template<typename CELL_Type> class cell_set; If this class is to model the theory then any instance will need a "maximal cell" or "root" in which all others are contained, which could be autogenerated with a member function. Moreover, it needs a "subcell" relation and an "insert" function which probably would take an existing cell as parent to any new cell and that would default to the root. I think a variation on this class should allow multiply parents, but for now I'll assume along with the above paper that parenthood is unique. The paper also defines a "parthood" relation and "mereological product" such that c * c' represents the set of subcells shared by two cells (which given unique parenthood must be either c or c* or null). They define two notions of summation, one of which simply groups all subcells of c + c' into a set, and another which looks for the least cell actually defined in the partition that contains all of those subcells. I could mention further structures which they define (and which could be member or namespace-scoped functions), but you get the idea. As a practical tool, this construction seems to be used as a kind of sorting machine. In the simplest case, there is one class of "target objects" which are to be fit into the set of cells (they use the term "projection" for a cell "projecting" onto one or more of those objects). So cell_set then takes two type parameters as in template<typename CELL_Type, typename TARGET_Type> class cell_set; the idea being that any cell_set instance would have a "location" function which takes a TARGET_Type value or collection and "locates" it within a cell in cell_set (defaulting to root if nothing else works). Users would have to provide a boolean "fit" function testing whether a TARGET_Type object fits into a CELL_Type object. Scale can be defined on cell_set instances by assigning the largest scale to root and stipulating that subcells are smaller-scaled than parent cells. A default implementation could assign a scale 1 to root, define "depth" as the number of parent cells between a given cell and root, assign scale 0 to the "deepest" cell, and if D is the max depth assign scale to other cells c using 1 - depth(c)/D. More nuanced implementations could consider the number of different subcells which a cell contains, with the idea that cells with more "inner structure" should be assigned larger scale. Scale can also be used to filter cell_sets into more maximal or more minimal calls, providing a kind of granular query machine. Imagine, for example, that a store is building a database for inventory, which fits into a collection of nestable categories. Scalar filtering might come into play if the store wants to temporarily "reassign" products to new categories to prevent categories being listed on their website with too few products, or conversely if the store wants to spotlight categories for some sort of promotion but only ones with no subcategories. Now, personally, I find that parent uniqueness is too restrictive and does not really fit real-world situations (for the same reasons that single inheritance is problematic...). Easing this restriction makes cell_sets more complex in a number of ways. They end up being graphs rather than trees, with parenthood one edge-type among others. I'm not saying that "partition theory" is the last word on multiscale modeling; I think another useful class would be some sort of multi_graph<CELL_Type> which shares many features with cell_set but allows multiple parents and perhaps allows the maximal cell to be undefined. This latter class would be more "bottom up". Instead of introducing new subcells as partitions of existing cells, new cells would be constructed as "mergers" of existing cells. In addition, edge types could be classified based on whether c <> c' (for some link type <>) implies that c is a subcell of c' or that c and c' are both potential subcells of some parent. These differences give rise to different kind of "walks" or constraints on walks, e.g., only follow edges to parents, or to children, or to siblings. Of course, cell_set as I described could be considered a special case of this more general multi_graph structure, but if multi_graph is to inherit cell_set's features it should support the construction of a "sort machine" for one or more target types; that is, provided a user-defined function "fitting" objects "into" vertices in the multi_graph, it should provide location functions for single or collections of objects of the proper type(s). Scalarity and granularity functions would work much as described for cell_sets, although graph-theoretic measures such vertex degree can be used to refine scale quantification for cells. I am particularly interested in using multi_graphs so defined for modeling GUIs. I've read some interesting work by RedWhale software, in Palo Alto, concerning algorithms for matching data elements to UI controls, which they call "interactors". For example, numeric data field would be mapped to spinners, list boxes, edit fields, scrollers, radio buttons, etc., based on their range of allowed values. Assume that the links between data components and interactors are represented by a multigraphs, so that for one edge type <v>, c <v> c' implies that c is a data field and c' is an interactor type which will visually represent c in a GUI. Suppose moreover that c <s> c' implies that c and c' are both interactors but c' is a higher-scales control, such as a notebook or dialog box; and that c <c> c' implies that c and c' are data components with c contained inside c'. The visual clarity of a GUI can be analyzed by studying how these three edge types interact in the graph, and any patterns which emerge could be used to refine algorithms to automatically generate GUIs based on data models. This could be extended by also introducing user-generated-events and application tasks, such as saving updated data to disk, so that c <t> c' could mean that c is a event meaning that the user wants to perform task c' (e.g., save to disk). Finally, to respond to a couple of points raised. For argument's sake, suppose I develop a single cell_graph class which incorporates both the partition and multigraph functionality I've described. (Actually I'd probably want instead to do a small group of related classes rather than one monolith, but, again, this is for argument's sake). Certainly this could be implemented in terms of existing STL containers, but the choice of which container to use is affected by how the cell_graph itself is used. As far as I can tell, for optimal memory usage cell_graph should work on values rather than pointers, but the values should never be copied, if possible, so that pointers into the cell_graph remain valid indefinitely. On the other hand, there are occcasions when it is useful to use cell_graph more as a vector than as a list. I won't go into the precise memory layout I've been using because I have not worked out all the details yet, but I think the choice of something nonstandard is justified. Conversely, even if (say) cell_graph<CELL_Type, PROJECTION_Type> is implemented in terms of standard STL containers behind the scenes, there is enough extra functionality to implement that it makes sense to develop it as a separate library. There are actually several other type parameters which I have not mentioned (although they take defaults), so using "bare" vector or set would yield very unwieldy code; better to hide as much as possible behind typedefs, partial specializations, or inhertiance: template <typename VERTEX_Type, typename CONNECTOR_Type, typename NODE_WRAP_Type, typename NODE_SERVICER_Type> void TierBlend::Route_Matrix_Compiler <VERTEX_Type, CONNECTOR_Type, NODE_WRAP_Type, NODE_SERVICER_Type>::compile(NODE_SERVICER_Type* servicer) ... Stuff like this should be library code, not user code. Finally, there is no single meaning to "scale" or "granularity". A scale metric can be induced on a partition or "partition-graph" based solely on nesting (e.g. subcells inside parent cells) but in real world situations there is no reason why "sibling" cells should have the same scale. The point is merely that classes representing these structures should provide for a scale measure associated with cells, graph vertices, and/or subgraphs, and should be a possible constraint or characterization of edge types as well (e.g. it could be stipulated that c <> c' implies c < c' for edge type <> and parthood relation <). Similarly, "granularity" could be associated with a given filter, query, or operation which specifies a range of scales on which the operation is to be performed. Thanks again for the comments. ---------------------------------------- From: "Edward Diener" <eldiener(a)tropicsoft.com> Sent: Sunday, June 05, 2011 8:18 AM To: boost(a)lists.boost.org Subject: Re: [boost] Gauging interest in new library re: multiscale/multigranular containers On 6/4/2011 4:55 PM, nathaniel(a)tierblend.org wrote: > > Hi: I would like to submit a library which would allow functionality > related to scale and granularity to be performed on STL-like containers. > Until recently I was in a doctoral program specializing in the philosophy > of science, and I am especially interested in multiscale data modeling and > its applications to e.g. GUI design, code generation, decision procedures, > and DSL implementation. For example, one of my projects involves a DSL > implemented through multiscale graphs in lieu of conventional syntax trees. > I used to study at Buffalo, which houses the National Center for > Ontological Research -- headed by the quite broad-ranging scholar Barry > Smith -- and has done pioneering work in biomedical ontology and also in > ontological models related to complex or "vague" aggregative structures. > In these structures collections of objects of some base type T can be > defined as aggregates but with varying degrees of looseness or "individual > coherence"; and this aggregation can be iterated to produce multiscaled > structures which can be queried or represented at different granularities. > There are a number of analytic procedures which can be implemented on such > structures, some overlapping with graph theoretic or statistical methods. > These structures also possess alot of internal structure above and beyond > their underlying list of values, so they are suited to memory-optimized C++ > code rather than higher-level languages like Java. However, I am not aware > of generic libraries which really incorporate these kind of data structures > and their analysis in a systematic way, although I have come across > non-template libraries which implement some similar features. What I > propose is a library which could be used in a fashion similar to > std::vector or std::set but which support additional functions along the > lines of, e.g., building multigraphs out of T-type nodes; partitions of > T-sets with functions to define or measure e.g. intrapartition relevance; > defining (or extending) a scale metric on T-objects, T-sets, T-arrays, or > other "T- data structures" and using it for rescaling, scale-filter, and > other scale-related transformations; defining iterators or "walks" on > T-collections which take scale and granularity into account; etc. In a > number of cases the algorithms for these kinds of operations have been > described in theoretical form or even already implemented in languages like > Scheme. You generally need to define "scale" and "granularity" in mathematical terms for computer programmers, else you are just interesting scientists in our particular area. Also would it not be possible to create a class which consists of an STL container and some other objects which represent "scale" and "granularity" and add the necessary functionality to that class rather than attempting to re-engineer some STL container ? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

[review] Heaps
by Andrew Sutton 07 Jun '11

07 Jun '11

All, I'd like to announce the beginning of the review of the Heap library, written by Tim Blechmann, and resulting from Tim's 2010 Google Summer of Code project The library implements a number of different heaps (or priority queues) including, a binary heap, d-ary heap, binomial heap, fibonacci heap, pairing heap, and skew heap. The library also provides an adaptor to make heaps mutable, allowing a programmer to modify a value and update its position within the heap. The library also also supports stability, ensuring that elements pushed into a heap with the same priority are popped in the same order. The library is not targeted in any specific domain nor directly related to any specific libraries, but intended to be a collection of general purpose data structures (not unlike the Boost.Unordered library). The documentation and source code can be downloaded from here: Documentation: http://tim.klingt.org/boost_heap Code: http://tim.klingt.org/git?p=boost_heap.git;a=snapshot;h=HEAD;sf=tgz Unlike previous reviews, this review will be assisted by a code review application, Code Collaborator (by SmartBear). The product was tested during a BoostCon session, and we are eager to see how well it scales to a community review. You can use the link below to access and review the Heap library. http://demo.smartbear.com/boost/go?page=ReviewDisplay&reviewid=4 The application allows line-by-line comments of the submitted source code in addition to providing features for general defect and issue reporting. If you are interested in using this system, we will have to register you as a user of the site. You can request access by replying to this message. I'm still learning my way around the system, so there are bound to be some missteps along the way :) If you are not interested in using the system, then feel free to send email like any other review. Reviews of the library should address the following questions. What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally, every review should answer this question: Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Please note that some questions may be easier to answer in email than with the review tool. As always, reviews are important to the continued quality of the Boost C++ Libraries. Thank you in advance for your comments and contributions. Andrew PS. The review was slated to start on Sunday, but I was not able to make the announcement until today.

7 38

[type_traits] is_constructible, ... when decltype is supported?
by Vicente Botet 07 Jun '11

07 Jun '11

Hi, when decltype is supported (as it is the case for gcc 4.6.0) we can define the C++0x traits is_constructible, is_assignable and the ones that depend on them. These traits are really important to conform with some of the C++11 interfaces. Next follows one examples from the standard: template (*class... UTypes*) explicit tuple(UTypes&&... u) noexcept; 8 Requires: sizeof...(Types) == sizeof...(UTypes). is_constructible(*Ti, Ui&& *)::value is true for all i. 10 Remark: This constructor shall not participate in overload resolution unless each type in UTypes is implicitly convertible to its corresponding type in Types. In Boost there are some libraries as Boost.Array, Boost.Fusion tuple that defines these kind of constructors or assignments and that require that the template types must be constructible or assignable. The problem when these constructors/assignments don't use of SFINAE to avoid that these functions participate on overload resolution is that is_constructible or is_assignable will give false positive results as the expression could be valid, even if the definition doesn't compiles. I don't know if it is worth including these traits in Boost when the compiler supports decltype so we can start writing conforming interfaces, but at least it would be nice if the Boost libraries start using these standard traits when them are available. Any thoughts? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/type-traits-is-constructible-when-declty… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

[review] Heaps: Mergeable Heaps
by Andrew Sutton 07 Jun '11

07 Jun '11

Tim, I think you should define a MergeableHeap that describes heaps that can be merged in O(log n) (i.e., binomial, fibonacci, pairing, skew). Actually, the only heaps that don't satisfy this requirement are binary heaps, b-heaps and d-ary heaps (they all seem to be linear). This is similar to the the AdjacencyMatrix in the BGL. This poses a serious problem, however. The mutable priority queue wrapper implements merge() as, at best, a linear operation, meaning that no mutable priority queue could model the MergeableHeap concept. Andrew

4 13

[Review] Boost.Convert review decision
by Edward Diener 07 Jun '11

07 Jun '11

Because Vladimir Batov has expressed himself by saying that he does not want to continue to offer his Boost.Convert library as a library for Boost, I am respecting his decision and his library is NOT accepted into Boost. I am still going to reserve the right to do an analysis of the various viewpoints and offer some way forward for the Boost.Convert library, if Vladimir Batov wishes to pursue it, or for any other library which wishes to present a convert-like interface. I will post this analysis sometime later in the week. There is also still one person who had asked me personally to do a late review by the end of Wednesday, and if that person still wants to do so I would still appreciate his input. I would like to thank Vladimir Batov for offering the library to Boost and all those who did reviews or offer comments about the library even if they did not do an actual formal review. Edward Diener

3 2

[preprocessor] [variadic] VMD_SIZE using ADD -- why?
by lcaminiti 06 Jun '11

06 Jun '11

Hello all, I am using the VMD Boost Library Under Construction to handle variadic macros. On MVSC, this library uses PP_ADD to calculate the variadic size VMD_SIZE(__VA_ARGS__). However, it does not provide a reentrant version of VMD_SIZE (like VMD_SIZE_D) which is a problem when nesting size calculations within while iterations because PP_ADD uses PP_WHILE. I think, if this implementation is kept, the library should also provide the reentrant variant VMD_SIZE_D that invokes PP_ADD_D instead of PP_ADD. #if defined(BOOST_MSVC) #define BOOST_DETAIL_PP_VMD_DETAIL_DATA_SIZE(...) \ BOOST_PP_ADD(BOOST_DETAIL_PP_VMD_DETAIL_APPLY(BOOST_DETAIL_PP_VMD_DETAIL_ARG_N, (__VA_ARGS__, BOOST_DETAIL_PP_VMD_DETAIL_RSEQ_N())),0) \ /**/ #else #define BOOST_DETAIL_PP_VMD_DETAIL_DATA_SIZE(...) \ BOOST_DETAIL_PP_VMD_DETAIL_APPLY(BOOST_DETAIL_PP_VMD_DETAIL_ARG_N, (__VA_ARGS__, BOOST_DETAIL_PP_VMD_DETAIL_RSEQ_N())) \ /**/ #endif BTW, why is PP_ADD(size, 0) used on MSVC? If this is just for forcing proper macro expansion, I think other techniques (like the ones used by PP_EXPAND) should be used so no PP_WHILE reentrancy dependency is introduced. Thanks, --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-preprocessor-variadic-VMD-SIZE-usi… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 4

[none_t] I/O operators patch
by Gregory Crosswhite 06 Jun '11

06 Jun '11

Hey everyone, Since my idea to add I/O operators for none_t has been approved by the community according to the three-week rule --- which as you all know states that any proposals that have received no feedback on the list after three weeks are therefore automatically approved by the community ;-) --- I have written a patch based on the feedback I have received to implement these operators and attached it to this e-mail. To summarize my earlier e-mail, the advantage of having these operators around is that they allow generic I/O code to be applied to data of type none_t. One decision that I made in this patch that I have mixed feelings about is that I put the operators in the boost namespace. The advantages of this approach are obvious, but the disadvantage is that this "hides" them from the user who might not realize that he or she needs to import operator>> and operator<< in order to access them (since importing qualified operators is something that is not usually done) but instead conclude they they don't exist at all. Alternatives include putting them in the global namespace and putting them in the std namespace. Any thoughts on this? Since the window for adding new features to Boost closes tomorrow, and this patch is relatively small and should be fairly innocuous, is there a chance that this or something like it could be considered for the next release? Thanks! :-) Greg

3 5

Process library with child process events
by Klaim - Joël Lamotte 06 Jun '11

06 Jun '11

Hi, On Wed, Jun 1, 2011 at 14:12, Jeff Flinn <Jeffrey.Flinn(a)gmail.com> wrote: > Gregory Crosswhite wrote: > >> Hey everyone, >> >> Since there is not yet a Boost.Process library, does anyone have a >> suggestion for a lightweight cross-platform C++ library for launching and >> monitoring (i.e. being able to tell if they die) child processes? >> > > I've put the code from the recent boostcon "boost process" presentation > that Boris Schaeling and I gave at: > > https://github.com/JeffFlinn/boost-process > > Initial documentation is at: > > > https://docs.google.com/document/pub?id=1qdpxcJB51WMuNYlKYPkPcZZGuPj7zmeUPI… > > The intent is to get this completed and ask for review this summer. The > areas needing work are: > > I've read the current (clearly incomplete w.i.p.) doc and parsed the headers and I like the design so far. However, I can't find a way to be notified if a child process did end, by getting to the end of the program or by having crashed or by having being shut down by external processes, the OS or the user. Did I miss something? If not, what is supposed to happen in the parent process if a child do get to an end (whatever the cause)? Joël Lamotte

6 11

Gauging interest in new library re: multiscale/multigranular containers
by nathaniel＠tierblend.org 06 Jun '11

06 Jun '11

Hi: I would like to submit a library which would allow functionality related to scale and granularity to be performed on STL-like containers. Until recently I was in a doctoral program specializing in the philosophy of science, and I am especially interested in multiscale data modeling and its applications to e.g. GUI design, code generation, decision procedures, and DSL implementation. For example, one of my projects involves a DSL implemented through multiscale graphs in lieu of conventional syntax trees. I used to study at Buffalo, which houses the National Center for Ontological Research -- headed by the quite broad-ranging scholar Barry Smith -- and has done pioneering work in biomedical ontology and also in ontological models related to complex or "vague" aggregative structures. In these structures collections of objects of some base type T can be defined as aggregates but with varying degrees of looseness or "individual coherence"; and this aggregation can be iterated to produce multiscaled structures which can be queried or represented at different granularities. There are a number of analytic procedures which can be implemented on such structures, some overlapping with graph theoretic or statistical methods. These structures also possess alot of internal structure above and beyond their underlying list of values, so they are suited to memory-optimized C++ code rather than higher-level languages like Java. However, I am not aware of generic libraries which really incorporate these kind of data structures and their analysis in a systematic way, although I have come across non-template libraries which implement some similar features. What I propose is a library which could be used in a fashion similar to std::vector or std::set but which support additional functions along the lines of, e.g., building multigraphs out of T-type nodes; partitions of T-sets with functions to define or measure e.g. intrapartition relevance; defining (or extending) a scale metric on T-objects, T-sets, T-arrays, or other "T- data structures" and using it for rescaling, scale-filter, and other scale-related transformations; defining iterators or "walks" on T-collections which take scale and granularity into account; etc. In a number of cases the algorithms for these kinds of operations have been described in theoretical form or even already implemented in languages like Scheme. I believe that this project is also well-suited to carry over into C++0x, because new features proposed there (such as Concepts, which I know keep moving in and out of the specification) have potential to make this library increasingly generic or "fine-tuneable"; for example, users should be able to specify custom allocators not only for T's but for aggregates or connectors between T's which might be recognized as part of the inner structure of a T-collection. Thanks in advance for any comments or suggestions.

3 2

none_t I/O operators
by Gregory Crosswhite 05 Jun '11

05 Jun '11

Hey everyone, I have recently run into a scenario where it was useful to have << and >> I/O operators defined for none_t. I was using Boost Program Options to create a list of program options, and I wanted one of my options to be a help message. Since this option has no value except for the side effect of printing a help message and exiting, I gave it the type none_t, i.e.: options.add_options() ( "help" ,opts::value<none_t>()->zero_tokens()->notifier(...function that prints help message...) ,"print help message and exit\n" ) When I did this, it complained that the >> operator was not defined for none_t, so I went ahead and defined my own I/O operators, which are essentially just no-ops: inline std::istream& operator>> (std::istream& in, boost::none_t& _) { return in; } inline std::ostream& operator<< (std::ostream& out, const boost::none_t& _) { return out; } It seems to me that these are the natural I/O operators to define for this type, and so it would be useful to have them be officially part of Boost. Although it is unlikely that a user would ever call them directly, their existence could prove useful in various circumstances where a generic I/O function is being applied to a none_t, such as the case I ran into/ If people were willing to accept a patch that adds these operators to Boost, then I would be willing to write such a patch. Obviously I would need to generalize the istream/ostream types to the full generic versions which include the template parameters for character traits, etc. I would also add forward declarations of istream and ostream just before these declarations so that the implementation would not need to have the <istream> and <ostream> headers as dependencies, though this would be tricky because I'd need to figure out how to detect if <istream> and/or <ostream> have not been included yet. Thoughts? Cheers, Greg

3 6

Re: [boost] [msm] need to increase the fusion set and map size to 30
by Christophe Henry 05 Jun '11

05 Jun '11

> So i added these two statements at the beginning, and this solved the > problem. > > # define FUSION_MAX_SET_SIZE 30 > # define FUSION_MAX_VECTOR_SIZE 30 > > Perhaps we can add this somewhere in the doc. Hi Kim, Maybe I should make this subject more visible. It is described here: http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/ch05.html I think that FUSION_MAX_VECTOR_SIZE is actually enough, but it's only due to the fact that set is implemented in terms of vector (to be exact, as I only use fusion::set, FUSION_MAX_SET_SIZE ought to be enough, but it's not, so I suppose it's a fusion bug). Regards, Christophe

2 2

Re: [boost] [review] Heaps: size and stability
by Brent Spillner 05 Jun '11

05 Jun '11

On 6/2/2011 at 19:27, Tim Blechmann wrote: > The stability issue relates to a previous discussion from a couple > months ago (brought up by Cliff Green, > http://article.gmane.org/gmane.comp.lib.boost.devel/219330) Cliff was > concerned that the implementation of stability added overhead to the > normally unstable heaps (i.e., an extra size_t, I think) from the > implementation. I worry that the use of a policy parameter to specify > stability will result in "accidental overhead" in cases where users > don't fully understand the impact of their configuration choices. >it is not possible to write every heap algorithm as `stable' heap. i do not >recall the exact point that will break stability if one just orders the nodes in >the tree, but there was a non-trivial issue (possibly related to mutable heaps). It should be possible to preserve the correctness of most operations (certainly find, insert, delete, merge, and rebalancing) for ordinary heaps by storing items with the same key value in leftist heap order, i.e. preserving the invariants that: (1) if a subtree contains multiple items with the same key as the subtree root, the item at the root is logically first in the order (i.e., standard heap ordering); (2) if both the left and right subtrees contain items with the same key as the subtree root, all items with that key in the left subtree are logically ordered before any item having the same key in the right subtree (leftist property); and (3) if a subtree contains multiple items with a particular key value K, every item with key value K has as its parent another item with key value K, with the possible exception of the subtree root (locality/compactness property) These properties are preserved by right- or left- rotation around the subtree root. To keep the heap at minimum height, you will also occasionally need a prune-and-splice operation (items with key value K in the right subtree become children of the rightmost node with key value K in the left subtree), followed by further rotations. The compactness property should allow find, insert, and delete to continue running in O(lg n) time when rebalancing is not required. The prune-and-splice operations add O(|K|), where |K| is the total number of nodes having key value K, to the worst-case rebalancing operation, but this |K| quite reasonably ~O(lg n) when the key values are sufficiently distributed. Some merge algorithms would clearly violate the invariants above, but stable merge is still possible in O(n) time. >iac the node versioning seems to be the usual approach for implementing stable >heaps. the type of the version should be exposed to the interface, though, so >one can specify arbitrary-sized integer types to avoid overflows ... Versioning is the simplest way to adapt a non-stable heap implementation for stability, but the space overhead (and concomitant loss of flexibility in using a preexisting array to store the heap) and the risk of overflow make it unsuitable for some applications, including the quite common event queue. With a 32-bit counter value, a queue that receives and average of 100 events/second will overflow in about 16 months--- i.e. 32 bits is just enough space for your library to pass a reasonable test battery and still fail in the real world. (Of course, you need not increment the counter on every single insertion, as I just noted in the Code Collaborator review.) Another option would be chaining, where each heap node contains either a single item or a linked list of items with the same key value. This would minimize the required changes to existing algorithms, support fancier heap types and heaplike structures, and only impose some storage overhead (one or two pointers into the list, perhaps a length counter, and a means of synchronizing list access (which could be an atomic update protocol for the head/tail pointers and/or length counter)) when you actually need it, at the cost of some type erasure within the generic heap structure and possibly extra copying at runtime (when a singleton node first becomes a linked list.) On the subject of counters: On 6/2/2011 at 10:19, Tim Blechmann wrote: >will have a look ... in general boost.heap does not throw any exceptions by >itself, but of course the held type, the container or the allocator can throw Lines 231 & 232 of the review version of stable_heap.cpp are: if (counter_ == std::numeric_limits<std::size_t>::max()) BOOST_THROW_EXCEPTION(std::runtime_error("boost::heap counter overflow")); (to be fair, this does seem to be the only case in the library... but Thorsten is right that it should be clearly documented.)

3 2

[review] Heaps: mutability
by Andrew Sutton 05 Jun '11

05 Jun '11

Tim, I'm trying to figure out how I can use a mutable queue to write something like Dijkstra's SP. Here's a skeleton with the relevant parts. Queue<Vertex*, Comp> q; Map<Vertex*, Queue::handle_type> h; h[start] = q.push(start); v->distance += x; q.update(h[v]); Comp is an indirect comparison of vertex distances (u->distance < v->distance). Does the mutable heap support this application (i.e., where I'm not directly updating the value type)? It's not clear from the examples supplied with the program. I suspect that it is, but it's not clear. Andrew

3 4

Help with shared_ptr usage?
by Johnny Willemsen 03 Jun '11

03 Jun '11

Hi, I can need some help with getting similar behavior as with shared_ptr for my classes., I have used std::shared_ptr with C++0x which matches the boost support. I have two classes, Base and Derived. Now I want to give our users not directly access to these implementation classes, but to some reference to them. I have created two templates, BaseRef_T and Derived_objref (see below). In Derived_objref I need to add some additional typedefs and type definitions. I have tried first to add these typedefs to a specialization of shared_ptr<> but couldn't get a clean solution. If I now use shared_ptr I can take a shared_ptr for a Derived and assign it to a BaseRef_T. That works without problems. But how to accomplish this with my own wrapper classes. This should only be possible when the types are related to inheritance. If I have now a D that is not derived from Base than that shouldn't work. Johnny #include <memory> class Base { public: }; class Derived : public virtual Base { public: }; template <typename T> class BaseRef_T { public: BaseRef_T (std::shared_ptr <T> t) : impl_ (t) {}; BaseRef_T (T* t) : impl_ (t) {}; BaseRef_T (void) : impl_ () {}; typedef T element_type; inline T* operator-> () { return impl_.get ();} inline T* get() const { return impl_.get ();} explicit operator bool() const // never throws { return impl_ == 0 ? false : true; } void operator=(const std::nullptr_t& t) // never throws { impl_ = t; } // protected: typedef std::shared_ptr <T> shared_ptr_type; shared_ptr_type impl_; }; typedef BaseRef_T <Base> BaseRef; template <typename T> class Derived_objref : public virtual BaseRef_T <T> { public: Derived_objref () : BaseRef_T<T> () {} Derived_objref (T *s) : BaseRef_T<T> (s) {} Derived_objref (const BaseRef_T <T>& o) : BaseRef_T <T> (o) {} void operator=(const std::nullptr_t& t) { this->impl_ = t; } typedef int my_index_type; // Needed as additional typedef for Derived struct Foo {int a;}; }; typedef Derived_objref <Derived> DerivedRef; int main (int,char*[]) { std::shared_ptr<Base> bs (new Base); std::shared_ptr<Derived> ds (new Derived); std::shared_ptr<Base> cs = ds; BaseRef b (new Base); DerivedRef d(new Derived); BaseRef c = d; // <== how to get this working? return 0; }

2 1

Invitation to connect on LinkedIn
by kannan k v via LinkedIn 03 Jun '11

03 Jun '11

LinkedIn ------------ kannan k v requested to add you as a connection on LinkedIn: ------------------------------------------ Yuriy, I'd like to add you to my professional network on LinkedIn. - kannan Accept invitation from kannan k v http://www.linkedin.com/e/bv6hcz-goh9zloe-1g/uV9CsZkavY-uKU5A7C-1JbkavY-u5P… View invitation from kannan k v http://www.linkedin.com/e/bv6hcz-goh9zloe-1g/uV9CsZkavY-uKU5A7C-1JbkavY-u5P… ------------------------------------------ Why might connecting with kannan k v be a good idea? People kannan k v knows can discover your profile: Connecting to kannan k v will attract the attention of LinkedIn users. See who's been viewing your profile: http://www.linkedin.com/e/bv6hcz-goh9zloe-1g/wvp/inv18_wvmp/ -- (c) 2011, LinkedIn Corporation

3 3

parsing strings at compile-time
by Andrzej Krzemienski 03 Jun '11

03 Jun '11

Hi Everyone, This is not directly related to any of the boost libraries, but I thought people from this list may find it interesting or useful. The below are links to three posts where I tried to describe how we can parse strings at compile time and convert them to data structures, still at compile-time in C++0x with generalized constant expressions. I do not have enough time to write a library myself, but perhaps someone would be able to use such techniques for their library. I think Regular Expressions library would benefit from this technique if the compiler would be able to check the correctness of a regex. http://akrzemi1.wordpress.com/2011/05/06/compile-time-computations/ http://akrzemi1.wordpress.com/2011/05/11/parsing-strings-at-compile-time-pa… http://akrzemi1.wordpress.com/2011/05/20/parsing-strings-at-compile-time-pa… Regards, &rzej

2 1

[Proto] Expression as fusion/MPL sequence
by Joel Falcou 03 Jun '11

03 Jun '11

Seems somethign crooky on this front. Calling fusion::at_c on expression ends up in error even after including boost/proto/fusion.hpp. Same way, flatten used as a transform seems to not give me a type that can be passed to any fusion or mpl function. Looking at proto/fusion.hpp I noticed that the iterator is indeed random_access but not the view itself which as a forward_traversal tag. Even after fixing this, no dice, at_c<N>(some_proto_expr) still fails to compile.

3 3

[test] Running regression tests
by Edward Diener 02 Jun '11

02 Jun '11

Attempting to run regression tests for the 'test' library on the Boost trunk I receive as output: "..\..\..\libs\test\build\Jamfile.v2:107: in modules.load rule boost-install unknown in module Jamfile</C:/Programming/VersionControl/boost/libs/test/build>. C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:314: in load-jamfile C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:62: in project.load C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:766: in project.use C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:89: in load-used-projects C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:73: in load C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:115: in load-parent C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:464: in initialize C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:309: in load-jamfile C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:62: in load C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:115: in load-parent C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:464: in initialize C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:309: in load-jamfile C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:62: in load C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:168: in project.find C:/Programming/VersionControl/boost/tools/build/v2\build-system.jam:570: in load C:\Programming\VersionControl\boost\tools\build\v2/kernel\modules.jam:283: in import C:\Programming\VersionControl\boost\tools\build\v2\kernel\bootstrap.jam:142: in boost-build C:\Programming\VersionControl\boost\boost-build.jam:17: in module scope" All other regression tests for libraries produce no Boost Build errors. Can anybody tell me what is wrong here ?

4 4

std::map::find() wrapper
by Olaf van der Spek 02 Jun '11

02 Jun '11

Hi, I've written a small wrapper for std::map::find() (and map-like containers/ranges) that returns a pointer to the value if found (or NULL if not found). See https://svn.boost.org/trac/boost/ticket/5227 The advantage is that you don't need the container type name (for ::reference), you can initialize the pointer inside an if condition, you don't have to compare against ::end() and you don't have to use ->second. For containers of pointers to objects, the wrapper could do an additional dereference. Do you think this would be useful for inclusion in Boost? Greetings, Olaf

17 61

[review] Heaps: size and stability
by Andrew Sutton 02 Jun '11

02 Jun '11

Tim, Do you really need to parametrize the constant-time size property? C++11 requires constant time size for all containers. I think that this is also a reasonable requirement for Heaps. I'm not aware of any applications that use so many heaps that the extra 4-8 bytes required by a size parameter would make huge difference in memory usage. Also, for heaps that can be effectively implemented in terms of other containers, they should guarantee O(1) size. The stability issue relates to a previous discussion from a couple months ago (brought up by Cliff Green, http://article.gmane.org/gmane.comp.lib.boost.devel/219330) Cliff was concerned that the implementation of stability added overhead to the normally unstable heaps (i.e., an extra size_t, I think) from the implementation. I worry that the use of a policy parameter to specify stability will result in "accidental overhead" in cases where users don't fully understand the impact of their configuration choices. Would it be better (would it be possible?) to write stable_heap as a heap adaptor? I think that this approach (if possible) has two benefits. First it encapsulates the strategy for implementing stability. It also provides a single point of reference for describing the impact of using that configuration. Andrew

3 4

safe-bool CRTP class
by Krzysztof Czainski 01 Jun '11

01 Jun '11

Hello, Vladimir Batov prepared a safebool helper class as part of his Pimpl library. I quote his rationale: /// An implicit conversion to bool (operator bool() const) is very much /// idiomatic and is often deployed in constructs like "if (foo)" and "if (!foo)" /// (with no explicit op!() defined). However, sadly, implementing "operator bool()" /// is *wrong* as that conversion kicks in far too often and unexpectedly. Like in /// "foo == 1", "foo+1", "1+foo" or potentially during lexical_cast<string>(foo) /// (if there are no op>>() and op<<() defined). Consequently, that "implicit /// conversion to bool" functionality has to be implemented in an indirect and /// somewhat awkward way via an implicit conversion to some other type. The best /// type for the purpose appears to be a pointer to a member function. For more /// see the chapter 7.7 in Alexandrescu's "Modern C++ Design" and the article at /// http://www.artima.com/cppsource/safebool.html by Bjorn Karlsson. In the review of Pimpl Joej Falcou suggested to make safebool a CRTP base class. I had prepared such a class some time ego, and I've been using it for a while now. Is there interest in adding it to boost? Perhaps as part of the operators library? /** * CRTP class, that provides operator unspecified_bool_t() const, implemented in terms of * Derived::operator! */ template < class Derived, class Base = empty_t > class boolable : public Base { void unspecified_bool_t_f() {} typedef void (boolable::*unspecified_bool_t)(); public: operator unspecified_bool_t() const { return ! static_cast<Derived const&>( *this ) ? 0 : &boolable::unspecified_bool_t_f; } }; Usage: struct X : public boolable<X> { bool operator!() const { return condition; } // inherit operator unspecified_bool_t implemented in terms of the above operator! }; Regards, Kris

13 39

[Math and numerics] interest in Circular values math and statistics library ?
by Lior Kogan 01 Jun '11

01 Jun '11

I built a C++0x circular-values math and statistics library, and posted it on CodeProject. See http://www.codeproject.com/KB/recipes/Circular-Values.aspx I wonder if such library may be a welcomed addition to Boost. Thank you, Lior

5 5

Re: [boost] [pimpl] Mini Review
by Sean Chittenden 01 Jun '11

01 Jun '11

>> I've been watching this discussion for a while (with vested >> interest), and want to use a few examples to shore up some of >> the discussion (and possibly move it off list so that things >> can proceed in a constructive manner). The concern is not that >> Pimpl is implementing an opaque pointer, it's the miscellaneous >> copy constructors, constructors, equality or whatever other >> misc "extras" that come along from using Pimpl, right? > > Not quite. Copy constructors and copy assignment, for example, are appropriate. They allow the library to manage copies of the implementation object. Problems arise, for example, from the addition of null(),operator ->(), and operator *(). This is less rhetorical than I'd like, but what's the right amount of baggage that a Pimpl implementation can bring along with it? On one side of the spectrum you have an austere implementation that is literally an opaque pointer with its relevant compilation glue ("the one true/pure pimpl"). On the other side of the spectrum you've got something that overloads functions and operators and makes a pimpl implementation easier to use, ala the Pimpl library. For example: https://github.com/sean-/Boost.Examples/blob/master/pimpl/boost/pimpl/pimpl… Not strictly necessary, but I understand why it's there and why it would be wanted in a Pimpl implementation. I also understand the puritanical argument for why you wouldn't want it. > reset(), which may be protected rather than public (I don't recall), is not as much of a problem, but my suggestion for that was that since the constructors allocate the implementation object, "resetting" the implementation should likewise not involve allocation. For that, I suggested a construct() member function template set, paralleling the constructors that implement "perfect forwarding." A constructor and a reset() that take a deleter would be appropriate for cases in which allocation is not desired. That design would be symmetrical. Got it, ok. >>> class Book : public pimpl< Book >::pointer_semantics { }; >>> // Or is the interface different because the ABI is >>> // different? >>> class Book { >>> class* impl_; >>> }; > > It's different because using inheritance and public member functions, pimpl<Book>::whatever has augmented Book's interface. Correct/agreed. >> With as (in?)efficient compilers sucking up gigs of RAM and >> frequently crashing during compilation[1], having a friendly >> mechanism to hide linkage and implementations behind opaque >> pointers is useful beyond externally exposed APIs in libraries. >> The tedium of doing this frequently makes the Pimpl library an >> easy win for many developers (though possibly not all of them >> and not in all situations). As a Pimpl consumer for over a >> year, I'm trying to concretely demonstrate where the possible >> pitfalls could be lurking with this implementation. Thanks in >> advance. -sc > > I have no problem with using the Pimpl Idiom. Just this past week I was able to advance some application testing readily because we used it in a couple of classes involved in an application's disorderly shutdown due to misconfiguration. My concern is that the Pimpl Library seems to have pushed past the idiom into something else, which is surprising to me and, clearly, to others. I should also be clear that I'm not against what the Pimpl Library has done, in terms of augmenting the derivate's interface via public inheritance, but that doing so should be in a class template and a library of a different name. That feedback makes sense, thanks Robert. I think the unease is coming from the Pimpl library implementing helpers and extending beyond only providing an opaque pointer. TBH, before using Pimpl, I'd implemented a subset of the helper functions in my own home-grown pimpl library so seeing them standardized never struck me as objectionable (the possibility of running in to name clashes, not withstanding). In fact, my search for Boost.Pimpl began because I missed adding a non-const* ->() to my implementation. After wading through pages of gcc error messages (naturally this happened in the middle of a asio/bind/wrap call) I started looking for a reference implementation that had some of this spelled out since I didn't think I should be spending my time reimplementing the wheel. I don't have an answer for what's "right" on the spectrum of austere vs "featureful", but the featureful side of Pimpl has clear merit. I'll move the rest of my comments over to the review tool. -sc http://demo.smartbear.com/boost/go?page=ReviewDisplay&reviewid=5 -- Sean Chittenden sean(a)chittenden.org

2 1

[conversion] ADL and templates
by Vicente BOTET 01 Jun '11

01 Jun '11

Hi, I've tried to add a configuration point in Boost.Conversion via overloading and ADL, but while the internal call of the library can find them using a trick that adds a parameter that contains the type of the return type, the user is not able to find them without using the same this trick, but this is too dark to be natural for user code. Next follows a simplified code of the problem. The following namespace N { struct S{}; template (*typename T*) T fct1(S const& s) { return T(s); } template (*typename T*) void fct2(T &t, S const& s) { t=s; } } void test () { N::S s1; N::S s2; fct2(s2, s1); s2=fct1(*N::S*)(s1); // (1) } Results in a compile error in (1) error: ‘fct1’ was not declared in this scope Is it standard behavior that fct1 can not be found by ADL? Thanks, Vicente P.S. Please replace (* and *) by angle brackets.

4 11

Cross-platform process library?
by Gregory Crosswhite 01 Jun '11

01 Jun '11

Hey everyone, Since there is not yet a Boost.Process library, does anyone have a suggestion for a lightweight cross-platform C++ library for launching and monitoring (i.e. being able to tell if they die) child processes? Thanks! Greg

3 2

Re: [boost] [pimpl] Mini Review
by Sean Chittenden 01 Jun '11

01 Jun '11

>>> Helping to implement copying and assignment is useful, >>> provided the class is supposed to support those operations. >> >> shared_ptr-based Pimpls copying and assignment are done by >> shared_ptr. > > That tells me that Pimpl provides copying and assignment for the derivate. > As you've noted, this is only by virtue of using private inheritance. I still don't think it is correct behavior for a library implementing the Pimpl Idiom to modify the interface class' (Book's) interface. Consider a raw pointer Pimpl design: > > class Book { > // state > }; > > becomes: > > class Book { > struct impl; > impl pimpl_; > }; > > struct Book::impl { > // state > }; > > Adding a pimpl did nothing to Book's interface. Why then should Book's interface chance when using your library? That seems to be an extension of the idiom into the territory of the Bridge Pattern or something else entirely. I've been watching this discussion for a while (with vested interest), and want to use a few examples to shore up some of the discussion (and possibly move it off list so that things can proceed in a constructive manner). The concern is not that Pimpl is implementing an opaque pointer, it's the miscellaneous copy constructors, constructors, equality or whatever other misc "extras" that come along from using Pimpl, right? To recap (using pointer semantics since that's my preferred implementation): > // book.h > class Book : public pimpl< Book >::pointer_semantics { > // interface > }; > > // book_impl.cc > template<> struct pimpl< org::example::String >::implementation : boost::noncopyable { > // impl state > } > Book::Book() : base() { } > > // user.cpp > Book b; > std::cout << "sizeof(Book): " << sizeof(b) << std::endl; From an ABI perspective, Book implemented via Pimpl maintains the same size (currently 16 bytes, regardless of Book::implementation), and thereby provides a stable ABI (if someone really was concerned about future-proofing their frontend ABI, they could pad Book in book.h). I think the concern is coming from: > Book* b2 = new Book(); > Book* b1 = b2; because there possibly isn't a clear understanding of how those mechanics would work with Pimpl (yes?). Or is it because it's unclear how you'd obtain the desired copy semantics - for example - with the proposed Pimpl library? I'm trying to tease out what the actual feedback is or what the possible suggestions could be (vs outright criticism). > Modifying the interface is the part I was referring to. > > You've said that copying and assignment are only supported (for value semantics, anyway) if the derivate provides them. That's a good approach. If everything is of that sort, then all's well, but that's not what I see. How is Book's interface different? > // Is the Interface different because of the inheritance? > class Book : public pimpl< Book >::pointer_semantics { }; > // Or is the interface different because the ABI is different? > class Book { > class* impl_; > }; Would a Pimpl implementation with preprocessor directives be more suitable because of the level of explicitness? Also, Pimpl implements an opaque pointer and successfully breaks compilation dependencies. Pimpl is not a Bridge implementation. > class Book { > PIMPL_PUBLIC_INTERFACE(Book, impl); > }; ? I use similar cpp(1) magic to implement NO_COPY_OR_ASSIGN() because I've found it to be more predictable in working (or failing) than inheriting from boost::noncopyable. With as (in?)efficient compilers sucking up gigs of RAM and frequently crashing during compilation[1], having a friendly mechanism to hide linkage and implementations behind opaque pointers is useful beyond externally exposed APIs in libraries. The tedium of doing this frequently makes the Pimpl library an easy win for many developers (though possibly not all of them and not in all situations). As a Pimpl consumer for over a year, I'm trying to concretely demonstrate where the possible pitfalls could be lurking with this implementation. Thanks in advance. -sc [1] A few years ago I came to terms with it being a Boost "Right Of Passage" to debug your first compiler crash (that wasn't the result of running out of RAM). -- Sean Chittenden sean(a)chittenden.org

2 1

[function] [1.47.0] #4717: Non-const local static variable stored_vtable
by Kazutoshi Satoda 01 Jun '11

01 Jun '11

I want the fix for the following ticket (regression, I think) included in 1.47. "#4717: Non-const local static variable stored_vtable" https://svn.boost.org/trac/boost/ticket/4717 Here is a quote of a essential part of the fix. - static vtable_type stored_vtable = + static const vtable_type stored_vtable = { { &manager_type::manage }, &invoker_type::invoke }; https://svn.boost.org/trac/boost/attachment/ticket/4717/djw_function_const_… I did same request for 1.46 and 1.46.1, and got no response. http://lists.boost.org/Archives/boost/2011/03/177769.php http://lists.boost.org/Archives/boost/2011/01/175248.php Please let me know if there is more effective way to push the fix, or if I'm doing something wrong. -- k_satoda

2 2

[shared_ptr] Some design advice
by Johnny Willemsen 31 May '11

31 May '11

Hi, I want to create some refcounted objects using shared_ptr. For example if I have class A_impl, I want my users only to use A. So, I created the following code: class A_impl { public: virtual ~A_impl () {}; void dosomething () {}; }; typedef shared_ptr <A_impl> A; The challenge is now that I want to provide some typedefs on A (which is a shared_ptr()). So that my users can use: A::my_value_type; I am aware of the reference_type, but I need to have some additonal typedefs and constants as part of A. I have started with a partial template specialization of shared_ptr, but I have my doubts whether this is the correct way. Another option would be to create our own shared_ptr that just embeds the boost_shared_ptr and exposes just some of its methods. Any specific ideas on this? Regards, Johnny

2 1

Re: [boost] [tokenizer] tokenizing by strings rather than chars
by Andrzej Krzemienski 31 May '11

31 May '11

> Andrzej Krzemienski wrote: > > I want to parse numbers separated by "new-lines", however, on > > my windows system, a "new-line" is represented by two > > consecutive characters: 13, 10 (or in other words by string > > "\n\r"). So, only if I encounter a sequence of these two chars > > do I want to cut the token. > > Spirit.Qi would do that handily. Something like this should work: > namespace qi = boost::spirit::qi; > std::vector<int> data; > qi::phrase_parse(input.begin(), input.end(), qi::int_, qi::eol, data); Thanks for the reply. And could I ask a similar question? I wanted to simplify my real task to make it shorter and clearer to understand, and it look like I changed it to a different one. My apologies. My real task is to check if the data in Windows clip-board is a column of data (copied from a grid or table). Such a column is just text separated with "\n\r" sequences. So, for example these are valid data: "12" - a column of height 1 with data "12", " a\n\r b" - a column of height 2 with two with data " a" and " b" "-1\n\r\n\r3" - a column of height 3 with datum "-1", empty cell, and datum "3". The spirit solution above will skip the empty cell in my third example. On the other hand, I do need the information about empty cells too. It really looks more like a tokenizing task. Or is there a way to do it easily in Spirit? Regards, &rzej

2 1

Re: [boost] [pimpl] Mini Review
by Ivan Le Lann 31 May '11

31 May '11

----- "Artyom Beilis" <artyomtnk(a)yahoo.com> a écrit : > Hello All, > > Because a pre-review runs this days in collaborator tool I still want > to provide some feedback on this library I was looking on long > time ago. > > - What is your evaluation of the design? > > --------------------------------------------- > This is the major problem of the library: > It tries to do simple things overcomplicated. > --------------------------------------------- > > > Take as an example: > > struct Book : public pimpl<Book>::value_semantics { ... }; > > Is an attempt to do things in "fancy" way where it is not needed. > > struct Book { > public: > private: > struct implementation; > smart_ptr<implementation> pimpl_; > }; > > Is much clearer. Your code would rather simulate pimpl<>::pointer_semantics. And you do not mention the boilerplate code generated. > > The proposed solution is overcomplicated hard to read and in general > makes > more troubles then helps, makes the code less readable by average > programmers. > > ------------------------------------ > shared_ptr as pointer model is Wrong > ------------------------------------ > (snip lots of smart_ptr related lines) Unless you want pointer_semancics ... As for value_semantics, shared_ptr is not used. > 2. clone_ptr - pointer that clones underlying object on its copy. > i.e. something like > > copy_ptr(copy_ptr const &other) : p_(other->clone()) {} Precisely what seems to be used in the library for value_semantics. > > The only advantage I can see in boost.pimpl over scoped_ptr or > auto_ptr > is that it does not require explicit destructor. An important advantage as many developpers get trapped here. And it is "only" a warning to do so ... > Spare Pointer use case > ------------------------ > > Another important use case in the case when pimpl is used to handle > ABI > stability and > in general the object has spare "pimpl" or d-pointer for future uses. > > Consider: > > struct book { > public: > book(); > book(book const &); > ~book(book const &); > book const &operator=(book const &); > std::string title() const; > std::string author() const; > void title(std::string const &); > void author(std::string const &); > private: > std::string author_; > std::string title_; > struct data; > copy_ptr<data> d; > }; > > > Now in book.cpp we define data as > struct book::data {}; And with Pimpl, you would put author_ and title_ in book::data. I failed to see the point here. You seem to say that Pimpl cannot be used for ABI stability, which seems wrong to me. Regards, Ivan.

5 13

Re: [boost] [random] recent changes causing failures in accumulators tests
by Steven Watanabe 31 May '11

31 May '11

AMDG On 05/30/2011 09:23 PM, Eric Niebler wrote: > On 5/27/2011 12:24 PM, Steven Watanabe wrote: >> On 05/26/2011 09:49 PM, Eric Niebler wrote: >>> Many accumulators tests are now failing on both trunk and release. I >>> have tracked it down to recent changes in Boost.Random. I don't know for >>> how long this has been happening. > <snip> >>> >>> Steven, this seems like a regression. Can you look into this? >>> > >> I think the only thing I changed was the seeding algorithm. >> The number of random bits was reduced from 53 to 48, but >> that's all lagged_fibonacci607 ever claimed to provide. > >> Your limits may be too low. I switched extended_p_square.cpp >> to use mt19937_64 and random_device with >> generate_canonical<double, 53> and it still failed >> with both. It's getting a bit late tonight. I'll >> work through the math tomorrow. > > Hi Steven, have you had a chance to look into this? I'm not so much > concerned about accumulators as I am about the potential regression in > random, especially since the release branch is effected and we're > closing in on a release. > For extended_p_square, the check for 0.25 with epsilon = 2, works out ot a 75% confidence interval. I bumped epsilon up to 3. I think this is somewhere between a 90 and 95% confidence interval. I adjusted the tests at 0.01 and 0.001 also. Once I got the test to pass with random_device consistently, it also passed with lagged_fibonacci607. (I'm not absolutely sure about the confidence intervals. I was estimating them using the binomial distribution, which is a poor approximation towards the edges). I'm pretty sure from this that the problem was that the probability that the test would pass with random values was too low, so the change in the seeding algorithm was enough to make it fail. I'll try to make time to check the other failing tests soon. In Christ, Steven Watanabe

1 0

[pimpl] Mini Review
by Artyom Beilis 31 May '11

31 May '11

Hello All, Because a pre-review runs this days in collaborator tool I still want to provide some feedback on this library I was looking on long time ago. - What is your evaluation of the design? --------------------------------------------- This is the major problem of the library: It tries to do simple things overcomplicated. --------------------------------------------- Take as an example: struct Book : public pimpl<Book>::value_semantics { ... }; Is an attempt to do things in "fancy" way where it is not needed. struct Book { public: private: struct implementation; smart_ptr<implementation> pimpl_; }; Is much clearer. The proposed solution is overcomplicated hard to read and in general makes more troubles then helps, makes the code less readable by average programmers. ------------------------------------ shared_ptr as pointer model is Wrong ------------------------------------ You almost never want to have shared object semantics for pimplized object. I use pimpl ideom widely in my projects CppCMS, CppDB and even in Boost.Locale and I used shared semantics only once where it was explicitly shared. In rest of the cases I had found myself using following smart pointers: 1. copy_ptr - pointer the copies underlying object on its copy. i.e. something like copy_ptr(copy_ptr const &other) : p_(new Object(*other)) {} Copy the object on copy. 2. clone_ptr - pointer that clones underlying object on its copy. i.e. something like copy_ptr(copy_ptr const &other) : p_(other->clone()) {} 3. hold_ptr - pointer with same const-semantics as an object it points to T const &operator*() const; T &operator*() ; T const *operator->() const; T *operator->() ; They cover almost all use cases, so with addon of shared_ptr it covers ALL use cases. In any case current boost::scoped_ptr or std::auto_ptr is much more suitable smart pointer for implementing pimpl then Boost.pimpl. The only advantage I can see in boost.pimpl over scoped_ptr or auto_ptr is that it does not require explicit destructor. i.e. class Foo : boost::noncopyable { public: Foo(); int x() const; void x(int v); private: struct data; std::auto_ptr<data> d; }; No good. You need to add ~Foo(); So it would know to destroy Foo::Data correctly. But this can be easily solved on hold_ptr, copy_ptr and clone_ptr level same as it solved for shared_ptr and in reality even this not needed as it is better to add empty destructor in cpp. Spare Pointer use case ------------------------ Another important use case in the case when pimpl is used to handle ABI stability and in general the object has spare "pimpl" or d-pointer for future uses. Consider: struct book { public: book(); book(book const &); ~book(book const &); book const &operator=(book const &); std::string title() const; std::string author() const; void title(std::string const &); void author(std::string const &); private: std::string author_; std::string title_; struct data; copy_ptr<data> d; }; Now in book.cpp we define data as struct book::data {}; And we do not initialize d at all. It is fast and efficient object that does not use data at all. Now when we decide to add new member "isbn" without breaking ABI. in book.cpp we define in book.cpp struct book::data { std::string isbn_; } And now we initialized the d pointer in constructor. And add new members in book.h std::string isbn() const void isbn(std::String const &); And implement them std::string book::isbn() const { return d->isbn_; } void isbn(std::string const &s) { d->isbn_ = s; } This is very important use case the the author does not even relate to. - What is your evaluation of the implementation? Generally not looked into too deeply but it is does not follow boost standards: - Naming conventions - Documentation - Build So it is not even ready for the review (even thou it can be easily changed as it is a small library) - What is your evaluation of the documentation? 1. The documentation should be in HTML file not on some Internet web site. 2. Rationale part missing The documentation in not Boost-Ready - What is your evaluation of the potential usefulness of the library? Useless for 90% of pimpl use cases. - Did you try to use the library? With what compiler? Did you have any problems? No I hadn't - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 4-5 hours of studying - Are you knowledgeable about the problem domain? Yes, I work with pimpl-ized object on daily bases in many different approaches including implementing my own smart pointers for pimpl (clone_ptr, hold_ptr, copy_ptr) - ABI Stability - Compilation time reduction, - Decoupling of the interface from implementation details. Should The library be accepted in Boost: ======================================== No it should not. It is "a fancy" library that was written without a knowledge of the problem domain. It tries to solve problem in smart way making it overcomplicated. IMHO old std::auto_ptr is much more suitable for writing pimpl-objects then Boost.Pimple. For easy pimpl-ideom you do not need a fancy class but rather a set of pimpl-suitable smart pointers. Best Regards, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

10 31

[Config] Big changes in C++0x detection...
by John Maddock 31 May '11

31 May '11

Just a heads up, that the latest Boost.Config changes: * Remove the concept related macros. * Tighten up most of the C++0x related tests, with the result that some C++0x features that were previously enabled are no longer - this may also cause the Boost.Config tests to fail on some platforms. * Some C++0x features that were not previously enabled are now - because they were passing the Boost.Config tests - there's at least one case where this is causing regressions in other libraries - if any more pop up please let me know ASAP! Thanks for your patience! John.

9 34

boost-test, why is there no DOUBLES_EQUAL?
by Sebastian Nowozin 31 May '11

31 May '11

Hello, I am a regular user of the boost test library, having used CPPunit before. I miss the following macro: BOOST_CHECK_DOUBLES_EQUAL(first, second, absolute_tolerance); which would check whether "std::fabs(first-second) <= absolute_tolerance" is true. It seems the boost test library does not support it, and instead forces/encourages users to use BOOST_CHECK_CLOSE(first, second, percent_relative_tolerance); The above macro does not really make sense in my application, I really need to check for absolute tolerances, irrespectively of the magnitude of the numbers. CPPunit has this feature as DOUBLES_EQUAL. Would you consider adding this? Thanks, Sebastian

9 16

[shared_ptr] calling functions by reference
by Sid Sacek 31 May '11

31 May '11

This might be a unimportant question and may have already been answered many times before, but I was wondering about functions that take shared pointers as arguments. Is there ever a reason I would not want to use a shared_ptr reference as an argument? I can't think of any, but is there any? class XYZ; void foo( shared_ptr< XYZ > &xyz ) { }

5 12

boost.atomic and boost.lockfree backports
by Bryce Lelbach 30 May '11

30 May '11

Hartmut and I have been using modified versions of Boost.Lockfree and Boost.Atomic in our codebase at work. I've put git repositories of our versions of both libraries up on github, so that the lockfree/atomic authors can integrate our bug fixes and/or feature extensions if they wish. The code is under the BSL. In addition to a number of bug fixes/tweaks, our variants contain the following enhancements: * boost.atomic: 128bit lockfree atomics for MSVC 2008+ (using _InterlockedCompareExchange128 and SSE2 intrinsics) and GCC-compatible POSIX compilers (using 16 byte __sync intrinsics). This code is x86-64 specific, and disabled by default. Define BOOST_ATOMIC_HAVE_SSE2 to enable in x86-64 MSVC 2008+ environments. Define BOOST_ATOMIC_HAVE_SSE2, BOOST_ATOMIC_HAVE_GNU_SYNC_16 and BOOST_ATOMIC_HAVE_GNU_ALIGNED_16 to enable for GCC-compatible compilers. The following command line flags are also needed for GCC-compatible compilers: -mcx16 (enables 16byte sync intrinsics) and -msse2. * boost.lockfree: A growable lockfree deque, based on algorithms by M. M. Michael. Backed by 128bit atomics. This is the first lockfree data structure I've written, so take it with a grain of salt. There's one bug that I'm aware of, unfortunately, it occurs infrequently so I haven't had much luck tracking it down. Links: https://github.com/brycelelbach/boost.atomic https://github.com/brycelelbach/boost.lockfree P.S. I don't have a list of the specific bug fixes on hand, I'll have to go through the SVN logs for that. The only non-trivial one that I know of is the problem with intel-linux that I found and fixed (intel doesn't define *amd64* macros, and they were used for x86-64 bit detection). -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

4 7

[profile_templates] template profiling on darwin
by Gordon Woodhull 29 May '11

29 May '11

Hey Steven, Thanks for your help getting the template profiler working on darwin. I just had to make a couple more obvious config copy/pastes to get this working - my diffs are below. Also, it appears that the tool is broken for gcc < 4.3 - it looks like some changes were made halfway for template_profiler_test{_enter|_exit} but still some undefined references to template_profiler_test. I mucked about with this for a few minutes, then gave up and upgraded to gcc 4.5, updated my simlinks, and darwin configuration works ok now. Now I've got LOTS of data to wade through (65K template instantiations for a very small MSM test!) Thanks again, Gordon Index: template-profile.jam =================================================================== --- template-profile.jam (revision 72066) +++ template-profile.jam (working copy) @@ -53,6 +53,22 @@ } +module darwin { + import template-profile : init-toolset ; + template-profile.init-toolset darwin ; + + actions compile.c++.preprocess { + $(CONFIG_COMMAND) $(OPTIONS) $(USER_OPTIONS) -D$(DEFINES) -I"$(INCLUDES)" -E "$(>)" | $(INSTRUMENT-ACTION) >"$(<)" + } + + actions compile.c++.template-profile { + "$(CONFIG_COMMAND)" $(LANG) -ftemplate-depth-$(TEMPLATE_DEPTH) $(OPTIONS) $(USER_OPTIONS) -D$(DEFINES) -D PROFILE_TEMPLATES -I"$(INCLUDES)" -c "$(>:W)" 2>&1 | "$(FILTER)" $(FILTER-OPTIONS) >"$(<)" + } +} + +IMPORT gcc : compile.c++.preprocess : darwin : compile.c++.preprocess ; +IMPORT gcc : compile.c++.template-profile : darwin : compile.c++.template-profile ; + module msvc { import template-profile : init-toolset ; @@ -88,6 +104,8 @@ toolset = msvc ; case gcc* : toolset = gcc ; + case darwin* : + toolset = darwin ; case * : errors.error unrecognized toolset $(toolset) ; } @@ -124,6 +142,7 @@ generators.register [ class.new warn-generator msvc.compile.c++.template-profile : INSTRUMENTED_TEMPLATE_PREPROCESSED_CPP : RAW_TEMPLATE_PROFILE : <toolset>msvc ] ; generators.register [ class.new warn-generator gcc.compile.c++.template-profile : INSTRUMENTED_TEMPLATE_PREPROCESSED_CPP : RAW_TEMPLATE_PROFILE : <toolset>gcc ] ; +generators.register [ class.new warn-generator darwin.compile.c++.template-profile : INSTRUMENTED_TEMPLATE_PREPROCESSED_CPP : RAW_TEMPLATE_PROFILE : <toolset>darwin ] ; class final-profile-generator : generator {

1 0

[type_erasure] default implementation of concept signatures
by Vicente Botet 28 May '11

28 May '11

Hi Steve, Concepts are able to define default implementations if the type doesn't provides the specific signature. For example in 20.1.2 Comparisons the concept LessThanComparable defines a default for implementation for bool operator>(U const& a, T const& b) { return b < a; } bool operator<=(U const& a, T const& b) { return !(b < a); } bool operator>=(T const& a, U const& b) { return !(a < b); } In the definition of the concept less_than_comparable in Boost.Any, you define the implementation of these operators in function of operator<(), but if the types provide the specific signature the specific function is not called. I guess that the default implementation of for example operator<= should use operator< only if the the underlying types don't provide operator<=. What do you think? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/type-erasure-default-implementation-of-c… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 9

[1.47.0] Release schedule
by Beman Dawes 28 May '11

28 May '11

* Monday, June 6: branches/release closed for all changes, except by permission of a release manager. * Monday, June 13: branches/release frozen. Only release managers may commit. Once tests have cycled and the release managers are satisfied with stability, release candidates for the beta will be generated. * Monday, Jun 20: Beta release target date. See June in http://www.boost.org/development/index.html or https://www.google.com/calendar/embed?src=5rorfm42nvmpt77ac0vult9iig@group.… The final release date won't be set until later in the process. Thanks, --Beman

1 0

'unnamed_Path' was not declared in this scope
by Ilya Chernykh 28 May '11

28 May '11

Hi! While building a package against boost I receive the following message: /usr/include/boost/filesystem/v2/operations.hpp: In function 'Path boost::filesystem2::current_path()': /usr/include/boost/filesystem/v2/operations.hpp:534:14: error: 'unnamed_Path' was not declared in this scope Is this an error in boost and how can I overcome it?

2 1

[gsoc] heap review
by Tim Blechmann 28 May '11

28 May '11

hi all, during this `summer of code', i will do the review of two proposed libraries, boost.lockfree and boost.heap. the boost.heap review will be the first one, taking place from may 30th to june 8th. boost.heap is an implementation of different priority queue data structures. they can be found at: tarball: http://tim.klingt.org/git?p=boost_heap.git;a=snapshot;h=HEAD;sf=tgz git repository: git://tim.klingt.org/boost_heap.git documentation: http://tim.klingt.org/boost_heap/ there will be a `formal' review announcement, i want to invite people to check out code, examples and documentation ... cheers, tim -- tim(a)klingt.org http://tim.klingt.org Question: Then what is the purpose of this "experimental" music? Answer: No purposes. Sounds. John Cage

6 9

[Block Pointer] benchmark
by Phil Bouchard 27 May '11

27 May '11

Hi, Just for the records I have benchmarked block_ptr using: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/be… And I get the following: auto_ptr: 9208870 ns shared_ptr: 22958516 ns block_ptr: 75860365 ns Which is pretty good given the complexity it goes thru. I was wondering if there is any hope in having a pool::ordered_malloc() call of O(1) instead of O(n) and a faster pool::is_from()? The latter could be just a check to see if a pointer is within reserved memory pages of the pool. I tried to talk to the author of pool but I got no response. Thanks, -Phil

10 47

[release] 1.4.7
by Thomas Heller 27 May '11

27 May '11

Hi, Now that boostcon is over, what are the dates for 1.47? Thanks, Thomas

9 11

boost.move?
by Bryce Lelbach 27 May '11

27 May '11

Has been Boost.Move been accepted already? If so, can we squeeze it in for the next Boost release? -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

1 0

Boost Steering Committee
by Beman Dawes 27 May '11

27 May '11

There was a special session Friday morning at BoostCon 2011 to announce the formation of a Boost Steering Committee. The slides from that session have been annotated to make them more comprehensible to those not present. See http://tinyurl.com/3l27o3q (There is also a link on steering.boost.org, but DNS isn't resolving that yet for me. Instead use https://sites.google.com/a/boost.org/steering/) We haven't yet decided anything beyond what is on the slides, so it will take a bit of time before details emerge. As the slides mention, the first job of the steering committee is to design of its own operating procedures and policies. Input from the Boost community will help form those procedures and policies. The steering committee is an important change in the way Boost operates! We hope it will position Boost to continue to grow and prosper. --The Boost Steering Committee Beman Dawes Dave Abrahams Hartmut Kaiser Jeff Garland Jon Kalb Marshall Clow Robert Stewart Steven Wantanabe

3 2

[tokenizer] tokenizing by strings rather than chars
by Andrzej Krzemienski 27 May '11

27 May '11

Hi, I am facing a problem, and I wonder if Boost.Tokenizer, or any other Boost library solves it already. I want to parse numbers separated by "new-lines", however, on my windows system, a "new-line" is represented by two consecutive characters: 13, 10 (or in other words by string "\n\r"). So, only if I encounter a sequence of these two chars do I want to cut the token. boost::char_separator appears to be a bad choice, because it only "cuts" on single chars. Is there a solution to that problem in Boost? Regards, &rzej

3 3

iterator_facade triggers ADL, fails to compile
by Arno Schödl 27 May '11

27 May '11

Hello, the attached file arg_names.cpp fails to compile (VS2008) when using boost::lambda::_1 or boost::phoenix::arg_names::_1. The compilation succeeds when using boost::bind. All three variations are in the attached code for illustration. The compilation fails due to the presence of a templated operator& definition which is introduced by the instantiation of a class that is declared "andable" (from boost/operators.hpp). The compilation fails because iterator_facade triggers ADL in BOOST_ITERATOR_FACADE_INTEROP and finds the aforementioned operator& when comparing iterators that carry boost::lambda::_1 or boost::phoenix::arg_names::_1 as part of their type specification. In the example, this is illustrated by using filter_iterator. It is not clear to me what exactly the mechanism is that causes this ADL problem. But the static_cast in BOOST_ITERATOR_FACADE_INTEROP can be implemented using references instead of pointers, as shown below, which makes the problem disappear. In any case, using operator& on the iterator may be problematic if the iterator overloads operator&. --- C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/boost_1_46_1/boost/iterator/iterator_facade.hpp Wed May 25 11:42:14 2011 +++ C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/boost_1_46_1/boost/iterator/iterator_facade - Copy.hpp Wed May 25 11:41:49 2011 @@ -819,8 +819,8 @@ is_interoperable< Derived1, Derived2 >::value \ )); \ return_prefix iterator_core_access::base_op( \ - *static_cast<Derived1 const*>(&lhs) \ - , *static_cast<Derived2 const*>(&rhs) \ + static_cast<Derived1 const&>(lhs) \ + , static_cast<Derived2 const&>(rhs) \ , BOOST_ITERATOR_CONVERTIBLE(Derived2,Derived1) \ ); \ } Does anyone understand better what is happening? Or can we simply adopt the change? Regards, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

3 4

[local] couple questions
by Jeffrey Lee Hellrung, Jr. 27 May '11

27 May '11

1) I notice from http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… that (proposed) Boost.Local has a dependency on Boost.ScopeExit. It seems that Boost.Local provides all the functionality of Boost.ScopeExit, and then some; at least, that's what seems to be implied by http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… It would seem reasonable then, maybe, should Boost.Local be accepted, to remove the dependence on Boost.ScopeExit and officially deprecate Boost.ScopeExit in favor of Boost.Local's BOOST_LOCAL_EXIT: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… What are your (you = Lorenzo or anyone else) thoughts regarding that development path? 2) I haven't read through the docs in *too* much detail yet, but I would guess from, for example, http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… that copying a Boost.Local functor amounts to something less than a deep copy, and possibly an entirely shallow copy. In other words, does int x = 0; void BOOST_LOCAL_FUNCTION_PARAMS( bind(int) x ) { // bind x by value, so a copy is taken... std::cout << ++x << std::endl; } BOOST_LOCAL_FUNCTION_NAME(f) boost::function< void ( ) > g(f); f(); g(); print "1" followed by "2" (my guess), or does it print "1" twice? I may have missed it entirely, but I'd like the semantics of copying a Boost.Local functor explicitly spelled out. P.S.: I noticed in http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… a misspelling in the comments of the last example, s/BOOST_IDENTITY_VALE/BOOST_IDENTITY_VALUE/. - Jeff

2 1

[type_at] Variadic template utility
by tymofey 27 May '11

27 May '11

While experimenting with varidic templates of the upcoming standard i discovered that quite often one would need to extract a type from parameter pack at specified position. While the task is trivial it would be quite handy to have a ready tool for this purpose, rather that specifying one yourself every time. You can find source code consisting of a single header at Vault/Utilities/type_at.hpp The usage is simple: boost::type_at<index, some_type_0, some_type_1, some_type_2, some_type_n>::type corresponds to some_type_index where index is in range [0..n]. For example: boost::type_at<2, int, float, char, long>::type corresponds to char. I hope this will be useful.

5 6

Test results down for a little while
by Daniel James 27 May '11

27 May '11

Hi, I just noticed that the server load was pretty high because someone was spidering the test results. So I removed them for a little while (I don't have time to work how to block an IP address). They'll be back soon-ish. Hopefully, whoever was doing so will understand. If you want an offline copy of the test results, you should probably ask on the testing list, I'm sure we can work something out. Daniel

1 0

[ICL] Compile error when using "is_numeric"
by sguazt 27 May '11

27 May '11

Hi, I've just checked-out the last SVN version of ICL and after compiling with gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) (flags: -Wall -Wextra -pedantic -ansi) I get these errors: --- [error] --- boost-trunk/boost/icl/concept/interval_bounds.hpp:89:58: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/concept/interval_bounds.hpp:89:58: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ ... boost-trunk/boost/icl/concept/interval_bounds.hpp:104:58: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/concept/interval_bounds.hpp:104:58: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ ... boost-trunk/boost/icl/left_open_interval.hpp:52:64: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/left_open_interval.hpp:52:64: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ ... boost-trunk/boost/icl/open_interval.hpp:51:64: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/open_interval.hpp:51:64: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ --- [/error] --- To solve this problem, it seems it is sufficient to prefix the use of "is_numeric" with "typename". Here below is the diff file: --- [diff] --- Index: boost/icl/left_open_interval.hpp =================================================================== --- boost/icl/left_open_interval.hpp (revision 72177) +++ boost/icl/left_open_interval.hpp (working copy) @@ -49,7 +49,7 @@ // Only for discrete types this ctor creates an interval containing // a single element only. BOOST_STATIC_ASSERT((icl::is_discrete<DomainT>::value)); - BOOST_ASSERT((numeric_minimum<DomainT, is_numeric<DomainT>::value >::is_less_than(val) )); + BOOST_ASSERT((numeric_minimum<DomainT, typename is_numeric<DomainT>::value >::is_less_than(val) )); } /** Interval from <tt>low</tt> to <tt>up</tt> with bounds <tt>bounds</tt> */ Index: boost/icl/concept/interval_bounds.hpp =================================================================== --- boost/icl/concept/interval_bounds.hpp (revision 72177) +++ boost/icl/concept/interval_bounds.hpp (working copy) @@ -86,7 +86,7 @@ { if(is_left_closed(decl) && !is_left_closed(repr)) { - BOOST_ASSERT((numeric_minimum<Type, is_numeric<Type>::value >::is_less_than(low) )); + BOOST_ASSERT((numeric_minimum<Type, typename is_numeric<Type>::value >::is_less_than(low) )); return icl::pred(low); } else if(!is_left_closed(decl) && is_left_closed(repr)) @@ -101,7 +101,7 @@ { if(!is_right_closed(decl) && is_right_closed(repr)) { - BOOST_ASSERT((numeric_minimum<Type, is_numeric<Type>::value >::is_less_than(up) )); + BOOST_ASSERT((numeric_minimum<Type, typename is_numeric<Type>::value >::is_less_than(up) )); return icl::pred(up); } else if(is_right_closed(decl) && !is_right_closed(repr)) Index: boost/icl/open_interval.hpp =================================================================== --- boost/icl/open_interval.hpp (revision 72177) +++ boost/icl/open_interval.hpp (working copy) @@ -48,7 +48,7 @@ // Only for discrete types this ctor creates an interval containing // a single element only. BOOST_STATIC_ASSERT((icl::is_discrete<DomainT>::value)); - BOOST_ASSERT((numeric_minimum<DomainT, is_numeric<DomainT>::value >::is_less_than(val) )); + BOOST_ASSERT((numeric_minimum<DomainT, typename is_numeric<DomainT>::value >::is_less_than(val) )); } /** Interval from <tt>low</tt> to <tt>up</tt> with bounds <tt>bounds</tt> */ --- [/diff] --- Can you fix it? Thank you very much!! Best, -- Marco

2 4

Re: [boost] Mixing different versions of Boost libs in a single process
by Grund, Holger 27 May '11

27 May '11

Well, BoostCon is over. So let me try again focusing on some specific bits: > > So the next best thing would be the ability to mix different versions > of Boost in a single process. Today, linkage names will be identical > across versions, which is problematic for static libraries on Windows, > and static libs and DSOs on Linux. [..] > Also there's BCP, which supports renaming namespaces. That's great, but > I guess it could be even better -- e.g. on toolchains where we have > inline namespaces or __attribute__((strong)). On Linux targets, symbol > versioning via GNU LD version scripts might make things a bit better -- > specifically, in that things gone wrong fail earlier and with better > diagnostics. > So when I run BCP on the entire boost tree I still get linkage names that would seem to clash across versions. Specifically, there's the graphml_reader namespace in libs/graph/src/graphml.cpp. Boost.Python and Boost.MPI have symbols that could cause problems, though these would seems to come from external OpenMPI and Python headers. I haven't really looked but it seems these should be fine so long as we build against the same OpenMPI and Python versions with the same configuration. What's the policy here? Do we want BCP to address these things? Or do we want libraries to not use namespaces outside of ::boost (or use linkage/symbol visibility to hide symbols from other DSOs)? Are there any tools to detect this kind of problem? I have a few things check two binaries for potential conflicts by walking debug info and symbol tables -- it's far from perfect and I can't just upload this to Boost, but I'd be happy to help out, if there's interest to get something into the regression tests. Thoughts, anyone? Thanks! -hg -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

2 2

[random] recent changes causing failures in accumulators tests
by Eric Niebler 27 May '11

27 May '11

Many accumulators tests are now failing on both trunk and release. I have tracked it down to recent changes in Boost.Random. I don't know for how long this has been happening. The accumulators tests use the lagged_fibonacci607 random number generator. The tests work by sending a large amount of random data through various statistical accumulators and checking that the results are within a certain tolerance of what they would be if the data were actually random. In Boost 1.45 and previous versions, this worked. (I haven't tested 1.46.) Trunk and release are hosed, leading me to suspect that this random number generator is no longer producing sufficiently random data. I have verified this by replacing boost/random on trunk with the one from 1.45. With this change, the accumulators tests pass. Steven, this seems like a regression. Can you look into this? -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[pimpl] Modularity thoughts
by Gregory Crosswhite 27 May '11

27 May '11

Hey everyone, As I have stated I think that it pimpl is acceptable enough as is even though it might contain "too much" for advanced users. Nonetheless, having reflected on some of the other reviews I do have some thoughts on some changes that could be made to it to make it more modular, while still preserving a default "all-in-one" option for ordinary users. Take the pimpl struct: =========================== template<class Interface> struct pimpl { struct implementation; template<class> class value_semantics_ptr; template<template<class> class> class pimpl_base; typedef pimpl_base<value_semantics_ptr> value_semantics; typedef pimpl_base<boost::shared_ptr> pointer_semantics; static Interface null(); }; =========================== and replace it with something roughly like =========================== template<template<class> class> equality_ops; template<template<class> class> ordering_ops; template<template<class> class> null_ops; template<template<class> class> bool_ops; template<class Interface> struct pimpl { struct implementation; template<class> class value_semantics_ptr; template<template<class> class> class pimpl_base; typedef pimpl_base<value_semantics_ptr> value_semantics_base; typedef pimpl_base<boost::shared_ptr> pointer_semantics_base; struct value_semantics: public equality_ops<value_semantics_base>, public ordering_ops<value_semantics_base>, public null_ops<value_semantics_base>, public bool_ops<value_semantics_base> {}; struct pointer_semantics: public equality_ops<pointer_semantics_base>, public ordering_ops<pointer_semantics_base>, public null_ops<pointer_semantics_base>, public bool_ops<pointer_semantics_base> {}; static Interface null(); }; =========================== Now take out all of the operations from pimpl_base and put them in separate subclasses like so: =========================== template<typename pimpl_base_type> struct equality_ops : public virtual pimpl_base { bool operator==(equality_ops const& that) const { return (impl_ == that.impl_); } bool operator!=(equality_ops const& that) const { return !(impl_ == that.impl_); } }; template<typename pimpl_base_type> struct ordering_ops : public virtual pimpl_base { bool operator<(ordering_ops const& that) const { return pimpl_base_type::impl_ < that.pimpl_base_type::impl_; } }; template<typename pimpl_base_type> struct bool_ops : public virtual pimpl_base { operator safebool_type() const { return safebool(pimpl_base_type::impl_.get()); } }; template<typename pimpl_base_type> struct null_ops : public virtual pimpl_base { typedef typename pimpl_base_type::interface T; static T null() { return pimpl<T>::null(); } }; =========================== Now the user can mix and match whatever operations he or she likes like, or simply take the full package by default. Note that I have intentionally left out constructors in the above classes because they aren't needed: since we are using virtual inheritance, the user of this library will be calling the constructor of pimpl_base directly, so we don't even have to worry about generating lots of boilerplate to forward the constructor arguments up to the base. In fact, this actually makes using this library simpler in one respect: normally a downside of using virtual inheritance in general is that every derived class needs to call the constructors of all bases, but in the particular case of this library this turns out to be a feature rather than a bug! The documentation discussed how when initializing a derived class you essentially have to call the constructor of the immediate base class and then undo it by resetting the pointer and then filling it with the correct type, but since we are using virtual inheritance now we no longer need this awkward procedure since we can just skip over the constructor of the immediate base class and call the constructor of pimpl_base directly! This also further removes the need for implementations to support a "null" value. Finally, and most importantly, a strong advantage of this design is that it is extensible so users and library writers can define their own operation that they would like to add to classes and mix them right in. Anyway, these are just some thoughts that I had. :-) Cheers, Greg

1 0

[pimpl] Preliminary Review
by Gregory Crosswhite 27 May '11

27 May '11

Hey everyone, Here are my preliminary thoughts regarding the pimpl library. First, I like the idea of having it or something similar to it be part of Boost because the functionality seems like it would be useful in a lot of cases. One of the strengths of including such a library in boost in my opinion is that it will appear in the "Libraries" list, which means that more people will be exposed to the idiom and will think of it as a possible option than they would otherwise. Put another way, Boost is both a collection of libraries and of best practices, so a good pimpl implementation belongs in boost even if it is a relatively small one. Now the question is whether this particular implementation itself is good enough. Honestly, I have trouble figuring out exactly what it does except by reading through the code since the documentation itself doesn't say what it does behind the scenes except to say vaguely that it implements "pointer semantics" or "value semantics". So one thing that the documentation really needs (among the many others that have been mentioned) is a section that clearly lists the features that it offers. One objection that Artyom reasonably raised is that this implementation may try to do too much, and doesn't offer much in the way of customization. However, people like Artyom are most likely going to be rolling their own implementation of the pimpl idiom anyway. I think that it is sufficient that a implementation be "good enough" for an ordinary user's needs that they won't have to think about any of the ugly details since it does all of that work for them, and to the extent that this is true of the current implementation Now for my thoughts on the code itself. Two of the classes in the implementation should probably be reviewed separately and put in different Boost libraries rather than the Pimpl library, namely safebool and value_semantics_ptr. safebool is an interesting solution to the problem that implicit conversions to the "bool" type implies implicit conversions to hosts of other types such as integers which can result in all sorts of unexpected behaviors that will bite you when you least expect it. safebool solves this problem by providing a convenient way for you to implement an effective "bool()" by instead implementing an operator that returns a special function-pointer that is specialized to your class and thus is equal neither in type nor value to a safebool for any other class; a minor cost that is presumably incurred by this is that a small amount of code will be added to the binary for this special no-op function, since I don't see how this can be optimized away. The implementation looks straightforward and the comments contain good documentation explaining both the usage and the rationale. I would recommend that safebool be accepted into boost and added to the utilities library on its own merits. value_semantics_ptr is a class that contains a pointer to data (or possibly a null pointer) and has the semantics that upon assignment it copies the data from another pointer, allocating (or freeing) its internal pointer if necessary. I think that this is a good idea and that something like this belongs in boost, but I suggest that the current implementation should be changed at least as follows before being accepted: First, it should be taken out of the pimpl<> class and made independent. Second, the traits struct member should be changed from a derived class to a second parameter in the list of template arguments to the value_semantics_ptr type, with the deep_copy member being pulled outside and being made the default value of the new second template argument. Alternatively, a type function --- e.g., copy_traits<T> --- could be used instead. Third, if Boost::Move is going to be ready soon it would be ideal if this class could be modified to support it in order to potentially save some extraneous copies. Fourth, one of the methods confuses me and apparently also the author: bool operator<(value_semantics_ptr const& that) const { return this->impl_ < that.impl_; // Should it be "*this->impl_ < *that.impl_" instead? } so this should be finalized. Fifth, the implementation will need to be fleshed out. operators such as * (dereference) and -> will need to be added, as well as some additional typedefs such as value, pointer, reference, etc. Operator safebool() will also need to be added. In conclusion, if pimpl is accepted I think it would be better for there to be a polished value_semantics_ptr that we feel comfortable having be directly tested and exposed to users be the back-end of this class than something hidden away, so when value_semantics_ptr is ready I think that it should ultimately be accepted to the Smart Ptr library. So much for safebool and value_semantics_ptr, now on to pimpl itself. The code looks straightforward and the comments document it reasonably well --- in fact, the ratio of comments to code in the main pimpl class is roughly 2:1, and in that count I was lazily including whitespace and single { and } lines as code lines, so that gives you a sense of how heavily it is commented. I have only taken a quick glance through it since this is a pre-review, but it all looks simple and straightforward to me, and it does a good job of generating tedious boilerplate so the user doesn't have to, exactly as it claims. On a side note, one additional set of semantics that I would recommend adding is move semantics, which could be implemented using the Boost::Move library. In conclusion, I think that this library should be broken into parts with safebool being put in utilities, value_semantics_ptr (and we can bikeshed over the name here of course :-) ) being put in smart ptr, and pimpl being put in a separate library. After this is done pimpl will be quite small, but I think that it pulls enough weight that it is nonetheless useful. To repeat what I said earlier, boost is not just a repository of libraries but of C++ best practices, so even if pimpl is small if it does a good job of capturing the pimpl idiom I still think that it should be accepted into Boost. Cheers, Greg

1 1

Library Review Tool (paging Jeff Garland) -- was : Re: [xint] Formal Review Result
by Michael Caisse 27 May '11

27 May '11

On 05/03/2011 09:12 AM, Matthew Chambers wrote: > On 5/3/2011 11:02 AM, Marsh Ray wrote: >> On 05/02/2011 03:04 PM, Barend Gehrels wrote (in another order): >>> >>> There was somebody who recently mentioned a scoreboard on this list >>> and I now think this is a good idea, because the review manager can >>> check if all reviews are taken into account. >> >> Yes, please. >> >> It would also make it more practical for an observer like me to sit >> down and simply read the reviews >> in an orderly way. >> >>> I understand that the traffic was really high, that review managers >>> do this voluntary, everybody don't have all the time, etc. >>> >>> Reviews are usually carefully written. People spend several hours on >>> it, sometimes days. Skipping these reviews is a sad thing. Writing a >>> library cost weeks, sometimes months or more. Forgetting reviews is >>> a very sad thing. >> >> Honestly, I would be more likely to help review libraries if I felt >> like it wouldn't be buried in >> the volume of the list. > > This where mailing lists fall to pieces. With proper forum software, > moderators could easily organize threads and change subject lines so > that it would be trivial to separate actual reviews from discussion. > And in fact, users would quickly adjust their behavior to fit the > paradigm. Instead, we have hundreds of messages with "review" in the > subject and only some of them are actual reviews, most being > discussion (like this one!). :( > > -Matt > _______________________________________________ Some time ago we all had a discussion like this and I believe Jeff Garland had mentioned Smart Bear's CodeCollaborator to aid in Boost Reviews. I used their product for a short time and was just taking a look at their web site again: <http://smartbear.com/products/development-tools/code-review/features/> I know there are other tools also (like Crucible) but CodeCollaborator also allows reviews of html docs which will obviously be handy. IIRC Jeff had mentioned that SmartBear might be willing to provide licensing for Boost (or opensource .. it is all fuzzy). I believe Jeff was in contact with them... but my memory might be failing (Jeff?? Are you there?) I would be willing to investigate this path further, including the administration and such of the tool, if it is of interest to the community. michael -- In the Sacramento/Folsom area? ** Profesional C++ Training mid-May ** http://www.objectmodelingdesigns.com/boostcon_deal.html Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

8 13

[network] Review Manager - Volunteer
by Michael Caisse 27 May '11

27 May '11

Review Wizards - Dean Michael Berris and I spoke today about his Network library submission that is in the review queue. I am willing to act as Review Manager for the library which is also acceptable to Dean. If there are no objections, please sign me up. Thank you - michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

Re: [boost] [Math and numerics] interest in Circular values math and statistics library ?
by Greg Rubino 26 May '11

26 May '11

I like that idea. An integer version of this lib would be a good start for a boost lib that supports arbitrary finite groups (you get cyclic and dihedral for free). I think such a thing would probably be more generally described in terms of permutations though. Greg Rubino On May 26, 2011 5:18 PM, "Krzysztof Czainski" <1czajnik(a)gmail.com> wrote:

1 0

[pre-review] Pimpl submission in the review queue
by Vladimir Batov 26 May '11

26 May '11

I have a Pimpl generalization submission getting close to the top in the review queue. Rob Stewart suggested I'd post it to the new Boost Code Collaborator site for a pre-review. That's what I did with the following link to the pre-review (Review #5): http://demo.smartbear.com/boost/go?page=ReviewDisplay&reviewid=5 Your participation in that pre-review is most welcome. Best regards, Vladimir.

8 14

[phoenix] conflicts between result_of namespace and result_of class.
by Vicente Botet 26 May '11

26 May '11

Hi, I have found an error when we define new phoenix expression inside boost namespace. The following #include <boost/phoenix/core/limits.hpp> #include <boost/phoenix/core/call.hpp> #include <boost/phoenix/core/expression.hpp> #include <boost/phoenix/core/meta_grammar.hpp> #include <boost/phoenix/object/detail/target.hpp> #include <boost/proto/transform/lazy.hpp> #include <boost/phoenix/core/is_actor.hpp> BOOST_PHOENIX_DEFINE_EXPRESSION( // line 19 (boost)(convert_to) , (proto::terminal<boost::phoenix::detail::target<proto::_> >) (boost::phoenix::meta_grammar) ) results in darwin.compile.c++ ../../../bin.v2/libs/conversion_ext/test/builtins.test/darwin-4.2.1/debug/builtins.o builtins.cpp:19: error: ‘namespace boost::result_of { }’ redeclared as different kind of symbol ../../../boost/utility/result_of.hpp:35: error: previous declaration of ‘template<class F> struct boost::result_of’ builtins.cpp:19: error: ‘template<class F> struct boost::result_of’ used without template parameters builtins.cpp:19: error: expected unqualified-id before ‘<’ token It seems that the Phoenix result_of protocol and the utility result_of conflicts. Is this a real issue? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/phoenix-conflicts-between-result-of-name… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

Re: [boost] [ICL] some improvement proposals. Making selectors return const reference
by Joachim Faulhaber 26 May '11

26 May '11

Hi Denis, list, thanks for your interest in Boost.ICL and for your input. First a side note on the subject line: You did what is stated in the boost discussion policy http://www.boost.org/community/policy.html which says: Put the Library Name in the Subject Line [ICL] some improvement proposals. Actually as you can see on the list the convention that is actually established is [boost][Libraryname] bla bla for the developers list and [Boost-users][Libraryname] bla bla for the user's list. *Would someone update the web page accordingly?* Next I'd like to refer to a suggestion you've sent in off-list: 2011/5/16 Denis <denis(a)camfex.cz>: > Hi Joachim > > I also think that the functions upper() lower() first() last() have to > return const reference to domain_type instead of domain_type. > It is the same for int/double/time but has sense for my blobs. > Returning domain_type implies copying. > Same logic as std::vector's at(). This is interesting. With first() and last(), I don't think it is possible, because, dependent on the type of interval, we may generate a local temporary object via increment (++) or decrement (--), which can not be referred to. On the contrary for upper() and lower(), we should always be able to pass the constant reference of the member variables of the interval as return value. As you say, this avoids copying operations that might decrease efficiency, if domain_type objects are large. I think a modification to the code can be done without breaking existing code, at least I hope so. We could use typedef boost::call_traits<domain_type>::param domain_return_type as return type of lower() and upper(), so pass by value can be kept for built in types. Still I am kind of reluctant when I think of implementing this optimization: (1) Return by value works well and fast for the majority of applications where domain_type is built-in or small (2) Return by value allows for compiler optimizations that are taking care for copy elision in many cases. (3) It would be nicer if all selectors had the same signatures (simplicity). (4) Customization of intervals will become more obscure, less understandable by the new domain_return_type. (5) We'd increase expert-friendliness for a concern that is relatively local: Using ICL::intervals and interval_containers with large domain objects is unfavorable anyway. If efficiency is a mayor issue, we would have to consider not using the large objects directly in intervals but introducing a level of indirection. We may refer to them through (smart)pointers or iterators which are small and use an induced ordering for the interval containers for the Compare template parameter. x < y <=> (*x) < (*y) So I'm not shure what to do. Currently I tend to consider an implementation of the proposal. Thoughts? Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

2 2

Re: [boost] [Boost-commit] svn:boost r72166 - trunk/libs/thread/src/pthread
by Juergen Hunold 26 May '11

26 May '11

Hi Anthony, On Wednesday, 25. May 2011 23:19:01 anthony(a)justsoftwaresolutions.co.uk wrote: > Author: anthonyw > Date: 2011-05-25 17:18:59 EDT (Wed, 25 May 2011) > New Revision: 72166 > URL: http://svn.boost.org/trac/boost/changeset/72166 > > Log: > extern "C" functions are static > > Text files modified: > trunk/libs/thread/src/pthread/once.cpp | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > Modified: trunk/libs/thread/src/pthread/once.cpp > =========================================================================== > === --- trunk/libs/thread/src/pthread/once.cpp (original) > +++ trunk/libs/thread/src/pthread/once.cpp 2011-05-25 17:18:59 EDT > (Wed, 25 May 2011) @@ -22,12 +22,12 @@ > pthread_key_t epoch_tss_key; > pthread_once_t epoch_tss_key_flag=PTHREAD_ONCE_INIT; > > - extern "C" void delete_epoch_tss_data(void* data) > + extern "C" static void delete_epoch_tss_data(void* data) At least gcc-4.5.2 does not like this combination and bails out with: error: invalid use of 'static' in linkage specification gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) Please find a patch fixing this attached. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

1 0

[review][autoindex] AutoIndex review result
by Daniel James 25 May '11

25 May '11

The AutoIndex reviews were unanimously in favour of inclusion so it has been accepted into Boost. Reviews were submitted by: Edward Diener, Paul A. Bristow, Barend Gehrels and Hartmut Kaiser. Artyom also took part. Some of the general issues that were raised: The name should be more consistent. There was a little confusion about installation, but this should be easier once it's part of boost. Since it works at the docbook level it can be a bit confusing for a pure quickbook user. We might need to add extra support to quickbook - possibly in the form of a template library. There was some confusion about the integration of the different documentation tools, e.g. the use of <quickbook-define> to optionally include content in quickbook, using 'xinclude' to include doxygen documentation in quickbook. I think this is more of a weakness of the quickbook documentation. A few reviewers wanted finer grained control over where index terms are inserted. It isn't clear how this could be done without adding too much complexity. Adding processing instructions to the xml is one possibility. The C++ header scanner picks up too many symbols for spirit (and will possibly do so for other libraries), some kind of annotation or configuration might help. Thanks to everyone who participated in the review, and to John Maddock for developing AutoIndex, Daniel James

2 1

Boost.Conversion: functors namming
by Vicente BOTET 25 May '11

25 May '11

Hi, during the Boost.Convert after review discussion there were some proposals to use Boost.Phoenix to build the functors. My question is what should be the name of the function that builds the functor. Some possibilities: short s=1; long l=3; using boost::phoenix::placeholders::_1; A- Use a different name: make_converter_to? s=boost::make_converter_to(*short*)(_1)(l) ; B- Use the same name in a different namespace. What about using "fp" as namespace (functional programming). s=boost::conversion::fp::convert_to(*short*)(_1)(l) ; C- Use the same name in the same namespace and use SFINAE/enable_if to select the correct implementation depending on the parameter. s=boost::convert_to(*short*)(_1)(l) ; Which are your preferences? Best, Vicente

5 12

[type traits] issue with operator traits and volatile qualifier
by Frédéric Bron 25 May '11

25 May '11

Sorry for being absent during the last month but it was very hard to find any time to work on the addition of the operator traits. I have not yet had the time to deal with the naming issue... But I found something more tricky while trying to solve the issue of reference types (& was just ignored). I never used the volatile qualifier but I found that the following behaviour breaks the code that detects if an operator returns void or not. Could someone tell me why the following code does not compile? bool f() { } void g(const volatile bool &) { } int main() { g(f()); return 0; } Many thanks, Frédéric

3 2

Re: [boost] [Lambda] Handling Bind/Lambda name clashes.
by Max Sobolev 25 May '11

25 May '11

On 25.05.2011 15:49, Eric Niebler wrote: > (fixing attribution...) > > On 5/23/2011 11:42 PM, Robert Jones wrote: >> On Thu, Apr 7, 2011 at 3:01 PM, Steven Watanabe wrote: >>> At some point in time, Eric Niebler wrote: >>>> And what is wrong with leaving bind in the boost namespace as I was >>>> suggesting and define boost::function like this: >>>> >>>> namespace boost { >>>> namespace function_adl_block { >>>> template<class Sig> >>>> struct function {...}; >>>> } >>>> using function_adl_block::function; >>>> } >>>> >>>> Now the "boost" namespace is no longer associated with >>>> boost::function, >>>> and boost::bind won't be found by ADL. > > It's probably a good general policy to move most/all types in Boost into > ADL-blocking namespaces like above, except those for which there is > reason to keep boost as an associated namespace. cool technique (for building more modular software / libs)!

1 0

[chrono, trunk] linux compile fix
by Tim Blechmann 25 May '11

25 May '11

today's trunk does not compile correctly. this trivial patch fixes the issue: thanks, tim Index: boost/chrono/detail/inlined/posix/thread_clock.hpp =================================================================== --- boost/chrono/detail/inlined/posix/thread_clock.hpp (revision 72154) +++ boost/chrono/detail/inlined/posix/thread_clock.hpp (working copy) @@ -21,6 +21,7 @@ thread_clock::time_point thread_clock::now( ) { + struct timespec ts; #if defined CLOCK_THREAD_CPUTIME_ID // get the timespec associated to the thread clock if ( ::clock_gettime( CLOCK_THREAD_CPUTIME_ID, &ts ) ) @@ -31,7 +32,6 @@ clockid_t clock_id; pthread_getcpuclockid(pth, &clock_id); // get the timespec associated to the thread clock - struct timespec ts; if ( ::clock_gettime( clock_id, &ts ) ) #endif { @@ -49,6 +49,7 @@ } thread_clock::time_point thread_clock::now( system::error_code & ec ) { + struct timespec ts; #if defined CLOCK_THREAD_CPUTIME_ID // get the timespec associated to the thread clock if ( ::clock_gettime( CLOCK_THREAD_CPUTIME_ID, &ts ) ) @@ -59,7 +60,6 @@ clockid_t clock_id; pthread_getcpuclockid(pth, &clock_id); // get the timespec associated to the thread clock - struct timespec ts; if ( ::clock_gettime( clock_id, &ts ) ) #endif {

2 1

Re: [boost] [pre-review] Pimpl submission in the review queue
by Sean Chittenden 25 May '11

25 May '11

> I have a Pimpl generalization submission getting close to the top in the review > queue. Rob Stewart suggested I'd post it to the new Boost Code Collaborator site > for a pre-review. That's what I did with the following link to the pre-review > (Review #5): > > http://demo.smartbear.com/boost/go?page=ReviewDisplay&reviewid=5 > > Your participation in that pre-review is most welcome. Fantastic! I signed up and am anxious to see this library accepte^Wreviewed^Waccepted. I've been using the Boost.Pimpl interface for nearly a year now and have been very successful and happy with its use in my projects. Second to ASIO, Boost.Pimpl has done more to impact the design, structure and maintenance of my projects than any other library (the benefits of a stable ABI are understated). Its use in maintaining clean interfaces and projects can't be understated. Historically I'd always saved implementing Pimpl for external facing bits and had always rolled my own interface, now I use it for everything internal or external because of how easy it is to thump out a Boost.Pimpl based interface. As I said on the review site, I've moved the Pimpl implementation in to "boost/pimpl" directory with success, though was not able to move the Pimpl library under the boost namespace. Actually... let me post a quick example that I wrote to both learn and quickly teach how to use Pimpl: https://github.com/sean-/Boost.Examples/tree/master/pimpl It takes about 60sec-3min for most people to have their "ah ha!" moment with that example (those unfamiliar with Pimpl would be wise to check it out, imnsho). I didn't dive in to the why, but in the implementation it is necessary open your namespace after you have defined your private implementation (see pimpl/pimpl_example_pointer_impl.cc:35). It would be nice to know why this is the case (or if it's a bug). Pre-review feedback: The examples used in the Pimpl unit tests are very very good, but it takes a few minutes to wade through the polymorphism and to tease out the most basic requirements for starting to use Pimpl. Walking through 1K of code to do something very simple is a bit daunting despite the obvious and nearly immediate dividends. Whenever I started using this, it was one of the best few hours I've ever spent learning something new. I'm very pleased to see this library move forward and look forward to its formal review. -sc -- Sean Chittenden sean(a)chittenden.org

4 3

Re: [boost] [date_time] Time zone improvements
by Rutger ter Borg 25 May '11

25 May '11

Jeff Garland wrote: > Very cool :-) One question -- is there a portable solution where a user > could deploy a files onto a Windows system or is it a Unix only solution? > I'm fine with incorporating a *nix only solution because what your > suggesting will be a nice solution for *nix platforms, but it will need to > be clear that it's not portable. I don't see why it wouldn't be possible to deploy the (big-endian) binary files to any platform. Getting it into this binary form (using zone info compiler zic) may be harder to do cross-platform, but cygwin may help here. [snip] > As the primary maintainer of Boost date-time I can say with certainty that > there is interest in this functionality -- it's long been on my todo list > and I haven't had time to get to it. You can email me privately and we > can discuss all the details of how to get your code incorporated. I'll do! Regards, Rutger

5 9

Re: [boost] [ICL] some improvement proposals
by Joachim Faulhaber 25 May '11

25 May '11

Hi Denis, thanks for your input again. You're a good analyzer of code. Maybe you want to consider writing a code review for libraries that are submitted for formal review on the boost developer's list from time to time :) 2011/5/19 Denis <denis(a)camfex.cz>: > Hi > > 1. (questionable because it changes the visible interface): rename > `left_open` and `right_open` to `right_closed` and `left_closed`. > > Reason: interval_bounds is used in bitwise operations with bit=1 means > `closed`. (1) I tried to consider common usage of naming of intervals that is known from math. There seems to tendency to assume closedness as default, while openness is indicated by naming: [x, y] an interval (also closed interval) [x, y) a right open interval (x, y] a left open interval (x, y) an open interval. (2) The bits are chosen so closedness is indicated by 1 and openness is indicated by 0 11 [x, y] an interval (also closed interval) 10 [x, y) a right open interval 01 (x, y] a left open interval 00 (x, y) an open interval. > `left_closed() | open()` resulting in `left_closed()` is more readable than > `right_open() | open()` resulting in `left_closed()`. > > Also, there are checkers `is_left_closed()` and `is_right_closed()` but not > for *_open ... again following common usage [see (1)]. > I had to use `class bounded_value` in my program (as in Icl details: > calculating lower and upper bound of interval separately, then constructing > the interval, bitwise or'ing bounds) > and I commented every usage of `right_open()` as `left closed` in order to > explain why I use `interval_bounds::right_open()` in constructing the left > `bounded_value` of the interval. > This resulted in the idea of renaming. > > Maybe making bit=1 mean `open` would be less painful for other users ? You see me inconsolable to hear that you are suffering pain from my library =( There is an concept "interval_bound" http://svn.boost.org/svn/boost/trunk/boost/icl/concept/interval_bounds.hpp that allows you to combine and-ing or-ing etc. of interval_bounds directly. I think that'll reduce your suffering, at least I hope so. Yes, it's missing from the docs. Would you create a ticket? BTW, you may locally extend the concepts in the way you desire and add functions according to you naming rational. > 2. define `contains(interval, elt)` as `!below(interval, elt) && > !above(interval, elt)` allowing the user to use `below()` and `above()`. > Sometimes it is useful. (3) Thanks for this suggestion. The design of the icl::interval's interface is done under the general requirement of minimality. The concept approach allows you always to add own function templates locally to the concept if you need them. > Anyway, all the versions of `contains()` are made of checking for both > bounds. If you found a suboptimal function implementation, please refer them specifically. I'd appreciate a suggestion for an optimization. You can also create a ticket. > 3. It would nice if the functions taking two intervals will have versions > taking an element as second argument. > I mean functions like `left_subtract`, `operator &`, etc. (I cannot tell all > the list at the moment) > Constructing temporary `close_interval` object in order only to pass it into > those functions is cheap with ints but would be expensive with > heap-allocated domains (blobs, strings, etc). This is worth considering. In my own use of intervals within the implementation of interval containers I never encountered the need for such functions ... yet they may be useful in other situations. What do others think? Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

2 2

[Iterator] Constness of transform_iterator's dereference operator
by Michel MORIN 24 May '11

24 May '11

(In the previous mail, "function call operator" should be "dereference operator". Sorry for this, I fix it and resend a mail.) A long-standing request that transform_iterator should use boost::result_of will be resolved in Boost 1.47. This is really nice news, but I have a concern related to this. In the new code, transform_iterator uses result_of<UnaryFunc(typename std::iterator_traits<Iterator>::reference)> to determine the return type of a functor. However, since transform_iterator's dereference operator is const, result_of<const UnaryFunc(typename std::iterator_traits<Iterator>::reference)> should be used instead. There is a patch for this fix in #5127: https://svn.boost.org/trac/boost/ticket/5127 Alternatively, to remove this inconsistency, we can strip the constness of transform_iterator's dereference operator by either A. Make UnaryFunc member data mutable as suggested in #4969: https://svn.boost.org/trac/boost/ticket/4969 or B. Add non-const overloads to - transform_iterator's dereference() function - iterator_core_access' dereference() function - iterator_facade's operator*() Patches for A (make_mutable.patch) and B (add_nonconst_overloads.patch) are attached in this mail. Comments? Regards, Michel

1 0

Re: [boost] [pre-review] Pimpl submission in the review queue
by Jeff Garland 24 May '11

24 May '11

Mostafa wrote: >> If you want to use the Code Collaborator site to examine the library, you must create an account. The good news is that there are other libraries there that you can review, too. If you wish to avoid creating an account, then you can follow the link on the review schedule to the code in the sandbox. > > Some may just want to follow a review without necessary participating in one. Requiring a user account discourages such activity, and in my opinion, creates an artificial barrier to further engagement between newcomers, or even existing Boost watchers, and Boost, even if it is a one-sided engagement. > > My thoughts, > > Mostafa This is all getting a bit ahead of my post-boostcon report on the library in a week review activities, but to answer this particular issue I'd say 1) you need a login to participate in the mailing list, 2) it's essential for spam prevention, and 3) data can be periodically put to the list to mitigate this issue. Below is a report (minor formatting tweaks) of the pimpl review generated from code collaborator. I think in all likelihood using one of the modern review tools is going to create a better environment overall. Jeff ************* Overview ID: 5 Status: Inspection Title: Pimpl idiom generalization. Creator: Vladimir Batov Created On: 2011-05-23 15:13 Finished On: 2011-05-24 11:55 Total Person Time: 01:27:06 Wall-Clock Time: 20:34:38 Total Reviewer Time: 00:46:00 LOC All Versions (Uploaded/Changed): 2997/0 LOC Final Versions (Uploaded/Changed): 2997/0 Document Pages (All): 0 Document Pages (Final): 0 Number of Defects: 16 Number of Comments: 8 ************* Overview: Support for value and pointer semantics. Support for boost::serialization. Support for separate -- interface and implementation -- class hierarchies (the Bridge pattern in GoF). Support for internal (implementation-only) run-time polymorphism (Non-Virtual Interface Idiom). Support for delegating constructors. Tutorial. Doxygen-generated docs. Linux and VS2008. ************* Participants Name Role Person-Hours Vladimir Batov Author 00:13:17 Robert Stewart Reviewer 00:46:00 Sean Chittenden Observer 00:06:13 ************* Defect Log ID Creator File Location Type Severity Text D22 Robert Stewart pimpl.hpp Line 25 Interface Major Names with two consecutive underscores are reserved for the implementation D23 Robert Stewart pimpl.hpp Line 25 Style Minor This macro name should start with "BOOST_PIMPL_" D24 Robert Stewart pimpl.hpp Line 54 Interface Minor pimpl<T>::xxxx_semantics is interesting, but xxxx_pimpl<T> is simpler and more direct. D25 Robert Stewart pimpl.hpp Line 157 Interface Major Names with double underscores are reserved for the implementation D26 Robert Stewart pimpl.hpp Line 158 Interface Major Names with double underscores are reserved for the implementation D27 Robert Stewart pimpl.hpp Line 159 Interface Major Names with double underscores are reserved for the implementation D28 Robert Stewart pimpl.hpp Line 160 Interface Major Names with double underscores are reserved for the implementation D29 Robert Stewart pimpl.hpp Line 244 Interface Major Names with double underscores are reserved for the implementation D30 Robert Stewart pimpl.hpp Line 49 Interface Minor What about Pimpl support for classes with a base class? Your design requires multiple inheritance. You could, instead, do the following: class Book : public value_pimpl<Book, Base> { }; template <class T, class Base = null_type> class value_pimpl : public Base { }; template <class T> class value_pimpl<T,null_type> { }; D31 Robert Stewart pimpl.hpp Line 291 Interface Minor This exposes too much of the implementation to the user. A construct() member function set, like the set of constructors your macro now generates, with perfect forwarding (and variadic support, when available), would be better. construct() can call the new operator and save the pointer, thereby hiding those details from the user. D32 Robert Stewart pimpl.hpp Line 57 Interface Minor This exposes the pseudo-smart pointer semantics. It shouldn't be public and it should probably be named "nil" rather than "null." The idea is that nil() returns an object with no implementation rather than a null pointer. D33 Robert Stewart pimpl-use-cases.html Line 346 Documentation Minor "It is not but not a 100% kosher" is nonsensical. Presumably, you mean something like, "This design has some problems." D35 Robert Stewart pimpl-use-cases.html Line 357 Documentation Minor s/nut shell/nutshell/ D36 Robert Stewart pimpl-use-cases.html Line 364 Documentation Minor s/More,/What's more,/ D37 Robert Stewart pimpl-use-cases.html Line 385 Documentation Minor s/for vast majority/for the vast majority/ D38 Robert Stewart pimpl-use-cases.html Line 386 Documentation Minor You can avoid the subsequent "he/she" awkwardness by rephrasing this sentence: "However, putting both <i>book1</i> and <i>book2</i> in a <i>std::set</i> results in two elements rather than one, despite the fact that they are supposed to represent the same <i>Book</i>." Overall Review Conversation Sean Chittenden I've been using Boost.Pimpl for almost a year now with great success (using it in conjunction with MSM, ASIO and Spirit). This has been an incredibly useful library for minimizing the interfaces exposed across components. There are three things that I'd like to see but are largely trivial: 1) a set of clean-room examples of the two implementations (i.e. split out the unit tests from a set of examples for pointer and value semantics), and an example of how to use Pimpl once it has been moved in to the boost namespace (I took a crack at this and was never successful at moving Pimpl in to the boost namespace).

1 0

Implicit cast rules
by Gregory Crosswhite 24 May '11

24 May '11

Hey everyone, Would someone please explain to me the implicit cast rule that prevents the following from compiling, and/or if there is a way around it? #include <boost/optional.hpp> #include <iostream> using namespace boost; using namespace std; struct C { operator optional<int>() { return none; } }; int main() { C c; cout << static_cast<optional<int> >(c) << endl; return 0; } Error message: In file included from /usr/include/boost/optional.hpp:15, from cast-to-optional.cpp:1: /usr/include/boost/optional/optional.hpp: In member function ‘void boost::optional_detail::optional_base<T>::construct(const Expr&, const void*) [with Expr = C, T = int]’: /usr/include/boost/optional/optional.hpp:262: instantiated from ‘boost::optional_detail::optional_base<T>::optional_base(const Expr&, const Expr*) [with Expr = C, T = int]’ /usr/include/boost/optional/optional.hpp:559: instantiated from ‘boost::optional<T>::optional(const Expr&) [with Expr = C, T = int]’ cast-to-optional.cpp:13: instantiated from here /usr/include/boost/optional/optional.hpp:392: error: cannot convert ‘const C’ to ‘int’ in initialization I can tell what is happening; it would seem that the implicit cast rule selects the optional() constructor before it even looks at my more specific cast operator. I'm just confused about why this should be, since I see no reason why constructor casts should be prioritized over operator casts. Is this just the way it is, a GCC quirk, something I'm doing wrong, etc? Thanks! Greg

5 4

Towards a plan to reduce active tickets
by Vicente BOTET 24 May '11

24 May '11

Hi, I've inspected the number of tickets since the las Bug Sprint and we ca see that we are having a mean of 18 additional active tickets each month. month created closed diff 01/05/10 99 107 8 01/06/10 122 316 194 // Bug Sprint 01/07/10 103 56 -47 01/08/10 115 120 5 01/09/10 85 34 -51 01/10/10 105 91 -14 01/11/10 109 80 -29 01/12/10 83 92 9 01/01/11 98 79 -19 01/02/11 98 71 -27 01/03/11 161 107 -54 01/04/11 105 145 40 MEAN 106,2 87,5 -18,7 * MEAN is calculated since the last Bug Sprint, that is for the last 10 months. I don't know what could be done to instead of having more active tickets each month having less. While the Bug Sprints are useful I think that we need to have a plan to reduce them is a regular way. I know that a lot of people would be at BoostCon. It would be great if this subject could be discussed in one of the general sessions. if you have any suggestion, please replay to this post and share your view with the Boost community. Best, Vicente

7 7

[Iterator] Constness of transform_iterator's function call operator
by Michel MORIN 24 May '11

24 May '11

A long-standing request that transform_iterator should use boost::result_of will be resolved in Boost 1.47. This is really nice news, but I have a concern related to this. In the new code, transform_iterator uses result_of<UnaryFunc(typename std::iterator_traits<Iterator>::reference)> to determine the return type of a functor. However, since transform_iterator's function call operator is const, result_of<const UnaryFunc(typename std::iterator_traits<Iterator>::reference)> should be used instead. There is a patch for this fix in #5127: https://svn.boost.org/trac/boost/ticket/5127 Alternatively, to remove this inconsistency, we can strip the constness of transform_iterator's function call operator by either A. Make UnaryFunc member data mutable as suggested in #4969: https://svn.boost.org/trac/boost/ticket/4969 or B. Add non-const overloads to - transform_iterator's dereference - iterator_core_access' dereference - iterator_facade's operator() Patches for A (make_mutable.patch) and B (add_nonconst_overloads.patch) are attached in this mail. Comments? Regards, Michel

1 0

BoostCon 2011 in German IT news
by Boris Schaeling 24 May '11

24 May '11

I got BoostCon 2011 into the German IT news on http://www.heise.de/developer/artikel/developer_artikel_1247894.html. If someone wants to contact IT websites in other countries (after all as a C++ developer I want to read about things like BoostCon), have a look at the article. This should give you an idea how you could get in contact with websites and provide them the kind of news they want to publish. As the conference ended last week, it maybe makes sense to send out "press articles" again when the videos of the presentations are online. Boris

3 2

How to determine if a function with a given signature is declared?
by andrew.beck＠astc-design.com 24 May '11

24 May '11

Hi, Newbie question follows... I've used BOOST_MPL_HAS_XXX_TRAIT_DEF in the past but recently needed to determine if a function was defined with a given signature. Searching boost::mpl, stackoverflow etc, I couldn't find anything to do what I needed. I've attached my solution below. Basically, I'm wondering if there is a boost::mpl solution or some other more elegant solution. thanks, andrew #include <boost/mpl/bool.hpp> #include <boost/mpl/assert.hpp> #define XXX_DEFINED(symbol) \ template <typename T, T* = symbol> \ struct check_ ## symbol \ { \ typedef void type; \ }; \ \ template <typename T, typename enable = void> \ struct symbol ## _defined : \ boost::mpl::false_ \ { }; \ \ template <typename T> \ struct symbol ## _defined<T, typename check_ ## symbol<T>::type > : \ boost::mpl::true_ \ { }; // declare a some_func(int) so we can see if its declared... void some_func(int) {} // defines some_func_defined template XXX_DEFINED(some_func); BOOST_MPL_ASSERT(( some_func_defined<void(int)> )); // some_func(double) hasn't been declared BOOST_MPL_ASSERT_NOT(( some_func_defined<void(double)> ));

5 7

[function] Problem copying when constructed with a functor
by Edward Diener 24 May '11

24 May '11

This simple code: #include <boost/detail/lightweight_test.hpp> #include <boost/function.hpp> struct p_functor_class_int { p_functor_class_int() : data(50) { } int operator()() const { return data; } void operator()(int d) { data = d; } int data; }; int main() { boost::function<int ()> bfun(p_functor_class_int()); boost::function<int ()> bfun2(bfun); return boost::report_errors(); } gives compiler errors. On gcc-4.6 I get: "In file included from C:\Programming\VersionControl\boost/boost/function/detail/maybe_include.hpp:13:0, from C:\Programming\VersionControl\boost/boost/function/detail/function_iterate.hpp:14, from C:\Programming\VersionControl\boost/boost/preprocessor/iteration/detail/iter/forward1.hpp:47, from C:\Programming\VersionControl\boost/boost/function.hpp:64, from test_function_bug.cpp:2: C:\Programming\VersionControl\boost/boost/function/function_template.hpp: In static member function 'static R boost::detail::function::function_invoker0<FunctionPtr, R>::invoke(boost::detail::function::function_buffer&) [with FunctionPtr = boost::function<int()> (*)(p_functor_class_int (*)()), R = int]': C:\Programming\VersionControl\boost/boost/function/function_template.hpp:907:60: instantiated from 'void boost::function0<R>::assign_to(Functor) [with Functor = boost::function<int()> (*)(p_functor_class_int (*)()), R = int]' C:\Programming\VersionControl\boost/boost/function/function_template.hpp:722:7: instantiated from 'boost::function0<R>::function0(Functor, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type) [with Functor = boost::function<int()> (*)(p_functor_class_int (*)()), R = int, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type = int]' C:\Programming\VersionControl\boost/boost/function/function_template.hpp:1042:16: instantiated from 'boost::function<R()>::function(Functor, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type) [with Functor = boost::function<int()> (*)(p_functor_class_int (*)()), R = int, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type = int]' test_function_bug.cpp:15:37: instantiated from here C:\Programming\VersionControl\boost/boost/function/function_template.hpp:95:39: error: too few arguments to function C:\Programming\VersionControl\boost/boost/function/function_template.hpp:96:9: warning: control reaches end of non-void function [-Wreturn-type] " I am sure I must be doing something wrong but I can not see it.

3 5

Review Wizard Report for May 2011
by Ronald Garcia 23 May '11

23 May '11

============================================== Review Wizard Status Report for May 2011 ============================================== News ==== 1. Process Library Rejected 2. Phoenix Library Accepted 3. XInt Library Rejected 4. Type Traits Extensions Accepted 5. Locale Library Accepted 6. Convert Library Withdrawn 7. Conversion Library Accepted Provisionally 8. Context Library Accepted Provisionally 9. Boost 1.46.1 Released Revised Libraries: Asio, Filesystem, Fusion, Graph, ICL, Math, Polygon, Proto, Property Tree, Signals2, TR1, Unordered Revised Tools: Quickbook Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * AutoIndex(Tool) - reviewed May 2011; review manager: Daniel James. The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * GIL.IO - accepted January 2011; author: Christian Henning. * Type Traits Extensions - accepted March 2011; author: Frederic Bron. The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Phoenix - accepted March 2011; author: Joel de Guzmann. * Move - accepted February 2011; author: Ion Gaztanaga. * Geometry Library - accepted November 2009; author: Barend Gehreis et al. * Ratio - accepted October 2010; author: Vicente Botet. * Chrono - accepted January 2011; author: Vicente Botet. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Switch - accepted provisionally January 2008; author: Steven Watanabe. * Log - accepted provisionally March 2010; author: Andrey Semashev. * Context - accepted provisionally May 2011; author: Oliver Kowalke. General Announcements ===================== As always, we need experienced review managers. The review schedule has grown substantially but we have few volunteers, so manage reviews if possible and if not please make sure to watch the review schedule and participate. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Endian * Conversion * Sorting (M) * AutoBuffer * Containers * Lockfree * Fiber (M) * Quaternions, Vectors, Matrices (M) * Stopwatches * Variadic Macro Data (M) * Type Traits Introspection * Block Pointer (M) * Heaps * Assign v2 * Network (M) * Algorithm * Local (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: | `Boost Vault <http://www.boost-consulting.com/vault/index.php?action=downloadfile&fil…>`__ | http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Endian ------ :Author: Beman Dawes :Review Manager: Joel Falcou :Download: http://svn.boost.org/svn/boost/sandbox/endian/ :Description: Conversion ---------- :Author: Vicente Botet :Review Manager: Gordon Woodhull :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=co…>`__ :Description: Generic explicit conversion between unrelated types. Boost.Conversion provides: * a generic ``convert_to`` function which can be specialized by the user to make explicit conversion between unrelated types. * a generic ``assign_to`` function which can be specialized by the user to make explicit assignation between unrelated types. * conversion between ``std::complex`` of explicitly convertible types. * conversion between ``std::pair`` of explicitly convertible types. * conversion between ``boost::optional`` of explicitly convertible types. * conversion between ``boost::rational`` of explicitly convertible types. * conversion between ``boost::interval`` of explicitly convertible types. * conversion between ``boost::chrono::time_point`` and ``boost::ptime``. * conversion between ``boost::chrono::duration`` and ``boost::time_duration``. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=al…>`__ :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. AutoBuffer ---------- :Author: Thorsten Ottosen :Review Manager: Robert Stewart :Download: http://www.cs.aau.dk/~nesotto/boost/auto_buffer.zip :Description: Boost.AutoBuffer provides a container for efficient dynamic, local buffers. Furthermore, the container may be used as an alternative to std::vector, offering greater flexibility and sometimes better performance. Containers ---------- :Author: Ion Gaztanaga :Review Manager: John Maddock :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo…>`__ :Documentation: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h…>`__ :Description: Boost.Container library implements several well-known containers, including STL containers. The aim of the library is to offers advanced features not present in standard containers or to offer the latest standard draft features for compilers that comply with C++03. Lockfree ------------------ :Author: Tim Blechmann :Review Manager: Hartmut Kaiser :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo…>`__ :Documentation: http://tim.klingt.org/boost_lockfree/ :Description: Lockfree provides implementations of lock-free data structures. Lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. Lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. Lockfree provides: * boost::lockfree::fifo, a lock-free fifo queue * boost::lockfree::stack, a lock-free stack Fiber ----- :Author: Oliver Kowalke :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo…>`__ :Description: C++ Library for launching fibers (micro-threads) and synchronizing data between the fibers. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Stopwatches ----------- :Author: Vicente Botet :Review Manager: Anthony Williams :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=st…>`__ :Description: On top of the standard facilities of Boost.Chrono, Stopwatches provides: * Stopwatches: A facility to measure elapsed time with the ability to start, stop, suspend, or resume measurement. * Stopwatch concept * Scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. * stopwatch, model of Stopwatch capturing elapsed Clock times. * stopwatch_accumulator, model of Stopwatch capturing accumulated elapsed Clock times. * Stopclocks: a complete time reporting package that can be invoked in a single line of code. * stopwatch_reporter, convenient reporting to an output stream (including wide char streams) of the elapsed time of models of Stopwatch results. * stopclock<Clock> shortcut of stopwatch_reporter<stopwatch<Clock>> Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: The variadic_macro_data library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Type Traits Introspection ------------------------- :Author: Edward Diener :Review Manager: Joel Falcou :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/tti/>`__ :Description: The TTI library, which is an abbreviation for the 'Type Traits Introspection' library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Sandbox <https://svn.boost.org/svn/boost/sandbox/block_ptr/>`__ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Heaps ----- :Author: Tim Blechmann :Review Manager: Andrew Sutton :Download: http://tim.klingt.org/git?p=boost_heap.git;a=snapshot;h=HEAD;sf=tgz :Description: The Heap library is an implementation of priority queues, data structures that order their elements priority. They are useful in a number of different applications especially graph search algorithms and queuing systems. Whereas the STL provides a class template std::priority_queue, Boost.Heap implements data structures with different features and performance characteristics. One key feature is the inclusion of "mutable" heaps, which allow the priorities of enqueued objects to modified and their position in the queue updated. The heaps in the library also support merging, stable sorting, and equality and less-than comparison. Assign v2 --------- :Author: Erwann Rogard :Review Manager: John Bytheway :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/assign_v2>`__ :Description: This library is an upgrade of Boost.Assign 1.0 that redefines its functionality, with optional C++0x support and new features. It expresses repetitive statements for assigning or inserting elements via a basic grammar. Network ------- :Author: Dean Michael Berris :Review Manager: Needed :Download: http://cplusplus-soup.com/2011/04/18/cpp-netlib-0-9-0-released/ :Description: This is a library that provides application layer protocol support using modern C++ techniques. It is light-weight, fast, cross-platform and is intended to be as easy to configure as possible. Algorithm --------- :Author: Marshall Clow :Review Manager: Dave Abrahams :Download: `Boost Sandbox Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Boost.…>`__ :Description: Boost.Algorithm is a collection of general purpose algorithms. While Boost contains many libraries of data structures, there is no single library for general purpose algorithms. Even though the algorithms are generally useful, many tend to be thought of as "too small" for Boost. An implementation of Boyer-Moore searching, for example, might take a developer a week or so to implement, including test cases and documentation. However, scheduling a review to include that code into Boost might take several months, and run into resistance because "it is too small". Nevertheless, a library of tested, reviewed, documented algorithms can make the developer's life much easier, and that is the purpose of this library. Local ----- :Author: Lorenzo Caminiti :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/local/>`__ :Description: This library supports local functions, local blocks, and local exits Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

3 3

[exception] warnings on top of trunk
by Bryce Lelbach 23 May '11

23 May '11

/opt/boost/trunk/stage/gcc-4.4.4-release/include/boost/exception/detail/exception_ptr.hpp: In function ‘void boost::rethrow_exception(const boost::exception_ptr&)’: /opt/boost/trunk/stage/gcc-4.4.4-release/include/boost/exception/detail/exception_ptr.hpp:458: warning: ‘noreturn’ function does return Is it cool for me to remove this attribute? -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

5 5

[Review] Type Traits Extension by Frederic Bron - Review summary and decision
by Joel Falcou 23 May '11

23 May '11

Hello all, Frederic Bron's type traits extension proposal review ended up last week. In so far, we received SEVEN reviews which are all voting YES for the inclusion of Type Traits extension in Boost. So the result is that the Type Traits Extension is ACCEPTED into Boost. Suggestions include: - some clean-up in the implementation like "Renam[ing] the detail classes inside the specific namespace without using number, i.e. with a clear meaning. The use of tag, tag 2 could be renamed check_pass, check_fail or something like that." - Sensibility on cv-ref qualifiers in traits call is important. This is being addressed by Frederic. - Frederic is OK to keep the detection of void as a valid return type by using some dont_check type as default. - small comprehensive example of some of the traits like a "maybe_print function, which prints a value if the appropriate operator<< ostream overload exists, else prints "<NOT PRINTABLE>". [...] a small example like this would show a practical use of the library, and how to make use of enable_if, or some other overload method." - The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. This topic is still hot and alive. An alternative to the naming scheme consensus was proposed in the form of alias of commonly used operator traits. This issue is I think beyond bikeshed-color argumentation and I think it is a good point if Frederic could step up and provide a definite and rationalized answer to this point. The current status is : * the namespace options is out casue the standard didnt choose this way; * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open * the std:: like naming seems limited as not all operators are there. Thanks to all reviewers and people participating to the discussions. Thanks to Frederic for his work.

18 67

Small nitpick in boost::iterator
by Joel Falcou 23 May '11

23 May '11

Seems boost.Iterator pass some parameter by value in the make(Reference r) function. However, MSVC 2010 and I suspect below dont like passing value which alignment is greater than 8 ( **cough** SIMD vector **cough** ) The fix is trivial, adding const & to this function. Should I go ahead and commit this to trunk ?

4 4

[pool] pool-based allocators and order of destruction
by John Maddock 23 May '11

23 May '11

I'm looking for second opinions on this bug report: https://svn.boost.org/trac/boost/ticket/5526#comment:1 The issue is this: if you use singleton_pool either directly or indirectly (via [fast_]pool_allocator), there is a potential order-of-destruction issue if you use it from within globally declared objects. I *think* it's OK, if the global object directly uses the singleton pool - or is it? But, things get really nasty if it's used indirectly as in the bug report via a thread_specific_ptr - the latter gets destructed very late - much later than the pool which is used by the object it points to, so the result is a program crash on exit. In general though, anything that uses indirection and "late initialization, late destruction" will cause problems. I see a number of solutions: * Document the limitation and leave it at that. * Make the singleton eternal and leak the pool's memory at program exit. * Use some kind of complex reference counting scheme so the pool is only destroyed when all it's memory has been released *and* main has exited. To be honest, I'm not thrilled by any of the above, but any opinions? Thanks in advance, John.

3 3

Boost.Log status
by Vicente BOTET 23 May '11

23 May '11

Hi, what is going on Boost.Log? The library was accepted provisionally on March 2010 * Log - accepted provisionally March 2010; author: Andrey Semashev. Best, Vicente

7 18

[review][autoindex] AutoIndex review ends tomorrow
by Daniel James 23 May '11

23 May '11

Hello everyone, Just a quick reminder that Saturday 21st May is the final day for the AutoIndex review. I'm going to wait for one final review before announcing the result, but other than that you need to contact me by then. thanks, Daniel James AutoIndex Review Manager

2 3

Re: [boost] [ICL] some improvement proposals
by Joachim Faulhaber 23 May '11

23 May '11

2011/5/23 Denis <denis(a)camfex.cz>: > Hi Joachim. > I think, I explained badly and unclear the issue about contains(). > If you will have look at its implementation, you will find there a few > specialized versions of contains(), but all of them have structure of > handmadely inlined code `!below(interval, elt) && !above(interval, elt)`. So > it looks like those two functions are part of the minimal set, and > contains() made on top of them. I propose to have there the specialized > below() and above() and the general implementation of contains(). I understand. That would be a good refactoring making the code smaller and more concise. Good proposal :) Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

Fwd: [Boost-users] condensed overview of boost
by Joachim Faulhaber 23 May '11

23 May '11

---------- Forwarded message ---------- From: Joachim Faulhaber <afojgo(a)googlemail.com> Date: 2011/5/23 Subject: Re: [boost][Boost-users] condensed overview of boost To: boost(a)lists.org, boost-users(a)lists.boost.org Hi Olaf, Hallo Dresden, 2011/5/12 Olaf Krzikalla <olaf.krzikalla(a)tu-dresden.de>: > Hi @boost, > > recently I've given some lectures about some selected boost libraries. Thank you for teaching boost! (boo to the community for not answering for so long ;) > After > that the audience expressed the wish to get an overview over all current > boost libraries. Thus for my next lecture I sat down and digged through the > complete 1.46 for several day. I found a lot of useful stuff, but I also > found a lot of obsolete, superseded, replaced or will-be-superseded stuff. > Some libraries seems to be sub-libs of other libs. Is there an overview of > inner lib relations and the actual lib state wrt. to the overall > development? There is an overview on the boost web-site www.boost.org of course in an synoptic quality with short descriptions of each library. As far as I know there is no single documentation on inter library relationships that is maintained, correct me if I'm wrong. Generated dependency graphs were provided by Chrisoph Heindl in December 2008. http://lists.boost.org/Archives/boost/2008/12/146290.php http://picasaweb.google.com/christoph.heindl/BoostDependencies1370 for boost-1.37 but not updated later. > The issues I've found so far: > > - Compatibility: very narrow. Is it still needed as a public lib? > - Functional, MemFun: superseded by Bind > - Call Traits, Functional/Forward, Lambda: will be superseded by C++0x > - Interval: can this become a sub-lib of ICL? boost::numeric::interval is closed interval on numeric types with a focus on interval arithmetic. It is also suitable handle numeric precision problems AFAIK, but I'm not an expert for that. In contrast ICL has a focus on the set character of intervals and their composition in interval containers. Non numeric intervals are possible as long as there is an ordering on the domain_type. I think it is unfortunate that ICL and numeric::interval do not interplay well. One of the main obstacle are the fixed closed borders of numeric::intervals, that lead to problems when adding or subtracting intervals to and from interval containers. There were discussions on this on the list but the authors of numeric::interval seemed not to be active at the time. Since numeric::intervals serve numeric purposes and icl::interval serve more general pusposes I think they can coexist happiely. As long a numeric::interval is not actively maintained, I don't think there is a chanche for change. > - Meta State Machine / Statechart: whats the actual difference? I.e. Meta State Machine is a library that generates finite state machines completely at compile-time from meta code. MSN is more expensive at compile time but may generate even faster code than a "traditional" FSM. Maybe Christophe can comment on this. > which problem is solved by one lib but not by the other? > - Fusion & Tuple: how are these related? Could boost::tuple become a > typedef to boost::fusion::vector. > > I know that most of these relations are there for historical reasons and > won't be changed. However I wish it had been documented somewhere. That > would make an in-depth introduction of boost a lot easier. There is no ready made structure or institution within boost for this. But definitely there are people who have similar thoughts, concerns and intentions. It depends if someone is going to contribute and/or is taking the lead for an effort like this. As mentioned above Chrisoph Heindl provided generated dependency graphs. Boris Schäling wrote an online book http://www.highscore.de/cpp/boost/index.html that has been translated by others. Paul Bristow cares on documentation quality for the math stuff. Robert Ramey, Dean Berris and others had initiatives about redesigning the boost web-site, just to mention a few things. So your effort on creating an overview and document on inter library relationships could be an own contribution and other could join in. Thanks again, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

[ICL] interval_map::find(const domain_type_comparable&) instead of interval_map::find(const domain_type&)
by Denis 23 May '11

23 May '11

Hi Joachim One small note about Icl maps. I think would be useful to make interval_map::find()'s function accept any type comparable to map's key. For example, the key type is std::string and the user want to search using a 0-terminated string or a string defined as arbitrary pointer and a length. Then the user will have to allocate the temporary string only to pass it to interval_map::find() You may argue that the std::map works same way. But there is the difference. If I want to do the trick above, I can use boost::multi_index or at least instead of std::map<std::string, ValueT> I can define something like std::map<tuple<const char*, size_t>, tuple<std::string, ValueT>> with key's const char* and size_t pointing to the data hosted in value. This is not possible with interval_map, where the values can be joined

3 3

BoostCon video mirror
by Jeroen Habraken 23 May '11

23 May '11

Hi, After becoming annoyed with blip.tv I've created a mirror of the BoostCon videos with the help of Nikhef (http://www.nikhef.nl/en/) It can be found at http://wipkip.nikhef.nl/events/BoostCon/2010/ and there's a quick overview over at http://vexocide.org/boostcon.html. If desired we'll gladly host the 2011 videos as well. Regards, Jeroen Habraken

1 0

[process] boostcon code now on github
by Jeff Flinn 22 May '11

22 May '11

The source code as presented at the boostcon "Boost Process" session is now available at: https://github.com/JeffFlinn/boost-process Let me know if there are any problems accessing this as I'm a github newbie. Thanks, Jeff

1 0

[btree] Status report
by Beman Dawes 22 May '11

22 May '11

The slides for my BoostCon "Proposed Boost B-tree Library" presentation are available: http://github.com/boostcon/2011_presentations/raw/master/tue/proposed_b_tre… Please be aware that while the library is progressing nicely, it isn't ready for production use: * There are outstanding bugs, particularly with variable length data. * Names and signatures may still change. * Documentation is barely started. * Build is failing on Mac OS X. That probably won't get fixed until after BoostCon. (Reported by Marshall Clow) That said, the response to the presentation was very positive and I'm actively continuing development. Anyone interested in the library is encouraged to take a look and give it a try. See http://github.com/Beman/Boost-Btree/blob/master/README for install instructions. Feedback welcome! Thanks, --Beman

5 12

Invitation to connect on LinkedIn
by Илья Биин via LinkedIn 21 May '11

21 May '11

LinkedIn ------------Илья Биин requested to add you as a connection on LinkedIn: ------------------------------------------ Yuriy, I'd like to add you to my professional network on LinkedIn. - Илья Accept invitation from Илья Биин http://www.linkedin.com/e/bv6hcz-gnyytzl3-3y/uV9CsZkavY-uKU5A7C-1JbkavY-u5P… View invitation from Илья Биин http://www.linkedin.com/e/bv6hcz-gnyytzl3-3y/uV9CsZkavY-uKU5A7C-1JbkavY-u5P… ------------------------------------------ DID YOU KNOW that LinkedIn can find the answers to your most difficult questions? Post those vexing questions on LinkedIn Answers to tap into the knowledge of the world's foremost business experts: http://www.linkedin.com/e/bv6hcz-gnyytzl3-3y/ask/inv-23/ -- (c) 2011, LinkedIn Corporation

1 0

Invitation to connect on LinkedIn
by Serge Blazhievsky 21 May '11

21 May '11

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Serge Serge Blazhievsky Staff Software Engineer at LiveOps San Francisco Bay Area Confirm that you know Serge Blazhievsky https://www.linkedin.com/e/bv6hcz-gny8eb0s-6p/isd/2953122588/yo_3A_ww/ -- (c) 2011, LinkedIn Corporation

2 1

Boost statechart viewer
by Petr Šilhavík 20 May '11

20 May '11

Dear Boost-Statechart developers and users, I would like to ask you to try the tool that I am developing in my bachelor thesis and give me your opinion about it. The tool is able to visualize state machines that use Boost-Statechart library. It uses Clang and LLVM *(version 2.9)* for producing the output files that can be visualized using dot. Now it can work with states (not the orthogonal states), transitions and custom reactions. You can find more information about it on the web page of this project where you can also download the source codes and see some examples of the output pictures. http://rtime.felk.cvut.cz/statechart-viewer/ I am looking forward to your answers. Best regards Petr Silhavik

4 11

[Unicode] Library info
by Mathias Gaunard 20 May '11

20 May '11

Just a remainder for people that followed my Unicode presentation at Boostcon: Library is available on the Boost Sandbox: <https://svn.boost.org/svn/boost/sandbox/SOC/2009/unicode> Documentation is available here: <http://mathias.gaunard.com/unicode/doc/html/>

2 4

How to inspect state of boost::mt19937?
by Matthew Gwynne 20 May '11

20 May '11

Hi, Does anyone know how I can access the internal state of the Mersenne twister (boost::mt19937) easily? That is the 623 state bytes. I am looking to initialise a random number generator and then inspect the state to compare it to another system which apparently implements MT19937 but gives different results. If someone could point me in the right direction, that would be great! Thanks! Matthew Gwynne http://cs.swan.ac.uk/~csmg/

2 2

Generic try, catch in boost::lexical_cast
by Jeroen Habraken 20 May '11

20 May '11

Hi, Whilst updating SVN today I spotted a change to boost::lexical_cast, https://svn.boost.org/trac/boost/changeset/71958, which introduces a try { } catch(...) { } construction. I'm curious as to why this catch-all is needed since it seems to be there to deal with boost::numeric_cast exceptions and whether it could lead to a std::bad_alloc being rethrown as a bad_lexical_cast. Kind regards, Jeroen Habraken

3 5

[local] this_ or _this?
by Lorenzo Caminiti 19 May '11

19 May '11

Hello all, Boost.Local uses a special name `this_` to access the object `this` bound from the enclosing scope. Shall this name be `this_` or `_this` according to Boost practices? struct c { void g(int x) { ... } void f() { void BOOST_LOCAL_FUNCTION_PARAMS( (int x) (bind this) ) { this_->g(x); // <<<<<<<<< Shall this be `_this->g(x);` instead? ... } BOOST_LOCAL_FUNCTIO_NAME(l) ... } ... }; In particular, some library uses _ postfix for statements like mpl::if_ (not mpl::_if) while other uses _ prefix for variables like phoenix::local_names::_f (not local_names::f_). Thanks a lot. -- Lorenzo

12 21

Forum created for IDL to C++0x work
by Johnny Willemsen 19 May '11

19 May '11

Hi, Last year I posted on the boost list about ideas for a new IDL to C++0x language binding for CORBA/CCM/DDS. The OMG has issued a RFP for this (see www.omg.org) In order to share technical ideas, we have opened a forum on http://www.orbzone.org, the community portal for Corba, CCM, and related middleware technologies. If you have any ideas, please share them on ORBzone. Regards, Johnny Willemsen Remedy IT

1 0

anonymous svn checkout
by Mathieu Champlon 19 May '11

19 May '11

Hi, http://svn.boost.org/svn/boost seems to be asking for credentials, is it on purpose ? Thanks, MAT.

1 1

Fwd: [ICL] some improvement proposals
by Denis 19 May '11

19 May '11

Hi 1. (questionable because it changes the visible interface): rename `left_open` and `right_open` to `right_closed` and `left_closed`. Reason: interval_bounds is used in bitwise operations with bit=1 means `closed`. `left_closed() | open()` resulting in `left_closed()` is more readable than `right_open() | open()` resulting in `left_closed()`. Also, there are checkers `is_left_closed()` and `is_right_closed()` but not for *_open I had to use `class bounded_value` in my program (as in Icl details: calculating lower and upper bound of interval separately, then constructing the interval, bitwise or'ing bounds) and I commented every usage of `right_open()` as `left closed` in order to explain why I use `interval_bounds::*right*_open()` in constructing the *left `*bounded_value` of the interval. This resulted in the idea of renaming. Maybe making bit=1 mean `open` would be less painful for other users ? 2. define `contains(interval, elt)` as `!below(interval, elt) && !above(interval, elt)` allowing the user to use `below()` and `above()`. Sometimes it is useful. Anyway, all the versions of `contains()` are made of checking for both bounds. 3. It would nice if the functions taking two intervals will have versions taking an element as second argument. I mean functions like `left_subtract`, `operator &`, etc. (I cannot tell all the list at the moment) Constructing temporary `close_interval` object in order only to pass it into those functions is cheap with ints but would be expensive with heap-allocated domains (blobs, strings, etc).

1 0

[iostreams] OK to patch Mac OS X config problem?
by Beman Dawes 19 May '11

19 May '11

The following path fixes a problem that causes a B-tree compile failure on Mac OS X. Does anyone know any reason not to apply this? --Beman PS: Thanks to Marshall Clow for testing this. --- C:\Users\Beman\AppData\Local\Temp\rtl.hpp-revBASE.svn000.tmp.hpp 2011-05-18 22:23:07.000000000 -0400 +++ C:\boost\trunk\boost\iostreams\detail\config\rtl.hpp 2011-05-18 22:21:21.000000000 -0400 @@ -42,13 +42,13 @@ # define BOOST_IOSTREAMS_FD_OFFSET __int64 # else // Borland, Metrowerks, ... # define BOOST_IOSTREAMS_FD_SEEK lseek # define BOOST_IOSTREAMS_FD_OFFSET long # endif #else // Non-windows -# if defined(_LARGEFILE64_SOURCE) && \ +# if defined(_LARGEFILE64_SOURCE) && !defined(__APPLE__) && \ (!defined(_FILE_OFFSET_BITS) || _FILE_OFFSET_BITS != 64) || \ defined(_AIX) && !defined(_LARGE_FILES) || \ defined(BOOST_IOSTREAMS_HAS_LARGE_FILE_EXTENSIONS) /**/ /* Systems with transitional extensions for large file support */

1 0

[boostcon][proto] Suggestion for LIAW session: fixed-point numbers
by Ravi 19 May '11

19 May '11

Hi, Are there any proto-based ideas for the library-in-a-week sessions? If not, would building a fixed-point data type be of interest? The domain is narrow enough that something useful can be accomplished in 4 sessions, but of large enough scope to present opportunities for exploring proto in depth. A fairly simple design follows representing a number: fixed_number<int width, int ulp, // 2^{ulp} is the smallest increment possible bool signed, template assigner<first, last, signed> > 'assigner' handles rounding/truncation/wrapping/etc when assigning another number (floating-point or fixed-point) to the current one. Internally, each fixed-point number would be represented by a boost::uint64_t or a boost::int64_t (limiting the maximum precision allowed). As an example, fixed_number<5, -3, false> would represent a data type that would go from 0 to 3.875 in steps of 0.125. Proto would be used for creating all arithmetic operations since the return type of a+b could be different from the type of either a or b. A bonus would involve getting the fixed-point data type to play well with std::complex (and, yes, I am aware that std::complex is not designed to work with anything other than double and float, and will require specialization in the std namespace). If there is sufficient interest, I could even provide a starting point with +,-,* implemented; / would take more time. The design above is intended as a starting point for discussion and I am most definitely not wedded to it. I am a tyro when it comes to proto, and hence would need someone with more proto expertise to guide the discussion. Regards, Ravi

8 24

[mutex] move / merge
by Phil Bouchard 18 May '11

18 May '11

Hi, Although Block Pointer is now thread safe it could use some optimization. To do so it'll need some special operations on mutexes such as move and merge. The operations need to be atomic as well. I was wondering if this was already attempted. Thanks, -Phil

5 15

Bug #3831
by Chris Wilson 18 May '11

18 May '11

Hi there, I'm attempting to use the JSON parser to read in a JSON file, but I am running up against the problem described in bug #3831<https://svn.boost.org/trac/boost/ticket/3831>, even though this bug has been marked as fixed. The milestone on the ticket is marked as 'Boost 1.42.0', but is has a score through it and I'm not sure if that means it's been fixed in that milestone or if it's been retargeted at a different milestone. I am using version 1.42.0-4ubuntu2 of the libraries so I am wondering if I have an outdated installation, or if there's another reason why I don't have the patched version. Can anyone shed some light this please? Thanks, Chris

3 3

[range] strange behavior of operator== with iterator_range
by Bryce Lelbach 18 May '11

18 May '11

Can someone tell me if the behavior demonstrated in the following program is intentional or a bug in Boost.Range? -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

3 2

[chrono] Thread clock compatibility problems on Android
by Libor Bus 18 May '11

18 May '11

Hello, has anybody experienced also compatibility problems of chrono library on Android? I found following (Android 2.2, NDK-r5b, chrono v0.71, rev #71693): 1) Sources with boost::chrono::thread_clock does not compile, since _POSIX_THREAD_CPUTIME is not defined on Android. My workaround is to hack chrono/config.hpp: # if 1 //defined(_POSIX_THREAD_CPUTIME) # define BOOST_CHRONO_HAS_THREAD_CLOCK # define BOOST_CHRONO_THREAD_CLOCK_IS_MONOTONIC true # endif 2) ::clock_gettime() fails when called with clock ID got from pthread_getcpuclockid. My workaround is to call ::clock_gettime( CLOCK_THREAD_CPUTIME_ID, &ts ) in chrono/detail/inlined/posix/thread_clock.hpp. 3) Additionally there is precision problem on Linux platforms, stopwatch<process_cpu_clock> provides results with different units on Windows (nanoseconds) and Linux platforms (miliseconds). BR, Libor -- View this message in context: http://boost.2283326.n4.nabble.com/chrono-Thread-clock-compatibility-proble… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 17

Re: [boost] Help on 2 key search
by Vicente Botet 18 May '11

18 May '11

Renee wrote: > > HiAll > Being a newbie i request your help. > > I have a emp database. I store them based on emp id as well as ssn and > need to store their extended details. What datatype is best used to store > this info. I need to search through millions of emp recs that can be > searched by either ssn or by emp id. do suggest. > some fields are as below: > emp id > ssn > emp first name > emp last name > emp sal > emp age > if we use map can have just one key value so it can be either ssn or emp > id. using 2 maps one for ssn and emp record and another for emp id and emp > record is not efficient as there are millions of records. > ur help is appreciated. will multi index help in this case. do suggest. > > -Renee > Hi, If you need to realize search based on these two fields MultiIndex seems the appropriated structure. If emp_id is an integer (unique) the use of a non-ordered index could give you better performances. The major problem is how to ensure this id is unique. I guess that ssn stands for Social Security Number, which is too big to fall on a builtin, so a string will be need. Again the use of a good hash could improve the performances. HTH, Vicente P.S. This kind of questions are better answered on the Boost User ML or even on Stack Overflow. -- View this message in context: http://boost.2283326.n4.nabble.com/Help-on-2-key-search-tp3530830p3531660.h… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[variant] static_visitor deadlock
by Andrew Hundt 17 May '11

17 May '11

I believe I may have found a way to create a deadlock in static_visitor, but it may be my own mistake. It seems if I apply one static visitor within another with an extra call to operator() that I use for shared_ptr objects, the program deadlocks in apply_visitor_binary_invoke::internal_visit(). The template in my class below is another static visitor object, so in essence I am creating an effect similar to a java decorator using visitors. Here is a stripped down version of the class with which the deadlock occurs: /** * @class VisitorDecorator * * @brief decorates (wraps) a normal visitor */ template <typename T> class VisitorDecorator : public boost::static_visitor<typename T::result_type> { typedef typename T::result_type t_result_type; public: VisitorDecorator(boost::shared_ptr<T> deviceCommandVisitor, std::string filename): m_visitor(deviceCommandVisitor), m_filename(filename) {} /** * @brief strip shared pointers and handle the object itself */ template <typename U, typename V> inline t_result_type operator()( boost::shared_ptr<U>& deviceP, boost::shared_ptr<V>& commandP){ return operator()(*deviceP,*commandP); } /** * @brief Connect the specified struct types to the log file */ template<typename U, typename V> t_result_type operator()(U& device, V& command){ return (*m_visitor)(device,command); } private: boost::shared_ptr<T> m_visitor; std::string m_filename; }; Does anyone have thoughts or suggestions, be it my fault or a bug in the library? Cheers! Andrew Hundt

1 1

[introductions]
by Gregory Crosswhite 17 May '11

17 May '11

Hey everyone! I don't know what the protocol is for this, but since I have been posting occasionally for a while and have offered to be a Review Manager but am relatively unknown to the community (which, again, means that I will completely understand and won't be offended in the slightest if you politely decline my offer to be a Review Manager :-) ) and have never introduced myself I figured that now might be as good a time as any: I am a graduate student who will be finishing up my PhD in Physics in the next month. My field is roughly quantum computing/quantum simulation, and my specialty is writing software that solves problems in the field of quantum error correction. My web page, which gives an overview of my background, is here: http://students.washington.edu/gcross/index.html Cheers, Greg

6 7

[multi_index] Extending multi_index_container hash tables
by Vladimir Voznesensky 17 May '11

17 May '11

Hello there. Another question. Why nodes with similar values are grouped sequentially in non-unique hash table? It's rather a strong restriction leading to extra iterations during insertions and modifications (please, see link_point and in_place methods in hashed_index.hpp). -vv

1 0

[review] Formal review of AutoIndex starts 5th May
by Daniel James 17 May '11

17 May '11

Hello everyone, The formal review of John Maddock's AutoIndex starts tomorrow, 5th May and finishes on Saturday 14th May. It's a little different to normal as it's a review of a documentation tool, rather than a library. We'll follow the normal procedure. Hopefully the review will also provide some experience for deciding how to deal with other tools in the future. About AutoIndex =============== The documentation describes it as "a tool for taking the grunt work out of indexing a Boostbook/Docbook document that describes C/C++ code". The documentation is online at: http://svn.boost.org/svn/boost/sandbox/tools/auto_index/doc/html/index.html AutoIndex can be downloaded from the vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=auto_i… The download also contains a pdf of the documentation at 'doc/auto_index.pdf', and a copy of the html documentation at 'doc/html/index.html'. You can also see some examples of the indexes it generates, in a few libraries' documentation: http://www.boost.org/libs/spirit/ http://www.boost.org/libs/type_traits/ http://www.boost.org/libs/math/doc/sf_and_dist/html/ Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) with '[autoindex]' in the subject. Or if you don't wish to for some reason, you can send them privately to me. If so, please let me know whether or not you'd like your review to be forwarded to the list. All reviews are appreciated, even if you don't have time for an in-depth study. It's worth a look even if you don't use docbook or the boost documentation tools yourself. As someone who uses boost, the generated indexes are intended for your use so your views do matter. Even though this isn't a library, I think the (slightly modified) general guidelines still apply: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of AutoIndex? - Did you try to use it? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think that AutoIndex should be accepted into Boost? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. More detail on the review process is available at: http://www.boost.org/community/reviews.html I think it should be made clear that if accepted, there won't be any requirement to use AutoIndex it. Thanks in advance, Daniel James AutoIndex Review Manager

6 11

[review][autoindex] AutoIndex review extended
by Daniel James 17 May '11

17 May '11

Hello all, The AutoIndex review is extended for another week, it's now running until Saturday 21st May. This will hopefully give people who have been busy preparing for boostcon a chance to review it in a quiet moment. I'm also interested in hearing from people who won't be using the tool directly, but might be using the indexes it generates. Or perhaps already are, since it's already been used for Boost.Spirit, Boost.Type Traits and Boost.Math: http://www.boost.org/libs/spirit/ http://www.boost.org/libs/type_traits/ http://www.boost.org/libs/math/doc/sf_and_dist/html/ It doesn't need to be a long or in depth review to be useful. The documentation is online at: http://svn.boost.org/svn/boost/sandbox/tools/auto_index/doc/html/index.html AutoIndex can be downloaded from the vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=auto_i… thanks, Daniel James AutoIndex review manager

3 12

Boost talk / Funding / Your input is needed
by Ruediger Berlich 17 May '11

17 May '11

Dear all, at BoostCon 2011, I will give a presentation with the title and abstract: //---------------------------------------- Funding Boost development through national and international research programs and funds This presentation wants to start a discussion about possible ways of leveraging national and international research programs and funds to support Boost development. The goals are threefold: - To start and organize a joint effort in many countries to leverage national and international research funding schemes (e.g. NSF, European Union, …) for the benefit of Boost development - To make Boost a standard topic in the curricula of computer science education at universities and polytechnicals around the world - To involve new protagonists from the science community in Boost development //---------------------------------------- I think that this pretty much sums up what the presentation is about. I will, however, necessarily have to assume a (European and particularly German) view on this topic, as I have no experience with e.g. US academic funding schemes. The session is meant to be a brainstorming session and reality check; and without your input it will hardly be possible to fill 90 minutes for this topic. If you have first-hand experience with research grants and national or international funding schemes or if you have any related idea you would like to share, I particularly invite you to come along and contribute to the overall picture. I am sending this mail to the development list, as this is hardly a user- level issue. Thanks and maybe see you at the session, Ruediger Berlich

2 1

[Block Pointer] now thread safe!
by Phil Bouchard 17 May '11

17 May '11

Ok, Block Pointer is now thread safe! The following file was its test: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/th… It is now ready for a review. Thanks! -Phil

3 6

[siprit] Can't compile the following code with vs 2008
by 罗勇刚(Yonggang Luo) 16 May '11

16 May '11

/***************************************************************************** * * This file is part of Mapnik (c++ mapping toolkit) * * Copyright (C) 2009 Artem Pavlenko * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA * *****************************************************************************/ //$Id$ #ifndef MAPNIK_EXPRESSIONS_GRAMMAR_HPP #define MAPNIK_EXPRESSIONS_GRAMMAR_HPP // mapnik #include <mapnik/value.hpp> #include <mapnik/expression_node.hpp> // boost #include <boost/version.hpp> #include <boost/variant.hpp> #include <boost/shared_ptr.hpp> #include <boost/concept_check.hpp> //spirit2 #include <boost/spirit/include/qi.hpp> #include <boost/spirit/include/qi_action.hpp> //fusion #include <boost/fusion/include/adapt_struct.hpp> //phoenix #include <boost/spirit/include/phoenix_core.hpp> #include <boost/spirit/include/phoenix_object.hpp> #include <boost/spirit/include/phoenix_operator.hpp> #include <boost/spirit/include/phoenix_function.hpp> #include <boost/spirit/include/phoenix_stl.hpp> #include <boost/spirit/home/phoenix/object/construct.hpp> namespace mapnik { namespace qi = boost::spirit::qi; namespace standard_wide = boost::spirit::standard_wide; using standard_wide::space_type; struct unicode_impl { template <typename T> struct result { typedef UnicodeString type; }; explicit unicode_impl(mapnik::transcoder const& tr) : tr_(tr) {} UnicodeString operator()(std::string const& str) const { return tr_.transcode(str.c_str()); } mapnik::transcoder const& tr_; }; struct regex_match_impl { template <typename T0, typename T1> struct result { typedef expr_node type; }; explicit regex_match_impl(mapnik::transcoder const& tr) : tr_(tr) {} template <typename T0,typename T1> expr_node operator() (T0 & node, T1 const& pattern) const { #if defined(BOOST_REGEX_HAS_ICU) return regex_match_node(node,tr_.transcode(pattern.c_str())); #else return regex_match_node(node,pattern); #endif } mapnik::transcoder const& tr_; }; struct regex_replace_impl { template <typename T0, typename T1, typename T2> struct result { typedef expr_node type; }; explicit regex_replace_impl(mapnik::transcoder const& tr) : tr_(tr) {} template <typename T0,typename T1,typename T2> expr_node operator() (T0 & node, T1 const& pattern, T2 const& format) const { #if defined(BOOST_REGEX_HAS_ICU) return regex_replace_node(node,tr_.transcode(pattern.c_str()),tr_.transcode(format.c_str())); #else return regex_replace_node(node,pattern,format); #endif } mapnik::transcoder const& tr_; }; template <typename Iterator> struct expression_grammar : qi::grammar<Iterator, expr_node(), space_type> { typedef qi::rule<Iterator, expr_node(), space_type> rule_type; explicit expression_grammar(mapnik::transcoder const& tr) : expression_grammar::base_type(expr), unicode_(unicode_impl(tr)), regex_match_(regex_match_impl(tr)), regex_replace_(regex_replace_impl(tr)) { using boost::phoenix::construct; using qi::_1; using qi::_a; using qi::_b; using qi::_r1; #if BOOST_VERSION > 104200 using qi::no_skip; #else using qi::lexeme; #endif using qi::_val; using qi::lit; using qi::int_; using qi::double_; using standard_wide::char_; expr = logical_expr.alias(); logical_expr = not_expr [_val = _1] >> *( ( ( lit("and") | lit("&&")) >> not_expr [_val && _1] ) | (( lit("or") | lit("||")) >> not_expr [_val || _1]) ) ; not_expr = cond_expr [_val = _1 ] | ((lit("not") | lit('!')) >> cond_expr [ _val = !_1 ]) ; cond_expr = equality_expr [_val = _1] | additive_expr [_val = _1] ; equality_expr = relational_expr [_val = _1] >> *( ( (lit("=") | lit("eq") | lit("is")) >> relational_expr [_val == _1]) | (( lit("!=") | lit("<>") | lit("neq") ) >> relational_expr [_val != _1]) ) ; regex_match_expr = lit(".match") >> lit('(') >> ustring [_val = _1] >> lit(')') ; regex_replace_expr = lit(".replace") >> lit('(') >> ustring [_a = _1] >> lit(',') >> ustring [_b = _1] >> lit(')') [_val = regex_replace_(_r1,_a,_b)] ; relational_expr = additive_expr[_val = _1] >> *( ( (lit("<=") | lit("le") ) >> additive_expr [ _val <= _1 ]) | ( (lit('<') | lit("lt") ) >> additive_expr [ _val < _1 ]) | ( (lit(">=") | lit("ge") ) >> additive_expr [ _val >= _1 ]) | ( (lit('>') | lit("gt") ) >> additive_expr [ _val > _1 ]) ) ; additive_expr = multiplicative_expr [_val = _1] >> * ( '+' >> multiplicative_expr[_val += _1] | '-' >> multiplicative_expr[_val -= _1] ) ; multiplicative_expr = primary_expr [_val = _1] >> *( '*' >> primary_expr [_val *= _1] | '/' >> primary_expr [_val /= _1] | '%' >> primary_expr [_val %= _1] | regex_match_expr[_val = regex_match_(_val, _1)] | regex_replace_expr(_val) [_val = _1] ) ; primary_expr = strict_double [_val = _1] | int_ [_val = _1] | lit("true") [_val = true] | lit("false") [_val = false] | lit("null") [_val = value_null() ] | ustring [_val = unicode_(_1) ] * | attr [_val = construct<attribute>( _1 ) ]* * | '(' >> expr [_val = _1 ] >> ')'* *//These lines got errors!, The first line can be resolved by replace with * * attr [_val = ( _1 ) ], And I can't deal with the second line!* *//Even though, the first line I can't to be sure if the resolve is correct! * ; attr %= '[' >> +(char_ - ']') >> ']'; #if BOOST_VERSION > 104200 ustring %= '\'' >> no_skip[*~char_('\'')] >> '\''; #else ustring %= '\'' >> lexeme[*(char_-'\'')] >> '\''; #endif } qi::real_parser<double, qi::strict_real_policies<double> > strict_double; boost::phoenix::function<unicode_impl> unicode_; boost::phoenix::function<regex_match_impl> regex_match_; boost::phoenix::function<regex_replace_impl> regex_replace_; // rule_type expr; rule_type equality_expr; rule_type cond_expr; rule_type relational_expr; rule_type logical_expr; rule_type additive_expr; rule_type multiplicative_expr; rule_type not_expr; rule_type primary_expr; qi::rule<Iterator, std::string() > regex_match_expr; qi::rule<Iterator, expr_node(expr_node), qi::locals<std::string,std::string>, space_type> regex_replace_expr; qi::rule<Iterator, std::string() , space_type> attr; qi::rule<Iterator, std::string() > ustring; }; } // namespace #endif // MAPNIK_EXPRESSIONS_GRAMMAR_HPP -- 此致礼罗勇刚 Yours sincerely, Yonggang Luo

2 1

[multi_index] Extending multi_index_container hash tables
by Vladimir Voznesensky 16 May '11

16 May '11

Dear Joaquin, Dear all, Please, find the comments below. Joaquin M Lopez Munoz writes: > Vladimir Voznesensky<vvoznesensky<at> gmail.com> writes: > > >> > >> > Hello there. >> > >> > Current implementation of hashed index has, at least, two issues, preventing >> > me from re-using it in some places. >> > >> > First, the time for unlink operation in >> > multi_index/detail/hash_index_node.hpp is O(m) where m is a occupancy of the >> > given bucket. I'ts usually ok for unique index, but seems to hit performance >> > of removing item in a non-unique index. It's all because of using >> > single-linked list instead of double-linked one. >> > The question here is whether non-unique indices will be populated > with many equivalent elements or not: if the former, a singly-linked > list implementation such as that of Boost.MultiIndex certainly > degrades at erasure, but going to a doubly-linked list unncessarily > imposes a non-negligible penalty (one pointer per element) in the > latter case. Having to decide I chose to favor the former case. > I think it should be up to a user to choose: the usage pattern could be very specific (for instance, a LIFO pattern seems to work OK with the single linked machinery). > If you can contribute a Boost-quality modification of the implementation > that lets the user decide between singly-linked and doubly-linked > implementation (say with an extra template paramater in > the hashed<...> index specifier I can certainly add it to the > library. > I have some questions to discuss here. 1. The 1st obvious step is to realize a double- linked list near a single-linked one. I plan not to subclass any stuff from the current detail/hash_index_node.hpp, but use it as a near sample. Should I copy detail/hash_index_node.hpp to, say, detail/hash_index_dbl_node.hpp or use the same file for realization? It seems not to be a problem to add a concrete NodeImpl second template argument to a class bucket_array. 2. hashed_index.hpp arise some gentle problems. I could put another template argument into detail::hashed_index, hashed_unique and hashed_non_unique, but what kind should it be? It's seems possible to add NodeType template argument to class hashed_index without breaking up BOOST_MULTI_INDEX_ENABLE_SAFE_MODE stuff, but how should we pass such sophisticatedly formed type from the final API? detail::hashed_index_args looks like a template hell. So, maybe it would be wiser to just introduce struct hashed_dbl_unique and struct hashed_dbl_non_unique extra variants? > Hahsed indices have the following bucket-handling interface: > > // bucket interface: > > size_type bucket_count()const; > size_type max_bucket_count()const; > size_type bucket_size(size_type n)const; > size_type bucket(const key_type& k)const; > > local_iterator begin(size_type n); > const_local_iterator begin(size_type n)const; > local_iterator end(size_type n); > const_local_iterator end(size_type n)const; > const_local_iterator cbegin(size_type n)const; > const_local_iterator cend(size_type n)const; > > local_iterator local_iterator_to(const value_type& x); > const_local_iterator local_iterator_to(const value_type& x)const; > > (See > http://www.boost.org/libs/multi_index/doc/reference/hash_indices.html#hash_…) > Is this not what you're looking for? > It's not clear from the docs and the sources, how to, say, insert a new element before or after a given one. Thank you.

1 0

Conversion/Enums/Opaque request for interest
by Vicente BOTET 16 May '11

16 May '11

Hi, Lastly I've been working on 3 Boost libraries proposals. * Boost.Conversion (https://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/…) * Boost.Enums (https://svn.boost.org/svn/boost/sandbox/enums/libs/enums/doc/html/index.html) * Boost.Opaque (https://svn.boost.org/svn/boost/sandbox/opaque/libs/opaque/doc/html/index.h…) Boost.Conversion manages with generic explicit conversion between unrelated types. The template function convert_to allows to convert a source type to a target type, using argument dependent lookup (ADL) to select a specialized convert_to function if available. If no specialized convert_to function is available, boost::conversion::convert_to is used. Boost.Enums intends to provide a partial solution to the scoped enums problem ensuring a portable solution compatible with compilers supporting natively scoped enums or not. In addition provides a framework to view enumerations as ordinal types so we can define some specific and efficient enum containers. Boost.Enums is composed of the following parts: * Scoped enums * Ordinal enums * Enum containers * MPL enums * String <-> Enum conversions Boost.Opaque intends to provide a library partial solution to "opaque typedefs". Boost.Opaque provides: * a generic mixin class hierarchy which can be specialized by the user to make new opaque classes. * a generic class hierarchy which can be instantiated by the user to make new opaque typedefs. * a meta-mixin concept that allows to compose in a easy way several aspects of a class in an orthogonal way. * a considerable number of meta-mixins that helps defining new types from an underlying type * Some helper macros that can reduce the declaration of a new opaque type to a single line, emulating the language-based approach. Boost.Opaque and Boost.Enums depend in some degree on Boost.Conversion. These are quite basic libraries that any of you could find useful (or not) and that are not associated to a complex domain, so any of you could have an opinion without spending too much time. Please follow the above links to have a better idea of the motivation of these libraries. Before continuing completing the design, docs and tests of these libraries I would like to know if there is an interest on these libraries and if you have any suggestion on how to improve them, you see something missing or that should be removed. This will help me a lot to concentrate my efforts on the library that reveals more interest. Any comment will really be appreciated. Thanks, Vicente

7 10

Status of make_shared_array
by Joe Dougherty 16 May '11

16 May '11

Hello; Roman Kecher started a thread<http://lists.boost.org/Archives/boost/2009/11/158170.php>in November 2009 regarding the creation of a boost::make_shared_array() function to complement the boost::make_shared()function. What is the status of this addition to the boost library? Thanks Joe

1 0

[Range] Support for array references, svn:executable on headers
by Bryce Lelbach 15 May '11

15 May '11

Boost.Range does not support array reference types. I'd like to add the specializations/overloads/code to Boost.Range to support array reference types (I have commit rights). Neil, is this alright? Does anyone see any see any problems with such changes? (some) of the places where changes are needed: 2011.05.13_18.45.33< VeXocide> it works perfectly fine with char const [5], but not with char const (&)[5] [snip] 2011.05.13_18.47.12< VeXocide> this probably means it's missing a whole bunch of specializations, because the other functions don't seem to support it either [snip] 2011.05.13_18.57.41< wash> VeXocide: where else do you believe changes would need to be made? 2011.05.13_18.58.43< VeXocide> wash, as far as I can tell (I've only checked a few) all functions at http://www.boost.org/doc/libs/1_46_1/libs/range/doc/html/range/reference/co… and http://www.boost.org/doc/libs/1_46_1/libs/range/doc/html/range/reference/co… need to have the specializations added 2011.05.13_18.59.49< VeXocide> an, range_end supports T (&a)[sz] 2011.05.13_18.59.51< VeXocide> ah * 2011.05.13_19.00.12< VeXocide> hmz 2011.05.13_19.01.42< VeXocide> range_difference doesn't 2011.05.13_19.01.53< wash> *nods* 2011.05.13_19.02.30< VeXocide> range_iterator and range_const_iterator don't either 2011.05.13_19.04.12< VeXocide> hmz One test case demonstrating the problem: #include <boost/range.hpp> #include <iostream> #include <typeinfo> int main(void) { std::cout << typeid(boost::range_size<char const (&)[5]>::type).name() << std::endl; return 0; } P.S. A number of the headers in Boost.Range have the svn:excecutable property. Can I remove this property from said headers? -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

4 4

Need second opions from some threading / object creation experts...
by John Maddock 15 May '11

15 May '11

Folks, I'm looking at the code for singleton_pool, and I can't *quite* convince myself that it's completely thread safe and guaranteed to do what it says, the code in question is in boost/pool/detail/singleton.hpp which is a deceptively clever/simple singleton implementation. I haven't been able to break it in practice, but would a sufficiently clever compiler be able to optimize away the call create_object.do_nothing(); and therefore not instantiate the object prior to main()? Thanks in advance, John.

3 5

[phoenix] Creating a download for boostcon
by Daniel James 15 May '11

15 May '11

I'm looking to create the download for boostcon either tonight or tomorrow. I'll probably do it myself rather than using the nightly downloads so that it will include the geometry documentation. Since there were changes to phoenix since the regression test were last run, we need to check that it has been manually tested on all the popular platforms first. I'll run the phoenix (and spirit?) tests on OS X if that will help.

5 12

[Block Pointer] single threaded
by Phil Bouchard 15 May '11

15 May '11

Hi, What if Block Pointer was single threaded for the moment? Would that prevent it from being part of Boost? A lot of applications are single threaded and could take advantage of it already. fast_pool_allocator is not multithread safe as well. The problem is the structure keeping track of each set, block_header, is dynamic (gets created and destroyed over and over) and to maintain a mutex in such conditions is not trivial. Thanks, -Phil

1 0

Mixing different versions of Boost libs in a single process
by Grund, Holger 15 May '11

15 May '11

Hi, I've been looking into how we can improve our own usage of Boost libraries and there's one thing that's been sticking out. We typically have often lots of components running in a single process. Many of these components are developed on different release schedules and while there's certainly demand to adopt later Boost versions, the logistics required to move all of these at the same time is a big headache. Now, while I haven't seen any official word on it, I've always assumed there's no binary compatibility guarantees whatsoever between Boost versions. It's been my impression that there may be a few or even a lot of folks who would be happy to see binary compatibility, but it's unlikely to happen anytime soon. So the next best thing would be the ability to mix different versions of Boost in a single process. Today, linkage names will be identical across versions, which is problematic for static libraries on Windows, and static libs and DSOs on Linux. I remember discussion about making use of GCC's visibility attribute. This would certainly be a step in the right direction. I can't find the page I'm thinking of right now (pointers anyone?). Anyhow, what's the status of this? Also there's BCP, which supports renaming namespaces. That's great, but I guess it could be even better -- e.g. on toolchains where we have inline namespaces or __attribute__((strong)). On Linux targets, symbol versioning via GNU LD version scripts might make things a bit better -- specifically, in that things gone wrong fail earlier and with better diagnostics. Lastly, there's the problem of interop. Say libfoo built with Boost Version 1.40 provides an API like: boost::some_class make_some_object(); If I want to use this in my component where I use Boost Version 1.50, how do I do it? I can think of a few of approaches, none of which really fully convinces me. Consider the same API as a virtual member function, where no linkage name is involved (assuming boost::some_class changed in some relevant way). What to do there? And how to detect this in the first place? There might be other problems like having two different instances of a singleton for two libs in process, or something completely different I haven't thought of. Is there any work going on in this area? Any interest? Thanks! -hg Holger Grund, Vice President Morgan Stanley | MS Strats and Modeling 25 Cabot Square | Canary Wharf | Floor 03 London, E14 4QA Phone: +44 20 7677-4095 Holger.Grund(a)morganstanley.com -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

1 0

[ICL] How to define infinite endpoint for the types without infinity?
by Joachim Faulhaber 15 May '11

15 May '11

Hi all, Denis raised a question concerning handling of infinities in icl::intervals in an off list email conversation. I thought this could be of greater interest so I am posting it here. > On Sat, May 14, 2011 at 4:23 PM, Joachim Faulhaber > <afojgo(a)googlemail.com> wrote: > >> 2011/5/14 Denis <denis(a)camfex.cz>: >>> Hello. >>> >>> Boost.Icl has four interval types: closed [a,b] for a<=x<=b, open >>> (a,b) for a<x<b, left-open (a,b] for a<x<=b, rigth-open [a,b) for >>> a<=x<b. >>> >>> That's enough for types which have explicit minimal and maximal >>> values: double, all integers, boost::time_interval, boost::ptime, ... >>> But there are types like string and vector, which have the minimal >>> value (i.e. empty string) but not the maximal one. It makes impossible >>> to define an interval with infinite right endpoint. Intervals (and >>> intervals with infinite right end) have sense for strings end vectors, >>> for sharding. >>> >>> Simplest solution looks like to use tuple<bool, string> in place of >>> string (true means infinity so such a pair will be bigger than any >>> string). But it will force me to use the pair instead of string >>> everywhere in the program (or to create pairs before any interval >>> operation, which implies string copying). >>> >>> Is there a better solution? Maybe to add a 5th and 6th interval types >>> into Icl: closed_to_infinity [a,+inf) and open_to_infinity (a,+inf) ? >>> >>> I asked also here: >>> http://stackoverflow.com/questions/6000655/boost-icl-how-to-define-infinite… >>> >> >> Hi Denis, >> >> thank you for using Boost.Icl. The point that you are addressing is an >> interesting one and I was thinking about the integration of infinities >> while developing the library a few times. Introducing infinity for >> icl::intervals has some problems. We would have to check for the >> infinity condition in almost every function, which makes the code more >> clumsy. >> >> I decided not to do this for pragmatic reasons: In most applications >> of intervals and interval containers infinity is not needed or can be >> replaced by a value that represents some sufficient maximum. So I >> thought that this situation does not justify to bloat the code of the >> interval concept by code related to infinities. >> >> I'd be nice if you could provide a small and compelling example using >> interval containers, where infinities are really needed and can not be >> replaced by some simple pragmatic means. I am always interested in >> those use cases to demonstrate the possibilities and check the limits >> of the usefulness of the ICL. In case you do and the example shows a >> new important use case I will add it to the library's docs and give >> credit to you as the author. >> >> This was the short answer. If this is o.k. for you, I will provide a >> longer answer later this weekend and send it to the boost developers >> and users list and also stack-overflow, because I think the topic is >> of interest to others as well. >> >> Thanks again, >> Joachim >> > > 2011/5/14 Denis <denis(a)camfex.cz>: > Hi Joachim > > Well. > That's all very depend on do we need to add both infinities or only +infinity. > I need intervals with open end for arbitrary byte vectors, but I > cannot imagine what negative infinity can be used for. > Seems like all the types with negative infinity already have an > explicit representation of the minimal value (maybe even signed > biginteger?). a limitless integer implementation can not have a fixed min and max, of course, and whether it has a special value for +/-infinity is up to the library author. To be able to express both infinities might be interesting even for types like built in integers that have their min and max values. > So, hereinafter I talk only about the possibilities of adding +inf as > endpoint of intervals. > And I assume that the domain type has its minimal value. > > I have just made a small patch (about 30 lines) marking +inf in a bit > in `interval_bounds` for dynamic bound intervals. > It has little overhead (the bit is checked only in `bounded_upper()` > `is_empty()` `exclusive_less()` `contains()` `upper_less()` and > `operator <<()`) and enabled only for intervals which are dynamic > bound and continuous. I see that you have tried to keep the impact of the intended infinity-extension of the code small... > As a future optimization, the continuous realm can be divided to > double-like and string-like ones in order to avoid checking this bit > for double-likes. ... and thought even further, which is nice. > Also it not easy to talk about performance when it comes to types like > strings or vectors. > Using something like "\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF".... to > represent the maximal blob could be slower and buggy than just an +inf > bit . > > > About the static intervals. > > In the classes `right_open_interval` and `open_interval`, if `_upb` > contains domain's unit value it comes to an empty interval > irregardless what is in `_lwb`. nifty considerations ... > This is not the only way to represent empty interval, any `_lwb` <= > `_upb` would also work. > > So those extra invariants can be used to store infinity without adding > extra fields to the static intervals classes. ... nifty but tricky > Domain's unit in `_upb` can represent +inf, and be seen by comparison > functions as the biggest value, but still the smallest when it is in > `_lwb`. > The case of both `_lwb` and `_upb` having unit will represent the > whole interval so user's tries to construct a empty interval > specifying two units (`open_interval("", "")`) should be corrected in > the constructors (to "\1","\1") > > In order not to impact the performance of the existing > `right_open_interval` and `open_interval`, two new classes > `right_open_interval_with_inf` and `open_interval_with_inf` can be > created by copying with small patching of the comparators and the > constructors. hmm... your posting is interesting with respect to different aspects. You are obviously using icl::intervals (and I guess also icl::interval_containers) with domain types of some types like string and (byte)vector. It was my ambition to allow for such types as domain types in addition to numbers. Of course you have to watch efficiency, if your values get large (not to mention approaching infinity ;) Because you are using icl in this realm you might experience difficulties and even detect bugs that no one else has found. Also you might explore properties of the underlying concept, which is the concept of a sequence, I guess. As I wrote in my first answer, I'd be very much interested in a short compelling example for the tutorial that demonstrates the kind of use case that you cover. It might be kind of unique and open up a new horizon of icl usage. I think it is a good idea to implement infinity as a property of intervals instead of using special values. I had similar considerations, but as I mentioned earlier, I didn't do that for pragmatic considerations. I think a real need to work with infinities does not occur in most applications. And even if someone want's to use them, it is always only a phenomenom that applies to the very first or last interval of an interval container. It might be true that by good design and use of metaprogramming we might be able to limit the impact a infinity extension to just a few functions and I acknowledge you tried to demonstrate that. Still these are functions (e.g. exclusive_less) that are called extremely frequently. So there is performance penalty also on those majority of instances where infinities are not needed at all. I appreciate your ideas but I guess I need some more time to think about them. One possibility might be to create a concept for infinity bounded intervals on top of dynamic intervals. So only users who explicitly need to model infinity bounded intervals would choose those. Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

Boost.Context review result
by Vicente BOTET 15 May '11

15 May '11

Hi, this was my first experience as review manager and it has been more difficult than I had expected. Apologies if I forget some important things or I misunderstood others. I hope that the major points have been taken in account. Here it is the result of the Boost.Context review. The library is accepted provisionally and will need to address some mandatory points before a mini review (4/5 days). There were not too much complete reviews (5) but globally all the reviewers voted for acceptation and two subject to some major redesign modifications. I hope I didn't miss somebody. YES Gordon Woodhull YES/Cnd Giovanni Piero Deretta YES Artyom YES Nat Linden YES Phil Endecott YES/Cnd, Jeffrey Lee Hellrung, Jr Thanks to all the review participants Gordon Woodhull, Giovanni Piero Deretta , Artyom, Nat Linden, Holger Grund, Phil Endecott, Jeffrey Lee Hellrung, Jr.. Special thanks to Giovanni Piero Deretta showing some major flaws in the global design and Holger Grund for showing a (possible) major bug on the Windows implementation. I know Oliver that you have already redesigned your library, but if there are points that you have not been addressed yet or have some difficulties addressing them, I will suggest you to work closely with Giovanni, he know well the domain and have a lot of good ideas, and exchange on this ML. You should follow up more closely the discussions during the mini review and even try to get feedback from the ML posting how you see your redesigned library. Point to be addressed before the mini review: Design 1. Separation of the context class in two interface: - A C-like interface that defines a POD struct that is memcpy-able and that can be implemented either using platform libraries, as ucontext, fibers or directly using assembler when a robust implementation is available. The context swap implementation don't need to save the signals as ucontext does. The following is just for illustrations purposes. struct boost_context; typedef void boost_context_fn_t(intptr_t); extern "C" void boost_context_make(boost_context* ctx, boost_context_fn_t * f, intptr_t p, ...); extern "C" void boost_context_swap(boost_context* from, boost_context const* to); extern "C" intptr_t boost_context_destroy( boost_context* fc); boost_context_make is a merge of get_context with make_context + some fields assignations. "A user will have lower expectations from such a low level API and at the same time will give more freedom for other people to implement on top of it higher abstractions as Boost.Corutines, Boost.Fibers ..." - A non-copiable but movable safe context class on top of the low level C-like interface, that will provide modern and efficient C++ interface, that is usable by a user in a safe way. The safe context class would just be one of the client of the C-like interface, other library authors could either use the underlying C-like API directly or the class context depending on wether they need the speed or safety. * The context class will not be templated any more, and the use of type erasure will ensure that. * The constructor will accept any C++ callable, function pointers, functors, ... * At this high level interface, the function provided by the user could throw exceptions, and the library must wrap the user function and needs to store the exception raised and provide an interface to retrieve them. 2. The stack implementation must ensure that the stack is unwound before it is destroyed. A stack should only be safely deallocated if either has been completely unwound or if it doesn't own any resources. A basic stack without protection seems mandatory. For debug purposes it has been required to provide some stack usage functions that allow to know the max size used for example. Implementation 3. The assembler implementation on Windows must be disallowed if the ABI bug reported by Holger is confirmed. As far as Windows provides a fiber implementation that is as efficient as the assembler one, the assembler implementation is not mandatory and the user of the provided Windows fiber is a preferable choice. 4. Most of the 'throw' statements in the context class should actually be asserts. 5. The provided stack should be used to store any context parameters as far as no major impediment is found during the implementation. This will avoid further allocations on the safe context class. Documentation 6. The documentation is very minimalist and should be expanded with a discussion on context switching and use cases. Take care of all the grammar/spelling improvements suggested by the reviewers (It will be great if Jeffrey could review the documentation before the mini-review). Some user land examples should be provided (why not the yield example). 7. The concept of (Movable) Stack must be clearly defined, as it is done in the standard, using expression requirements with semantic constraints. 8. The assembler implementation should be carefully documented, so others could maintain the code and add other implementations if needed. 9. Some performance measure should be added. Providing the number of cycles on each implemented platform would be nice. Build system 10. The default build on a platform must work (It must be ABI compatible with the underlying platform) and take care of the specific features. Of course, the build needs to support cross compiling, so the user should be able to override the default values. Others points that are not required but that can make the library more usable or efficient: 1. The assembler implementations could be simplified if the context itself was represented as a single pointer to the top of the stack. This would save some instructions to move the source address from the stack return address to the context struct and back. 2. Instead of supporting a 'fc_link' a-la ucontext, have the callback function return a new context (it is void now). 'fc_link' is useful only on some limited cases (usually when you have an external scheduler managing your contexts), while the having the callback return the 'next continuation' has more applications (note that fc_link can be implemented easily in term of the continuation returning variant, but the reverse is harder). This will be very useful, for example, to implement some kind of 'exit_to' functionality (unwind the stack and restore another context), a key piece for safe context destruction. 3. Give to boost_context_swap the ability to exchange a parameter with the other context: boost_context_parm_t boost_context_swap( boost_context * ofc, boost_context const* nfc, boost_context_parm_t parm) where boost_context_parm_t is either union boost_context_parm_t { void * ptr; int int_; }; or simply intptr_t; boost_context_swap saves the current context in ocf and restores the context ncf as usual; additionally, if ofc was 'captured' on a call to boost_context_swap, this call will return the value of parm on the original context. This extra parameter is equivalent to the second parameter of longjmp. If ofc was created with boost_context_swap, 'parm' will be an extra parameter to the function. Note that this can be potentially implemented with little or no overhead. 4. Add a variant of boost_context_swap that allows executing a function on the destination context (in this case 'parm' would be passed parameter to this function. This is mostly useful for injecting an exception on the destination context. This can be potentially implemented on top of the existing functionality, but would slow down every context switch; a possible efficient implementation would manipulate the destination stack to add a call to the function on top of it, so that the cost is paid only when required. 5. Add a current context function (thread local). Vicente Review Manager

5 8

Phoenix: error: extra ‘;’ on boost/phoenix/core/environment.hpp
by Vicente BOTET 15 May '11

15 May '11

Hi, There is an error on In file included from ../../../boost/phoenix/core/call.hpp:12, from ../../../boost/conversion/fp/convert_to.hpp:15, from builtins.cpp:16: ../../../boost/phoenix/core/environment.hpp:446: error: extra ‘;’ It seems that the error: extra ‘;’ are on lines 433 and 444 at the end of two functions definitions. Could this be fixed? Thanks, Vicente

5 6

[countertree] New Version
by Francisco José Tapia 15 May '11

15 May '11

Hi this message is to announce the new version of the countertree library. You can find the zip file with the code and the documentation in < http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam…> or if you want a quick look , you can see in my web page < http://fjtapia.webs.com/works/countertree/index.html> Technically this library is an implementation of a binary red-black counter tree. Colloquially is a balanced tree with an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container. If the information stored is unordered, we have the class boost::vectortree. This class have the same interface than a std::vector. The std::vector is very fast O(k) inserting and deleting at end , but very slow O(N) if you must do in other positions . In the vectortree all the operations are O(logN). It is a bite slower than std:vector inserting and deleting at end, but much more faster for to insert and delete in any other position. If the information stored is ordered, you have the classes boost::set, boost::multiset boost::map and boost::multimap. These classes have identical interfaz than the std::set , std::multiset, std::map and std::multimap, and additionally, access by position with the function at(pos). The iterators are random access and have a function pos() which return their position in the container. You can mix safely access by iterators and access by position. The performance of these classes are similar to the classes of the STL. #include <boost/countertree/set.hpp> #include <iostream> int main ( void ) { //------------------------ begin -------------------- boost::set<int> A ; for ( int i = 0 ; i< 100 ; ++i) A.insert(i); for ( int i = 0 ; i < A.size() ; ++i) std::cout<<A.at(i); return 0 ; }; For to show the utility of this, imagine a large unordered file with the information about the employees of a big company. You have indexes implemented with multimaps, with pairs [value, position], and use the upper_bound and lower_bound functions . You need to select the employees in a range of age and weight. With the boost:multimap you can know the number of elements of the selection. In the weight query we found 100 elements and in the age query 10000 elements. To travel the elements of the weight query asking for the age, is faster than the opposite. Tray it. It fast, useful and easy to understand and use,. They are the STL classes with a few additional functions. I had checked this code with GCC (32 and 64) and Visual Studio 2008 (32) and Visual Studio 1010 (32 and 64). Please, if you find any problem, please mail me ( <fjtapia(a)gmail.com>) or if you mail Boost, please insert [countertree] in the head of the message. Some days I have not time to read all messages arrived to my mail, but if I see that I detect and respond first. Francisco Tapia <fjtapia(a)gmail.com>

7 12

Phoenix: is there a Phoenix expression trait?
by Vicente BOTET 15 May '11

15 May '11

Hi, I'm adding a convert_to Phoenix like functor to Boost.Conversion. I would like to use the same name, i.e. convert_to, but the overloads conflict. I would like to use sfinae to choose the correct overloading between template inline typename expression::convert_to, U>::type const convert_to(U const& u); template Target convert_to(Source const& from, boost::dummy::base_tag const& p=boost::dummy::base_tag()) Is there a trait that can be used to detect if the parameter is a Phoenix expression? BTW, I have just based my implementation on the one for static_cast, that uses the detail boost::phoenix::detail::target Could someone explain me why this is needed? Could this detail be moved to the user interface? Best, Vicente

3 2

[context] new version (stack unwinding, ASIO example, ...)
by Oliver Kowalke 14 May '11

14 May '11

Hello, I've reworked on boost.context regarding to the suggestion of the last review (thanks to Vicente as review manager) - but not all requests could be fulfilled. The new lib supports stack unwinding, has examples like C# enumerator concept (yield_return(), yield_break()) and an adapted version of a echo server using stack-less coroutines written by Chr. Kohlhoff and Java continuations. The new version (boost.context-0.7.0.zip) is published on boost vault and the documentation can be read here : http://ok73.ok.funpic.de/boost/libs/context/doc/html/ . Best regards, Oliver

1 0

[BGL] container_gen (was Re: [tree] reviving the tree library)
by Cromwell Enage 14 May '11

14 May '11

--- On Fri, 5/6/11, Erik Erlandson wrote: > My storage models are effectively wrappers around the > underlying containers (the container is a member of > the node type). I originally thought it would be nice > to allow a user to somehow drop in any container they > wanted, but I was unable to find a way to make that > work properly. [snip] > Perhaps container_gen would allow it to be more fully > automated. The idea behind container_gen is indeed to allow users to drop in containers of their choosing by providing their own specializations and selectors. In turn, your node class template needs only to take in the selector type as an additional template parameter. One current limitation that may be important to you is the inability to supply custom allocators as well. I saw in the sandbox that the BGL authors were planning to provide selector templates parameterized by allocator type. I'm wondering how that work is progressing. At any rate, to the BGL authors: I find container_gen to be a useful utility metafunction outside its current home. Would anyone else like to see it become a first-class Boost citizen? Cromwell D. Enage

3 5

[signals2] trunk - vc++ 10 warning about assignment operator
by Edward Diener 13 May '11

13 May '11

An attempt to instantiate a signals2 signal of the form: template <class T> class notification_boost_signal2 { public: boost::signals2::signal<void (const i_some_interface<T> &,boost::optional<T>,T)> sig; }; for notification_boost_signal2<char>, gives the error message in vc++ of: "C:\Programming\VersionControl\boost\boost/signals2/detail/signal_template.hpp(367) : warning C4512: 'boost::signals2::detail::signal3_impl<R,T1,T2,T3,Combiner,Group,GroupCompare,SlotFunction,ExtendedSlotFunction,Mutex>::slot_invoker' : assignment operator could not be generated" There is a huge template trace leading up to this final warning, but before giving it I wonder if anyone knows what it is about ? Perhaps Frank Mori Hess or Douglas Gregor is out there and can tell me what is happening.

3 4

[Block Pointer] multithread help
by Phil Bouchard 13 May '11

13 May '11

Hi everybody, I was wondering if there is anybody familiar enough with Block Pointer that could give me a hand regarding multithread support. Once again the test file is at: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/th… The main class I am trying to protect with a mutex is block_header from: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp Thanks, -Phil

3 7

[multi_array] Is there interest for an [index_list] library?
by Pierre-Andre Noel 13 May '11

13 May '11

(This email has earlier been sent to the wrong list. Thanks to Steven Watanabe for pointing that out.) Dear all, I would like to gauge the interest of the community in a library that can serve 1) as a complement to Boost.MultiArray and 2) as an alternative to Boost.MultiArray. For the first type of use, an example of the candidate library's capabilities is that it makes available a special iterator "it" that allows to browse all the elements of a MultiArray "m". This special iterator has an it.indices() members that returns a "list" Collection of indices (i.e. an IndexList) such that "m(list)" and "*it" are the same elements. This can be useful for functions whose effect on an element of "m" depends on where this element is situated in "m". The second way to use the candidate library is as an alternative to Boost.MultiArray of dynamically chosen (execution time) dimensionality. Moreover, the elements do not necessarily need to be arranged in a multi-dimensional "box", as is the case in a MultiArray. For example, a "simplex" organization of the elements is already implemented. If you are interested to know more, I strongly suggest you to take a look at the example file in sandbox/index_list/libs/index_list/examples.cpp . The library itself is in sandbox/index_list/boost and a readme file (with some details concerning concepts and "priorities") is in sandbox/index_list/libs/README . An automatically generated (Doxygen) documentation is located in sandbox/index_list/libs/index_list/doc/index.html . Sadly, there is no "real" documentation for now. Many thanks for your time. Sincerely, Pierre-André Noël

5 11

boost lib must provide C interface?!
by Oliver Kowalke 13 May '11

13 May '11

Hi, can a boost C++ library be required/forced to provide a C API? Even if the library author doesn't like this idea - because he would be responsible for C stuff. <boost/config.hpp> include <cstddef> which will not be available for a C compiler - maybe this is an indication that boost libs are not required to implement a C-API. regards, Oliver -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

5 6

Testing Problems
by Christopher Jefferson 13 May '11

13 May '11

Apologises, the following message is going to be a fairly long list of complaints. However, I wanted to post them rather than just let them disappear. Some background: I previously worked on getting clang and libc++ working in boost, in both c++03 and c++0x mode, submitting a large number of patches to achieve that goal. I also ran regression testers for this libraries. I am broadly planning on giving that up, unless various things improve in various ways. That isn't a threat, just I don't have the man and CPU time to spare working around issues in boost. Problems: 1) Running the boost regression tests takes unacceptably long. I would like to run tests for clang with and without libc++, with and without c++0x mode. Running those 4 sets of tests takes a huge amount of time. Various tests (and I keep meaning to try to find which ones) take huge amounts of memory, meaning it isn't reasonable to run even a single-threaded boost regression test in the background on a 4GB machine. Running tests in parallel doesn't seem to speed them up particularly, while bringing the machine even more onto it's knees. 2) The boost regression testpage ( http://www.boost.org/development/tests/trunk/developer/summary.html ) is fairly useless, as it doesn't say when a particular test failed. This means I just have to try to memorise the current state of all the compilers I am interested in, and look for new fails by eyeball. Much more useful would be changing the 'fail' to the most recent svn version at which a new fail occurred? 3) I always find trac hard to use. I usually want to do 2 things: a) Find all open bugs attached to package X b) List all bugs which I filed, or have have submitted a message to. I find both of these easy to achieve with bugzilla, and not with trac. 4) Getting patches, in particular very simple ones (like warning suppression) can take multiple prods and can languish for a long time in trac. I'm not sure what the best solutions to all of these problems are. Obviously they could each be tackled but several of them would involve changes to many different boost libraries, which is something I find can be like pulling teeth (some maintainers are extremely good, I certainly don't want to tar everyone with one brush!) On practical note, is it time for boost to move to officially supported compilers for each release? These could easily be read off the testing page (no test = not offically supported), and the packages which do not pass testing could be briefly listed in the release notes. This might have the advantage of encouraging more people to run tests, if they want their compiler to be offically supported. Apologises for the lengthy rant, Chris Jefferson

2 1

[review] string convert
by Gordon Woodhull 12 May '11

12 May '11

Hi Vladimir, Ed, all, It is a curiosity of Boost reviews that a vote of conditional acceptance is actually more powerful than a No vote, because if you vote No, the author might try to convince you to change your vote but otherwise has no incentive to listen to you any further. Therefore I vote to accept this library with the strong condition that a simpler syntax be adopted, doing away with the odd static ::from() function, and completely getting rid of the confusing, error-prone lazy functions. I am aware that the author thinks the present syntax is necessary, but I will argue against it in each case. (As another meta-review comment, I've noticed a few authors saying they won't consider any changes unless their library is accepted. This sets up a deadlock situation: the reviewer will not accept the library without the changes, and the author won't make the changes without acceptance. Everyone digs in their heels and nothing gets done. I think any author who really wants their library to be in Boost should be willing to submit it for a second review. And I think reviewers should tend toward conditions on acceptance rather than no votes. My two cents.) > - What is your evaluation of the design? That's the focus of my review, specifically, the design of the interface. Supplying a default value, a don't-throw option, and applying manipulators/locale, are the major features missing from lexical_cast. So I think there is no doubt that a library like this is needed, if lexical_cast can't be upgraded. And according to its author, lexical_cast can't be upgraded because it must look like a cast and all these features require more parameters (template or actual). So, fine, let's have a replacement that's not .*_cast. It is incredibly clear what lexical_cast does because it uses the standard meaning of the operators, function calls, and return values. There is a lot of value in that. I don't think it's always a bad idea to have lazily evaluated objects or creative uses of operators, but IMHO if it is possible to do something more clearly with the standard order of evaluation and standard use of operators and function calls, then that should be preferred. The interface of the proposed Convert library is not simple enough. To start out with the most annoying thing, I don't like "::from" at all. The replacement should look as close to lexical_cast as possible. So, why the extra '::from'? Even though I disagree with the lazy evaluation (see below), even that doesn't seem to require this weird static member syntax. Is '::from' just so that '::result' will not feel lonely? For the rest of this review, I'm going to refer to convert<T>::from(s), but please keep in mind that I really think it should be something like string_convert<T>(s). So, next '::result'. It's some form of optional return. So why not just return optional? It is not much less to type convert<int>::result maybe = convert<int>::from("not an int"); versus optional<int> maybe = convert_cast<int, use_opt>("not an int"); (Where use_opt might also be spelled dont_throw, opt_out, .. I don't really care. Yes there may be problems because of the necessary deduced template argument for the source type. But isn't there a way around that with Boost.Parameter?) Why should the LHS modify the behavior of the proxy object returned by ::from? It's far too much to think about for such a simple operation. I'd rather the function clearly did or didn't throw on its own, not be influenced by its context. Lazy evaluation in expression templates is typically used to offer some kind of declarative syntax. So let's ask ourselves if that is needed here. The main innovation here is a lazily evaluated object which can then - throw or not throw based on its context convert<int>::result i = convert<int>::from("not a string"); - take iostream manipulators, which are applied before the conversion takes place. - take additional options through a second application of function call operator (!) All of these uses defy the way we ordinarily read function evaluation. What, the conversion is now feeding some data into std::hex? And then where does it go after that? It gets returned? Weird. The right shift operator was chosen in the standard because it depicts an arrow; otherwise there is nothing that says I/O about it. Thus the only way this syntax would make sense to me is if it were int i = std::hex >> convert<int>::from("deadbeef"); and then unfortunately it would be impossible to have more than one manipulator without some horrible parentheses, because of the left associativity. I don't like the look of streaming operators that lead nowhere. No, why not just int i = convert<int>::from(s, std::hex); ? Or from(s, _manip = std::hex) Or, at worst (and I don't see why this is necessary) from(s)(_manip = std__hex); If you want the operator syntax, just do int i; stringstream(s) >> std::hex >> i; If it's really got to be one line, a syntax like int i = stringstream_(s) >> std::hex >> ret_; would at least make sense and I'm sure that there's a way to do that almost as succinctly using Phoenix. On a similar nice-feature-but-weird-syntax note, let's look at the Using Boost.Convert with Standard Algorithms section, which offers a few ways that you can use convert<T>::from() to create a functor: std::transform( strings.begin(), strings.end(), std::back_inserter(integers), convert<int>::from(string(), -1) >> std::hex); std::transform( strings.begin(), strings.end(), std::back_inserter(integers), convert<int>::from<string>()(fallback_ = -1) >> std::hex); Apparently if you pass an empty string or omit the parameter to from(), it creates a function object which takes a string as a parameter. Is this correct? This seems like it would have unwanted consequences, since we now have a function object that can take either extra options or the string input. Again, I'm not against clever syntax, but this seems promiscuous and confusing. I think it would be much more appropriate to provide a Phoenix function object for the purpose, something like std::transform( strings.begin(), strings.end(), std::back_inserter(integers), convert_<int>(_1, -1, std::hex)); Sigh of relief. I see what that means immediately, and it doesn't make me worry about what convert's going to do if I forget a parameter. I agree with Jeroen's request for a default-constructed version. I don't see why no syntactic sugar could be doled out for this, a _defcon (template or real) parameter or whatever. I also want to mention type-to-type conversion, which Vicente Botet has thought out much more thoroughly in his Conversion library. This library offers type-to-type conversion seemingly as an afterthought, just because the syntax allows it. I definitely see the value of a conversion mechanism that first looks for a direct type-to-type conversion and then defaults to using type-to-string-to-type. I just don't think conversion should always do that, and I don't think such a mechanism should be called plain convert. It does make any more sense to call such a thing plain convert than it does to start optimizing lexical_cast with special cases that don't use strings (sorry!). It would be called best_conversion or something that conveys that it's doing the best it can based on what converters have been "installed" at compile time. Again my objection is not to the functionality but to an obfuscating interface where you're not sure what behavior you're going to get. I feel the same about the string-to-string conversion: it seems to be in there just because the syntax supports it, not because it actually makes sense here. I guess this is because library is called Convert instead of String Convert or Via Stream Convert, which is its main focus (and rightly so). Apologies for repeating this: I still don't get why the extra options go into a second function call operator. I found some earlier messages where you simply added those to the first function call. Simplify, simplify, simplify the interface. Please. To summarize, I don't get why we can't just have this simple clear syntax: optional<int> i = string_convert<int, dont_throw>(s); // or string_convert<int>(s, _throw=false) if that's impossible int i = string_convert<int>(s, manip_ = std::hex); It's (plain) functional. There's no question when things get evaluated or thrown. I don't care about any of the particular names used, just the syntax. > - What is your evaluation of the implementation? I read the code enough to answer my own questions about what the library actually does. As noted, I disagree with many design choices, but the implementation seems fine. The only thing that caught my eye as a little strange is that there's the string_sfinae namespace and header which in fact contains a bunch of metafunctions which are sometimes used in sfinae and sometimes just used as metafunctions. Obviously not a big deal, just some metonymy or historical artifact there. To return to convert<>::result On Apr 27, 2011, at 7:07 PM, Vladimir Batov wrote: > They, indeed, seem to provide *similar* functionality. In fact, convert::result *uses* boost::optional. If you have a look at convert::result (it's quite small), then everything else in addition to boost::optional is what convert::result adds. In words, IMHO convert::result is better than boost::optional tailored for its domain (conversions). So you made me look. I conclude that the only functionality it adds is the ability to delay throwing on error until the result::value() is called, am I wrong? I don't understand why you'd want this, because I thought the whole point of using ::result was when you didn't want to throw. But maybe I'm missing something. Again I think this could all be SO much simpler. > - What is your evaluation of the documentation? It's well written and explains the subject well. It seems a bit flippant in places ("I've included this and that because why not?" kinds of statements) and IMO that's because the focus of this library is a little too fuzzy. Stick to string/stream conversion, fix the problems with lexical cast. Don't try to build a general conversion framework unless you're really willing to think that through. I looked for a Rationale section that would explain why this functionality could not be included in lexical_cast, and could not find it. Vladimir, I know you said On Apr 26, 2011, at 6:47 PM, Vladimir Batov wrote: > I again urge you to please dig the archives to see why that "extra > functionality should be added to boost::lexical_cast" view is not exactly original and most importantly why it was decided *not* to proceed as you insist. But I don't think that's a substitute for explaining to new users why they can't get what they want with modest improvements on the lexical_cast interface. Why is it that they really want some fancy lazy function object / "declarative" interface? Likewise with this non-argument: On Apr 26, 2011, at 6:47 PM, Vladimir Batov wrote: > I've come to a firm conclusion that that additional > functionality/configurability is *not* implementable within the boundaries of the lexical_cast interface. In particular, the TypeIn and TypeOut types must be discriminated, i.e. one type has to be specialized first. Without going into details I'll just say that otherwise is just does not work. So, it has to be convert<TypeOut>::from<TypeIn>. You can take my word for it or you could walk that road yourself. Sorry, but I find this response either lazy or rude. You wrote the library: you explain to us why the way it is! I'd really like to know why you think it's necessary to do convert<T>::from(s) rather than the much more familiar and easy-to-grasp string_convert<T>(s). I don't want to try to write it myself to find out why it does or doesn't need to be that way. You entered a fairly contentious arena with a majorly different interface. Write a rationale and don't just tell us to search the list. > - What is your evaluation of the potential usefulness of the > library? Very, very useful. I use lexical_cast and am frustrated by the limitations. > - Did you try to use the library? With what compiler? Did you > have any problems? No, I did not - I see how it works and trust that it does. I was not tempted to start looking for ways to make the library produce surprising results because it was immediately clear to me from the interface design that those misbehaviors would exist. I'm not always a Keep It Simple person, but in this case, please do. Otherwise you're destroying one of the best features of lexical_cast. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? I spent about 5 hours reading the documentation and code, and 5 hours reading/rereading the current reviews and writing mine. I wish I'd had time to go back to the earlier discussions, although I searched a little bit; again I think everything that could be learned there should have been in the Rationale. > - Are you knowledgeable about the problem domain? Moderately. I like to know how every construct I'm using works, and I gulp at the inefficiency of lexical_cast every time I use it, even though I never use it where efficiency matters. To further prove my point that conditional acceptance is stronger than voting no, note that I've basically made my yes vote conditional on fixing most of the things Thomas Heller complained about, notably On Apr 26, 2011, at 2:58 PM, Thomas Heller wrote: > Moreover, I don't get how the design really is superior to boost::lexical_cast, and why it couldn't been implemented as an extension to that library. (It can't take a .*_cast name, but it can use the simple syntax.) > The use of this converter function object looks like a nice concept at first sight but, as mentioned above, in the end, probably adds more confusion and problems than anything else. (It confused me and didn't look nice.) > I don't think that having everything hidden behind this static from function is wise and should be rethought. Different functions, for different purposes would be better suited. On Apr 27, 2011, at 5:14 AM, Thomas Heller wrote: > Even though you tried to be minimal and > simplistic, the function is overloaded with too different (in concept) > behavior that its really confusing to get what the function is really > doing. So my end result is that its not really minimal and > minimalistic, but bloated ... sometimes, more is less. (I think more template or function parameters could also do the trick.) I realize that my conditions mean some serious redesign, but this is an 834-line library and it would probably be even shorter without all the unnecessary lazy functions and weird out-of-place operators. I want to contrast this with my No vote in the XInt review, where I also had issues with the design. I would have voted for conditional acceptance of XInt if it were possible, but the changes there seemed like they would need additional review. String Convert is much simpler and I think that a compromise could be reached to (IMO) simplify the interface and answer most of the objections that Thomas, Jeroen, and I have made. I apologize to Ed for making a complicated vote. I'd be glad to clarify my position if needed. Cheers to Vladimir - you've identified an important problem! Now just give it a clear interface and we'll have something good. Gordon

13 163

[local] Help for the Alternatives section
by Lorenzo Caminiti 12 May '11

12 May '11

Hello all, I am updating Boost.Local docs and I could use a some help in getting the Alternatives section right http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… . How can I program the following code (its local function and `factor` constant binding) using Boost.Phoenix, Boost.Lambda, and C++0x lambda functions? If you know, can you please reply with the actual code? #include <boost/local/function.hpp> #include <iostream> #include <vector> #include <algorithm> int main() { double sum = 0.0; int factor = 10; void BOOST_LOCAL_FUNCTION_PARAMS(double num, // Variable `factor` bound as constant. bind& sum, const bind& factor) { sum += factor * num; std::cout << "Summed: " << sum << std::endl; } BOOST_LOCAL_FUNCTION_NAME(add) std::vector<double> v(3); v[0] = 1.0; v[1] = 2.0; v[2] = 3.0; // Local function `add` passed as template parameter. std::for_each(v.begin(), v.end(), add); return 0; } Thank you very much! -- Lorenzo

14 82

Delimiting protocol messages (was [asio] read_some() splits data)
by Marsh Ray 12 May '11

12 May '11

On 05/11/2011 09:36 AM, Andrew Holden wrote: > On Wednesday, May 11, 2011 9:57 AM, Slav wrote: >> Then messages of length not multiple of 128 (BUFFER_SIZE) >> will not be read - tested it, anyway, after >> last socket::read_some() (with readBytes> 0&& < >> BUFFER_SIZE) next socket::read_some() never ends. > > It would probably help to understand that TCP has no concept of a > "message". Anything you write to a socket is appended to a stream of > *bytes*. Alternatively, we could say that TCP, in fact, does have a well-defined concept of messages: they are all exactly one byte long. > Several subsystems on both the sending and receiving computers ... and sometimes boxes in the middle ... > will have the option of splitting and combining adjacent buffers with no > consideration to how big each individual write was. I've done a little protocol stuff with ASIO now and I must say it's a lot of fun and I can't go back to doing it any other way. > On further thought, I think I see the problem (and I apologize for the > bad recommendation in my last email). Your sender somehow needs to > communicate the message size or flag the end of the message. A partial > list of options includes: The pattern I encounter over and over again (often at multiple levels in a protocol) is: class protocol_layer_context { vector<uint8> buffer; void on_received_data(vector<uint8> & rx_bytes) { buffer.append(rx_bytes); // perhaps a virtual override. size_t msg_len = this->parse_len_from_start_of_buffer(); if (buffer.size() <= msg_len) { vector<uint8> msg_buf = consume_data_from_front_of_buffer(buffer, msg_len); // perhaps a virtual override this->process_complete_message(msg_buf); } // post another ASIO read request this->request_more_data(); } ... But there are some important issues with this naive pseudocode: 1. It can result in recopying the data a bunch of times for every protocol layer, killing performance. 2. It's susceptible to a denial-of-service (DoS). Bad guy can send trick you into allocating all your memory. 3. Sometimes the length of a message is stated at the beginning of the message, sometimes it isn't known until the end. 4. No processing happens on the message until it's completely read, but some protocols really need the receiving endpoint to process it incrementally. 5. Error handling 6. Optimal threading 7. Etc. We find bugs in exactly this logic all the darn time. Often the data being received is untrusted and possibly malicious. Real-world protocol implementations will commonly crash under fragmentation fuzzing, sometimes resulting in exploitable security holes. In a sense, this is the general refactoring problem of 'incrementalizing' a parsing function by moving all its state from stack variables into a longer-lived context object. We've seen it done successfully with coroutines, but that's not a commonly accepted solution because, frankly, the native C/C++ runtimes have not yet given coroutines the love (i.e., portability and performance guarantees) they really deserved. If someone figured out how to leverage generic techniques to handle just the unidirectional message delimiting problem in a bulletproof way I think it would make a really great boost library. - Marsh

1 0

Free BoostCon Registration
by Dave Abrahams 12 May '11

12 May '11

Unfortunately, two of our registrants had to cancel after the refund deadline. Fortunately, they have offered their registrations to anyone who might have not registered because of the cost. If you would like to claim these available registrations, please send email to our registrar, Marshall Clow (mclow AT gmail.com) Thanks, and see you in Aspen! -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 1

[spirit][qi] Dynamically combine Boost.Spirit.Qi rules at runtime
by Daniel F. 11 May '11

11 May '11

Hi, I recently tried to combine an arbitrary number of rules as alternatives in Boost.Spirit.Qi. Since rules are implemented as objects it seemed feasible to me. My motivation was to make certain parts of my grammar easily extensible. Unfortunately, I ran into some problems, so I wrote a simple program (see attachment for the complete code) demonstrating the unexpected behavior. Here's the key part: // "Dynamic" version - Does not compile! :( /* std::vector<rule_t> rules; rules.push_back(qi::char_('a')[qi::_r1 = px::val(0)]); rules.push_back(qi::char_('b')[qi::_r1 = px::val(1)]); rules.push_back(qi::char_('c')[qi::_r1 = px::val(2)]); std::vector<rule_t>::iterator i(rules.begin()), last(rules.end()); rule_t grammar; grammar = (*i)(qi::_r1); //[no_op] for(++i; i!=last; ++i) { grammar = grammar.copy() | (*i)(qi::_r1); //[no_op] } */ // "Dynamic" version - Kind of works! :-/ std::vector<rule_t> rules; rules.push_back(qi::char_('a')[qi::_r1 = px::val(0)]); rules.push_back(qi::char_('b')[qi::_r1 = px::val(1)]); rules.push_back(qi::char_('c')[qi::_r1 = px::val(2)]); std::vector<rule_t>::iterator i(rules.begin()), last(rules.end()); qi::rule<iterator_t, int()> temp; temp = (*i)(qi::_val); //[no_op] for(++i; i!=last; ++i) { temp = temp.copy() | (*i)(qi::_val); //[no_op] } rule_t grammar; grammar = temp[qi::_r1 = qi::_1]; Now, I suppose that the first version (commented out) doesn't compile, because I'm not passing the inherited attribute down to grammar.copy(). I would love to know if there's a better way of doing this than the workaround that is the second version. The second version actually compiles and it seems to do the right thing. However, once I attach a simple semantic action as indicated in the code using comments (see "[no_op]"), the behavior becomes really weird. Rather than printing 0,1,2 as before, the program prints 0,0,2. So I'm wondering, is what I'm trying to accomplish resulting in undefined behavior? Is this a bug? Or, quite possibly, am I just using something (e.g. semantic actions?) the wrong way? Thanks for reading, Daniel

4 7

[convert] no-throw and fallback feature
by Vicente BOTET 11 May '11

11 May '11

Hi, I was thinking on the fallback feature a little bit more and I've the impression that we can get it for free. If we accept that we need a no-throw function such as try_convert_to that returns an optional Target we can have the fallback using the optional::get_value_or function auto r = try_convert_to(*int*)(s); int i = r.get_value_or(fallback); or just int i = try_convert_to(*int*)(s).get_value_or(fallback); or int i = get_value_or(try_convert_to(*int*)(s), fallback); I don't know if it is worth adding a function that does all in one int i = convert_to_or(*int*)(s, fallback); Best, Vicente

5 25

[autoindex] Review
by Edward Diener 11 May '11

11 May '11

This is my review of autoindex. - What is your evaluation of the design? Very clean and easy to understand. - What is your evaluation of the implementation? Did not look at the internals. - What is your evaluation of the documentation? Generally good. Here is a list of mostly grammatical errors: 1) Overview: "the HTML indexes look a lot less good" -> "the HTML indexes look a lot worse" Step 1: Build the AutoIndex tool: "Finally note that tools/auto_index/auto-index.jam gets copied into the same directory as the rest of the Boost.Build tools." -> I am not sure if this means that building AutoIndex does this automatically or the end-user must do it but the sentence grammar suggests the former, which does not happen for me. If the end-user should do it, the line should read "Finally note that tools/auto_index/auto-index.jam should be copied into the same directory as the rest of the Boost.Build tools." 2) Step 2: Configure Boost.Build jamfile to use AutoIndex "Always send the output to a log file. It will contain of lot of stuff, but is invaluable to check if all has gone right, and else diagnose what has gone wrong. -> ..."and also diagnose what has gone wrong." ..."or else diagnose what has gone wrong." 3) Available Indexing Options: For Document Type 'library', Available Index Types says 'See Chapter'. I am guessing this means it is the same as Document Type 'chapter' but it should be made clearer in the remark. 4) Step 7: Iterate - to refine your index: "You can restrict which sections are indexed for a particular term. So assuming that the docbook document has the usual hierarchical names for section ID's hierarchical names for section IDs(as Quickbook generates, for example), you can easily place a constraint on which sections are examined for a particular term. " ' -> remove the second repeated "hierarchical names for section IDs". "This would avoid an index entry every time ° kelvin is found, something the user is unlikely to find helpful. " -> "This would avoid an index entry every time 'Kelvin' is found, something the user is unlikely to find helpful. " 5) Script File (.idx) Reference: "Blank lines consisting of only whitespace are ignored, so are lines that start with a #. (But, of course, you can't append # comments onto the end of a line!). " -> I am guessing this should be: "...(But, of course, you can append # comments onto the end of a line!)." "recurse An optional boolean value - either "true" or "false" - that indicates whether to recurse into subdirectories. This defaults to "false" -> Needs a period at the end. "type The type to which items found using this rule will assigned, index terms created from the source file and then found in the XML, will have the type attribute set to this value, and may then appear in a specialized index with the same type attribute " -> Needs a period at the end. The only other issue in the documentation is that while there is very good documentation about what type of XML container wraps an internally generated index, I am not sure what this actually means to a Quickbook author. No doubt somewhere there is probably a discussion in Docbook of what these XML containers mean and do but, aside from experimentation, the user of AutoIndex is not likely to understand what it means to put the Index in a specific XML container and how this affects the final layout of the documentation. Perhaps some further explanation of what this actually means for an AutoIndex user, especially for a Quickbook document, would be appropriate. - What is your evaluation of the potential usefulness of AutoIndex? Immense. Searching through documentation of even mildly complex libraries which have little or no index is very frustrating. - Did you try to use it? With what compiler? Did you have any problems? I have used it for the documentation of my VMD and TTI libraries with both gcc and vc++ under Windows. Any problems were of my own making and the author of AutoIndex answered my questions when I was stuck. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A pretty deep study, although I have not tried to add anything to the index file other than 'scan' statements. - Are you knowledgeable about the problem domain? Yes. I vote for the library to be accepted into Boost. Edward Diener

2 1

inquiry about proposing a new Boost library for a tree template container class
by Erik Erlandson 11 May '11

11 May '11

Hello, I recently completed an STL-compliant template container class for storing data in an arbitrary tree structure. It seemed like it might be a useful component of Boost, and I wanted to ask about how new projects are submitted for consideration. The current incarnation of the project is called 'st_tree', and resides here: https://github.com/erikerlandson/st_tree/wiki Regards, Erik Erlandson

7 27

[type_factory] new utility/class proposal
by Vlad Lazarenko 11 May '11

11 May '11

Dear Boost developers, How many times in your experience you needed to associate a type with some identifier known at run-time only? It’s like having an associative container with numeric key and type as a value. Not object, but type. This is a concept similar to object factory pattern but with no objects, only their types. I call it a type factory. There might be a solution for this in Boost already but I haven’t seen it. Please forgive me if I am just being blind. Just to give you a little taste of what I mean – imagine that you have a stream of bytes where objects of different types and sizes are stored (serialized), and one byte identifying a type is preceding every such serialized object, and you need to parse it. One approach is to have a switch statement, for example, where all type identifiers are cased, and parse data depending on a type. But then, as list of types grows and/or shrinks, maintenance of this switch becomes unpleasant. And if this logic is in some base library, where user specifies list of types, it becomes even worse. There might be another way, I thought, and came up with sort of hybrid between compile-time types and run-time identifiers – a type factory. I am wondering if anyone else will find it useful. Perhaps we can have it as part of boost utility classes. Here is a very simple example of usage: https://github.com/Yocto/type_factory/blob/master/test/simple_example.cpp It gets a number from “argc”, and then, depending on its value, invokes “speak” method of either “cow”, “dog” or “alligator” classes. More functionality is covered in unit test. Basically, the type factory, given a list of types as “MPL vector“ is enumerating them from 0 to N. Later, for any given instantiation of “create” method, it generates a dispatch table for invoking of one of template methods (with no arguments) on a supplied “visitor” class. The source code of the class is here - https://github.com/Yocto/type_factory/blob/master/include/yocto/type_factor…. There are a lot of details, but the main class exposed to the user-land API is “type_factory”. Please let me know if you are interested in such a concept. Thank you, Vlad

2 1

Review manager needed for TTI library
by Edward Diener 10 May '11

10 May '11

I am looking for a review manager for my TTI library in the review queue. The TTI library, which is an abbreviation for the 'Type Traits Introspection' library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also reproduces functionality ( without changing existing code ), for the purposes of completeness, from Boost.MPL regarding introspection of types and templates. The purpose of the library is to provide a consistent set of interfaces for doing compile-time introspection of a type, which other template metaprogrammers can use in their code. Since I have acted as a review manager for another library, and have expressed my willingness to do so for some other libraries, I would appreciate it if someone, who understands Boost MPL well and the compile-time introspection problems my library solves, would be a review manager for my own library.

3 6

Re: [boost] [trolling] Alexander's crusade (was: [provocative] Whom did the SFC pay to list boostdevelopers as a whole in "Current Member Projects"?)
by Matt Chambers 10 May '11

10 May '11

> ... pointless quoted legal jargon... What's your point? -Matt

10 17

[container_bptree] first version of submitted library
by Vadim Stadnik 09 May '11

09 May '11

Hi all, The first version of submitted library container_bptree http://www.boostpro.com/vault/index.php?action=downloadfile&filename=contai… offers a number of STL variants of containers based on B+ trees. These powerful data structures enable the implementation of various useful extensions of STL containers and iterators. One of the most interesting improvements is the efficient algorithm accumulate(), which has computational cost *O(log N)* in the worst case. This algorithm can increase performance of solutions in numerous application areas, including traveling salesman problem. Please read the documentation and try the included test code. The current implementation has been developed for Visual Studio compilers (2008 and 2010). Portability of this library has not yet been tested. I would really appreciate if someone could compile and run the test code using other compilers and let me know if there are any technical issues. Any suggestions concerning improvements of the current version of this library will be carefully analyzed and implemented if possible. The potential of B+ trees has not yet been used to its full capacity. There are a number of options for further extensions of this library. The community interest and feedback will have an effect on the priority of the development of new features and efficient algorithms in future versions of this library. Thank you, Vadim Stadnik

2 2

[phoenix] not playing nice with other libs
by Eric Niebler 09 May '11

09 May '11

The following trivial program fails to compile: #include <boost/phoenix/core/limits.hpp> #include <boost/numeric/conversion/converter.hpp> It generates the following: In file included from ../../../../branches/release/boost/numeric/conversion/detail/is_subranged.hpp:17, from ../../../../branches/release/boost/numeric/conversion/detail/conversion_traits.hpp:21, from ../../../../branches/release/boost/numeric/conversion/conversion_traits.hpp:13, from ../../../../branches/release/boost/numeric/conversion/converter.hpp:13, from main.cpp:2: ../../../../branches/release/boost/mpl/multiplies.hpp:38: error: wrong number of template arguments (12, should be 5) ../../../../branches/release/boost/mpl/aux_/preprocessed/gcc/times.hpp:68: error: provided for ‘temp late<class N1, class N2, class N3, class N4, class N5> struct boost::mpl::times’ Phoenix is changing the following fundamental constants: BOOST_PROTO_MAX_ARITY BOOST_MPL_LIMIT_METAFUNCTION_ARITY BOOST_PROTO_MAX_LOGICAL_ARITY BOOST_RESULT_OF_NUM_ARGS IMO, Phoenix shouldn't be touching these. It should work as best it can with the default values. Users who are so inclined can change them. -- Eric Niebler BoostPro Consulting www.boostpro.com

13 40

Re: [boost] [tree] Reviving the tree library
by Cromwell Enage 09 May '11

09 May '11

--- On Fri, 5/6/11, Rene Rivera wrote: > On 5/6/2011 4:22 PM, Cromwell Enage wrote: > > What are your thoughts on a generalized depth-first > > iterator that also indicates whether it's currently > > in pre-order traversal mode, post-order traversal mode, > > or neither? I've found it useful for implementing > > scene graphs, for example. > > The goal was to make it possible to have any kind of > iteration. The ones in the TR are the simple common > ones. So yes, other iterations would be good to add. > I'm all for generalization. Are you thinking of the > static kind, as in traits, etc.? Or are you thinking > of something run-time? I was originally thinking of run-time generalization, i.e. the depth-first iterator being a functional superset of pre-order, post-order, and in-order iteration. But now that I look at the implementation, it might not necessarily be so. For a simple illustration, consider this ASCII rendition of the following tree: ___B +--+--+ A_____C If this were stored in a sorted binary tree, one might expect binary_tree::iterator to output the elements in this order: A B C However, if we expect an unsorted nary_tree::iterator to behave the same way (in-order, in this case), then what is the correct output for the following tree? _________I +-----+--+--+-----+ A_____E_____O_____U My current depth-first iterator would output the following: I pre_order A pre_order A post_order E pre_order E post_order O pre_order O post_order U pre_order U post_order I post_order One could filter by pre_order or post_order to obtain the corresponding output, so in that respect my depth-first iterator would be a functional superset. However, it traverses every node exactly twice, and definitely not in the same way as a sorted binary_tree::iterator. Therefore, while I agree that my depth-first iterator could make a fine addition, it may not necessarily serve well as an nary_tree::iterator. Thoughts? Cromwell D. Enage

1 0

[lexical-cast] New maintainer
by Antony Polukhin 09 May '11

09 May '11

Alexander Nasonov and Kevlin Henney gave me their permissions to become a new maintainer of Boost.LexicalCast library. Plans for the nearest future: 1) fix inspection program warnings (missing licenses, copyrights, non ascii chars ...) 2) contact with bug reporters, and fix bugs if they still exist 3) add unit tests and performance optimizations If somebody has some advices, comments or wishes, I would be glad to hear them. 2011/5/9 Kevlin Henney <kevlin(a)curbralan.com>: > Antony Polukhin <antoshkka(a)gmail.com: >> There are some bug fixes in trunk and performance optimizations, that >> can not make their way to release. And there is no accepted >> Boost.Convert library, that can do better than lexical_cast. >> >> Alexander Nasonov, the current maintainer of lexical_cast, wrote that >> he has no time for maintaining lexical_cast and that he has no >> objections against new maintainer.( That was in thread '[boost] >> [lexical-cast] version of lexical_cast in 1.46.1 is quite older than >> in trunk'). >> >> If you don`t mind, I`d like to become a new maintainer of >> lexical_cast. I`ve already talked with Alexander, he gave me a short >> introduction of how to maintain and what changes can be accepted into >> the library. He also advised to talk to you. > > Yes, I would be happy for you to do this, if you want to run initial changes > by me and/or Alexander. > > Antony Polukhin <antoshkka(a)gmail.com: >> Would you be so kind to give me some advises and tell more, about the >> official procedure of becoming a maintainer? > > I don't think there is an official process for becoming maintainer, other > than the original author and/or the current maintainer saying "You are now > the maintainer!" :-) > > And please feel free to ask me any questions about the requirements or > design intent. > > Antony Polukhin <antoshkka(a)gmail.com: >> Is there some requirements, not described in N1973 that the library >> must follow to? > > No, we had no plans for any additional features, only fixes to bugs and > improvements in performance. The functionality is at a point where it is > stable. > > So, congratulations: You are now the maintainer! > > Regards, > > Kevlin

1 0