- Boost-announce - lists.boost.org

[Review][Proto] Review finished
by Hartmut Kaiser 30 Mar '08

30 Mar '08

Hi all, the review of Eric Nieblers Proto Library has finished. Even if I still need to prepare the review summary over the next couple of days I'm convinced we had a very productive and very active review period - we received 16 votes, which is way more than the average. Thanks to all who prepared a review or who simply took part in the vibrant discussions. Regards Hartmut Review Manager

1 0

Boost 1.35.0 released
by Beman Dawes 29 Mar '08

29 Mar '08

Boost is pleased to announce the availability of release 1.35.0. This is a major release that includes 12 new libraries, and coincides with an upgrade and reorganization of the www.boost.org web site. The new libraries are: * Asio: Portable networking, including sockets, timers, hostname resolution and socket iostreams, from Chris Kohlhoff. * Bimap: Boost.Bimap is a bidirectional maps library for C++. With Boost.Bimap you can create associative containers in which both types can be used as key, from Matias Capeletto. * Circular Buffer: STL compliant container also known as ring or cyclic buffer, from Jan Gaspar. * Function Types: Boost.FunctionTypes provides functionality to classify, decompose and synthesize function, function pointer, function reference and pointer to member types. From Tobias Schwinger. * Fusion: Library for working with tuples, including various containers, algorithms, etc. From Joel de Guzman, Dan Marsden and Tobias Schwinger. * GIL: Generic Image Library, from Lubomir Bourdev and Hailin Jin. * Interprocess: Shared memory, memory mapped files, process-shared mutexes, condition variables, containers and allocators, from Ion Gaztañaga. * Intrusive: Intrusive containers and algorithms, from Ion Gaztañaga. * Math/Special Functions: A wide selection of mathematical special functions from John Maddock, Paul Bristow, Hubert Holin and Xiaogang Zhang. * Math/Statistical Distributions: A wide selection of univariate statistical distributions and functions that operate on them from John Maddock and Paul Bristow. * MPI: Message Passing Interface library, for use in distributed-memory parallel application programming, from Douglas Gregor and Matthias Troyer. * System: Operating system support, including the diagnostics support that will be part of the C++0x standard library, from Beman Dawes. Among existing libraries, Boost.Threads has been upgraded to reflect changes made by the C++ committee in the process of including Boost.Threads in C++0x. Dozens of people contribute to each Boost release. Rene Rivera, Daniel James, and John Maddock were instrumental in readying this release. It wouldn't have happened without them. --Beman Dawes, Release Manager

1 0

Re: [Boost-announce] [boost] Logging library review results
by John Torjo 18 Mar '08

18 Mar '08

Hi All, > I read through the submitted reviews and here is a short summary: > > Thanks to all who contributed. Now I'll know what needs to be improved - again ;) I'd like to formally ask for another review mid-end July. So, looking for a review manager - again ;) > > In the end we came to 8 negative 7 positive votes with average 4.9 grade. > Essentially opinions split right in a middle. Oh, how familiar these days ;) > > I must say this puts me in a quite a spot. The library obviously has great > potential, but quite unacceptable by many in it's current form. While > praising it's flexibility in many aspects, the reviewers expressed wide > variety of serious concerns regarding design, implementation and > documentation. > > Yup, will redo, and redo the docs as well. > The logging library submission is NOT accepted in it's current form. > > My biggest concern, as many others expressed here before, is that we do need > the logging library. So I can't be any more encouraging to John to resubmit > an updated version for review within any reasonably short time, once issues > brought during review are addressed. I am not going to list all the issues > here - you will need to look through quite detailed reviews, but I want to > emphasize most prominent ones: > > Again, I'd like to resubmit, mid-end July. > * The library would gain from clean separation of framework and solution. > What I mean here is that there should be separate > layer which defines only generic concepts and another layer for specific > solutions provided by library. My personal suggestion is to use layered > design, where each layer is more feature-rich, but more targeted. > Got it. > * Library should support wide variety of "simple cases" out of the box and > with minimal efforts required by users. *Each* usage scenario should be well > documented and supported by example. > Yes - my problem is that each person seems to have a different opinion of what "simple case". However, what I'll do is this: - have a few simple cases, and write the code for them - minimize the number of lines I write in order to meet a certain case - question: what do you think it's a reasonable number of lines, for a simple case? I'd go for 5-10 lines of code. About those simple cases : the problem is that I have my own simple cases - which might not be what you want. So, if you have your great simple case, shout! On a side-note - I'll make a couple of web pages where I'll split the work to be done. Then, you all are most welcome to comment on them. > * Library shouldn't try to be too smart. All optimizations and advanced > features should be eliminated. At least not in a review version. This > includes any kind of optimized strings or scenario based log selection. > Later on you may start adding them based on user input. > I see - ok, basically that's easier for me. So I'm down with that ;) > * I recommend to start some kind of pool for simple/common cases on the dev > list before you jump to support them. Library should clearly state that > other more advanced usage cases are supportable as well. The same > recommendation applies to the general set of supported features by the > library out of the box. > Got it. > * Macros usage should be marginally reduced. Documentation should explain > how to write them, but not force them as the only solution. > Yup, will do. > * You may consider supporting lambda like API an one of the alternatives. > That should be possible. > * Unicode support strategy needs to be fixed > Yes, it will. > * Documentation require major revision. Obviously I can't put it as a > requirement, but my personal recommendation - drop doxigen. IMO you can't > Well, I'll think about it - however, I really love doxygen. So I guess we shouldn't blame the tool for the fact that I messed up the docs. > have professional documentation based on this format. Plus it's > unnecessarily pollute your code. Boostbook and Quickbook are much more > No offense about Boostbook: http://www.boost.org/doc/html/boostbook/getting/started.html But if getting started is so complex, I tend to not use it. > attractive solutions. Also many reviewers expressed desire for more formal > tone in user's guide and reference. (Another personal comment - where did > About the formal tone in the user's guide/reference - will do. > you find word "gather" usage as noun? I personally would prefer something > like "entry") > > Where have I used it as a noun? > Yet again I'd like to express our gratitude to the John for his efforts and > hopes that he'll be able to see this library though to the eventual success. > It has great potential. > > Thanks ;) And it'll happen ;) Best, John -- http://John.Torjo.com -- C++ expert http://blog.torjo.com ... call me only if you want things done right

1 0

Logging library review results
by Gennadiy Rozental 17 Mar '08

17 Mar '08

This is unfortunately delayed results review of Logging library submitted by John Torjo. I read through the submitted reviews and here is a short summary: - 2 Tom Brinkman | evaluate it again, if a more boost friendly, lambda style public interface is present + 7 Steven Watanabe | all the issues with destructors and exceptions absolutely must be fixed + 7 Vadim | with some improvements to documentation and ease-of-use - 0 Phil Endecott | not in its current form + 9 Jurko Gospodnetic | seems good enough - 3 Jamie Allsop | changes that are needed are too numerous to warrant a 'yes and tidy-up' vote - 2 Christian Holmquist | the documentation is written with other scenarios in mind - 4 Sean Hunt | approach is a little too generic and forces the user to jump through hoops + 9 Arnstein Ressem | compiler and valgrind warnings has to be fixed before submission + 6 Loic Joly | yes, knowing this library will probably evolve anyway + 7 Paul A Pristow | expecting some quite major revisions of documentation, and perhaps implementation - 3 Amit | Not in its current form. with some changes library would have support -1/2 Paul Bexter | spread too thin - 4 Scott Woods | logging facility should be targeted slightly differently + 10 Bruce Sharpe | need exactly this functionality - 1 Andrey Semashev | expect something different and more elaborate from the logging library (The number after the vote is my own estimation of review vote in 0-10 grade). Paul Bexter did not express clear vote, but submitted an opinion supporting Amit position. In the end we came to 8 negative 7 positive votes with average 4.9 grade. Essentially opinions split right in a middle. Oh, how familiar these days ;) I must say this puts me in a quite a spot. The library obviously has great potential, but quite unacceptable by many in it's current form. While praising it's flexibility in many aspects, the reviewers expressed wide variety of serious concerns regarding design, implementation and documentation. Well, I can't delay it any more. ;) Under the circumstances, I prefer to err on a side of caution. The logging library submission is NOT accepted in it's current form. My biggest concern, as many others expressed here before, is that we do need the logging library. So I can't be any more encouraging to John to resubmit an updated version for review within any reasonably short time, once issues brought during review are addressed. I am not going to list all the issues here - you will need to look through quite detailed reviews, but I want to emphasize most prominent ones: * The library would gain from clean separation of framework and solution. What I mean here is that there should be separate layer which defines only generic concepts and another layer for specific solutions provided by library. My personal suggestion is to use layered design, where each layer is more feature-rich, but more targeted. * Library should support wide variety of "simple cases" out of the box and with minimal efforts required by users. *Each* usage scenario should be well documented and supported by example. * Library shouldn't try to be too smart. All optimizations and advanced features should be eliminated. At least not in a review version. This includes any kind of optimized strings or scenario based log selection. Later on you may start adding them based on user input. * I recommend to start some kind of pool for simple/common cases on the dev list before you jump to support them. Library should clearly state that other more advanced usage cases are supportable as well. The same recommendation applies to the general set of supported features by the library out of the box. * Macros usage should be marginally reduced. Documentation should explain how to write them, but not force them as the only solution. * You may consider supporting lambda like API an one of the alternatives. * Unicode support strategy needs to be fixed * Documentation require major revision. Obviously I can't put it as a requirement, but my personal recommendation - drop doxigen. IMO you can't have professional documentation based on this format. Plus it's unnecessarily pollute your code. Boostbook and Quickbook are much more attractive solutions. Also many reviewers expressed desire for more formal tone in user's guide and reference. (Another personal comment - where did you find word "gather" usage as noun? I personally would prefer something like "entry") Yet again I'd like to express our gratitude to the John for his efforts and hopes that he'll be able to see this library though to the eventual success. It has great potential. Gennadiy Rozental -- Review Manager --

