Ich sehe immer wieder Code von Leuten, die ihre Variablen mit dem "_" versehen.
Hat das irgendeine weitere Bedeutung?

Die warscheinlich ausführlichste Antwort der Welt...
hast du vielleicht ein paar mehr Infos?

EDIT:
Ok. Wiklet war da ausführlicher, weiß jetzt worum es geht.

class Bla
{
    private:
                int _bla;    //<--- Membervariable

    public:
                int bla_again;  //<--- keine Membervariable
};

Den Unterstrich setzen aber die Meisten tatsächlich für private Member, manche an den Anfang, manche ans Ende.

Den Unterstrich setzen aber die Meisten tatsächlich für private Member, manche an den Anfang, manche ans Ende.

Wenn Du schon Unterstriche machen willst, folge Herb Sutter: http://de.wikipedia.org/wiki/Herb_Sutter
http://www.gotw.ca/gotw/004.htm

class Complex {
    public:
        Complex( double real, double imaginary = 0 )
          : _real(real), _imaginary(imaginary) {};

        void operator+ ( Complex other ) {
            _real = _real + other._real;
            _imaginary = _imaginary + other._imaginary;
        }

        void operator<<( ostream os ) {
            os << "(" << _real << "," << _imaginary << ")";
        }
        //...

In den MFC wurde m_BlaBla verwendet. Herb Sutter hat einfach das m (für "member") entfallen lassen.

Den Unterstrich setzen aber die Meisten tatsächlich für private Member, manche an den Anfang, manche ans Ende.

Wenn Du schon Unterstriche machen willst, folge Herb Sutter

Wieso sollte ich?
Jeder möge das machen, was er für hübsch hält (solange es standardkonform ist). Das ist eh ein Implementierungsdetail, dass die meisten Leute einen feuchten Kericht angeht.

Nebenbei, schau dir mal in dem gotw-Link Punkt 11 an

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

Style: Try to avoid names with leading underscores. Yes, I've habitually used them, and yes, popular books like "Design Patterns" (Gamma et al) do use it... but the standard reserves some leading-underscore identifiers for the implementation and the rules are hard enough to remember (for you and for compiler writers!) that you might as well avoid this in new code. (Since I'm no longer allowed to use leading underscores as my "member variable" tag, I'll now use trailing underscores!)

That's it. Here's a corrected version of the program, ignoring design and style issues not explicitly noted above:

Also da haben wir nun die ganze Entwicklung:
m_blaBla => _blaBla => blaBla_ :D:D:D

class Complex {
    public:
        explicit Complex( double real, double imaginary = 0 )
          : real_(real), imaginary_(imaginary) {}

        Complex& operator+=( const Complex& other ) {
            real_ += other.real_;
            imaginary_ += other.imaginary_;
            return *this;
        }
//...

class foobar{
public: //ctor
foobar();

public: //methods
type const& get_st() const;
void fu();

private:
// !!!
type foo_;
type bar_;
};

der underscore ist hinten, da es sich besser läst

17.4.3.1.2 Global names schrieb:

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

Ein Member ist ganz offensichtlich niemals Teil des globalen Namensraumes.

princess schrieb:

also ich hab mir heut ma das style guide von der uni reingezogen und "guter/sauberer/ code sieht bei membern so aus:
...
der underscore ist hinten, da es sich besser läst

Immer dieser definitive Kram. Zweimal in Folge public: zu schreiben ist z.B. einfach Unfug.

Benutz' btw. mal cpp-Tags, dafür sind sie da.

der underscore ist hinten, da es sich besser läst

Passt doch zum aktuellen C++-Standard und dem diesbezüglichen Ausweichmanöver von Herb Sutter.

Konsequent wäre nun folgende Weiterentwicklung:
m_blaBla => _blaBla => blaBla_ => blaBla_m :D:D:D:D

also ich hab mir heut ma das style guide von der uni reingezogen und "guter/sauberer/ code sieht bei membern so aus:

Aber nur laut deiner Uni. Es gibt hier mehrere Geschmäcker, ich lehne z.B. jegliche Unterstriche in Variablennamen ab und ergänze Membervariablen auch nicht um irgendwelche Kürzel etc. (Wenn man die Unterscheidung braucht gibt es immer noch this->).

Dies ist aber auch nur eine von vielen Meinungen.

Wenn man die Unterscheidung braucht gibt es immer noch this->

Das ist ja wohl der letzte Ausweg.

this->blaBla

class Complex {
    public:
        Complex( double real, double imaginary = 0 )
          : _real(real), _imaginary(imaginary) {};

        void operator+ ( Complex other ) {
            _real = _real + other._real;
            _imaginary = _imaginary + other._imaginary;
        }

        void operator<<( ostream os ) {
            os << "(" << _real << "," << _imaginary << ")";
        }
        //...

In den MFC wurde m_BlaBla verwendet. Herb Sutter hat einfach das m (für "member") entfallen lassen.

Das macht echt Sinn
Ansatt es _logischerweise_ so zu machen:

class Complex {
    public:
        Complex( double _real, double _imaginary = 0 )
          : real(_real), imaginary(_imaginary) {};

        void operator+ ( Complex _other ) {
            real = real + _other.real;
            imaginary = imaginary + _other.imaginary;
        }

        void operator<<( ostream _os ) {
            _os << "(" << real << "," << imaginary << ")";
        }
        //...

In dieser Variante muss man das "_" naemlich wesentlich weniger mitschreiben.

Da das alles nur Style-Zeug ist brauch ich das vorerst nicht zu beachten.

Fang lieber gleich damit an, was man sich mal angewöhnt hat gewöhnt man sich schwer wieder ab. Und "stillos" zu programmieren ist eine Sache die man sich IMO gleich garnicht angewöhnen sollte.

was bringt mir eine kennzeichnung der member variablen? das klingt so sehr nach polnische notation und das klingt furchtbar.

folgender code funktioniert übrigens:

explicit Complex( double real, double imaginary = 0 )
        : real(real), imaginary(imaginary) {}

PS:
in java schafft man es ja auch ohne m_ auszukommen...

MfG SideWinder

Und nun?

Und nun?

get/set verwenden?

was bringt mir eine kennzeichnung der member variablen? das klingt so sehr nach polnische notation und das klingt furchtbar.

Dem kann ich mich auch nur anschließen. Meiner Erfahrung nach führt dies auch zu ein leicher lesbaren Code - aber Geschmäcker sind verschieden (Macht den Stil in eurer Firma/Projekt aus).

cu André