26

With gcc 4.7.2 this compiles just fine for me:

int main()
{
  int _ = 1;
  return 0;
}

Can I expect this to compile in general? I've read the answers about underscores as prefixes. But what if the underscore isn't prefixing anything?

Community
  • 1
  • 1
Alec Jacobson
  • 6,032
  • 5
  • 51
  • 88

6 Answers6

22

Yes, from The C++ Programming Language, 4th Edition:

A name (identifier) consists of a sequence of letters and digits. The first character must be a letter. The underscore character, _, is considered a letter.

BeeOnRope
  • 60,350
  • 16
  • 207
  • 386
Rag
  • 6,405
  • 2
  • 31
  • 38
16

According to Stroustrup (3rd edition, section 4.9.3), an identifier consists of a sequence of letters and digits. The first character must be a letter. The underscore character is considered a letter.

So, yes, it should be portable.

Wayne McGee
  • 345
  • 1
  • 7
13

Yes, _ is a valid identifier, since it meets the syntax requirements. Basically, an identifier consists of an underscore or letter, followed by zero or more other characters that can be underscores, letters or digits. (As of C++ 2011, identifiers can also contain universal character names and other implementation-defined characters, but that's not relevant to your question.)

But it's probably not one that you should use in your own code, unless you're very careful.

As this answer says, quoting the 2003 C++ standard:

Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

Your _ variable isn't in the global namespace, so you're safe in this case, but it's a good idea to avoid defining any identifiers starting with an underscore.

Also, I believe GNU gettext (which provides support for localized messages) uses the name _ for its own purposes. (It was arguably a bad idea for GNU gettext do to this, but it was a convenient choice.)

Community
  • 1
  • 1
Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
  • Doesn't this (GNU gettext convention) conflict with C++ naming rules? I read that global names *beginning* with an underscore are forbidden? – Wolf Jan 12 '16 at 15:16
  • 1
    @Wolf: They're not exactly *forbidden*, but they're reserved. Yes, I believe gettext's use of `_` violates both C and C++ requirements -- but as long as the implementation doesn't actually use `_`, it's not likely to cause actual problems. – Keith Thompson Jan 12 '16 at 16:28
3

Yes. a single _ will be accepted as variable or any identifier/namespace name! E.g. google mock uses this.

underscore_d
  • 6,309
  • 3
  • 38
  • 64
πάντα ῥεῖ
  • 1
  • 13
  • 116
  • 190
0

Yeah it's a valid prefix. Running

#include <iostream>

using namespace std;

int main()
{
char* _ = "Hello World";
cout << _ << endl; 
return 0;
}

prints out "Hello World" as expected. It's not a very helpful varible name but it is valid

user2573153
  • 254
  • 2
  • 14
  • 10
    Compiling or running it does not ensure standards-compliance or portability. – Wayne McGee Sep 05 '13 at 22:46
  • 1
    @WayneMcGee: Unless you either have access to LOTS of compilers [although it is likely to either fail or succeed in some compiler when the opposite should happen], or ask the compiler to be strict about standards [and again, strictness may be subject to compiler bugs]. – Mats Petersson Sep 05 '13 at 23:37
0

But why having this weird name '_' for a variable? Does it mean you do not want no one access it again or something? Saw code looks like:

for (auto _ : <range based container>) {
    // some code that does not use '_' at all
}
Qqwy
  • 5,214
  • 5
  • 42
  • 83
  • 1
    (this is probably better as a "comment" than an "answer"; to reduce risk of downvotes). I sometimes use `_` to indicate output arguments that I don't intend to use. `string first_name; {string _; get_first_and_last_name(first_name,_); } ` – Alec Jacobson Jan 05 '21 at 22:12
  • 1
    It's a python convention. – tejasvi88 Dec 19 '21 at 10:38
  • It can be used to emulate Pascal's "with" syntax (see for example https://stackoverflow.com/a/28645309/1945549). – Roland Sarrazin May 31 '23 at 10:24