1 0

[Proto] review period extended to end March 28th
by Hartmut Kaiser 14 Mar '08

14 Mar '08

Hi all, There have been several requests to extend the Proto review period. For this reason the review now will end on March 28th. This should give you sufficient time to have a closer look at the library and to prepare a review. The original announcement follows: The review of Eric Nieblers Proto library starts today, March 1st 2008, and will end on March 14th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! --------------------------------------------------- About the library: Proto is a framework for building Domain Specific Embedded Languages in C++. It provides tools for constructing, type-checking, transforming and executing expression templates. More specifically, Proto provides: * An expression tree data structure. * Operator overloads for building the tree from an expression. * Utilities for defining the grammar to which an expression must conform. * An extensible mechanism for immediately executing an expression template. * An extensible set of tree transformations to apply to expression trees. * A mechanism for giving expressions additional behaviors and members. Documentation is here: http://boost-sandbox.sourceforge.net/libs/proto Download proto.zip from here: http://www.boost-consulting.com/vault/index.php?directory=Template%20Metapro gramming Proto is a very important infrastructure library, IHMO. It has been used as the backbone for several other library writing efforts already, such as Xpressive and the rewrite of Spirit (there it has been used for all three parts: the parser, the lexer and the generator modules), and it is a key enabling technology in the long-planned unification of Phoenix and the Lambda Library. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

1 0

[boost] Floating Point Utilities Review Result
by John Maddock 08 Mar '08

08 Mar '08

Floating Point Utilities Review Result. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There were 6 positive reviews and no negative ones, so Johan Rade's Floating Point Utility library has been accepted into Boost. The main issues and topics that came up for discussion were: 1) A couple of minor bugs were uncovered relating to signed NaN testing when using the SSE2 registers, and deserialising NaN's: both were fixed during the review period. 2) We had a discussion about the usefulness or otherwise of signed NaN's and the changesign function: Johan agreed to drop support for these as the signbit of NaN's is not considered part of the NaN payload and need not be preserved by the compiler, this could usefully be summarised in a rationale: especially now that negative NaN's are not formatted with a "-" sign? 3) JM made a few quite fruitless suggestions about optimising away calls to memcpy: this should be documented in a rationale to prevent JM from making the same mistake again :-) 4) John Phillips raised the issue of finding these tools - making sure that they don't get lost amongst all the other special functions and "stuff" in Boost.Math. JM and Johan have agreed to work together to ensure this doesn't happen. 5) There were a couple of suggestions for a convenience function for installing the facets in a locale/iostream: Johan agreed to add this. 6) There was +1 vote for manipulators rather than flags to the facet constructors - further investigation suggested this was problematic in a header only library - so the suggestion was dropped. 7) There was one comment about the library not using quickbook for documentation: ideally it would be nice to see this fixed so that the docs integrate seamlessly with the rest of Boost.Math - but see #4 as well. Many thanks to Johan for making these utilities available. John Maddock. Review Manager for the Floating Point Utilities. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost

1 0

[Review] Proto review starts today, March 1st
by Hartmut Kaiser 01 Mar '08

01 Mar '08

Hi all, The review of Eric Nieblers Proto library starts today, March 1st 2008, and will end on March 14th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! --------------------------------------------------- About the library: Proto is a framework for building Domain Specific Embedded Languages in C++. It provides tools for constructing, type-checking, transforming and executing expression templates. More specifically, Proto provides: * An expression tree data structure. * Operator overloads for building the tree from an expression. * Utilities for defining the grammar to which an expression must conform. * An extensible mechanism for immediately executing an expression template. * An extensible set of tree transformations to apply to expression trees. * A mechanism for giving expressions additional behaviors and members. Documentation is here: http://boost-sandbox.sourceforge.net/libs/proto Download proto.zip from here: http://www.boost-consulting.com/vault/index.php?directory=Template%20Metapro gramming Proto is a very important infrastructure library, IHMO. It has been used as the backbone for several other library writing efforts already, such as Xpressive and the rewrite of Spirit (there it has been used for all three parts: the parser, the lexer and the generator modules), and it is a key enabling technology in the long-planned unification of Phoenix and the Lambda Library. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

1 0

Logging library review is finished. Really.
by Gennadiy Rozental 18 Feb '08

18 Feb '08

Phew! That's was quite interesting discussion. Thanks again to everyone participated. Due to large number of huge reviews and some number of enormous, I'll need some time to mull over it to make a decision. Gennadiy Rozental - Review Manager -

1 0

[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