c++ vs delphi

[tommie-lie]

Zitat:

Zitat von Binärbaum

Code:

{
  int a;
  char b;

  b= 'A';
  a= 7;
  b= b+a;///na, was sagst du dazu?
}

Dazu sage ich, daß das eines der Dinge ist, die mir an C gefallen, nämlich daß die Daten so gehandhabt werden, wie sie für den Prozessor vorliegen und der Programmierer nicht meilenweit von der Architektur alles mit Samthandschuhen serviert bekommt.
Der C-Char und der Delphi-Char sind zwei verschiedene Datentypen. Ein Char in C ist nur ein Byte, was auch immer ich darin speichere und als was auch immer ich dieses Byte interpretiere. "c = 'A'" ist eine Zuweisung, wobei "'A'" zwar vom Menschen als Buchstabe interpretiert wird, in Wirklichkeit jedoch nichts anderes als die Zahl 65 ist. Genauso wie ShortInt und LongInt in Delphi sind auch char und int in C zuweisungskompatibel. b enthält danach den Wert 65+7=72. Versuche ich das wieder als Zeichen zu interpretieren (indem ich es ohne in einen String umzuwandeln ausgebe, kriege ich das Zeichen "H", aber nur, weil die Konsole die Zahl 72 aus dem Buffer als H auf den Bidlschirm pinselt.
Die korrekte Delphi-Übersetzung wäre also eher:

Delphi-Quellcode:

var
  a: LongInt;
  b: ShortInt;
begin
  b := Ord('A'); //(oder "b := Byte('A');", ich weiß nicht, ob der Compiler sowas zulässt,
                 // vielleicht geht auch schon das implizite Casting mit "b := 'A';"
  a := 7;
  b := b + a;
end;

Zitat:

Zitat von malo

Bei folgendem Code kommt aber auch eine AV ;-)

Code:

{
  printf(b);
}

Klar, bei

Delphi-Quellcode:

var
  x: PLongWord;
begin
  x := nil;
  x^ := 123;
end;

kommt auch eine :roll:

Wenn man printf() richtig anwendet, kommt keine Zugriffsverletzung, sondern wie oben gesagt ein "H", da b (72) als ASCII-Zeichen (%c) interpretiert wird:

Code:

{
  int a;
  char b;

  b= 'A';
  a= 7;
  b= b+a;///na, was sagst du dazu?
  printf("%c", b);
}

So, nu aber Schluß mit dem versuchten Beweis, daß C das Böse[tm] selbst ist.

Zitat:

Zitat von mael

Es bleibt natürlich der Nachteil der Header-Übersetzungen (ist aber eigentlich nur fürs DDK relevant).

Und für FreePascal, wenn man's unter Linux einsetzen will :mrgreen:

Zitat:

Zitat von mael

Diese peinliche Superhero Werbung von Borland ist ja auch dem Delphi-Ansehen nicht gerade zuträglich.

Vielleicht Kompensation für einen kleinen... Entwicklungsstand :mrgreen:
Und Hunde die Bellen, beißen nicht...


Edit: Mann, mann, nichtmal taggen kann ich richtig :-?

[Binärbaum]

Zitat:

Zitat von bigg

Zitat:

Bei folgendem Code kommt aber auch eine AV

ja und genau das kann unvorhergesehene Fehler verursachen,
kann aber auch Vorteile haben.

Ich sehe im Moment keine Vorteile an einer AV :gruebel: außer dass man damit ziemlich abrupt das Programm beenden kann. :mrgreen: Aber dafür gibt es doch bessere Möglichkeiten.
Also IMHO sollte der Compiler sowas auch erkennen, wenn schon zur Compilerzeit klar ist, dass durch den Code eine AV ausgelöst wird. Aber das geht jetzt schon mehr in Richtung Compiler als Sprache...

MfG
Binärbaum

[Michael_Bayer]

Ich glaube, das sagt einiges:
Monster.de Sucherergebnis (leider keine Trefferanzahl - nur Seitenzahl)

Suche nach C++: 18 Seiten
Suche nach Delphi: 1 Seite
Suche nach C#: 3 Seiten

Man beachte, dass C# die "jüngste" Sprache ist...

[bigg]

Zitat:

Ich sehe im Moment keine Vorteile an einer AV

Die muss doch nicht zwangsweise immer auftretten :zwinker:
In diesem Fall ist das natürlich ... äh ... doof :roll:

[sECuRE]

Hi,

Zitat:

Zitat von Pseudemys Nelsoni

Zitat:

C++ soll angeblich leichter sein als C

Kaum, da C++ eine Obermenge von C ist, d.h alles was in C geht, geht auch in C++. Demnach kann C++ höchstens schwerer(wenn überhaupt) sein als C.

nunja, in C++ steht dir die STL zur Verfügung, die insbesondere das Handling der Strings einfacher macht.

cu

[mael]

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von mael

Es bleibt natürlich der Nachteil der Header-Übersetzungen (ist aber eigentlich nur fürs DDK relevant).

Und für FreePascal, wenn man's unter Linux einsetzen will :mrgreen:

Die wichtigen Dinger sind schon übersetzt, wie gesagt, ich halte nichts davon zuviel Fremdkode zu verwenden. Programme die so geschrieben sind neigen zu Blähungen (siehe mal Adobe Reader, die Liste der Fremdbeiträge ist enorm) und Fehlern. Immer das Neuste zu verwenden ist auch nicht unbedingt gut. Okay jetzt sage ich es: ich finde GTK, Qt schei*e, auch wenn es dafürÜbersetzungen gibt. Man schaue sich mal die GUIs an, überall kleine Fehler, nicht das Standardaussehen, eigene Komponenten anstatt die des OS (z.B. Dateidialog). Das ist nicht was man als Firma gebrauchen kann. Linux ist eher fürs Web/Server Zeugs im kommerziellen Bereich interessant, und dafür hat man mit Kylix oder FreePascal was man braucht.

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von mael

Diese peinliche Superhero Werbung von Borland ist ja auch dem Delphi-Ansehen nicht gerade zuträglich.

Vielleicht Kompensation für einen kleinen... Entwicklungsstand :mrgreen:
Und Hunde die Bellen, beißen nicht...

Soweit würde ich nicht gehen, ich finde eher daß die Entwicklung nicht weiter geht. Zuviel Zeit wird in Zusatzkomponenten investiert anstatt die Kern-Eigenschaften zu verbessern, wie Kompiler und Sprache. U.a. einer der Gründe warum ich Datenbanken und Webzeugs nicht so mag, sie ziehen zuviele Resourcen auf sich.

[tommie-lie]

Zitat:

Zitat von mael

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von mael

Es bleibt natürlich der Nachteil der Header-Übersetzungen (ist aber eigentlich nur fürs DDK relevant).

Und für FreePascal, wenn man's unter Linux einsetzen will :mrgreen:

