Vorteile von Delphi

[mumu]

mich würden gern mal die Vorteile von Delphi gegenüber c++ usw... interessieren...

[Angel4585]

Nun ich bin quasi noch Programmieranfänger. Und da ist der eindeutige Vorteil, das es für den Einstieg in die Programmierwelt deutlich einfacher zu lernen ist, da man mit ganzen "Worten" und nicht mit irgendwelchen kryptischen Zeichen arbeiten kann.

[Luckie]

Zitat:

Zitat von mumu

mich würden gern mal die Vorteile von Delphi gegenüber c++ usw... interessieren...

Du vergleichst Äpfel und Birnen bzw. bist nicht genau genug. Delphi bezeichnet eine IDE von Borland und es ist die Kurzform für Delphi Language, welche eine Pascal basierende Programmiersprache meint. C++ ist nuzr eine Programmiersprache. Was willst du jetzt also vergleichen? Die Sprache Delphi mit der Sprache C++ oder die IDE Delphi mit den verschiedenen IDEs für C++? Oder geht es dir gar um einen Vergleich der Klassenbibliothek VCL mit Klassenbibliotheken für C++ wie zum Beispiel die MFC?

[Binärbaum]

Das ist ja nun ziemlich allgemein gehalten, wäre schön, wenn du genauer sagen kannst, welche Aspekte von Delphi dich interessieren. Aber ich fange mal mit dem an, was mir sponmtan einfällt:
Erstens ist Delphi-Sourcecode leserlicher (meine Meinung) und somit auch einfacher für andere nachzuvollziehen als C/C++, weil nicht so "kryptisch". Ein weiterer Vorteil ist die besser gelöste Parameterübergabe an Funktionen/ Prozeduren: wenn man in C einen "Call by reference" machen will, muss man immer Zeiger übergeben und innerhalb der Funktion diese Zeiger dereferenzieren, wenn man auf den Wert zugreifen will. Bei Delphi nimmt man einfach das Schlüsselwort var vor den entsprechenden Parameter, und den Rest macht der Compiler.
übrigens unterscheidet Delphi zwischen Funktionen und Funktionen mit leeren Ergebnistyp (=Prozeduren).

Code:

void f(int x) {
  ...
}

int g(int x) {
  ...
}

entspricht in Delphi:

Delphi-Quellcode:

procedure f(x: Integer);
begin
  ...
end;

function g(x: integer): Integer;
begin
  ...
end;

MfG
Binärbaum

[noidic]

Auf die Frage wirds keine konkrete Antwort geben können, beides ist etabliert und hat seine Freunde. Ich z.B. habe keine Präferenz, jedes für seinen Zweck. Für Systemnahe oder Backend-Programmierung bevorzuge ich ( wenns das Projekt zulässt ) C/C++, für Client-Anwendungen mit und ohne DB-Zugriff Delphi.

[Luckie]

Zitat:

Zitat von Binärbaum

Erstens ist Delphi-Sourcecode leserlicher (meine Meinung) und somit auch einfacher für andere nachzuvollziehen als C/C++, weil nicht so "kryptisch".

Ein eingefleischter C/C++ programnmierer wird dir genau das Gegenteil sagen. Da das einfach Geschmacks- bzw. Gewöhnungssache ist, dürfte diese persönliche Meinung wertlos für den Fragestller sein.

Zitat:

Ein weiterer Vorteil ist die besser gelöste Parameterübergabe an Funktionen/ Prozeduren: wenn man in C einen "Call by reference" machen will, muss man immer Zeiger übergeben und innerhalb der Funktion diese Zeiger dereferenzieren, wenn man auf den Wert zugreifen will. Bei Delphi nimmt man einfach das Schlüsselwort var vor den entsprechenden Parameter, und den Rest macht der Compiler.

Jetzt stellt sich die Frage: Ist es gut, dass Delphi die Pointer quasi vor dem Programmierer versteckt oder schlecht? Also ich finde es nicht so gut, da gerade Anfänger nie wissen, wann sie es mit einem Pointer zu tun haben und wann nicht. Hinzukommt, dass ichmir nie sicher sein kann, was die Compilermagic aus meinem Quellcode macht bzw. wie sie ihn versteht. Man verliert einfach etwas an Kontrolle.

[Tubos]

Zitat:

Erstens ist Delphi-Sourcecode leserlicher (meine Meinung)

Eben. Leserlichkeit ist subjektiv. Ich finde zum Beispiel die Sprachkonstrukte in C++ schöner, eleganter und leichter zu lesen. Man muss ja nicht alles aufs extremste verkürzen - natürlich kann man in C++ nahezu unlesbaren Code schreiben, aber das macht kaum jemand.
edit: Luckie ist mir zuvorgekommen...

Zitat:

wenn man in C einen "Call by reference" machen will, muss man immer Zeiger übergeben und innerhalb der Funktion diese Zeiger dereferenzieren, wenn man auf den Wert zugreifen will.

Korrekt. Aber in C++ kann man nicht nur per Pointer, sondern auch per Referenz übergeben und dann ist es genauso wie in Delphi das var Schlüsselwort.

[Phoenix]

