- Boost - lists.boost.org

FYI: Improved GMane Archive Search
by David Abrahams 06 Jan '05

06 Jan '05

Lars Magne Ingebrigtsen, the man behind GMane, recently told me about a new search facility: "<URL: http://rain.gmane.org/> -- it's a Xapian-powered search. It's still in beta, and recent articles aren't in its index. You can advertise it, but it's likely to be out of commission now and then as the Xapian people work on it." Now you know all. It does seem to be wicked fast. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

Boost General Interest mailing list
by Jon Kalb 06 Jan '05

06 Jan '05

Boosters, This messages announces the Boost General Interest mailing list, called Boost-Interest. This list is a moderated low-traffic announcement-only list of interest to the Boost community. On topic messages will include announcements of books, magazine articles, papers, talks, seminars, products, tools, events, or conferences on advanced uses of C++, generic/generative/meta-programming, and, of course, the Boost libraries. Off topic will be discussion of any kind and job postings. Yes, this is an opt-in list for announcements, but it is a moderated list and the moderators make you two promises. This list will be low volume and all messages will be on-topic (as defined by the charter above). Subscribe or unsubscribe at the Boost-Interest home page: http://lists.boost.org/mailman/listinfo.cgi/boost-interest Anyone may post to this list, but due to the high potential for abuse, each message is individually moderated. Please anticipate some delays in posting and understand that the list moderators have the final say on what is or is not on-topic. -- Jon Kalb Boost-Interest Moderator Kalb(a)LibertySoft.com

7 8

[type_traits] request for decayed<T>::type
by Thorsten Ottosen 06 Jan '05

06 Jan '05

Hi, The following trait is supposed to make it easier to forward arguments in generic code and in particular string literals. For example, I will use it when I update boost.assign to use const T& arguments instead of T arguments. It could also be used to make a better version of std::make_pair(): template< class F, class S > inline std::pair< typename decayed<F>::type, typename decayed<S>::type > make_pair( const F& f, const S& s ) { return std::pair< typename decayed<F>::type, typename decayed<S>::type >( f, s ); } Any thoughts from the type_traits authors? Do anybody mind if I add this to the cvs and make some docs for the type-traits library? br -Thorsten begin 666 decayed.cpp M(VEN8VQU9&4@/&)O;W-T+W)A;F=E+W9A;'5E7W1Y<&4N:'!P/@T*(VEN8VQU M9&4@/&)O;W-T+W1Y<&5?=')A:71S+VES7V%R<F%Y+FAP<#X-"B-I;F-L=61E M(#QB;V]S="]M<&PO979A;%]I9BYH<' ^#0HC:6YC;'5D92 \8F]O<W0O;7!L M+VED96YT:71Y+FAP<#X-"B-I;F-L=61E(#QU=&EL:71Y/@T*#0IN86UE<W!A M8V4@8F]O<W0-"GL-"B @("!N86UE<W!A8V4@9&5C87EE9%]D971A:6P-"B @ M("![#0H@(" @(" @('1E;7!L871E/"!C;&%S<R!4(#X-"B @(" @(" @<W1R M=6-T(')A;F=E7W!O:6YT97(-"B @(" @(" @>PT*(" @(" @(" @(" @='EP M961E9B!C;VYS="!T>7!E;F%M92!R86YG95]V86QU93Q4/CHZ='EP92H@='EP M93L-"B @(" @(" @?3L-"B @("!]#0H@(" @#0H@(" @=&5M<&QA=&4\(&-L M87-S(%0@/@T*(" @('-T<G5C="!D96-A>65D#0H@(" @>PT*(" @(" @("!T M>7!E9&5F('1Y<&5N86UE(&UP;#HZ979A;%]I9E]C/"!I<U]A<G)A>3Q4/CHZ M=F%L=64L#0H@(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @ M(" @(&1E8V%Y961?9&5T86EL.CIR86YG95]P;VEN=&5R/%0^+ T*(" @(" @ M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @("!M<&PZ.FED96YT M:71Y/%0^(#XZ.G1Y<&4@='EP93L-"B @("!].PT*#0H@(" @=&5M<&QA=&4\ M(&-L87-S($8L(&-L87-S(%,@/@T*(" @(&EN;&EN92!S=&0Z.G!A:7(\('1Y M<&5N86UE(&1E8V%Y960\1CXZ.G1Y<&4L( T*(" @(" @(" @(" @(" @(" @ M(" @('1Y<&5N86UE(&1E8V%Y960\4SXZ.G1Y<&4@/@T*(" @(&UA:V5?<&%I M<B@@8V]N<W0@1B8@9BP@8V]N<W0@4R8@<R I#0H@(" @>PT*(" @(" @("!R M971U<FX@<W1D.CIP86ER/"!T>7!E;F%M92!D96-A>65D/$8^.CIT>7!E+" - M"B @(" @(" @(" @(" @(" @(" @(" @(" @='EP96YA;64@9&5C87EE9#Q3 M/CHZ='EP92 ^*"!F+"!S("D[( T*(" @('T-"@T*?0T*#0HC:6YC;'5D92 \ M<W1R:6YG/@T*#0II;G0@;6%I;B@I#0I[#0H@(" @8F]O<W0Z.F1E8V%Y960\ M:6YT/CHZ='EP92!I;G1E9V5R(#T@,3L-"B @("!B;V]S=#HZ9&5C87EE9#QC M:&%R6S)=/CHZ='EP92!C:&%R7W!T<B ](")F;V\B.PT*(" @(&)O;W-T.CID M96-A>65D/&-O;G-T(&-H87);,ET^.CIT>7!E(&-C:&%R7W!T<B ](")F;V\B M.PT*(" @(&)O;W-T.CID96-A>65D/'=C:&%R7W1;,ET^.CIT>7!E('=C:&%R M7W!T<B ]($PB9F]O(CL-"B @("!B;V]S=#HZ9&5C87EE9#QC;VYS="!W8VAA M<E]T6S)=/CHZ='EP92!C=V-H87)?<'1R(#T@3")F;V\B.PT*#0H@(" @<W1D M.CIP86ER/'-T9#HZ<W1R:6YG+'-T9#HZ<W1R:6YG/B!P(" ](&)O;W-T.CIM M86ME7W!A:7(H(")F;V\B+" B8F%R(B I.PT*(" @('-T9#HZ<&%I<CQS=&0Z M.G-T<FEN9RP@:6YT/B @(" @(" @<#(@/2!B;V]S=#HZ;6%K95]P86ER*" B M9F]O(BP@,2 I.PT*#0H@(" @<W1D.CIP86ER/'-T9#HZ=W-T<FEN9RQS=&0Z M.G-T<FEN9SX@<#,@(#T@8F]O<W0Z.FUA:V5?<&%I<B@@3")F;V\B+" B8F%R M(B I.PT*(" @('-T9#HZ<&%I<CQS=&0Z.G=S=')I;F<L(&EN=#X@(" @(" @ M(' T(" ](&)O;W-T.CIM86ME7W!A:7(H($PB9F]O(BP@,2 I.PT*#0HO+R @ M("!I;G0@87)R87E;,3!=.PT*+R\@(" @<W1D.CIP86ER/&EN="HL:6YT*CX@ M<#4@/2!B;V]S=#HZ;6%K95]P86ER*"!A<G)A>2P@87)R87D@*3L-"@T*?0T* ` end

