From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2002-11-20 07:10:43
----- Original Message -----
From: "Rob Stewart" <stewart_at_[hidden]>
> From: Thorsten Ottosen <nesotto_at_[hidden]>
> > From: "Yitzhak Sapir" <yitzhaks_at_[hidden]>
> > > 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
> 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
> > > syntax.
> I agree.
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
> > > The parenthesis form is not that hard. Add a space between the values
> > > 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
we're discussing anything that has to do with ambiguity, simple people's
for a certain syntax. I think I mentioned in a mail that one could choose
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.
> > 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
> > 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:
> ["ssdsd"] = Class(2, Cow(3)),
> ["dfedfe"] = Class(2, Cow(3));
> What could be more intuitive?
["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.
> > > this case, white space doesn't save him from this mistake. And it
> > > be hard to find.
> > no. as I said earlier, a missing value will be caught at "bug-time"
> > 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk