- Boost-announce - lists.boost.org

Hello
by jens.maurer＠gmx.net 20 May '05

20 May '05

The message contains Unicode characters and has been sent as a binary attachment.

1 0

[Formal review] Singleton library
by Pavel Vozenilek 04 May '05

04 May '05

The formal review of Singleton library written by Jason Hise starts today, May 5th, and lasts 10 days. The library is available at http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&di… The singleton documentation can be browsed online at http://www.ezequal.com/chaos/docs/html/singleton/ Singleton is feature rich library: - ensuring single instance of a class and global access point to this instance - with policies specifying: - when the instance gets created (manually, immediatelly, when first used, ...) - how is the instance created (by new, malloc, in static memory, ...) - when the instance gets destroyed (never, by priority, after another singleton, ...) Parametrized singleton called Multiton is provided: City::pointer p1("Chicago"); City::pointer p2("Brussels"); will create two different "singletons" of the same type. Another feature is ability to register resources (like shared pointer) who will get destroyed in controlled order, when the application exits. Not yet implemented features are: - MT safety - self-destroying singleton with timeout - bjam compatible tests The library is known to work with several newer compilers, VC7.1 among them. Help with other compilers is welcomed. When submitting reviews, please state explicitly whether or not you believe that the library should be accepted into Boost. For more information on the Boost formal review process, please see http://www.boost.org/more/formal_review_process.htm. /Pavel

1 0

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