- Boost-announce - lists.boost.org

[Boost-users] Ann: Floating Point Utilities Review starts today
by John Maddock 18 Feb '08

18 Feb '08

The review of Johan Rade's floating point utilities starts today. Code and docs can be downloaded from : http://www.boost-consulting.com/vault/index.php? action=downloadfile&filename=floating_point_utilities_v3.zip&directory=M ath%20-%20Numerics& The library consists of three parts: 1) Floating point classification routines: these are optimised implementations of the C99 and C++ TR1 functions fpclassify, isinf, isnan, isnormal and isfinite. From Boost-1.35 onwards these are already a part of Boost.Math (see http://svn.boost.org/svn/boost/trunk/libs/math/doc/sf_and_dist/html/ math_toolkit/special/fpclass.html) so if accepted the two implementations will get merged. The review here should focus on the implementation used, and testing on whatever platforms you have available - in particular are there any circumstances (compiler optimisation settings etc) where this implementation breaks? 2) Sign manipulation functions: implementations of the C99 and C++ TR1 functions copysign and signbit, plus the changesign function. Two of these (signbit and copysign) are currently undocumented members of Boost.Math, and again the two implementations will get merged if this library is accepted. Again the main focus of the review here is the implementation, and testing thereof especially in the presence of compiler optimisations. 3) C++ locale facets: these will read and write non-finite numbers in a portable and round-trippable way: that is not otherwise possible with current C++ std library implementations. These are particularly useful for number-serialisation for example. Since the design is already specified by the C++ standard for these facets, your review here should focus on implementation, testing, documentation, and perhaps where in Boost these should best be placed if accepted. These look to be a useful collection of utilities, so I'll look forward to your reviews, Regards, John Maddock, Floating Point Utilities Review Manager. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[flyweight] Review summary
by Ion Gaztañaga 17 Feb '08

17 Feb '08

