Argumentloser Konstruktor
-
Ich hab aber noch eine Frage, das von dir beschriebene, "merkwürdige" Verhalten gilt aber nur bei Ctor-Aufrufen, oder?
-
@NoIDE sagte in Argumentloser Konstruktor:
Ich hab aber noch eine Frage, das von dir beschriebene, "merkwürdige" Verhalten gilt aber nur bei Ctor-Aufrufen, oder?
Ich weiß nicht, was du genau mit merkwürdigem Verhalten meinst? Das Problem hängt wie von mir beschrieben eben mit der Konstruktion des Objektes zusammen, daher tritt es also natürlich auch nur bei der Konstruktion von Objekten auf. Dort aber immer. Egal ob man jetzt den CTor explizit definiert oder nicht. Ich weiß aber nicht, was da genau merkwürdig sein soll.
Es ist vlt. merkwürdig aus Sicht eines Java Programmierers in folgender Hinsicht:
- In Java werden meines Wissens nach Felder (Members) erst initialisiert, nachdem der Body des Konstruktors ausgeführt wird. Eine Initialisierungsliste gibt es nicht. Bei C++ eben vor dem Body, dafür gibt es aber halt die Initialisierungsliste
- In Java hat man Referenztypen für Objekte (neben primitiven Datentypen) und deren Default Value ist null analog zu Pointern in C++ (nullptr). Bei der Default Initialisierung wird also nie ein Objekt konstruiert und entsprechend gibt es solch einen Fehler wie in C++ auch nicht in Java
In beiden Fällen ist es aber nicht merkwürdig, sondern eben unterschiedliches Sprachdesign und somit höchstens für den entsprechenden Programmierer unüblich, der es anders gewohnt ist.
-
@Leon0402 sagte in Argumentloser Konstruktor:
In Java werden meines Wissens nach Felder (Members) erst initialisiert, nachdem der Body des Konstruktors ausgeführt wird. Eine Initialisierungsliste gibt es nicht. Bei C++ eben vor dem Body, dafür gibt es aber halt die Initialisierungsliste
Hm, idR. beim Aufruf des ctors, oder sie sind static, dann bereits davor. Konstante (final) Felder müssen übrigens immer einen Wert haben, also entweder direkt bei der Deklaration oder sie werden im Ctor initialisiert.
@Leon0402 sagte in Argumentloser Konstruktor:
In Java hat man Referenztypen für Objekte (neben primitiven Datentypen) und deren Default Value ist null analog zu Pointern in C++ (nullptr). Bei der Default Initialisierung wird also nie ein Objekt konstruiert und entsprechend gibt es solch einen Fehler wie in C++ auch nicht in Java
Es gibt die Default-Initialisierung, ja. Aber im Unterschied zu C++ werden dabei keine neuen Instanzen erstellt (wenn man das nicht explizit angibt).
In Java gibt es keine Variablen (auch keine Member/Felder), die keinen Wert haben (uninitialisiert sind), wenn sie gelesen werden, das stellt der Compiler sicher.
Mir ist neu (war neu), dass in C++ die Member vor Aufruf des Ctors default initialisiert werden. In Java kann es keine Objekte geben, die nicht mit new/Ctor angelegt wurden. Das ist vermutlich der Unterschied.
-
Moin
Ja das ist unschön aber c++ verhält sich da korrekt. Mein Workaround: Lass den legacy Konstruktor einfach weg und erstelle eine custom Ersatzmethode in der Basisklasse und die wird ganz normal vererbt. Einziger Nachteil damit ist daß diese Methode extra aufgerufen werden muß.SubClass *res = new SubClass; // hier nichts übergeben res->inst(foo, bar); // rufe den ErsatzkonstruktorMFG
-
Dann is es aber keine Komposition im UML-sinne mehr...
-
@nameName sagte in Argumentloser Konstruktor:
Dann is es aber keine Komposition im UML-sinne mehr...
Und wo war das gefordert? Egal, Hauptsache mal wieder nen Fachbegriff angebracht, um zeigen zu wollen, dass du Ahnung von iwas hast.
-
-
@DocShoe sagte in Argumentloser Konstruktor:
@nameName sagte in Argumentloser Konstruktor:
Dann is es aber keine Komposition im UML-sinne mehr...
Und wo war das gefordert? Egal, Hauptsache mal wieder nen Fachbegriff angebracht, um zeigen zu wollen, dass du Ahnung von iwas hast.
Das ist doch Nonsens. Ich habe mir lediglich die Mühe gemacht, und die Fragestellung genau gelesen. Ihr anscheinend nicht.
De-facto habt ihr die Komposition in eine Aggregation oder sogar nur in einfache Assoziation aufgeweicht. Die Ein-existentieller-Teil-eines-Ganzen-Beziehung besteht nicht mehr.
Und warum das Ganze? Weil nicht sein kann, was nicht sein darf: Meine Vorschläge waren womöglich richtig.
-
Dann zitier doch bitte mal den Aufgabentext, wo Komposition gefordert ist, ich finde da nix.
-
Es stimmt, dass das Wort "Komposition" nicht geschrieben steht oder gar gefordert wurde.
Aber wenn ich objektorientiert mit C++ arbeite, lassen Dinge wie "Referenz von einem Objekt auf ein anderes Objekt" oder "Objekt ist ein integraler Bestandteil eines anderen Objektes" eine gewisse Interpretation im UML-Sprachgebrauch zu.
Also aus dem zuerst gezeigten Quell-Kode geht schon hervor, dass Klasse "A" ein integraler Bestandteil von Klasse "B" ist, ergo diese Beziehung in UML als "Komposition" bezeichnet werden kann.
Die Bemerkung von @nameName ist so falsch also nicht.
Ob die Bezeichnung "Komposition" in Beziehung zur UML "Oldschool" ist, sei dahingestellt, dass ist u.a. "Mathematik" auchDiese Themen wurde in diesem Forum auch schon diskutiert, hier eine kleine Auswahl;
Aggregation und Komposition realisieren
Asossziation, Aggregation, Komposition - wie wird es realisiert
Wo liegt der Unterschied zw. Assoziation, Aggregation und Komposition?
-
@Helmut-Jakoby
Danke für deine Unterstützung...Im Berufsleben hat man auch Use-Cases oder User-Stories... also eine umgangssprachliche Umschreibung der Anforderungen (im Idealfall sogar eine Lastenheft). Dann ist es Sache des Programmierers (oder Architekten), die technischen Beziehungen herzustellen.
Aber... was weiß ich schon. Mir sollte ja der Mund verboten werden, und alles, was ich schreibe, ist pauschal falsch...
Und ja, ich bin in C++ kein Crack... aber auch nicht komplett disqualifiziert.
-
Leute: Don' t feed the trolls!
A "troll" is a person who intentionally attempts to disrupt, cause controversy, incite an argument, and/or receive negative attention by deliberately posting provocative content. The term may also refer to the act of posting such content, or the content itself.
Trolls are generally deceitful and often use ambivalence as a method of covertly insulting, intimidating, or inciting a person or persons for their own sadistic pleasure. They often pick their words very carefully and are therefore able to defend their masked attempts at creating unrest, frequently redirecting the blame onto the community and its supposed failure to understand them properly. Trolling is strictly prohibited.
Quelle: https://wiki.manjaro.org/index.php?title=Forum_Rules
-
@Helmut Jakoby:
Es geht hier nicht darum, was sinnvoll ist oder nicht, sondern darum, was gefordert ist. Und da hat Kollege @nameName wieder irgendwas reinterpretiert, das nirgendwo explizit erwähnt wurde. Anschließend präsentiert er uns seine Erkenntnis als Fakten, auf die ausschließlich er gekommen ist, weil er als einziger die Frage genau gelesen hat.Nach
@NPC sagte in Argumentloser Konstruktor:
Eine erzeugung von A in B kommt leider eigentlich nicht in Frage. A ist ein relativ großes Objekt mit dem ich ein >bisschen Arbeite bevor ich es an B weitergebe (weshalb ich eine Kopie von A vermeiden möchte). B braucht dann > einige Methoden von A für seine Arbeit.
und
@NPC sagte in Argumentloser Konstruktor:
Leider muss ich mich, der Aufgabe wegen, hier auf die Performance fokusieren.
Die Frage die sich sofort stellt ist natürlich die wie sehr ich auf Performance schauen kann, wenn mir dergleichen Eigenschaften unbekannt sind. Das ist (hoffentlich) weniger kritisch als es scheint. Mein Ursprüngliches Problem lag an einer misinterpretation der Übergabe selbst. Mir war nicht bewusst, dass ich nicht automatisch einen Pointer übergebe, wenn ich ein Objekt übergeben will. Da bin ich wohl aus anderen Programmiersprachen zu sehr verwöhnt.will TE explizit keine Komposition. Das hat @nameName trotz genauen Lesens wohl nicht verstanden, was ihn trotzdem nicht davon abhält, seinen Beitrag für richtig zu halten, der in Wirklichkeit aber überhaupt keine Relevanz hat. @nameName verfällt hier wieder in sein altes Muster: Fakten zu ignorieren und sie so zu umzudeuten, dass sie seine Vorstellungen stützen.
Kritik an seinem Beitrag fasst als Kritik an seiner Person auf, und nicht an seinem Beitrag. Damit glaubt er, sein Beitrag ist immer noch richtig, und sämtliche Kritik richtet sich ausschließlich gegen ihn, weil er eine Persona Non Grata sei.
@nameName
Das war leider nix. Mal wieder. Macht aber nix, irgendwann wird's schon noch. Bestimmt. Ich glaub' da ganz fest an dich. Du musst nur einfach aufhören, permanent Blödsinn zu faseln, dann klappt's auch mit'm Nachbarn.
-
Wer es noch nicht gemerkt hat: Das grundlose User-Bashing geht weiter ...
-
@Quiche-Lorraine sagte in Argumentloser Konstruktor:
Leute: Don' t feed the trolls!
A "troll" is a person who intentionally attempts to disrupt, cause controversy, incite an argument, and/or receive negative attention by deliberately posting provocative content. The term may also refer to the act of posting such content, or the content itself.
Trolls are generally deceitful and often use ambivalence as a method of covertly insulting, intimidating, or inciting a person or persons for their own sadistic pleasure. They often pick their words very carefully and are therefore able to defend their masked attempts at creating unrest, frequently redirecting the blame onto the community and its supposed failure to understand them properly. Trolling is strictly prohibited.
Quelle: https://wiki.manjaro.org/index.php?title=Forum_Rules
Zu tief ins Glas geschaut?
