Delphi-PRAXiS - c++ vs delphi

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)

- - c++ vs delphi (https://www.delphipraxis.net/43452-c-vs-delphi.html)

Re: c++ vs delphi

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

Re: c++ vs delphi

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

Re: c++ vs delphi

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...

Re: c++ vs delphi

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:

Re: c++ vs delphi

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

Re: c++ vs delphi

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.

Re: c++ vs delphi

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

Re: c++ vs delphi

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von mael

wie gesagt, ich halte nichts davon zuviel Fremdkode zu verwenden

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 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.

Re: c++ vs delphi

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.

Re: c++ vs delphi

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:

Sag ich ja, geht auch anders.

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 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++.