Hi to all, I've just written a summary of the flyweight review that tries to point out the main requests, questions and comments from reviewers and Joaquin's replies to those. If someone thinks I've missed some important point, please let me know. Joaquín is already correcting the pointed issues and thinking about alternatives on the keyed_flyweight issue. I hope we can definitely solve them satisfactorily in a short period of time. Here we go: -------------------------- Beginning of summary -------------------------- ------------------------- *Tim Blechmann’s review:* ------------------------- Design: Good. Suggests using read-write locks to improve concurrency since most operations will be searches. Implementation: fine Documentation: good Usefulness: quite useful to reduce memory footprint. Try to use the library: no Effort: Read documentation and compare it with his own implementation Knowledgeable about the problem domain: yes Accept the library: yes This reviews starts a thread about the correct read-write lock implementation for flyweight: 1) Joaquín points out that the library is based on insert(x) so a good candidate can be: readwrite_lock l(mutex); l.read_lock(); if(h=find(x))return h; else{ l.unlock(); l.write_lock(); h=insert(x); } Unfortunately read-write locks were removed due to a bug so this issue will be put under Future Work section for now. 2) Alberto Ganesh Barbati: suggests using hinted insert to improve performance in cases where find(x) fails and try to get a O(1) insertion. He also suggests using promotion or/and upgradable mutexes. 3) Joaquín thinks promotion/upgradable mutexes are not necessary. Read-write locks/upgradability/hints will need more thinking to maintain current policy orthogonality and the issue needs time. As mentioned, the issue will be revised when rw locks are available in Boost. Review manager note: I think that using “hint” needs atomic convertibility, because the “hint” can be invalidated by an erasure between unlock_sharable() and lock_sharable() and hint insertion does not guard against invalidated hints, but only against non invalidated but non-optimal hints. ------------------------- *John Reid’s review:* ------------------------- Design: Very good. Suggests intermodule_holder as the default holder. Implementation: Ok. Documentation: Clearly written and well thought out. He would like to see more examples and the inclusion of test code. Usefulness: High Used the library: No Effort: A quick read through the tutorial and the examples Knowledgeable about the problem domain: Not a design patterns expert but using C++ for 15 years. Accept the library: yes 1) Joaquín replies that intermodule_holder performs a way more expensive static initialization process than static_holder (needs shared memory). Another reason for not including this is that Boost.Interprocess (on which intermodule_holder depends) is not universally supported. Agrees to improve examples. 2) John suggests documenting intermodule_holder limitations 3) Joaquín agrees documenting these limitations ------------------------- *Marcus Lindblom’s review* ------------------------- Design: Very nice. Comments: namespace should be boost::flyweight. Factory should be called store Implementation: Not looked at thoroughly. Documentation: Great! Comments: the reference page, the first header ("boost/flyweight.hpp") doesn't link to anything? flyweight.hpp page misses to mention the tag argument in the first list of parametrization. Usefulness: High. Used the library: Nope. Effort: Quick reading. (1h) Knowledgeable about the problem domain: Yes Accept the library: Yes 1) Joaquín says that namespace issues are related to compiler bugs and the namespace conforms Boost rules explained at "For those who are really interested in namespaces" at http://tinyurl.com/ywb9n7 Factory name was chosen because most descriptions of the flyweight design pattern use this same terminology: http://tinyurl.com/ys5k3q Agrees to fix documentation problems with Firefox. ------------------------- *Matias Capeletto’s review* ------------------------- Design: Great. Implementation: Quick look. Documentation: Good. Typo spotted. Usefulness: High Used the library: gcc 4.1.3, under Linux Effort: Followed the library progress from the beginning Knowledgeable about the problem domain: Yes Accept the library: Yes 1) Joaquín: Typo fixed David Sankel’s review Design: Very well designed. Suggests a configuration option for equality segmantics. Implementation: He hasn't looked at much code, so I have no opinion here Documentation: Good Usefulness: Good Used the library: No Effort: An in depth study of the documentation Knowledgeable about the problem domain: Not until this review Accept the library: Yes 1) Joaquín says it’s trivial to override the default equality on a per case basis: typedef flyweight<whatever,...> fw_t; inline bool operator==(const fw_t& x,const fw_t& y) { return &x.get()==&y.get(); } ------------------------- *Vicente Botet’s review* ------------------------- Design: Good. Issues: * The tests performed on example5 should be extended with a intermodule_holder specifier. Joaquín’s answer: there is no need for that since it’s only performed in the initialization. * On platforms on which static variables are unique inter DLL the intermodule_holder specifier type can be a static_holder_class. Joaquín’s answer: Ok. * Holder specifier renaming. Maybe static_holder by module_holder, and intermodule_holder by process_holder? Joaquín’s answer: Agrees to revise names but he’s not found good alternatives. * Add an exclusive core specifier Joaquín’s answer: Added to Future Work section. Implementation: Quite good * Minor correction The documentation states that the ..._specifier must be a ..._marker, but this is not needed for the ..._class Joaquín’s anwswer: This ability used to be documented at the reference, but I've just checked and it is no longer there, I'll restore that bit. * refcounted_value is a class that could be public. Why it is declared in the namespace detail. Joaquín’s answer: It is an implementation detail, the user won't ever be exposed to it. * could you explain why detail::recursive_lightweight_mutex is needed and boost::detail::lightweight_mutex is not used directly? Joaquín’s answer: Recursive mutexes are needed when constructing composite complexes with flyweight<>. Documentation: Good. Issues: * Some more elaborated examples suggested. Joaquín’s answer: I'll try to extend the examples section. * intermodule_holder specifier: A reference to a document explaining the problem with platforms not ensuring the unicity of static variables when DLL are used will be welcome. Joaquín’s answer: I'm no expert here, but I'd say that platforms without static var unicity across dynamic modules are the majority rather than the exception. * Reference section: The reference section was much more hard to follow. I think that the interactions between the different classes are very hard to describe using the current style. Joaquín’s answer: It tries to keep the level of formality you find at the C++ standard. The idea is you go to the reference for exact, authoritative information. * An implementation section will help to understand how all this works, describing the interactions between the core and the policies. Joaquín’s answer: I'd much prefer to concentrate on improving the part on extending the library without disclosing too much about how things are assembled internally. * Add performance section Joaquín’s answer: Ok. * Rational: Adding of the map versus set problem explanation.??? Usefulness: Good Used the library: No. Effort: In-depth reading of the docs and implementation Knowledgeable about the problem domain: Yes Accept the library: Yes ------------------------- *Neil Hunt’s review* ------------------------- Design: Good Implementation: Good Documentation: He didn't read it all closely. * Some performance indicators or at least discussion of the tradeoff of extra hashing vs reduced dynamic allocations would be useful. Joaquín’s answer: ok Usefulness: Useful Used the library: No Effort: A moderate investigation. Knowledgeable about the problem domain: Yes Accept the library: Yes ------------------------- *Alberto Ganesh Barbati’s review* ------------------------- Design: Very good. Issues: * It doesn't fully grasp the essence of the flyweight pattern because of a major flaw. The flaw is the fact that an object needs to be created in order to check whether an equivalent flyweight exists or not. Implementation: Well done. Issues: * I strongly disagree with the choice of the term "factory" for a component that actually only acts as a storage. Documentation: Very well written. Issues: * The policies are indeed properly described, but the bare description is not very helpful in showing how to write a new policy Usefulness: Useful if the flaw I described before could be addressed Used the library: gcc 3.4.5 (mingw) Effort: A couple of hours. Knowledgeable about the problem domain: Yes. Accept the library: Reluctantly, the answer is no. He encourages the maintainer to consider addressing the issues I raised here, in which case I am ready to change my opinion. 1) Joaquín’s answer: * Instantiating a flyweight<T> will always create a temporary T (and hopefully just one when we get rvalue refs and variadic templates). The purpose of the library is *not* to avoid constructing expensive objects, it is to reduce memory consumption through object sharing. Collateral benefits include increased performance in object passing around. * GoF introduces a key type K into the pattern that is used to retrieve the actual values of T. So, we have a one-to-one relation KT, i.e. there exists a stateless function f of the form “T f(const K&)”. My analysis led me to conclude that the right approach is to assume that K==T. * Joaquín will investigate the potencial of the LookupFactory (factories that, additionally to the insert memfun, provide a find memfun) pattern, described at http://lists.boost.org/Archives/boost/2008/01/132798.php * I decided to keep "factory" because this component is obviously * related to the element of the same name in GoF and oher descriptions * of the pattern. * I’ll refine the reference section to make it easier write custom policies. 2) Alberto’s answer: I have another case in an project I am working on: in a 3D application, I have heavyweight 3D mesh objects that might be shared among several actors. The key of a 3D mesh is just its filename. I don't want to load an entire mesh into memory just to find out that I have it already. 3) Joaquín proposes the keyed_flyweight: struct character { character(char c):c(c){} char c; }; int main() { // fw_t objects are constructed from chars // but are convertible // to character. typedef keyed_flyweight<char,character> fw_t; // creates an internal character('a') fw_t x1('a'); // same shared value as x1, zero temporary character's fw_t x2('a'); // creates an internal character('b') fw_t x3('b'); } 4) Alberto proposes unifying keyed and non-keyd with just one flyweight class template: * we have two types: key_type for keys and value_type for values. The two types can be coincident (non-keyed proposal) * the constructor of flyweight semantically takes keys, not values * keys (not values) are fed as-is to the factory insert() method: it's up to the factory to determine whether the key is already present and if it's not present to construct the corresponding value. * the insert() method returns a handle * the factory provides a way to extract values from handles * The rest of the design would more or less stays exactly the same. 5) Joaquín’s answer to Alberto’s unified flyweight: I'd rather factories remained dumber so that all this intelligence is implemented in the core because: * STL associative containers are either set-like * (key_type=value_type) or map-like (T != value_type != key_type, because T == mapped_type). * The container would have to deal with a more general notion of key extraction. Boost.MultiIndex can do that, but I don't want to tie flyweight to that lib. Review manager note: The discussion went a bit further but the essence is that Joaquín has proposed alternatives and is ready to further discuss the issue because flyweight won’t be ready until Boost 1.36. I encourage Joaquín, Alberto and other contributors to discuss the issue in the future again. ------------------------- *John Torjo’s review* ------------------------- Design: Ok. Implementation: Ok. http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/tutoria… I think there could be a simpler way to do this: http://www.entropygames.net/globals.htm Documentation: Very nice Usefulness: Very useful. Used the library: No. Effort: 1.5h Knowledgeable about the problem domain: Yes Accept the library: Yes. ------------------------- *Markus Werle's review* ------------------------- Design: Not reviewed Implementation: Not reviewed Documentation: Good Usefulness: Yes Used the library: No Effort: Moderate Knowledgeable about the problem domain: No Accept the library: Yes ------------------------- *Kevin Sopp’s review* ------------------------- Design: Good. A way to get usage statistics about the flyweights would be nice (Joaquín agrees) Implementation: Good Documentation: Good Usefulness: Good Used the library: Yes Effort: Moderate Knowledgeable about the problem domain: Yes Accept the library: Yes Other accepted suggestions coming from non-review posts: Add assertions to catch static variables destruction ordering problems with flyweight. The refcounted tracking policiy can detect such illegal situations (an entry is destroyed with a refcount!=0). -------------------------- End of summary -------------------------- Ion Gaztañaga - Review Manager -

