Was sind die Regeln über einen Unterstrich in einem C ++ Bezeichner verwenden?

https://stackoverflow.com/questions/228783

04-07-2019
|

Frage

Es ist üblich, in C ++ zu nennen Membervariablen mit irgendeiner Art von Präfix, die Tatsache zu bezeichnen, dass sie Membervariablen sind, eher als lokale Variablen oder Parameter. Wenn Sie von einem MFC-Hintergrund gekommen sind, werden Sie wahrscheinlich m_foo verwenden. Ich habe auch myFoo gelegentlich gesehen.

C # (oder möglicherweise nur .NET) scheint nur einen Unterstrich zu empfehlen, wie in _foo. Ist das erlaubt durch die C ++ Standard?

Lösung

Die Regeln (die nicht geändert wird in C ++ 11):

in jedem Bereich vorbehalten, auch für den Einsatz als Implementierung Makros:
- Bezeichner mit einem Unterstrich beginnen, unmittelbar gefolgt von einem Großbuchstaben
- Identifikatoren benachbarte Unterstrichen (oder "Doppelstrich")
in dem globalen Namensraum reserviert:
- Bezeichner mit einem Unterstrich beginnen
Auch alles im std Namensraum ist reserviert. (Sie dürfen Vorlage Spezialisierungen hinzufügen, though.)

Von 2003 C ++ Standard:

17.4.3.1.2 Globale Namen [lib.global.names]

Einige Sätze von Namen und Funktion Signaturen werden immer auf die Implementierung reserviert:


Jeder Name, der einen Doppelstrich (__) oder beginnt mit einem Unterstrich von einem Großbuchstaben gefolgt enthält (2,11) ist für jeden Einsatz zur Umsetzung vorbehalten.

Jeder Name, der mit einem Unterstrich beginnt im globalen Namespace als Name für die Verwendung bei der Umsetzung reserviert ist. ¹⁶⁵


¹⁶⁵⁾ Solche Namen sind auch im Namensraum ::std reserviert (17.4.3.1).

Da C ++ basiert auf dem C-Standard (1.1 / 2, C ++ 03) und C99 ist eine normative Referenz (1.2 / 1, C ++ 03) diese auch gelten, aus dem 1999 C Standard:

7.1.3 Reservierte Bezeichner

Jeder Header deklariert oder definiert alle Bezeichner in der zugehörigen Subklausel aufgeführt sind, und   optional deklariert oder definiert Bezeichner in dem zugehörigen zukünftigen Bibliothek Richtungen Subklausel und Kennungen aufgelistet, die immer entweder für die Nutzung oder zur Verwendung als Dateibereichskennungen reserviert ist.


Alle Bezeichner, die mit einem Unterstrich und entweder einem Großbuchstaben oder einem anderen beginnen   Strich ist für jeden Einsatz immer vorbehalten.

Alle Bezeichner, die mit einem Unterstrich beginnen immer reserviert für den Einsatz als Bezeichner   mit Dateigültigkeitsbereich sowohl in dem normalen und Tag-Namen Leerzeichen.

Jeder Makroname in einem der folgenden Unterabschnitten (einschließlich der künftigen Bibliothek   wie angegeben Richtung) ist für die Verwendung reserviert, wenn eine ihrer zugehörigen Header enthalten ist;   sofern nicht ausdrücklich anders angegeben (siehe 7.1.4).

Alle Bezeichner mit externer Bindung in einem der folgenden Unterabschnitten (einschließlich der   zukünftige Bibliothek Richtungen) sind immer für die Verwendung als Bezeichner mit externer vorbehalten   Verknüpfung. ¹⁵⁴

Jeder Bezeichner mit Rahmen-Datei in einem der folgenden Unterabschnitten aufgeführt (einschließlich der   zukünftige Bibliothek Richtungen) sind für den Einsatz als Makronamen reserviert und als Kennung mit   Datei Umfang im gleichen Namensraum, wenn einer ihrer zugehörigen Header enthalten ist.


Es wurden keine anderen Kennzeichen sind vorbehalten. Wenn das Programm erklärt oder definiert eine Kennung in einem   Kontext, in dem es (außer wie durch 7.1.4 erlaubt), oder definiert einen reservierten reserviert ist   Bezeichner als Makronamen, das Verhalten ist nicht definiert.