Die wichtigen Dinger sind schon übersetzt

Ja, nur teilweise falsch und unvollständig, zum Bleistift popen() und pclose() oder einige Signal-Handling-Funktionen. Wenn ich Units als deprecated deklariere (oldlinux), sollte ich auch dafür sorgen, daß die gleiche Funktionalität in den neuren Units zur Verfügung steht (und ein "external blubb" tut ja nun wirklich nicht weh...).

Zitat:

Zitat von mael

wie gesagt, ich halte nichts davon zuviel Fremdkode zu verwenden

Oh, ich halte sehr viel davon, vorhandene und standardisierte Sachen nicht wieder und immer wieder neu zu implementieren. Die libc ist da, warum sind nicht alle deren Funktionen entsprechend der Docs importiert worden?

Zitat:

Zitat von mael

Okay jetzt sage ich es: ich finde GTK, Qt schei*e, auch wenn es dafürÜbersetzungen gibt. Man schaue sich mal die GUIs an, überall kleine Fehler, nicht das Standardaussehen, eigene Komponenten anstatt die des OS (z.B. Dateidialog).

Ich finde nonVCL sche*e. Überall baut man sich seine Dialoge selber, sie sehen nicht aus wie die VCL-Dinger aus Delphi, sie können teilweise viel mehr und sind daher mit Funktioenn überfüllt. Und an das einheitliche Layout halten sie sich auch noch!
Merkste wat? Jenaaaau, es kommt drauf an, *wie* man etwas macht. Daß nicht jedes Programm die Gnome-Filedialogs benutzt, hat überhaupt rein garnix mit GTK zu tun.

Zitat:

Zitat von mael

Soweit würde ich nicht gehen, ich finde eher daß die Entwicklung nicht weiter geht.

Aber sie bellen laut, mit ihrem Superhero. Trotzdem beißt die IDE lange nicht mehr, weil sie der Entwicklung zu weit zurückhinken. Microsoft hat Produktivitätsfeatures in der IDE, von denen träumt Borland nachts. Mit Delphi8/2005 sind sie ja immerhin in Richtung *ein* Fenster für *eine* IDE gegangen, ist schonmal was Feines, wenn man's richtig macht. (Umso schlimmer, daß Lazarus es immer noch nicht auf die Reihe kriegt, die zahllosen Fenster vernünftig zusammenzufassen, wenn Metacity (und die meisten anderen WMs) nicht die Möglichkeit für mehrere virtuelle Desktops hätte, Lazarus wäre nicht benutzbar, wenn man nebenbei noch Mailclient, Browser, Dokumentationen und sonstiges offen hat.)

[mael]

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von mael

wie gesagt, ich halte nichts davon zuviel Fremdkode zu verwenden

Oh, ich halte sehr viel davon, vorhandene und standardisierte Sachen nicht wieder und immer wieder neu zu implementieren. Die libc ist da, warum sind nicht alle deren Funktionen entsprechend der Docs importiert worden?

Libc hat in Delphi/Pascal nichts zu suchen. Dafür gibt es Jedi. Was C++ angeht verwendet man natürlich libc und STL. Aber z.b. nicht die verkorkste HDR-Image-library die war mist.

Zitat:

Zitat von tommie-lie

Ich finde nonVCL sche*e. Überall baut man sich seine Dialoge selber, sie sehen nicht aus wie die VCL-Dinger aus Delphi, sie können teilweise viel mehr und sind daher mit Funktioenn überfüllt. Und an das einheitliche Layout halten sie sich auch noch!
Merkste wat? Jenaaaau, es kommt drauf an, *wie* man etwas macht. Daß nicht jedes Programm die Gnome-Filedialogs benutzt, hat überhaupt rein garnix mit GTK zu tun.

Ich merke sehrwohl das Du da was vermischst. Es geht nicht um VCL oder nicht, sondern um die Standard BS-Dialoge. Ich hasse Programme die GTK-OpenDialog anstatt Windows-OpenDialog haben und die eben nicht leistungsfähiger sind. Die haben kein Explorer-Kontextmenü und häufig wird auch noch das Dateisystem à la Unix dargestellt. Umgekehrt mag ich es auch nicht in Unix Systemen wenn der Windows-Stil erzwungen wird (wie z.B. Teilweise in Kylix).
Zum Glück verwendet nicht jedes Programm den GTK DateiDialog, und natürlich hat das gerade was mit GTK zu tun :twisted: Ich meine selbst FireFox kriegt das gebacken.

Zitat:

Zitat von tommie-lie

Trotzdem beißt die IDE lange nicht mehr, weil sie der Entwicklung zu weit zurückhinken. Microsoft hat Produktivitätsfeatures in der IDE, von denen träumt Borland nachts.

Wenn man sauberen Kode schreibt ist Refactoring höchstens für Umbenennungen sinnvoll. Aber allgemein deutet häufige Nutzung auf schlechtes Design und Planung hin. Erst seit .NET hat MS VC++ einen ordentlichen Form-Designer, aber besser als in D7 ist der nicht. Die IDE ist auch nicht das Problem, sondern die fehlende Sprachentwicklung (von Delphi). D7 IDE mit GExperts da kommt MS VS nicht ran.

Zitat:

Zitat von tommie-lie

Mit Delphi8/2005 sind sie ja immerhin in Richtung *ein* Fenster für *eine* IDE gegangen, ist schonmal was Feines, wenn man's richtig macht.

Geschmackssache

Zitat:

Zitat von tommie-lie

(Umso schlimmer, daß Lazarus es immer noch nicht auf die Reihe kriegt, die zahllosen Fenster vernünftig zusammenzufassen, wenn Metacity (und die meisten anderen WMs) nicht die Möglichkeit für mehrere virtuelle Desktops hätte, Lazarus wäre nicht benutzbar, wenn man nebenbei noch Mailclient, Browser, Dokumentationen und sonstiges offen hat.)

Ich verwende Lazarus nicht, weil es schlecht ist: buggy, zusammengestückelt, gehackt (so wie viele C++ IDEs).
Mit Delphi 7, also getrennten Fenstern, und x weiteren geöffneten Programmen habe ich keine Probleme. Für Multimonitornutzer sind gedockte Fenster unpraktisch.

Aber das alles wird OT.

[tommie-lie]

Zitat:

Zitat von mael

Libc hat in Delphi/Pascal nichts zu suchen. Dafür gibt es Jedi. Was C++ angeht verwendet man natürlich libc und STL. Aber z.b. nicht die verkorkste HDR-Image-library die war mist.

*räusper*
Auf einem GNU-System will ich auch die offizielle GNU-Laufzeitumgebung benutzen, und die ist nunmal die GNU C Library. Die bietet Dinge wie Signal Handling, IPC und sogar ein Waschbecken. Außerdem kann man davon ausgehen, daß sie auf jedem GNU-System vorhanden ist, daher kann ich sie dynamisch linken und meine Echse bleibt schön klein.
Und wie öffne ich mit JEDI einen POSIX-Pipe zu einem Prozess, von dem ich die PID habe?

