----- Original Message ----- From: "Rob Stewart" <[EMAIL PROTECTED]>
> 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. It was hypothetical that the missing value should be a problem, not that maps from 'int' to 'int' are. If you fordot a value, an assertion will be triggered. > > > > > 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. [snip] 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. no, if I had compiled it at all. No compiler accepts white spaces in identifiers. > > > > 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. You could then also quickly be accustomed to code like m+= 1,2, 3,4; I don't think we're discussing anything that has to do with ambiguity, simple people's personal preferences for a certain syntax. I think I mentioned in a mail that one could choose to support both syntaxes, but I'm not sure that is a good idea. > > > 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. good. :-) > > 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. My imagination is just not good enough, please show an example with both syntaxes and pinpoint where the error appears. > 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? init(m) ["sdsds"] -> Class( 2, Cow(3)); >(Efficiency may be another matter, > but it's intuitive, right?) yes. might not be such a bad idea. > > > >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. I cannot imagine a situation where constant data in a program has not been tested. I agree compile errors are better, but if it means you ruin the interface, it might not be worth it. regards Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
