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

[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,… [View More]

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 … [View More]

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 … [View More]

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, … [View More]

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.… [View More]

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> > … [View More]

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 … [View More]

9 22

[GSoC] Getting started
by Andrew Sutton 07 May '11

07 May '11

Hello GSoC students and mentors, Students, if you haven't contacted your mentor, now would be the time do so. Mentors, if you haven't heard from your students, you need to try to get in touch with them. If anybody is having trouble getting a hold of their student or mentor, please let me know. During the "Getting to Know You Phase", you should be doing two things: 1. Defining goals and expectations for the summer and 2. Starting to get up to speed with Boost's development environment … [View More]

3 2

[Review] Boost.Convert, review manager analysis
by Edward Diener 07 May '11

07 May '11

As previously stated Vladimir Batov decided to withdraw his library at the end of the review period from consideration for inclusion into Boost and I had announced this and the fact that because of this the library would not be accepted. Nonetheless I want to give my analysis of the reviews and the issues both pro and con of the reviewers. I also want to give some of my own thinking on these issues. There were few reviews of the library but much late discussion in the final day of the … [View More]review period and just afterward. There were 2 reviews which voted to accept Convert ( Artyom Bellis, Alfredo Correa ), 3 reviews which voted not to accept Convert ( Jeroen Habraken, Thomas Heller, Hartmut Kaiser ), 1 review which would have accepted Convert but qualified that only if lexical_cast could not be extended instead ( Rob Stewart ), 1 review which would have accepted Convert with large scale changes ( Gordon Woodhull ), and one mention, not a formal review, of acceptance until something else came along but with perhaps a later change of mind ( Paul Bristow ). There was also one review sent to me personally by Barend Gehrels, after Vladimir Batov withdrew his library, which voted not to accept Convert. There were also a number of people who raised doubts and objections to Convert in various ways without giving a formal review. It is all these issues raised by reviewers and commenters I want to discuss next. Vladimir Batov was responsive to nearly all of those issues but I want to enumerate them and give my own thoughts about them as I read reviews and comments. A number of people wanted lexical_cast to be extended instead of a new library. This certainly is a valid viewpoint. But I believe that the lexical_cast library is set as it is until someone takes it over from its original author and is willing to change it. I think it is better to review the library under discussion rather than to hope that something else can be changed in the future. There was an issue of the basic syntax which many people did not like. Instead of the syntax of 'convert<dest>::from(source)' there were a number of people who wanted to see 'convert<dest>(source)' instead, largely becaused it matched the 'lexical_cast<dest>(source)' syntax. Vladimir Batov explained why he used the syntax he did. I think in this case it is reasonable. Again this is an issue in relation to lexical_cast, and I saw no real significant difference between the syntaxes on a basis of practical use. The main issue brought out by many people is whether a single function can encompass successfully all of the functionality which Convert wished to encompass and whether this functionality both worked smoothly with everything others wished to do with the functionality. Here there were many valid objections and I will attempt to enumerate them: 1) The return value of the convert function is really many different returns, and this is done through implicit conversions of the actual return type. This was mentioned most eloquently by Thomas Heller. It is quite natural to assume that the return value of a successful call to 'convert<dest>::from(source)' would be a 'dest' object but instead it is a value which has an implicit conversion to 'dest'. This works when passing the value to ordinary functions but does not when passing the value to template functions. As Vladimir Batov mentioned one can use the 'value()' member function of the return value, and presumably also one can use a 'static_cast<dest>' also, to force the exact 'dest' object to be passed, but I also viewed this as a negative way to work, and a very valid objection to the way Convert was designed. To me it was not just a matter of confusion to the end-user but of a naturalness of use. A convert-type interface should have some function where, if the convert is successful, the actual result of the conversion is returned, and not some intermediate value with an implicit conversion. 2) The Convert library uses a stream-based method to do conversions but wanted to leave the door open for other methods. Part of the extended syntax of the library works with stream manipulators and locales. A very valid point was brought up, again by Thomas Heller, that it is not clear how the extended syntax is supposed to work with and affect non-stream based specializations of the basic convert template. Even the method of extending the library in this way, rather than just providing stream-based operators for a given type, is open to much doubt as valid C++ and largely left unexplained in the documentation. 3) The syntax for the stream-based and locale additions to the library's functionality was found odd by many people. The term 'wacky' was often used and Vladimir Batov did defend his choice about it well. Nonetheless it is a valid issue to consider whether the extended syntax is easy for a person to use. I found the syntax for using iostream manipulators quite natural, and the syntax for locales and other functionality such as throwing behavior less natural. Again I do not want to get too caught up in syntactical issues but I did understand the issues brought up by others regarding this. 4) The method of using the convert function in algorithms was criticized. Some people expressed their wish that a placeholder syntax, as used by other Boost libraries, be used. I actually found the way Convert does this as pretty elegant, there were two syntaxes which worked, but could understand others liking for the placeholder syntax. 5) The use of a default value, the issue of a default constructor, and the differing results when a conversion fails or not, received much discussion, especially at the official end of the review period and afterward, and I appreciate reading all of the discussions. I do not want to specifically go into each one, other than to say that I think this has basically to do with the issue of having a single function do everything which could not easily cover all the different scenarios mentioned for actual use. There were other valid concerns which are related to just a need for more complete documentation. Vladimir Batov responded to most of them. Here I will enumerate them: 1) Rob Stewart in his review mentioned many documentation corrections related to grammar, spelling etc. 2) What locale is being used by default is not explained. 3) The reference is very incomplete. 4) The section for extending the library is unclear and incomplete. Finally there were valid concerns relating to getting Convert to work properly. Some of these related Convert and lexical_cast and noted the differences. A few others mentioned things which just did not work properly in the actual conversion and again Vladimir Batov said he would look at these issues. Barend Gehrels sent me a late review, which he did not want to post to the mailing list because Vladimir Batov had already withdrawn is library, in which he said that he had some technical problems adapting a Boost.Geometry type to work with Convert. I think these are all technical issues which can be resolved. Many other people had specific incisive remarks during the review period but I can not list them all. That does not mean those remarks were ignored by me in any way, as I read and attempted to digest what everyone had to say. Final remarks: I would like to bring some clarity to the issues which may have forced Vladimir Batov to essentially withdraw his library at the end of the review period from consideration and which led to much comment and criticism about the library. This is my purely personal take on the library, but it is based on my technical understanding of the issues involved. The main issue with the library is that the 'single function fits all scenarios' works much less well in practical use than the author supposed, even as I understood the reason for simplicity which caused him to pursue this path. There really needs to be a function that simple returns the converted value upon success. Overloaded versions of that function, or differently named functions, can return other specific things. Where there is a great attraction to a return value which can be implicitly converted to other values, I think this attraction given practical use is somewhat illusory. While I did not enjoy some of the harsher remarks made by Thomas Heller in his review of the library about the design of Convert ( and I do not think he really meant them as harshly as they may have sounded ) he did rightly point out that the 'overloaded' return value is an impediment to a cleaner design which would allow one to use the right convert function given the possibilities which the library wants to accomplish. I know there has been many subsequent discussions about a set of functions that can replace the single function in Convert depending on how Convert can be used, and I do not myself want to get in the middle of this debate, but once there is an understanding of what needs to be done, I really think the library can be designed to appeal to end-users in a better way. The second issue in my mind is that the library attempts to do too much given the way it was designed. If the focus is simply a library which does stream-based conversion between strings and objects ( both ways ) I personally think it would be much better. Once you look for non-stream based conversions you have to consider more carefully how the stream-based syntax and locales should be integrated with the library. Once you look for type to type conversions rather than string to type and type to string conversions you have to design a good general facility for specifying how this is done within the functions you provide. This is a much bigger job of thinking about design, unless you are simply providing a very generalized shell with little real functionality built-in. I am not saying the author of the library has not thought about these issues, but my impression is that they have not been addressed carefully. Just in case anyone wanted to know, and also so that Vladimir Batov does not feel so bad about withdrawing the library from consideration at the end of the review period, I would have rejected the library for inclusion into Boost given the reviews and comments of others and my own perceptions of the issues involved. But I think the author has still done a fine job and is close to having a library which could be included as a part of Boost. Although it is hard work, it has been a pleasure to be a review manager of this library and I thank everyone involved and especially the author of the Convert library himself. Edward Diener [View Less]

2 1

[Block Pointer] Docs
by Phil Bouchard 06 May '11

06 May '11

Hi, Sorry for the repetitive emails and thanks to Gregory Crosswhite regarding it but I have improved the user-friendliness of the utility: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/overvi… Please let me know if there's anything unclear. Thanks, -Phil

2 6