Zitat:

Zitat von mael

Ich merke sehrwohl das Du da was vermischst. Es geht nicht um VCL oder nicht

Nein, darum ging es mir auch nicht...
Die VCL hält sich auch nicht immer an das, was Windows ihr vor die Füße wirft. Und seit XP sehen sie auch nicht immer so aus, wie alle anderen Windows-Anwendungen. Deswegen die vCL zu verteufeln ist aber auch nicht das Wahre. Wenn du sämtliche Windows-Features haben willst, musst du sie dir selber besorgen und nicht Fremdkapselungen benutzen. Erst Recht nicht GTK oder Qt, die auch noch komplett eigene Widgets zur Verfügung stellen.

Zitat:

Zitat von mael

sondern um die Standard BS-Dialoge. Ich hasse Programme die GTK-OpenDialog anstatt Windows-OpenDialog haben und die eben nicht leistungsfähiger sind.

Ah, I see... Und wie stellst du dir das unter Linux mit dem Windows-Dialog vor? Wine zu erzwingen kann's ja wohl nicht sein... Wenn ich mein Programm nur unter Windows veröffnetlichen will, brauche ich kein GTK, da komme ich mit den Windows Controls schneller und vor allem mit kleineren Programmen (keine GTK-Bibliotheken) ans Ziel. Wenn ich Programme für Windows und Linux bereitstellen will, muss ich eine gemeinsame Teilmenge finden. Und die ist nunmal nur GTK. Natürlich kann ich mir mehrere Versionen meines Quellcodes zulegen. Da wäre eine für Windows, eine für Gnome, eine für KDE, eine für xfce, eine für fvwm, eine für icewm, eine für fluxbox, eine für Enlightenment, eine für... fein, und du maintainst das dann? Abgemacht.

Zitat:

Zitat von mael

Die haben kein Explorer-Kontextmenü und häufig wird auch noch das Dateisystem à la Unix dargestellt.

Ach herrje. Dann benutz' Windows-Software, die hat auch windowsspezifische Dialoge und Features.

Zitat:

Zitat von mael

Ich meine selbst FireFox kriegt das gebacken.

Die haben auch genug maintainer für beide Plattformen. Bei OpenOffice.org hast du sogar im laufenden Betrieb die Wahl zwischen dem OO.o-eigenen (selbstgebastelten) Dialog und den System-Dialogen.

Zitat:

Zitat von mael

Wenn man sauberen Kode schreibt ist Refactoring höchstens für Umbenennungen sinnvoll. Aber allgemein deutet häufige Nutzung auf schlechtes Design und Planung hin.

Finde ich nicht, es weist lediglich auf gewachsenen, ergo entwickelten Code hin.

Zitat:

Zitat von mael

Zitat:

Zitat von tommie-lie

Mit Delphi8/2005 sind sie ja immerhin in Richtung *ein* Fenster für *eine* IDE gegangen, ist schonmal was Feines, wenn man's richtig macht.

Geschmackssache

Zugegeben.

Zitat:

Zitat von mael

Ich verwende Lazarus nicht, weil es schlecht ist: buggy, zusammengestückelt, gehackt (so wie viele C++ IDEs).

Aus den selben Gründen würde ich es ebenfalls nicht benutzen, aber mangels Alternative bin ich leider dazu gezwungen.

Zitat:

Zitat von mael

Mit Delphi 7, also getrennten Fenstern, und x weiteren geöffneten Programmen habe ich keine Probleme.

Für Multimonitornutzer sind gedockte Fenster unpraktisch.[/quote]Ja, Delphi legt dir auch nicht für jedes Fenster einen eigenen Eintrag in die Taskleiste und behandelt nicht jedes Fenster als getrenntes Fenster, sondern als Unterfenster des Hauptfensters, sodaß bei einem Klick auf ein belibebiges Fenster die gesamte IDE in den Vordergrund kommt. Lazarus macht das nicht.

Zitat:

Zitat von mael

Aber das alles wird OT.

Stimmt.

[mael]

Zitat:

Auf einem GNU-System will ich auch die offizielle GNU-Laufzeitumgebung benutzen, und die ist nunmal die GNU C Library.

Tut auch string-handling anbieten was unnötig ist für Pascal. Andere notwendige Sachen sind vorhanden, zumindest habe ich bis jetzt noch nichts gehabt was nicht übersetzt war und wofür pascal nicht selbst was bietet.

Zitat:

Die VCL hält sich auch nicht immer an das, was Windows ihr vor die Füße wirft.

Aber zu über 90%, XP konnte vorher nicht sein, aber es gibt ja D7 oder Lischkes Theme-Manager und das sieht genau wie XP aus weil es eben Win-Controls verwendet. VCL ist fast nur ein Wrapper.
Schau dir mal ne Qt Anwendung mit Themes an...

Zitat:

Erst Recht nicht GTK oder Qt, die auch noch komplett eigene Widgets zur Verfügung stellen.

Was genau das ist was ich nicht mag, ListView und TreeView von Windows sollten verwendet werden, ich will kein importiertes Linux.

Zitat:

Und wie stellst du dir das unter Linux mit dem Windows-Dialog vor?

Da sollte der Window-Manager Standard-Dialog verwendet werden (wie KDE oder GNOME ihn anbieten) und nur wenn nicht vorhanden dann GTK oder Qt Dialoge. Ich habe doch schon gesagt, unter Linux mag ich auch kein importiertes Windows. (siehe Bemerkung zu Kylix)

Zitat:

Wenn ich Programme für Windows und Linux bereitstellen will, muss ich eine gemeinsame Teilmenge finden. Und die ist nunmal nur GTK.

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:

Natürlich kann ich mir mehrere Versionen meines Quellcodes zulegen. Da wäre eine für Windows, eine für Gnome, eine für KDE, eine für xfce, eine für fvwm, eine für icewm, eine für fluxbox, eine für Enlightenment, eine für... fein, und du maintainst das dann? Abgemacht.

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:

Ach herrje.

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.
Ein Programm muß sich an das BS anpassen und nicht sein Heimatland importieren. Wenn ich ins Ausland gehe um dort zu leben lerne ich die Sprache dieses Landes und seine Bräuche.
Ich verlange nicht meine Wurstbude und mein Bier, und installiere mir meine eigene neutrale Zone, das ist unhöflich.

Zitat:

Zitat von mael

Ich meine selbst FireFox kriegt das gebacken.

Zitat:

Die haben auch genug maintainer für beide Plattformen. Bei OpenOffice.org hast du sogar im laufenden Betrieb die Wahl zwischen dem OO.o-eigenen (selbstgebastelten) Dialog und den System-Dialogen.

Sag ich ja, geht auch anders.

Zitat:

