- Boost-announce - lists.boost.org

[Review] Named Parameters library (ongoing)
by Doug Gregor 22 Nov '04

22 Nov '04

Today is the last day of the review of the Named Parameters library by David Abrahams and Daniel Wallin. Let's hear some more comments! The original announcement follows: The Named Parameters library provides a framework for writing functions that can accept arguments by name or by position. The use of named parameters can improve the readability of calls to these functions, especially when the functions have many parameters with default values. The Named Parameters library allows one to write a new_window function that allows a call such as: window* w = new_window("alert2", movable = true); The library is available in the Boost sandbox here: boost/named_params.hpp libs/utility And in the files area (login required): http://groups.yahoo.com/group/boost/files/named_params.zip Reviewers may wish to compare this solution to the named parameters already used by the Boost Graph Library, documented here: http://www.boost.org/libs/graph/doc/bgl_named_params.html Please send your reviews either to the Boost list or to me personally. The former is preferred, because it allows the community to consider your review as well. When writing your review, you may wish to consider the following questions (from http://www.boost.org/more/formal_review_process.htm#Comments) - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? As always, please remember to clearly state whether you believe the library should be accepted into Boost. Thank you Doug Gregor Review Manager, Named Parameters library

1 0

Boost 1.32.0 released
by Aleksey Gurtovoy 20 Nov '04

20 Nov '04

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + NOTE: This is a stripped-down copy of the Boost 1.32.0 release + + notes. See http://www.boost.org for the full version. + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Important - New Toolset Names ----------------------------- The names of some the Boost.Build toolsets have been changed to remove the "." (dot) character and to fix some other naming inconsistencies. For example, vc7.1 toolset was renamed to become vc-7_1. Please refer to the Supported Toolsets section of the installation guide for the complete list of the current toolset names. This change was made as a part of the effort to make the Boost distribution compatible with ISO 9660 level 2 requirements. New Libraries ------------- * Assignment Library: Filling containers with constant or generated data has never been easier, from Thorsten Ottosen. * Minmax Library: Standard library extensions for simultaneous min/max and min/max element computations, from Herv Brnnimann. * Multi-index Containers Library: Containers with multiple STL-compatible access interfaces, from Joaqun M Lpez Muoz. * Numeric Conversion Library: Optimized policy-based numeric conversions, from Fernando Cacciola. * Program Options Library: Access to configuration data given on command line, in config files and other sources, from Vladimir Prus. * Range Library: A new infrastructure for generic algorithms that builds on top of the new iterator concepts, from Thorsten Ottosen. * Serialization Library: Serialization/de-serialization of arbitrary C++ data structures to various formats including text, binary, and xml, from Robert Ramey. * String Algorithms Library: Collection of string related algorithms for case conversion, trimming, find/replace operations and more, from Pavol Droba. * Tribool: 3-state boolean type library, from Doug Gregor. Updated Libraries ----------------- * Compose: This deprecated library has been removed. * Graph: - Added bundled properties to the adjacency_list and adjacency_matrix class templates, greatly simplifying the introduction of internal vertex and edge properties. - The LEDA graph adaptors have been ported to LEDA 4.5. - Added algorithms for betweenness centrality and betweenness centrality clustering. - Added circle layout and undirected spring layout algorithms. * MPL Library: - Updated to use the Boost Software License. - New documentation, including a complete reference manual. - Major interface changes and improvements, many of which are not backward compatible. Please refer to the 1.32 changelog for the detailed information about upgrading to the new version. * Python Library: - Updated to use the Boost Software License. - A new, better method of wrapping classes with virtual functions has been implemented. - Support for the new Python Bool type, thanks to Daniel Holth. - Support for upcoming GCC symbol export control features have been folded in, thanks to Niall Douglas. - Improved support for std::auto_ptr-like types. - Components used by other libraries have been moved out of python/detail and into boost/detail to improve dependency relationships. - Miscellaneous bug fixes and compiler workarounds. * Signals Library: Introduced deterministic slot ordering, permitting slots to be connected at the beginning or end of slot groups or the slot list itself. Combiners may safely have state and are accessible from the signal. * Utility: class template result_of added. * Test Library: - namespace names gets shorten; old one still supported till next release. - added proper encoding of XML PCDATA. - support for wide string comparison implemented. For complete list of changes see Test Library release notes. Regression tests ----------------- This release has been extensively tested on a variety of different compilers and platforms. It is known to contain no regressions against the previous reference release on the compilers and configurations tested. Please refer to the corresponding regression reports at http://www.meta-comm.com/engineering/boost-regression/1_32_0 to see how well your compiler performs on the new Boost codebase. Acknowledgements ---------------- This release wouldn't have been possible without the dedicated effort of many, many members of the Boost community who generously contributed their outstanding expertise, time and energy to making it happen. For patches, bug fixes, troubleshooting, expert advice, and prompt responses to the release manager's requests we thank: David Abrahams, Misha Bergal, Jonathan Brandmeyer, Fernando Cacciola, Marshall Clow, Christopher Currie, Pavol Droba, Caleb Epstein, Eric Friedman, Jeff Garland, Michael Glassford, Doug Gregor, Joel de Guzman, Hubert Holin, Jaakko Jrvi, Hartmut Kaiser, Bronek Kozicki, Tarjei Knapstad, Toon Knapen, Aaron W. LaFramboise, Joaqun M Lpez Muoz, Christoph Ludwig, John Maddock, Paul Mensonides, Guillaume Melquiond, Thorsten Ottosen, Vladimir Prus, Robert Ramey, Rene Rivera, Gennadiy Rozental, Stefan Slapeta, Jonathan Turkanis, Pavel Vozenilek, Jonathan Wakely, Daryle Walker, Victor A. Wagner Jr. and Martin Wille. Also, our special thanks go to: John Maddock for the managing the effort of converting the majority of the Boost libraries to the Boost Software License, Eric Niebler and Joel de Guzman for taking on the important job of improving the Boost documentation's look and feel, and last, but not least, to our regression test runners, without whom we simply would never have released: Toon Knapen, Bronek Kozicki, Rene Rivera, Markus Schpflin, Stefan Slapeta, Victor A. Wagner Jr. and Martin Wille. Thank you everybody! -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

FORMAL review of "Output Formatters" - results
by John Torjo 21 Oct '04

21 Oct '04

Dear all, We got a lot of feedback relating the "Output Formatters" library [1]. "Yes" votes : 4 "No" votes: 2 "Abstain" votes: 2 Conclusions: - The docs and naming of the classes/functions could certainly be improved. - Seems a lot of people want this for pretty output, testing, debugging. - People don't need this library to provide ANY input facilities - quite a few people wanted a redesign. Thus, I wil consider this library "Pending Acceptation". In other words, it's considered Accepted by default, but since it will be redesigned, a new short review will take place. Reece will redesign the library, and a new formal review will take place within 3 months from now. This review will take less time - I assume 7 days. I will talk to Tom and Reece and schedule a next review date. Best, John [1] Just in case you still want a peek at the old code: http://www.torjo.com/code/outfmt.zip (153Kb) -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html

1 0

[review] Formal review of the Smart Container library starts today
by Pavol Droba 26 Sep '04

26 Sep '04

Hi all, The review of the Smart Container library, written by Thorsten Ottosen starts today (September 26th, 2004) and runs for 10 days (until October 5th, 2004). The latest version of the library can be found at http://boost-sandbox.sourceforge.net/smart_container.zip or http://groups.yahoo.com/group/boost/files/pointer%20container/smart_contain… The package contains all you need to sucessfuly use the library with the Boost version 1.31 or later, however library tests require the latest Boost.Test, that is available from the main Boost CVS. What does the library provide? The library documentation states: >>>>>>>>>>>>>>>> Whenever a programmer wants to have a container of pointers to heap-allocated objects, there is usually only one exception-safe way: to make a container of smart pointers like boost::shared_ptr. This approach is suboptimal if 1. the stored objects are not shared, but owned exclusively, or 2. the overhead implied by smart pointers is inappropriate This library therefore provides standard-like containers that are for storing heap-allocated or cloned objects (or in case of a map, the mapped object must be a heap-allocated or cloned object). For each of the standard containers there is a smart container equivalent that takes ownership of the objects in an exception safe manner. In this respect the library is intended to solve the so-called polymorphic class problem. The advantages of smart containers are 1. Exception-safe and fool proof pointer storage and manipulation. 2. Notational convenience compared to the use of containers of pointers. 3. Can be used for types that are neither Assignable nor Copy Constructible. 4. No memory-overhead as containers of smart pointers can have (see 11 and 12). 5. Usually faster than using containers of smart pointers (see 11 and 12). 6. The interface is slightly changed towards the domain of pointers instead of relying on the normal value-based interface. For example, now it is possible for pop_back() to return the removed element. The disadvantages are 1. Less flexible than containers of smart pointers <<<<<<<<<<<<<<< As an example of how the new containers look like, consider that <code> typedef boost::shared_ptr<Foo> foo_ptr; std::vector<foo_ptr> vec; vec.push_back( foo_ptr( new Foo ) ); (*vec.begin())->bar(); </code> now becomes <code> boost::ptr_vector<Foo> vec; vec.push_back( new Foo ); vec.begin()->bar(); </code> In your reviews, please include the answers for the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Also, in the documentation you will find questions from the submitter to the reviewer; whenever you feel you have something to contribute on these issues, please don't hessitate to include that in your review. Thank you, Pavol Droba, review manager for the Smart Containers library.

1 0

Formal review of "Output Formatters" library begins today
by John Torjo 12 Sep '04

12 Sep '04

Dear boosters, The FORMAL Review of "Output Formatter" library begins today, Sept 12, 2004. Author: Reece Dunn Description: The outfmt library provides means to write and read containers/ arrays/ ranges (pairs of iterators) to/from STL streams. It also provides means to customize formatting as your write to/read from a stream: std::list<int> l; // { 1, 4, 10 } std::cout << formatob(l); // output: [ 1, 4, 10 ] std::cout << formatob(l).format("<",">"); // output: <1, 4, 10> Download: You can get it from the boost sandbox: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/outf… http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/out… As a convenience (only for the period of the review), you can also get it from http://www.torjo.com/code/outfmt.zip (153Kb) Review process: Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. When doing the formal review, please answer the following questions: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And most important, 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. More on the formal review process: http://www.boost.org/more/formal_review_process.htm The Review Manager is: John Torjo john.lists(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/

1 0

[Formal review result] Tribool
by Thomas Witt 30 Jun '04

30 Jun '04

Hi, I am happy to report that the "Tribool" library by Doug Gregor has been ACCEPTED into boost. Other than this there is very little to be said. Reviews were generally in favour of the library and the issues surfaced during the review have been addressed by Doug. There were some comments regarding the scope of the library. While I agree that an broader coverage of 3-valued logic might be good to have, I do not think it justifies delaying acceptance of the library. Regards Thomas Review Manager Tribool -- Thomas Witt witt(a)acm.org

1 0

[Formal review result] Collection Traits Library
by Hartmut Kaiser 01 Jun '04

01 Jun '04

Hi all, after working through the pile of mails submitted for the review of the Collection Traits Library from Thorsten Ottosen, it is obvious, that it is ACCEPTED to Boost. All of the reviewes voted YES to include the library. Congratulations Thorsten! Most of the issues brought up during the review (mainly documentation nitpicks) were resolved already by Thorsten (or Thorsten agreed to fix them). Here are the open ones: 1) There were some discussions, whether the library should be renamed and/or incorporated with other ongoing efforts. There was no definitive consensus, how to achieve this. But the discussions showed that it seems to be good, if the collection traits library could be integrated with other libraries, existing and currently developed, to make it a part of a future Boost.Range library. I'm sure, that we'll see a lot of corresponding discussions in the future. 2) The strong requirement that end() should have constant complexity rules out the integration of C-strings into the library. Additionally special threatment of char[] arrays is needed, so they behave in the same way as their char* conterparts. The problem, that end(char[]) pointed to the byte after the '\0' was corrected already. Regards Hartmut Review Manager

1 0

Formal Review Tribool
by Thomas Witt 19 May '04

19 May '04

The review of Douglas Gregor's Tribool library begins now and runs through Saturday, May 29. Here is a short introduction to the library: The 3-state boolean library contains a single class, boost::logic::tribool, along with support functions and operator overloads that implement 3-state boolean logic. The tribool class acts like the built-in bool type, but for 3-state boolean logic. The three states are true, false, and indeterminate, where the first two states are equivalent to those of the C++ bool type and the last state represents an unknown boolean value (that may be true or false, we don't know). When reviewing the library, please remember to include: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. The library is available in the Boost files area as tribool-20031026.tgz Thank you, Thomas Witt -- Thomas Witt witt(a)acm.org

1 0

regex patches available
by John Maddock 03 May '04

03 May '04

All users of Boost.Regex-1.31.1 should be aware that there are now a set of patches available for this release - see https://sourceforge.net/project/showfiles.php?group_id=7586 for downloads. Issues fixed include: POSIX style regular expressions not behaving correctly with regex_grep. Non-greedy repeats not backtracking correctly in some cases. Backreferences cause some repeat operators to behave incorrectly. Some wide character expressions weren't getting correctly optimised, leading to thrown exceptions in trivial cases. Misc. compiler compatibility fixes. Regards, John Maddock

1 0

[boost] FC++ -- Formal Review Result
by Mat Marcus 05 Apr '04

05 Apr '04