1 0

[flyweight][review] Flyweight accepted
by Ion Gaztañaga 05 Feb '08

05 Feb '08

Hi to all, The Flyweight library submitted by Joaquín M. López Muñoz has been *accepted* into Boost. Thanks to all reviewers and all who contributed to the library before the review. We've received 10 reviews (Alberto Ganesh Barbati, David Sankel, John Reid, John Torjo, Kevin Scopp, Marcus Lindblom, Markus Werle, Matias Capeletto, Neil Hunt, Tim Blechmann), and all except Alberto's one were positive. Please, if I've missed a review, let me know. Joaquín agreed to address Alberto's comments (either with keyed_flyweight or by another method) and I like to encourage Joaquín and Alberto and the rest of the Boost community to improve the flyweight library to optimize and adapt it for situations like Alberto has described. I'm pretty sure that we'll reach an agreement. I'll have some time during the weekend to read all the reviews and write an small summary of requested changes, ideas, complaints, etc... to summarize the review process. Congratulations to Joaquín and thanks to all those who have participated in the review. Ion Gaztañaga - Review Manager -

1 0

[flyweight] Review period extended to February 3
by Ion Gaztañaga 29 Jan '08

29 Jan '08

Hi to all, We've received 4 positive reviews and several comments, but we still want more ;-) Some people expressed interested in the pre-review period and I want to give some time (weekend is the right time to review a Boost library...) to those who are interested in the library and have not found time to review it. The last review day is February 3. Common, the library is very lightweight ;-) to review, it's pretty well documented, it's certainly small and very general purpose. Here is the information. Last call to passengers! *Description:* Flyweights are small-sized handle classes granting constant access to shared common data, thus allowing for the management of large amounts of entities within reasonable memory limits. Boost.Flyweight makes it easy to use this common programming idiom by providing the class template flyweight<T>, which acts as a drop-in replacement for const T. *Online docs:* http://tinyurl.com/2sstyr http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/index.html *Download:* http://tinyurl.com/hrdm6 http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… *Notes:* 1) We've seen some suggestions in the mailing list for Flyweight. Joaquín has nicely explained a couple of issues that we'd like to address/discuss in the review: http://tinyurl.com/33ghtf http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/review_… 2) Flyweight needs Boost 1.35 elements because the library depends on libraries like Interprocess for some features/tests. Since SVN snapshot tarballs seem to be missing these days, those who want to try flyweight can download a working SVN-HEAD snapshot here: http://igaztanaga.drivehq.com/boost_trunk.tar.bz2 3) Serialization tests won't work. This feature is expected to work when some new features (discussed in the mailing list between Joaquín and Robert Ramey) are added in Boost.Serialization. Those are expected for Boost 1.36. What to include in Review Comments ================================== 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. Ion Gaztañaga - Review Manager -