Zitat:

Zitat von mael

Wenn man sauberen Kode schreibt ist Refactoring höchstens für Umbenennungen sinnvoll. Aber allgemein deutet häufige Nutzung auf schlechtes Design und Planung hin.

Finde ich nicht, es weist lediglich auf gewachsenen, ergo entwickelten Code hin.

Schon, aber es sollte nicht soweit kommen, daß man nicht mehr ohne auskommt und daher die IDE für einen "unnutzbar" ist.

Zitat:

Zitat:

Zitat von mael

Mit Delphi 7, also getrennten Fenstern, und x weiteren geöffneten Programmen habe ich keine Probleme.

Für Multimonitornutzer sind gedockte Fenster unpraktisch.

Ja, Delphi legt dir auch nicht für jedes Fenster einen eigenen Eintrag in die Taskleiste und behandelt nicht jedes Fenster als getrenntes Fenster, sondern als Unterfenster des Hauptfensters, sodaß bei einem Klick auf ein belibebiges Fenster die gesamte IDE in den Vordergrund kommt. Lazarus macht das nicht.[/quote]
Das ist natürlich schlecht, solange hab ich mir das nichtmal angesehen.


P.S. Ich habe nichts gegen Linux. Auch nicht gegen OpenSource Frameworks, aber die mir bisher bekannten sind einfach unsauber. Dann MS VS hat sich gerade mal gemausert da ist jetzt die Borland IDE plötzlich total schlecht? Das finde ich doch etwas unobjektiv.
Momentan sind viele Lösungen (insbesondere GUI) nicht ausgereift sowohl für Pascal als auch für C++.

[tommie-lie]

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... Mit Kylix und Delphi hätte ich da weniger Bedenken.

Zitat:

Zitat von mael

Andere notwendige Sachen sind vorhanden, zumindest habe ich bis jetzt noch nichts gehabt was nicht übersetzt war und wofür pascal nicht selbst was bietet.

Kannst du mir dann auch sagen, wie ich oben genannte POSIX-IPC mit JEDI hinkriege?

Zitat:

Aber zu über 90%, XP konnte vorher nicht sein, aber es gibt ja D7 oder Lischkes Theme-Manager und das sieht genau wie XP aus weil es eben Win-Controls verwendet. VCL ist fast nur ein Wrapper.

Die erweiterten Möglichkeiten des LVs kriegt man damit trotzdem nicht (z.B. Kacheln).
Und warum pinselt man sich Labels selbst auf den Canvas, wenn es doch unter den Windows-Controls so schöne Dinge wie STATICs gibt? *Das* gehört auch dazu, wenn man sämtliche nativen Elemente unterstützen will.

Zitat:

Schau dir mal ne Qt Anwendung mit Themes an...

Sieht schön aus.

Zitat:

Was genau das ist was ich nicht mag, ListView und TreeView von Windows sollten verwendet werden, ich will kein importiertes Linux.

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.

Zitat:

Da sollte der Window-Manager Standard-Dialog verwendet werden (wie KDE oder GNOME ihn anbieten) und nur wenn nicht vorhanden dann GTK oder Qt Dialoge. Ich habe doch schon gesagt, unter Linux mag ich auch kein importiertes Windows. (siehe Bemerkung zu Kylix)

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.

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.

Du hast nie ein reines X-Programm gesehen, oder?

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.

Du hast tatsächlich nie ein X-Programm gesehen :shock:
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.

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.

Zitat:

Ein Programm muß sich an das BS anpassen und nicht sein Heimatland importieren. Wenn ich ins Ausland gehe um dort zu leben lerne ich die Sprache dieses Landes und seine Bräuche.

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.

Zitat:

Zitat von mael

Zitat:

Die haben auch genug maintainer für beide Plattformen. Bei OpenOffice.org hast du sogar im laufenden Betrieb die Wahl zwischen dem OO.o-eigenen (selbstgebastelten) Dialog und den System-Dialogen.

Sag ich ja, geht auch anders.

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.

Zitat:

Zitat von mael

Zitat:

Zitat von tommie-lie

Ja, Delphi legt dir auch nicht für jedes Fenster einen eigenen Eintrag in die Taskleiste und behandelt nicht jedes Fenster als getrenntes Fenster, sondern als Unterfenster des Hauptfensters, sodaß bei einem Klick auf ein belibebiges Fenster die gesamte IDE in den Vordergrund kommt. Lazarus macht das nicht.

Das ist natürlich schlecht, solange hab ich mir das nichtmal angesehen.

Ganz ehrlich, ohne dir nahetreten zu wollen, mir scheint, als hättest du dir vieles nicht genau angesehen.

Zitat:

Zitat von mael

Dann MS VS hat sich gerade mal gemausert da ist jetzt die Borland IDE plötzlich total schlecht? Das finde ich doch etwas unobjektiv.

Meinungen über die Produktivität einer IDE sind immer subjektiv. Es gibt auch Leute, die lieben Lazarus.

[mael]

Zitat:

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 :shock:

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 :roll:

Zitat:

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.

[tommie-lie]

Zitat:

Zitat von mael

Zitat:

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.

Welche andere Pascal-Implementierung soll ich denn unter Linux sonst benutzen? GPC, das nicht DelphiLanguage-kompatibel ist, weil es sich an die offenen Standards hält? Oder Kylix, dessen IDE auch nicht wesentlich besser ist und das unter einem 2.6er-Kernel nicht mehr zuverlässig läuft und mittlerweile auch veraltete Units hat?

Zitat:

System V IPC Sachen sind in Kylix libc.pas definiert, JEDI hat, bis jetzt, soweit ich weiß dafür keine Unterstützung.

Ist ja eigentlich auch nicht deren Aufgabe. Als Joint Endeavor of Delphi Innovators brauchen sie sich eignetlich nicht um IPC von anderen Betriebssystemen kümmern.

Zitat:

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.

Wie wäre es: Ich benutze einfach die Standardbibliothek für sowas, die GNU C Library?

Zitat:

Zitat:

Qt

Wird nicht korrekt gezeichnet, die Menüs wackeln hin und her, die Shortcuts sind schlecht implementiert, Teile werden nicht gezeichnet (z.B. beim PageControl)

Ist mir in meinem (zugegebenermaßen kurzen) KDE-Leben nicht aufgefallen. Zumindest hat Gnome/GTK derartige Probleme nicht, und auch die Menüs von Knoppix oder Kanotix wackeln nicht hin und her. Um schlechte Erfahrungen mit Shortcuts zu machen hatte ich es nie lange genug in produktivem Einsatz, in Gnome funktionieren sie aber.

Zitat:

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