Faktisch: Es gibt nachweislich keine Unterschiede zwischen Delphi und einer anderen Programmiersprache. Alle Hochsprachen sind Turing-Vollständig und damit gleich mächtig, das heisst man kann theoretisch alles in jeder Sprache realisieren.

So, und nun kommt eine ganz schöne Prise subjektivität dazu: Nicht alles lässt sich jeder Sprache gleich einfach und elegant lösen. Delphi z.B. ist ungeheuer eingeschränkt wenn es darum geht, Treiber zu programmieren. Es lässt sich jedoch mit einer ganzen Menge eingebettetem Assembler und ziemlichen Verrenkungen machen. Das ist aber etwas das ich meinem ärgsten Feind nicht wünsche. Auf der anderen Seite finde ich Delphi ungeheuer geschickt wenn es darum geht mit Datenbanken zu arbeiten.

Ich bin der Ansicht: Die Programmiersprache und die jeweilige Plattform sind Werkzeuge des Entwicklers um etwas zu schaffen. Wie im Handwerk gilt hier auch: Ich nehme keinen Kreuzschlitzschraubendreher wenn ich einen Nagel in die Wand hauen will. Ich nehme also kein Delphi wenn ich einen Treiber programmieren muss. Ich nehme auch eher C++ wenn ich 3D-Computerspiele schreiben will (die Dinger sind in der Regel in C++ tatsächlich performanter). Ich nehme Delphi wenn ich schnell wartbare Datenbankanwendungen schreiben will. Ich nehme eine .NET-Sprache (Delphi.NET wenn ich es ausbauen will, C# wenn es wohl immer so bleiben wird) wenn ich mir schnell ein kleines 'machmirmal'-Tool Programmieren will.

Ein Entwickler sollte sowieso mehrere Sprachen beherrschen und die Sprache für eine jeweilige Aufgabe auswählen. Da spielt viel Erfahrung mit rein. Ich schlage gerne vor: Suche Dir verschiedene Anwendungen raus (3D-Würfel rotieren lassen, eine kleine Adressdatenbank, einen kleinen Webserver (muss nur eine Seite ausliefern können)) und programmiere die gleiche Anwendung in verschiedenen Programmiersprachen. Du wirst schnell selber merken welche Sprache Dir für welche Aufgabenstellung am ehesten liegt und welche Du wann wählen solltest.

Eigene Erfahrung, gerade bei solchen Fragestellungen die nur zu gerne in einem Glaubenskrieg ausarten, ist hier der beste Ratgeber.

[ichbins]

Ganz egal, was jetzt besser ist, auf jedenfall gibt es für C-Programmierer weit mehr Stellenangebote. Schau einfach mal hinten auf die PCPraxis oder sonstwo wo sie Werbung für dieses Fernstudium machen, du wirst nur C-Angebote finden.

Wenn du selbst professioneller Programmierer werden willst, solltest du auf jeden Fall beide Sprachen beherrschen.

Ich persönlich bevorzuge Delphi (weil ich es leserlicher finde und weil ich mir C noch garnicht so richtig angeschaut habe.)

[hanspeter]

Wobei man aber fairer Weise sagen muss, das die Blütezeit von Delphi im
abfallenden Teil der Glockenkurve ist.
Delphi setzte sich über lange Jahre von der Konkurenz durch eine hervorragende IDE,
einen superschnellen Compiler und eine revolutionäre Klassenbibliothek ab.
(Ich arbeite mit Borland-Software seit Turbo-Pascal 1.0.)
Die Blütezeit für W32 Apllikationen lag so bei Delphi 5 und 7.
Jetzt bin ich z.B. in einer Situation, dass ich privat mit Delphi 7 (problemlos)
arbeite und beruflich mit D2005.
Abgesehen davon das Delphi 2005 erst nach 3 bis 4 Updates, also fast einem Jahr, für
kommerzielle Entwicklungen brauchbar wurde, habe ich in den letzten drei Monaten
bereits mehrere Abstürze und Neuinstallationen hinter mir.
Sollte sich, was zu erwarten ist, Net durchsetzen, dann spricht nicht mehr sehr viel
für Delphi.
Mir persönlich täte das sehr leid.
Aber da ich mit der Programmiererei mein Geld verdienen muß, brauche ich effiziente
und stabile Werkzeuge.
VS 2005 IDE ist deutlich effizienter, allein der Debugger rechtfertigt einen Umstieg.
Für reine Net Entwicklung läuft man z.B. gerade jetzt mit D2006 dem Net2.0 etwa 1 Jahr hinterher.
Hoffnung hatte ich auch auf Kylix gesetzt. Wäre hier eine Plattform- unabhängige
Programmierung möglich gewesen, wäre das ein gewichtiges Argument.
Leider liegt dieser Zweig auf Eis.
D 2006 schaue ich mir noch an. Hier aber nicht mehr die Architekt, sondern nur
noch die Personalversion.

[Interceptor]

Zitat:

Zitat von Phoenix

Ich nehme eine .NET-Sprache (Delphi.NET wenn ich es ausbauen will, C# wenn es wohl immer so bleiben wird) wenn ich mir schnell ein kleines 'machmirmal'-Tool Programmieren will.

Bitte um Erklärung.
Die .NET Bibliothek bietet dir nahezu unbegrenzte Möglichkeiten jede Art von Anwendung zu schreiben, ganz gleich wie umfangreich diese werden soll

[malo]

Ich will mich auch mal einmischen. Alles folgende basiert auf eigenen Eindrücken, die ich mit verschiedenen Sprachen gemacht habe.

Delphi (ehemals Pascal) ist imho gut für Anfänger geeignet (wurde auch ursprünglich) als Lehrsprache entwickelt). Das liegt an einfachenden, treffenden Schlüsselwörtern (var, begin, end, if..then, procedure, function, constructor, destructor etc.). Wenn man mal mit C++ vergleicht, so ist das in Delphi (für einen Laien) deutlich leserlicher. Denn ein Anfänger weiß sofort, dass bei begin irgendwas anfängt, und mit end etwas aufhört. Aber so klar ist doch nicht, dass bei einer geschweiften öffnenden Klammer ein Anweisungsblock anfängt? Wenn man genau drüber nachdenkt, klingt es zwar logisch, aber so leicht zu verstehen ist das nicht. Oder, dass nach einem var Variablen aufgeführt werden, ist leicht verständlich.

Ich halte also Pascal (und natürlich auch Delphi) für eine für Anfänger geeignete Sprache. Einfach, weil sie einfach verständlich und logische Schlüsselwörter verwendet.
Außerdem wird man in Delphi zu halbwegs strukturierter Programmierung gezwungen. Z.B. durch seperate Var- und Const-Bereiche, durch Unterscheidung zwischen Implementation und Interface-Abschnitt (jedenfalls in den .pas-Dateien) etc.
In anderen Sprachen (z.B. C++) kann man überall eine Variable deklarieren, wo man grade Lust hat. Dadurch kann ein Quellcode sehr schnell unleserlich gemacht werden. Natürlich gibt es auch unleserlichen Delphi-Code, aber durch die erweiterten Strukturregeln gibt es da weniger Möglichkeiten.
Wenn ich mir nämlich mal meinen Delphi-Code ansehe, und meinen PHP-Code (C++ entwickle ich persönlich kaum), dann erkenne ich schon deutliche Unterschiede, gerade was die Variablendeklarationen angeht ;)

