speicherwerte von member-variablen



  • das war je gerade meine frage (vielleicht etwas komisch formuliert):

    ich haette auch gedacht, dass es nicht so ist. ausprobieren kann man es. jedoch bleibt die frage ob es eine generelle sprach-spezifische festlegung ist, d.h. wenn ich es ausprobiere und die dinger sind genullt, dann ist das zufall oder haengt vom system ab auf dem ich es probiere (embedded system z.B.) !?!

    Also sind member prinzipiell explizit im konstruktor zu nullen sofern es erwuenscht ist!?

    gruss



  • In der Regel wird nur der Speicher reserviert bzw. belegt. Die Variablen beinhalten dann das was vorher an dem Speicherplatz war. Das hat den Nachteil das es etwas schwerer zu debuggen ist, da es vorkommen kann das der vorherige Inhalt durchaus Sinn macht in seiner Form aber indirekt zu Fehlern führt.



  • Nun ja, ich weiß, dass es mit meinem Compiler (VS2008) definitiv so ist. Da wird nix implizit genullt. Deine letzte Frage kann ich also mit Ja beantworten.



  • weiss jemand ob man generell davon ausgehen kann, dass member-variablen einer klasse, sofern sie nicht explizit durch den konstruktor genullt wurden, immer genullt sind beim anlegen einer instanz

    Es kommt drauf an: Wenn sie in der Initialisierungsliste des Konstruktors nicht explizit genullt werden, aber trotzdem auftauchen (mit leeren Klammern), dann werden sie value-initialisiert. Value-Initialisierung bedeutet, dass die Variable mit einer in den Zieltyp konvertierten 0 initialisiert wird.

    Globale PODs werden auch implizit genullt.



  • also das wird glaube ich unterschiedlich gehandhabt:

    undefiniert:

    class A
    {
    public:
    long x;
    };
    
    int main(int argc, char *argv[])
    {
      A *pa = new A();
      A a;
      // beide male ist x undefiniert
    }
    

    sofern ich aber den standard-konstruktor ueberschreibe mit:

    class A
    {
    public:
    A(){}
    long x;
    };
    int main(int argc, char *argv[])
    {
      A a;
      // x ist genullt !!
    }
    


  • Sobald du einen eigenen Konstruktor schreibst, wird x implizit genullt? Hmm, ich habe das eben an einer bestehenden Klasse getestet. Da stand während OnInitDialog (also nach Konstruktor-Aufruf) in einem int-Member nur Müll, trotz überschriebenem Konstruktor...



  • Im ersten Fall wird A default-initialisiert. Das heisst (da A kein POD ist) für alle POD-Member von A, dass sie nicht initialisiert werden.

    Im zweiten Fall wird A auch default-initialisiert, wobei der explizite Konstruktor x nicht initialisiert. Das hier sollte auch unbestimmt sein, x muss also nicht genullt sein. (Ist z.B. beim MSVC2005 auch nicht so)

    Der dritte Fall fehlt hier: x wird im expliziten Konstruktor default-initialisiert. Dann wäre es auf jeden Fall genullt.

    class A
    {
    public:
    A() : x() {}
    long x;
    };
    


  • Das im zweiten Fall "genullt" wird mag Zufall sein. Kann ja gut sein das der Speicherbereich der dort dem x zugetan wird vorher für andere Zwecke (Debug?) genutzt und mit 0 initialisiert wurde.



  • hmm keine ahnung.
    ich habe VS2003, da wird bei leerem ueberschriebenen default-konstruktor (ohne member-null-initialisierung) die member x zu 0.
    vielleicht fuegt der compiler ja bei nem leer ueberschriebenen konstr. das x() mit an!?
    trotzdem danke.
    gruss.



  • pepe75 schrieb:

    hmm keine ahnung.
    ich habe VS2003, da wird bei leerem ueberschriebenen default-konstruktor (ohne member-null-initialisierung) die member x zu 0.
    vielleicht fuegt der compiler ja bei nem leer ueberschriebenen konstr. das x() mit an!?
    trotzdem danke.
    gruss.

    Auch, wenn du als Release kompilierst? In der Debug-Version wird der Speicher ja noch irgendwie vorbereitet, vielleicht hängt's damit zusammen.


Anmelden zum Antworten