Jakie są zasady dotyczące używania podkreślenia w identyfikatorze C ++?

W C ++ powszechne jest nazywanie zmiennych składowych z pewnym prefiksem, który oznacza, że ​​są to zmienne składowe, a nie zmienne lokalne lub parametry. Jeśli pochodzisz z tła MFC, prawdopodobnie będziesz używać m_foo. Od myFooczasu do czasu widziałem .

Wydaje się, że C # (lub po prostu .NET) zaleca używanie tylko podkreślenia, jak w _foo. Czy jest to dozwolone przez standard C ++?

Reguły (które nie zmieniły się w C ++ 11):

• Zarezerwowane w dowolnym zakresie, w tym do wykorzystania jako makra implementacyjne :
  • identyfikatory zaczynające się od znaku podkreślenia, po którym bezpośrednio następuje wielka litera
  • identyfikatory zawierające sąsiadujące podkreślenia (lub „podwójne podkreślenie”)
• Zarezerwowane w globalnej przestrzeni nazw:
  • identyfikatory rozpoczynające się znakiem podkreślenia
• Ponadto wszystko w stdprzestrzeni nazw jest zarezerwowane. (Możesz jednak dodawać specjalizacje do szablonów).

Od standardu C ++ 2003:

17.4.3.1.2 Nazwy globalne [lib.global.names]

Niektóre zestawy nazw i sygnatur funkcji są zawsze zarezerwowane dla implementacji:

• Każda nazwa, która zawiera podwójny znak podkreślenia ( __) lub zaczyna się od znaku podkreślenia, po którym następuje wielka litera (2.11), jest zarezerwowana dla implementacji do dowolnego użytku.
• Każda nazwa rozpoczynająca się znakiem podkreślenia jest zarezerwowana dla implementacji i może być używana jako nazwa w globalnej przestrzeni nazw. ¹⁶⁵

¹⁶⁵⁾ Takie nazwy są również zastrzeżone w przestrzeni nazw ::std(17.4.3.1).

Ponieważ C ++ jest oparty na standardzie C (1.1 / 2, C ++ 03), a C99 jest odniesieniem normatywnym (1.2 / 1, C ++ 03), mają one również zastosowanie, od standardu C z 1999 roku:

7.1.3 Zastrzeżone identyfikatory

Każdy nagłówek deklaruje lub definiuje wszystkie identyfikatory wymienione w powiązanej podklasie i opcjonalnie deklaruje lub definiuje identyfikatory wymienione w powiązanej podklasie i identyfikatorach przyszłych bibliotek, które są zawsze zarezerwowane do dowolnego użytku lub do wykorzystania jako identyfikatory zakresu plików.

• Wszystkie identyfikatory rozpoczynające się znakiem podkreślenia i wielką literą lub innym znakiem podkreślenia są zawsze zarezerwowane do dowolnego użytku.
• Wszystkie identyfikatory rozpoczynające się znakiem podkreślenia są zawsze zarezerwowane do stosowania jako identyfikatory o zakresie pliku zarówno w zwykłej, jak i w przestrzeni nazw.
• Każda nazwa makra w dowolnym z poniższych podrozdziałów (łącznie z przyszłymi kierunkami biblioteki) jest zarezerwowana do użytku, tak jak określono, jeśli uwzględniono którykolwiek z powiązanych z nią nagłówków; chyba że wyraźnie zaznaczono inaczej (patrz 7.1.4).
• Wszystkie identyfikatory z zewnętrznym powiązaniem w dowolnym z poniższych podrozdziałów (w tym przyszłe kierunki bibliotek) są zawsze zarezerwowane do użycia jako identyfikatory z zewnętrznym łączeniem. ¹⁵⁴
• Każdy identyfikator z zakresem pliku wymienionym w którejkolwiek z poniższych podklas (w tym przyszłe kierunki bibliotek) jest zarezerwowany do użycia jako nazwa makra i jako identyfikator z zakresem pliku w tej samej przestrzeni nazw, jeśli uwzględniono którykolwiek z powiązanych z nim nagłówków.