Gtk ist auch nicht für Windows gemacht!
Schau mal, geh mal auf www.gtk.org. Im dortigen Download-bereich findest du eh nur die Quellen. Das "GTK+ for Win32"-Projekt ist nichtmal auf gtk.org gehostet, es ist Teil des GIMP-Projekts und nichtmal davon ein offizieller Teil. Es wird von Tor Lillqvist maintained und mehr oder weniger eine private Entwicklung. Und wenn du den Windows-Links auf [url}www.gimp.org[/url] folgst, wirst du sogar merken, daß der Windows-Port ein eigenständiges Sourceforge-Projekt ist, nämlich gimp-win.

Zitat:

Außerdem werden häufig auch Programme von Windows nach Linux portiert.

Was ohne wine(lib) ein unglaublicher Aufwand ist, weil kein einziger der Calls auch nur ansatzweise unter Linux existieren.

Diese ganze Diskussion lässt sich ganz einfach komprimieren: GTK hatte never ever das Ziel, Windows zu unterstützen, und dennoch bist du der Meinunng, daß es deren Aufgabe sei, native Dialoge des jeweiligen Systems zu verwenden. Für sowas war aber GTK nie gemacht worden.

Zitat:

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!

"Ich" war in diesem Fall jemand, der irgendwas auf allen Plattformen zugänglich machen will. Das sind auch die Trolltech- und GTK-Leute. Es ist und bleibt das gleiche Problem: Eine Heidenarbeit, für die niemand Zeit hat.

Zitat:

Ich habe sogar schon eines programmiert. Und X bietet auch Fensterchen, Menüs und Nachrichten, Maus, ...

Ich weiß, was es kann, aber es sieht hässlich aus, wenn man nicht erheblich mehr Arbeit in die Oberfläche steckt als in die Programmlogik.

Zitat:

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.

Wenn du Gnome oder KDE benutzt, integriert sich ein X-Programm überhaupt nicht in die bestehende Oberfläche. Ist dir das wirklich lieber als zwei verschiedene Dateidialoge?

Zitat:

Falsch, alle Crossplattform Programme sehen so aus, und das ist unakzeptabel.

Ja, das ist es, was ich sagte. Linux-Programme sehen meist wie Linux-Programme aus, und mit Windows-Programmen sieht's genauso aus. Erst was rübergeschleppt wird muss sich irgendwo in der Mitte treffen. Crossplatform-Anwendungen, die auf jeder Zielplattform wie zuhause aussehen sollen, sind keine plattformübergreifenden Anwendungen mehr, sondern Ports der kompletten GUI auf die jeweilige Zielplattform. Ein komplettes Rwrite kommt dem ganzen noch am nächsten, auch wenn man wenigstens die ganzen Backends mitbenutzen kann, wenn die Entwickler nicht gepennt haben und Backend und Frontend so miteinander verflochten haben, daß man trotzdem den kompletten Code neuschreiben darf.

Zitat:

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.

ACK.
Aber wenn ich auf mehreren Hochzeiten feiern will, müsste ich für jedes Betriebssystem eine eigene Oberfläche entwickeln und maintainen. Da ich persönlich mich lieber auf die Funktionalität des Programmes konzentriere und nicht 80% meiner Arbeit in die Oberfläche stecke, nehme ich da lieber etwas, was auf allen Plattformen verfügbar ist und portiere nicht jeden Dialog rüber.
Echt Plattformunabhängigkeit gibt es bereits mit Java, dort sehen alle Programme gleich (schlecht :mrgreen:) aus. Und wenn ich mich nicht irre gibt es sogar für Java entsprechende Schnittstellen zum unterliegenden System, sprich native widgets.

Zitat:

Ist doch gut das sie sich die Mühe machen.

Finde ich nicht. Sie könnten schon Version 2.0 fertig haben, wenn all jene, die an den native widgets gearbeitet haben, an der Anwendung selbst entwickelt hätten.

Zitat:

(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ß.)

Du bist Programmierer, du kannst gerne anfangen. Es gibt sicherlich Leute, die sich die Finger nach sowas lecken werden. Die großen Linux-Projekte à la GIMP oder Openoffice.org werden es aber nicht sein.

[Robert_G]

OT:
Ist immer wieder lustig, wenn tommie einen zum rumsticheln gefunden hat. :mrgreen:
*sich wieder schmunzelnd zurückzieht*

[Hansa]

Tja, es ist immer wieder lustig wie manche mit Fachbegriffen um sich schmeißen, die sie irgendwo gehört haben aber das ganze eigentlich gar nicht benutzen. 8)

Da der Thread nun mit der Ausgangsfrage überhaupt nichts mehr zu tun hat, sondern eher mit Linux / Windows : es hieß, ein Windows - Programm solle aussehen wie ein Windows - Programm und nicht wie ein Linux Programm usw. Wenn dem nicht so ist, dann nervt das IMHO die Enduser. Gestern wollte ich z.B. was aus dem Internet ausdrucken. Hellblaue Schrift auf Schwarz. Echt cool. 8) Ich habe einen Teil des Textes nach Word kopiert. Da war das coole dann eben, daß die hellblaue Schrift auf dem weißen Papier gar nicht zu lesen war. Ich mußte die Schriftfarbe also erst auf schwarz umstellen um es dann drucken zu können.

Das Problem bei "Standards" ist nun leider, daß es zumindest bei Windows keiner ist ! :mrgreen: Wer sich strikt an die Mickysoft "Standards" hält, der bekommt massive Probleme sein Programm nach ISO???? zertifizieren zu lassen. Denen (und auch mir) ist es u.a. nämlich ein Greuel, mit ALT-F4 ein Fenster schließen zu müssen und mit TAB zum nächsten Steuerelemet zu gehen. Wer hat sowas erfunden ?

Wie gesagt, es geht dabei nicht mal so um das Aussehen, sondern um eine einheitliche, intuitive Bedienung eines Programmes ohne Verrenkungen im Handgelenk. Es wäre wohl schon wichtiger, sich über solche Sachen mal Gedanken zu machen, als über Betriebssysteme oder auch C zu diskutieren, die man sowieso nicht beeinflussen kann.

[MathiasSimmack]

Zitat:

Zitat von Hansa

Gestern wollte ich z.B. was aus dem Internet ausdrucken. Hellblaue Schrift auf Schwarz. Echt cool. 8)

Da sah im Web sicher auch gut aus.

Zitat:

Ich habe einen Teil des Textes nach Word kopiert.

Ich hätte ganz einfach im Browser eingestellt, dass selbiger nicht mehr die Styles der Seite sondern meine Standardfarben benutzt. So was können gute Browser. Dann hättest du gleich drucken können. ;)

[Mephistopheles]

:twisted:

Code:

M = M * V;

Dies ist das Kreuzprodukt mit einer Matrix und einem Vektor.

Code:

us1 += us2;

Code:

us1 += L"\blablubb";

Code:

us1 += "Ein ANSI-String ... blabla";

Dies war eine Wrapperklasse für die UNICODE_STRING-Struktur in Aktion.
Ich komme dann wieder sobald operator-Überladen in Delphi auch geht (ohne .NET!) :zwinker:

