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

TEST
by john＠johnmaddock.co.uk 26 Apr '05

26 Apr '05

q�ō��o��1��H�8��ڒ�g��EJ]�F��Jrw�.��k��Q�R�[M�ڠ&n�uz͡��Kd��5��Y�ݴ:�K� ��]'��鋭s&�� Y}��6�a{�Z.5?�c��0��̼f^ebqA��C��C�̟ъ�ϼ�.�Ve�t3��K��0�-��P>�W,mb��oNyH� S,��0e��m>�g�Ӫ�"}j�� J��K"��M$�n�T#N�e�o<�u��##%�V%c0O]�d��Si��pD�J"�Z �.4��J�K?�xq�v�ߺ5��o��~��XRGC��G��0�Z��TY�tX��WD��$Z��֮��Cl��GJ�KT�S�S�|o� �xi��,KxM-�؍��ˉU�A܌v<�i��'�bu�s�5Xx�^m�,5D�5��u؜`h�ȍ&��-�xS;��h��{��H�yW5.-aa�3�d ��O��wL�Ј�hVc��س��էA��sZ��C�g��S�:�Y�"ok�Vy ��oV7[k�K��1��i�P��1��[B��Z"�D-�"֩a�Gb#��3y�A��h��5��Y.N��]��j��g��{�{��34&v3ֽ��,C�F�G��o��o�\f lS��"��f��P/�x0J G :��S�.��zβ�:8J&*I��q}��p��b�1O��oщ[<No�>��'��Z^�S�� ҿ��N7��"��V*� �:1J��G�/��n��9�[��^�x�� ]m��)��4�� "��Z�Ћ˻*�E]��}` 85��5�̨��F-)�%�2K5��w񑏨>�kM{C|��"�S ��H�!�Mk֧�{�b;Rv�m�-/�B��X7�y*�S��<��W�U��~��׶�M��}~�?�$�Ja��3_`UaTC�,� K��pn�x�n��L��nn*ۉ/?��^Fk��O��ٹ ݦ�\2Aζ�R��u )��g�?�p�~Ɋ�"�ރ8^`V�>�W�Y��D��k��E�)�Ի0�̿�Ns3� ��Ԃ�V�b3xê8��6 ��9��F�)��J�LD9��wQ�H4�۪�4�[�Em��0"[B&}�v&M�4w�1�y��U�S��EC_]�O� v�Z�*��^��ţ`�T� ��䑹� �Ё�E�ju,J�W��q��2"LYk�h��椙�\;b��X�)�ұ��x� /��x�}��XZ�~k��s_�J��&ֽM�A11�v��W7��$�-��/<�v��V��O�<)T,ޱ�_�-��{SO�sd�^� �7�M��fZ�'t�Q��H�Z��e�U M�dkS��'%t-��P��E��l*��z��s�wS�枳�Ս�ﶭ>�;�BD 0M�ӭ�mvRK.q�z�*pb�P��79V�#��6��CaYCR�e)��6Ք��V�iV�� T � �x�1��ε��Xy�H 3��[V5�q��z�R`9�sp�"R܎nF��V�5M��黍Q'}�p��I�\./]O�":��e7��(��ծ5)5ڸ� �`v:��Y)ȉ��!KyDտV��P�|��a�ךrܡG��ǩ:G��D4�[I��'��{KM�s0\�0x̹�Y��z�ĆP��c|cC}��T|��S%��?�:Yv��/K�؊��PU��Z��,â��T�{g$�mYf�0B�|V� G�Nlb��Q��5P��j�*��D��D��h�Z��ʗ� Bl�w��7��(�aw�\��]QTPڦ�g"��L��X<��-��xm�Yxvۢ`To̡iy�z�x.tZb_�R��`��¡�ҶlT��^�;��J!Z��$�/��m,}�x(�pH㮪6�O8<�x�19��Ό J�XB^�do�g�c��G{�c�R_�%f��3d�9��n8�*p(f%�� NSj��?�G�w�x��D�$�em?;��͸oK5N��jz��'ũ�pHYF��S�_��T

1 0

[review results] hash functions accepted
by Thorsten Ottosen 21 Mar '05

21 Mar '05

Dear all, I'm pleased to announce that Daniel James' hash-functions library is accepted into boost. The review comments were generally positive, a few bugs were fixed and in general we had a solid discussion in favor of the current design. Congratulations to James! I would like to thank all who partcipated: Dave Harris Peter Dimov John Maddock Joaquin M. Chris Jefferson Caleb Epstein Topher Cooper David Abrahams Alberto Barbati Tobias Swinger Jaap Suter Rob Stewart Bronek Kozicki Below is a list of issue that was resolved; let us have a discussion about any of them if I have misunderstood something. Also, feel free to mention something if it was forgotten by me. Issues and solutions: --------------------- 1. for those who don't want to include the whole std-lib, individual headers can be put in hash/std/XX.hpp (but see 3) 2. update docs to reflect that ADL is used. 3. consider if the primary template should not take 1 range parameter and call hash_range; unordered containers can then be explicitly overloaded when they become available. this would also have the great effect that subranges like sub_range<string> "just works" by default 4. avoid too many zero hash values by defaulting to something other than 0 5. change implementation of hash values for pointers so undefined behavior is gone (and consider adding x + (x >> 3) ) 6. the design aim was predictibility and to minimize collision; for the latter part, I would like to know if similar values hash to similar buckets or not. If very different objects end up in the same buskets, wouldn't equality be much faster rejected? Should this be a concern? 7. the hash_ptr<> suggestion is better done with general indirected function 8. hash_range should be overloaded to take an initial seed best regards Thorsten, review manager -- Thorsten Ottosen ---------------------------- www.dezide.com www.cs.aau.dk/index2.php?content=Research/bss www.boost.org www.open-std.org/JTC1/SC22/WG21/

1 0

[FSM library] review result: accepted with few conditions
by Pavel Vozenilek 15 Mar '05

15 Mar '05

FSM library written by Andreas Huber has been accepted into Boost, with few conditions and few recomendations. Thanks, Andreas, for your work and stamina to get thus far! Also thanks to all courageous reviewers. Short overview: =============== Opinions of reviewers were mixed. Large group liked the library, some even used it in production code. Other large group had objections Most questioned were performance and API. At the end my opinion is: no single perfect fit exists so it makes little sense to dismiss this library waiting for a hypothetical everyone-is-happy solution. Other variant was to ask for changes and for second review later. FSM is mature, has been developed for years and will be maintained in the future: its not likely such solution would make much of good for end result. Conditions: 1. Name of the library should be changed: - not to suggest that only one FSM implementation may exists in Boost - not to give wrong impression to people who look for tool with maximal runtime efficiency. - to stress the "high-level" nature of the library Names suggested during review were Statechart (by Alexander Nasonov) and umlfsm. 2. Information about performance overhead should be separated into page of its own and made clearly visible. Recomendations: 3. API of the library should be simplified as much as possible. Quirks and dangerous situations should be eliminated as much as possible. 4. The documentation should be improved as much as possible. 5. Runtime overhead should be decreased as much as feasible but without sacrifying currently available features of the library. Detailed information: ===================== 1. Name of the library should include change of namespace as well. 2. The information about runtime overhead. Separate page should be created and made visible on front page. It should contain examples of applications where FSM may not be the best solution (e.g. parsers). 3. API of the library, quirks and features. People asked many ways to simplify the API and increase orthogonality of its features: - the danger in using transit<> should be eliminated (Jonathan Turkanis suggested way how to do it) - the syntax to add deferred event should be cleaned up, even it it adds overhead - similarly posting events from inside FSM: if there's chance to make its syntax easier it should be done (no matter what IMHO) - reducing # of template parameters for state, possibly putting reactions as typedef inside state - it was suggested (by Daryl Green) to deduce reaction-list by examination of class interface - polymorphic events may be added for completeness (Peter Petrov found workaround but it may be better to do it right) - add handling of unknown events - custom allocator for FSM used for all states constructed in it. Perhaps it is possible to detect presence of overloaded operator new in state and it if doesn't exist then use state_machine allocator - not using containers keeping historical data when history feature is not used - possibility to use flyweight classes for states or class factories to create states - eliminate need for mpl::list for history parameter - description of transition guards in header was requested (perhaps it may be optional feature) Whether the library should separate its asynchronous part out was not discussed much. I guess it is better to keep it in and possibly submit it as standalone library. 4. Documentation. Among suggested improvements were: - better indentation in code snippets, inlined comments, syntax highlighting - adding complete examples to code snippets so users can try immediatelly - more information for error handling and asynchronous FSMs - reduce the radius of big black dots for initial states - external documents describing UML mapping should be more visible - avoiding forward declarations of events in code snippets - more examples (e.g. half-adder used twice to create a full-adder, suggested by Dave Gomboc, combination of synchronous and asynchronous machines) The documentation is now very dense, splitting it into smaller parts may help. More hyperlinking would also help a lot. The documentation may contain page "How to" with tricks, workarounds and non-obvious examples of use. For example how to use nested state to keep data related to inner states. I think adding UML and/or FSM tutorial in documentation is not task if this library. 5. Runtime overhead. Best effort should be made but only after stabilizing features and API. Reducing executable code size (per state/transition) may be the first direction here. ------------------------------- I hope that alternative FSM implementations (like the one currently developed by Alexander Nasonov) or dynamic FSM will appear and will be submitted to Boost as well. /Pavel

1 0

[review] hash functions
by Thorsten Ottosen 08 Mar '05

08 Mar '05

Dear All, It's a pleasure to announce that the review of Daniel James' hash functions library starts today (8th of March) and ends the 12th of March. The library is fairly small and can be seen as an extension to boost.functional. Therefore the review is a fast-track review. >From the introduction of the library: "boost::hash is an implementation of the hash function object specified by the C++ Standard Library Technical Report. It is being proposed as an addition to Boost.Functional" "The hash functions have several possible uses, but the main intention of boost::hash is for indexing a hash table such as the unordered associate containers in the Technical Report, or the hash index for the Boost Multi-Index Containers Library. A hash table stores its values in buckets which are numbered by their keys' hash values. Given a key, the bucket the object lies in can be quickly found be calculating its hash value and looking in the corresponding bucket. This requires the hash function to be fast - since the point is to find the object quickly. Collisions need to be minimised, to reduce the number o objects in each bucket, and thus the number of comparisons required to find objects in a bucket." . If you decide to do a review, please follow the guidelines described in http://www.boost.org/more/formal_review_process.htm#Comments The library can be downloaded from http://boost-sandbox.sourceforge.net/vault/index.php?directory=Hash best regards Thorsten, review manager -- Thorsten Ottosen ---------------------------- www.dezide.com www.cs.aau.dk/index2.php?content=Research/bss www.boost.org www.open-std.org/JTC1/SC22/WG21/

1 0

ANN: review of FSM library starts
by Pavel Vozenilek 21 Feb '05

21 Feb '05

Review of Finite State Machine library written by Andreas Huber starts today, February 21 and lasts 10 days. The library can be found at: http://boost-sandbox.sf.net/fsm.zip (781 kB). FSM is feature rich library to design finite state machines without need for external generator. It is accompanied by extensive documentation. Here are some questions you might want to answer in your review: * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? * The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? * What is your evaluation of the implementation? Are there parts of code too obscure or duplicating exiting Boost functionality? Can something be factored out to standalone library or among general utilities? * Are there performance bottlenecks? Does the library design fit requirements of real-time systems? How is it useable for embedded systems? Is the documentation clear on performance tradeoffs? * What is your evaluation of the potential usefulness of the library? Can you compare this FSM to other implementations? * Did you try to use the library? With what compiler? Did you have any problems? Do you have tips for better support of older compilers? What are possible portability 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 reviewer 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. Pavel Vozenilek FSM review manager

1 0

Boost Logo Contest
by Joel 06 Jan '05

06 Jan '05

Hello, Boost (www.boost.org) is an open, collaborative effort that includes thousands of programmers from the C++ community at large. Boost is hoping to retire the existing logo (http://www.boost.org/boost.png) and adopt a new one. We are now launching a competition for the creation of a new logo. The competition is open to all designers, both professional and non- professional. The final design must be submitted as a scalable vector format, preferably SVG or EPS. A free, open source, scalable vector graphics editor can be found here: http://inkscape.org/. Alternative bitmap versions (small, medium and large icons, web graphics, etc.) of the logo may also be submitted to augment the main vector format. A JPEG or PNG version, to be placed in a web page, must also be submitted for judging. The Boost community will vote on submitted entries. Voting shall be based on Instant Runoff Voting (http://www.fairvote.org/irv/whatis2.htm) meaning that each individual voter shall choose 5 favorites, in order of preference. In addition to proper acknowledgement, the winning designer will receive: + the Boost Logo Designer T-shirt (printed with the winning logo design), plus, + a signed copy of the MPL book by David Abrahams and Aleksey Gurtovoy, C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond (http://www.awprofessional.com/titles/0321227255) Entries will be accepted on or before February 15, 2005. I will act as the logo contest manager. Please email all entries to me (djowel at gmail dot com). I shall post all submitted entries to Boost's web site. The competition will close on March 1, 2005 and the winning entry will be announced soon thereafter. + The logo must be immediately identifiable with the spirit of Boost. + The logo's concept must be simple and clear and should have relevance to the organization. + The logo should not be too detailed and should work in low resolution. + Any logo submission that is blatantly racist, sexist, obscene, or otherwise discriminatory will be rejected. + The logo must be the original work of the submitter. + The logo must be free of any copyright or other intellectual property claims. + The winning logo shall be distributed under the Boost Software License, Version 1.0. (www.boost.org/LICENSE_1_0.txt) Regards, Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[review-results] Smart Container Library
by Pavol Droba 07 Dec '04

07 Dec '04

Hi, I hereby announce that the Smart Container library is ACCEPTED into Boost. Congratulations and thanks to Thorsten Ottosen for providing us with this library. Most of the reviewers were in favor of acceptance, but there were several requests for improvements. I have consulted them with Thorsten and he proposed to do following changes. I consider them sufficient for acceptance. 1. add support for boost.range in insert functions, constructors etc 2. use void* implementation 3. improve docs as discussed during the review 4. add support for null values: - remove preconditions - add functions is_null( size_t idx ); is_null( iterator ); 5. add more debug checks after access to ptr_begin(), ptr_end() 6. reconfigure policies: ptr_vector<T,clone_manager> becomes ptr_vector<T,clone_allocator = something, std::allocator<T*> = std::allocator<T*> > or perhaps ptr_vector<T,clone_allocator = something< std::allocator<T* > > 7. improve tests I also suggest, that before the inclusion of the library into the boost distribution, the library should be brought in the discussion to verify, that all issues above have been addressed. Best Regards, Pavol Droba Review Manager

1 0

[Review Results] Named Parameters Library
by Doug Gregor 05 Dec '04

05 Dec '04

The Named Parameters Library has been accepted into Boost. Congratulations to the authors, David Abrahams and Daniel Wallin. The vast majority of reviews were positive, although most reviewers requested additional documentation. Here is a list of the most important/commonly-requested changes or additions to the library: - More documentation! Specifically, + Automatic overload generation should go into the tutorial + Document operator, + Performance data (what's the cost?) + Reference section + "Best practices" section. - Add a metafunction for getting the type of a parameter, e.g., param_type<Params, width_t>::type. - Add test cases for the automatic overload generation macros. - Fix the BOOST_NAMED_PARAMS_MAX_ARITY bug; Cromwell Enage provided a solution. Doug Gregor Review Manager

1 0

[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