May 2010 - Boost - lists.preview.boost.org

Re: [boost] [MSM] move to trunk
by Christophe Henry 19 May '10

19 May '10

> On 5/18/2010 8:22 AM, Christophe Henry wrote: >> >> I'm a bit jetlagged but (luckily) had an uneventfull trip back. And >> the BoostCon was worth it! > > Indeed! It was great to meet you. It was great to meet you too! >> I plan to check in into the trunk in the next few weeks, I really want >> MSM to be in 1.44. >> I only need to write some unit tests so it should be pretty quick. >> I'll post a mail as soon as I'm done. > > If it's just a matter of unit tests and the interfaces are stable, I > suggest just merging it to trunk now and working on the tests there. > When it's ready, you can merge to release. > > -- > Eric Niebler > BoostPro Computing > http://www.boostpro.com Yes the interfaces and docs are stable, so it is just a matter of writing test cases and add a jam file. Then I will merge MSM to the trunk fast (probably tomorrow) and then start writing the tests. Thanks! Christophe

1 0

sparse_vector class
by Neil Girdhar 19 May '10

19 May '10

boost/numeric/ublas/vector_sparse.hpp implements a "sparse vector" for arithmetic types. I generalized this for default constructible types, and was wondering if anything like this has been considered for inclusion as a separate boost library. Code available on request.

1 0

Boostcon followup - Boost Lockfree review - On behalf of Mark Moir
by Tomas Puverle 19 May '10

19 May '10

I have been in touch with Mark Moir (he was one of the transactional memory speakers at boostcon), wrt the boost lockfree library. As an expert in the field, he was kind enough to do a mini-review. I am posting his comments here and am hoping that these don't get lost in the usual fray of activity, as he is one of the few bona-fide experts in the field that will take the time to actually review the submission. His comments are below: ==== This is mostly a matter of taste, but I don't much care for the approach of having CAS increment the version number, rather than having this explicit in the algorithm, for at least the following reasons: - it is not in keeping with standard cas operations, so an important part of the algorithm appears to be missing; at a minimum, cas should be renamed to cas_and_bump_version or something. - not all algorithms need to increment the version number on every CAS, for example, the stack algorithm is correct provided we increment the version number of every pop; it does not need to be done on push. This is only a (probably minor) performance concern in the stack algorithm, but one can imagine cases in which it would be important not to increment the version every time, and for such cases, a different library would be needed. - There is an awkward mix of handling version numbers in the fifo code. The node constructor explicitly increments the version number, whereas all other dealing with the version number are hidden behind cas, etc. Furthermore, this explicit incrementing is unnecessary, as far as I can tell. To avoid a "late" enqueue accidentally succeeding, the version number of a node's next pointer should be incremented once for each time it goes through the queue. But this is done by the cas of the enqueue that installs a node after it, and I think this is sufficient. I don't like "just in case" code. The authors should understand whether it's really necessary, and if so, document the reason. If (as I suspect), it's not, they should get rid of it. - I also think there should be more comments about these kinds of subtle issues, especially because the Michael & Scott paper played a little fast and loose with this. (Although they do confess to using a free list, there is a strong suggestion that nodes can be "freed" (as opposed to being put in a type-stable free list), and also no discussion of the importance of preserving version numbers of nodes in the free list. - I think there is a bug in the empty method of the fifo, at least for some memory models. (Note too that M*S did not present an empty method, so again additional comments would be appropriate IMO.) The problem is that the order of the reads is critical to ensure correctness, but there is no memory barrier to enforce this ordering. (Note that if either the compiler or the processor reorders the two loads, it is possible for empty to read tail while the queue is nonempty, then another enqueue happens, then all items that were in the queue when tail was read are removed. Now head has the same value as was read from tail previously, so the comparison can succeed and empty can return true, but the queue was never empty.) Again, I think a comment would be appropriate. ====== Hope this is helpful. Best wishes, Tom PS: It was a real pleasure meeting everyone at the conference.

3 4

BoostCon 2011 Hotel Reservation Billing
by David Abrahams 19 May '10

19 May '10

FYI, last year the Meadows' move to an automated reservation system caused some issues with the amount people were charged for reservations. After inquiring specifically into billing for 2011 reservations, this is what I heard back from Doug Crawford: > I met with our reservations team. > For your group, we'll go back to manual deposits. > Aspen Meadows will agree to the following: > Room reservations will be accepted with 1 night deposit > > Balance due 30 days prior to arrival > > Reservations made 30 days or less prior to arrival will be > charged in full. > > Standard reservations cancellations policies apply - > reservations are non refuncable less than 14 days of arrival. ^----------------sounds intriguing, but I think this is meant to say “non-refundable.” ;-) Cheers, -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

1 0

Can Boost accept libraries that works only with C++0x compilers?
by vicente.botet 18 May '10

18 May '10

Hi, Boost has a high reputation due, between others, to having high portable libraries. I was wondering if this portability goal would not return against Boost, and limit the expressivenes of the libraries that can be included if we continue to force them to work with C++98 compilers. Even if C++0x is not yet released, there are already some compilers that allow to release these C++0X specific libraries. In order to have the best of both worlds, what do you think about start accepting libraries that are portable on C++0x compilers? This could be released as a separated package, that will, of course, depend on the current Boost package. I don't know if we need a specific namespace for these kind of libraries. Comments are welcome. Best, Vicente

7 11

Re: [boost] [contract] Boost spoiled function declarations
by Andrzej Krzemienski 18 May '10

18 May '10