Es gibt natürlich auch diverse Sprachfeatures, die in Delphi nicht vorhanden sind. Dazu gehört (bis einschl. D2005) Operatoren-Überladung, oder auch Templates und ähnliches. Das macht Delphi unflexibler, was Problemlösungen angeht. So hat Delphi beispielsweise Probleme mit Treiberprogrammierung (weiter oben angesprochen). Das ist aber eine der wenigen Ausnahmen von Dingen, die mit Delphi schwieriger sind als mit C++.

Desweiteren ist so ziemlich jede Programmiersprache gewissermaßen Problembedingt. Manche Sprachen haben Lösungen für Problem A, manche Sprachen für Problem B, mit manchen geht beides nicht (gut), und manches geht mit beiden Sprachen hervorragend.


Im Endeffekt: Die beste Programmiersprache ist die, mit der du am besten umgehen kannst. ;)

P.S.: Alles, was ich bezüglich "leichter zu lesen" etc. geschrieben hab, war das, was ich versucht habe, möglichst objektiv aus der Sicht eines Laien zu beschreiben. Das waren zum Teil Dinge, die mich als Laie damals an Delphi gefesselt hatten. In Delphi war das halt leichter zu verstehen, von den Sprachkonstrukten her. Daher bitte ich auch keine C/C++/C#/Java/Whatever-Fantatiker jetzt groß aufzuschreien. Ihr könnt es aber gerne nach eurer Ansicht richtig stellen.

[Tubos]

Zitat:

In anderen Sprachen (z.B. C++) kann man überall eine Variable deklarieren, wo man grade Lust hat. Dadurch kann ein Quellcode sehr schnell unleserlich gemacht werden.

Ergänzung: Und in C++ kann der Code sogar unkompilierbar werden, wenn man sich nicht an die Trennung von Header- und Implementierungsdatei haltet. Da kann man ganz böse und völlig undurchsichtige Fehler bekommen, wenn man das nicht richtig macht. Alles schon erlebt ;)

[supermuckl]

hi

Zitat:

(wurde auch ursprünglich) als Lehrsprache entwickelt

sicher?

[r_kerber]

Zitat:

Zitat von supermuckl

hi

Zitat:

(wurde auch ursprünglich) als Lehrsprache entwickelt

sicher?

Jep, von Nikolaus Wirth an der ETH Zürich.

[noidic]

Jo, Pascal ist eine Sprache zum lernen der prozeduralen(!) Programmierung. Was heute daraus geworden ist, ist zwar in der Basis immernoch Pascal und hat damit pädagogische Elemente, hat aber ansonsten mit der Ursprungsidee nicht mehr wirklich was zu tun :)

[Oxmyx]

Zitat:

Zitat von Binärbaum

