From: Thorsten Ottosen <[EMAIL PROTECTED]>
> From: "Yitzhak Sapir" <[EMAIL PROTECTED]>
> > On Wed, 9 Oct 2002, Thorsten Ottosen wrote:
> >
> > > 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
No, it isn't hypothetical. It is a reasonable situation to map
from one numeric type to another, and to use integers for the
initial values even when assigning to a floating point type.
> > > 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;
As you can see, tabs can be a problem. At least in mailing
lists! ;-)
> > 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.
I agree.
> 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.
They are neither false nor irrelevant arguments. He was,
however, exercising hyperbole. Your point, if I understand you
correctly, is that the compiler would have complained had you
been able to actually attempt to compile the above with a more
compliant compiler.
> > 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;
You make a great point.
> > 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 );
I don't put spaces within parenthetical expressions, so I'm
accustomed to code like this:
init(m)(1, 2)(2, 3)(3, 4);
I find that perfectly readable.
> > In this case white space does enhance readability, but the syntax
> > guarantees the user won't make a mistake.
I find the spaces distracting, but since they are not required,
but merely possible should your own sense of taste dictate them,
I have no problem either way.
> 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+=.
The concern is not hypothetical. If you have a
std::map<int, double>, you could easily initialize it with only
"pairs" of integers, and the compiler will be happy to convert
integers to doubles for you. How can you find an error if the
compiler doesn't flag it? How will you learn that you transposed
a 2 and a 3 in such a case? It depends upon how that
transposition affects the rest of your code. It may be invisible
in most circumstances.
> 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.
I find these readable:
init(m)("ssdsd", Class(2, Cow(3)));
m+= ("dfedfe", Class(2, Cow(3)));
Couldn't you use map-like notation:
init(m)["ssdsd"] = Class(2, Cow(3)), ["dfedfe"] = Class(2, Cow(3));
The idea is that init(m) would create an object that provides the
subscript operator which takes the map's key type as a parameter
and returns an object with an assignment operator which takes the
map's value type as a parameter. The assignment operator
would return the original "init" object. The "init" class
provides the comma operator to allow chaining as shown.
(Add whitespace to taste:
init(m)
["ssdsd"] = Class(2, Cow(3)),
["dfedfe"] = Class(2, Cow(3));
)
What could be more intuitive? (Efficiency may be another matter,
but it's intuitive, right?)
> >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).
You're assuming the code path containing that initialization code
will always run. What if the situation leading to that code path
wasn't tested? That may not bode well for the testing
methodology, but the point is that a compile time error is
better.
> > 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 '_'?.
MPL and Lambda use _ as a placeholder, not as a principal class.
--
Rob Stewart [EMAIL PROTECTED]
Software Engineer http://www.sig.com
Susquehanna International Group, LLP using std::disclaimer;
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