Noch Fragen? :mrgreen:

... ihr wißt ja: ich bin der Geist, der stets verneint :mrgreen:

And the winner is ... Celphi++

[mael]

Zitat:

Zitat von Hansa

Das Problem bei "Standards" ist nun leider, daß es zumindest bei Windows keiner ist ! :mrgreen: Wer sich strikt an die Mickysoft "Standards" hält, der bekommt massive Probleme sein Programm nach ISO???? zertifizieren zu lassen. Denen (und auch mir) ist es u.a. nämlich ein Greuel, mit ALT-F4 ein Fenster schließen zu müssen und mit TAB zum nächsten Steuerelemet zu gehen. Wer hat sowas erfunden ?

Wie gesagt, es geht dabei nicht mal so um das Aussehen, sondern um eine einheitliche, intuitive Bedienung eines Programmes ohne Verrenkungen im Handgelenk. Es wäre wohl schon wichtiger, sich über solche Sachen mal Gedanken zu machen, als über Betriebssysteme oder auch C zu diskutieren, die man sowieso nicht beeinflussen kann.

Solche Sachen wie man ein Fenster schliesst lassen sich z.B. elegant loesen wenn man wie KDE diese Tastenkuerzel konfigurierbar macht. Daher ist es also wichtig das BS + WindowManger zu achten um Komfort fuer den Benutzer zu erreichen, also auch spezielle Features des BS zu unterstuetzen.

Was Windows angeht, ist bestimmt nicht alles perfekt, aber es sind wohl die meistens Nutzer daran gewoehnt. Jetzt mal einfach sein eingenes Design/Konzept aufzuzwingen kann es wohl nicht sein. Und wenn schon, dann muss man es auf jeden Fall auf den BS Standard umstellen koennen.

ALT+F4 ist fuer mich kein Problem, Klavierspielen macht die Haende sehr flexibel :lol:

[mael]

Zitat:

Zitat von Mephistopheles

:twisted:

Code:

M = M * V;

Dies ist das Kreuzprodukt mit einer Matrix und einem Vektor.

Code:

us1 += us2;

Code:

us1 += L"\blablubb";

Code:

us1 += "Ein ANSI-String ... blabla";

Dies war eine Wrapperklasse für die UNICODE_STRING-Struktur in Aktion.
Ich komme dann wieder sobald operator-Überladen in Delphi auch geht (ohne .NET!) :zwinker:

And the winner is ... Celphi++

Freepascal hat Operatorueberladung, aber wie schon gesagt, bei Delphi fehlt die Weiterentwicklung der Sprache.

Was die Unicode-Sache angeht, es gibt WideString, was also soll das Beispiel?

[tommie-lie]

Zitat:

Zitat von mael

Was die Unicode-Sache angeht, es gibt WideString, was also soll das Beispiel?

Hihi, die RTL ist aber nicht sonderlich darauf ausgelegt, und auch die VCL-Controls unterstützen es nicht. Du bist also auf Fremdkomponenten angewiesen, wenn du deine Controls nicht zu Fuß über die API mit Daten versorgen willst.

Zitat:

Zitat von mael

elegant loesen wenn man wie KDE diese Tastenkuerzel konfigurierbar macht.

Kann Gnome auch.

[TheAn00bis]

Ist denn von der Perfomance kein Unterschied zu finden?

Es wäre also möglich ein modernes Spiel auch in Delphi zu schreiben? Oder nicht?

[NicoDE]

Zitat:

Zitat von TheAn00bis

Es wäre also möglich ein modernes Spiel auch in Delphi zu schreiben? Oder nicht?

Eher nicht. 90% der Software die man einkauft (Physik-, Animatons-, Sound-, Musik-, ...System) um überhaupt mit dem Spiel anzufangen, bieten nur ein C/C++-Interface.

[mael]

Zitat:

Zitat von NicoDE

Zitat:

Zitat von TheAn00bis

Es wäre also möglich ein modernes Spiel auch in Delphi zu schreiben? Oder nicht?

Eher nicht. 90% der Software die man einkauft (Physik-, Animatons-, Sound-, Musik-, ...System) um überhaupt mit dem Spiel anzufangen, bieten nur ein C/C++-Interface.

Es gibt sogar Leute die jetzt mit C# Spiele entwickelnhttp://gameports.net/gp/offlineseite/artikel_1598.html (Google Cache weil die original Seite offline ist)

Von der Performance selber gesprochen:
Delphi hat Probleme was die Geschwindigkeit bei Gleitkommaberechnungen angeht, da optimiert der Kompiler leider so gut wie gar nicht. Ich kenne bis jetzt auch keinen Delphi/Pascal Kompiler der die "neuen" Prozessorfeatures wie MMX oder SSE direkt zur Codeoptimierung nutzt.
Für Graphik alleine ist das nicht so schlimm, das Problem ist erst bei komplexen (sprich realistischen) Physikengines oder der KI von Gegnern.

Wer einen echten Vorsprung gegenüber der Konkurrenz haben will der wird mit vielen Einkäufen nicht so weit kommen, denn er muß sich abheben. Graphik und Effekte zählen heute leider mehr als die Spielidee.

[tommie-lie]

Zitat:

Zitat von mael

Zitat:

Zitat von NicoDE

Zitat:

Zitat von TheAn00bis

Es wäre also möglich ein modernes Spiel auch in Delphi zu schreiben? Oder nicht?

Eher nicht. 90% der Software die man einkauft (Physik-, Animatons-, Sound-, Musik-, ...System) um überhaupt mit dem Spiel anzufangen, bieten nur ein C/C++-Interface.

Es gibt sogar Leute die jetzt mit C# Spiele entwickeln

Lies richtig, Nico sagte, daß die Bibliotheken, die man einkauft, nur C(++)-Interfaces haben. Wenn du sie dir selbst schreibst, hast du dieses Problem nicht, aber oft genug kauft man fremde Engines und entwickelt das eigene Spiel darauf aufbauend.

[mael]

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von mael

Zitat:

Zitat von NicoDE

Zitat:

Zitat von TheAn00bis

Es wäre also möglich ein modernes Spiel auch in Delphi zu schreiben? Oder nicht?

Eher nicht. 90% der Software die man einkauft (Physik-, Animatons-, Sound-, Musik-, ...System) um überhaupt mit dem Spiel anzufangen, bieten nur ein C/C++-Interface.

Es gibt sogar Leute die jetzt mit C# Spiele entwickeln

Lies richtig, Nico sagte, daß die Bibliotheken, die man einkauft, nur C(++)-Interfaces haben. Wenn du sie dir selbst schreibst, hast du dieses Problem nicht, aber oft genug kauft man fremde Engines und entwickelt das eigene Spiel darauf aufbauend.

Lies Du richtig und komplett :

Zitat:

