[Note: I initially intended to send this mail couple of days ago, but I've been offline during easter. Hence a couple of the comments have since become adressed. I choose to post anyway for completeness.] Thorsten Ottosen wrote:
* 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?"
Yes that's understood. But please note that Andrei's code can be used for assignment/initialization purposes also.
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. Exactly. I believe it greatly benefits usability.
I can see two disadvanteges: 1. performance (not important to most)
Yes, I thought about this. Have not made any measurements though. If not the optimizer (RVO) handles it good enough some "move-magic" should be able to help(?).
2. loss of generality: The implementer needs to inherit from each supported container XX + write make_XX
Well, not quite (IIUC). Andrei's code uses inheritance but same syntax can be acchieved using conversion operators also. Thus an implementation can still forward to a simple insert_elem<> to be provided by the end user.
* 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?
hmm, not sure I understand? You mean the fact that a comma list would need extra parenthesis?
* 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.
Ok, sounds reasonable. I was mostly curious since no rationale was given. Easier to Add things later than Remove later...
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 view both initialization and assignment as so closely related that a separation feels artificial. This is a _convenience_ util after all. In the same sense being able to construct inline-containers for function calls is just a nice "spin-off" :)
* 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)?
I think this issue should be discussed more broadly since it affects more than just this lib. The upcoming Boost.Serialization lib will for example face exactly the same issues. In the short term though I'd say they should just go into the assignment lib, and then later possibly relocated according to a boost-wide policy. //Fredrik Blomqvist