10

According to cppreference it is possible to define a literal using

CSomeClass operator ""s(const char* literal, size_t size);

Now after reading the paragraph I think it should be also possible to define

CSomeClass operator ""r(const char* literal, size_t size);

(note the r ud-suffix instead of s)

Overloading s just gives the clang warning

warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]

which I can't really understand as I'm compiling with -std=c++14. Overloading r gives

error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
warning: user-defined literal suffixes not starting with '_' are reserved; no literal will invoke this operator [-Wuser-defined-literals]

which seems even less accountable to me.

Why does clang emit these warnings/errors and how can I make the r ud-suffix valid.

Uroc327
  • 1,379
  • 2
  • 10
  • 28
  • 1
    What part of the warning don't you understand? It says your literal has to start with `_`. The reference you link to says the same. You can't declare one called `r`, but you can declare one called `_r`. – Mike Seymour Mar 12 '15 at 18:20
  • Reading the reference I understood that since c++14 one can overload without the underscore. – Uroc327 Mar 12 '15 at 18:25
  • OK, I can see how the wording of that reference might imply that the restriction only applied to the form with a space, not the new C++14 form. The standard's quite clear though: "Literal suffix identifiers that do not start with an underscore are reserved for future standardization." – Mike Seymour Mar 12 '15 at 18:33
  • 3
    @Mike Seymour cppreference edited to stress that point – Cubbi Mar 12 '15 at 18:53
  • Are you compiling `s` with C++14 and `r` with C++11? I guess I'm confused about the warning on one and the error on the other. I do remember at one point the "" and the identifier were required to touch with no intervening space. Then it was relaxed. I can't remember if that was C++14 or a DR on C++11.. I'll check but I'm pretty sure his was a DR against C++11. – emsr Mar 13 '15 at 12:22
  • There is something - and this gets back to why the lack of `_` is discouraged for user-space code. An implementation (and the standard) is allowed to use suffixes without an underscore. Such a suffix, say `r`, will shadow the literal operator for that same suffix defined by the user. Does anyone know if clang or libc uses `r`? That would do it. – emsr Mar 13 '15 at 12:26
  • @emsr nope, both are compiled in c++14 mode – Uroc327 Mar 13 '15 at 12:32

1 Answers1

13

User-defined literals must begin with the underscore _: the suffixes that do not begin with the underscore are reserved for the literal operators provided by the standard library.

orlp
  • 112,504
  • 36
  • 218
  • 315
  • Hm ok.. Where does it actually say that the second alternative (marked with `since C++14`) is reserved for the standard library (be it on the site or in the standard)? – Uroc327 Mar 12 '15 at 18:24
  • 2
    @Uroc327 In the definition for `ud-suffix`. – orlp Mar 12 '15 at 18:27
  • 2
    In the event that future C++ adds a e.g. a "qqz" literal suffix with some meaning, is it intended that programmers using today's compilers should be allowed to write code which, when run on a compiler without "qqz", would define "qqz" in the same fashion as the future standard does? – supercat May 02 '15 at 16:24