Wer einen echten Vorsprung gegenüber der Konkurrenz haben will der wird mit vielen Einkäufen nicht so weit kommen, denn er muß sich abheben. Graphik und Effekte zählen heute leider mehr als die Spielidee.

[NicoDE]

Zitat:

Zitat von mael

Wer einen echten Vorsprung gegenüber der Konkurrenz haben will der wird mit vielen Einkäufen nicht so weit kommen, denn er muß sich abheben.

Meiner bescheidenen Meinung nach sind 95% aller Titel im Budget-Bereich - da reichen 'kleine' Effekte für's 'kleine' Geld :)
Ich nehme an, dass Du die 'großen' Titel meinst... auch die kaufen Subsysteme (die halt aufgebohrt werden), da niemand mehr die Zeit hat, sich 5 Jahre hinzusetzen um eine Engine und ein Spiel zu entwickeln. Zudem wird es zunehmends schwieriger in Deutschland Experten in den betreffenden Bereichen (z.B. Animation) zu finden.

Zitat:

Zitat von mael

Graphik und Effekte zählen heute leider mehr als die Spielidee.

Angebot und Nachfrage. Leider.
Noch jemand Lust auf den Fußball-Manager 2006 :witch:
(es geht auch anders, auf Siebenwind wird immer noch Rollenspiel mit OU-Engine gespielt :))

topic: man kann mit Delphi gute, moderne Spiele entwickeln - ist nur eine Frage der Anforderungen und der Zeit.

[tommie-lie]

Zitat:

Zitat von mael

Lies Du richtig und komplett :

Zitat:

Wer einen echten Vorsprung gegenüber der Konkurrenz haben will der wird mit vielen Einkäufen nicht so weit kommen, denn er muß sich abheben. Graphik und Effekte zählen heute leider mehr als die Spielidee.

Das ändert nichts an dem, was Nico gesagt hat. Und es werden in der Realität oft viele Dinge dazugekauft, weil die Entwicklungskosten für komplette Eigenentwicklungen zu groß sind. Auch an Graphik und Effekten kann man Dinge kaufen und sie besser machen als andere, das fängt nämlich schon bei liebevolleren Texturen und Modellen an. Man kommt auch mit Einkäufen weit.

[TheAn00bis]

Bleibt mal locker :wink:

Ja, mir war klar, dass es so gut wie keine Grafikengine für Delphi zu kaufen gibt. Mir ging es mehr um das theoretische, ob Delphi sonst irgendwelche Nachteile mit sich bring.

Was bedeutet denn Codeoptimierung eigentlich? Natürlich kann ich mir was darunter vorstellen, dass der compilierte Assemblercode so effektiv wie möglich gestalltet ist. Aber macht das so viel aus?

[NicoDE]

Zitat:

Zitat von TheAn00bis

Natürlich kann ich mir was darunter vorstellen, dass der compilierte Assemblercode so effektiv wie möglich gestalltet ist. Aber macht das so viel aus?

Wenn man sehr häufig verwendete Klassen optimiert (zB Matrizen), dann kann das sehr viel bringen. Aber selbst dafür finden sich Lösungen für Delphi (optimierte C++Builder-Klassen einlinken). Ansonsten ist es einfach mehr Arbeit mit Delphi Language Performanceprobleme zu vermeiden - aber grundsätzlich geht es. Den größten Performancegewinn bringen, aus Erfahrungswerten, immer noch die Optimierung der Algorithmen und Datenstrukturen...

[mael]

Zitat:

Zitat von TheAn00bis

Was bedeutet denn Codeoptimierung eigentlich? Natürlich kann ich mir was darunter vorstellen, dass der compilierte Assemblercode so effektiv wie möglich gestalltet ist. Aber macht das so viel aus?

NicoDE hat Recht, daß es wesentlich auf den richtigen Algorithmus ankommt.

Berechnungen mit Multimedia Daten lassen sich typischer Weise aber nicht durch einen klugen Algorithmus beschleunigen.
Häufig muß man den kompletten Datenstrom betrachten: Filtereffekte, Überblenden, Tonverzerrung, OGG-Vorbis-Decodierung und Ähnliches können nicht einfach einen Teil der Daten ignorieren.
Häufig wird ist das bei schnellen Algorithmen der Fall: z.B. Clipping: spart Zeichenoperationen, Stringsuche: die Länge des Such-Strings kann verwendet werden um Bytes zu überspringen.

Trotzdem schafft man mit SSE häufig 2-4 fache Beschleunigung (für Multimedia-Daten), weil dort mehrere Datenpakete der gleichen Größe auf einmal verarbeitet werden können.

Was Gleitkommaoperationen angeht: Delphi streut zuviele fwaits in seinen Kode ein, solche Funktionen wie Sin werden als Funktionsaufruf implementiert obwohl der Prozessor direkt dafür einen Opcode anbietet. Da wäre Compilermagic sinnvoller. Dann werden oft Sachen hin und herkopiert auch wenn es unnötig ist.
Es gibt noch anderes... Vor längerer Zeit habe ich mal einen Funktionsparser geschrieben, der den Term dann in Assemblerkode umgewandelt hat. Das war jetzt nicht wirklich optimiert, aber trotzdem immer ungefähr doppelt so schnell wie der von Delphi kompilierte Kode.
C++ Kompilat war meistens noch schneller.

Allgemein, ist Delphi gegenüber klassischen C++ Compilern nicht so schlecht, ausgenommen Intel's C++ Compiler, aber der optimiert ja auch auf die neusten CPUs.

[mirage228]

Hi,

mir hat sich hier beim Lesen eine Frage gestellt, die ggf. OT ist:

Was passiert eigentlich, wenn man einen Code mit SSE(2), MMX, etc. Befehlen schreibt und dieser auf einem Prozessor ohne dieses Feature ausgeführt wird? Das wäre mal sone Sache die mich interessieren würde...

mfG
mirage228

[NicoDE]

Zitat:

Zitat von mirage228

Was passiert eigentlich, wenn man einen Code mit SSE(2), MMX, etc. Befehlen schreibt und dieser auf einem Prozessor ohne dieses Feature ausgeführt wird?

EInvalidOpCode :)
(aber bei aktuellen Spielen setzt man einfach einen P4-kompatiblen Prozessor voraus...)

[tommie-lie]

Zitat:

Zitat von TheAn00bis

Ja, mir war klar, dass es so gut wie keine Grafikengine für Delphi zu kaufen gibt.

Nuja, zu kaufen vielleicht nicht, aber die Quake2-Engine wurde mal nach Delphi portiert: http://www.sulaco.co.za/quake2/

Zitat:

Zitat von TheAn00bis

Was bedeutet denn Codeoptimierung eigentlich? Natürlich kann ich mir was darunter vorstellen, dass der compilierte Assemblercode so effektiv wie möglich gestalltet ist. Aber macht das so viel aus?

