Zitat:
@Hagen: Recht hast du mit der Aussage, daß die
VCL auch eine "
API" nur auf höherem Level ist. Leider ist die
VCL TThread-Klasse nich annähernd vergleichbar mit CThread. Sie ist "unter aller Sau"!
Da gebe ich dir Recht. Allerdings gerade in diesem Detail ist ein Vergleich ein bischen unfair. Aus Sicht der neueren
VCL kann die MFC nicht unter Linux verwendet werden. Aus Sicht der MFC kann diese sich enorm stark auf die Fähigkeiten des Windows
API's verlassen. Dadurch sind die Threadfähigleiten unter Windows bei der MFC besser aber unter Linux existieren diese Fähigleiten nicht für die MFC. Es ist also eine Frage der Zielsetzung
Zitat:
Ein echter VCLer sollte zwar, da bin ich ganz deiner Meinung, auch mit
API und
ASM umgehen können. Andererseits sieht man grade, daß viele Leute sich einfach der Komponenten anderer bedienen, diese aber nichtmal dann bedienen (oder gar anpassen) können, wenn der Source vorhanden ist.
Das empfinde ich nicht als schlimm. Ich meinte unter "
VCL-Coder" ein Programmierer der neue Komponenten für die
VCL schreibt. Man muß also nochmals differenzieren. Programmierer die Komponenten für die
VCL entwicklen können, müssen auch das
API beherrschen.
VCL Anwednungsprogrammierer wiederum benötigen kein
API Wissen und müssen nur in der Lage sein die
VCL-Komponenten anzuwenden. Genau diese Abstrahierbarkeit ist der entscheidende Vorteil der
VCL.
Mir als Anwendungsentwickler wäre es am liebsten wenn ich alles per Drag&Drop coden könnte ohne eine einzigste Sourcezeile schreiben zu müssen. Sollte es so eine
VCL geben würde mein Entwicklungsaufwand drastisch reduzieren. Allerdings verlange ich von so einem Tool viel mehr als das was man momentan auf dem Markt findet. Trotzdem programmiere ich gerne weiterhin auf
API und Assembler, aber eben mit andere Aufgabenstellung.
Gruß Hagen