Ein weiterer Vorteil ist die besser gelöste Parameterübergabe an Funktionen/ Prozeduren: wenn man in C einen "Call by reference" machen will, muss man immer Zeiger übergeben und innerhalb der Funktion diese Zeiger dereferenzieren, wenn man auf den Wert zugreifen will. Bei Delphi nimmt man einfach das Schlüsselwort var vor den entsprechenden Parameter, und den Rest macht der Compiler.

Code:

void machWas(int* a)
{
    (*a)++;
}

void machWas(int& a)
{
    a++;
}

Ich sehe keinen Unterschied zu Delphi.

Bei 'const' geht C++ noch einen Schritt weiter und lässt es zu, ganze Methoden als konstant zu deklarieren (d.h. die Methode ändert nicht das Objekt):

Code:

class tolleKlasse
{
private:
    int einWert;
public:
    int derWertPlusX(const int x) const { return einWert+x; } 
};

[Phoenix]

Zitat:

Zitat von Interceptor

Zitat:

Zitat von Phoenix

Ich nehme eine .NET-Sprache (Delphi.NET wenn ich es ausbauen will, C# wenn es wohl immer so bleiben wird) wenn ich mir schnell ein kleines 'machmirmal'-Tool Programmieren will.

Bitte um Erklärung.
Die .NET Bibliothek bietet dir nahezu unbegrenzte Möglichkeiten jede Art von Anwendung zu schreiben, ganz gleich wie umfangreich diese werden soll

Ganz einfach: Die Wart- und Lesbarkeit des Codes.
Delphi ist einfach besser lesbar als C#, und da die Fähigkeiten von Delphi.NET und C# dank der darunter liegenden Bibliothek vollkommen identisch sind nehme ich bei Projekten die eher Wachsen werden wegen der besseren Lesbarkeit und eben Wartbarkeit eher Delphi.NET als 'Synatx meiner Wahl'. Ein 'fire and forget'-Tool schreibe ich der einfachheit halber in C# - das ist schneller zu tippen und ich musses mir hinterher nicht nochmal angucken ;-)

Edit - Nachtrag: Sorry, Frage falsch verstanden.

Ich verwende eher Delphi weil ich da schon eine entsprechend gut ausgebaute und ausgetestete Code-Basis habe die sich nicht ohne weiteres nach .NET portieren lässt. .NET bietet zwar viel, ist aber gerade im Datenbankbereich noch nicht so weit gediehen um alles das zu können was ich mit meinem nativen Code schon alles machen kann. Und bevor ich das alles nochmal unter .NET nachprogrammiere arbeite ich zur Zeit lieber noch auf der Basis weiter von der ich weiss das alles einwandfrei tut und eine neue Applikation entsprechend schnell fertig ist.

Wobei die Portierung sicher nur eine Frage der Zeit ist... die gerade recht knapp ist. Letzten Endes wird .NET (ungeachtet der Programmiersprache) aber sicher der Weg to go sein.

[Binärbaum]

Zitat:

Zitat von Oxmyx

Zitat:

Zitat von Binärbaum

Ein weiterer Vorteil ist die besser gelöste Parameterübergabe an Funktionen/ Prozeduren: wenn man in C einen "Call by reference" machen will, muss man immer Zeiger übergeben und innerhalb der Funktion diese Zeiger dereferenzieren, wenn man auf den Wert zugreifen will. Bei Delphi nimmt man einfach das Schlüsselwort var vor den entsprechenden Parameter, und den Rest macht der Compiler.

Code:

void machWas(int* a)
{
    (*a)++;
}

Ich sehe keinen Unterschied zu Delphi.

Dann werden wir mal deutlicher:

Delphi-Quellcode:

procedure machWas(var a: integer);
begin
  a:= a+1;
end;

und

Code:

void machWas(int* a)
{
    (*a)++;
}

sind nicht viel unterschiedlicher, aber was, wenn man (aus Schusseligkeit, oder warum auch immer) bei C die Dereferenzierung vergisst und folgendes schreibt und somit aus Versehen den Zeiger verändert und nicht den Wert des Integers, auf den a verweist:

Code:

void machWas(int* a)
{
    a++;
}

Das ist theoretisch möglich und wird sogar kompiliert, nur das, was die Prozedur macht, ist in beiden Fällen komplett anders.

Anderes Beispiel, was "gern" falsch gemacht wird bei C/C++:

Code:

int c;
...
if (c=7) { //<--Fehler, sollte normalerweise (c==7) sein
  printf("blabla1");
  c+=3;
}
else {
  printf("else-Zweig");
  c++;
}
...

Im Code sollte eigentlich nur überprüft werden, ob der Wert von c gleich sieben ist und abhängig davon etwas ausgegeben werden. Durch (unabsichtliches) Weglassen des einen Gleichheitszeichens wird aus dem Vergleich eine Zuweisung. Damit bekommt man gleich zwei Fehler auf einmal: Die if-Abfrage ist immer erfüllt, da c=7 zu 7 ausgewertet wird, und somit als wahr interpretiert wird. Der else-Zweig wird also nie ausgeführt. Und zweitens wird auf c der Wert 7 zugewiesen, was so nicht beabsichtigt war.
Das Schlimme dabei ist, dass dadurch im späteren Programmverlauf unter Umständen ein ganz anderes Verhalten als das gewünschte auftreten kann; es kann sogar passieren, dass sich dieser Fehler weiter durch das Programm schleppt und später Fehler verursacht, die normalerweise (d.h. bei einem einfachen Vergleich) nie aufgetreten wären.

Bei Delphi (bzw. Pascal) wird für den Vergleich ein "=" und für die Zuweisung ":=" verwendet. Wenn man dort aus Versehen mal ein Zeichen vergisst, bekommt man spätestens beim Kompilieren eine Fehlermeldung und kann so den Fehler entdecken, während man bei C/C++ hingegen "fröhlich" kompilieren kann und sich bei der Ausführung des Programms mit den entstandenen Fehlern herumplagen muss. ;)