Wenn das Programm entfernt (mit #undef) jede Makrodefinition einer Kennung in der ersten   Gruppe über das Verhalten aufgeführt ist nicht definiert.

¹⁵⁴⁾ Die Liste der reservierten Bezeichner mit externer Bindung enthält errno, math_errhandling, setjmp und va_end.

Weitere Einschränkungen zutreffen könnten. Zum Beispiel behält sich die POSIX-Standard eine Menge von Kennungen, die in normalen Code wahrscheinlich zu zeigen, sind:

Namen mit einem Kapital E Beginn folgten eine Ziffer oder Großbuchstaben:
- kann für zusätzliche Fehlercodenamen verwendet werden.
Namen, die entweder mit is oder to gefolgt von einem Kleinbuchstaben beginnen
- kann für zusätzliche Zeichenprüfung und Konvertierungsfunktionen verwendet werden.
Namen, die mit LC_ beginnen mit einem Großbuchstaben gefolgt
- für zusätzliche Makros verwendet werden, die Angabe locale Attribute.
Namen aller vorhandenen Mathematik-Funktionen mit dem Suffix f oder l vorbehalten
- für Funktionen entsprechen, die auf Schwimmer und lange doppelte Argumente bedienen sind.
Namen, die mit SIG beginnen mit einem Großbuchstaben gefolgt sind reserviert
- für zusätzliche Signalnamen.
Namen, die mit SIG_ beginnen mit einem Großbuchstaben gefolgt sind reserviert
- für zusätzliche Signal Aktionen.
Namen mit str beginnen, mem oder wcs von einem Kleinbuchstaben gefolgt sind reserviert
- für zusätzliche Zeichenfolge und Array-Funktionen.
Namen mit PRI oder SCN von jedem Kleinbuchstaben oder X gefolgt beginnen, sind reserviert
- für weitere Formatbezeichner Makros
Namen, die mit _t Ende sind reserviert
- für zusätzliche Typnamen.

Während diese Namen für Ihre eigenen Zwecke verwenden könnte jetzt nicht ein Problem verursachen, haben sie die Möglichkeit von Konflikten mit zukünftigen Versionen dieses Standards erhöhen.

Ich persönlich fange einfach nicht Identifikatoren mit Unterstrichen. Neue zusätzlich zu meiner Regel:. Verdoppeln Unterstrichen nicht überall verwenden, die einfach ist, wie ich selten Strich verwenden

Nach forschen zu diesem Artikel ich meine Identifikatoren Ende nicht mehr mit _t wie dies durch den POSIX-Standard reserviert ist.

Die Regel über jede Kennung mit _t Endung hat mich sehr überrascht. Ich denke, das ist ein POSIX-Standard (noch nicht sicher), die nach Klärung und offiziellen Kapitel und Verse. Dies ist aus dem GNU libtool Handbuch , reservierte Namen listing .

CesarB vorgesehen, um den folgenden Link, um die POSIX 2004 reservierten Symbole und Notizen ‚dass viele andere Präfixe und Suffixe reserviert ... dort gefunden werden können.‘ Das POSIX 2008 reservierten Symbole sind hier definiert. Die Einschränkungen sind etwas differenzierter als die oben.

Andere Tipps

Die Regeln Kollision von Namen zu vermeiden, sind beide in der C ++ Standard (siehe Stroustrup Buch) und erwähnt von C ++ Gurus (Sutter, usw.).

Persönliche Regel

Weil ich nicht solche Fälle behandeln wollte, und wollte eine einfache Regel, habe ich entworfen, um ein persönliche ein, die sowohl einfach und korrekt ist:

: Wenn ein Symbol Benennung, werden Sie Kollision mit Compiler / O / Standard-Bibliotheken, wenn Sie vermeiden

nie ein Symbol mit einem Unterstrich beginnen

nie in ein Symbol mit zwei aufeinander folgenden Unterstrichen nennen.

Natürlich hilft der Code in einem eindeutigen Namespace setzen Kollision zu vermeiden, auch (aber schützt nicht vor bösen Makros)

Einige Beispiele

(I-Makros verwenden, da sie die mehr Code umwelt von C / C ++ Symbolen sind, aber es könnte alles von Variablennamen Klassennamen sein)

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

Auszüge aus C ++ 0x Entwurf

Von der n3242.pdf Datei (ich erwarte, dass Text der endgültige Standard ähnlich sein):

17.6.3.3.2 Globale Namen [global.names]

Einige Sätze von Namen und Funktion Signaturen werden immer auf die Implementierung reserviert:

-. Jeder Name, der einen Doppelstrich enthält _ _ oder beginnt mit einem Unterstrich von einem Großbuchstaben gefolgt (2,12) zur Umsetzung für die weitere Nutzung reserviert ist

-. Jeder Name, der mit einem Unterstrich beginnt für den Einsatz zur Umsetzung reserviert ist als Name im globalen Namespace

Aber auch:

17.6.3.3.5 Benutzerdefinierte wörtliche Suffixe [usrlit.suffix]

Wörtliche Suffix Kennungen, die mit einem Unterstrich beginnen nicht für zukünftige Standardisierung reserviert sind.

Diese letzte Klausel ist verwirrend, es sei denn, man bedenkt, dass ein Name mit einem Unterstrich beginnen und von einem Kleinbuchstaben gefolgt wäre OK, wenn nicht im globalen Namensraum definiert ...

MSDN :

Die Verwendung von zwei aufeinanderfolgenden Unterstriche (__) zu Beginn einer Kennung oder eines einzelnen führenden von einem Großbuchstaben gefolgt Strich, ist reserviert für C ++ Implementierungen in allen Bereichen. Sie sollten mit einem führenden vermeiden durch einen Kleinbuchstaben gefolgt Strich für Namen mit Dateiumfang wegen möglicher Konflikte mit aktuellen oder zukünftigen reservierte Bezeichner.

Das bedeutet, dass Sie einen einzelnen Strich als Membervariable Präfix verwenden können, solange sie von einem Kleinbuchstaben gefolgt wird.

Diese scheinbar aus dem Abschnitt 17.4.3.1.2 des C ++ Standard genommen wird, aber ich kann nicht eine Quelle für den vollen Standard online finden.

Siehe auch diese Frage .

Wie bei dem anderen Teil der Frage, ist es üblich, den Unterstrich am Ende der Variablennamen zu setzen, um nicht intern mit etwas zu kollidieren.

ich dies auch innerhalb von Klassen und Namespaces, weil ich dann nur eine Regel erinnern (im Vergleich zu „am Ende des Namens in der globalen Reichweite und den Anfang des Namens überall sonst“).

Ja, Unterstrichen kann überall in einer Kennung verwendet werden. Ich glaube, die Regeln sind:. Jeder von a-z, A-Z, _ in dem ersten Zeichen und diejenigen + 0-9 für folgende Zeichen

Unders Präfixe sind in C-Code gemeinsam - ein Unterstrich bedeutet „privaten“ und doppelten Unterstrichen werden in der Regel für die Verwendung durch den Compiler reserviert

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow