"Fredrik Blomqvist" <fredrik_blomqvist@home.se> wrote in message news:c5ceon$qbm$1@sea.gmane.org... [snip]
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.
yes. If I have to make individual headers anyway, it's quite easy to supply make_vector() etc.
I can see two disadvanteges: [snip] 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.
yes.
* 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?
This looks a bit wierd const vector<int> v = init( v ),1,2,3,4,5; but not horrible wierd. Now if you do have a const sequence, array would do just fine const array<int,5> a = {1,2,3,4,5}; (execpt that this don't work in an initializer list) [snip]
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" :)
So you would support Boost.Initialization ?
* 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.
ok. br Thorsten