1 0

[review] Fast track review of Boost.Utility/Singleton - rejected for now
by John Torjo 29 Jan '08

29 Jan '08

Hi all, We've gotten a lot of feedback on the Boost.Utility/Singleton. It's clear that such an addition would be beneficial to Boost, but I've chosen to reject the library at this time. Summary: - 4 positive reviews - 4 negative reviews Phil Endecott - yes Nat Goodspeed - yes Dherring[@]ll[]mit[]edu - yes Ingolf Steinbach - yes Anthony Williams - no Gennady - no Pierre-Jules Tremblay - no Michael Marcin - no The main concern was that the library is not flexible enough, and that it imposes too many things on the users (like, if BOOST_HAS_THREADS is defined, the singleton is automatically thread-safe). I would like to see this into Boost, so I hope Tobias will update the library, given all this feedback, and I would suggest another review in 2-3 months. I'd like to be the review manager then as well, if Tobias will still want me. Suggestions: * Should use policies to specify creation/destruction, access to singleton, resurection For creation/destruction, one should be able to have singleton<single_thread<T> >, singleton< synchronized<T> >, singleton< thread_specific<T> > * example for DLL support * more detailed docs As for the next review of the library, I will talk to Tobias, and let the review wizard know. Thanks to Tobias, for the lib, and to all that participated to the review! Best, John - Review Manager - -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right

