[boost] Re: Formal Review: Assignment Library

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-04-06 23:05:13

Hi Fredrik,

"Fredrik Blomqvist" <fredrik_blomqvist_at_[hidden]> wrote in message
news:c4vclu$dc$1_at_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