On 4/2/2011 5:30 PM, Michel Fortin wrote:
On 2011-04-02 19:58:25 -0400, Walter Bright <newshou...@digitalmars.com> said:
The problem with the octal literals is, as has been often complained about,
people getting surprised by it. I've never heard of anyone being surprised by
the binary or hex literals.
Indeed. Isn't that a good argument for implementing octal literals the same way
as binary and hex literals?
Yes, except for something else - the rarity of need for octal literals. The only
modern usage I've seen of it is for file permissions.
I think it's a feature, not a "resort", that library templates can do this
well. I think it's far better than C++0x's user defined literals, for example.
I disagree that it's better. With C++ user defined literals the user doesn't
have to find by himself whether the number fits within the range of a regular
integer literal and if not fall back to using a string as the template argument
instead.
I believe that if you attempted to do octal literals using C++0x user defined
literals, you'd run into exactly the same issue (overflow). See:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf
C++0x user defined literals call a global function, which fails when you have
more than one definition of the same literal. I.e. you cannot qualify the
function to resolve ambiguity.
Other complaints about them:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3250.html
I don't think it's much worse, but I fail to see how it could be better.
Reasons:
1. It is not a language extension
2. Conflicting names are easily resolved
3. More than one argument is possible
4. The full power of CTFE is available to compute it, rather than the very
limited C++0x constexpr
5. If you read N2765, it's pretty darned hackish. I.e. there's the "raw" and
"cooked" mode.
Which makes me wonder, what does the compiler suggests in the error message when
it encounters 01777777777777777777777 ? I suspect it doesn't add the necessary
quotes, does it?
No, it doesn't. The lexer knows nothing about higher level semantics.