The formal review for FC++ has completed. I am sorry to say that FC++ is not accepted into boost at this time. It may be possible for the library to be accepted in the future, but not without changes substantial enough to warrant an additional review. I will describe some possible strategies for later acceptance together with the rationale for my decision. Note that while the library is not accepted, the author has successfully established some of the merits of the functional programming paradigm and we should not require him to re-establish those same points in a future review. For that matter, I'm not convinced that we should have asked him to establish these points in the first place. * Rationale This was a very difficult decision, and I spent a long time sitting on the fence. I believe that the functional programming paradigm is important for C++ programmers, and that there are many interesting features available in FC++ such as lazy lists and the standard prelude functionality. In addition, though there was not a consensus amongst reviewers to accept (see Opinions of the Reviewers below), several boost library authors offered positive reviews of FC++. I finally managed to gather my thoughts and come to a decision -- thanks to all for your patience. In formulating my decision, I realized that one of the important questions to ask of a candidate boost library is: "Can I in good faith recommend to any C++ programmer with interest in domain X that they spend the time and effort to learn library Y and consider using it in relevant projects?" For FC++ I can not yet in good faith answer yes. I do think that it is worthwhile for *some* programmers to look at and would certainly consider pointing to FC++ in its present form from the boost web site as an "interesting third party library" if we maintained such links. But as I said I am not yet ready to put the boost "brand" on FC++. Why not? My evaluation was based on two main criteria, practicality and educational value, of which detailed accounts follow. ** Evaluation of Practicality Today FC++ is a largely monolithic library with a fair degree of overlap with other boost components. This led to a good deal of confusion/discussion during the review period. Such a state of affairs (monolith with substantial overlap) could conceivably be acceptable if there were clear problems for which FC++ was a uniquely suited practical solution. Exact Reals (see footnote *** below) notwithstanding, I don't believe that the *practical* value of FC++ as a *monolithic* embedded DSL in C++ supporting mixed paradigm programming has been satisfactorily established. [footnote ***: The existence of clients such as the Exact Real lib help demonstrate some degree of practicality. During the review I briefly examined the Exact Real site. This looked like an interesting application though I could not yet say how much practicality was demonstrated since, for example, the performance characteristics of lazy lists and constructive reals were not immediately clear to me. If FC++ is to be accepted on practical grounds potential users may want to be able to understand performance characteristics.] If the authors were to break FC++ into smaller pieces and should they participate in a future lambda, phoenix, FC++ merger then the above concerns would be addressed. It surely doesn't hurt that the authors of those other libraries expressed strong interest in the above direction. And as was pointed out in the review some of the ideas from FC++ might successfully be applied to other boost libraries such as function and/or bind. If FC++ was part of a single consistent set of FP components within boost then there would be good odds of achieving consensus to accept. The changes to bring this about would be of significant enough magnitude however that I would not be comfortable with provisional acceptance today -- a future review (or reviews of pieces are submitted independently) would be required. ** Evaluation of Educational Value Since boost is not necessarily restricted to purely practical libraries I also considered accepting FC++ into boost on the grounds that it provides an environment in which C++ programmers can learn more about and experiment with FP. FC++ enjoys some degree of success in this area. However I found it disturbing that during the review a number of traditional/imperative-style C++ programmers were just not "getting it" about FP. Perhaps a case could be made for accepting FC++ in its entirety on educational grounds after some of the improvements suggested by reviewers were implemented, e.g. improvements to the documentation and naming (useful in any case), the completion of some additional features such as Monads, or deeper documentation of the useful implementation techniques. But I must admit that I find this strategy less attractive, and I would urge you to try to break things up instead. One of the difficulties in finding acceptance on purely educational grounds might be characterized like this: if I was to recommend a way for an imperative programmer to learn more about functional programming today I would probably suggest a jump into an (OCa)ml, Haskell, or even a Lisp/Scheme environment. I am not sure that this I would recommend the FC++ environment for this purpose even with the changes suggested above. That is, I am not entirely convinced of the *purely educational value* of working with a functional programming DSL within C++. I really would prefer to see the FC++ ideas used in a practical mixed paradigm setting. * Opinions of the reviewers I was a bit concerned about the dearth of reviews during the first week so I decided to extend the review. The final number of reviews was still lower than I would have liked, but in the end I received approximately 4 no votes and 7 yes votes, with varying amounts of effort spent. Of the no votes, there was some support for acceptance after a later review, pending certain improvements. At the same time a number of the yes votes urged acceptance only after similar concerns were addressed. From this one could argue that there was near consensus that the community would be interested in accepting FC++ after these issues were addressed. The issues include the state of the documentation, the monolithic nature of the lib, and the incomplete nature of some components of the lib, e.g. monads. So I view some of the yes votes and no votes as differing mainly on whether to accept now with the above provisions or whether to require a second review after the above concerns were addressed. I spent some time vacillating between those options before finally settling on my decision to require a second review before acceptance. Given the significant nature of the requested changes I was only comfortable choosing the latter option. * Conclusion Though I am sorry not to be able to accept FC++ into boost today I would like to acknowledge its authors for the influence this library has had on other boost components. I strongly encourage you to keep working to bring the innovations from FC++ into boost in the future. I would also like to acknowledge Brian for his many creative contributions to the boost community and his thoughtful and professional posts. I am sure that I am not alone in saying thanks for all your efforts and I look forward to hearing more from you in the future. - Mat

1 0