[cruso]

Zitat:

Zitat von Luckie

Zitat:

Zitat von mumu

mich würden gern mal die Vorteile von Delphi gegenüber c++ usw... interessieren...

Du vergleichst Äpfel und Birnen bzw. bist nicht genau genug. Delphi bezeichnet eine IDE von Borland und es ist die Kurzform für Delphi Language, welche eine Pascal basierende Programmiersprache meint. C++ ist nuzr eine Programmiersprache. Was willst du jetzt also vergleichen? Die Sprache Delphi mit der Sprache C++ oder die IDE Delphi mit den verschiedenen IDEs für C++?

Soviel ich weiß hat Borland gesagt, dass nun auch von der Delphi Programming Language gesprochen werden kann. Mit der Begründung: "Es hat sich soviel geändert". Also seit Delphi 7 kann auch von Delphi Programming Language gesprochen werden!

MfG
Cruso

[malo]

Zitat:

Zitat von Binärbaum

Code:

void machWas(int* a)
{
    (*a)++;
}

Ich sehe keinen Unterschied zu Delphi.

Dann werden wir mal deutlicher:

Delphi-Quellcode:

procedure machWas(var a: integer);
begin
  a:= a+1;
end;

und

Code:

void machWas(int* a)
{
    (*a)++;
}

sind nicht viel unterschiedlicher, aber was, wenn man (aus Schusseligkeit, oder warum auch immer) bei C die Dereferenzierung vergisst und folgendes schreibt und somit aus Versehen den Zeiger verändert und nicht den Wert des Integers, auf den a verweist:

Code:

void machWas(int* a)
{
    a++;
}

Das ist theoretisch möglich und wird sogar kompiliert, nur das, was die Prozedur macht, ist in beiden Fällen komplett anders.[/quote]

Wieso machst du das nicht so:

Code:

void machWas(int& a)
{
    a++;
}

Dürfte doch aufs selbe hinauslaufen? int& ist dann doch auch ein call-by-reference. Oder vertu ich mich da?

[malo]

Zitat:

Zitat von cruso

Soviel ich weiß hat Borland gesagt, dass nun auch von der Delphi Programming Language gesprochen werden kann. Mit der Begründung: "Es hat sich soviel geändert". Also seit Delphi 7 kann auch von Delphi Programming Language gesprochen werden!

Einmal das Zitat von Luckie, nur dass ich die wichtigen Stellen markiert habe:

Zitat:

Zitat von Luckie

Du vergleichst Äpfel und Birnen bzw. bist nicht genau genug. Delphi bezeichnet eine IDE von Borland und es ist die Kurzform für Delphi Language, welche eine Pascal basierende Programmiersprache meint. C++ ist nuzr eine Programmiersprache. Was willst du jetzt also vergleichen? Die Sprache Delphi mit der Sprache C++ oder die IDE Delphi mit den verschiedenen IDEs für C++?

Demnach hast du schon Recht, allerdings ist dein Posting völlig bedeutungslos, weil genau das in dem Zitat von Luckie steht (nur anders ausgedrückt).

[cruso]

Naja, hast im Prinzip recht! :P

[Oxmyx]

Zitat:

Zitat von Binärbaum

Dann werden wir mal deutlicher:
[...]

Jetzt hast du grad übersehen, worauf ich hinaus will. Dies hier ist ein Call-by-Reference-Aufruf genau so wie in Delphi:

Code:

int machWas(int& a)
{
    a++;
}

Wenn ich diese Funktion mit einer Variablen aufrufe, wird die aufrufende Variable direkt verändert, ohne Zeiger.

Und ich denke die Sache mit = und == hat man spätestens nach dem ersten großen Fehlersuchen drin.

[Phoenix]

Auch wenn's Offtopic wird: Noch geiler wird's in Java:

Code:

String str="abc";

