>>155041>>155042>>155045Am Kern vorbeigeredet. Es geht nicht darum, dass das Ergebnis fehlerhaft ist. Es geht darum, dass es nicht implementierbar ist - egal in welcher Sprache.
Um es implementierbar zu machen, muss man seine Prioriät setzen, und eine Sache davon aufgeben.
Erstmal: Es wurde damit gezeigt, dass es kein reines C++-Problem ist. Keine Ahnung, warum der Punkt überhaupt zur Debatte stand, und wohin das führen sollte, aber egal. Bereits im obigen Code-Beispiel aus
>>154245 befindet sich in
diff2 bei der Array-Subskribierung
arr[i+1] und
arr[i] Undefined Behavior. Für die dabei auftretende Zeigeraddition muss der Zeiger dem Array-Elementtyp entsprechen (5.7.7 [expr.add], siehe auch explizite Notiz dort). Dementsprechend ist beim ADA-Code auch kaum etwas anderes los: Es hat "implementierungsabhängige Resultate", d.h. hierbei fehlerhaft. Es geht aber nicht um die Fehlerhaftigkeit - es geht darum, _warum_ man es entweder nur fehlerhaft oder (durch Sprachverbot) garnicht machen kann.
Wie schon gesagt: Man muss sich zwischen Werte-Arrays und Vererbung im OOP-Stil entscheiden.
>Java
>C#
Und diese haben diese Entscheidung genau so getroffen: Sie erlauben keine Werte-Arrays von Klassen. Es ist gerade eine Bestätigung von dem, was Felix sagt.
Das Problem von Werte-Arrays und Vererbung wurde also einfach versteckt, indem dem Programmierer verboten wurde, in die Nähe davon zu kommen.
Die beiden Sprachen unterscheiden dabei explizit zwischen Werten und Referenzen (Java: Primitives und Objects, C#: Value Types und Reference Types). Die üblichen Klassen, insbesondere bei Vererbung, fallen dann zu jeweils letzterer Gruppe (Objects bzw. Reference Types). Damit kriegt man nur Referenzen und kann keine Werte-Arrays davon bauen. Man kann in C#
structs bauen, welche Value Types sind, aber Vererbung geht mit
structs in C# nicht. Erneute Bestätigung von dem, was Felix sagt.
Übrigens hat Java für sich erkannt (nachdem die sich so köstlich über C++ mokiert haben, dass C++ doch mit
class und
struct total doppelt-gemoppelt wäre), dass es doch eigentlich auch total knorke wäre, wenn man neben Klassen noch etwas anderes hätte, etwas, mit dem man (so wie in C# mit
structs) neue primitive Typen erschaffen könnte. Und daher haben sie Java JEP 401 aufgefahren.
Und wenn man reinschaut:
>
>A concrete value class is implicitly final and may have no subclasses.
https://openjdk.org/jeps/401
Also haben sie damit zwar Werte-Arrays erlaubt, aber genau dabei dann Vererbung (bei der tatsächlich irgendwelche Attribute vererbt werden) verboten. Erneute Bestätigung von dem, was Felix sagt.
Kein Wunder: Oben wurde gezeigt, dass es logische Folge von Arrays und der Vererbung im OOP-Stil ist. Und dass es eine bewusste Entscheidung war - eine Entscheidung, die schlecht war. Merkwürdig, dass darauf keiner eingegangen ist. Vielleicht, weil eine Reaktion nach dem Motto "hahaha, dein Kot funktioniert so nicht, ganz schön doof, ne?" einfacher war, anstatt den zugrundeliegenden Grund zu ergründen, _warum_ das nicht funktionieren kann und _warum_ einige Sprachen das verbieten.
Felix dreht das jetzt daher einfach mal um: Wie würdet ihr Werte-Arrays + zur Laufzeit erweiterbare Vererbung für eine Sprache umsetzen wollen?
Da bisher niemand etwas gegen die sprachunabhängige, logische Folge der Inkompatibilität von Werte-Arrays und Vererbung im OOP-Stil gesagt hat: Es bleibt der Geburtsfehler von Vererbung im OOP-Stil. Sie haben lieber Werte-Arrays rausgekickt als Erweiterbarkeit zur Laufzeit. Eine schlechte Entscheidung.