Hi Fredrik, "Fredrik Blomqvist" <fredrik_blomqvist@home.se> wrote in message news:c4vclu$dc$1@sea.gmane.org...
* I definitely think that the stl.hpp header should be split up to provide finer granularity (altough possibly retaining a convenience wrapper.)
ok.
* Have you read this article by Andrei Alexandrescu? http://www.moderncppdesign.com/publications/inline_containers.html
I might have a long time ago. Anyway, the goal seems to be different. His problem is "How can you pass a varying number of arguments to a function and maintain type safety?"
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(...);
True. I think my view has been that it could be done by calling a function, but that would not give the direct overview you're talking about. I can see two disadvanteges: 1. performance (not important to most) 2. loss of generality: The implementer needs to inherit from each supported container XX + write make_XX
* 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.
yes. It looks a bit wierd when using a comma list. If you have a const sequence, array<T,x> would probably do, right?
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.
Ok, I see no problems with a specific utility for initialization. It will save people the need for writing a function.
, I'd Really like it to support const initialization. (is that the correct term btw?)
I'm not sure, but I would just call it copy-initialization of a const object.
* 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?
It's not planned because the stuff got a bad reception. In particular, it overlaps with boost::counting_iterator, although I still think counting iterator requires too much typing. And since I went away from suporting any form of initialization, I called the lib "assignment" instead (since some were against calling it initialization in a broader sense).
* 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.
Ok, there is a general question that also must be answered; should these things even be in this lib (compared to being in the libs they support)?
* Boost.PP could/should be used to provide configurable upper limits for number of parameters.
ok. Thanks for your comments br Thorsten