if (str == "abc") {
   echo("String ist abc")
} else {
   echo("String ist NICHT abc");

Jeder denkt, im IF würde verglichen ob 'abc' im String drinsteht (was es ja tut) und dann ausgeben 'String ist abc'. Es kommt jedoch immer die Ausgabe 'String ist nicht abc' heraus.

Wenn man sich näher damit befasst ist es auch klar, weil in Java der String ein Objekt ist, und die Variable str im Prinzip ja nur ein Pointer auf die konkrete Instanz ist. Und der Pointer (also str) ist sicher nicht "abc" sondern irgend ein Adresswert. Richtig müsste sein:

Code:

if (str.equals("abc")) {
   //hier passt es
}

Und das ist einer der Gründe, warum ich Java so elendig hasse: Der Code tut nicht das wonach er intuitiv aussieht. Das ist bei Delphi zum Glück ganz anders.

[Oxmyx]

Zitat:

Zitat von Phoenix

Auch wenn's Offtopic wird: Noch geiler wird's in Java:
[...]
Und das ist einer der Gründe, warum ich Java so elendig hasse: Der Code tut nicht das wonach er intuitiv aussieht. Das ist bei Delphi zum Glück ganz anders.

Das hat nichts mit Java zu tun, das ist schon so seit es Strings gibt, und jeder Programmierer weiß das. In Delphi würde das genauso wenig funktionieren:

Delphi-Quellcode:

var
  a, b: PChar;
begin
  a := 'abc';
  b := a;
  if b = 'abc' then begin
    // String ist abc
  end
  else
    // String ist nicht abc  <== Ausgabe
  begin
end;

Genau das gleiche ist es mit C/C++. Deshalb vergleicht man nullterminierte Strings ja nie direkt, sondern in Delphi z.B. mit CompareStr oder in C/C++ mit strcmp/stricmp.

[Tubos]

Zitat:

Deshalb vergleicht man nullterminierte Strings ja nie direkt, sondern in Delphi z.B. mit CompareStr oder in C/C++ mit strcmp/stricmp.

Nein. In C++ kann man den == Operator überladen.
Man muss das nicht mal selber machen, die string - Klasse aus der Standardbibliothek bietet so eine Funktionalität.

DAS finde ich richtig hässlich an Java: diese ständigen equals - Aufrufe.
Wenn es in Java mal Operatorenüberladung gibt werde ich mich in dieser Sprache auch wohler fühlen.

[sniper_w]

Immer wieder wenn solche Diskusionen auftauchen, kommt es zu einem Fehler. Man sagt so "in C/C++ ...". Ja, grossteils stimmt das, aber C ist NUR eine Untermenge von C++. Es gint dinge die es nur in C++ gibt und nicht im C und zwar "call by reference".

Code:

void something( int &a )

Das ist pures C++.
Und C++ ist "etwas" type sicherer geworden. D.h. man kann nicht alles was man in C schreibt direkt mit einem C++ compiler compilieren lassen, es sei denn es ist innerhalb von "extern "C" {}" direktieve. Z.B.

Code:

void (WINAPI *glBegin)(void);
glBegin = GetProcAddress( dllHandle, "glBegin");

In C geht das wunderbar, in c++ aber nicht (nicht ohne typecasting ).

[malo]

Zitat:

Zitat von sniper_w

Immer wieder wenn solche Diskusionen auftauchen, kommt es zu einem Fehler. Man sagt so "in C/C++ ...". Ja, grossteils stimmt das, aber C ist NUR eine Untermenge von C++.

Bei denen die "C/C++" schreiben tritt meist einer der folgenden Fälle auf:
a) Sie wissen nicht, ob der jew. Code nun unter C oder C++ läuft, oder
b) Sie sind zu Faul sich Gedanken drüber zu machen (wie ich meistens), oder
c) Es läuft in beiden Sprachen (nicht) :mrgreen:

Meistens ist aber tatsächlich C++ gemeint ;)

[Oxmyx]

Zitat:

Zitat von Tubos

Zitat:

Deshalb vergleicht man nullterminierte Strings ja nie direkt, sondern in Delphi z.B. mit CompareStr oder in C/C++ mit strcmp/stricmp.

Nein. In C++ kann man den == Operator überladen.
Man muss das nicht mal selber machen, die string - Klasse aus der Standardbibliothek bietet so eine Funktionalität.

Naja, trotzdem ruft man mit == dann strcmp auf. ;)

Zitat:

DAS finde ich richtig hässlich an Java: diese ständigen equals - Aufrufe.
Wenn es in Java mal Operatorenüberladung gibt werde ich mich in dieser Sprache auch wohler fühlen.

Operatorüberladung fehlt mir auch noch in Win32-Delphi.

[malo]

Zitat:

Zitat von Oxmyx

Operatorüberladung fehlt mir auch noch in Win32-Delphi.

Dann freu dich auf Dexter ;)

[jbg]

Zitat:

Zitat von malo

Es gibt natürlich auch diverse Sprachfeatures, die in Delphi nicht vorhanden sind.

Es gibt auch Sprachfeatures, die in Delphi vorhanden sind, aber nicht in C++ :wink:
Schon mal mit COM gearbeitet? Oder bei einem Interface die Implementierung dessen auf eine andere Klasse delegiert?

Zitat:

Dazu gehört (bis einschl. D2005) Operatoren-Überladung

So allgemein kannst du das nicht über Delphi 2005 sagen. Delphi.NET beherrscht Operator-Überlagung. Delphi.Win32 noch nicht.

Zitat:

auch Templates und ähnliches

Was meinst du mit "ähnliches". Mir fällt da nichts weiteres ein.

Zitat:

Das macht Delphi unflexibler, was Problemlösungen angeht.

