[boost] Re: Formal Review: Assignment Library

From: Fredrik Blomqvist (fredrik_blomqvist_at_[hidden])
Date: 2004-04-11 16:55:31

[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