[boost] Re: Formal Review: Assignment Library

From: Fredrik Blomqvist (fredrik_blomqvist_at_[hidden])
Date: 2004-04-06 18:00:08

Tom Brinkman wrote:
> The review of Assignment Library library, written by
> Thorsten Ottosen 2003 (nesotto_at_[hidden]) 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