Die fehlende Operator-Überladung macht Delphi sicherlich nicht unflexibler. Vielleicht unleserlicher, aber nicht unflexibler. Bei Templates sieht die Sache schon anders aus. Wobei einem da meisten mehr die "Generics" statt die ausgewachsenen Templates (z.B. Rekursive Templates) abgehen. Es wäre schon schön, wenn man "TList<TMyClass>" schreiben könnte und nicht jedesmal die Klasse TMyClassList neu schreiben muss (mit den kommenden Live-Templates wird einem dann wenigstens mal die Schreibarbeit abgenommen).

Zitat:

So hat Delphi beispielsweise Probleme mit Treiberprogrammierung

Da du das in den selben Absatz geschrieben hast, wie die beiden oben Zitierten Sätze, hatte ich das erstmal so verstanden, dass wegen der fehlenden Operator-Überladung und Templates mit Delphi keine Treiber möglich sind.
Treiber lassen sich prinzipiell nur mit dem Microsoft C++ Compiler schreiben. Ich habe noch keinen Windows-Treiber von bcc32 oder gcc (Mingw) gesehen. Also ist Delphi da nicht alleine. Treiber brauchen einen speziellen Linker, der die Datei so markiert, dass der Kernel sie auch akzeptiert.

Zitat:

Das ist aber eine der wenigen Ausnahmen von Dingen, die mit Delphi schwieriger sind als mit C++.

Wieviel Prozent der Programmierer schreiben denn einen Treiber? Mich hat es bis heute noch nicht gestört, dass ich keinen Treiber schreiben kann. Dazu gehört auch ein ganzes Stück an Wissen und dieses Wissen brauche ich mir nicht anzueignen, weil ich wahrscheinlich in meinem ganzen Leben nie einen Windows-Treiber schreiben werde.

[malo]

Zitat:

Zitat von jbg

Zitat:

Dazu gehört (bis einschl. D2005) Operatoren-Überladung

So allgemein kannst du das nicht über Delphi 2005 sagen. Delphi.NET beherrscht Operator-Überlagung. Delphi.Win32 noch nicht.

Naja, ich hab auch nur vom Win32-Teil geredet. Wenn ich .NET meine, schreibe ich es i.d.R. seperat nochmal hin. Aber im Grunde hast du Recht. Ich sollte demnächst etwas besser aufpassen, was ich genau schreib ;)

Zitat:

Zitat von jbg

Die fehlende Operator-Überladung macht Delphi sicherlich nicht unflexibler. Vielleicht unleserlicher, aber nicht unflexibler. Bei Templates sieht die Sache schon anders aus. Wobei einem da meisten mehr die "Generics" statt die ausgewachsenen Templates (z.B. Rekursive Templates) abgehen. Es wäre schon schön, wenn man "TList<TMyClass>" schreiben könnte und nicht jedesmal die Klasse TMyClassList neu schreiben muss (mit den kommenden Live-Templates wird einem dann wenigstens mal die Schreibarbeit abgenommen).

Mit unflexbiler meinte ich, dass man weniger Möglichkeiten hat, ein Problem zu lösen. Bei C++ gibt es ja für alles und für jeden mehrere Möglichkeiten, etwas zu machen (verglichen mit Win32-Delphi bis D2005). Ob das jetzt ein Segen oder ein Fluch ist, ist ein anderes Streitthema.
Allerdings ist man schon gewissermaßen beschränkt, wenn man auf die Prozeduren/Funktionen zurückgreifen muss. Einigen wird das egal sein, aber es gibt auch einige große Fans von Operatoren, die da viel lieber einen Operator für schreiben würden. Ist hauptsächlich eine Geschmacksfrage. Und mit D2006 kann man in Delphi (Win32) auch Operatoren überladen :firejump:

Zitat:

Zitat von jbg

Da du das in den selben Absatz geschrieben hast, wie die beiden oben Zitierten Sätze, hatte ich das erstmal so verstanden, dass wegen der fehlenden Operator-Überladung und Templates mit Delphi keine Treiber möglich sind.
Treiber lassen sich prinzipiell nur mit dem Microsoft C++ Compiler schreiben. Ich habe noch keinen Windows-Treiber von bcc32 oder gcc (Mingw) gesehen. Also ist Delphi da nicht alleine. Treiber brauchen einen speziellen Linker, der die Datei so markiert, dass der Kernel sie auch akzeptiert.

Das ist ein eigenes Thema, darüber gibt es genug Threads. Treiber
Übrigens meinte ich nicht, dass Treiber wegen Templates oder Operatorüberladung nicht möglich seien (nur als Info) ;)

Zitat:

Zitat von jbg

Wieviel Prozent der Programmierer schreiben denn einen Treiber? Mich hat es bis heute noch nicht gestört, dass ich keinen Treiber schreiben kann. Dazu gehört auch ein ganzes Stück an Wissen und dieses Wissen brauche ich mir nicht anzueignen, weil ich wahrscheinlich in meinem ganzen Leben nie einen Windows-Treiber schreiben werde.

Ich hab nicht gesagt, dass es schlimm ist, mit Delphi keine Treiber entwickeln zu können. Ich habe es einfach als Beispiel aufgeführt, was mit Delphi nicht geschickt möglich ist. Wie wichtig das ist, ist eine andere Frage ;)

