16
void operator"" test( const char* str, size_t sz  )
{
    std::cout<<str<<" world";
}

int main()
{
    "hello"test;
    return 0;
}

In GCC 4.7, this generates "warning: literal operator suffixes not preceded by '_' are reserved for future standardization [enabled by default]"

I understand why this warning is generated, but GCC says "enabled by default".

Is it possible to disable this warning without just disabling all warnings via the -w flag?

cmeub
  • 497
  • 2
  • 11
  • 4
    Wow, I din't know that C++11 supports overloading [operator ""](http://ideone.com/ZDyCML). By the way the g++ present in ideone at least doesn't warn, but my local compiler does. Just for other's info (who don't know the context), by changing `test` to `_test` the warning goes away. – iammilind Mar 12 '13 at 07:05
  • 12
    Why do you want to? There's every chance that later C++ versions will include potentially conflicting symbols. That's *bad*. GCC's problem is that it isn't giving you an *error* the way it should. – Nicol Bolas Mar 12 '13 at 07:09
  • 1
    @Nicol, appreciate your comment and this warning does indeed result in an error for me because I use -Werror. We have many valuable warnings in GCC yet we still let the programmer disable them explicitly. – cmeub Mar 12 '13 at 07:26
  • 5
    @cmeub: But that's my point: it's not *supposed* to be a warning. It's supposed to be an error. It is ill-formed according to the C++11 standard for the user to define a user-defined literal that doesn't begin with `_`. GCC *shouldn't* let you turn it off, just like it shouldn't let you turn off r-value references, variadic templates, or any other individual C++11 feature. Be glad it lets you turn off exceptions and RTTI. – Nicol Bolas Mar 12 '13 at 07:58
  • 2
    Out of curiosity, could you please explain _why_ you absolutely need to use user defined literals without an underscore? – Piotr99 Mar 12 '13 at 12:44
  • 1
    The actual answer is [**here**](http://stackoverflow.com/questions/21227071/disable-gcc-warning-about-underscore-prefixed-user-defined-literals) and can be combined with [pragma](http://stackoverflow.com/questions/3378560/how-to-disable-gcc-warnings-for-a-few-lines-of-code). It is a bad idea to do it in the context of above question, but I found this question because of the title (I was actually trying to get C++14 functionality - `""s` - to my own namespace in C++11 code). – firda Sep 15 '14 at 12:40

2 Answers2

6

After reading several comments to this question, I reviewed the C++ 11 Standard (non-final draft N3337).

When I said "I understand why this warning is generated" I was mistaken. I assumed that an underscore was not technically required by the standard, but just a recommendation (hence the warning rather than an error).

But as Nicol Bolas has brought up, the standard uses the following language when speaking about user defined literals:

"Literal suffix identifiers that do not start with an underscore are reserved for future standardization." usrlit.suffix

"Some literal suffix identifiers are reserved for future standardization; see [usrlit.suffix]. A declaration whose literal-operator-id uses such a literal suffix identifier is ill-formed, no diagnostic required." over.literal

This is similar to the language used for reserved identifiers and the "alternative representations" such as "and", "or", "not". I think this makes it pretty clear that this shouldn't actually be a warning in the first place, but an error.

This may not be the direct answer to the question of "is it possible to disable", but it is answer enough for me.

Community
  • 1
  • 1
cmeub
  • 497
  • 2
  • 11
1

For what it is worth, -Wno-literal-suffix silences this warning since gcc-7 (see here live on godbold), i.e. this option also turns off warnings for user defined literal operators without leading underscore:

-Wliteral-suffix (C++ and Objective-C++ only)

...

Additionally, warn when a user-defined literal operator is declared with a literal suffix identifier that doesn’t begin with an underscore. Literal suffix identifiers that don’t begin with an underscore are reserved for future standardization.

However, one should stick to the advice in @cmeub's answer and rather avoid using literal suffix identifiers without underscore, as it leads to ill formed programs.

ead
  • 32,758
  • 6
  • 90
  • 153