OOP und Klassenhierarchien

Finalspace · 28. März 2017

andy_m4 schrieb:
Ergänzung (28. März 2017)

Das kannst Du auch bei einem klassischen Toolkit haben. Gerade Swing kennt z.B. Modellklassen die Du dafür benutzen kannst um Deine Daten aus einer Datenbank, Datei, whatever zu holen.

Das nennt man dann Binding, bzw. Data-Binding und gibts schon sehr lange.
Delphi war meines wissens mit seiner Datenbankgeschichte und direkte UI-Binding (z.b. DBGrid) einer der ersten Vertreter in diesem Bereich.

andy_m4 schrieb:
Das ist bei Green-Threads (Java-Sprech) so, aber nicht bei native-threads die auf mehrere CPU-Kerne verteilt werden.

siehe dazu: https://de.wikipedia.org/wiki/Thread_(Informatik)

Sofern sie auf mehrere Kerne aufgeteilt sind werden sie parallel ausgeführt.

Das gilt für SMT a-ka Hyerthreading. Sind die Threads auf mehrere Kerne verteilt hast Du natürlich auch alle Register doppelt.

Sollte man eigentlich alles wissen, wenn man seit 1995 programmiert. ;-)

Das ist das erste mal das ich den Begriff "Green Threads" höre, kannte den Begriff nicht - naja man lernt nie aus.

Habe ich doch geschrieben das die Instruktionen auf modernen CPU´s parallelisiert ausgeführt werden.

Aber bin kein Fachmann wenns um Multicoreprogrammierung geht - das nutze ich nur wenn ichs brauche, z.b. in einer Workerqueue und jeder Worker ist mit der Thread-Affinity-Mask einem Core zugewiesen. Mehr mache ich mit Threads privat nicht.

Beruflich in C#/Java nutze ich wenn es geht Threadpools, was im Grunde dem entspricht was ich in C mache -> Worker Queue.

andy_m4 schrieb:
Das Problem ist, dass Multithreaded-Programmierung nicht unbedingt trivial ist und deshalb noch teilweise sehr verhalten eingesetzt wird. Auch GUI-Toolkits können nicht unbedingt immer damit umgehen, wenn ein zweiter Thread ihnen ins Handwerk pfuscht.

Meine UI´s laufen immer im Haupt-Render-Thread, da ist es mir egal, aber ja Multithreading ist kein leichtes Thema. Aber wenn Daten von anderen Threads abgerufen werden, dann wird das immer über CAS oder Ticketmutex geschützt, inkl. Lese -und Schreibbarrieren.

andy_m4 schrieb:
Ich kenn jetzt Visual Studio nicht, aber entweder unterbricht der während einer Debugging-Session die jeweils anderen Threads oder Du hast eine Applikation gedebugt, die green-threaded ist.

Visual Studio kann ne Menge mit Threads machen, z.b. alle bis auf einen pausieren, welche wieder zurückholen, die Register anzeigen und noch mehr.

andy_m4 schrieb:
Klassen musst Du auch in Java deklarieren. Oder was meinst Du mit Klassendeklaration ?

Ich rede von dem Unterschied zwischen Deklaration und Implementierung, sprich du definiert deine Klasse in einer Header-Datei und implementierst den Code in der Translation-Unit.

In Delphi macht man das nach dem "interface" aber vor dem "implementation" Abschnitt.
In C++ ist es schlichtweg immer getrennt in .h und .cpp.

andy_m4 schrieb:
Genau. Properties verschleiern so ein bisschen, was da wirklich passiert. Also eigentlich genau das, was Du nicht magst. :-)

Jop ich mag Properties nicht, alles Public und fertig.
Nur wenn etwas explizit geschützt werden soll, dann wirds private inkl. public Property und Getter und Setter.

andy_m4 schrieb:
Templates sind für Metaprogrammierung. Was Du vermutlich meinst, ist Metaprogrammierung zur Laufzeit.

Jop, ich mein Metaprogrammierung zur Laufzeit.

TheCadillacMan · 28. März 2017

andy_m4 schrieb:
Bei C# fängts ja schon damit an, dass Du primitive Datentypen hast die eben keine Objekte sind.

Da verwechselst du was mit Java.

Alle "primitiven" Datentypen (string, int, short etc.) in C# sind nur ein Alias für entsprechende CLR-Typen (String, Int32, Int16 etc.). Auch wenn das ValueTypes sind, erben sie letztendlich von System.Object und sind somit auch Objekte.

andy_m4 · 28. März 2017

Finalspace schrieb:
Das nennt man dann Binding, bzw. Data-Binding und gibts schon sehr lange.