[Christian Seehase]

Moin Andreas,

hast Du Dir das hier schon einmal angesehen:

object_pascal_templates
TCollection und TCollectionItem
TObjectList-Descendant mit Templates

[jbg]

Zitat:

Zitat von Christian Seehase

hast Du Dir das hier schon einmal angesehen:

Klar. Ich habe da sogar was eigenes mal angefangen, dass mir aus

Delphi-Quellcode:

type
  TTemplateList = class(TList){template<T>}
  private
    function GetItem(Index: Integer): T;
  public
    property Items[Index: Integer]: T read GetItem;
  end;

  TIntegerList = TTemplateList{template<Integer>};

folgendes macht/machen sollte:

Delphi-Quellcode:

type
//  TTemplateList = class(TList){template<T>}
//  private
//    function GetItem(Index: Integer): T;
//  public
//    property Items[Index: Integer]: T read GetItem;
//  end;

  {$INCLUDE TTemplateList__Integer__.tpl}//TIntegerList = TTemplateList{template<Integer>};

Mit TTemplateList__Integer__.tpl:

Delphi-Quellcode:

  // [der Delphi-Parser im Forum zieht die erste Zeile immer nach ganz links]
  TTemplateList = class(TList){template<Integer>}
  private
    function GetItem(Index: Integer): Integer;
  public
    property Items[Index: Integer]: Integer read GetItem;
  end;

Das Projekt hatte ich aber aus Zeitmangel recht schnell eingestampft. Übrig blieb der Delphi language Preprocessor (dpp32), der nichts anderes macht als Makros per {$DEFINE Concat(x, y) x##y} einzuführen.

[pajofego]

In den letzten Jahren habe ich nur noch in C++ programmiert. Vorgabe vom Arbeitgeber! Nun gut, ich habe mich an die Macken eines C/C++ Compilers gewöhnt und irgendwann versteht man ihn dann auch. Die Syntax von C finde ich im Vergleich zu Pascal günstiger bzw. ich muss weniger schreiben...ist aber wie schon allseits diskutiert wurde eine reine Geschmaksfrage! Ansonsten fand ich Delphi schlichtweg geil! Der compiler ist/war sauschnell, meine Berechnungen liefen meistens sogar schneller als in C++! Das einzige was mich heute an Delphi nervt - verzeiht wenn ich nicht mehr auf dem neuesten Stand bin, vielleicht hat sich ja dahingehend etwas geändert-, ist:

Die Unterscheidung von Klein und Großbuchstaben (vielleicht arbeite ich zuviel mit LINUX)
Kann man heute endlich in Delphi Operatoren überladen?
begin/end -> das sind 6 Zeichen mehr als "{ }"
sowie keine Makros

Aber wie gesagt, falls der native compiler von delphi immer noch so sauschnell ist wie zu Zeiten von Delphi 6, dann finde ich das heute - zumindestens ist das für mich ein wichtiges Kriterium - verdammt gut!

Schade nur, dass ich nichts mehr in Delphi mache...vielleich ändert sich das ja mal irgendwann wieder! Wenn man einmal in C++ steckt kommt man da nicht mehr so schnell wieder raus.

Gruß

pajofego

[malo]

Zitat:

Zitat von pajofego

Die Unterscheidung von Klein und Großbuchstaben (vielleicht arbeite ich zuviel mit LINUX)

Versteh ich nicht. Delphi ignoriert Groß/Kleinschreibung.

Zitat:

Kann man heute endlich in Delphi Operatoren überladen?

In der nächsten Version geht das, in Dexter ;)

Zitat:

begin/end -> das sind 6 Zeichen mehr als "{ }"

Stört mich eigentlich nicht wirklich... denn begin/end fällt viel leichter ins Auge als { }. Die eckigen Klammern sind viel unauffälliger. Da schreib ich lieber 6 Zeichen mehr.

[noidic]

Zitat:

Zitat von sniper_w

Ja, grossteils stimmt das, aber C ist NUR eine Untermenge von C++.

Das stimmt so nicht, es sind zwei verschiedene Sprachen mit teilweise disjunktem Funktionsumfang. C++ ist auf Basis von C entwicklet worde, ist aber keinesfalls eine Erweiterung von C, damit ist C auch keine Untermenge von C++.

[mumu]

jo also genau so ne diskussion hab ich erhofft :-)

hab absichtlich die frage nicht genauer formuliert, da mir die verschiedensten eindrücke interessieren.

was ich noch klasse in delphi find:
bei VB musste man immer bestimmte dlls mitliefern, damit die applikation lauffähig ist. delphi hingegegen kompiliert alles in die exe. oder was meint ihr?

[pajofego]

Zitat:

Zitat von malo

Zitat:

Zitat von pajofego

Die Unterscheidung von Klein und Großbuchstaben (vielleicht arbeite ich zuviel mit LINUX)

Versteh ich nicht. Delphi ignoriert Groß/Kleinschreibung.

Sorry, ich meinte, das die Nichtunterscheidung mich nervt...aber zum Glück ist das Geschmackssache...Delphi hat verdammt viele Vorteile