C oder Delphi oder was?

[Nils_13]

Es ist gewöhnungssache. Delphi ist allgemein zwar recht übersichtlich, aber C/Cpp ist auch gut zu durchschauen und ich sehe beide Dialekte als gut gelungen an.

[bigg]

moin,

hast du die WinAPI wirklich unter C++? Ich denke nicht, zumindest würde es keinen Sinn machen, direkt auf die WinAPI zu zugreifen. :zwinker: Und wie die meisten hier wissen, ist C != C++! In C darfst du deine Variablen schön oben deklarieren. Objektorientierte Programmierung gibt es unter C nicht.

Und der Vergleich von Pascal und Delphi hinkt ebenfalls.

[St.Pauli]

Ich verstehe den Sinn des Themas nicht ganz. Du hast uns gefragt, ob du dein geplantes Projekt in C/C++ oder in Delphi programmieren sollst. Nun gut, wir liefern dir ein Pro-Argument nach dem anderen, aber du probierst uns von C/C++ zu überzeugen!?!?

Die Effizienz eines Programmieres hängt unter anderem von der verwendeten Syntax ab. Pascal verfügt nunmal, im Gegensatz zum "kryptischen" C/C++, über eine sehr lesbare Syntax. Und wir sind alles Menschen. Und ich bezweifele stark, dass es für ein menschliches Gehirn einfacher ist, sich in der C/C++ Syntax zurecht zu finden als in der von Pascal.

[Bernhard Geyer]

- buf[128] wird nicht verwendet.
- Wo wird errno initialisiert oder ist das eine herumgeisternte globale Variable (Schlechtes Design)
- Wird hier time_t noch signed oder unsigend verwendet? Sprich: Ist der Code nur bis 2030 oder 2100 lauffähig?
- Einen Fehlerwert mittels eines gültigen Wertes zu kennzeichnen ist auch nicht gerade schön. Was ist wenn time_t mal erweitert wird und LONG_MAX immer noch den maximalwert eines bestimmten Datentyps darstellt? (Schöne Portierbarkeit von C/C++-Code)
- Wieso muß es in C/C++ immer 50 verschiedene neue Typen für einen Integer geben. size_t ist so ein Fall
- Was macht stat?
- Einmal wird table->check_file im Sinne eines Booleans verwendet und einmal wird 0 zugewiesen. Sinnvoller wäre hier FALSE zu verwenden (Ach ja: Bloß wo ist das wieder definiert bzw. wurde es auch richtig definiert).

Also in meinem Augen ist das nicht das beste Beispiel für einen gut lesbarern Code.

[Garfield]

Zitat:

Zitat von morp2

... Zum einen hab ich da Delphi 7 mit der super VCL, zum anderen hab ich das Visual Studio 2005 mit C++ und der WinApi. ...

Mit Deiner Frage wirbelst Du hier ganz schön Staub auf. Warum vergleichst Du eigentlich das alte Delphi 7 und nicht das aktuelle Turbo Delphi mit VS 2005?

[alzaimar]

Zitat:

Zitat von morp2

...
Jetzt nochmal in C

Code:

void schreiben(char *s)
{
    printf("%s", s);
}

Bei C erkenne ich auf einen Blick dass mit { ein Block beginnt und mit } der Block endet. Bei Delphi muss ich den Quellcode, wie gesagt, lesen um auf das gleiche Ergebnis zu kommen.

:wall: Selten so was Blödes gelesen...

Code:

void schreiben (char *s) {printf
("%s"
,s)
;}

Kommt doch immer drauf an, wer und wie man es formatiert, gelle?

Zitat:

Zitat von morp2

...Ok hier erkennt man das vielleicht nicht, aber bei 1000 Zeilen Quellcode kann mich das schonmal in den Wahnsinn treiben.

Wer lesen kann, ist klar im Vorteil :mrgreen: Und "C" kann sehr unleserlich werden:

Code:

for (;i++<*++j;*i++) if (!*--i) i+=j

Aaaaahh. Ja. DAS treibt nun *mich* in den Wahnsinn.

C ist kein deut besser orer schlechter als Pascal. Wichtig ist, das man die Ideen in gut lesbaren Code umsetzen kann, und dabei ist dann die Sprache wirklich egal.

Es gibt aber eine Eigenheit von Amateuren: Sie versuchen, Ihre Unwissenheit hinter komplexen Verklausulierungen zu verbergen: Politiker reden geschwollen daher, Gesetzestexte sind bis zur Unkenntlichkeit verklausuliert und ... Die Mehrheit der Programmierer verwendet 'C'.

[mkinzler]

Zitat:

Warum vergleichst Du eigentlich das alte Delphi 7 und nicht das aktuelle Turbo Delphi mit VS 2005?