> See examples below: Is Boost.Contract parenthesized syntax really more > complex than Boost.Parameter or Boost.Interface? > 1) While I recognize the ugliness of the Boost.Contract parenthesized > syntax, I think it is actually simpler than Boost.Parameter or > Boost.Interface syntax because it is essentially "the usual C++ syntax > with all the tokens wrapped within parenthesis". > 2) It is possible to provide Boost.Contract with macros similar to > ones of Boost.Parameter. Hi, I think you are succesfully making the point that Boost.Contract syntax is no worse than that of Boost.Parameter; and since the latter made it into Boost, the syntax of Boost.Contract should be considered acceptable too. What is interesting is whether it is possible to define a function that validates contracts and allows named parameters at the same time. You already said it was possible. I paste an example from your post below. struct g { CONTRACT_CLASS( (g) ) BOOST_PARAMETER_MEMBER_FUNCTION( (void), depth_first_search, tag, (required (graph, *) ) (optional (visitor, *, boost::dfs_visitor<>()) (root_vertex, *, *vertices(graph).first) (index_map, *, get(boost::vertex_index, graph)) (in_out(color_map), *, default_color_map(num_verticies(graph), index_map)) ) ) CONTRACT_FUNCTION( (public) (template)( (typename)(graph_type) (typename)(visitor_type) (typename)(root_vertex_type) (typename)(index_map_type) (typename)(color_map_type) ) (void) (depth_firt_search)( (graph_type&)(graph) (visitor_type&)(visitor) (root_vertex_type&)(root_vertex) (index_map_type&)(index_map) (copyable)(color_map_type&)(color_map) ) (postcondition) ({ CONTRACT_ASSERT( color_map == CONTRACT_OLDOF(color_map) + 10 ); }) (body) ({ color_map += 10; std::cout << "graph=" << graph << std::endl; std::cout << "visitor=" << visitor << std::endl; std::cout << "root_vertex=" << root_vertex << std::endl; std::cout << "index_map=" << index_map << std::endl; std::cout << "color_map=" << color_map << std::endl; }) ) }; This example is for sure more complex than any Boost.Parameter or Boost.Contract. I believe it should be possible to add another set of macros that would allow defining functions with named parameters and contract verification in a more simpler manner. E.g. something like: struct g { CONTRACT_CLASS( (g) ) CONTRACT_NAMED_PARAM_FUNCTION( // a new macro (public) (void) (depth_firt_search)( (CONTRACT_NAMED_PARAM_REQUIRED_ARG(&graph) CONTRACT_NAMED_PARAM_OPTIONAL_ARG(&visitor)(boost::dfs_visitor<>()) CONTRACT_NAMED_PARAM_OPTIONAL_ARG(&root_vertex)(*vertices(graph).first) CONTRACT_NAMED_PARAM_OPTIONAL_ARG(&index_map)(get(boost::vertex_index, graph)) CONTRACT_NAMED_PARAM_OPTIONAL_ARG(copyable)(color_map_type&)(color_map) (default_color_map(num_verticies(graph), index_map)) ) (postcondition) ({ CONTRACT_ASSERT( color_map == CONTRACT_OLDOF(color_map) + 10 ); }) (body) ({ color_map += 10; std::cout << "graph=" << graph << std::endl; std::cout << "visitor=" << visitor << std::endl; std::cout << "root_vertex=" << root_vertex << std::endl; std::cout << "index_map=" << index_map << std::endl; std::cout << "color_map=" << color_map << std::endl; }) ) }; Obviously, my example is syntactically wrong and may be impossible, but I think you get the general idea. I am not sure if it is Boost's requirement that different libraries should interoperate smoothly with one another, but it would surely be elegant. I am not sure if this is achievable, as the macro tricks employed in the above libraries are beyond my comprehension. Also, it is not clear whether it should be a task for Boost.Contract maintainer or Boost.Parameter maintainer - the issue seems symmetrical. Regards, &rzej

3 4

[MSM] move to trunk
by Christophe Henry 18 May '10

18 May '10

>Hello Christophe - > >I hope you had an uneventful trip home after boostcon. > >I am starting to use MSM 2.1 this week in a project. I have gotten the >tarball from the sandbox; however, it would be convenient to use the >library from the svn trunk so I can monitor changes before release. Do >you have a time line for checking in the library to trunk? > >Thank you for your time. Take care - >michael Hi Michael, I'm a bit jetlagged but (luckily) had an uneventfull trip back. And the BoostCon was worth it! I plan to check in into the trunk in the next few weeks, I really want MSM to be in 1.44. I only need to write some unit tests so it should be pretty quick. I'll post a mail as soon as I'm done. Cheers, Christophe

2 1

[shared_ptr] enable_shared_from_any ?
by Philip Warner 18 May '10

18 May '10

Many apologies if this has already been debated and discarded, but I have been using boost for a little while now, and most specifically boost::shared_ptr. I recently found enable_shared_from_this{2} and, in SVN, enable_shared_from_raw, and while both of these are extremely useful, ISTM they do not go quite far enough. Specifically, what I would like to see is a solution to the following code: C1 *p = new C1(); shared_ptr<C1> ptr(p); ... ...some time later.... shared_ptr<C1> ptr2<p>; and the resulting mess because of double-deallocation. Yes, one solution id discipline, but for a library developer, a better solution might be robustness in the face of (mild) ignorance or misuse. And yes, this is sloppy, but in our case we have a set of interfaces that want to implement variant function return types based on derived class pointers, and we can not do that by returning shared_ptr objects. We need to return raw pointers, then rewrap them. One solution is shared_from_this etc. Another is to extend shared_from_this so that *any* shared_ptr created from and object that inherits, say, enable_shared_from_any, will always get a shared pointer that works as one might expect. To this end we have built a (trivial) class that inherits from shared_ptr<T> and a matching base class, that together function to achieve what we need. The only real problem is we have to duplicate some parts of shared_ptr (constructors and operators mainly), the second problem is that not being experts in the very fine details of templates, boost, and cross-platform development, it would be extremely convenient if this functionality were implemented within shred_ptr in a similar way to the way enable_shared_from_this is done -- ie. only for those classes that implement an appropriate base class. The third problem is that because it does not have access to shared_ptr internals, it is not as efficient as it might be. Is submitting a patch to shared_ptr the appropriate way forward? Has this been discussed, debated and discarded before? If there is interest I am very happy to submit a patch, and I would also welcome any pointers (no pun intended) as to where the disadvantages and advantages of this kind of approach have been discussed before.

4 7

A Remedy for the Review Manager Starvation
by Joachim Faulhaber 18 May '10

18 May '10

Dear list, at boostcon (which was awesome :) we talked about the "review manager starvation" that boost is suffering from. I have offered a proposal on this topic, which seemed to have found a good acceptance at Tuesday evening's session. I'd like to share this proposal on the list now, in order to develop a more concrete policy, based on the proposal and its discussion. Where does the motivation come from? There is a huge amount of motivation in the "boost process". People really work their butts off. But this motivation is not everywhere in "boost world". Obviously it is lacking in the field of being a review manager. The motivation is mostly in the field of developing and contributing high quality generic libraries: Being a boost contributor. * People have a general desire to contribute something useful. * Boost contributors generally are passionate about generic library development. * Boost as a high quality library collection is THE platform for a contributor to place its contribution. * The boost community and list is an opportunity to learn from an elite in the field of generic library programming. * The formal review is both a reality test of the quality of a contribution and an acknowledgement by the experts. * The motivation to get into boost is caused by its high standards, because it makes boost attractive. * This in turn motivates not everyone, but those who are passionate about high quality generic programming. Boost is like a beautiful woman that is not easy to win. And this is a good thing. Let's be honest: Being accepted into boost and winning a beautiful woman has this in common: It extends our ego for a large part. (Whether this is always wise is another story ... but that's where we're after). So this is my suggestion: (1) Let's increase the standards: Let's make it more difficult for a library to be accepted into boost. (2) Let's create a new role: The Review Manager Assistant (RMA), who does almost all the work that is needed to manage a formal review. (3) To take on the job as a review manager assistant will be a precondition for a contributor to submit his own library. So we are making the contributors lives even harder with this... We should give them something on "the other side of the coin": (4) Let's foster a general culture of acknowledgement in boost. (5) Contribution must not be discouraged by inaction. (6) Contribution to boost is a win win game: Even if a library is not accepted there will be a value for the contributor and the boost community. To make this more concrete: (ad 1) Standards: The list of standards that a library submitted for review has to fulfill should be very clear, so the contributor can prepare his lib using that check list *and* the RMA can check the submission thoroughly. This list should be more explicit and more transparent than what we have now: To fulfill the list of requirements for a submission which is checked by the RMA is then the first certifiable standard of quality that a library can obtain in the review process. Included in the list of requirement for first time contributors should be: (1.1) 2 previews on the boost mailing list OR 1 boostcon presentation with a sufficient feedback of interest from the community (1.2) Issuing reviews for 2 formal reviews of other contributors. (1.3) Being RMA for another library once. (ad 2) A Review Manager Assistant (RMA) ... (2.1) does all the work that is necessary to check a library submission, organizes the process, moderates and files a final report, (2.2) unburdens the review manager from all kinds of detail work, except for the final verdict. (2.3) rejects the library submission, if it not yet fulfills all requirements. An RMA will probably be highly motivated, because he learns all about the standards and the review process that helps him for his own library project. (ad 5) An RMA is not necessarily needed for a review. If no RMA is found the review manager can do the job himself (current procedure). If an RMA volunteers he can start to organizing the review process. He checks the lib and requests a review manager, if necessary. If no one steps forward, the RMA starts the review process, which can not be halted by mere inaction. Any acceptable review manager can take that role. If no one takes action, the review is managed by the RMA. The RMA files the final report on the review within 2 weeks after it ends. The RM declares the result within 4 weeks after the review on the basis of the RMA's summary. (ad 6) Based on the high standards that are checked rigorously by the RMA a library submitted to boost gets certified as "conforms boost standards" or similar, even if it fails to be accepted into boost. In addition to the accepted boost libraries, there will be a collection of associated libraries (boost friends) that can be listed on a web page and that officially are allowed to use some logo that informs about the certified state. (ad 4) This is a form of acknowledgement for those who took on the project of a boost contribution but didn't make it into the core collection and to make them friends or associates of boost rather than "boost losers". So this is my proposal. I wanted to post this on the list because it is a result of this years boostcon and also the topic is kind of urgent. On the other hand you can not expect me to participate very much in this discussion for the next week, because I am on vacations. I'm looking forward to your thoughts and I will be back next week. Cheers Joachim P.S.: BoostCon was really great this year! Lot's of interesting talks and the sessions that addressed topics of the boost community were quite inspiring and creative. Not to mention the picnic and jam session (very enjoyable despite cold weather).

11 28

safe bool operator
by Domagoj Saric 18 May '10

18 May '10

While examining source and binary code for the various safe_bool/unspecified_bool_type implementations two issues can be noticed: - source code verbosity/repetition - binary code inefficiency The first issue is made worse by the fact that even this simple idiom is broken on some compilers ('pointed out' by workarounds in smart_ptr/detail/operator_bool.hpp) so workarounds must also be copied/'rediscovered'... The second issue (related to the usual implementation with member function pointers) has two sides, one is that taking the address of a function will force it to be included in the resulting binary even if it is never used or is always inlined and the second is that some compilers produce non-optimal code. For example for the following source code: boost::optional<int> test1; boost::optional<int> test2; __declspec( noinline ) void func() { if ( test1 ) test2 = *test1; } MSVC++ 8.0 and 9.0 will produce the following binary code ... 0F923A26 movzx eax,byte ptr [test1 (0F968210h)] 0F923A2D neg eax 0F923A2F sbb eax,eax 0F923A31 test eax,offset boost::optional_detail::optional_base<int>::is_initialized (0F923B9Eh) 0F923A36 je ... ... but if the if line is changed to if ( test1.is_initialized() ) the following code will be produced: ... 0F923A26 cmp byte ptr [test1 (0F968210h)],0 0F923A2D je ... ... At first I tried a solution that takes advantage of the fact that MSVC++ has plain-pointer-sized/register-sized member function pointers for plain single inheritance non virtual member functions and worked properly but than I found old discussions about the same subject: http://lists.boost.org/Archives/boost/2003/09/52846.php http://lists.boost.org/Archives/boost/2002/10/38624.php where the solution for MSVC++ was to use a pointer member data which gives the same results as my initial solution... Anyways I've attached a .hpp file with a draft implementation proposal (missing the compiler workarounds from smart_ptr/smart_ptr/detail/operator_bool.hpp for example) that uses both approaches... It enables a one liner implementation for a safe_bool operator: class my_class { public: bool some_is_valid_function() const; operator boost::unspecified_bool_type() const { return boost::make_safe_bool( some_is_valid_function() ); } //or by using a macro BOOST_SAFE_BOOL_FROM_FUNCTION( some_is_valid_function() ) } -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman begin 666 safe_bool.hpp M(W!R86=M82!O;F-E#0HC:69N9&5F('-A9F5?8F]O;%]H<' -"B-D969I;F4@ M<V%F95]B;V]L7VAP< T*+R\M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2T-"B-I;F-L=61E(")M<&PO8F]O;"YH<' B#0HO+RTM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0T*;F%M97-P86-E(&)O;W-T#0I[#0HO M+RTM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0T*#0IN86UE<W!A M8V4@9&5T86EL#0I[#0H@(" @<W1R=6-T('5N<W!E8VEF:65D7V)O;VQ?='EP M95]H96QP97(-"B @("![#0H@(" @(" @('9O:60@;65M8F5R7V9U;F-T:6]N M*"D@>WT[#0H@(" @(" @(&EN="!M96UB97)?9&%T85\[#0H@(" @?3L-"@T* M(" @('1Y<&5D968@=F]I9" H=6YS<&5C:69I961?8F]O;%]T>7!E7VAE;'!E M<CHZ*G5N<W!E8VEF:65D7V)O;VQ?='EP95]F=6YC=&EO;BD@*"D[#0H@(" @ M='EP961E9B!I;G0@("!U;G-P96-I9FEE9%]B;V]L7W1Y<&5?:&5L<&5R.CHJ M=6YS<&5C:69I961?8F]O;%]T>7!E7V1A=&$@(" @(" @(#L-"@T*(" @('5N M:6]N(&9A<W1?<V%F95]B;V]L#0H@(" @>PT*(" @(" @("!U;G-I9VYE9"!L M;VYG(" @(" @(" @(" @(" @(" @<&QA:6Y?<&]I;G1E<E]P;&%C96AO;&1E M<CL-"B @(" @(" @=6YS<&5C:69I961?8F]O;%]T>7!E7V9U;F-T:6]N('!O M:6YT97)?=&]?;65M8F5R(" @(" @(" [#0H@(" @?3L-"@T*(" @("\O(" @ M270@:7,@87-S=6UE9"!T:&%T(&EF('1H92!C;VUP:6QE<B!I<R!A8FQE('1O M(&9I="!A('!L86EN+"!S:6YG;&4-"B @(" O+R!I;FAE<FET86YC92!M96UB M97(@9G5N8W1I;VX@<&]I;G1E<B!I;G1O('-I>F5O9B@@=F]I9" J("D@=&AA M="!I=',@;G5L; T*(" @("\O(&)I;F%R>2!R97!R97-E;G1A=&EO;B!I<R!I M9&5N=&EC86P@=&\@82!P;&%I;B!N=6QL('9O:60@<&]I;G1E<B H86QL(&)I M=',-"B @(" O+R!Z97)O960I+B!7:71H;W5T(&$@=V%Y('1O(&-H96-K('1H M:7,@870@8V]M<&EL92!T:6UE('1H:7,@87-S97)T960@870-"B @(" O+R!R M=6YT:6UE+@T*(" @("\O(" @5&AE(&%B;W9E(&YE960@;F]T(&AO;&0@9F]R M(&1A=&$@;65M8F5R('!O:6YT97)S("AE+F<N($U35D,K*R!U<V5S("TQ#0H@ M(" @+R\@9F]R(&YU;&PM9&%T82!M96UB97(@<&]I;G1E<G,I+@T*(" @('1Y M<&5D968(a);7!L.CIB;V]L7SPH('-I>F5O9B@@9F%S=%]S869E7V)O;VP@*2 \ M/2!S:7IE;V8H('5N<VEG;F5D(&QO;F<@*2 I/B!C86Y?=7-E7V9A<W1?8F]O M;%]H86-K.PT*#0H@(" @='EP961E9B!M<&PZ.FEF7PT*(" @(" @(" @(" @ M/ T*(" @(" @(" @(" @(" @(&-A;E]U<V5?9F%S=%]B;V]L7VAA8VLL#0H@ M(" @(" @(" @(" @(" @=6YS<&5C:69I961?8F]O;%]T>7!E7V9U;F-T:6]N M+ T*(" @(" @(" @(" @(" @('5N<W!E8VEF:65D7V)O;VQ?='EP95]D871A M#0H@(" @(" @(" @(" ^.CIT>7!E('5N<W!E8VEF:65D7V)O;VQ?='EP93L- M"@T*(" @(&EN;&EN90T*(" @('5N<W!E8VEF:65D7V)O;VQ?='EP92!M86ME M7W-A9F5?8F]O;%]W;W)K97(H(&)O;VP@8V]N<W0@=F%L=64L(&UP;#HZ=')U M95\@+RIU<V4@9F%S="UH86-K('9E<G-I;VXJ+R I#0H@(" @>PT*(" @(" @ M("!F87-T7W-A9F5?8F]O;"!C;VYS="!F87-T4V%F94)O;VP@/2![('9A;'5E M('T[#0H@(" @(" @(&%S<V5R= T*(" @(" @(" H#0H@(" @(" @(" @(" H M("$A9F%S=%-A9F5";V]L+G!O:6YT97)?=&]?;65M8F5R(#T]("$A=F%L=64@ M*2 F)@T*(" @(" @(" @(" @(E1H92!V;VED+7!O:6YT97(M<VEZ960@;65M M8F5R('!O:6YT97(@;G5L;"!B:6YA<GDB#0H@(" @(" @(" @(" B<F5P<F5S M96YT871I;VX@87-S=6UP=&EO;B!D;V5S(&YO="!H;VQD(&9O<B!T:&ES(@T* M(" @(" @(" @(" @(F-O;7!I;&5R+W!L871F;W)M+B(-"B @(" @(" @*3L- M"B @(" @(" @<F5T=7)N(&9A<W13869E0F]O;"YP;VEN=&5R7W1O7VUE;6)E M<CL-"B @("!]#0H-"B @("!I;FQI;F4-"B @("!U;G-P96-I9FEE9%]B;V]L M7W1Y<&5?9G5N8W1I;VX-"B @("!M86ME7W-A9F5?8F]O;%]S=&%N9&%R9%]W M;W)K97(H(&)O;VP@8V]N<W0@8F]O;%]V86QU92P@=6YS<&5C:69I961?8F]O M;%]T>7!E7V9U;F-T:6]N(&-O;G-T(&YU;&Q?=F%L=64@*0T*(" @('L-"B @ M(" @(" @<F5T=7)N(&)O;VQ?=F%L=64@/R F=6YS<&5C:69I961?8F]O;%]T M>7!E7VAE;'!E<CHZ;65M8F5R7V9U;F-T:6]N(#H@;G5L;%]V86QU93L-"B @ M("!]#0H@(" @:6YL:6YE#0H@(" @=6YS<&5C:69I961?8F]O;%]T>7!E7V1A M=&$-"B @("!M86ME7W-A9F5?8F]O;%]S=&%N9&%R9%]W;W)K97(H(&)O;VP@ M8V]N<W0@8F]O;%]V86QU92P@=6YS<&5C:69I961?8F]O;%]T>7!E7V1A=&$@ M(" @(&-O;G-T(&YU;&Q?=F%L=64@*0T*(" @('L-"B @(" @(" @<F5T=7)N M(&)O;VQ?=F%L=64@/R F=6YS<&5C:69I961?8F]O;%]T>7!E7VAE;'!E<CHZ M;65M8F5R7V1A=&%?(" @(#H@;G5L;%]V86QU93L-"B @("!]#0H-"B @("!I M;FQI;F4-"B @("!U;G-P96-I9FEE9%]B;V]L7W1Y<&4@;6%K95]S869E7V)O M;VQ?=V]R:V5R*"!B;V]L(&-O;G-T('9A;'5E+"!M<&PZ.F9A;'-E7R O*G5S M92!S=&%N9&%R9"!V97)S:6]N*B\@*0T*(" @('L-"B @(" @(" @<F5T=7)N M(&UA:V5?<V%F95]B;V]L7W-T86YD87)D7W=O<FME<B@@=F%L=64L('5N<W!E M8VEF:65D7V)O;VQ?='EP92@@," I("D[#0H@(" @?0T*?2 O+R!N86UE<W!A M8V4@9&5T86EL#0H-"@T*='EP961E9B!D971A:6PZ.G5N<W!E8VEF:65D7V)O M;VQ?='EP92!U;G-P96-I9FEE9%]B;V]L7W1Y<&4[#0H-"@T*:6YL:6YE#0IU M;G-P96-I9FEE9%]B;V]L7W1Y<&4@;6%K95]S869E7V)O;VPH(&)O;VP@8V]N M<W0@=F%L=64@*0T*>PT*(" @(')E='5R;B!D971A:6PZ.FUA:V5?<V%F95]B M;V]L7W=O<FME<B@@=F%L=64L(&1E=&%I;#HZ8V%N7W5S95]F87-T7V)O;VQ? M:&%C:R@I("D[#0I]#0H-"B\O($EF('=E(&-O=6QD('5S92!M96UB97(@<&]I M;G1E<G,@8F5F;W)E('1H92!M96UB97(@:7,@86-T=6%L;'D@9&5C;&%R960O M<V5E;@T*+R\@=V4@8V]U;&0@=7-E($-25% M8F%S960@:&5L<&5R(&-L87-S M97,@9F]R(&UI;FEM=6T@=F5R8F]S:71Y('-A9F5?8F]O; T*+R\@:6UP;&5M M96YT871I;VYS.@T*+R\@=&5M<&QA=&4@/&-L87-S($)A<V4L(&)O;VP@*$)A M<V4Z.BIB;V]L7V9U;F-T:6]N*2 H*2!C;VYS=#X-"B\O(&-L87-S('-A9F5? M8F]O; T*+R\@>PT*+R\@(" @(&]P97)A=&]R('5N<W!E8VEF:65D7V)O;VQ? M='EP92@I(&-O;G-T('L@<F5T=7)N(&UA:V5?<V%F95]B;V]L*"!S=&%T:6-? M8V%S=#Q"87-E(&-O;G-T("H^*"!T:&ES("DM/BIB;V]L7V9U;F-T:6]N*"D@ M*3L@?0T*+R\@?3L-"B\O#0HO+R!C;&%S<R!M>5]C;&%S<R Z('!U8FQI8R!S M869E7V)O;VP\;7E?8VQA<W,L("9M>5]C;&%S<SHZ=F%L:60^#0HO+RXN+@T* M#0HO+RXN+FEN<W1E860@=V4@87)E(&QE9G0@=VET:"!M86-R;W,N+BX-"B-D M969I;F4@0D]/4U1?4T%&15]"3T],7T923TU?1E5.0U1)3TXH(&-O;G-T365M M8F5R1G5N8W1I;VX@*2!<#0H@(" @;W!E<F%T;W(@8F]O<W0Z.G5N<W!E8VEF M:65D7V)O;VQ?='EP92@I(&-O;G-T('L@<F5T=7)N(&)O;W-T.CIM86ME7W-A M9F5?8F]O;"@@8V]N<W1-96UB97)&=6YC=&EO;B@I("D[('T-"@T*(V1E9FEN M92!"3T]35%]3049%7T)/3TQ?1E)/35]$051!*" @(" @8V]N<W1-96UB97)$ M871A(" @(" I(%P-"B @("!O<&5R871O<B!B;V]S=#HZ=6YS<&5C:69I961? M8F]O;%]T>7!E*"D@8V]N<W0@>R!R971U<FX@8F]O<W0Z.FUA:V5?<V%F95]B M;V]L*"!C;VYS=$UE;6)E<D1A=&$@(" @(" @*3L@?0T*#0H-"B\O+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM#0I]("\O(&YA;65S<&%C92!B M;V]S= T*+R\M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2T-"B-E 7;F1I9B O+R!S869E7V)O;VQ?:'!P#0H` ` end

7 9

Library for base64
by deninok 18 May '10

18 May '10

Hi all! Is there any interest in a library for base64 encoding? Something like this: int main() { base64_encoder encode; std::string pure = "Hello world!"; std::string enc; encode( pure, enc ); // In enc: SGVsbG8gd29ybGQh ... } Library uses boost::dynamic_bitset. Denis -- View this message in context: http://old.nabble.com/Library-for-base64-tp28561821p28561821.html Sent from the Boost - Dev mailing list archive at Nabble.com.

8 10

[iterator] why isn't there a mapped_type iterator adaptor in boost?
by Mostafa 18 May '10

18 May '10

Hi all, Why isn't there a mapped_type/key_type iterator adaptor in boost? (Just in case it's not clear, something which allow one to iterator over the keys or the mapped-values of a map/multimap.) I would think this is a pretty common need. By the way, going through the archives this is all I could dig up: http://thread.gmane.org/gmane.comp.lib.boost.devel/117946 Additionaly something with a clearer syntax than the following would be great: make_transform_iterator( map.begin(), boost::bind( &MAP_TYPE::value_type::first, _1 )) ie, something along the lines of: take_mapped_type(map.begin()) Thanks, -Mostafa

6 13

[BGL] All-pair problem on a subset of vertices
by Cosimo Calabrese 18 May '10

18 May '10

Hi to all, if we want to find the shortest distance between *every* pair of vertices in a graph, we can use the Jonson's or Floyd-Warshall's algorithm, obtaining a NxN matrix of distances, where N is the total number of the graph's vertices. The problem is: how can I do if I don't need the distance of *every* pair of graph's vertices, but I'm interested in only a subset of vertices? In other words, I would to obtain a MxM matrix, where M<N. In every case, I'm not interested in path from the pairs, but only in the distance. My solution is to execute M times the Dijkstra algorithm from every vertex of the subset, and to abort every exploration when I've founded the Mth vertex of the subset. Are there something of more efficent? My graphs contain approximately 12 millions of vertices, but I'm interested in a subset of 10.000 vertices. Thanks in advance, Cosimo Calabrese.

2 2

[Boost][Thread] Non-copyable boost::thread
by Belcourt, Kenneth 18 May '10

18 May '10

Hi, The Boost.Thread documentation points out that boost::thread is non- copyable but then goes on to provide rational for why it should be possible to return by value from make_thread_return_local(). Intel-11.1 on Darwin is a recent compiler that will not compile this code. [ from libs/thread/test/test_thread_return_local.cpp ] boost::thread make_thread_return_local(boost::thread::id* the_id) { boost::thread t(do_nothing,the_id); return t; } The same error message is generated in both debug and release builds on Darwin (though strangely it doesn't appear to be an error with Intel 11.1 on Linux). "/opt/intel/Compiler/11.1/067/bin/intel64/icpc" -xc++ -w1 -O0 -g - inline-level=0 -vec-report0 -DBOOST_ALL_NO_LIB=1 - DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_THREAD_POSIX - DBOOST_THREAD_USE_LIB=1 -I".." -c -o "/Volumes/Scratch/kbelco/boost/ results/boost/bin.v2/libs/thread/test/ test_thread_return_local_lib.test/intel-darwin-11.1/debug/threading- multi/test_thread_return_local.o" "../libs/thread/test/ test_thread_return_local.cpp" ../libs/thread/test/test_thread_return_local.cpp(16): error #373: "boost::thread::thread(boost::thread &)" (declared at line 111 of "../ boost/thread/detail/thread.hpp") is inaccessible return t; ^ Any ideas how to work around this failure? Thanks. -- Noel

3 10

feenablexcept doesn't exist on Darwin
by Christopher Jefferson 17 May '10

17 May '10

boost::test recently started using feenableexcept, which is not supported on Darwin / Apple. See https://svn.boost.org/trac/boost/ticket/4222 for patch. This bug is particularly annoying as it is causing many failures, as the problem is in the testing code.

3 2

Visual Studio 2010 Template Limits
by Daniel Larimer 17 May '10

17 May '10

I have written some code that makes heavy use of templates and which compiles just fine using g++; however, when I recently tried to compile the code in VC++ 2010 I got a fatal error C1063: compiler limit : compiler stack overflow. It directs me to this template... See reference to class template instantiation 'delegate<T1>::overloads<1,S0,ptr0>' being compiled The general code structure is... template<T1> class delegate { template<typename RTN, typename TY PARAM_TNS, RTN (TY::*m_ptr)(PARAM_PTS)> class method_impl<RTN (TY::*)(PARAM_PTS), m_ptr> : public method; // specialized for n with BOOST_PP_ITERATE (blows up even if n == 1) template<int, typename S0, S0 ptr0> class overloads<n, PARAM_TYPES> : public method_impl<S0,ptr0>, public method_impl<S1,ptr1> ... { }; }; I don¹t even need to instantiate delegate<ForSomeType>, simply including the header causes it to blow up. Considering the extent to which boost uses and ³abuses² templates I thought I would ask whether anyone here knows of some limitation or constructs which I must avoid? Is there some way to increase the ³stack² for VC++¹s CL program? Dan

2 1

[contract] Boost spoiled function declarations
by Lorenzo Caminiti 17 May '10

17 May '10

Hello all, I have been looking into other Boost libraries besides my Boost.Contract that spoil function declarations using macros. I found that both Boost.Parameter (approved) and Boost.Interface (under construction) significantly spoil function declarations. Boost.ConceptCheck also spoils function declarations but its REQUIRE macro has a very simple syntax so I am not comparing it with Boost.Contract. See examples below: Is Boost.Contract parenthesized syntax really more complex than Boost.Parameter or Boost.Interface? Boost.Contract (under construction) BOOST_CONTRACT_FUNCTION( (inline) (double) (sqrt)( (double)(x) ) (precondition)( (x >= 0.0) ) (postcondition)(result)( (result == x * x) ) ({ ... }) ) Note that the usual C++ syntax would have been essentially the same as above but without the extra parenthesis `()`. Boost.Parameter (approved) BOOST_PARAMETER_FUNCTION( (void), depth_first_search, tag, (required (graph, *) ) (optional (visitor, *, boost::dfs_visitor<>()) (root_vertex, *, *vertices(graph).first) (index_map, *, get(boost::vertex_index,graph)) (in_out(color_map), *, default_color_map(num_vertices(graph), index_map) ) ) ) { ... } Boost.Interface (under construction) BOOST_INTERFACE_BEGIN(IShape) BOOST_INTERFACE_CONST_FUNCTION0(GetX, int) BOOST_INTERFACE_CONST_FUNCTION0(GetY, int) BOOST_INTERFACE_CONST_FUNCTION0(GetArea, double) BOOST_INTERFACE_FUNCTION2(SetXY, void, (int, x), (int, y)) BOOST_INTERFACE_FUNCTION2(OffSetXY, void, (int, x), (int, y)) BOOST_INTERFACE_CONST_FUNCTION0(GetName, const char*) BOOST_INTERFACE_END(IShape) 1) While I recognize the ugliness of the Boost.Contract parenthesized syntax, I think it is actually simpler than Boost.Parameter or Boost.Interface syntax because it is essentially "the usual C++ syntax with all the tokens wrapped within parenthesis". 2) It is possible to provide Boost.Contract with macros similar to ones of Boost.Parameter. However, Boost.Parameter only supports const/non-const members while Boost.Contract also supports volatile, virtual, inline/extern, auto/register, function templates, and everything else. If specific macros were to be provided for all these different function traits plus their combinations, Boost.Contract will have a *lot* of macros. For example, just to support qv-qualifiers, Boost.Contract should provide CONTRACT_FUNCTION(), CONTRACT_FUNCTION_CONST(), CONTRACT_FUNCTION_VOLATILE(), CONTRACT_FUNCTION_CONST_VOLATILE(). Plus all these qv-qualifier macros will have to be combined with inline, virtual, etc -- the number of macros grows combinatorially in the number of function traits! Instead the parenthesized syntax allows you to specify or omit the function traits directly in the function declarations so all the traits can be combined as usual in C++ and with the use of one single macro CONTRACT_FUNCTION(). Regards, -- Lorenzo

1 0

[MSM] move to trunk
by Michael Caisse 17 May '10

17 May '10

Hello Christophe - I hope you had an uneventful trip home after boostcon. I am starting to use MSM 2.1 this week in a project. I have gotten the tarball from the sandbox; however, it would be convenient to use the library from the svn trunk so I can monitor changes before release. Do you have a time line for checking in the library to trunk? Thank you for your time. Take care - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

Namespace for a Boost Hashing Library
by Scott McMurray 17 May '10

17 May '10

I initially used boost::hash, forgetting that the unordered containers have already claimed that name. A number of alternatives have been proposed, so I hoped to get some thoughts from the wider community. The intention for the library is to provide concepts and some implementations for checksums (like CRC32), plain hash functions (for hash tables), and cryptographic hash functions (like MD5 or SHA-256). Some possibilities: - boost::hashes Following the usual boost method of a plural namespace when a class exists. - boost::hash_algo or boost::hash_algorithms Following the string_algo precedent. - boost::hashing or boost::hashing_algorithms Using a gerund for a change. - boost::digests or boost::message_digest Using the name of the result of a hash, rather than the process. - boost::fingerprint (or boost::dactylogram) An alternative name for the result of a hash. - Something else better that you come up with Some complaints raised about those options: - boost::hashes or boost::hashing or boost::digests It's hard to remember when namespaces aren't singular as usual (especially for the first two, when the library doesn't provide anything named "hash"). - boost::hash_algo It would be better to not use an abbrev. - boost::hash_algorithms or boost::hashing_algorithms or boost::message_digest Shorter namespaces are generally preferred, where possible. - boost::fingerprint (or boost::dactylogram) Implies a particular use and certain minimum length of result. Which one(s) do you prefer or dislike? Thanks, ~ Scott McMurray

10 15

www.boost.org: update link to boost Jam 3.1.18 instead of 3.1.17?
by Wolfgang Fertsak 17 May '10

17 May '10

Hi, I just noticed that the link to Boost Jam in the download-section in www.boost.org still points to Version 3.1.17, although 3.1.18 is available since march... Best regards, Wolfgang

1 0

[Boost.Thread] Patch for Intel on Darwin
by Belcourt, Kenneth 17 May '10

17 May '10

Hi, The thread library is failing to build with Intel on Darwin with this error. "/opt/intel/Compiler/11.1/067/bin/intel64/icpc" -xc++ -w1 -O0 -g - inline-level=0 -vec-report0 -DBOOST_ALL_NO_LIB=1 - DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -I".." -c -o "/Volumes/ Scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/intel- darwin-11.1/debug/threading-multi/pthread/thread.o" "../libs/thread/ src/pthread/thread.cpp" ../libs/thread/src/pthread/thread.cpp(385): error: identifier "get_nprocs" is undefined return get_nprocs(); ^ The fix is to test for Apple and Intel before the GNU test. Index: libs/thread/src/pthread/thread.cpp =================================================================== --- libs/thread/src/pthread/thread.cpp (revision 61969) +++ libs/thread/src/pthread/thread.cpp (working copy) @@ -381,6 +381,10 @@ { #if defined(PTW32_VERSION) || defined(__hpux) return pthread_num_processors_np(); +#elif defined(__APPLE__) && defined (__INTEL_COMPILER) + int count; + size_t size=sizeof(count); + return sysctlbyname("hw.ncpu",&count,&size,NULL,0)?0:count; #elif defined(_GNU_SOURCE) return get_nprocs(); #elif defined(__APPLE__) || defined(__FreeBSD__) This has been tested on Darwin and Linux. Okay to commit? -- Noel

2 1

[website] [1.43.0] broken link
by Mostafa 17 May '10

17 May '10

FYI, The following webpage: http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/reference.ht… has a broken link at the "Overview" section, ie, http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/reference/ov… -Mostafa

3 3

Re: [boost] New moderators request unclear? (was: A Remedy for the Review Manager Starvation)
by Thomas Klimpel 17 May '10

17 May '10

Manfred Doudar wrote: > And now, I think a little more about Joachim's mail, and the stated > reception his ideas had at BoostCon (no, I wasn't there - but take > Joachim on his word); and now also recall Beman's email of a while > back, asking for persons to come forward and nominate themselves to > moderate the list - because: Oh, maybe I completely misunderstood Beman's request then. I'm not a native speaker, but I even looked up "nominate" at <http://dict.leo.org>. It seems to mean something like "to elect somebody". (I had looked it up, because it was unclear to me whether "nomination" includes asking the person for permission first.) But as you put it, it seems to mean something like "to volunteer". > "[existing moderators'] day job responsibilities have changed, or > other distractions are preventing them from giving list moderation > the attention it deserves." > > ..this makes me think that there is a call of sorts for "new-blood", > because some boosters are moving on, in some respects (not > necessarily entirely, but other responsibilities keep them away, and > they may not be able to devote as much time as they once did, be it > moderation or otherwise). I wasn't sure here whether Beman was explicitly asking for new blood, or just formulating his request in a way that it was clear that new blood was also allowed. But if somebody would nominate Eric Niebler, Daniel James, Rene Rivera, Hartmut Kaiser, Vladimir Prus, Robert Ramey, Gennadiy Rozental, Joel de Guzman or any other of the usual suspect, I'm pretty sure that Beman wouldn't object. So if I understood Beman's request correctly, he is still waiting for additional nominations. If I understood him incorrectly, and he is just waiting for volunteers, I think he should add a clarification to his request that is also understandable for non-native speakers (that are unaware of the connotations of the word "nomination", if these connotations should really exist). Regards, Thomas

3 2

[test] New location of fraction_tolerance()
by Jeremiah Willcock 16 May '10

16 May '10

There used to be a function named fraction_tolerance() in boost::test_tools (in <boost/test/floating_point_comparison.hpp>) that marked that a floating-point comparison uses a fraction as its tolerance value. That function seems to have disappeared in one of the recent checkins. What is the intended replacement? There is no boost::math::fpc::fraction_tolerance which is what appears from the new naming pattern to be the correct name. Is there an equivalent to that function? -- Jeremiah Willcock

2 1

[contract] static assertions
by Lorenzo Caminiti 16 May '10

16 May '10

Hello all, Shall Boost.Contract static static assertions? 1) N1962 removed static assertions previously added by revisions N1866 and N1773 of the same proposal -- why? 2) In my experience, I never used static assertions within the contracts. However, I am thinking to provide them because they might be useful to better document contract interfaces with assertions that can be efficiently evaluated at compile-time. For example: template<typename T> struct x { CONTRACT_CLASS( (x) ) public: CONTRACT_FUNCTION( (public) (void) (f)( (T)(val) ) (precondition)( (static)(sizeof(T) <= sizeof(long)) // static assertion (checked at compile-time) (val != 0) // run-time assertion ) ({ ... }) }; This code will use one of the BOOST_MPL_ASSERT() to assert the static condition in the precondition function generated by the CONTRACT_FUNCTION() macro. I think this is similar to asserting BOOST_MPL_ASSERT((sizeof(T) <= sizeof(long))) in the function body or at class scope. However, having the static assertion in the contracts has the following advantages: (+) The static assertion compilation and check can be selectively enabled/disabled when preconditions/postcondition/invariants are turned on/off using CONTRACT_CHECK_PRECONDITON/etc. (+) It more clearly documents that the (static) requirement `sizeof(T) <= sizeof(long)` is added by the function f (instead of the class or some other member function). -- Lorenzo

3 4