hexfloats in c++0x

Can we turn on support for hexfloats in -std=c++0x? It is already turned on in c++03 mode.

get_double.pass.cpp:108:14: error: invalid suffix 'p' on integer constant
        assert(v == 0x125p-1);
        ^

Thanks,
Howard

They're disabled in C++0x mode because they conflict with user-defined literals. We might be able to jump through some hoops to see if there's a literal operator named "p" or "P" in scope, but... yuck.

Suggestions welcome!

  - Doug

<sigh> That's a serious design flaw / incompatibility in C++0x. hexfloat literals are one of the better features of C99. We even enshrined hex-float formatting in the C++0x library. What a mess...

-Howard

What's more, there should be a warning in C++03 mode to the effect that they are incompatible with C++0x. It is not reasonably implementable in C++0x.

Consider 0x123p4. In C99 the meaning is clear; in C++0x this clearly means a call to operator "" p4. It seems really ugly to enable both

Now, it's worth nothing that every literal name starting with a non-underscore is "reserved for future standardization", which I interpret to mean "the program is well-formed but might not be in the future". It would probably be reasonable to implement a -f flag to make hex exponents take precedence over user-defined literals, but I do not think we can do that by default.

Sean

Douglas Gregor wrote:

Can we turn on support for hexfloats in -std=c++0x? It is already turned
on in c++03 mode.

get_double.pass.cpp:108:14: error: invalid suffix 'p' on integer constant
       assert(v == 0x125p-1);
       ^

They're disabled in C++0x mode because they conflict with user-defined
literals. We might be able to jump through some hoops to see if there's a
literal operator named "p" or "P" in scope, but... yuck.

Suggestions welcome!

I think that behavior is undefined for any program that uses a literal
suffix without a leading underscore, because those names are reserved for
use by a further Standard.

Therefor, I think clang's lexer could just prefer lexing "0x123p4" as a
floating point literal and can issue a warning about declarations of names
such as 'operator "" p' ("warning: literal operator will never be used
implicitly" or some such).

I think independently of that, emitting a warning would be a good idea for
'operator "" L(unsigned long long)' too. Since unless I'm mistaken, that
operator cannot be called implicitly either ("12L" isn't a user defined
literal).

Douglas Gregor wrote:

Can we turn on support for hexfloats in -std=c++0x? It is already turned
on in c++03 mode.

get_double.pass.cpp:108:14: error: invalid suffix 'p' on integer constant
      assert(v == 0x125p-1);
      ^

They're disabled in C++0x mode because they conflict with user-defined
literals. We might be able to jump through some hoops to see if there's a
literal operator named "p" or "P" in scope, but... yuck.

Suggestions welcome!

I think that behavior is undefined for any program that uses a literal
suffix without a leading underscore, because those names are reserved for
use by a further Standard.

The *library* reserves those names, not the language. The language is perfectly happy to allow operator ""p, and that's where the conflict with C99 comes up.

Therefor, I think clang's lexer could just prefer lexing "0x123p4" as a
floating point literal and can issue a warning about declarations of names
such as 'operator "" p' ("warning: literal operator will never be used
implicitly" or some such).

Yes, of course we can do that. It's a hack that assumes that the user is going to use the standard library somewhere, and therefore falls under the rule that prohibits user-defined literal operators without a leading "_".

  - Doug

Douglas Gregor wrote:

Douglas Gregor wrote:

Can we turn on support for hexfloats in -std=c++0x? It is already
turned on in c++03 mode.

get_double.pass.cpp:108:14: error: invalid suffix 'p' on integer
constant
      assert(v == 0x125p-1);
      ^

They're disabled in C++0x mode because they conflict with user-defined
literals. We might be able to jump through some hoops to see if there's
a literal operator named "p" or "P" in scope, but... yuck.

Suggestions welcome!

I think that behavior is undefined for any program that uses a literal
suffix without a leading underscore, because those names are reserved for
use by a further Standard.

The *library* reserves those names, not the language. The language is
perfectly happy to allow operator ""p, and that's where the conflict with
C99 comes up.

Why does this only apply to programs that use the library and the following
does not? Clang rejects it, without the program using the standard library.

    int __clang__ = 0;

The restriction is also stated as a subclause of 17.6.3.1. Is the "always
reserved", which is used for reserving __foo and _Foo, intended to break out
of the implicit assumption governing all of 17.6.3.1 that says the
restrictions only apply to programs using the facilities of the standard
library?