Re: [boost] Re: Re: Re: new initialization lib, any interest?

From: Yitzhak Sapir (yitzhaks_at_[hidden])
Date: 2002-10-08 12:40:37

On Tue, 8 Oct 2002, Thorsten Ottosen wrote:

> > Anyway, what would the advanteges of this
> > approach?
>
> It seems to me to be more extensible and to integrate better with the
> other Boost classes, in my opinion.
> [thor]
> not understood, really. Its a library for initializing primary the STL. I
> have thought about
> more boost classes like PropertyMap and the graph stuff: adjacency_list,
> adjacency_matrix.
> But it should be witha uniform syntax...and(excuse me for saying so) an
> simple syntax ("as simple as possible but no ...") .

Even as far as the STL you don't seem to support it properly.  The
main thing that seems to me to be unsupported are pairs (example, list of
pairs).  But I'm sure you could have, with a little more thought to
details.  Anyhow, my interface has a uniform syntax (even if you don't
like it).

It would also be worthwhile for you to make your interface compile with
Visual C++ 6 (and probably other compilers).  For example, the policies
classes are partially specialized, and VC 6.5 and others don't accept
partially specialized classes.  In your case, I think you could use
function template overloading to provide a solution to this.  (Also take
note of the point list example later on).

> [thor]
> at first speed wasn't an issue. but my test (see other mail) that there is
> no overhead in my approach.
> I don't  think it is unthinkable that a loop could contain
>
> set_cont( v ) += x,y,z;

I either think that they'd be better as a list of explicit push_back()s,
or that a std::copy(block.begin(), block.end(), std::back_inserter(v));
would be better.

> [thor]
> not understood. Have you run a test?

I can't.  I use VC 6.5.

> If you think about missing a single
> value, the solution is easy. put a flag in the Map_comma_initializer
> that is set false  in operator,(); set the flag to true in
> Map_data_initialiser
> and the the destructor of Mapcomma_initializer test the flag. If you're
> referrring

Huh?  You're expecting a beginner to understand this?  I mean the user
will have a problem if he does something like (contrived so you know what
the values are supposed to be):

std::map<int, int> prime_to_odd; // the nth odd for the nth prime
set_cont(prime_to_square) += 2, 1, 3, 3, 5, 5, 7, 11, 9, 13, 11;

There's a value missing, but he'd have to carefully work through the list
to find out which value is missing.

> to  a compile time error, then maybe the compile time list is better.
> However,
> its more complicated usage would be much worse than waiting for a runtime
> initilization error.

Compile time errors are always preferable.  But very simply, I can't
compile your code because it uses template specialization that is not
supported by my compiler.

> [thor]
> when 'set' appears as a function name its always a verb in the imperative,
> never a noun.
> Thus you shouldn't be confused with the set class. In my vocabulary
>
> set( v )  += ...
>
> has only one meaning, and it conveys fine what's going one. Initializer is a

You can't use "set" because it conflicts with STL name set.  set_cont
could be a container of sets, a set of containers, the act of setting a
container to something, etc.  Set it self has an ambiguous meaning.  Take
in mind that now there's a proposal for an "enum_set" which is a different
thing entirely from the STL set.  Two nouns.  Two sets.  Two different
things.  How about assigner(), a function that returns an assigner object
to its parameter?

> bad name because this is "fraud"
>
> initialize( v ) = 1,2,3,4.
>
> since ot will remove whatever v held before that statement. It's realy an
> assignment.
> , not initializing something.

So call your library an "assignment" library.  It's not any more "fraud."
I used initializer() because that was the name of the library.  Assigner
would work just as well.

> good idea. What's the purpose of doing this for set, multiset? They already
> work with
> set_cont.

An associative mistake of mine.

> [Yitzhak: a map example]
>
> [thor]
> I don't agree. With your syntax above it's not clear what is the key and
> what is data. Production code
> would be
>
> set_map(addresses) = address("Washington St.", 30), "Johnson";

It's not clear with your syntax, because the user gives a comma delimited
list, that delimits both the keys and the data by commas.  Instead of
using this example, about about a list of pairs.

typedef std::pair<int, int> point;
std::list<point> point_list;
set_cont(point_list) += ....

Would this work?

> I also think my interface integrates better with the Boost methodology.
> For example, I think the same effect of your simpler enum_n_from can be
> achieved using make_counting_iterator().  (The step-size portion cannot,
> unfortunately, and I'd have liked counting iterator to have step size for
> integer data types).
>
> [thor]
> who is to jugde what integrates better? A formal review board, I presume.

I just said I think so.  It's my own thought.  I try not to state any
subjective statements as fact.  And I didn't here.

> Ease of use was top priority. Any iterator stuff will probably ruin that.
> I will wait for your step iterator too.

I am not writing one.  I just commented that boost has a counting iterator
that provides the functionality of the non-step enum_n_from.  I just said
it would be nice if the counting_iterator would have handled stepsizes in
integral counted types.  But I don't really need it, so I have no need to
write one.

I really don't think my format is that complex to understand (especially
with proper documentation), and neither that expensive for use.  Your
format is nice for its use of the comma operator.  I'm not against it, but
I asked why not also, and then realized it wasn't that hard to implement
(at least what I did yesterday wasn't that hard).