Thema: c++ vs delphi

Einzelnen Beitrag anzeigen

Benutzerbild von mael
mael

Registriert seit: 13. Jan 2005
391 Beiträge
 
Delphi XE3 Professional
 
#52

Re: c++ vs delphi

  Alt 5. Apr 2005, 23:37
Zitat:
Zitat von mael:
Tut auch string-handling anbieten was unnötig ist für Pascal.
Kommt drauf an, welche RTL ich verwende. Und ganz ehrlich: ich verwende lieber die String-Funktionen der libc als die der FPC-RTL...
Wenn das so ist, solltest Du sowieso FP sein lassen.

Zitat:
Kannst du mir dann auch sagen, wie ich oben genannte POSIX-IPC mit JEDI hinkriege?
System V IPC Sachen sind in Kylix libc.pas definiert, JEDI hat, bis jetzt, soweit ich weiß dafür keine Unterstützung. Die pthread.h ist aber kurz und schnell übersetzt, also kein wirkliches Hindernis. Wie wäre es: Übersetzte es und schick es auf die JEDI mailing Liste.

Zitat:
Die erweiterten Möglichkeiten des LVs kriegt man damit trotzdem nicht (z.B. Kacheln).
Richtig das fehlt, sowas ist aber kein Konzept-Fehler sowie bei GTK für Windows, sondern ein nicht implementiertes Feature. Sicherlich weit weniger tragisch und vorallem sehr viel leichter zu korrigieren.

Zitat:
Und warum pinselt man sich Labels selbst auf den Canvas, wenn es doch unter den Windows-Controls so schöne Dinge wie STATICs gibt?
Es gibt TStaticText wenn man möchte, Labels sind Resourcenschonender. Gerade unter Win9x sind Fensterresourcen ziemlich begrenzt.

Zitat:
Zitat:
Schau dir mal ne Qt Anwendung mit Themes an...
Sieht schön aus.
Wird nicht korrekt gezeichnet, die Menüs wackeln hin und her, die Shortcuts sind schlecht implementiert, Teile werden nicht gezeichnet (z.B. beim PageControl)

Zitat:
Dann benutz' doch Windows-Anwendungen. Ich sehe nicht, wo dein Problem liegt. Unter Windows kommst du mit GTK und Qt nur dann in Berührung, wenn du auf Linux-Feeling nicht verzichten willst und dir entsprechend portierte Linux-Programme zulegst. Ich wüsste kein Projekt, das von Anfang an ausschließlich für Windows entwickelt wurde und GTK benutzt.
*Ich* will Portability, und ich benutze dafür liebend gerne freie Toolkits.
Du ignorierst einfach was ich sage. Es geht nicht was für Programme ich verwenden will, es geht darum das GTK sich nicht an Windows hält, und auch wenn man Crossplattform ist muß man trotzdem sich ans BS halten wie Firefox. Und daher ist GTK keine gute Basis um Programme zu schreiben. Außerdem werden häufig auch Programme von Windows nach Linux portiert. Z.B. PC-Bibliothek, Qt hat der heutigen Office-Bibliothek nicht gut getan.

Zitat:
Und ich habe schon gesagt daß du dann für jeden popeligen Windowmanager eine eigene GUI schreiben müsstest, weil jeder irgendwas anders macht, wenn du für alles immer und überall die native widgets nehmen willst.
Lies richtig, es geht um die Frameworks. Die sollen sich nach dem Standard richten, wenn sie das tun, mußt DU Dich nicht um die Details kümmern. Die Kritik ist: sie tun es nicht!

Zitat:
Aber ein schlechter Kompromiss, genausogut könnte man die VCL erweitern und Wrapper um die X Window API machen und eventl. noch Window Manager berücksichtigen. Ein ordentlicher Pascal-Wrapper dafür wäre durchaus machbar und von allen verwendbar (wodurch sich die Last verteilt) aber eben nicht auf GTK basiert.
Zitat:
Du hast nie ein reines X-Programm gesehen, oder?
Ich habe sogar schon eines programmiert. Und X bietet auch Fensterchen, Menüs und Nachrichten, Maus, ... bietet zwar nicht soviel wie Windows und keine Datei-Dialoge aber darum soll sich ja GTK und co kümmern, aber nicht einfach alles selbst machen. Wiederverwenden was da ist.

Zitat:
Unsinn, nur Win32 API und X Window API, der Window Manager(für Unix) macht kaum mehr als die Darstellung. Um die Abweichungen muß sich außerdem GTK auch kümmern, und das tut es auch nicht immer so schön.
Zitat:
Du hast tatsächlich nie ein X-Programm gesehen
Und Du noch nie was von einem anständigen Gespräch gehört, ich maße mir nicht an über Dich zu urteilen.

Zitat:
Wenn du optisch auf das Niveau von Windows kommen willst, hast du schon fast ein fertiges TK, da kannst du auch ein fertiges (GTK, Qt, ...) nehmen.
Nicht optisch, sondern von der Komplexität der Steuerelemente her.

Zitat:
Zitat:
Stöhn nicht, es geht darum das Windows Software wie Windows Software funktionieren und aussehen muß, gleiches gilt für Linux Software und für Crossplattform.
Windows-Software sieht i.A. wie Windows-Software aus. Linux-Feeling kriegst du nur, wenn du Software, die für Linux entwickelt wurde, nach Windows rüberschleppst.
Falsch, alle Crossplattform Programme sehen so aus, und das ist unakzeptabel.

Zitat:
Schön, wenn du 300 Sprachen kannst, einige Programmierer beschäftigen sich aber mehr mit den Programmfeatures und mit den Bugfixes als mit Oberflächenpolierung auf Systemen, die sie nur aus Gefälligkeit unterstützen, weil die Nachfrage für einen Windows-Port so groß war.
Warum schreibt man denn Programme? Damit sie von jemanden genutzt werden können, und nicht um zu sagen "ich bin so toll, warum gefällt Dir Trottel nicht wie mein Programm funktioniert".
GUI Design ist sehr wichtig, es geht ja nicht um kleine Zeichenfehler, sondern das jedes Programm anders funktioniert und dafür gibt es BSe. Verwendet man Bordmittel beherrscht man ein Programm im Handumdrehen, sonst ist dauerend Einarbeitung nötig = unproduktiv.

Zitat:
Ja, mit einem heidenaufwand. An der Native Widget Unterstützung für OpenOffice.org2 hat man über ein Jahr rumentwickelt. Zeit, die man bei kleineren Projekten mit wneiger Entwicklern besser in das Programm selbst stecken sollte.
Ist doch gut das sie sich die Mühe machen. In Zukunft kann man dann auf dieser Arbeit aufbauen. (Du scheinst immer noch nicht zu verstehen, daß ich nicht verlange, daß jeder alles nochmal neu macht, aber das es ein gutes Framework geben muß.)

Zitat:
Ganz ehrlich, ohne dir nahetreten zu wollen, mir scheint, als hättest du dir vieles nicht genau angesehen.
So ein Kommentar kommt immer wenn die Argumente ausgehen

Zitat von mael:
Meinungen über die Produktivität einer IDE sind immer subjektiv. Es gibt auch Leute, die lieben Lazarus.
Schön das Du auch mal endlich merkst das nicht deine Sicht die Wahrheit ist.
HxD, schneller Hexeditor:
http://mh-nexus.de/hxd
  Mit Zitat antworten Zitat