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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2002-10-10 17:48:58

----- Original Message -----
From: "Yitzhak Sapir" <yitzhaks_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Thursday, October 10, 2002 9:31 PM
Subject: Re: [boost] Re: new initialization lib, any interest?

> On Wed, 9 Oct 2002, Thorsten Ottosen wrote:
>
> > Peter Dimov <pdimov_at_[hidden]> wrote:
> > > Why do you need so many headers?
> >
> > apparently I don't.
>
> I'd be in favor of a naming format that was "init_map.hpp" for specific
> code necessary for anything <map> and "init_list.hpp" for that code
> necessary for anything in <list>.  I'd not be in favor of including <list>
> or <map> in those headers as I don't think these headers should be
> included "in place" of the standard headers, but rather, in addition to
> the standard headers.  As such, not including the headers, is as if you
> are making a basic assumption that the user did include them.  This forces
> the user to include them on his own, which is probably what he wants, if
> he knows he's going to initialize a std::map or whatever.

with  some of Dimov's stuff the headers could be fewer. If the code does not
need to know about
a standard header, then I also think it would be wrong to include it.
As for splitup, I think a big one for the lasy people (just like
<boost/smart_ptr.hpp> and
some specialized for the ones who care (just like <boost/shared_ptr.hpp etc)
would be better. I can't see a difference between'
init_map.hpp and init/map.hpp other than the last favors a more hierarchical
strucure.

> > > init(container)(value1)(value2)(value3);
> > >
> > > or
> > >
> > > init(map)(key1, value1)(key2, value2);
> >
> >  nice stuff! It is considerably simpler than my initial code. I presume
you
> > like the lisp syntax better :-)? As you know, I don't think it is the
right
> > one. One could choose
> > to support both, though. The problem of missing a value in the
assignment to
> > the map is hypothetical. If I wan't to map int to int, I can make the
> > mapping just as clear by using newline or tabs:
> >
> > set_map( m ) += 1,2    2,3    3,4    5,6;
> > set_map( m ) += 1,2
> >                            2,3
> >                           3,4;
> >
>
> Given that you yourself did not do well in giving an example of
> separation with whitespace, I think this speaks strongly for a pair-wise
> syntax.
maybe you didn't see my other reply? It was late :-) If I had tried to
compile it I would have gotten one
of your favorable compile-time errors. So to use your words, I don' t think
it "speaks strongly" for anything.
In fact, I would appreciate you'd not come up with false and irrelevant
arguments.

> In any case, I'm against something like assign_map(m) += or
> append_map(m) =.  Does the first do a clear() before it assigns?  Does the
> second?  The "set_map" or "append_map" or "assign_map" suggests one way,
> the "+=" or "=" suggests another.  This ambiguity does not occur with the
> parenthesis form, as there is no way to specify "multiple" meanings.  This
> double meaning problem is also what led me to propose doing away with the
> name altogether and having: m += 1,2, 2,3, 3,4, 5,6;

I like this syntax and will properly adopt it in due time. It's the most
precise and short so far.
having two operators is not that bad. It would require the user to know this
of course, but
in all my time in computer science, it must be some of the least complex
I've come around.
Especially when the semantics of the normal += and = is preserved, C++ users
will
learn it in no time.

> I had considered a form such as m += 1, 2 + 3, 4 + 5, 6; but
> unfortunately, the C++ syntax is to translate this to m += 1, 5, 9, 6;  In
> fact, there is no operator you could use that I can see.

no. In the naive beginning I talked with Leor Zelman about it. He quickly
turned my attention to operator precedence; comma has th lowest so
it will never work.

> The parenthesis form is not that hard.  Add a space between the values and
> the parenthesis, and the value isn't buried:
>
> init(m)( 1, 2 )( 2, 3 )( 3, 4 );
>
> In this case white space does enhance readability, but the syntax
> guarantees the user won't make a mistake.

neither will he in the other case. ¨The concern is hypothetical and the
interface for map and eg vector will be different which is much worse than
having both operator= and operator+=.
Spaces are always nice (I would always add spaces inside paranthesis as you
did before), but the less parenthesis
the better. The are still more desturbing than a comma. It might not be
simple integers that are added:

init( m)( "ssdsd", Class( 2, Cow( 3 ) ) )

m += "dfedfe", Class( 2, Cow( 3 ) )

the less parenthesis the better.

>In your case, whitespace might
> add something, but the user can still make a mistake.  Even something
> like:
>
> set_map(m) += 1,2,   2,3,   3,4,   5,6,   7,8,  | 9,
>               9,10,  11,12, 13,14, 15,16  17,18
>               19,20;
>
> With the user screen margin occuring where the | passes is possible.  In
> this case, white space doesn't save him from this mistake.  And it could
> be hard to find.

no. as I said earlier, a missing value  will be caught at "bug-time" (~the
first time the user runs the code).

> And I'm not in favor of naming anything that resides in the global
> namespace "_".
nothing will be put in the global namespace. It will all be in namespace
init or something.
The lambda library uses '_1' and '_2' etc. So why not '_'?.

>
> > The first version is the best. One would never miss a value that way and
the
> > values are easier to read than something burried in paranthesis:
> >
> > init( m )(1,2)(2,3)(3,4);
> >
> >  Now, your templates are really clever. I think that approach would
remove
> > much dependency. However, I think I will still get problems
> > when I need to use set and stack because insert() is different for set
and
> > stack uses push(). What would be the most elegant way out of this
trouple?
>
> A second level of templates that partially specializes the
> insertion/clearing functions based on the container passed could work...
Ok...
much like it works now, just will less dependency of headers except for
container adaptors
and any other to be supported container that don't fit the defaults.

best regards

Thorsten