- Boost-announce - lists.preview.boost.org

Boost 1.34.0 Released
by Thomas Witt 13 May '07

13 May '07

Boost 1.34.0, the latest version of peer-reviewed, portable C++ libraries, has been released. This release brings five new libraries and extensive updates to existing libraries. http://www.boost.org New Libraries * Foreach Library: BOOST_FOREACH macro for easily iterating over the elements of a sequence, from Eric Niebler. * Statechart Library: Arbitrarily complex finite state machines can be implemented in easily readable and maintainable C++ code, from Andreas Huber. * TR1 Library: An implementation of the C++ Technical Report on Standard Library Extensions, from John Maddock. This library does not itself implement the TR1 components, rather it's a thin wrapper that will include your standard library's TR1 implementation (if it has one), otherwise it will include the Boost Library equivalents, and import them into namespace std::tr1. Highlights include: Reference Wrappers, Smart Pointers, result_of, Function Object Binders, Polymorphic function wrappers, Type Traits, Random Number Generators and Distributions, Tuples, Fixed Size Array, Hash Function Objects, Regular Expressions and Complex Number Additional Algorithms. * Typeof Library: Typeof operator emulation, from Arkadiy Vertleyb and Peder Holt. * Xpressive Library: Regular expressions that can be written as strings or as expression templates, and that can refer to each other and themselves recursively with the power of context-free grammars, from Eric Niebler. Updated Libraries * Assign Library: o Support for ptr_map<key,T> via the new function ptr_map_insert() o Support for initialization of Pointer Containers when the containers hold pointers to an abstract base class. * Date_time library: o Support for new US/Canada timezone rules and other bug fixes. See Change History for details. * Filesystem Library: Major upgrade in preparation for submission to the C++ Standards Committee for TR2. Changes include: o Internationalization, provided by class templates basic_path, basic_filesystem_error, basic_directory_iterator and basic_directory_entry. o Simplification of the path interface by eliminating special constructors to identify native formats. o Rationalization of predicate function design, including the addition of several new functions. o Clearer specification by reference to POSIX, the ISO/ IEEE Single Unix Standard, with provisions for Windows and other operating systems. o Preservation of existing user code whenever possible. o More efficient directory iteration. o Addition of a recursive directory iterator. * Function Library: Boost.Function now implements a small buffer optimization, which can drastically improve the performance when copying or constructing Boost.Function objects storing small function objects. For instance, bind(&X:foo, &x, _1, _2) requires no heap allocation when placed into a Boost.Function object. * Functional/Hash Library o Use declarations for standard classes, so that the library doesn't need to include all of their headers o Deprecated the <boost/functional/hash/*.hpp> headers. o Add support for the BOOST_HASH_NO_EXTENSIONS macro, which disables the extensions to TR1 o Minor improvements to the hash functions for floating point numbers. * Graph Library: o edmonds_maximum_cardinality_matching, from Aaron Windsor. o lengauer_tarjan_dominator_tree, from JongSoo Park. o compressed_sparse_row_graph, from Jeremiah Willcock and Douglas Gregor of Indiana University. o sorted_erdos_renyi_iterator, from Jeremiah Willcock of Indiana University. o biconnected_components now supports a visitor and named parameters, from Janusz Piwowarski. o adjacency_matrix now models the Bidirectional Graph concept. o dijkstra_shortest_paths now calls vis.initialize_vertex for each vertex during initialization. o Note: the name of the compiled library for the GraphViz reader has changed to boost_graph (from bgl-viz) to match Boost conventions. o See the complete revision history for more information. * MultiArray Library: Boost.MultiArray now by default provides range-checking for operator[]. Range checking can be disabled by defining the macro BOOST_DISABLE_ASSERTS before including multi_array.hpp. A bug in multi_array::resize() related to storage orders was fixed. * Multi-index Containers Library: o New random access indices. o Non key-based indices feature new rearrange facilities. o This version also includes a number of optimizations and usage improvements. For a complete list of changes, see the library release notes. * Optional Library: o boost::none_t and boost::none now added to Optional's documentation o Relational operators now directly support arguments of type 'T' and 'none_t' o operator->() now also works with reference types. o Helper functions make_optional(val), make_optional (cond,val) and get_optional_value_or(opt,alternative_value) added. o Constructor taking a boolean condition (as well as a value) added. o Member function get_value_or(alternative_value) added. o Incompatbility bug with mpl::apply<> fixed. o Converting assignment bug with uninitialized lvalues fixed. * Parameter Library: o Every ArgumentPack is now a valid MPL Forward Sequence. o Support for unnamed arguments (those whose keyword is deduced from their types) is added. o Support for named and unnamed template arguments is added. o New overload generation macros solve the forwarding problem directly. o See also the Python library changes, below. * Pointer Container Library: o Support for serialization via Boost.Serialization. o Exceptions can be disabled by defining the macro BOOST_PTR_CONTAINER_NO_EXCEPTIONS before including any header. This macro is defined by default if BOOST_NO_EXCEPTIONS is defined. o Additional std::auto_ptr<T> overloads added s.t. one can also pass std::auto_ptr<T> instead of only T* arguments to member functions. o transfer() now has weaker requirements s.t. one can transfer objects from ptr_container<Derived> to ptr_container<Base>, * Python Library: o Boost.Python now automatically appends C++ signatures to docstrings. The new docstring_options.hpp header is available to control the content of docstrings. o stl_input_iterator, for turning a Python iterable object into an STL input iterator, from Eric Niebler. o Support for void* conversions is added. o Integrated support for wrapping C++ functions built with the parameter library; keyword names are automatically known to docsstrings. o Enhancements to the API for better embedding support (boost::python::import(), boost::python::exec() and boost::python::exec_file()). * Signals Library: More improvements to signal invocation performance from Robert Zeh. * Smart Pointers Library: o Allocator support as proposed in N1851 (162 Kb PDF). o pointer_cast and pointer_to_other utilities to allow pointer-independent code, from Ion Gaztanaga. * String Algorithm Library: o lexicographical_compare o join o New comparison predicates is_less, is_not_greater. o Negative indexes support (like Perl) in various algorihtms (*_head/tail, *_nth). * Wave Library: o Wave now correctly recognizes pp-number tokens as mandated by the C++ Standard, which are converted to C++ tokens right before they are returned from the library. o Several new preprocessing hooks have been added. For a complete description please refer to the related documentation page: The Context Policy. o Shared library (dll) support has been added for the generated Wave libraries. o The overall error handling has been improved. It is now possible to recover and continue after an error or a warning was issued. o Support for optional comment and/or full whitespace preservation in the generated output stream has been added. o The Wave library now performs automatic include guard detection to avoid accessing header files more than once, if appropriate. o Full interactive mode has been added to the Wave tool. Now the Wave tool can be used just like Python or Perl for instance to interactively try out your BOOST_PP macros. Additionally it is now possible to load and save the current state of an interactive session (macro tables et.al.). o The overall performance has been improved by upto 40-60%, depending on the concrete files to process. o Support for new pragmas has been added allowing to control certain library features from inside the preprocessed sources (partial output redirection, control of generated whitespace and #line directives). o Optional support for #pragma message "..." has been added. o This version also includes a number of bug fixes and usage improvements. For a complete list of changes, see the libraries change log. Supported Compilers Boost is tested on a wide range of compilers and platforms. Since Boost libraries rely on modern C++ features not available in all compilers, not all Boost libraries will work with every compiler. The following compilers and platforms have been extensively tested with Boost, although many other compilers and platforms will work as well. For more information, see the regression test results. * Apple GCC 4.0.1 on Mac OS X. * Borland C++ 5.8.2 on Windows. * GNU C++ o 3.2.x., 3.3.x, 3.4.x, 4.0.x, 4.1.x on Linux o 4.1.x on Solaris o 3.4.x on Windows * HP aC++ A.06.14. * Intel C++ 9.1 on Windows, 9.0 on Linux. * Metrowerks CodeWarrior 9.4 on Windows. * Microsoft Visual C++ 6.0 (sp5, with and without STLport), 7.0, 7.1, 8.0. Note: Boost does not support the non-standard "Safe" C++ Library shipping with Visual C++ 8.0, which may result in many spurious warnings from Boost headers and other standards-conforming C++ code. To suppress these warnings, define the macro _SCL_SECURE_NO_DEPRECATE. * Sun Studio 11 on Solaris. Acknowledgements Thomas Witt managed this release. A great number of people contributed their time and expertise to make this release possible. Special thanks go to Vladimir Prus for making Boost.Build version 2 a reality, David Abrahams for authoring a new Getting Started guide, Rene Rivera for general build and installation support and Greg D. for answering countless questions. -- Thomas Witt witt(a)acm.org

