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

Book "The Boost C++ Libraries" now in English
by Boris Schaeling 23 Jun '10

23 Jun '10

Andreas and I are pleased to announce that the book "The Boost C++ Libraries" is now available in English: <http://en.highscore.de/cpp/boost/> At this point I have to thank Andreas who started translating the 16 chapters of my book nearly a year ago and managed to finish this tremendous amount of work after all that time. Without him there wouldn't be a single sentence of my book available in English. Thank you, Andreas! :-) While you can simply click on <http://en.highscore.de/cpp/boost/> and have a look, here are some explanations in case someone is interested: * The book is licensed under a Creative Commons License and can be copied, distributed and transmitted for non-commercial use. As the part "for non-commercial use" might raise some concerns: You are definitely allowed to use the book at work (print it, hand it out to colleagues, publish it on intranet web servers etc.). We also welcome trainers who want to use the book in classes about the Boost C++ libraries (even if you are paid as a trainer). There is no need to ask us for permission either. What we don't want to see though is e.g. a commercial IT magazine simply filling pages by printing the book. * The book currently consists of 16 chapters. While there are some chapters which present only one library, others introduce a couple of libraries. I decided not to write one chapter per library because some libraries are so small that it's all explained within a few paragraphs. If you want to lookup libraries though you find direct links in the overview at <http://en.highscore.de/cpp/boost/introduction.html#introduction_overview>. * There is a link "Found an error? Fix it in your browser!" below the table of contents in every chapter (your browser must support Javascript to display the link). If you click on the link the webpage becomes editable. This makes it rather easy to fix typos or other mistakes. Changes are saved on the server and will be reviewed (to protect against spam). * If you click on "Found an error? Fix it in your browser!" there is another option called "Mark keywords". If you select this option you can mark words (by clicking on them). The idea is to create an index by marking those words which you think should be included in an index. As it's quite a lot of work to create a good index we welcome proposals of what to include. * For those who know German there is still the original version of the book at <http://www.highscore.de/cpp/boost/>. The content is the very same (even same sample codes). We will also keep the books in sync (it's not that the German version won't be updated anymore). * You can download the HTML version of the book from <http://en.highscore.de/cpp/boost/The%20Boost%20C++%20Libraries.zip>. The ZIP file contains all the web pages and other resources you need to read the book offline. For those who'd like to get a PDF or ePub version of the book there are links to download them. You'll notice that the download of those versions is not for free. The money is used to pay server costs and to finance new chapters. We hope you agree that the prices are reasonable. * If you purchase the ePub version of the book I am very interested in your feedback. As the eBook market is still rather small it's difficult to get the feedback you need to understand what to improve. Given that there have been many discussions lately about what's wrong with Boost, we hope that this book will give the Boost libraries and C++ another, well, boost. :-) Boris

14 16

[GSoC][Phoenix3] Regarding mutability of arguments passed to phoenix expressions
by Thomas Heller 14 Jun '10

14 Jun '10

Regarding arguments to phoenix expressions there are two possibilities. The first is: Arguments are mutable. The current phoenix is implemented to be able to this. Example: int i( 1 ); ( ++phoenix::arg_names::arg1 )( i ); The result of ++phoenix::arg_names::arg1 will be 2, i will have the value 2 after the expression is evaluated. The other approach would follow a more functional programming style as the data will not be mutable int i( 1 ); [1] ( ++phoenix::arg_names::arg1 )( i ); [2] ( ++phoenix::arg_names::arg1 + phoenix::arg_names::arg1 )( i ); The result of [1] will be 2, however i does not get changed (it remains to be 1). The result of [2] will be 3. i still unchanged. This example would be working "out-of-the-box" with the current prototypes. To get the mutability back into phoenix i propose the use of phoenix::ref. I favor the second approach. However, this would break API compatibility between the existing implementation. The question i want to ask the current and prospective users if it feasible to break your existing code? Is there a lot of existing code depending on this behaviour? Does it make sense to break code in such a way? Regards, Thomas

10 28

boost::thread compiler error on SUN CC 5.9
by Urs Stotz 08 Jun '10

