Dienstag, 22. Juli 2008

Warum dynamic_cast?

Nach reiflicher Überlegung, und dazu gehört auch dieser interessante Fall der Separierung von Daten und Algorithmen, welcher kontrovers zum OOP Paradigma (Daten und Methoden zu vereinen) steht und in der rechten Abbildung dargestellt ist, bin ich darauf gekommen, dass dynamic_cast in erster Linie zur Einschränkung des Polymorphismus sinnvoll ist. Dies verschiebt logische Fehler in die Compile-Zeit.



Hier kennzeichnet sich auch der wichtigste Unterschied zwischen Template und Polymorphismus ab. Templates bleiben vollständig typisiert zur Compile-Zeit.

Außerdem ist mir in diesem Zusammenhang mit Hilfe von Claudius aufgefallen, dass der Polymorphismus ein Werkzeug zur untypisierten Programmierung ist. In diesem Sinne ist daher der dynamic_cast eine Wiederherstellung der typisierten Programmierung. So ermöglicht C++ eine erstrebenswerte Freiheit der Programmierung mit spezifischen und unspezifischen Typen. Dies Variationsmöglichkeit sollte/ist die optimale Lösung in der Frage Pro/Contra un-/spezifischen Datentypen. Jetzt liegt es nur noch am Programmierer sich einen unspezifischen Datentyp mit Hilfe des Polymorphismus zu erstellen. Man denke dabei einfach an den + Operator, welchen es schon bei Strings und bei Floats gibt. Wir nehmen dann das Werkzeug des Polymorphismus und erstellen uns ein Objekt, welches String und Float intern verwaltet und schreiben noch einen entsprechenden + und = Operator für diese verwaltende Objekt. Schon haben wir das Objekt, welchem sowohl Strings als auch Floats zugewiesen werden könne.


Ist PHP nicht eigenlich mit einer typisierten Programmiersprache geschrieben worden?


==> Resumee / Regel

der beiden Fragen "Warum Templates vs. Polymorphismus?" und "Warum dynamic_cast?"

Verwende Templates bei Algorithmen, welche um eine Funktionalität erweitert werden oder mit unterschiedlichen Datentypen arbeiten sollen.
Verwende Polymorphismus, wenn das OOP Paradigma bestehen bleibt. D.h. die Daten und der Algorithmus nicht getrennt werden. Die Algorithmen sind dann nur spezifisch für diese Daten.
(Nebenbei: die Frage der Responsibility bleibt unverändert. Die Objekte sind für das Laden und Löschen der Daten aus dem Speicher verantwortlich.)

--
Grüße

Warum Templates & Iterators statt Polymorphismus?

Contra:
  • Die Templates der Iteratoren machen den Code komplizierter.
  • Befinden sich Templates in Libraries, muss länger kompiliert werden. Zudem muss der gesamte Code zur Verfügung stehen.

Pro:
  • Es ist bei Verwendung von Iteratoren nicht notwendig eine Basisklasse zu verwenden, welche die gesamte Funktionalität der abgeleiteten Klasse abbildet. D.h. das umständliche erweitern der Basisklasse entfällt bei Iteratoren.
  • Code ist schneller, da keine Table-look-ups notwendig sind.


Mir ist noch unklar, weshalb es wirklich Sinn macht, diese zusätzliche Programmiersprache "Templates" in der Programmiersprache zu haben. (Es heißt, Templates haben die Funktionalität einer Programmiersprache.)

Vielleicht wird es bei der nächsten Frage ersichtlich.

--
Grüße

Dienstag, 15. Juli 2008

Borland Together (reg.) - Love at the first glimpse?


Hi freaks,

I call this 'love on the first glimpse':
Nice design. Simple overview. Flashy icon.
no unnecessary subwindow in the environment.
And all fits into my 'look and feel' of the windows OS.
Blue. (Hint: the default colour of the OS could be determined by an win-app. But Borland is here probably only assuming blue has every one.)

Ok your right, theres a Java Overhead, but the first glimpse is great.

[later on ...]


ups... it's more readable if it's marked. :-/






ups... alle windows in the windows ... ok eclipse like :-(




ok no program is running absolute determinstic?







ok I give it up!
Visual Studio (devenv.exe) is smaller than Together,
only sometimes the compiler (cl.exe) of VS goes up to this effort.


Resumee


Probably a nice tool, but I don't know how nice the fat mice is. It was to much overhead on this fat mice.


--
greet's
PS: I knew it, love at the first glimpse isn't what I thought.