Tom Brinkman wrote:
The review of Assignment Library library, written by Thorsten Ottosen 2003 (nesotto@cs.auc.dk) starts today(April 1, 2004)and runs for 10 days.
Latest version of the library is available at: http://groups.yahoo.com/group/boost/files/assignment/ (204 kB) or in the sandbox.
What it is?
The purpose of this library is to make it easy to fill containers with data by overloading operator the comma, () and operator()().
[Snip] Hi, This isn't a formal review, just some initial comments based on a quick test of the lib. * I definitely think that the stl.hpp header should be split up to provide finer granularity (altough possibly retaining a convenience wrapper.) * Have you read this article by Andrei Alexandrescu? http://www.moderncppdesign.com/publications/inline_containers.html One advantage of an approach like the above, which I personally value, is the ability to do const-initialization: vector<foo> const v = make_vec(...); * Another variant similar to the above is to use a function-template as a pure "type grabber" and provide a conversion operator for the chaining proxy. This allows syntax like: container<T> const c = init(c)(..)(..) ; This technique is used in Leor Z's lib, as I'm sure you're aware. A third option (also used by Leor) is to have a fully templatized conversion operator. I'd vote for the "middle road" solution above though. Would be interesting to hear your opinion and rationale regarding this. Regardless of implementational technique and syntax finally chosen, I'd Really like it to support const initialization. (is that the correct term btw?) * What's the reason for removing the enum_* initialization mentioned in your Codeproject article? http://www.codeproject.com/vcpp/stl/PGIL.asp Is something similar planned to be added later? * insert_assigner.hpp boost/call_traits.hpp is included but not used. * Documentation nitpick: The "history and rationale" part doesn't have a quick-link from the index. * I think the documentation for initialization of boost::graph, uBlas etc should be moved to separate chapters (files). The lib will most surely grow and a separated structure for adding docs for new components could just as well be used right away. * Boost.PP could/should be used to provide configurable upper limits for number of parameters. * Perhaps use concept_check to ensure that the default version of make_insertion only operates on Sequences? Hope this makes alteast some sense to you, I'll try to tinker with the lib some more and hopefully return :) Regards // Fredrik Blomqvist