Objekt und Klasse und Konstruktoren



  • "The data items and the functions that manipulate them are combined into a structure called a class."

    Ist jetzt ein Objekt und eine Klasse das gleiche oder was ist da der genaue Unterschied?

    Dann noch eine Frage aus einem anderen Kapitel. Dort heisst es:

    "More than one constructor, but only one destructor, can be declared for a class"

    Also ein Konstruktor erzeugt und initialisiert ein Objekt und derer kann es mehrerer pro Objekt geben, aber ein Objekt kann nur einen einzige Destruktor besitzen. Was hat es denn damit auf sich? Wozu will man mehrere Konstruktoren für ein Objekt besitzen und wieso dann nur einen Destruktor?

    Ich finde, dass dieses Tutorial und speziell dieses Kapitel gut zu obiger allgemeiner Fragestellung passt.



  • OK, danke, damit kann ich mehr anfangen 🙂

    Also war es an den OP gerichtet...



  • SeppJ schrieb:

    Logik? Das Argument bricht doch schon beim allerersten Schritt zusammen, wenn es um Parameter für die Konstruktion geht.

    Bei welchem allerersten Schritt soll denn welches Argument aus welchem Grund genau zusammenbrechen?

    hustbaer schrieb:

    Kosten:

    Mehrere Konstruktoren zu erlauben macht in einer Sprache die bereits Overloads erlaubt nichts wesentlich komplizierter. Die Overload-Resolution Regeln gibt es bereits, der Ctor wird ganz normal anhand dieser ausgewählt.
    Davon abgesehen wird nichts verkompliziert. Es müssen keine speziellen Regeln definiert werden was beim operator = zu passieren hat, es muss kein zusätzlicher State in das Objekt rein.

    Nutzen:

    Mehrere Konstruktoren sind nötig um flexible konsturierbarkeit von Klassen zu ermöglichen wenn diese...
    * const Member haben
    * Member haben die nur per Ctor initialisiert werden können (d.h. nicht default konstruiert und danach so verändert werden können dass sie "passen").
    Weiters erspart man sich dadurch lauter "named Constructor" Funktionen zu basteln.

    Weiters sind mehrere Konstruktoren nötig für kopierbare und konvertierbare Klassen.

    ---

    Der Nutzen ist also ziemlich klar und mMn. auch ziemlich gross, und die Kosten sind minimal.
    Also genau umgekehrt wie beim Destruktor.

    Selbst wenn man mal davon ausgehen wuerde, das obige Aussagen korrekt waeren:
    a) Du hast die Kosten und Nutzen der Destruktor gar nicht analysiert, wie kannst du also "genau umgekehrt" daraus folgern?
    b) Willst du jetzt sagen das ein Feature nur dann in C++ eingebaut werden sollte, wenn sein Nutzen mindestens so hoch wie der von Konstruktoren und die Kosten nicht hoeher als der von Konstruktoren ist?
    c) Wie genau sollen Kosten und Nutzen ueberhaupt als konkreter Wert berechnet werden um so eine quantitive Einschaetzung abzugeben?



  • TGGC schrieb:

    a) Du hast die Kosten und Nutzen der Destruktor gar nicht analysiert, wie kannst du also "genau umgekehrt" daraus folgern?

    Hab ich schon. Nur hab ich nicht "Kosten": und "Nutzen:" davorgeschrieben.

    TGGC schrieb:

    b) Willst du jetzt sagen das ein Feature nur dann in C++ eingebaut werden sollte, wenn sein Nutzen mindestens so hoch wie der von Konstruktoren und die Kosten nicht hoeher als der von Konstruktoren ist?

    Nein.
    Willst du jetzt sagen dass du ernsthaft der Meinung warst ich wollte das sagen, oder stellst du die Frage nur weil du mich lächerlich machen willst?

    TGGC schrieb:

    c) Wie genau sollen Kosten und Nutzen ueberhaupt als konkreter Wert berechnet werden um so eine quantitive Einschaetzung abzugeben?

    Dass man das ganze nicht in konkrete, sinnvolle Zahlen packen kann ist klar. Das hindert Menschen aber nicht daran Entscheidungen anhand der Gegenüberstellung von Kosten und Nutzen zu treffen. Macht das Standard Committee dauernd.



  • hustbaer schrieb:

    Hab ich schon. Nur hab ich nicht "Kosten": und "Nutzen:" davorgeschrieben.

    Heisst also, deine Analyse ist: "mir faellt nichts ein". Super...

    hustbaer schrieb:

    Nein.
    Willst du jetzt sagen dass du ernsthaft der Meinung warst ich wollte das sagen, oder stellst du die Frage nur weil du mich lächerlich machen willst?

    Nein, ich war der Meinung, das du hier Zeug erzaehlst, was mit dem Thema 0 zu tun hat. Danke das du dies bestaetigst.

    hustbaer schrieb:

    Dass man das ganze nicht in konkrete, sinnvolle Zahlen packen kann ist klar.

    Warum also behaupten, da waere ein weiterer konkreter Grund?

    Die ganze Diskussion mit dir ist sinnlos, weil faktisch einfach inkorrekt.



  • TGGC schrieb:

    hustbaer schrieb:

    Hab ich schon. Nur hab ich nicht "Kosten": und "Nutzen:" davorgeschrieben.

    Heisst also, deine Analyse ist: "mir faellt nichts ein". Super...

    Nein.
    Steht hier: https://www.c-plusplus.net/forum/p2462991#2462991

    TGGC schrieb:

    hustbaer schrieb:

    Nein.
    Willst du jetzt sagen dass du ernsthaft der Meinung warst ich wollte das sagen, oder stellst du die Frage nur weil du mich lächerlich machen willst?

    Nein, ich war der Meinung, das du hier Zeug erzaehlst, was mit dem Thema 0 zu tun hat. Danke das du dies bestaetigst.

    Ebenfalls nein, was ich hier erzähle hat mit der Sache sehr viel zu tun. Wenn du es nicht verstehst darfst du gerne nachfragen.

    TGGC schrieb:

    hustbaer schrieb:

    Dass man das ganze nicht in konkrete, sinnvolle Zahlen packen kann ist klar.

    Warum also behaupten, da waere ein weiterer konkreter Grund?

    Willst du jetzt etwa behaupten dass es überhaupt keine Gründe gibt warum ein Feature in den Standard aufgenommen wir bzw. eben nicht? Deine Behauptung dass es an dem "maximale Effizienz" Ansatz von C++ ist einfach nur Blödsinn. Einen Hinweis darauf dass es Quatsch ist lieferst du auch selbst gleich mit - die virtuellen Destruktoren. Die dürfte es dann nämlich genau so wenig geben.

    TGGC schrieb:

    Die ganze Diskussion mit dir ist sinnlos, weil faktisch einfach inkorrekt.

    ROFL
    Das sagt der richtige.



  • hustbaer schrieb:

    TGGC schrieb:

    hustbaer schrieb:

    Hab ich schon. Nur hab ich nicht "Kosten": und "Nutzen:" davorgeschrieben.

    Heisst also, deine Analyse ist: "mir faellt nichts ein". Super...

    Nein.
    Steht hier: https://www.c-plusplus.net/forum/p2462991#2462991

    Ja genau in dem Post hab ich das "mir faellt nichts ein" gelesen.

    hustbaer schrieb:

    TGGC schrieb:

    hustbaer schrieb:

    Nein.
    Willst du jetzt sagen dass du ernsthaft der Meinung warst ich wollte das sagen, oder stellst du die Frage nur weil du mich lächerlich machen willst?

    Nein, ich war der Meinung, das du hier Zeug erzaehlst, was mit dem Thema 0 zu tun hat. Danke das du dies bestaetigst.

    Ebenfalls nein, was ich hier erzähle hat mit der Sache sehr viel zu tun. Wenn du es nicht verstehst darfst du gerne nachfragen.

    Oh, was besseres als ad hominem faellt dir wohl nicht mehr ein. Entweder spielt der Kosten/Nutzen Verhaeltnis eines konkreten Features eine Rolle - weil niemals Features mit schlechteren implementiert wurde. Oder es spielt keine Rolle und dann ist es nicht mein Fehler wenn du es nicht schaffst zu erklaeren, warum diese konkrete Feature hier interessant ist.

    hustbaer schrieb:

    TGGC schrieb:

    hustbaer schrieb:

    Dass man das ganze nicht in konkrete, sinnvolle Zahlen packen kann ist klar.

    Warum also behaupten, da waere ein weiterer konkreter Grund?

    Willst du jetzt etwa behaupten dass es überhaupt keine Gründe gibt warum ein Feature in den Standard aufgenommen wir bzw. eben nicht? Deine Behauptung dass es an dem "maximale Effizienz" Ansatz von C++ ist einfach nur Blödsinn. Einen Hinweis darauf dass es Quatsch ist lieferst du auch selbst gleich mit - die virtuellen Destruktoren. Die dürfte es dann nämlich genau so wenig geben.

    Ist schon klar...

    Fakt ist numal, das es mit der vtable schon eine Moeglichkeit gibt, einer konkreten Instanz einer Klasse Funktionen zuzuordnen und virtuelle Destruktoren zeigen das die auch fuer Destruktoren problemlos funktioniert. Das es ohne vituelle Funktionen (also ohne vtable) nicht geht, zeigt eindeutig das man nicht bereit ist den Overhead fuer das dynamische Binden des Destruktors in jeder Klasse zu zahlen. Einen weiteren Funktionspointer ausserhalb der vtable fuer den Destruktor zu bauen waere technisch kein Problem. Trotzdem hat man lieber den Weg gewaehlt, das jeder der eine Klasse schreibt, sich selbst Gedanken machen muss, wie der Destruktor genau arbeiten soll, falls irgendwann jemand eine Ableitung schreibt.



  • @TGGC
    Ich glaube wir haben die ganze Zeit an zwei unterschiedliche Dinge gedacht.

    Was du vermutlich meinst (und ohne den allerletzten Teilsatz in deinem Beitrag - "falls irgendwann jemand eine Ableitung schreibt" - wäre ich garnicht auf die Idee gekommen): *jede* Klasse bekommt einen Dtor-Zeiger verpasst. Ganz egal wie viele Destruktoren sie definiert, einfach überhaupt jede Klasse. Damit wären natürlich auch alle Klassen von diesem Overhead betroffen. Und damit ergäbe sich natürlich auch der zusätzliche Nutzen dass man jede Klasse als Basisklasse verwenden kann, und die Objekte dann über einen Basisklassenzeiger zerstören, ganz egal ob die Klasse "als Basisklasse ausgelegt" war oder nicht.

    Was ich meine: nur Klassen die mehr als einen Dtor definieren bekommen einen zusätzlichen Dtor-Zeiger (oder automatisch einen VTable Zeiger, auch wenn sie keine virtuellen Funktionen definieren -- bzw. wie auch immer man es konkret umsetzt). Damit würde der zusätzliche Overhead auch nur solche Klassen betreffen.

    Ist das soweit richtig?



  • Ich hatte doch direkt in meinem ersten Post geschrieben, das man C++ mit virtual erst dazu zwingen muss den Funktionspointer fuer den Destructor zu speichern, was man dann eben mit extra Overhead bezahlt.



  • Naja ... die "für jede Klasse" Variante macht einfach SO viel mehr als gefragt dass ich einfach nicht auf die Idee gekommen bin dass du es so meinen könntest.
    Es haben dann zwar viele Sachen die du geschrieben hast unter meiner (falschen) Auslegung keinen Sinn gemacht, aber manchmal steht man halt ordentlich auf dem Schlauch.

    Sorry, ich mach sowas wirklich nicht absichtlich.


Anmelden zum Antworten