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

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

[GSoC] Helping out Phoenix v3
by Joel Falcou 04 May '10

04 May '10

Joel and I pondered about getting a student from GSoC to help us complete the phoenix v3 port to proto. I currently have a few prototypes and ideas to extend it further but a few more hands are most welcome. Considering the schedule, I'll be compeltely free for mentoring this prospective student. Now, is it realistic and on topic for GSoC ?

9 33

Re: [boost] [repost][multiarray] Bug with boost::detail::multi_array::array_iterator on MSVC 2010RC?
by Thomas Klimpel 04 May '10

04 May '10

Jesse Perla wrote: > I have attached my test files. Any ideas or patches would be appreciated I could reproduce the problem with MSVC 2010beta2. I noticed that only the debug version fails to build. So I added the line #define _HAS_ITERATOR_DEBUGGING 0 and everything compiled fine. So the simplest solution is to add ADD_DEFINITIONS(-D_HAS_ITERATOR_DEBUGGING=0) to your CMakeLists.txt, which many people recommend in any case, because they claim that the debug version under MSVC would otherwise violate the "runtime complexity specifications" of the corresponding containers and iterators. (I don't know whether this is really true, but I really think that this workaround is not unreasonable.) But of course, you want to know whether this is a bug in boost::multi_array or a bug in MSVC 2010beta2. Before we come to that, another "workaround" would be to change multi_array/iterator.hpp:56 for , boost::random_access_traversal_tag to , std::random_access_iterator_tag This will most probably work, but would lying to the standard library, because the reference reference type of the corresponding iterator is not value_type& (but a proxy): http://lists.boost.org/boost-users/2006/11/23565.php What effectively happens it that the iterator gets the category "input_iterator", but std::copy wants to have an "output_iterator". I think I understand why the iterator doesn't satisfies the requirement of a "forward_iterator", but it's unclear to me why it didn't qualify as an "output_iterator". There is an "input_output_iterator_tag" in "boost/iterator/detail/facade_iterator_category.hpp", so it would have been possible for the iterator to be both "input_iterator" and "output_iterator". However, it seems to me that "input_output_iterator_tag" is never used in the Boost.Iterator library. I would have to read more about "output_iterator" to understand whether Boost.Iterator is correct here. With my current understanding of "output_iterator", I would say it's a bug in "boost/iterator/detail/facade_iterator_category.hpp". Perhaps somebody with more knowledge about "output_iterator" and Boost.Iterator can explain to me why an iterator using the "boost::random_access_traversal_tag" for the "CategoryOrTraversal" template parameter of "iterator_facade" will never get the category "output_iterator" (or "input_output_iterator_tag"). Regards, Thomas

4 6

Help with VeecoFTC - exception - cloning_test / msvc-9.0~wm5~stlport5.2
by Emil Dotchevski 24 Apr '10

24 Apr '10

Can someone help me figure out what's going on here: http://tinyurl.com/ybpbsp4 Thanks! Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

3 5

[RangeEx] Where is the current version?
by Mathias Gaunard 19 Apr '10

19 Apr '10

Where is the current version (or a fairly recent version) of RangeEx? I can't find anything on the trunk, the sandbox or the vault.

5 13

[asio] read_until -- possibly misleading documentation?
by Richard Smith 15 Apr '10

15 Apr '10

The documentation for Boost.ASIO (which is otherwise very comprehensive) says of the boost::asio::read_until set of overloads: | Read data into a streambuf until a delimiter is | encountered. <http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/reference/read_unt…> What the function actually does is to read blocks of data into the streambuf, and stop when the delimiter is found. This means that frequently data beyond the delimiter will be read into the streambuf. (And this is elaborated in more detail on the individual function's pages, if a reader looks there.) I appreciate that this behaviour is compatible with the documentation, but someone less familiar with ASIO could easily assume that the function will read as far as the delimiter and no further. (And I have just spent a fair amount of time debugging a piece of code where the author had made this assumption.) Could we change the summary documentation to read something like: | Read data into a streambuf at least until a delimiter is | encountered. The implementation may read beyond the | delimiter, but will not block when doing so. While I'm on the subject of ASIO documentation, I can't see any documentation on whether the service_name parameters to the basic_resolver_query constructors are allowed to be port numbers (e.g. "80") or whether they have to be symbolic names (e.g. "http"). Port numbers work, at least on Linux, but it's not clear whether this is something that I should be relying on. Similarly for IPv4 and IPv6 addresses in the host_name parameter. Richard Smith

3 2

Guidelines on wiki
by Daniel James 13 Apr '10

13 Apr '10

Hello, I've copied the guidelines onto the wiki now, you can see them at: https://svn.boost.org/trac/boost/wiki/Guidelines/ Any comments? I've changed the beta site to redirect to them. I haven't linked to them from the front page of the wiki as they aren't 'official' yet. I'll be moving more pages over soon-ish. Any ideas about how the wiki should be structured? Daniel

5 10

GSOC 2010 - BGL Graph Connectives.
by Tri Nguyen 12 Apr '10

12 Apr '10

Hi, I am Tri Nguyen from South Plains College. I am interested in Graph Connectives Project of BGL. In this writing, I would like to ask two questions, and then propose my idea of doing four Connectives: union, join, intersection, and difference. My first question is: How big is the graph? Or students will try to do as big as possible. My second question is: What type of data-structures (matrix or list) will be used? I attached my ideas in the PDF file below. Please have a look. I appreciate all responses, Thank you, Tri Nguyen.

4 15

GSoC2010 Sweepline Algorithm
by Andriy Sydorchuk 12 Apr '10

12 Apr '10

Hi, Boost Community! I am interested in participation in GSoC 2010. The project I liked the most is the generic implementation of Sweepline Algorithm. Basically fast and robust Sweepline Algorithm requires implementation of next data structure: 1) Event Queue (priority queue). 2) Sweep Line (self-balancing binary search tree). 3) Output datastructures (voronoi vertices, triangulation edges, etc.). Based on that I got next questions: - Which kind of self-balancing binary trees is better for that kind of approach? I am thinking about Red-Black Trees in prefer to AVL trees, as sweepline algorithm requires more adding and deletion operations. And AVL trees are better for look up operations. - STL library includes two generic implementations of self-balancing binary trees (red-black): map, set. I am quite new with Boost library, but probably there are some more specific self-balancing binary tree implementations there? - For Voronoi diagram and delaunay triangulation input data is set of points. What about input of the Medial Axis problem? -- Best, Andrii Sydorchuk

4 33

[BGL] Revisiting Parallel BGL
by Sandeep Gupta 12 Apr '10

12 Apr '10

Hi, I raised the issue of parallel BFS not working correctly here http://lists.boost.org/boost-build/2009/10/22631.php. The issue remained unresolved. I revisited it for last two days and the incorrectness in likelihood is probably due to initialization of distance property map for all non-start vertex to be infinity. Hope this helps. Thanks Sandeep

3 17