3. Warning C4355

Warning C4355

  • R

    Setz das Attribut später, z.B. im Konstruktor-Rumpf.

    Das macht aber vieles anderes unelegant ...
    Warum init/setter methoden, wenn man das im konstruktor loesen kann ...
    und ne variable nur deswegen nicht const machen, nur weil du es wegen der obigen geschichte nicht in Konstruktor hinbekommst, ist auch doof

    @Dravere
    wenn du this verwendest, nur um ne referenz auf das object , in dessen initialisierungsliste Du dich grad befindest, isses durchaus ok.
    Du musst in Deinem objekt, welches du mit dem this da grad konstruierst, nur sicher sein das Du an der stelle noch keine vollkonstruierte referenz hast, also keine meber der referenz aufrufen etc.(was man in der initialisierungsliste eh seltener tut) der stack selber iss aber schon aufgerollt, also sind alle die referenzen auf alle member rein pointertechnisch schon gueltig.

    Deswegen iss es ja auch nur ne Warnung, kein Fehler
    wenn dich die meldung stoert, da du ja pflichtbewusst die warnungen nich einfach ignorierst ^^, benutze #pragma warning(disable 4355), natuerlich nur an den stellen wo dir sicher bist das es ok ist ....

    und freu dich schon mal auf den 8.0er compiler, der dir fast alle c-funktionen aus der cstdlib die man mangels an gescheiten alternativen in c++ immer noch verwendet, als depricated und unsicher deklariert und seine plattformabhaengige M$ variante dafuer haben will ^^

    Ciao ...

    0
  • Administrator

    Artchi schrieb:

    Och Leute man man man ... es ändert an unseren Antworten nichts. Deine Lösung ist trotzdem "krank". 😃 😉

    Na danke ^^

    Artchi schrieb:

    Und der Compiler sagt auch, das es nicht i.O. ist, weil die Initialisierer-Liste (die du ja benutzt) _vor_ der Objekt-Konstruktion abgearbeitet wird. Was ja auch der Sinn dieser Erfindung ist.

    Setz das Attribut später, z.B. im Konstruktor-Rumpf. Da ist das Objekt schon gebaut.

    Also wenn man this im Rumpf des Konstruktor benutzt dann geht es?? Wann genau wird denn nu das this konstruiert? ^^

    MFK schrieb:

    Sollte das nicht in Ordnung sein? Der Zeiger wird ja im Konstruktor von CGroupPlay nicht benutzt.

    Hmmm im echten code ... nein hab im Rumpf nur ein ASSERT_VALID(m_pDoc) eingebaut. Grundsätzlich ja sogar unnötig ^^

    camper schrieb:

    es führt zu einer recht starken koppelung der klassen. das heißt aber nicht das daran etwas undefiniertes wäre

    Soll es auch. CGroupPlay ist eine Art von Kommunikationsklasse zwischen verschiedenen CGoup Objekten und der Doc-Klasse.

    camper schrieb:

    this zeigt in diesem falle auf ein teilweise konstruiertes objekt, und damit kann das argument in CGroupPlay nur eingeschränkt verwendet werden, bis CRankingsDoc vollständig konstruiert ist. das sollte aber intuitiv schon klar sein, jedenfalls ist an der benutzung von this in der initilisierungsliste - an sich - nichts fehlerhaftes.

    Anderst gesagt, das funktioniert? Kann es eben leider noch nicht testen, da ich noch keine sinnvolle Benuzteroberfläche dazu habe, derzeit progge ich nur den "Motor" 😉

    Und in der Vorschau grad noch gemerkt. Danke RHBaum, somit wäre die Frage an Camper schon beantwortet ^^

    Also fehlt nur noch die Antwort auf die Frage, wann denn nun der this-Zeiger konstruiert wird?

    Grüssli und danke für die vielen Antworten!

    0
  • ?

    Dravere schrieb:

    Also fehlt nur noch die Antwort auf die Frage, wann denn nun der this-Zeiger konstruiert wird?

    Wenn der Konstruktor vollständig abgearbeitet wurde 😉

    Edit: Konstruiert ist er ja schon, halt nur nicht vollständig ...

    0
  • R

    Der this zeiger wird sofort reserviert, nicht konstruiert ^^ das ist ja gar nicht das Problem.

    - du erstellst dein object ...
    - dein object hat members
    - sobald du in den scope kommst, wo dein Object definiert ist (wenn du es aufn stack anlegst) oder sofort och vor rueckkehr deines new sind fuer dein object und alle seine members und members members der speicher reserviert (nicht initialisiert). sprich die zeiger/referenzen auf die dinger sind gueltig. weiter noch nix ...
    - unabhaengig und compilerabhaengig (oder irr ich mich da) werden die freien speicher der variablen initialisiert. das haengt von der art ab, was du in die init liste schreibst und um was fuer objecte es sich handelt.
    - danach wird in abhaengigkeit von der reihenfolge der deklaration (nicht der reihenfolge in der initialisierungsliste) die konstruktoren deiner mebers aufgerufen ....
    - danach dein eigener konstruktor.

    wenn du in deiner init liste also this verwendest, sind zwar alle adressen/und referenzen die du durch &this oder &this->xyz bekommen wuerdes gueltig, aber es ist eben nicht garantiert, das die daten selber stimmig sind, weil die konstruktoren der member von this noch nicht aufgerufen wurden teilweise ....
    mit viel humor koennt man da sogor ne konstruktor / init endlosschleife reinbekommen ^^
    Und nur genau davor will dich dein compiler warnen ...

    Verstaendlich genug ?

    Ciao ...

    0
  • H

    Sowie mit der Abarbeitung der Initialisierungsliste begonnen wird, existiert der this-Zeiger.
    Der C++ Standard sieht den Einsatz des this-Zeigers in der Initialisierungsliste jedoch
    nicht vor, sein Einsatz ist erst im Konstruktorrumpf erlaubt - soweit ich weiss!.
    mfg

    0
  • R

    sein Einsatz ist erst im Konstruktorrumpf erlaubt

    Nachdem die Reihenfolge der Konstruktion expliziet ziemlich genau definiert ist, ist nen sinvoller umgang mit this zeigern in der initliste durchaus moeglich ... an vielen stellen macht das sogar auch expliziet sinn.

    Deshalb glaub ich nicht das der standard es verbietet .... sondern er wird es den usersn ueberlassen mit der sache sinvoll umzugehen ^^

    Ciao ...

    0
  • Administrator

    Na ok ... ich glaub ich hab es so einigermasen verstanden. Und so nehme ich nun an, dass es funktionieren wird, so wie ich es aufgebaut habe. Da ich den Zeiger nur Abspeicher um Später damit arbeiten zu können, lange nachdem alle Konstruktoren aufgerufen wurden.

    Vielen, vielen Dank für die Hilfe.

    Grüssli

    0
  • C
    Mod

    ISO/IEC 14882:2003 12.7/2 schrieb:

    [Example:
struct A { };
struct B : virtual A { };
struct C : B { };
struct D : virtual A { D(A*); };
struct X { X(A*); };
struct E : C, D, X {
      E() : D(this),            // undefined: upcast from E* to A*
                                // might use path E* [e]rarr[/e] D* [e]rarr[/e] A*
                                // but D is not constructed
                                // D((C*)this), // defined:
                                // E* [e]rarr[/e] C* defined because E() has started
                                // and C* [e]rarr[/e] A* defined because
                                // C fully constructed
            X(this)             // defined: upon construction of X,
                                // C/B/D/A sublattice is fully constructed
            { }
};
—end example]
    0
  • M

    Das trifft IMHO auf diesen konkreten Fall nicht zu, da hier keine Typumwandlung stattfindet. Der Konstruktor von CGroupPlay nimmt einen CRankingsDoc*, und den bekommt er auch.

    0
  • C
    Mod

    schon klar. es ging mir nur darum, dass auch hier this in der ctor-initialisierungsliste verwendet wird.

    0
Anmelden zum Antworten