6 19

Boost Shmem BoostBook Help uploaded to Boost Files
by Ion Gaztañaga 06 Jan '05

06 Jan '05

Hello to all, I've just uploaded the Boost Shmem library help to Boost Files section (Boost.Shmem.2005-01-04.help.zip) so anyone can have a look and see what the library does without building the documentation. The documentation is in BoostBook format. Feel free to comment, regards, /Ion

1 0

Archive stuck?
by Gennadiy Rozental 06 Jan '05

06 Jan '05

1 0

Re: Singleton
by Dave Handley 06 Jan '05

06 Jan '05

> Does it make any sense to use a template allocator parameter, like the > standard container types, to control creation and destruction of my > instance, or are new and delete sufficient? Singleton creation is an interesting issue - Loki provides a number of different creation policies, including creating using new, malloc, or creating statically. Implementing them with a policy template. > Is there any other functionality that should be added? Specifically, > is it sufficient to enforce that singletons are created in a specific > order before main and destroyed in the reverse order after main (using > dependency instances), or should I provide some way to support > alternate lifetimes (ex: create on first reference to instance)? Ordering of Singletons is, in my opinion, one of the most important issues with Singletons. It is almost certainly insufficient in most applications to create in a specific order, and delete in reverse order. One reason for this is start-up performance - you don't want every Singleton to have to create at startup (necessarily). Another reason can be memory efficiency. Loki again provides a number of policies including a Phoenix Singleton and a Longevity managed singleton. I personally tend to use Longevity managed singletons linked to the at_exit function. Nevertheless, there are some additional things that I would like to see - for example, a phoenix singleton that could be created and destroyed more than once during a program run could be useful - either explicitly or even if not used for a while. Also, allowing thread-safety as an option is also crucial. > Is there any interest in adding this library to Boost? I would love to see a robust implementation of a Singleton in Boost. Whenever I start a software project, almost without exception I tend to add both Boost and Loki to the project - it would be great if I could add only Boost. I have to say however, that a more general library which implemented a variety of design patterns (like Loki) would be even better. For example: 1) Singleton 2) Visitor - like Loki implementing both a conventional cyclic visitor, and an acyclic visitor. 3) Composite 4) Abstract Factory 5) etc. etc. I've written my own templatised composite (available on codeproject.com) implementing a number of different iteration strategies (deep iteration, shallow iteration, typed iteration, etc.) and would be more than willing to throw that into the melting pot if there was some interest in putting together a library of design patterns for Boost. I've also written an acyclic visitor, like Loki but with a key change in the way that a failed visit is handled - in Loki if the visitor cannot visit a particular type of node, the default action is handled by a template in the base class of the visitable hierarchy. This in my view is flawed, and the default action should actually be handled by the visitor if required - this keeps the concept of action and data separated in accordance with the original visitor design pattern. This would probably need some work if it was to go into any attempt at a design patterns library. Dave Handley

3 2

g++ STL/MPL conflicts?
by Arkadiy Vertleyb 06 Jan '05

06 Jan '05

Hi all, I was porting my older stuff into Boost 1.32, and it went fine with VC71. However, using g++ 3.3, I ran into a lot of naming conflicts between STL and MPL algoritms, such as find_if, copy_if, etc. From looking into previous posts, I can see that tis relates to a combination of problems in the g++ STL, such as using unqualified calls, and ADL not working correctly. Does anybody know if the problem was fixed in later versions of GCC? Thanks, Arkadiy

8 24

Re: Singleton
by CHAOS 05 Jan '05

05 Jan '05

Dave Handley wrote: > Ordering of Singletons is, in my opinion, one of the most important issues with Singletons. It is almost certainly insufficient in most applications to create in a specific order, and delete in reverse order. One reason for this is start-up performance - you don't want every Singleton to have to create at startup (necessarily). Another reason can be memory efficiency. Loki again provides a number of policies including a Phoenix Singleton and a Longevity managed singleton. I personally tend to use Longevity managed singletons linked to the at_exit function. Nevertheless, there are some additional things that I would like to see - for example, a phoenix singleton that could be created and destroyed more than once during a program run could be useful - either explicitly or even if not used for a while. Also, allowing thread-safety as an option is also crucial. The way that my design works is to use reference counting in the form of dependency objects, which create the singleton when the first dependency is constructed and destroy the singleton when the last dependency is destroyed. If a singleton A owns a dependency on singleton B, that dependency lifetime will be greater than the lifetime of A itself, meaning that B will exist for the duration of A's lifetime. The only property of my singleton that forces it to be constructed before main and destructed after is the existence of a static dependency in the singleton class to itself. If I removed this static dependency, it would allow for singletons that could be created and destroyed any number of times, and lifetime would be completely controlled by the scope at which the dependencies lived. Implementing this change would make it possible for GetInst to fail, when it would be more desirable to have GetInst somehow utilize a dependency itself. Perhaps I could enable this by having GetInst return a type of smart pointer, which would own a singleton dependency as well as pointing to the singleton object. Thoughts / suggestions? I have no experience in dealing with thread safety. Would ensuring thread safety require that the singleton have access to a threading library, or would it be possible to just write the code more carefully to ensure safety, similar to writing exception safe code? In addition, I have no familiarity with the other design patterns you mentioned, nor with Loki. I learned about the singleton concept through a friend and thought that it made for an interesting challenge. I just ordered Modern C++ Design, so hopefully I can familiarize myself with these topics in the near future. For reference, I will leave a link to the code below: http://www.ezequal.com/chaos/libs/singleton.h

1 0

Yet another variant-style type, and boost inter-library dependencies
by christopher diggins 05 Jan '05

05 Jan '05

I have written a union-style type similar to boost::variant which allows single values, and multiple types. This type is called a union-list ( ul ) and is described at http://www.codeproject.com/useritems/union_list.asp I will be honest, there are several disadvantages of the union-list when compared to boost::variant 1. Declaration style is uglier : typdef ul<int, ul<char, ul<float, ul<string, ul_end> > > > my_union_list; 2. the data size is huge = summation of the size of the individual types plus sizeof(bool) * #types. 3. union-list has very few features The advantages (and my motivation for creating it) of the union-list is that it requires no other boost libraries and has a very tiny code base. Another difference ( but not neccessarily an advantage ) of the union-list is that it uses and provides an index to access the type of its contents. I don't know if this is sufficient to warrant eventual submission as a boost mini-library. Any comments? In general I am curious about how other boosters feel about boost library sizes and inter-library couplings. For me this is a big obstacle to using boost in many circumstances. It doesn't seem to be a concern at all for the boost community, but I wonder if other programmers have similar sentiments and find themselves often seeking out simpler alternatives. Christopher Diggins http://www.cdiggins.com http://www.heron-language.com

4 9

Plans to submit the Boost Software License for OSI approval?
by Christopher D. Russell 05 Jan '05

05 Jan '05

Are there plans to submit the Boost Software License to OSI to get it added to the "Approved" list (http://opensource.org/licenses/)? OSI certification would be useful: - allow SourceForge project admins to publish under "Boost Software License" as opposed to "Other / Proprietary" - less explaining to business people / lawyers - Regards Chris

2 2