- Boost - lists.boost.org

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

10 May '11

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

3 6

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

10 May '11

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

10 17

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

09 May '11

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

2 2

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

09 May '11

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

13 40

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

09 May '11

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

1 0

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

09 May '11

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

1 0

Re: [boost] howto: boost.lambda + stl on VS 2010 (SP1) ?
by Mathias Gaunard 09 May '11

09 May '11

On 05/05/2011 01:37, Raffi Enficiaud wrote: > Hi all, > > Sorry for bothering with this. I recently encountered some problems in using > boost.lambda with Visual 2010 Express, and need some clues for solving the > issue (there are many ways around of course). > I simply want to accumulate the values of a std::map, and I thought using > lambda to access the second member of the map iterator was appropriate. Here > is the piece of code: > > typedef std::map<T1, unsigned short> m_t; > m_t m ; // fill m > double acc(0); > std::for_each(m.begin(), m.end(), var(acc) +=& _1->*& > m_t::value_type::second); > > The last line does not compile on Visual (it does on GCC), I have to add a > typedef: > > typedef typename m_t::value_type aa; > std::for_each(m.begin(), m.end(), var(acc) +=& _1->*& aa::second); > > Which one is "more correct" ? It's one of the annoying MSVC bugs. MSVC doesn't like it when you chain nested names in template contexts.

1 0

[release] Adding more documentation to the release process
by Daniel James 08 May '11

08 May '11

Hi Beman, At the moment the release doesn't include the geometry documentation which is at libs/geometry/doc/html. I've being creating a new file, boost-release-docs.7z which includes both the main documentation and the geometry documentation (it's a new file because it's zipped from the root, rather than from the doc directory). The attached patch should change the script to use that, and fix copying the documentation - this will also allow us to easily add other documentation at a later date. It's copying to the boost root directory. If you'd rather keep things contained it could use repeated calls to xcopy for the relevant directories, although that would require changing the scripts every time some new documentation is added. Does it look okay to you? Daniel

2 1

[multi_index] feature proposal: member keys and typeless specification of keys
by JOAQUIN M. LOPEZ MUÑOZ 08 May '11

08 May '11

Hi all, This is a proposal for inclusion of two new features into Boost.MultiIndex, mem_key and BOOST_MULTI_INDEX_AUTO_KEY. Consider the following: struct foo { int x; int bar(); int baz()const; }; typedef multi_index_container< foo, indexed_by< ordered_unique<member<foo,int,&foo::x> >, ordered_unique<mem_fun<foo,int,&foo::bar> >, ordered_unique<const_mem_fun<foo,int,&foo::baz> > > > multi_t; Note that we have to use member, mem_fun or const_mem_fun depending on the kind of key used. mem_key allows for a uniform specification syntax: typedef multi_index_container< foo, indexed_by< ordered_unique<mem_key<int foo::*,&foo::x> >, ordered_unique<mem_key<int (foo::*)(),&foo::bar> >, ordered_unique<mem_key<int (foo::*)()const,&foo::baz> > > > multi_t; This in itself gains us relatively little; but if we have a C++11 compiler with decltype, BOOST_MULTI_INDEX_AUTO_KEY can use mem_key in a way that dispenses with the need for specifying the type of the key! typedef multi_index_container< foo, indexed_by< ordered_unique<BOOST_MULTI_INDEX_AUTO_KEY(&foo::x)>, ordered_unique<BOOST_MULTI_INDEX_AUTO_KEY(&foo::bar)>, ordered_unique<BOOST_MULTI_INDEX_AUTO_KEY(&foo::baz)> > > multi_t; Some requests and questions: 1. If you're interested in these features, please download the attached mem_key.hpp file, play with it and report on successful/problematic usage. 2. Do you think this is worth including in Boost.MultiIndex? 3. Proposals on the naming scheme? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx

3 6

[provocative] Whom did the SFC pay to list boost developers as a whole in "Current Member Projects"?
by Alexander Terekhov 08 May '11

08 May '11

http://sfconservancy.org/members/current/ (Current Member Projects) "Boost provides free peer-reviewed portable C++ source libraries. Boost emphasizes libraries that work well with the C++ Standard Library. Boost libraries are intended to be widely useful, and usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. Boost aims to establish existing practice and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report ( TR1) as a step toward becoming part of a future C++ Standard. More Boost libraries are proposed for the upcoming TR2." The context: (pacer) 03/23/2011 192 ENDORSED LETTER addressed to Judge Shira A. Scheindlin from David Leichtman dated 3/23/2011 re: Requesting that the Reply and Kuhn Declaration be stricken, or in the alternative, that the Court consider Best Buy's responses to these new theories and arguments. ENDORSEMENT: Defendant's request is granted. The Court will consider Best Buy's response to the new issues raised in Plaintiffs' Reply, as set forth in this letter. So Ordered. (Signed by Judge Shira A. Scheindlin on 3/23/2011) (jpo) (Entered: 03/23/2011) 04/14/2011 193 OPINION AND ORDER. For the reasons in this opinion and order, plaintiffs' motion to join WD is denied. The Clerk of the Court is directed to close this motion (Docket No. 133). (Signed by Judge Shira A. Scheindlin on 4/14/2011) (rjm) (Entered: 04/15/2011) 04/26/2011 194 ENDORSED LETTER addressed to Judge Shira A. Scheindlin from Emmett J. McMahon, dated 4/25/2011, re: Counsel for the defendant Best Buy Co., writes to request a pre-motion conference regarding a motion to strike Plaintiffs' claim for "actual damages and any additional profits of [Best Buy] incurred as the result of infringement." ENDORSEMENT: Request granted. A premotion conference will be held on May 6 at 2:30. So Ordered. (Pre-Motion Conference set for 5/6/2011 at 02:30 PM before Judge Shira A. Scheindlin) (Signed by Judge Shira A. Scheindlin on 4/25/2011) (lnl) (Entered: 04/26/2011) (details) http://www.terekhov.de/192.pdf http://www.terekhov.de/194.pdf Suggestion: Please remove boost from http://sfconservancy.org/members TIA. regards, alexander.

9 22