1 0

[review] Review of Flyweight library started January 21 and still running!
by Ion Gaztañaga 26 Jan '08

26 Jan '08

Hi all, The formal review of Flyweight library started January 21 and will end January 30, we have a few nice reviews, but I'm sure that those who haven't reviewed it are also interested in the library ;-). The library solves quite a common programming pattern, is small and very well documented. So don't be afraid to try it! Information for reviewers: *Description:* Flyweights are small-sized handle classes granting constant access to shared common data, thus allowing for the management of large amounts of entities within reasonable memory limits. Boost.Flyweight makes it easy to use this common programming idiom by providing the class template flyweight<T>, which acts as a drop-in replacement for const T. *Online docs:* http://tinyurl.com/2sstyr http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/index.html *Download:* http://tinyurl.com/hrdm6 http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… *Notes:* 1) We've seen some suggestions in the mailing list for Flyweight. Joaquín has nicely explained a couple of issues that we'd like to address/discuss in the review: http://tinyurl.com/33ghtf http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/review_… 2) Flyweight needs Boost 1.35 elements because the library depends on libraries like Interprocess for some features/tests. Since SVN snapshot tarballs seem to be missing these days, those who want to try flyweight can download a working SVN-HEAD snapshot here: http://igaztanaga.drivehq.com/boost_trunk.tar.bz2 3) Serialization tests won't work. This feature is expected to work when some new features (discussed in the mailing list between Joaquín and Robert Ramey) are added in Boost.Serialization. Those are expected for Boost 1.36. What to include in Review Comments ================================== 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. Ion Gaztañaga - Review Manager -

1 0

BoostCon 2008 Now Open For Registration
by David Abrahams 25 Jan '08

25 Jan '08

Hi All, The 2nd annual Boost Conference has been scheduled for May 4-9 2008. Please see http://www.boostcon.com/registration for registration information. If you want to stay at the Aspen Meadows (highly recommended as it is within walking distance of the conference venue and was the site of great after-hours discussions in '07), it's especially important this year that you book your rooms early. Since, unlike last year, Aspen's airport will be open this May, demand for rooms has been heavy. In fact, the following week, which we tried to get, was snapped up by another group before we even had a chance to catch our breath, just weeks after BoostCon'07 ended. We'll be working hard on getting the program together for 2008 over the coming weeks. We hope to include many more Boost authors and contributors, and build in several more intensive library-specific sessions, to make 2008 better than ever. Please send any questions to the BoostCon planning committee at: organizers(a)boostcon.com. Those of you who didn't make it to BoostCon'07 may want to have a look at the photo gallery at http://boostcon.com/community/photos, peruse the 2007 program at http://boostcon.com/program, and check out the two trip reports mentioned here: http://boostcon.com/news/2007/Jul/16/yet-another-trip-report. See you in Aspen! -- The BoostCon Planning Committee

1 0

[review] Review of Flyweight library begins today January 7
by Ion Gaztañaga 21 Jan '08

21 Jan '08

The formal review of Flyweight library, proposed by Joaquín M. López Muñoz, begins today (sorry for the late announcement): *Description:* Flyweights are small-sized handle classes granting constant access to shared common data, thus allowing for the management of large amounts of entities within reasonable memory limits. Boost.Flyweight makes it easy to use this common programming idiom by providing the class template flyweight<T>, which acts as a drop-in replacement for const T. *Online docs:* http://tinyurl.com/2sstyr http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/index.html *Download:* http://tinyurl.com/hrdm6 http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… *Notes:* 1) We've seen some suggestions in the mailing list for Flyweight. Joaquín has nicely explained a couple of issues that we'd like to address/discuss in the review: http://tinyurl.com/33ghtf http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/review_… 2) Flyweight needs Boost 1.35 elements because the library depends on libraries like Interprocess for some features/tests. Since SVN snapshot tarballs seem to be missing these days, those who want to try flyweight can download a working SVN-HEAD snapshot here: http://igaztanaga.drivehq.com/boost_trunk.tar.bz2 3) Serialization tests won't work. This feature is expected to work when some new features (discussed in the mailing list between Joaquín and Robert Ramey) are added in Boost.Serialization. Those are expected for Boost 1.36. What to include in Review Comments ================================== 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. Ion Gaztañaga - Review Manager -

1 1

[flyweight] Remainder: Flyweight review will start January 21
by Ion Gaztañaga 18 Jan '08

18 Jan '08

Hi to all, Flyweight library will be reviewed January 21-30. For those interested in the library, this post contains all the information needed for the review: *Author:* Joaquín M. López Muñoz *Description:* Flyweights are small-sized handle classes granting constant access to shared common data, thus allowing for the management of large amounts of entities within reasonable memory limits. Boost.Flyweight makes it easy to use this common programming idiom by providing the class template flyweight<T>, which acts as a drop-in replacement for const T. *Online docs:* http://tinyurl.com/2sstyr http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/index.html *Download:* http://tinyurl.com/hrdm6 http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… *Notes:* 1) We've seen some suggestions in the mailing list for Flyweight. Joaquín has nicely explained a couple of issues that we'd like to address/discuss in the review: http://tinyurl.com/33ghtf http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/review_… 2) Flyweight needs Boost 1.35 elements because the library depends on libraries like Interprocess for some features/tests. Since SVN snapshot tarballs seem to be missing these days, those who want to try flyweight can download a working SVN-HEAD snapshot here: http://igaztanaga.drivehq.com/boost_trunk.tar.bz2 3) Serialization tests won't work. This feature is expected to work when some new features (discussed in the mailing list between Joaquín and Robert Ramey) are added in Boost.Serialization. Those are expected for Boost 1.36. Regards, Ion

1 0

the Switch library by Steven Watanabe has been accepted provisionally
by Stjepan Rajko 17 Jan '08

17 Jan '08

