At [over.literal] I read, in the list of examples, that
double operator""_Bq(long double);
is valid, whereas
double operator"" _Bq(long double);
is ill-formed, which is apparently a consequence of the space right after "".
Now, from the linked page, I can easily get to [usrlit.suffix] with one click and I read that
Literal suffix identifiers that do not start with an underscore are reserved for future standardization.
Good, but where do I read why operator"" _Bq is invalid?
I've also read the description of user-defined-string-literal on cppreference, but to be honest I've found it a bit confusing.
Can anybody break that down with examples?
"" _Bq is a string-literal followed by an identifier, whereas ""_Bq is a user-defined-string-literal which is a single, distinct preprocessing token ([lex.pptoken]).
As a consequence, the former is affected by macro expansion, but the latter is not:
#define _x
int operator "" _x(char); // becomes `int operator "" (char);` which is invalid
int operator ""_x(char); // ok
That aside, both forms are allowed as part of a literal-operator-id and have the same meaning. However, since forming the first construct involves the use of a reserved identifier, it is ill-formed with no diagnostic required per [lex.name]/3 (motivation for this being that _Bq could be in use by the implementation as a macro).
That's the intent, anyway. The current normative wording does not actually make that difference clear enough: user-defined-string-literal ultimately contains an identifier, and [lex.name]/3 has no indication that it only applies to identifiers that are themselves preprocessing tokens. This is the subject of CWG2521.
Related
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?
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.
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.
My question regarding underscores in names is partly answered here, but either the answer is incomplete or I do not fully understand it.
Sect. 2.14.8.7 of the C++11 standard declares this literal operator as an example:
long double operator "" _w(long double);
Besides declaring the operator, the standard and its example do two further things that, if viewed separately, each make sense:
it begins the name _w with an underscore; and
it puts the operator in the global namespace.
My question has two parts:
According to the answer linked above, the name _w is not an identifier, or the identifier _w is not a name, or ... well, I'm confused.
If _w is okay, then is the capitalized _W okay, too -- as in 60.0_W, meaning 60.0 watts? Or is the preprocessor likely to mishandle the capitalized version?
Undoubtedly like you, I am not in the habit of starting global names with underscores, a habit the standard's sect. 17.6.4.3.2.1 explicitly seems to deprecate. Therefore, if you can cast some additional light on the matter of underscores, names and literal operators, the light would be appreciated.
Alright, I checked back with Richard Smith from the Clang team, and the _W part in your literal operator is indeed not a reserved identifier and/or name and it is also a seperate preprocessor token which will get expanded if it names a macro. This is in accordance with the standard subclauses 2.5, where an identifier is a preprocessor-token, and 2.2 which has macro expansion as part of phase 4, before preprocessor-tokens are replaced with just tokens of the language grammar, which happens in phase 7.
He also mentioned that, since the Portland meeting of the committee, you can say operator""_W, which will prevent macro expansion, since the _W is not a single identifier anymore. Clang trunk already implements this and compiles the following snippet:
#define _W _x
int operator""_W(unsigned long long){ return 42; }
int main(){
int i = 1337_W;
}
What is the meaning of "qualifier" and the difference between "qualifier" and "keyword"?
For the volatile qualifier in C and we can say that volatile is a keyword, so what is the meaning of "qualifier"?
A qualifier adds an extra "quality", such as specifying volatility or constness of a variable. They're similar to adjectives: "a fickle man", "a volatile int", "an incorruptible lady", "a const double". With or without a qualifier, the variable itself still occupies the same amount of memory, and each bit has the same interpretation or contribution to the state/value. Qualifiers just specify something about how it may be accessed or where it is stored.
keywords are predefined reserved identifiers (arguably, see below) that the language itself assigns some meaning to, rather than leaving free for you to use for your own purposes (i.e. naming your variables, types, namespaces, functions...).
Examples
volatile and const are both qualifiers and keywords
if, class, namespace are keywords but not qualifiers
std, main, iostream, x, my_counter are all identifiers but neither keywords nor qualifiers
There's a full list of keywords at http://www.cppreference.com/wiki/keywords/start. C++ doesn't currently have any qualifiers that aren't keywords (i.e. they're all "words" rather than some punctuation symbols).
Where do qualifiers appear relative to other type information?
A quick aside from "what does qualifier mean" into the syntax of using a qualifier - as Zaibis comments below:
...[qualifiers] only qualify what follows [when] there is nothing preceding. so if you want a const pointer to non-const object you had to write char * const var...
A bit (lot?) about identifiers
identifiers themselves are lexical tokens (distinct parts of the C++ source code) that:
begin with a alpha/letter character or underscore
continue with 0 or more alphanumerics or underscores
If it helps, you can think of identifiers as specified by the regexp "[A-Za-z_][A-Za-z_0-9]*". Examples are "egg", "string", "__f", "x0" but not "4e4" (a double literal), "0x0a" (that's a hex literal), "(f)" (that's three lexical tokens, the middle being the identifier "f").
But are keywords identifiers?
For C++, the terminology isn't used consistently. In general computing usage, keywords are a subset of identifiers, and some places/uses in the C++11 Standard clearly reflect that:
"The identifiers shown in Table 4 are reserved for use as keywords" (first sentence in 2.12 Keywords)
"Identifiers that are keywords or operators in C++..." (from 17.6.1.2 footnote 7)
(There are alternative forms of some operators - not, and, xor, or - though annoyingly Visual C++ disables them by default to avoid breaking old code that used them but not as operators.)
As Potatoswatter points out in a comment, in many other places the Standard defines lexical tokens identifier and keyword as mutually exclusive tokens in the Grammar:
"There are five kinds of tokens: identifiers, keywords, ..." (2.7 Tokens)
There's also an edge case where the determination's context sensitive:
If a keyword (2.12) or an alternative token (2.6) that satisfies the syntactic requirements of an identifier (2.11) is contained in an attribute-token, it is considered an identifier. (7.6.1. Attribute Syntax and Semantics 2)
Non-keyword identifiers you still shouldn't use
Some identifiers, like "std" or "string", have a specific usage specified in the C++ Standard - they are not keywords though. Generally, the compiler itself doesn't treat them any differently to your own code, and if you don't include any Standard-specified headers then the compiler probably won't even know about the Standard-mandated use of "std". You might be able to create your own function, variable or type called "std". Not a good idea though... while it's nice to understand the general division between keywords and the Standard library, implementations have freedom to blur the boundaries so you should just assume C++ features work when relevant headers are included and your usage matches documentation, and not do anything that might conflict.
#define LINK_ENTITY_TO_CLASS(mapClassName,DLLClassName) \
static CEntityFactory<DLLClassName> mapClassName( #mapClassName );
This is a macro from the Alien Swarm mod for Half-Life 2, meant to be compiled with MSVC.
I've never seen an argument preceded by a # in a macro before, and I'm not sure if this is a MSVC specific thing or just uncommon. What does it mean?
This is part of both standard C and C++ and is not implementation-specific. The # preprocessing operator stringizes its argument. It takes whatever tokens were passed into the macro for the parameter designated by its operand (in this case, the parameter mapClassName) and makes a string literal out of them. So, for a simple example,
#define STRINGIZE(x) # x
STRINGIZE(Hello World)
// gets replaced with
"Hello World"
Note that the argument tokens are not macro replaced before they are stringized, so if Hello or World were defined as a macro, the result would still be the same. You need to use an extra level of indirection to get the arguments macro replaced (that linked answer discusses the concatenation operator, ##, but applies equally to the stringization operator.
I was looking through the DXUTCore project that comes with the DirectX March 2009 SDK, and noticed that instead of making normal accessor methods, they used macros to create the generic accessors, similar to the following:
#define GET_ACCESSOR( x, y ) inline x Get##y() { DXUTLock l; return m_state.m_##y;};
...
GET_ACCESSOR( WCHAR*, WindowTitle );
It seems that the ## operator just inserts the text from the second argument into the macro to create a function operating on a variable using that text. Is this something that is standard in C++ (i.e. not Microsoft specific)? Is its use considered good practice? And, what is that operator called?
Token-pasting operator, used by the pre-processor to join two tokens into a single token.
This is also standard C++, contrary to what Raldolpho stated.
Here is the relevant information:
16.3.3 The ## operator [cpp.concat]
1 A ## preprocessing token shall not
occur at the beginning or at the end
of a replacement list for either form
of macro definition.
2 If, in the
replacement list, a parameter is
immediately preceded or followed by a
## preprocessing token, the parameter is replaced by the corresponding
argument’s preprocessing token
sequence.
3 For both object-like and
function-like macro invocations,
before the replacement list is
reexamined for more macro names to
replace, each instance of a ##
preprocessing token in the replacement
list (not from an argument) is deleted
and the preceding preprocessing token
is concatenated with the following
preprocessing token. If the result is
not a valid preprocessing token, the
behavior is undefined. The resulting
token is available for further macro
replacement. The order of evaluation
of ## operators is unspecified.
It's a preprocessing operator that concatenates left and right operands (without inserting whitespace). I don't think it's Microsoft specific.
This isn't Standard C++, it's Standard C. Check out this Wikipedia article.
And is it a good practice? In general, I hate pre-processor macros and think they're as bad as (if not worse than) Goto.
Edit: Apparently I'm being misunderstood by what I meant by "This isn't Standard C++, it's Standard C". Many people are reading the first phrase and failing to read the second. My intent is to point out that macros were inherited by C++ from C.
As Mehrdad said, it concatenates the operands, like:
#define MyMacro(A,B) A ## B
MyMacro(XYZ, 123) // Equivalent to XYZ123
Note that MISRA C suggests that this operand (and the # 'stringify' operand) should not be used due to the compiler dependent order of calculation.
It is token pasting operator allowed by Standard C++ (see 16.3.3 for details).
As for good practice: using macro is not a good practice IMHO (in C++).
it's the concatenation for macro arguments i.e.
GET_ACCESSOR (int, Age);
will be expended to
inline int GetAge() { DXUTLock l; return m_state.m_Age;};