Char - Array und Pointer

[Moppi]

So weit war ich bei C/C++ noch nicht durchgestiegen. Ich kann mir bis jetzt noch nicht vorstellen, dass tatsächlich keinerlei Möglichkeit besteht, Objekte nachträglich zu erweitern. Wenn das aber so ist, Pech gehabt.
Liegt vielleicht daran, dass in C/C++ unter OOP verstanden wird, dass man die Programmierung (Erstellen, Warten, Pflegen des Quelltextes) vereinfacht; ich dagegen Objekte aber als Objekte betrachten und verändern möchte, die man auslagern und bei bedarf wieder eingliedern kann, ebenso dass sie grundsätzlich veränderbar sind (zumindest Eigenschaften hinzuzufügen und zu entfernen) und zwar jederzeit.

Das JavaScript eine Interpretersprache ist, ist schon klar. Bloß mir noch nicht, wie genau dort auf unterster Ebene das Objekthandling implementiert wird. Mir kommt der Gedanke auf, dass dies nicht anders gemacht wird, als es sich hier gerade mit C aufzeigt. Man weiß ja von Maschinencodeseite, dass es grundsätzlich möglich ist, auch zur Laufzeit neuen Maschinencode zu generieren, der auch ausgeführt werden kann - also sich selbst verändernder Code. Dass das in geschützen Modi der CPUs ab 80386 anders oder zumindest nicht mehr so einfach jederzeit möglich ist, weil es eben Privileglevel gibt, ist eine andere Sache.

Bei C/C++ gibt es std::list
So kann man zur Laufzeit Kopien von Objekten erstellen und diese untereinander per Listen verketten und so verwalten.



MfG

[HaWe]

nein, mit C++ auf Microprozessor-Basis (AVR, ARM, ESP) sehe ich keine Chance.
Eventuell geht es über Betriebssysteme mit dynamischen Link-Libraries (DLL wie bei Windows), wobei eine DLL zur Laufzeit erzeugt und dann neu eingelinkt wird...
Aber Interpreter wie Javascript arbeiten komplett anders als executables aus C++ Programmen, wie Klebwax schon schrieb, und Interpreter-Code ist auch um 10er-Potenzen (1/100 oder gar 1/1000) langsamer.
OOP sagt auch nur aus, dass grundsätzlich objektorientiert programmiert werden kann (Objekte, Instanzen, Vererbung) und sagt nichts darüber aus, was man damit machen kann oder auch nicht.

[Ceos]

Ich verstehe gerade nicht warum man ein Objekt zur Laufzeit überhaupt einen neuen Member hinzufügen muss.

Wenn man weis was man möchte braucht man doch zur Laufzeit nichts hinzufügen!? In Java (Am Beispiel modded Minecraft) kann man Klassen und daraus resultierende Objekte manipulieren und neue Member hinzufügen weil man zum Beispiel die Funktion einer Tür erweitern möchte ohne eine gänzlich neue Türklasse zu erstellen. Aber da geht es ja nur darum die Funktionalität zu erweitern und das patchen der Klassen funktioniert auch nur solange gut, wie von der Klasse auch noch kein Obejkt erzeugt worden ist!

meinObjekt.Name2 = "Müller"; einfach so funktionieren wird, wenn Name2 nicht schon in meinObjekt existiert hat.
Aber vielleicht funktionbiert es ja auch mit: meinObjekt.Name2 = new String("Müller"); ???

Wenn es darum geht, warum nicht einfach

meinObjekt.Namen[2] = "Müller";

wobei Namen ein Listen-Objekt ist

[Moppi]

Wenn man weis was man möchte braucht man doch zur Laufzeit nichts hinzufügen!?

Doch schon. Es gibt ganz einfache Beispiele, wie die einer Schallplattensammlung. Wo Du einfach neue Objekte hinzufügen möchtest, ohne dass das z.B. auf 50 Objekte beschränkt wäre. Während Schallplatten bestimmte Informationen hergaben, die man in Eigenschaften eintragen könnte, könnte es sein, dass CDs noch eine weitere Eigenschaft haben, die man auch gerne hinzufügen würde, ohne den Programmcode dafür ändern zu müssen.



MfG

[Ceos]

Wo Du einfach neue Objekte hinzufügen möchtest, ohne dass das z.B. auf 50 Objekte beschränkt wäre.

Exakt das habe ich doch gerade beschrieben?! Ein std::list Objekt ist dynamisch, man kann also jederzeit (solange der RAM es hergibt) neue Objekte hinzufügen (bei einem µC würde ich aber eine LinkedList nehmen, keine Ahnung was das Äquivalent in C++ ist)

Während Schallplatten bestimmte Informationen hergaben, die man in Eigenschaften eintragen könnte, könnte es sein, dass CDs noch eine weitere Eigenschaft haben, die man auch gerne hinzufügen würde, ohne den Programmcode dafür ändern zu müssen.

Öhm wie wäre es wenn du dann einfach der Schallplatte beibringst dass sie sich selbst erklärt?! Warum müssen die Informationen über die Schallplatte in der "Liste" doppelt gespeichert werden, das ist doch Speicherverschwendung und die Liste interessiert nicht ob das eine Schallplatte aus Gold, Nickel, Paltin oder Uran ist oder nach Einhornpups duftet, solange sie mit der grundlegenden Schallplatte-Klasse kompatibel ist oder?

[HaWe]

@moppi:
bei deinem Schallplatten-Beispiel änderst du nicht das Objekt selber, sondern fügst nur dynamisch einen neuen Eintrag oder mehrere hinzu. Das ist genau das, was Adressen-Datenbanken machen, wenn du eine neue Person mit einer neuen Anschrift und Tel.-Nr. hinzufügst. Die Anzahl der Einträge ist nach oben offen, wenn du sie dynamisch erzeugst.
Du fügst dann aber kein neues Objekt (keine neue Klasse, keine neue Instanz) hinzu, für das z.B. auch die Anzahl der PCs und TVs im Haushalt oder die qm der Wohnung eingegeben werden kann.
Für ganz neue Felder musst du das Objekt von vornherein mit diesem Feld konstruieren und dann neu kompilieren.

https://www.eu-datenbank.de/datenban...c-datenbanken/

[Moppi]

Für ganz neue Felder musst du das Objekt von vornherein mit diesem Feld konstruieren und dann neu kompilieren.

Das haben wir weiter oben schon festgestellt, entspricht nicht so unbedingt meiner Vorstellung von Objektorientierung.

Stell Dir nur vor, Du könntest als Mensch dein Smartphone nicht händeln. Warum? Weil als Du geboren wurdest, das noch nicht existierte und das Gehirn nicht in der Lage ist, sich darauf einzustellen, weil die Struktur, um ein Smartphone zu handeln und Informationen darüber zu speichern, ja noch nicht existieren konnte. Du könntest es zwar sehen, aber nie zuordnen was es ist, bzw. wie man es bedient und was man damit tun kann; Du müsstest erst Nachkommen haben, deren Gehirn dann drauf ausgerichtet / eingestellt ist, weil es sich komplett neu entwickelt, also sozusagen neu kompiliert wird.

MfG

- - - Aktualisiert - - -

Aber: so weit ich gelesen habe, ist OOP dafür gedacht, die Softwareentwicklung zu vereinfachen. Nicht um selbstmodifizierenden Code zu erstellen.