Żadne inne identyfikatory nie są zastrzeżone. Jeśli program deklaruje lub definiuje identyfikator w kontekście, w którym jest zarezerwowany (inny niż dozwolony w 7.1.4), lub definiuje zastrzeżony identyfikator jako nazwę makra, zachowanie jest niezdefiniowane.

Jeśli program usunie (z #undef) dowolną definicją makra identyfikatora w pierwszej grupie wymienionej powyżej, zachowanie jest niezdefiniowane.

¹⁵⁴⁾ Lista zarezerwowanych identyfikatorów z zewnętrznym wiązaniem obejmuje errno, math_errhandling, setjmp, i va_end.

Mogą obowiązywać inne ograniczenia. Na przykład standard POSIX rezerwuje wiele identyfikatorów, które prawdopodobnie pojawią się w normalnym kodzie:

• Nazwy rozpoczynające się od dużej Elitery następują po cyfrach lub wielkich literach:
  • może być użyty do dodatkowych nazw kodów błędów.
• Nazwy, które zaczynają się na jedną islub tonastępują po niej małą literą
  • może być wykorzystywany do dodatkowych funkcji testowania znaków i konwersji.
• Nazwy rozpoczynające się od, LC_po których następuje wielka litera
  • może być użyty do dodatkowych makr określających atrybuty ustawień regionalnych.
• Nazwy wszystkich istniejących funkcji matematycznych z przyrostkiem flub lsą zastrzeżone
  • dla odpowiednich funkcji, które działają odpowiednio na liczbach zmiennoprzecinkowych i długich podwójnych argumentach.
• Nazwy zaczynające się SIGod dużej litery są zastrzeżone
  • dla dodatkowych nazw sygnałów.
• Nazwy zaczynające się SIG_od dużej litery są zastrzeżone
  • dla dodatkowych akcji sygnalizacyjnych.
• Nazwy rozpoczynające się od str, memlub wcspoprzedzające małą literę są zastrzeżone
  • dla dodatkowych funkcji łańcuchowych i tablicowych.
• Nazwy rozpoczynające się od PRIlub SCNpo każdej małej litery lub Xsą zastrzeżone
  • dla makr dodatkowego specyfikatora formatu
• Nazwy kończące się _tsą zastrzeżone
  • dla dodatkowych nazw typów.

Mimo że używanie tych nazw do własnych celów może nie powodować problemów, zwiększają one możliwość konfliktu z przyszłymi wersjami tego standardu.

Osobiście nie zaczynam identyfikatorów od podkreślników. Nowy dodatek do mojej zasady: nie używaj nigdzie podwójnych znaków podkreślenia, co jest łatwe, ponieważ rzadko używam podkreślenia.

Po przestudiowaniu tego artykułu nie kończę już moich identyfikatorów, _t ponieważ jest to zastrzeżone przez standard POSIX.

Zasada o każdym identyfikatorze kończącym się na _tbardzo mnie zaskoczyła. Myślę, że to standard POSIX (jeszcze nie jestem pewien) szukający wyjaśnień i oficjalnego rozdziału i wersetu. Ten pochodzi z GNU Libtool ręcznych , wymieniające zastrzeżonych nazw.

CesarB podał następujący link do zastrzeżonych symboli POSIX 2004 i zauważa, że ​​„można tam znaleźć wiele innych zastrzeżonych prefiksów i sufiksów”. Tutaj są zdefiniowane symbole zastrzeżone POSIX 2008 . Ograniczenia są nieco bardziej szczegółowe niż powyższe.

Zasady unikania kolizji nazw znajdują się zarówno w standardzie C ++ (patrz książka Stroustrupa), jak i wspomniane przez guru C ++ (Sutter itp.).

Reguła osobista

Ponieważ nie chciałem zajmować się sprawami i chciałem prostej zasady, zaprojektowałem osobistą, która jest jednocześnie prosta i poprawna:

Podczas nazywania symbolu unikniesz kolizji z bibliotekami kompilatora / systemu operacyjnego / standardowego, jeśli:

• nigdy nie rozpoczynaj symbolu znakiem podkreślenia
• nigdy nie wymieniaj symbolu z dwoma kolejnymi podkreśleniami w środku.

Oczywiście umieszczenie kodu w unikalnej przestrzeni nazw pomaga również uniknąć kolizji (ale nie chroni przed złymi makrami)

Kilka przykładów

(Używam makr, ponieważ bardziej zanieczyszczają kod symboli C / C ++, ale może to być wszystko od nazwy zmiennej do nazwy klasy)

#define _WRONG
#define __WRONG_AGAIN
#define RIGHT_
#define WRONG__WRONG
#define RIGHT_RIGHT
#define RIGHT_x_RIGHT

Wyciągi z wersji roboczej C ++ 0x

Z pliku n3242.pdf (oczekuję, że końcowy standardowy tekst będzie podobny):

17.6.3.3.2 Nazwy globalne [global.names]

Niektóre zestawy nazw i sygnatur funkcji są zawsze zarezerwowane dla implementacji:

- Każda nazwa, która zawiera podwójny znak podkreślenia _ _ lub zaczyna się znakiem podkreślenia, po którym następuje wielka litera (2.12), jest zarezerwowana dla implementacji do dowolnego użytku.

- Każda nazwa rozpoczynająca się znakiem podkreślenia jest zarezerwowana dla implementacji i może być używana jako nazwa w globalnej przestrzeni nazw.

Ale również:

17.6.3.3.5 Sufiksy literału zdefiniowane przez użytkownika [usrlit.suffix]

Dosłowne identyfikatory sufiksów, które nie zaczynają się od znaku podkreślenia są zarezerwowane do przyszłej standaryzacji.

Ta ostatnia klauzula jest myląca, chyba że weźmiesz pod uwagę, że nazwa zaczynająca się od jednego znaku podkreślenia, po której następuje mała litera, byłaby OK, gdyby nie została zdefiniowana w globalnej przestrzeni nazw ...

Z MSDN :

Użycie dwóch sekwencyjnych znaków podkreślenia (__) na początku identyfikatora lub pojedynczego wiodącego znaku podkreślenia, po którym następuje wielka litera, jest zarezerwowane dla implementacji C ++ we wszystkich zakresach. Należy unikać używania jednego wiodącego znaku podkreślenia, po którym następuje mała litera dla nazw z zakresem pliku, ze względu na możliwe konflikty z bieżącymi lub przyszłymi zastrzeżonymi identyfikatorami.

Oznacza to, że możesz użyć pojedynczego podkreślenia jako prefiksu zmiennej składowej, o ile po nim następuje mała litera.

Jest to najwyraźniej zaczerpnięte z sekcji 17.4.3.1.2 standardu C ++, ale nie mogę znaleźć oryginalnego źródła pełnego standardu online.

Zobacz także to pytanie .

Jeśli chodzi o drugą część pytania, często umieszcza się podkreślenie na końcu nazwy zmiennej, aby nie kolidowało z niczym wewnętrznym.

Robię to nawet w klasach i przestrzeniach nazw, ponieważ muszę wtedy zapamiętać tylko jedną regułę (w porównaniu do „na końcu nazwy w zakresie globalnym i na początku nazwy wszędzie indziej”).

Tak, podkreślenia mogą być używane w dowolnym miejscu w identyfikatorze. Uważam, że są to następujące reguły: dowolne z az, AZ, _ w pierwszym znaku i te + 0-9 dla następujących znaków.

Prefiksy podkreślenia są powszechne w kodzie C - pojedynczy znak podkreślenia oznacza „prywatny”, a podwójne podkreślenia są zwykle zarezerwowane do użytku przez kompilator.