ID3v2-Tags benutzen ein 28bit-Integer-Format, bei dem in jedem Byte das höchstwertige Bit immer auf 0 gesetzt ist (und zusätzlich noch im Gegensatz zu Intel-Prozessoren auch noch das MSB als erstes im Datenstrom lag). Ein einfaches Auslesen war also nicht möglich, eine Konvertierungsfunktion musste her. Meine reine Pascal-Implementierung (eine Codezeile, reine Integerarithmetik, ausschließlich ANDing, Shifting und ORing, also eigentlich eine recht popelige Aufgabe) habe ich um mehr 30% beschleunigt, indem ich sie in Assembler neu geschrieben habe. Zugegeben, diese Funktion wird nur ein paar Mal aufgerufen und die Anwendung selbst ist ja auch alles andere als geschwindigkeitskritisch, aber ich war jung und brauchte das Geld ;-)
Der Delphi-Compiler (ich weiß nicht, ob's der ICC besser gemacht hätte) produziert nicht immer optimalen Code (schon allein weil der Compiler manchmal nichts über die Anwendung weiß und keine Annahmen über die Umgebung machen kann, von daher ist jeder Compiler noch weiter optimierbar für spezielle Anwendungen) und bei kritischen Funktionen kann eine Handoptimierung durchaus noch etwas bringen.

[Robert_G]

Wirklich krasse Unterschiede beim Otptimieren bemerkt man beim Debugging von .Net Apps.

Wenn du zum Bleistift durch eine Collection mit nur 5 Elementen iterierst wird sich der JIT nicht viel Mühe geben um möglichst optimalen Code zu generieren.
Jetzt führe die gleiche Methode mit 10000 Elementen aus. Der ASM Code hat sich geändert, da er jetzt rausholt was er nur kann. :shock:

Wobei es wieder fies ist JITs einer VM mit einem normalen Compiler zu vergleichen. ;) (wäre für beide Seiten ungerecht)
Wollte es nur als krasses Beispiel erwähnen. :mrgreen:

[MagicAndre1981]

Zitat:

Zitat von NicoDE

Zitat:

Zitat von mirage228

Was passiert eigentlich, wenn man einen Code mit SSE(2), MMX, etc. Befehlen schreibt und dieser auf einem Prozessor ohne dieses Feature ausgeführt wird?

EInvalidOpCode :)
(aber bei aktuellen Spielen setzt man einfach einen P4-kompatiblen Prozessor voraus...)

Wie jetzt? Es wird ein P4 kompatibler Prozzi vorausgesetzt. Dann dürfte ein Spiel nur auf Prozessoren laufen, die SSE2 haben. Aber ich kann mit meinen AthlonXP 2400+ trotzdem spielen ohne SSE2.

Zum Thema:
Der Intel C++ Compiler bietet die Möglichkeit, Code für verschiede Prozzitypen zu schreiben.

André

[tommie-lie]

Zitat:

Zitat von MagicAndre1981

Wie jetzt? Es wird ein P4 kompatibler Prozzi vorausgesetzt. Dann dürfte ein Spiel nur auf Prozessoren laufen, die SSE2 haben. Aber ich kann mit meinen AthlonXP 2400+ trotzdem spielen ohne SSE2.

Dann setzen deine Spiele vielleicht nicht zwingend SSE2 vorraus ;-)

[Robert_G]

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von MagicAndre1981

Wie jetzt? Es wird ein P4 kompatibler Prozzi vorausgesetzt. Dann dürfte ein Spiel nur auf Prozessoren laufen, die SSE2 haben. Aber ich kann mit meinen AthlonXP 2400+ trotzdem spielen ohne SSE2.

Dann setzen deine Spiele vielleicht nicht zwingend SSE2 vorraus ;-)

Macht auch keins, Nico meinte wohl P3-kompatibel. Sonst hätten die ganzen "nicht ganz so aktuellen" ( :mrgreen: ) 32 Bit AMDs schon lange in die Röhre gekiekt. :lol:

[mael]

Zitat:

Wie jetzt? Es wird ein P4 kompatibler Prozzi vorausgesetzt. Dann dürfte ein Spiel nur auf Prozessoren laufen, die SSE2 haben. Aber ich kann mit meinen AthlonXP 2400+ trotzdem spielen ohne SSE2.

Es gibt dann mehrere Echsen (plural von EXE :cyclops:) jede für einen bestimmten Prozessortyp.
Andere Möglichkeit ist optimierte Bereiche für mehrere Prozessoren zu schreiben und mit Hilfe von CPUID den richtigen Code zur Laufzeit auszuwählen.

Zitat:

Zitat von MagicAndre1981

Zum Thema:
Der Intel C++ Compiler bietet die Möglichkeit, Code für verschiede Prozzitypen zu schreiben.

Und optimiert auch ganz normalen C++ Code für den Ziel-Prozessor ohne daß man was anpassen müßte.

[MagicAndre1981]

Zitat:

Zitat von mael

Zitat:

Wie jetzt? Es wird ein P4 kompatibler Prozzi vorausgesetzt. Dann dürfte ein Spiel nur auf Prozessoren laufen, die SSE2 haben. Aber ich kann mit meinen AthlonXP 2400+ trotzdem spielen ohne SSE2.

Es gibt dann mehrere Echsen (plural von EXE :cyclops:) jede für einen bestimmten Prozessortyp.
Andere Möglichkeit ist optimierte Bereiche für mehrere Prozessoren zu schreiben und mit Hilfe von CPUID den richtigen Code zur Laufzeit auszuwählen.

Zitat:

Zitat von MagicAndre1981

Zum Thema:
Der Intel C++ Compiler bietet die Möglichkeit, Code für verschiede Prozzitypen zu schreiben.

Und optimiert auch ganz normalen C++ Code für den Ziel-Prozessor ohne daß man was anpassen müßte.

Jupp, der Intel C++ Complier ist schon geil :thumb: :thumb:

[Mephistopheles]

Zitat:

Zitat von mael

Was die Unicode-Sache angeht, es gibt WideString, was also soll das Beispiel?

Was soll der Kommentar?
Dir ist schon klar, was die UNICODE_STRING-Struktur ist? Hier mal der Typ in Delphi:

Delphi-Quellcode:

type
  UNICODE_STRING = record
    Length: Word;        // Länge in Bytes, immer gerader Wert
    MaximumLength: Word; // Maximale Länge in Bytes, immer gerader Wert
    Buffer: PWideChar;
  end;

... und jetzt bin ich mal gespannt, wie exakt du das mit einem WideString lösen willst, ohne vor der Übergabe einer UNICODE_STRING-Struktur jedesmal rumzupfriemeln. Präprozessor-Makros gibt es neben Operator-Overloading auch nicht bei Delphi.

Außerdem kann man in C++ Klassen wie Stackvariablen benutzen - will heißen, wenn "out-of-scope" wird die Klasse freigegeben.