code_Kommentar

danke
aber warum schreibt man nicht einfach:
m = max;
topPos = 0;

hat die Schreibeweise

: topPos(0),m(max)

eine gewisse Priorität oder ist ein Muss?

ser1al

cremesimo schrieb:

danke
aber warum schreibt man nicht einfach:
m = max;
topPos = 0;

hat die Schreibeweise
: topPos(0),m(max)
eine gewisse Priorität oder ist ein Muss?

im gegenteil, eigentlich sollte man eingebaute typen im konstruktor, und nicht in der initialisiererliste initialisieren!

Konstruktor(int irgendwas):bla(irgendwas)   //nicht so gut
{
 bla=irgendwas;    //ist besser
}

//wenn bla und irgendwas zB ein int, oder double oder so ist

MFK

5er1al schrieb:

im gegenteil, eigentlich sollte man eingebaute typen im konstruktor, und nicht in der initialisiererliste initialisieren!

Warum?

ser1al

MFK schrieb:

5er1al schrieb:

im gegenteil, eigentlich sollte man eingebaute typen im konstruktor, und nicht in der initialisiererliste initialisieren!

Warum?

weil inilisten imho unübersichtlich und für -zumindest den anfänger- heimtükisch sein können!

Volkard_Tutorial schrieb:

Diese Variante ist aber nicht vorzuziehen, denn Initialisiererlisten sind unübersichtlich und tückisch. Verwenden Sie sie nicht für eingebaute Typen wie int oder float.

Chew-Z

Es gibts auch kompetente Menschen die anderer Meinungen sind:
http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.6

virtual

Sorry, aber das ist ziemlicher unfug, finde ich, denn ob die Liste übersichtlich ist oder nicht hängt davon ab, wie man den Quellcode layoutet. Wenn man ähnlich einer Zuweisung im Konstruktor hingeht, pro Zeile eine Initialisierung macht, ist es nicht unübersichtlich.

Genausowenig wie ich

a = 1; b = 2; c = a*b;

in eine Zeile schreibe, schreibe ich auch Initialisierer nicht in eine Zeile.

groovemaster

5er1al schrieb:

im gegenteil, eigentlich sollte man eingebaute typen im konstruktor, und nicht in der initialisiererliste initialisieren!

Nope! Schreib deine Initialisierungsliste vernünftig, dann wirds auch nicht unübersichtlich. Leider machen das zu wenige Leute, deshalb ist das für Anfänger oft verwirrend. Zumindest in diesem Punkt hast du Recht.

widersprecht ihr euch nicht selber?
Einerseits preist ihr volkard so an, andererseits sagt ihr, dass das was in seinem tutorial ist falsch ist?

virtual

STOP! schrieb:

widersprecht ihr euch nicht selber?
Einerseits preist ihr volkard so an, andererseits sagt ihr, dass das was in seinem tutorial ist falsch ist?

1. Preise ich niemanden an.
2. Wo Licht, da auch Schatten (kenne allerdings sein Tutorial nicht, dehalb kann ich zur Licht/Schatten verteilung keine aussage treffen).

groovemaster

STOP! schrieb:

widersprecht ihr euch nicht selber?

Nö, wieso?

STOP! schrieb:

Einerseits preist ihr volkard so an, andererseits sagt ihr, dass das was in seinem tutorial ist falsch ist?

Erstens wird hier niemand angepriesen, und zweitens, wo ist da der Widerspruch? Schliesslich ist niemand perfekt.

otze

MFK schrieb:

5er1al schrieb:

im gegenteil, eigentlich sollte man eingebaute typen im konstruktor, und nicht in der initialisiererliste initialisieren!

Warum?

weil man dann so schöne probleme mit konstanten membern bekommt

Das Tückische ist übrigens die Initialisier-Reihenfolge, aber nur wenn man nicht weiss wonach sie sich richtet. Hier ein Beispiel:

#include <iostream>

using namespace std;

class bar
{
    public:
        bar(const char *s)      
        {
            cout << s << " ";
        }
};

class foo
{
    public:
		foo() : m_a("was"), m_b("soll"), m_c("das") {}

        //Das Folgende würde gar nicht funktionieren, denn bar hat keinen Parameterlosen Konstruktor.
		//Dieser wird aber benötigt, weil die Member schon initialisiert werden, bevor der Code innerhalb 
		//der Mengenklammern beginnt. Das heisst, wenn es einen Default-Konstruktor gäbe, würden die Member,
		//im Konstruktor-Block zum zweiten Mal initialisiert werden. Es sei denn der Compiler würde 
		//den Unsinn erkennen und optimieren.
		//foo()
		//{
		//	m_a = bar("was");
		//	m_b = bar("soll");
		//	m_c = bar("das");
		//}

    private:
        bar m_c,m_b,m_a;
};

int main()
{
    foo f;
    cout << endl;
    cin.get();
}

Blue-Tiger

nillable schrieb:

Das Tückische ist übrigens die Initialisier-Reihenfolge, aber nur wenn man nicht weiss wonach sie sich richtet.

Moderne Compiler machen sowieso drauf aufmerksam, wenn die Reihenfolge nicht ok ist

Blue-Tiger schrieb:

Moderne Compiler machen sowieso drauf aufmerksam, wenn die Reihenfolge nicht ok ist

Inwiefern und welche? Beim Übersetzen des Beispiels macht weder g++ 3.4.2 (MinGW) noch VC 7.1 auf irgendwas aufmerksam.
Falls wir aneinander vorbeireden: das Tückische, das veranschaulicht werden sollte, ist, dass die Member nicht in der Reihenfolge initialisiert werden, in der man sie in der Initialisierungsliste aufführt, sondern in der Reihenfolge der Deklarationen.

FireFlow

=====> Bei elementaren Datentypen ist es *scheiss egal* was man macht, denn diese werden lokal nicht mit Standardwerten gefüllt. Bei Klassen jedoch sollte man es unbedingt machen da man ansonsten ein Konstruktoraufruf mehr hat.

FireFlow schrieb:

=====> Bei elementaren Datentypen ist es *scheiss egal* was man macht, denn diese werden lokal nicht mit Standardwerten gefüllt.

Es sei denn, man hat, wie otze schon andeutete, konstante Member.

groovemaster

FireFlow schrieb:

Bei elementaren Datentypen ist es *scheiss egal* was man macht

Eben nicht. Lies dir otze's Beitrag nachmal durch. Oder wie siehts zB mit Referenzen aus?

FireFlow

groovemaster schrieb:

FireFlow schrieb:

Bei elementaren Datentypen ist es *scheiss egal* was man macht

Eben nicht. Lies dir otze's Beitrag nachmal durch. Oder wie siehts zB mit Referenzen aus?

Ich meinte das ganz normale int var; Bei Referenken und const Typen siehts wieder anderst das stimmt.

ser1al

na da hab ich ja was angerichtet!

Aber warum sie eben tükscih ist wurde ja schon gesagt....!