Templateprobleme

davie

in dem fall ist es noch (relativ) egal, aber es ist besser, sich das anzugewöhnen.

ChrisM

Hmm... d.h. ich soll Members ab jetzt immer über die Initialisierungsliste initialisieren? Sieht das bei größeren Klassen dann nicht etwas komisch aus?

ChrisM

davie

Etwas_Groessere_Klasse::Etwas_Groessere_Klasse (int a, int b, int c, int d) :

m_a (a),
m_b (b),
m_c (c),
m_d (d),
m_e (a+b),
m_Instanz_von_Etwas_Kleinere_Klasse (a+b, b%d, m_e)

{}

sieht doch nett aus
also, wenn es sowas schon gibt, dann nutze es auch
In der FAQ haben wir, glaub ich, auch einen beitrag, der sich damit beschäftigt.
ansonsten benutz mal die suchfunktion. findest sicherlich viele gute argumente für solche listen

[ Dieser Beitrag wurde am 13.04.2003 um 22:40 Uhr von davie editiert. ]

ChrisM

OK, danke, werd ich mir wohl angewöhnen

Langsamer kanns net sein und das ist die Hauptsache

ChrisM

davie

ist sogar oft schneller (ansonsten ctor + op=)

Krösus

Ich glaube, mal gelesen zu haben (Effektiv C++ programmieren?), daß die Element-Initialisierliste NICHT in der im Konstruktor angegebenen Reihenfolge abgearbeitet wird, sondern stattdessen in der Reihenfolge, wie die Elemente in der Klassendefinition auftauchen! Frage: Stimmt das?!?!
Wenn Du daher Deine Klasse so aufbaust

class Etwas_Groessere_Klasse
{
    Klein m_Klein;
    int m_e;
    //...
};

dann bekommst Du demnach ein ziemliches Problem bei folgender Elemente-Initialisierung:
[cpp]
Etwas_Groessere_Klasse::Etwas_Groessere_Klasse (int a, int b, int c, int d) :
m_a(a),
m_b(b),
m_c(c),
m_d(d),
m_e(a + b),
m_Klein(a + b, b % d, m_e) //m_e noch undefiniert!!??
{}[/cpp]

HumeSikkins

daß die Element-Initialisierliste NICHT in der im Konstruktor angegebenen Reihenfolge abgearbeitet wird, sondern stattdessen in der Reihenfolge, wie die Elemente in der Klassendefinition auftauchen! Frage: Stimmt das?!?!

Ja das stimmt. Die Elementinitialisierung in der Initialisierungsliste wird automatisch so angeordnet, dass sie der Deklarationsreihenfolge der Elemente entspricht. Wer also Abhängigkeiten zwischen einzelnen Elementen hat, sollte dies unbedingt berücksichtigen.

ChrisM

So hab grad ein Problem mit der Elementinitialisierungsliste, ich post das grad mal hier.

Also:

class CString : public std::string
{
};

class CPlugin
{
public:
    CPlugin(const CString &strFile);
    ~CPlugin(void);

private:
    CString &m_strFile;
    HMODULE m_hModule;
};

CPlugin::CPlugin(const CString &strFile) :
m_strFile(strFile)
{
}

Gibt bei der Elementinitialisierungsliste von CPlugin::CPlugin(const CString&) folgende Fehler:

Plugin.cpp
c:\dokumente und einstellungen\chris\eigene dateien\programmieren\projekte\age\source\engine\plugin.cpp(24) : error C2440: 'initializing' : 'const class AGE::CString' kann nicht in 'class AGE::CString &' konvertiert werden
Durch die Konvertierung gehen Qualifizierer verloren
c:\dokumente und einstellungen\chris\eigene dateien\programmieren\projekte\age\source\engine\plugin.cpp(24) : error C2439: 'm_strFile' : Element konnte nicht initialisiert werden
c:\dokumente und einstellungen\chris\eigene dateien\programmieren\projekte\age\include\engine\plugin.hpp(26) : Siehe Deklaration von 'm_strFile'

ChrisM

ChrisM

Aua, kleiner Tippfehler, sorry das was schuld:

private:
    CString &m_strFile;

ChrisM

davie

du willst ne referenz auf einen CString machen, der aber als "const" übergeben wird.
entweder du benützt const_cast (...)
oder
du machst aus der Referenz eine Instanz:
CString &m_strFile => CString m_strFile
oder du nimmst das const im Konstruktor weg. Dann existiert die referenz als gültige aber nur solange, wie das Objekt auch existiert. folgendes bsp führt dann zu undefiniertem verhalten:

CPlugin *foo () {
   CString x("Hello"); //Sprungmarke 1
   return new CPlugin (x); 
}

int main () {
   CPlugin *cpl = foo ();
   /*
     wenn du hier jetzt die referenz auf [Sprungmarke 1] benutzt
     bekommst du Probleme
   */
}