The Switch library, submitted by Steven Watanabe, has been accepted provisionally pending a mini-review to be scheduled when possible. The purpose of the mini-review will be to assure that the suggestions outlined below have been adequately addressed. I would like to again thank Steven for submitting a very useful library, and for diligently working with the reviewers on improving its design. I would also like to thank Tobias Schwinger, Joel de Guzman, Darren Cook, Daniel (dherring@...), Felipe Magno de Almeida, and Paul Bristow for providing reviews, votes and half votes. Finally, thanks also to Dan Marsden, Larry Evans, Alexander Nasonov, Richard (legalize@...) and Mathias Gaunard for contributing to the discussion. SUMMARY OF VOTES: Tobias Schwinger and Joel de Guzman have submitted full reviews with positive votes: http://article.gmane.org/gmane.comp.lib.boost.user/32637 http://article.gmane.org/gmane.comp.lib.boost.user/32634 (Joel eventually converted his vote to "yes") One "yes" (half) vote was submitted by Paul Bristow: http://article.gmane.org/gmane.comp.lib.boost.devel/170069 One "no" (half) vote was submitted by Felipe Magno de Almeida: http://article.gmane.org/gmane.comp.lib.boost.devel/170051 Another "no" came privately - the point there was that the library didn't undergo enough scrutiny before submission, and that it should be resubmitted. Another privately submitted "no" came soon after the review opened, stating that the reviewer was not able to deduce any usability/usefulness from the library documentation, and suggested there should be a motivating example on the first page. RATIONALE FOR ACCEPTANCE: I believe the low number of full, positive reviews is justified by the relatively narrow scope that this library covers. Within that scope, however, reviewers indicated that the library is extremely useful. Also, the reviewers submitting positive votes have indicated (and proven) significant expertise in the area, leading me to place much weight on their votes. On the other hand, the negative votes did not point out any concrete flaws in the library itself that would merit rejection. RATIONALE FOR REQUIRING A MINI-REVIEW The "no" votes did, on the other hand, indicate some skepticism of the quality of the library/documentation as submitted, and the progress of the redesign that was happening during the review. Also, as a result of the review, the potential scope of the library has expanded significantly from what was originally proposed (which mostly focused on the ability to choose the number of cases at run-time). I believe that a combination of these two give sufficient reason for a mini-review - doubts about the library can be resolved, and those that might become prospective users of the library under the expanded scope will get a chance to give their opinion. I volunteered to manage the mini-review, so once the library is ready it will hopefully not remain in the review queue for too long (as it seems that finding review managers is the biggest problem ATM). To keep the burden on the community low, I propose to treat the mini-review as a partial continuation of the current review - I will consider the "yes" votes by Tobias and Joel to be left standing unless they state otherwise, and will require any "no" votes to be (re)justified given the new condition of the library. SUGGESTED CHANGES TO THE LIBRARY: * Documentation All reviewers have noted that the documentation could be improved. Specific suggestions were: * motivating example on the first page * additional examples * performance stats * more explanation of the types involved and how they are used. As the scope for the library has increased as a consequence of the review, a gentler, more detailed documentation approach might benefit the library - I believe that many people might find the new library useful, given the right motivation and examples in the documentation. * Return type Tobias Schwinger suggested that the return type should be specified explicitly in the switch_ call, rather than inferring it from the function object, and this seems to be the status quo in the newer designs. Joel de Guzman also suggested that if a version of switch_ should infer the return type, that return type should be a Boost.Variant of the types returned by each of the cases. * Default default behavior If the default behavior is left unspecified, switch_ should invoke the default constructor of the return type in the default case, rather than throwing an exception. This was suggested by Tobias Schwinger after the issue was raised by Dan Marsden. Alexander Nasonov has also indicated that a throwing default case can cause inefficiency, even when it is guaranteed not to be invoked. * Fall-through Alexander Nasonov pointed out the lack of fall-through capability in the submitted implementation. Fall-through has been incorporated into the recent designs being discussed. * Allowing void-returning function objects for the default case with a non-void returning switch Tobias Schwinger mentioned the possibility of allowing default case function objects of void return type even when the switch return type is non-void, as long as the function object call does not return. This would be useful, for example, if the function object is guaranteed to throw. After some discussion on whether determining if the return type is void can be done efficiently, it looks like the proposed solution is to use a special return type that indicates that the call will not return. Since Tobias indicated that this feature is a minor point, it could be implemented or not, depending on how well it fits into the final design. * Design There has been a lengthy discussion on the underlying design of the library, what it should offer, and whether the name of the library is appropriate. There are two types of designs that have been put forward as being appropriate and/or necessary for a Boost.Switch library. On one hand, there is the submitted design (labeled "A" in recent postings), which takes the switch cases in an MPL sequence and a single function object containing implementations of all cases. Joel de Guzman has proposed another design (labeled "B"), in which the switch cases are specified separately and allow a different function to be used for each case. Design "A" is better suited for situations in which the number of cases is determined by a compile time constant, while "B" is more appropriate for many use cases, and provides more flexibility and a more familiar syntax. The result of the discussion was that the Boost.Switch library should cover both situations, and an interface is now being developed that can be used in different ways for different uses (based on a common concept capturing case sequences). Thanks again to all that have contributed to this review, and congratulations to Steven for the accepted library. As others have stated, there is much confidence that Steven will meet the challenges successfully for the mini-review, which we will schedule as soon as the library is ready. Regards, Stjepan

1 0