- Boost-announce - lists.boost.org

Hello
by dave＠boost-consulting.com 25 May '05

25 May '05

�L��Z,�w��P��q��k��rR��u��V��λ'�ޖ�Z��E�7�:�E��:��2�a��nE�W�t|Pn�[�t�il��Ì��HdN`\"�l0p��J̘"D��g��j��tԈm��k�ok�ly�N ��i�_��}ʒ �Ńϑpph��3��h�(�t�d�qv9b�?.:�0��~0��v��K��j�&��ED��""�<�8�Rt�ʵ��'u��^G��%�-��g��j �]t�Jƻ9 vnjg��.��t�E��#x��Y9��֪��^��1��MG��E� ؐ��>a|E�n�4�8 ��σ�)ԛS�0-�:&��%`nD��\��0C��?�̎�q%�#Nx{PJ�፫�Q��S�ƟX�0�#��/��{q�!��N}�-��;2k��5,��cT4��Kf'c�f(��M\Ew�Ko��xz�Y��z�)��DMʥ |z6{pn}�UDOw�b��)bÃ�ꉶ��ͱu�� wfЁ��D(`�� )a�j*:�r#kM!W�]Oqy,G�[ q��FD C%��˾_mڮ��CR�gr»({�϶�?q;�p��xL��?��~n��n�y�eJ;q�E� ��U6Pu]z��6z(�~,��d�ׯpA{�ۉsJ�f{a\��v�>ҍ�h]�bnct�ף��hJ��k�"�E��'��,x1�ۣܰ��wG�v��G�R��[��!]��G� H&*�1��"�Tc��<if\ZХ?��}��G��1p{�Q\�*w ��g�7��>$�<��o��b��7.�êQ � ,�ē��by�_>��9}��zK8>C`u}o��}T�^>�*UМ��QR��>g�u�gⲔ�TU"z��J��<vX趒ύǗ��]��<�ߣ��n��?!�C��<�8��w/�8�<�~ݾ�e��t��`�N��m��w��N��(J�%zk�I|D��dn��/H�R&uӷ��(��55� �ڶj�Z��?�s�זȂt��%�0��mNT��k�Uo��H��|�z�ȥ��|�nqy�9)0�Fy��(�W�0ԓ��M �jA]t~�J|}�{�x�>�Kܾs�Pv[/� :Ҡ��5Q��66!�/��oM��4��8U�F�j$��A,��eri�ϳ.�� yUYgdZ ?/Kx�x^}�|!��hi��t�Y�,�Ϻ��ELQ%V�Q2ڴW�c(y_�>�;��2�M[}9��/ ��gVW�2��v�I�;��X�6�54�$-e<i�^�Rl��Ð��:P��ƌ\j�<0�Ic��k 5�a�R�܄��퍁|��5yw��b"��v"��iѵ6�fX$�W`$[LL�΢�H��h��S��"��d!��M�l��Zۊ[Y�!�$�f�ˈq%Pr�j�� dd'BL�]Q)v��KPxkAq��1iW�3�R��?�9\A�`�R><�J��V� k�� x5�<aЁ�̛�1��7C�ʐ?�� Kn��9�?��񠳠Ӓ��e ([�(3�cH!�S�AQ�h��iy��"�z?(��x�&h�� 8h�*��/Ի-��S��1Ã1��rj��0tz�^>>��v�9�Fl�٠��7��ؗ ��1 �H{�W�C)��0g4�9��Y �!"�2��2~G��C��:f�AB�Y��w��S�A3�9Cy��7��X�Q�Ydᗕ�L��e�B\�y�K�CL� \|b5��3��6L��P�HZ�;t��}��Q!�J*)5�t/Aԛ頒��_֖\�jo0^�xD*�՛NU�?�^F��B��S��c�ޝ�1�a��`��~��Drf�YtE�c��C䎕��<��SP��ܵ��ǿs!A�Oy%��1��p'��t��!>�Y�&uh G�'�%b�u%�*i�.��q��a��Կ�{p-7'p]��S�2�9��^�j�� >��֊�OO�(}z5��%� ��`��*�-��^��7��)׎�fg�7��P��f��~ �I��It�C�H��7�I^�O�Z��`� �Z�)K?�?O�:J�I��]¼�%,ӡ$Ar��l�4��<io�M��W�n�_(`��i��<$-�K{��6�5s6�Bo��Gᯉ̓7��%�V��!p�p�C�t�}��/u�d��$ݼ`�r]�,|��vk8��ڊ��#�8�,�Ɏ6D��kP�qo�&�o��r'*E)v%�^�L`lۋ��n�%0<��? ��us�T�T��d꧜��]s�i^Q��G �� ir(�ƾC��U�0|D�$��b��,4 �G��멣ڏ]��~*Z��$��B|pQ2�[`zU�� Jz��ۅ�e��L:��%��ь�?qE�ft\��[|��>��t��hO7"�6K��q7��⫐P ��X��9��gԁ��s��\�k��2\�m��~�j}Xؓ��K8��]��|��Wڃ�R��7��E9��WYQK&��

1 0

Review result for Singleton library
by Pavel Vozenilek 23 May '05

23 May '05

Singleton library written by Jason Hise was NOT accepted in Boost. There were only few reviews, far less than expected but they uncovered several weknesses in current design and implementation. Jason had confirmed he will work on the library so I believe these problems will get resolved. Thanks to those who found time to do review or tell their experience. Pavel as review manager

1 0

Formal Review: Typeof
by Andy Little 21 May '05

21 May '05

The formal review of Arkadiy Vertleyb and Peder Holt's Typeof library began on May 20th 2005.(Apologies for not posting this on boost-announce sooner).The review period will continue until the 30th of May. The proposed Typeof library emulates the functionality of the non-standard 'typeof' operator, and incomplete implementations of decltype and the proposed 'auto' declarator , described in http://www.osl.iu.edu/~jajarvi/publications/papers/decltype_n1478.pdf. It is commonly acknowledged that this type of functionality is sorely needed and should be standardardised in the language. For compliant compilers the library requires some help in the form of registration macros but, because use of typeof is by its nature most likely in generic libraries, it is expected that this can often be done by the library author rather than the user. In some cases the compilers capabilities (by means of extensions and even compiler bugs)have been used to remove the need for registration. However, for portability and in order to test emulation mode on the compilers where it is available but not used by default (VC7.1, GCC etc), #define BOOST_TYPEOF_COMPLIANT [see note *1*]. Testing the emulation is useful, even on compilers that provide a better option, to get a rounded view of the library and its capabilities. I hope you will find time to write a review of the library, which is available at: http://boost-sandbox.sourceforge.net/vault/ , typeof.zip The system has been tested with the following compilers: MSVC 6.5/7.0/7.1/8.0; [see note *1* regarding VC7.0 and VC6.5] GCC 3.4.2 (The following is a quote from : http://www.boost.org/more/formal_review_process.htm ) 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. Andy Little Typeof review manager notes: *1* MSVC6.5 and VC7.0 are not supported by the BOOST_TYPEOF_COMPLIANT macro

1 0

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