Kann eine Nested Class tatsächlich Performance verbessern?



  • Hi,

    wie der Titel schon aussagt, frage ich mich gerade, ob eine Nested Class in irgendeinem Szenario tatsächlich Performance verbessern kann.

    Wenn ihr euch jetzt fragt, wie ich darauf komme ... ich habe bei uns im Code diesbzgl. einen Kommentar gesehen. Der Code ist auch schon was älter ... ca. 10-15 Jahre.

    Der Code sieht ungefähr so aus ...

    class A
    {
      // und hier steht der Kommentar, dass diese Klasse B nicht als
      // High Level Klasse eingebaut wurde aus Performance Gründen
      class B
      {
        // ...
      };
    
      B[10] member;
    };
    

    Ist dem so, dass es tatsächlich etwas bringt? Oder war dem mal so? Oder ist das einfach nur totaler Nonsense?



  • Vielleicht greift eine Methode von B aus "Performance-Gründen" auf Privates von A zu. Etwas anderes fällt mir jetzt nicht ein.



  • TyRoXx schrieb:

    Vielleicht greift eine Methode von B aus "Performance-Gründen" auf Privates von A zu. Etwas anderes fällt mir jetzt nicht ein.

    Ahh ... auf die Idee bin ich noch nicht gekommen. Überprüfe ich mal, ob dem so ist.
    Dank dir schon mal für den Denkansatz!



  • Optimierer schrieb:

    Hi,

    wie der Titel schon aussagt, frage ich mich gerade, ob eine Nested Class in irgendeinem Szenario tatsächlich Performance verbessern kann.

    Wenn ihr euch jetzt fragt, wie ich darauf komme ... ich habe bei uns im Code diesbzgl. einen Kommentar gesehen. Der Code ist auch schon was älter ... ca. 10-15 Jahre.

    Der Code sieht ungefähr so aus ...

    class A
    {
      // und hier steht der Kommentar, dass diese Klasse B nicht als
      // High Level Klasse eingebaut wurde aus Performance Gründen
      class B
      {
        // ...
      };
    
      B[10] member;
    };
    

    Ist dem so, dass es tatsächlich etwas bringt? Oder war dem mal so? Oder ist das einfach nur totaler Nonsense?

    Da sehe ich zunächst keinen Vorteil.

    Vorschlag A:
    Sehen tun tue ich aber ganz vage einen bei

    class A
    {
      class B//Könnte aber ruhig auch außerhalb definiert sein!
      {
        /*
        weg, war suboptimös
        A* myOwner;
        A* getOwner()
        {
           return myOwner;
        }
        */
        A* getOwner()
        {
           return astonish_cast<offset_off(A,member)>(*this);
           //B muss A kennen, damit das geht!
        }
        // ...
      };
      string a;
      B member;//A muss B kennen, damit das geht!
      int c;
    };
    

    Und weil sie sich beide kennen müssen, hab ich den Trick gemacht.
    Aber ist nicht wahr, denn nur B::getOwner muss A kennen und B::getOwner könnte auch leicht nach A definiert werden.

    Vorschlag B:
    Da war mal was auf dem MS-Compiler, daß man per MS-Erweiterungs-Sprachmittel angeben konnte, wie lang die Zeiger auf Funktionen einer Klasse sind, weil für wenn keine virtuellen dabei sind, gehts vielleicht kürzer, wenn keine virtuellen Basisklassen involviert sind, noch viel besser oder sowas.

    Dann kann man B nicht vor A definieren und A nicht vor B, weil von der forward-deklarierten Klasse die Methodenzeiger nicht mehr optimiert werden können.



  • volkard schrieb:

    Und weil sie sich beide kennen müssen, hab ich den Trick gemacht.
    Aber ist nicht wahr, denn nur B::getOwner muss A kennen und B::getOwner könnte auch leicht nach A definiert werden.

    Der Vorteil einer Nested-Class ist in dem Fall trotzdem dass man damit leicht verhindern kann dass B ausserhalb von A verwendet wird (einfach private machen). Zwecks Verhinderung von Bugs -- weil ja die in getOwner getroffene Annahme natürlich auch stimmen muss.

    Andrerseits liesse sich natürlich auch das anders lösen - z.B. über privaten ctor und friend .


Log in to reply