Ist doch in diesem Kontext irrelevant. Ihm geht es ja um grundsätzliche Eigenschaften/Unterschiede der Syntax von C und Pascal. Seine Vorbehalte können wir hier auch nicht ausräumen.

[alzaimar]

@morp2: Preisfrage: Woher kommen die ganzen Buffer Overruns, die für die Instabilität der meisten Programme verantwortlich sind? Von der dämlichen C Library, der kranken Syntax und den noch bescheuerten Halbamateuren, die sich mit ihrem Frickelwissen 'C' als 'Cult' Programmiersprache (Chit wäre besser) ausgesucht haben (Gründe in meinem vorherigen Post).

Wenn diese Dünnbretttippsen eine ordendliche Programmiersprache mit wohldefinierter Syntax und einer Library verwendet hätten (die nämlich nicht ganz so viel Müll erlaubt wie 'C'), dann wären uns viele der Exploits (nicht alle, is ja logisch), Bufferoverruns, DoS-Attacken etc. erspart geblieben.

Die IT-Welt ist nicht *dank* C so weit, sondern *trotz*!

Das musste mal gesagt werden.

[morp2]

Zitat:

Zitat von Bernhard Geyer

- buf[128] wird nicht verwendet.

Ja stimmt ich hab den Code an der Stelle etwas gekürzt

Zitat:

Zitat von Bernhard Geyer

- Wo wird errno initialisiert oder ist das eine herumgeisternte globale Variable (Schlechtes Design)

#define errno (*_errno())

Zitat:

Zitat von Bernhard Geyer

- Wird hier time_t noch signed oder unsigend verwendet? Sprich: Ist der Code nur bis 2030 oder 2100 lauffähig?

Kommt auf den Compiler an. Im VS signed.

Zitat:

Zitat von Bernhard Geyer

- Einen Fehlerwert mittels eines gültigen Wertes zu kennzeichnen ist auch nicht gerade schön. Was ist wenn time_t mal erweitert wird und LONG_MAX immer noch den maximalwert eines bestimmten Datentyps darstellt? (Schöne Portierbarkeit von C/C++-Code)

Der Schrei nach Portierbarkeit ist eine Erfindung von genervten Java Programmierern ;)

Zitat:

Zitat von Bernhard Geyer

- Wieso muß es in C/C++ immer 50 verschiedene neue Typen für einen Integer geben. size_t ist so ein Fall

Das hat damals als wir noch nicht mit IDEs programmiert haben die Lesbarkeit ungemein verbessert

Zitat:

Zitat von Bernhard Geyer

- Was macht stat?

Wenn ich dir Delphicode zeige in dem eine Funktion namens stat benutzt wird kannst du mir dann sagen was stat macht? Bzw ein Rechtsklick und dann auf "Gehe zu Definition" reicht um es rauszufinden

Zitat:

Zitat von Bernhard Geyer

- Einmal wird table->check_file im Sinne eines Booleans verwendet und einmal wird 0 zugewiesen. Sinnvoller wäre hier FALSE zu verwenden (Ach ja: Bloß wo ist das wieder definiert bzw. wurde es auch richtig definiert).

Was heißt hier richtig definiert? False war 0 und False wird auch immer 0 sein.

[Nils_13]

Zitat:

Zitat von alzaimar

@morp2: Preisfrage: Woher kommen die ganzen Buffer Overruns, die für die Instabilität der meisten Programme verantwortlich sind? Von der dämlichen C Library, der kranken Syntax und den noch bescheuerten Halbamateuren, die sich mit ihrem Frickelwissen 'C' als 'Cult' Programmiersprache (Chit wäre besser) ausgesucht haben (Gründe in meinem vorherigen Post).

Wenn diese Dünnbretttippsen eine ordendliche Programmiersprache mit wohldefinierter Syntax und einer Library verwendet hätten (die nämlich nicht ganz so viel Müll erlaubt wie 'C'), dann wären uns viele der Exploits (nicht alle, is ja logisch), Bufferoverruns, DoS-Attacken etc. erspart geblieben.

Die IT-Welt ist nicht *dank* C so weit, sondern *trotz*!

Das musste mal gesagt werden.

Und womit wurde Delphi programmiert ? Imho mit C++ und das ist schließlich die "Verbesserung" von C und da würde ich doch lieber bei *dank* und *trotz* (wegen deinen Argumenten) zugleich bleiben. C ist nunmal veraltet, also was bringt es, die neusten Delphiversionen mit C zu vergleichen ? Das wollte ich mal los werden.

An den Fragesteller: Du hättest diese Frage in einem neutralen Forum, in dem es um Delphi und C geht stellen sollen.