08 Jun '10

boost::thread give a compile error on SUN CC 5.9: /opt/SUNWspro/bin/CC +d -library=stlport4 -library=stlport4 -xcode=pic32 -erroff=wvarhidemem,hidevf,hidevfinvb -errtags=yes -features=tmplife -features=tmplrefstatic -g -mt -erroff=%none -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -I"." -c -o "bin.v2/libs/thread/build/sun-5.9/debug/stdlib-sun-stlport/threading-multi/pthread/thread.o" "libs/thread/src/pthread/thread.cpp" "libs/thread/src/pthread/thread.cpp", line 77: Error, badbinaryop: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> && void*" is illegal. "libs/thread/src/pthread/thread.cpp", line 588: Error, badbinaryop: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> || void*" is illegal. 2 Error(s) detected. make: *** [thread.o] Error 2 with this small patch it will compile: --- boost_1_42_0.org/libs/thread/src/pthread/thread.cpp 2009-10-19 11:18:13.000000000 +0200 +++ boost_1_42_0/libs/thread/src/pthread/thread.cpp 2010-02-10 13:48:25.037748000 +0100 @@ -74,7 +74,7 @@ namespace boost { current=next; ++next; - if(current->second.func && current->second.value) + if(current->second.func && (current->second.value != 0)) { (*current->second.func)(current->second.value); } @@ -585,7 +585,7 @@ namespace boost { (*current_node->func)(current_node->value); } - if(func || tss_data) + if(func || (tss_data != 0) ) { current_node->func=func; current_node->value=tss_data;

3 2

[multiindex] internal scope_guard has changed access from public to protected
by Thorsten Ottosen 31 May '10

31 May '10

Hi Joaquín, I'm using the scope_guard from multi_index/detail/scope_guard.hpp. It seems like a revision has made the destructor and copy-constructor protected instead of private. This is in some sense more idiomatic, but it breaks a use that I have in my upcomming auto_buffer class. Basically I'm only constructing a scope_guard object when I know the code can throw, otherwise I construct a "null" scope_guard which is simply an instance of scope_guard_impl_base. Here's the code: namespace auto_buffer_detail { typedef boost::multi_index::detail::scope_guard_impl_base null_guard; } #define BOOST_AUTO_BUFFER_CONSTRUCTOR_SCOPE_GUARD() \ boost::has_nothrow_copy<T>::value ? boost::auto_buffer_detail::null_guard() : \ boost::multi_index::detail::make_obj_guard( *this, \ &auto_buffer::deallocate, \ buffer_, members_.capacity_ ) and use it like so: boost::multi_index::detail::scope_guard guard = BOOST_AUTO_BUFFER_CONSTRUCTOR_SCOPE_GUARD(); ... guard.dismiss(); Any chance you make the two members public again? -Thorsten

6 19

[castor] Interest in Logic Paradigm for C++ ?
by Roshan Naik 23 May '10

23 May '10

Based on suggestions from some Boost community experts, I would like to gauge interest to see if there is broader interest for including the Castor library into Boost. In short, Castor's aim is to foster multiparadigm programming in C++ by supporting techniques from the Logic Paradigm. See below for a longer description. ============== Description: ============== Logic Paradigm (LP) is a general purpose declarative programming paradigm. It focuses on "what" to compute and not "how" to compute. Although LP has been well explored in Computer Science as a fundamental computational model, it remains unavailable for main stream software development due to lack of support in popular programming languages. Prolog is perhaps the most commonly known language among those that support LP. Castor takes a pure library approach (i.e. without language extensions) for introducing LP to C++. Instead of providing a Logic interpreter or evaluation engine in library form, Castor provides a few simple library primitives on which LP techniques can be supported. This approach allows a natural and deep integration of declarative code into the language and also provides the flexibility of freely combining Logic with the other paradigms such as OO, generics, functional etc. STL concepts like iterators, containers and streams can also be used in declarative code. For an introductory tutorial on LP in C++ and Castor please refer to http://mpprogramming.com/downloads/betaTutorial.pdf. Castor is intended to be a free standing library that depends only on the standard C++ library. It does not depend on Boost or other libraries. It is a pure header library. ============== Current State: ============== A stable 1.0 version has been available since 2008 on www.mpprogramming.com/cpp under the MIT license. Work on version 1.1 is in progress and an early beta is now available. Current efforts are directed largely towards making Castor a richer "standard library" for working with LP in C++. Castor was not originally targeted for Boost but more recently I have been giving it more serious consideration regarding inclusion into Boost. At the upcoming BoostCon 2010 I will be presenting 'Logic Paradigm for C++'. If there is interest, my thought is that feedback from the Boost review/submission process and modifications to satisfy other Boost requirements/guidelines will perhaps yield a 1.2 version that will become the real Boost candidate. Any help in this space will be much appreciated. ================== Links for Castor - v1.1 beta (ported to Gcc 4.4.1 and VC++ 2008) : ================== Library+docs: http://mpprogramming.com/downloads/prebeta-1.1.zip Individually downloadable documentation: Tutorial: http://mpprogramming.com/downloads/betaTutorial.pdf Reference Manual: http://mpprogramming.com/downloads/betaRefManual.pdf Design doc: http://mpprogramming.com/downloads/betaDesignDoc.pdf - Roshan Naik

16 52

Let's use stack exchange!
by Gennadiy Rozental 21 May '10

21 May '10

Hi, I've always envied a bit how stackoverflow site was operating. I like the interface much better than mailing lists. Search, filtering, thread tracking... Now that the engine behind it is free http://www.joelonsoftware.com/items/2010/04/13.html I think we can benefit a lot from using it for boost. In addition it should help us with review managers issues. We can use "reputation" based system to qualify potential managers. In practice: who should agree to this and who would do the work? Gennadiy

9 13

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

[interprocess] flat_set/flat_map should add front(), back(), operator[], pop_back()
by Thorsten Ottosen 13 May '10

13 May '10

Hi Ion, When using e.g. a flat_set as a priority queue, it is annoying not to have back() and pop_back() available. As for operator[](), then of couse cont.begin()[n] works, but this is somewhat less pretty compared to just cont[n]. Therefore I would really like to see all the above functions added to the interface. kind regards Thorsten

2 2

BOOST_NO_EXTERN_TEMPLATE check is broken
by Doug Gregor 12 May '10

12 May '10

The current Boost.Config check for BOOST_NO_EXTERN_TEMPLATE uses incorrect syntax. The test, in libs/config/test/boost_no_extern_template.ipp, looks like this: namespace boost_no_extern_template { extern template<class T> void f(T); int test() { return 0; } } The "extern" in C++0x extern templates can only be placed on explicit template instantiations. Here's a better test: namespace boost_no_extern_template { template<typename T, typename U> void f(T* p1, U* p2) { p1 = p2; } extern template void f(int*, float*); int test() { return 0; } } If the compiler rejects or ignores the "extern" in that explicit template instantiation declaration, we'll get an (invalid) compiler error. Grepping through the compiler configurations, BOOST_NO_EXTERN_TEMPLATE is set for several compilers that do in fact have support for C++0x extern templates, namely GCC and EDG-based compilers (when in either in C++0x or non-strict mode). - Doug

2 1

[xint] Third release is ready, requesting preliminary review
by Chad Nelson 09 May '10

09 May '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm happy to announce that the third release of the Extended Integer library is ready, in both the sandbox and the Vault. This is a major overhaul of the library, taking into account all of the feedback and recommendations provided on the first two: * The exception-blocking system is gone, replaced by a separate nothrow_integer class. * There's now a fixed_integer class template as well. * The test functions now use Boost.Test, and the documentation has been moved to Doxygen. * Nearly every function received a thorough examination as well; many of them were tweaked, and a few completely replaced. Please take a look and let me know what you think of the changes. I'm very happy with them. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvabA0ACgkQp9x9jeZ9/wSwvACcCJ18QkRbKWmByYO7Q1xe6qYx EUYAnRl4+mzw9X2VvGCCFPl0Q0VWLhRN =fhbW -----END PGP SIGNATURE-----

21 230