From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-04-06 23:05:13
"Fredrik Blomqvist" <fredrik_blomqvist_at_[hidden]> wrote in message
> * 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?
I might have a long time ago. Anyway, the goal seems to be different. His
"How can you pass a varying number of arguments to a function and maintain
> One advantage of an approach like the above, which I personally value, is
> the ability to do const-initialization: vector<foo> const v =
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
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
people the need for writing a function.
> Really like it to support const initialization. (is that the correct term
I'm not sure, but I would just call it copy-initialization of a const
> * What's the reason for removing the enum_* initialization mentioned in
> Codeproject article?
> http://www.codeproject.com/vcpp/stl/PGIL.asp Is something similar planned
> 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
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
> * I think the documentation for initialization of boost::graph, uBlas etc
> should be moved to separate chapters (files). The lib will most surely
> 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.
Thanks for your comments
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk