4. Vorangestellte Underlines (__name)

Vorangestellte Underlines (__name)

  • R

    Doppelte Underlines und Underlines mit folgendem Großbuchstaben sind dem Compiler vorbehalten und darfst du selbst nicht nie niemals benutzen. So sollen Namens-Konflikte vermieden werden, zB für C-Lib interne Funktionen oder Erweiterungen im C-Standard (daher heißt der Bool-Typ in C auch _Bool und der Typ für komplexe Zahlen _Complex)

    0
  • P

    Also wenn ich das richtig verstehe, nehme ich solche Namensgebungen stillschweigend zur Kenntnis und verwende selbst nie Variablen- Namen mit vorangestellten Underlines.

    Du sagst, Underlines mit nachfolgedem Großbuchstaben sind für den Compiler reserviert, wie sieht es dann mit Kleinbuchstaben aus?

    Kann man allgemein sagen, dass das Underline- Zeichen in der C/C++ Syntax keine Bedeutung für den Programmierer hat, sondern eben nur für das Vermeiden von Namenskonflikten in Standard- Header Dateien Anwendung finden?

    0
  • K
     

    #ifndef __SCHWEINE_IM_WELTALL_H__
#define __SCHWEINE_IM_WELTALL_H__
void __SCHWEINE_IM_WELTALL__(void);
#endif /* __SCHWEINE_IM_WELTALL_H__ */
    0
  • P

    Ja richtig, in jeder Header Datei wird ja das Underline Zeichen verwendet:

    #ifndef _NAME_
#define _NAME_
.
.
.
#endif

    Was es hier mit den Underlines aufsich hat verstehe ich ebenfalls nicht. Dass es sich auch hier um Namenskonflikte handelt, kann ich mir nicht vorstellen.

    @keksekekse:
    Was du mir damit allerdings sagen wolltest hab ich nicht begriffen! 🙂

    Dabei fällt mir noch was auf: Du verwendest

    #define __SCHWEINE_IM_WELTALL_H__

    anstatt

    #define _SCHWEINE_IM_WELTALL_H_

    wie ich es schreiben würde in meiner Unwissenheit. Tust du das, um einen Unterschied zum einzelnen Underline im Namen zu erzeugen?
    Ist das so üblich oder reine Geschmacksache?

    0
  • C
    Mod

    edit:nt

    0
  • B

    Platon schrieb:

    Ja richtig, in jeder Header Datei wird ja das Underline Zeichen verwendet:

    #ifndef _NAME_
#define _NAME_
.
.
.
#endif

    Nicht ganz. In Standardheadern wird sowas gemacht, und in denen von Systemlibraries u.ä. In deinem eigenen Code solltest du das aus den genannten Gründen tunlichst unterlassen. Compiler- und Libraryimplementoren reißen sich ein Bein aus, damit es auch unter ungünstigen Umständen nicht zu Namenskollisionen kommt. Wenn du dir das zum Vorbild nimmst sabotierst du diese Anstrengungen. Für nichts.
    Ich gebe allerdings zu, dass es unwahrscheinlich ist, dass eine Standardlibrary den Bezeichner __SCHWEINE_IM_WELTALL__ intern verwendet, außer vielleicht es ist die KekseKekseWare-STL 🤡

    0
  • P

    Wenn das so ist werd ich mir deinen Ratschlag mal zu Herzen nehmen und ganz schnell alle Underlines aus meinen Header- Dateien entfernen!
    Hochoffiziell hatte ich ja selbstverständlich auch nie welche verwendet! ^^

    Auf __SCHWEINE_IM_WELTALL_H__ zu stoßen ist tatsächlich recht unwahrscheinlich, da geb ich Dir Recht! 🙂

    Da damit alle Fragen meinerseits geklärt sind bedanke ich mich bei allen Beteiligten, die mir so schnell und tatkräftig die Augen geöffnet haben!
    Lg und schönen Abend noch!

    0
  • S

    Es ist eigentlich niergends definiert, ob man __WASWEISSICH__ benutzen darf oder nicht, denn dem Compiler ist nur wichtig, dass Variablennamen nur alphanumerische Zeichen enthalten, Underscores, Zahlen und dass Variablennamen nicht mit einer Zahl anfangen. Wenn der Compiler aber 2 Variablen im selben Gültigkeitsbereich mit dem selben Namen sieht (oder bei Macros), dann wird er sich melden.

    Es gibt wie gesagt keine Vorschrift, sehr wohl Konventionen, die man ignorieren kann aber es nicht sollte.

    Du kannst natürlich Funktionen/Variablem mit doppelten __ benutzen. Im Linux Kernel sind z.b. Funktionen und Variablen mit __func_name, __var_name definiert und dort bedeutet es, dass man wirklich weiß, was diese Funktionen tun, bevor sie man einsetzt. Deswegen sieht man oft unter Linux keine Variablen/Funktionen, die mit __ anfangen, weil die Konvention besagt, dass solche __ dem Kernel vorbehalten sind. Aber keiner zwingt dich dazu, dich dran zu halten.

    Eine andere Konvention ist, dass man Makros immer groß schreibt. Ich habe sehr selten Makros klein geschrieben gesehen. Deswegen benutzen Programmierer keine Variablen/Funktionen mit __IRGENDWAS__, damit es nicht mit einem Makro verwechselt wird (vom Programmierer natürlich, dem Compiler ist das egal).

    Jedem ist es frei seine/ihre Variablen und Funktionen zu benennen, wie er/sie will. Man kann sogar komplett auf Buchstaben verzichten, wie folgendes Beispiel so schön demonstriert 😉

    #include <stdio.h>

/* gibt den eingegebenen Wert + 1 zurück */
int ___(int _){int __=_-_-_-_;__-=- --_;return -__;}

int main(void)
{
    int _=121, __IST_NICHT_RESERVIERT_SOLLTE_MAN_ABER_NICHT_BENUTZEN__ = 19;
    printf("foo(%d) = %d\n", _, ___(_));
}

    Aber außer in Obfuscated C Code oder im Obfuscated C Code Contest sieht man das nicht, weil die Lesbarkeit gegen 0 geht.

    0
  • P

    Danke auch für Deine Info! Das Funktionen und Variablen im Linux- Kernel mit doppeltem Underscore beginnen find ich sehr interessant! Garnicht dumm, spezielle Funktionen auf diese Weise hervorzuheben/ zu markieren!

    An die Konventionen möchte ich mich natürlich halten, nicht ohne Grund hat man eine bestimmte Schreibweise der Syntax vorgesehen, die für die (leichte) Lesbarkeit des Codes (Dein Beispiel demonstriert dies sehr anschaulich) zweifelsohne wichtig ist!

    supertux schrieb:

    #include <stdio.h>

/* gibt den eingegebenen Wert + 1 zurück */
int ___(int _){int __=_-_-_-_;__-=- --_;return -__;}

int main(void)
{
    int _=121, __IST_NICHT_RESERVIERT_SOLLTE_MAN_ABER_NICHT_BENUTZEN__ = 19;
    printf("foo(%d) = %d\n", _, ___(_));
}

    Zugegebenermaßen hab ich jetzt ne ganze Weile gebraucht um das zu entschlüsseln! 🙂

    0
  • R

    supertux schrieb:

    Es ist eigentlich niergends definiert, ob man __WASWEISSICH__ benutzen darf oder nicht

    DOCH! Im C Standard ist das definiert. Das hatte ich ja auch schon geschrieben! Wenn du mir nicht glauben willst, dann schnapp dir den ISO C Standard und lies dir Abschnitt 7.1.3 durch...

    0
  • B

    supertux schrieb:

    Es ist eigentlich niergends definiert, ob man __WASWEISSICH__ benutzen darf oder nicht

    Doch, im ANSI-C Standard 🙄

    Du kannst natürlich Funktionen/Variablem mit doppelten __ benutzen. Im Linux Kernel sind z.b. Funktionen und Variablen mit __func_name, __var_name definiert und dort bedeutet es, dass man wirklich weiß, was diese Funktionen tun, bevor sie man einsetzt.

    Der Linux-Kernel ist nicht in Standard-C geschrieben, sondern erstmal nur für den gcc. Es ist also ein leichtes, Kollisionen zu vermeiden. Vermutlich fließen auch Informationen zwischen den beiden Projekten hin und her.

    Deswegen sieht man oft unter Linux keine Variablen/Funktionen, die mit __ anfangen, weil die Konvention besagt, dass solche __ dem Kernel vorbehalten sind. Aber keiner zwingt dich dazu, dich dran zu halten.

    Der letzte Satz bringt deinen Denkfehler auf den Punkt. Es muss kein Zwang bestehen. Beispielsweise hindert dich niemand daran, die Adresse einer lokalen Variablen zurückzugeben und später damit noch zu arbeiten. Das geht eine Weile gut, vielleicht immer. Aber niemand garantiert, dass das immer funktioniert. Die Sache mit den Unterstrichen ist exakt das gleiche. Es funktioniert normalerweise, aber es ist nicht garantiert. Wenn dein Programm mit der nächsten Compilerversion nicht mehr läuft, hast du niemanden zum verklagen.

    0
  • S

    rüdiger schrieb:

    supertux schrieb:

    Es ist eigentlich niergends definiert, ob man __WASWEISSICH__ benutzen darf oder nicht

    DOCH! Im C Standard ist das definiert. Das hatte ich ja auch schon geschrieben! Wenn du mir nicht glauben willst, dann schnapp dir den ISO C Standard und lies dir Abschnitt 7.1.3 durch...

    Bashar schrieb:

    supertux schrieb:

    Es ist eigentlich niergends definiert, ob man __WASWEISSICH__ benutzen darf oder nicht

    Doch, im ANSI-C Standard 🙄

    Ich lasse mich immer eines besseres belehren, ich hätte nicht gedacht, dass das wirklich im ANSI Standard definiert wäre. Zu meiner Verteidigung muss ich sagen, dass ich keine Ahnung habe, wo ich mir den gesamten ISO C Standard nachschauen könnte 😉

    Bashar schrieb:

    Der letzte Satz bringt deinen Denkfehler auf den Punkt. Es muss kein Zwang bestehen. Beispielsweise hindert dich niemand daran, die Adresse einer lokalen Variablen zurückzugeben und später damit noch zu arbeiten. Das geht eine Weile gut, vielleicht immer. Aber niemand garantiert, dass das immer funktioniert. Die Sache mit den Unterstrichen ist exakt das gleiche. Es funktioniert normalerweise, aber es ist nicht garantiert. Wenn dein Programm mit der nächsten Compilerversion nicht mehr läuft, hast du niemanden zum verklagen.

    Du hast Recht, hab nicht dran gedacht. Da ich nur mit dem gcc arbeite, hatte ich damit nie Probleme.

    0
Anmelden zum Antworten