[boost] Re: Formal Review: Assignment Library

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-04-11 18:48:49

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