Ich meinte eigentlich das klassische Model-View-Controller-Konzept. Du hast halt eine View-Klasse die das was sie darstellt quasi aus der Model.Klasse rauszieht. Ob das nu Datenbank ist oder ein Zufalls generator spielt keine Rolle.
Data-Binding ist somit schon eine Spezialisierung.

Finalspace schrieb:
Delphi war meines wissens mit seiner Datenbankgeschichte und direkte UI-Binding (z.b. DBGrid) einer der ersten Vertreter in diesem Bereich.

Das kann gut sein. Borland war gerade Anfang der 90er Jahre sehr bemüht um die ganzen Datenbankgeschichten.

Finalspace schrieb:
Das ist das erste mal das ich den Begriff "Green Threads" höre, kannte den Begriff nicht - naja man lernt nie aus.

Wie gesagt, ist eher Java-Sprech.

Finalspace schrieb:
Habe ich doch geschrieben das die Instruktionen auf modernen CPU´s parallelisiert ausgeführt werden.

Wichtig ist halt nur zu wissen, dass es bei Multicore eben keine scheinbare Parallelität durch Zeitscheiben gibt, sondern tatsächlich echte Parallelität.

Finalspace schrieb:
Aber bin kein Fachmann wenns um Multicoreprogrammierung geht - das nutze ich nur wenn ichs brauche, z.b. in einer Workerqueue und jeder Worker ist mit der Thread-Affinity-Mask einem Core zugewiesen. Mehr mache ich mit Threads privat nicht.

Kommt halt immer auf die Anforderungen drauf an. Sinnvoll ist es dann, wenn man eben Rechenpower braucht. Dann bedeutet eben zwei Kerne zu Benutzen im Idealfall doppelt so schnell (in der Praxis hängt es natürlich immer vom konkreten Fall ab).

Finalspace schrieb:
Visual Studio kann ne Menge mit Threads machen, z.b. alle bis auf einen pausieren, welche wieder zurückholen, die Register anzeigen und noch mehr.

Irgendwie mache ich klassisches Debugging nur selten. Da schreib ich lieber die Infos die ich benötige als Log. Keine Ahnung, woran es liegt. Früher war ich wesentlich öfter im Debugger unterwegs.

Finalspace schrieb:
Ich rede von dem Unterschied zwischen Deklaration und Implementierung, sprich du definiert deine Klasse in einer Header-Datei und implementierst den Code in der Translation-Unit..

Ja. Dieser Header-Dateien-Quatsch ist ja allgemein sehr antiquiert.

Ergänzung (28. März 2017)

TheCadillacMan schrieb:
Da verwechselst du was mit Java.

Alle "primitiven" Datentypen (string, int, short etc.) in C# sind nur ein Alias für entsprechende CLR-Typen (String, Int32, Int16 etc.). Auch wenn das ValueTypes sind, erben sie letztendlich von System.Object und sind somit auch Objekte.

Ok. Bisher dachte ich immer, C# macht an solchen Stellen Autoboxing.
https://msdn.microsoft.com/de-de/library/yz2be5wk(v=vs.90).aspx

The Ripper · 28. März 2017

Und das merkst Du halt an vielen Stellen. Außerdem wurden viele Dinge weggelassen die OOP ausmachen (Reflection, echte Polymophie etc.).

Könntest du ein paar von denen vielen Stellen bitte nennen?

Reflection hat übrigens nichts mit OOP zu tun und was ist echte Polymorphie?

Finalspace · 29. März 2017

Betreffend kontra-OOP bin ich gestern Abend auf ein paar Videos gestoßen:
CppCon 2014: Mike Acton "Data-Oriented Design and C++"
Casey and the Holy OOP Grail
Private Data & Getters/Setters
OOP Rant

Spiegelt zum Großteil meine Meinung wieder.

TheCadillacMan · 29. März 2017

andy_m4 schrieb:
Ok. Bisher dachte ich immer, C# macht an solchen Stellen Autoboxing.

Das hat nur mit der Speicherallokierung zu tun (Stack vs. Heap).
Bis auf die fehlende "abgehende" Vererbung (selbst erben sie von ValueType) und das Zuweisungsverhalten (Referenzkopie vs. Kopie) verhalten sich Werte- und Referenztypen praktisch identisch.

Die (wirklich) primitiven Typen in Java (int vs. Integer) sind da deutlich eingeschränkter.

Suche

OOP und Klassenhierarchien

Finalspace

Lt. Junior Grade

TheCadillacMan

Captain

andy_m4

Vice Admiral

The Ripper

Lt. Commander

Finalspace

Lt. Junior Grade

TheCadillacMan

Captain