kc@rna.UUCP (Kaare Christian) (06/27/89)
Zortech C++ (v1.07) failed to compile the following line, complaining "bad abstract_declarator". val = min + ( double(y_pointer) / double(slide_ht)) * (max-min); It had no problem with the line val = min + ( (double)y_pointer / double(slide_ht)) * (max-min); or with the line val = min + double(y_pointer) / double(slide_ht) * (max-min); Is this an ambiguity in C++, or is Zortech just not smart enough? Clearly, when the compiler sees the first paren followed by a type name, it must trudge on quite a ways to figure out that the paren is part of an expression, not part of a cast. Kaare Christian kc@rna.rockefeller.edu
bright@Data-IO.COM (Walter Bright) (06/29/89)
In article <678@rna.UUCP> kc@rna.UUCP (Kaare Christian) writes:
<Zortech C++ (v1.07) failed to compile the following line,
< val = min + ( double(y_pointer) / double(slide_ht)) * (max-min);
<It had no problem with the line
< val = min + ( (double)y_pointer / double(slide_ht)) * (max-min);
<or with the line
< val = min + double(y_pointer) / double(slide_ht) * (max-min);
<Is this an ambiguity in C++, or is Zortech just not smart enough?
Zortech C++ uses 2 token lookahead. That is not enough to distinguish
(double(expression)) from (double)(expression), so the compiler guesses
the latter. Handling all the cases according to Bjarne Stroustrup's rules
requires arbitrary lookahead, which I haven't implemented yet.
The workarounds, though, are in general rather trivial, so this hasn't
been a major problem.