1 0

2007 Boost Conference is Next Week!
by David Abrahams 08 May '07

08 May '07

The following message is a courtesy copy of an article that has been posted to gmane.comp.lib.boost.user,gmane.comp.lib.boost.devel,gmane.comp.lib.boost.interest as well. Hi Everyone, As you probably know, Boost holds its first annual conference next week (http://boostcon.com) Since we first announced the conference, there have been a couple of recent additions to the already stellar program (http://www.boostcon.com/program) most notably a ConceptGCC InstallFest, so every attendee can have a toolchain with some of the most important C++0x features already implemented (http://www.boostcon.com/program/sessions#gregor-conceptgcc-installfest) There are still a few places left; if you have been thinking of coming, now is the time to take action! Onsite registrations will be accepted Sunday May 13 from 4-6pm in the big entry lounge of Aspen Meadows. If you're planning to register onsite, you should still book a hotel room ASAP (http://www.boostcon.com/location/lodging#reservations) Please send any questions to boostcon-plan-AT-lists.boost-consulting.com See you in Aspen! -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com

1 0

[boost][math toolkit] Review results
by Matthias Schabel 02 May '07

02 May '07

I'd like to congratulate John Maddock, Paul Bristow, and their contributors on putting together an outstanding submission to Boost. It is rare to have complete unanimity among votes, but in this case there were no dissenters to accepting either the special functions or the statistical distributions portions of the library, so I'm glad to announce that it has been accepted for inclusion in Boost. Thanks to the many participants in the review : Gottlob Frege, Guillaume Melquiond, Johan Råde, Arnaldur Gylfason, John Phillips, Mark Van De Vyver, Stephan Tolksdorf, Hubert Holin, Seweryn Habdank-Wojewodski, Kevin Lynch, Leonaldo Peralta, Jeff Garland, and Stefan Seefeld (apologies for anyone I might have missed in this list). Here is a brief summary of the relatively few major issues that were raised during the course of the review : 1) Error handling is an issue that arises because this library is at the frontier between traditional numerical libraries and a (hopefully) new breed of such libraries that utilize modern programming techniques and facilities. Jeff Garland suggested that the default behavior should be to throw an exception, with errno being an option enabled by macro. It would also be nice to have more granular control over which instances throw exceptions and which do not (so, for example, a user could choose to ignore denormals). It was also suggested that additional, more transparent exceptions be provided for cases such as failure to converge rather than reusing tools::logic_error. 2) Jeff Garland also pointed out, rightly in my opinion, that attempts to use statistical functions that do not exist for a distribution should fail to compile rather than leading to a runtime error (e.g. mean of a Cauchy distribution). A reasonable method of implementing this should be devised or a strong argument for why it is not feasible/desirable provided. 3) Arnaldur Gylfason did some nice accuracy and performance testing vs. R. It was noted that the performance of quantile functions in this library was significantly worse than R, unlike non-quantile functions. He also pointed out that, for discrete distributions, the current behavior of returning fractional results for quantiles may not be the expected one. These issues should be addressed and documented. 4) Hubert Holin suggested the possibility of use of a policy parameter to choose between speed and accuracy. Another interesting possibility would be to allow the user to specify the desired precision either at compile or runtime. 5) It appears that this library will actually become two "sublibraries" within the Boost.Math library. Currently all code lives in the boost::math namespace; I would like to at least see a discussion of the possibility of having boost::math::special_functions, boost::math::statistics, and, perhaps, boost::math::statistics::distributions namespaces - as more functionality gets added to boost::math, collisions will become more likely, so some thought given now to logical partitioning may save pain later. During the review a number of typos and minor issues of documentation were raised, which the authors will need to address if they haven't already. In particular, John Phillips noted that the rationale behind using rational (vs. polynomial) approximations be clarified, the derivation of coefficients be documented, and the list of special functions in the documentation be expanded to encompass all functions actually implemented in the library. Stephan Tolksdorf requested a table listing standard statistical tests and the corresponding library implementations and enumerated a number of other documentation issues. Overall, the library was very well received, and the authors are to be commended on the tremendous amount of care and effort devoted to its preparation. Matthias Schabel Review Manager

1 0

[SPAM:## 74%] [boost] [Review] The review of the Boost.Guid library starts today (April 30th)
by Hartmut Kaiser 30 Apr '07

30 Apr '07

Hi all, The review of the proposed Boost Guid library written by Andy Tompkins starts today (April 30th, 2007) and ends May 10th, 2007. You can download the library here: http://www.boost-consulting.com/ vault/ (file guid_v7.zip). --------------------------------------------------- About the library: Guid is a library providing an implementation of Globally Unique Identifiers. Guid's are used in many facets of programming, including databases, networks, remote procedures, serializations, transactions, identifying documents, and identifying classes. This library is efficient and is able to create name-based and random-based guids. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - 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? Regards Hartmut Review Manager _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost

1 0

[boost] [math toolkit] Review Ends
by Matthias Schabel 28 Apr '07

28 Apr '07

The review period for the proposed Math Toolkit by John Maddock and Paul Bristow is now over. I will be assembling responses and put together a synopsis over then next few days. Thanks to everyone who participated and submitted reviews. Matthias

1 0

[boost][math toolkit] Formal Review today, April 11, through April 20
by Matthias Schabel 13 Apr '07

13 Apr '07

The formal review of the Math Toolkit, submitted by John Maddock, Paul Bristow, Hubert Holin, and Xiaogang Zhang, begins today, April 11 and ends April 20. The library and documentation may be downloaded from the Boost Vault: http://www.boost-consulting.org/vault/index.php? &direction=0&order=&directory=Math%20-%20Numerics The Math Toolkit is divided into three interrelated components : 1) a reasonably comprehensive set of statistical distributions 2) a set of high quality special functions 3) tools needed to implement special functions Because this library subsumes a wide range of material, I anticipate that not all reviewers will feel comfortable reviewing the entirety of the library. In order to expand the potential reviewer and increase overall participation, partial reviews of one or more of the three components described above are encouraged. As this is a primarily numerical library, quality of implementation, both correctness and efficiency, is critical. The authors have provided an extensive set of tests, but, as always, more eyes catch more bugs. Attention paid to these areas by reviewers is particularly welcome. Your comments may be brief or lengthy, as long as they provide sufficient basis for the Review Manager to assess your evaluation of the library. Relevant areas include interface/design, implementation, relevance to Boost, etc... If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: • 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. Review comments can be sent to the developer list, the user list, or directly to me if you don't wish to comment publicly. Thank you in advance for your time and work on this review. Matthias Schabel Review Manager _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost

2 2

[boost] [Review] Quantitative units review results
by John Phillips 11 Apr '07

11 Apr '07

I’m happy to report that the quantitative units library developed by Matthias Schabel and Steven Watanabe has been accepted for inclusion in boost. My thanks to the authors for their submission, and to the reviewers for all the work put into the reviews and discussions. A very busy review period saw contributions ranging from small commentaries to extensive reviews and discussions from Shaun Bloom, Martin Bonner, Paul Bristow, Malte Clasen, Phil Endecott, Michael Fawcett, Ben FrantzDale, Dave Hicherson, Lewis Hyatt, Janek Kozicki, Zach Laine, Eric Lemings, Kevin Lynch, John Maddock, Michael Marcin, Scott McMurray, Noah Roberts, Martin Schulz, Andrey Semashev, Dave Steffen, Matthias Troyer, K. R. Walker, David Walthall, Gunter Winkler and Deane Yang. Thanks to you again, since without your work the library would not become nearly as good as it can be. Given the scale of the review and the large number of issues discussed, this summary will be rather long. As has been my policy in the past, I will try to encapsulate the main ideas in the discussions for ease of later reference. In the case of this library, there are also some specific recommendations that should be addressed before the library is added to the CVS. Some of them were fixed by the authors during the review, and made available at that time, but for completeness the completed issues will also be included in the report. I’ll organize the report with some general discussion issues first, followed by suggestions for improvement for the library (required issues will be clearly marked and listed first), and since there was a vocal minority who argued against inclusion, the report will end by specifically addressing some of the points they raised in the review discussion. DISCUSSION Whether boost should include unit analysis as a compile time library or a runtime library is an almost religious issue. On each side are adherents who are strongly committed to their views and who see no way their needs can be met by the other type of library. However, the goal of boost is not to decide who is correct in situations of this sort. Boost was founded to generate good ideas and good implementations so use by a wide audience could determine which if any of these ideas are appropriate for addition to the language. Therefore, my suggested resolution to the compile time vs. runtime issue is for a runtime adherent to submit a runtime units library that is of sufficient quality for boost inclusion and let the broader base of programmers decide if there is a need for one or both libraries. Since the compile time library is already completed and accepted, it is reasonable to expect that any runtime submission should either be able to cleanly interoperate with the compile time version or a convincing rationale will be supplied for why this is not a reasonable goal. I look forward to this submission, though I will probably not volunteer to run the review since I claim no expertise in the issues that runtime proponents feel make a compile time solution inadequate. For the moment, I believe there is certainly enough of an audience that is looking for a compile time solution to justify the need for a library. I could only find two reviewers who said that a proper solution couldn’t be formulated with compile time facilities. The implication is that the rest of the people who expressed opinions about the library did not consider this an obstacle. In a list of library builders (as the boost developer list is) I would expect a bias toward compile time solutions compared to runtime solutions, but not enough of a bias to make me believe there is not an audience for a compile time solution. I also think that some of the problems perceived by those who opposed the library are more communications problems than problems with library functionality. To try to alleviate this issue, I am insisting that the documentation adds a rationale section. This section is suggested for all boost libraries, but is badly needed in a setting where there are many subtle mistakes of thinking or design that can be made. The authors showed during the discussions that they have good reasons for their choices, but some of those reasons are not obvious. A rationale section that is clear and complete on the topics of what the library is intended to do, why that is a good idea and how that can be done in C++ will go a long way to avoid further misunderstandings. The library uses the type system to make code more readable and more dependable. However, many commonly used third party libraries are not built in a way that is compatible with this use of the type system. Thus, some sort of proxy or façade system will be used in most cases to provide an interface with third party facilities. My personal preference is to put the special interface on the unsafe libraries, but either way, this would be a good choice for a simple example. It also gives a chance to explain that this is not a flaw in the design of the units library, but instead an issue with how to communicate between sections of a program that have incompatible type information. If, in the future the third party libraries are improved to allow direct communication, the façade can become a pass through or be removed. Imperial units (My apologies to Martin for the use of the term.) open a can of worms, but a nearly unavoidable one. They should either be included, or a prominent explanation of why they are not included should be provided. During the review questions arose of what to do with units such as meter * furlong / foot. The decision that the default behavior is to not convert and simplify is IMHO the correct one. In my academic area of expertise, the units km / (s * Mpc) (kilometers per second per megaparsec) are an example of a commonly used unit where automatic simplification is not acceptable. Megaparsecs measure distance, but should not be used to simplify with the kilometers. (These units are used to measure the expansion rate of the universe.) Paul made the case in his review, and I think he is correct, that the documentation should be very friendly to non-expert C++ programmers. Many potential users will not be experts in the template system or even the type system, but will be looking for a way to write more usable code for manipulating numbers in calculations. The documents should be written and organized to aid this. My suggestions are that you simplify the quick start’s discussion of how the library does its job, and focus on just presenting two problems (the work calculation and the circuit calculation) and how the units library makes solving those problems easier and more intuitive. Do it as two problems, each with a reason to exist, instead of as one mashed together program. Also, the listings for each example on the examples page should include a short (a few words to a couple of sentences) description of the problem the example illustrates and solves. Remember that someone who doesn’t already know the value of including units in code (and that means almost everyone) will look at the introduction, the quick start and the examples. If they aren’t convinced of the utility of the library by then, they’ll stop looking. This isn’t a binding suggestion, but right now static_rational is an implementation detail. As such, I think it should be kept internal to the library. If it is useful and important enough to move out to its own library, then pretty it up and submit it for the review process. This closely follows the pattern established by such useful tools as fusion. It took some thinking, but I believe the decision not to add operator++() is a good one. It might be good to include the reasoning and something like the example that ended that discussion (from Eric, I think) in the rationale section. REQUIRED IMPROVEMENTS Each of the improvements below should be addressed before adding the library to the CVS. Add a rationale section to the documentation. Since the design decisions required for a good units library aren’t always obvious, you need to include a section that explains the choices and your reasons for making the design decisions you made. Many things listed below have a place in this section. Fix the bugs in conversion/construction. You already addressed this, but make sure each way to construct a quantity that should work, does work. Include an explanation of why the ones that shouldn’t work don’t. Either include a real performance test, or no performance test. As the discussion during the reviewed, performance testing is not trivial, and when done without careful thought creates confusion. If you can develop a good performance test, include it in the examples or as a separate program in the documentation. However, example 14 isn’t a good performance test and confuses people about what is happening in the library. Check the suggestion about auto generation of ordinal values. If auto generation works across translation units, use it instead of assigning values. If auto generation does not work, consider the reserved range ordinals. This has to be addressed before submission because any later decision to change the range of reserved ordinals is a potentially breaking change for users (and probably a very hard one to debug). Remember that it is better to reserve 3 times too many ordinals than even 1 too few. Look at the problems of reworking the library for mpl re-use and simplifying the conversion implementation. If these projects are of a reasonable scale to be completed without slowing you down so much that you miss a release, do them now. Otherwise, implement them after including the library in the CVS. Remove the mutating member function x.value(). You have already agreed that this is a good choice and that needed mutating functionality should use a more ugly and obvious syntax, such as x.quantity_cast(). You have designed a way to simplify reverse conversions so someone who adds a new unit system doesn’t have to add redundant conversion definitions. Include this in the library and documentation. Include a rationale item that explains why the default behavior is explicit conversions. Correct the typos Paul noticed on the work “calculation” in the quick start. Provide a clear and complete listing of the systems and units included in the library. The use nautical::miles is not consistent with other names. Decide what naming scheme you want and stick with it. Include a rationale item that explains the reason for the notation quantity<SI::length> m_value=3.0 * SI::meter. I think you have a good reason, but it isn’t explained to the user. SUGGESTED IMPORVEMENTS The improvements below are not required, but they are suggestions for how to make a good submission better. Consider them, and do what you think will make the best library. Consider a check for compilers that are known to not be able to compile the library. Carefully consider the purpose for each example provided. What do you expect a reader to learn from each example? What examples are needed for users who want to write code for the common use cases for a library of this sort? Add an item to the rationale to quickly explain why rounding and error issues are not handled in the library. Consider changing the notation for negative exponents away from using parenthesis. Zach Laine had a collection of suggested edits to the text. Consider how to best fix them. One thing that will greatly aid broad adoption is ease of definition for new units and systems. There are tons of unit systems in the world, and someone is using each of them. As such, the easier you can make adding new units and systems, the better. This includes a possible tutorial showing the process (including discussions of the decisions that must be made and good ways to make them). It will greatly benefit the authors if anyone who tries this tells them about what went well and poorly. Provide clear and detailed examples of implicit and explicit conversions. Include a discussion of the good and bad points of each. Consider convenience headers for a variety of typical use cases. Consider whether you should change the current header arrangement to make them more or less fine grained. Consider including a simple currency example, with rates checked at run time from some simple source. Consider an example of using the library to interface with a GUI (similar to Janek’s). Consider including an example of how to accept a value in units not known at compile time and convert to a predetermined unit. You decided the if() check on line 57 of quantity.hpp is not needed. Check for other unneeded code and remove. Include the SI prefixes (milli, mega, …) in the SI catchall header. Since you can’t assume the memory layout of quantities in arrays is the same as doubles in all cases, consider an optional compile time check on sizeof() to make sure the size is the same. Consider adding the example from the discussion of a dual reference frame system. This is a good use of this library that won’t occur to many users without help. Consider opening the constants for use in systems that don’t provide native typeof(). This might be unimportant, if such systems can’t use the library for other compatibility reasons. Documentation is the gift that keeps on giving. Continue to look for ways to make the documentation more clear and complete. ISSUES RAISED WITH THE LIBRARY During the discussion, several issues were raised that have reasonable answers. I’ll try to collect my understanding of the issues and the answers here. It does not allow interaction with a GUI layer. Janek’s example posted to the discussion shows direct interaction including the ability to select units at runtime from the GUI. Similar can be done for other presentation layer issues except for possible rounding issues, which are inherently hard to solve satisfactorily. The focus should be on the business and presentation layers. While both layers are important, there is a substantial audience for this library that does little to no work with them. If this library proves insufficient for this work, a runtime submission is encouraged. Rational exponents are a needless complication and make integration with a runtime system impossible. While not everyone has a use for them, there is a noteworthy population that needs to have them, so they are provided. Similar functionality can be provided at runtime using boost::rational. Inadequate serialization tools are provided. I/O with units is a large and complicated problem all its own. Anyone who wishes to solve it is welcome to develop a library proposal, but the scope of this proposal is intentionally limited in this regard. Workarounds are needed for third party libraries, such as BLAS. This is true, but a common symptom of any unit system for C++. The only question is then where the workarounds happen. See above for more on this. Doesn’t support … (pick your favorite) So far, Janek has provided code examples for GUI use and Michael tells us he has used it with OpenGL and other systems. In fact, reasonable solutions have been provided for every problem presented, so far. There may be problems of this sort, but no direct evidence has been seen so far. No check for matching units on deserialized quantities. This is true to an extent, but not as important as it sounds. The serialization library provides support for version numbers on archives. The version number can be propagated between groups along with a definition of the required data format for that version. Yes, it is possible for someone to ignore this information, but it is also possible for them to call their units meters but use numbers that go along with feet. No unit system can eliminate such intentional circumventions, so it isn’t very important that this one doesn’t. Some real world uses of units have improper dimensions. For example measuring pressures in terms of inches of mercury. This will probably best be handled at I/O time, and converted to some more sensible internal unit for the rest of the program. In cases where this is not a viable answer, I don’t currently have one. Why distinguish between torque and energy, since the have the same dimensions? There are sensible physical problems where torque and energy both appear, such as rotational energy problems with work. As such, insulating against accidents is good. That’s the whole thing. Thanks to anyone who lasted this long, and thanks once again to the authors. John Phillips _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost

1 0

Intrusive library review results: library accepted
by "JOAQUIN LOPEZ MU?Z" 02 Apr '07

02 Apr '07

I'm pleased to announce that Ion Gaztañaga's Intrusive library has been accepted into Boost. Prior to its inclusion in Boost, the author is encouraged to address several issues raised during the review, a summary of which is given below. A total of 14 full reviews were received, all of them positive. Additionally, other members did not submit full reviews but expressed their support for the library. One Boost member raised some concerns about the usefulness of the library; I hope these concerns have been satisfactorily addressed by those review participants who explained their current and potential usage scenarios for Boost.Intrusive. This has shown that more movitational material need to be provided in the documentation introduction and in the form of full-fledged examples. Thank you to Ion Gaztañaga for all the hard work involved in creating a Boost library, to Olaf Krzikalla, who wrote the first versions of this piece of work, and to all the participants in the review. The list of issues to be addressed follows. Feel free to comment if you detect some error or omission from my part. List of issues to be addressed prior to inclusion of the Intrusive library into Boost: * Documentation - Provide a motivating introduction about usefulness of Boost.Intrusive. - Add some hello world motivating examples. - Class names linked to their section in the reference (except in code due to Quickbook limitations). - Document iterator and const_iterator as part of the container interfaces. - Add overview of iterator validity rules. - Document usage before concepts. - Improve concepts part. - Provide container concepts à la STL. - Add performance section. - Add quick guide to docs. - Make the tests more comprehensive. - Add examples section. - State clearly the purpose of the lib in the introduction. - Add more examples using the different hooks. - State in docs the possibility that tags be incomplete types. - State in docs the fact that Boost.Intrusive does not support shared_ptr's. - Document the fact that member hooks rely on non-standard implementation techniques. * Naming - Change Destroyer to a more suitable name (e.g. Sink or Disposer), rename member functions accordingly. - Rename current() as iterator_to(). - Rename [s]list_algorithms as circular_[s]list_algorithms. - Drop the 'i' prefix from the names of containers. - Rename linked() as is_linked(). - Rename assign_and_destroy() as destroy_and_assign(). * Interface improvements - Study ways to simplify the usage syntax of hooks. - Add a default value to Tag. - Member hooks shouldn't be parameterized on the host class type. - Make hooks assignment operator a no-op. - bucket_size() y bucket() should be const. - Provide cbegin(), cend() etc. - Add *_fwd.hpp headers. - Fuse autolink and regular/safe hooks into one class whose second parameter is a category class. * Implementation improvements - Iterators to be implemented with iterator_facade. - Use Boost.Concept for concept checking if compilation times are not severely affected. - Extend bucket primes table to 64 bits. - Use template trick to avoid direct use std::size_t in template parms of containers, thus pulling the std namespace in via ADL. - Use Watanabe's version of swap_nodes() for ilist. - Use insert_after() in clone_from(). - Reimplement clone_from() to not delete partially constructed data on exception. - Investigate bug with member hooks and virtual inheritance. * Extensions and issues to be considered in the future - Order-statistics tree. - Study other libraries for ideas: DOL, PTL, jjLib. - Study feasibility of implementing a "destroy multihooked element when completely unlinked" mode. - Investigate use of two-way pointers with Boost.Intrusive. - Consider a shift() member function for lists and slists. - Additional slist-like container with a pointer-to-last member to make swapping constant time. The Review Manager, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[boost] [Review] Quantitative Units library review begins today, March 26
by John Phillips 26 Mar '07

26 Mar '07

The review for the Quantitative Units library, submitted by Matthias Schabel and Steven Watanabe begins today, March 26 and ends April 4. From the documentation: The Boost.Units library is a C++ implementation of zero runtime overhead compile-time dimensional analysis in a general and extensible manner, treating it as a generic metaprogramming problem. Support for units and quantities (defined as a unit and associated value) for arbitrary unit system models and arbitrary value types is provided, as is a general facility for unit conversions enabling fine-grained control over conversion. Complete SI and CGS unit system models are provided, along with systems for angles measured in degrees, gradians, and radians. A small subset of the SI system including only length, mass, and time is developed in the examples as a demonstration of the relative ease of adding new unit systems and the extensibility of the library architecture. In this review, the authors and I expect that there will be active discussions on two topics. In every review there is a discussion of the quality of the library implementation and documentation, and it is obviously expected and desired here. Also, since this library is specifically designed as a compile time library with no attempt to provide unit conversions or other runtime facilities it is expected that the review will include an active thread on whether this is the correct design decision. In specific, this is a different approach than that taken by Andy Little's submission of last year. Because some people will be more interested in one or another of these two discussions, I request that everyone clearly marks comment topics to show which they are discussing. This will also improve Matthias' and Steven's ability to respond usefully and my ability to produce review results and recommendations that accurately reflect the desires of the boost community. In general, please include the following in your review. 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. Here are some questions you might want to answer in your review: • 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. Review comments can be sent to the developer list, the user list, or directly to me if you don't wish to comment publicly. Thank you in advance for your time and work in this review. John Phillips Review Manager _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost

1 0

Review Schedule
by Tom Brinkman 17 Mar '07

17 Mar '07

Review Schedule http://www.boost.org/more/formal_review_schedule.html . If you have any changes, post them as a reply to this thread. We need experienced review managers for many of the libraries in the review queue. A few of them have been waiting for a volunteer for a few months now, such as boost::exception, boost::GloballyUniqueIdentifier and boost::scope_exit. If your interested, let us know. Preferably, you will have a background in the problem domain, but no association with the library and are a regular contributer on the boost mailing list. You can read the "review manager" requirements at the following link: http://www.boost.org/more/formal_review_process.htm Most of the libraries are located at the Boost Sandbox Vault, located here: http://boost-consulting.com/vault/ Here is a summary of the libraries that are in the queue waiting for a "review manager" volunteer. ------------------------------------- Library: Exception Author: Emil Dotchevski Location: http://www.revergestudios.com/boost-exception/boost-exception.zip Review Manager: Needed Date: Needed Summary: The purpose of Boost Exception is to free designers of exception classes from having to consider what data needs to be stored in exception objects in order for the catch site to be able to make sense of what went wrong. When Boost Exception is used, arbitrary values can be stored in any exception. This can be done directly in the throw-expression, or at a later time as the exception object propagates up the call stack. The ability to add data to any exception object after it has been thrown is important, because often some of the information needed to handle an exception is unavailable at the time of the throw. ----------------------------------------- Library: Globally Unique Identifier Author: Andy Tompkins Location: Boost Sandbox Vault Review Manager: Needed Date: Needed Summary: A guid, or globally unique identifier, is an identifier standard used in many disciplines including computer networks, distributed computing, and databases. They can be used to tag objects with very short lifetimes, to reliably identify very persistent objects across a network. An attractive feature of guids is their relative small size, of 128-bits, compared to alternatives. Also the creation of guids does not require a centralized authority. ----------------------------------------- Library: Scope Exit Author: Alexander Nasonov Location: Boost Sandbox Vault Review Manager: Needed Date: Needed Summary: The scope-exit-arg-pp-seq is Boot.Preprocessor sequence of identifiers that can be used inside scope-exit-body. The direct-declarator is declarator-id followed by optional argument of type boost::scope_exit_group (inside brackets or after the equal sign). This construct executes scope-exit-body at the close of the current scope. ----------------------------------- Library: Floating Point Utilities Author: Johan Råde Location: Boost Sandbox Vault Review Manager: Needed Date: Needed Summary: Proposed Additions to the Boost Math Library <boost/math/fpclassify.hpp> Functions for floating point number classification: fpclassify, isfinite, isinf, isnan, isnormal. Follows TR1. <boost/math/signbit.hpp> Functions for floating point number sign bit access and modification: signbit, copysign, changesign. Follows TR1. <boost/math/nonfinite_num_facets.hpp> Facets that parse and format infinity and NaN according to the C99 standard. Used for portable handling of infinity and NaN in text streams. ----------------------------------- Library: Switch Author: Steven Watanabe Location: Boost Sandbox Vault Review Manager: Needed Date: Needed Summary: Needed

1 0