Delphi-Language erweitern !?

[Robert_G]

Zitat von Christian Seehase:

wohl nicht intuitiv und lesbar genug, denn es müsste...

Jo , ++ hätte vorher stehen müssen.

[SirThornberry]

@sECuRE: Klar geht das, aber hier wollen Leute eben unbedingt nur "++" schreiben und sind zu faul noch die "(" und die ")" zu tippen. Wenn man es als Funktion mit den Klammern macht kommt man in delphi mindestesn auf 3 zeischen die man tippen muss (+ variablenname)
a(ZuIncrementierendeVariable) und mit dem "++" bräuchte man eben nur 2 Zeischen tippen...

Ich finds auch bischen übertrieben, wenn einem der C++ Syntax besser gefällt soll man eben C++ programmieren und nicht versuchen Delphi den Syntax von C++ beizubringen.

[Flocke]

Wenn man in Delphi ++i und i++ erlaubt, dann müsste man das aber auch für Zeiger definieren und ebenso einführen, dass Zuweisungen gleichzeitig auch Ausdrücke sind, also dass so etwas in Delphi geht:

Delphi-Quellcode:

while (cZeichen := pString++^) <> #0 do
begin
  //...
end;

oder
a := (b := (c := (d := e + 1) + 5) * 2) - 3;

[Robert_G]

Zitat von SirThornberry:

@sECuRE: Klar geht das, aber hier wollen Leute eben unbedingt nur "++" schreiben und sind zu faul noch die "(" und die ")" zu tippen. Wenn man es als Funktion mit den Klammern macht kommt man in delphi mindestesn auf 3 zeischen die man tippen muss

Es geht doch nciht darum wieviel getippt werden muss.
inc ist eigentlich keine Delphi syntax, es ist eine prozedur. OK, sie wird wohl immer in inlining resultieren, denoch hat sie nichts mit Delphis syntax zu tun.
Die IDE würde inc nicht rot färben, sie tut es sehr wohl für Operatoren. (Zumindest wenn man es so einstellt )

Zitat von SirThornberry:

Ich finds auch bischen übertrieben, wenn einem der C++ Syntax besser gefällt soll man eben C++ programmieren und nicht versuchen Delphi den Syntax von C++ beizubringen.

Das wäre nicht nur übertrieben, es wäre schlichtweg dumm.
Aber ++, --, +=, -= wären doch nett. Das ist auch keine C++ syntax! Das sind einfach nur Operatoren. (+,-,*,/ ist doch keine C++ Syntax )
D2005 kam mit "for Item in Container", das gab es vorher auch nicht.
Aber es ist, gerade in .Net, nunmal eine ziemlich nette Neuerung. Da kam doch auch keiner daher und hat rumgepupt, weil es eine Nachmache von C#'s "foreach" bzw. VB's "for each" ist.

@Flocke, warum nicht? Aber nur wenn dein zweites Beispiel mit 10 Jahren Cobol bestraft werden würde.

[malo]

Zitat von PierreB:

C++ bietet aber auch die Möglichkeit des ++var, wofür ich in Delphi auch keine Umsetzung kenne. Warum sollte ich mich mit dem zufriedenenstellen was ich hab ? Würdest du lieber inner 50m² Wohnung oder inner Villa wohnen ?

Du vergisst aber die Nachteile bei der Sache: Wenn du eine Villa hast, musst du es auch noch schaffen, diese sauber zu halten. Du musst viel größere Wege gehen, wenn du irgendwo hin willst und du hast viele, viele leer stehende Zimmer.

So ähnlich sehe ich das mit den Programmiersprachen auch.

Klar, Delphi ist irgendwo schon beschränkt, und bietet weniger Möglichkeiten als C++. Du musst den C++-Code sauber halten. Ein gutes Beispiel sind da Variablendeklarationen oder Klassendeklarationen. All das muss man in Delphi ordentlich in einem seperaten Part machen. Bei C++ ist es möglich das alles "irgendwo" zu machen. Meiner Meinung nach schon ein Nachteil von C++.

Außerdem hat C++ sehr viele Features. Aber sei mal ehrlich... wieviele davon nutzt du auch wirklich? Mehrfachvererbung, schön und gut. Aber ich hab so etwas bisher nie gebraucht. Operatorüberladung... auch toll. Ist es nicht egal, ob man für eine Routine eine Variable mit einem Operator aufruft, oder ob man dafür eine Funktion schreibt?
Natürlich, Inkrementor-Operatoren sind schick. Aber häufig reicht es auch, wenn man das ganze mit inc(x) und dec(x) macht. Eine nette Spielerei, mehr nicht.

Und C++ bringt sehr viele Möglichkeiten mit. Teilweise zu viele... das erhöht häufig auch nur die Kompilierzeit. Und die meisten Dinge benötigt man auch nicht wirklich...


Ich bin der Meinung, dass etwa die Hälfte der C++-Features, die in Delphi "fehlen" auch nur Spielereien sind, die auch nicht unbedingt notwendig sind.

Mal ganz zu schweigen von den Umwegen, die man zum Teil gehen muss (Beispiel: strings. Klar, man kann strings.h / string.h einbinden und dann einfach einen String deklarieren. Aber das erhöht auch nur die .exe. Wenn man das nicht will, muss man entweder sinnlos mit Pointern um sich werfen oder ein Char-Array deklarieren).

Außerdem bringt C++ viele Routinen (Operatoren, Funktionen etc.) mehrfach mit. Beispiel: Konsolenausgabe. In einer Datei steht cout<< (oder cin>>? egal), in einer anderen steht printf. Wenn man jetzt in Unit2 eine bestimmte Funktion braucht, aber schon Konsolenausgabe mit cout gemacht hat, der bindet trotzdem die gleichen Funktionen NOCHMAL ins Programm ein. Sinnvoll?



Ach, jetzt krieg ich bestimmt Schläge von Robert, aber... naja

[sECuRE]

Hi,

also ich finde, dass man in C(++) durch Headerfiles durchaus Ordnung reinbringen kann, in Delphi steht ja Header und Code für gewöhnlich im selben File. Des Weiteren ist die Sache mit den Strings und printf/cout der Unterschied zwischen C und C++ - cout und string ist C++, printf und char-arrays ist C. Wegen der Abwärtskompatibilität gehen die C-Funktionen auch in C++. Leider sind viele Funktionen in C++ nicht vorhanden, sondern nur in C, sodass man zwischen C-strings und strings hin- und her-casten muss .

cu

[alzaimar]

Ja, die Performance. Die ++/-- Dinger von C sind wirklich ne tolle Sache, performancetechnisch gesehen.

[schöni]

Hallo PierreB!

Du warst es doch , der das Them begonnen hat. Du willt also die Sprache ObjectPascal (oder heißt die inzwischen Delphi wie die IDE?) um neue Elemente erweitern. Das klappt definitiv nicht, denn dazu müßtest Du den Compiler erweitern. Der muß ja am Ende das neue Sprachkonstrukt auch lesen können, um passenden Code dafür generieren zu können. Jetzt erhälst Du bei dem von Dir gebrachten Beispiel i++ einen Sysntaxfehler. Wenn der Compiler aber i++ wie inc(i) verstehen soll, muß folglich die Logik des Parsers (ein Teil des Compilers geändert werden. Das geht bei Delphi nicht, denn dazu brauchst Du den Quelltext und den wird Borland wahrscheinlich nicht rausgeben, vielleicht noch nicht mal gegen sehr viel Geld. Wenn Du dich im Compilerbau auskennst, kannst Du derartiges mit Freepascal machen, weil dort der Compiler im Quelltext vorliegt. Mal abgesehen vom Einarbeitungsaufwand in die Quelltexte. Also zusammenfassend gesagt, wenn eine Programmiersprache um neue Sprachelemente (Schlüsselwörter, Schreibweisen u.a.) erweitert werden soll, muß ein Eingriff in die Logik des Compilers erfolgen. Anders sieht es aus, wenn unter Verwendung derselben Spachsyntax neue Unterprogrammbibliotheken oder Komponenten erstellt werden sollen.

Ich hoffe, das Problem ist jetzt klar! Es grüßt

schöni

[Robert_G]

Hmpf? Schlecht gefrühstückt, Schöni?
_Natürlich_ müsste der Compiler geändert werden. Und warum zum Geier soll das nicht gehen?
Ging ja für "for in", interfaces, dyn. arrays,... auch.

[PierreB]

@malo:
Es ging mir mit diesem Thread nicht darum, die Vor- und Nachteile von C++ zu erläutern.

@SirThornberry und ein paar andere:

Zitat:

Ich finds auch bischen übertrieben, wenn einem der C++ Syntax besser gefällt soll man eben C++ programmieren und nicht versuchen Delphi den Syntax von C++ beizubringen.

Darum ging es mir auch nicht. Wie du einigen von meinen Posts entnehmen kannst, habe ich den ++ Operator nur als Beispiel angebracht, eigentlich ging es mir darum, zu erfahren, ob man die Sprache ObjectPascal (also Delphi) erweitern kann.

@schöni: Jupp alles klar, danke für deinen Post.