C/C++ oder Pascal/Delphi ?

[thos]

hab hier ein echt geiles stück code gefunden das ein für alle mal
klärt ob man in C/C++ oder in Pascal/Delphi coden sollte .. he he he

-------------------------------------------------
#define BEGIN {
#define END }
#define IF(x) if ( x )
#define THEN
#define TRUE 1
#define Writeln(x) printf("%s\n", #x);
#define PROGRAM int
#define main main(void)

PROGRAM main
BEGIN
Writeln(Hello World !)
IF(TRUE) THEN
Writeln(Ende)
END
---------------------------------------------------

noch fragen? :-)

[Bolle]

welche sprache soll das darstellen?

[thos]

das kannst du mit jedem C/C++ compiler kompilieren.
(ist also standard C)

[Felix Kaiser]

Toll und was soll das bringen?

[cYrus]

lol.. gehts nicht noch irgendwie komplizierter :\ vllt perl-code das nächste mal (hat denn c++ denn schon nen md5 funktion oder musste die dann auch noch coden) :P

so long
cYrus

[Bolle]

lol ich wette so hat man vor 20 jahren gecodet. dieses ganze preprozessorgewurschtel....

[Jan Krüger]

naja, wenn du das gleiche ohne die #defines einem pascal-compiler vorsetzt, wird der dir in jeder zeile (außer "IF(TRUE) THEN") einen syntax error liefern. :D
du kannst in C nicht exakt das Verhalten eines Pascal-Compilers nachbauen, dazu sind die Sprachen zu verschieden.

[xOOn]

umgekehrt waere besser weil ich finde den c++ syntax besser!!!

uebrigens der C++ Builder akzeptiert auch .pas dateien!!!!!!

[Jan Krüger]

korrekt, aber das liegt daran, dass der delphi-compiler mitgeliefert ist. und, soweit ich weiß, erst ab der professional edition.

[Felix Kaiser]

xOOn: Im Vergleich zu Delphi ist der C++ Syntax vorallem bei DLLs überhaupt nicht besser, ganz im Gegenteil ;)

Mir fällt grad ein, kann mir irgendwer mal erklären warum der C++ Builder beim Compilieren immer so ewig lange braucht und meint, eineinhalb Millionen Zeilen compilieren zu müssen anstatt nur MEINEN Source und davon auch nur den geänderten neu? Find ich bissl affig vorallem weils stört :mad:

[cYrus]

@felix

dafür brauchst auch nur 5 min zum starten :P ich find das teil echt schrecklich im gegensatz zur delphi ide..

so long
cYrus

[xOOn]

@JaSt
jepp :))

@Felix Kaiser
delphi kompiliert schnell aber suckt wie nicht normal schon wenn man einen double in einen int zuweisst

@cYrus
was findest du schrecklich delphi oder den builder

[Jan Krüger]

xOOn: typecasting gibt es bei object pascal zwar auch, aber klassischerweise und um den code sauberzuhalten, wird eine konverterfunktion benutzt, wenn sich tatsächlich beim typecasten der inhalt der daten ändert (double -> integer == komischer exponentialwert -> zahl).
in object pascal würde mal trunc(double) oder round(double) benutzen.

der delphi-compiler ist eindeutig verdammt schnell, ja. :D
die IDEs finde ich alle in irgendeiner art gut, und zum starten brauchen sie alle nicht lange. aber ich benutze ja inzwischen keine mehr (direkt mal kylix installieren :)).

[xOOn]

naja trunc das sind 7 zeichen (mit () :p) zu lange ich will einfach nur int i = d; :p :p

[Jan Krüger]

das ist aber auch unter C++ nicht sauber (unter C geht es gar nicht).

test.cpp:2: warning: initialization to `int' from `double'
test.cpp:2: warning: argument to `int' from `double'


richtig wäre int i = (int) d; und das sind (mit () und " ") 5 zeichen. wenn du das leerzeichen weglässt, sinds immer noch 4. und in delphi mal schnell einen wrapper zu schreiben, durch den du statt trunc() auch t() schreiben kannst, ist nicht unbedingt so der riesenaufwand. :D

[xOOn]

bei mir kommen nur noch sinnvolle warnungen :D

ich code ziemlich kriminell und wenn ich dann mal nen bock drinnen habe das kannste lange suchen, bist aber meiner meinung nach schneller

[Felix Kaiser]

Die Warnungen sind sinnvoll, da diese Typen schon immer inkompatibel waren. Bei einer Zuweisung double auf int, wird automatisch ein Truncate durchgeführt, da über das FPU der Ganzzahlteil extrahiert werden muss.

Kann mir vielleicht auch mal noch jemand erklären, warum niemand mal auf die Idee gekommen ist C übersichtlich zu gestalten? Es suckt gewaltig in einem Projekt Unmengen von Dateien zu haben. Allein das Prinzip Source und Deklarationen getrennt zu halten ist schon ein Minus. Ich finde es lästig laufend zwischen dem Source und dem Headerfile hin und herzuschalten. Kostet nur Zeit und Zeit ist Geld :p

[xOOn]

warum ist bis jetzt niemand auf die idee gekommen etwas zu bauen, damit sich fenster automatisch ihre groesse anpassen, das funkt auch nicht so richtig, und warum kann man in "pascal" alles machen was man in c++ machen kann:
delphi ist fast kein "pascal" mehr, alles was es in anderen sprachen gibt wurde genommen ein einfacher syntax geaddet und dann das war dann delphi! aber egal derzeit ist c# die einzige sprache ohne wiedersprueche und veralterten scheiss drinn. und ihn 10 jahren laestern alle ueber c#

header und source zu trennen bringt es nicht, aber warum gibt es in delphi out und var :) oder string und AnsiString (ist string nicht das teil welches auf 255 begrenzt ist?)

[Felix Kaiser]

AnsiString ist string und das ist nicht auf 255 Zeichen begrenzt, theoretisch kannst du dort 4 G reinpacken. Außer man sagt dem Compiler, er soll Shortstrings benutzen, dann sinds 255 Zeichen, der klassische Pascalstring.

Was meinst du mit out und var? Var ist ja klar ...

Dass Header und Source trennen nichts bringt, ist mir auch klar und die Entwickler von C haben sich wohl gedacht, wie könnte man am besten Unübersichtlichkeit erzeugen :D

[xOOn]

schreib mal anstatt var out hin, ist genau das selbe 2 befehle fuer 1 ding var ist nur wegen der pascal compt. und out hat sich nicht durchgesetzt

[Felix Kaiser]

Ist ja n Ding, von out hab ich noch nie was gehört :) Aber das ist doch egal und schon garkein Nachteil.

[Jan Krüger]

es gibt sehr wohl einen unterschied zwischen var und out, und zwar einen gravierenden. kleines zitat aus der delphi-doku:
An out parameter, like a variable parameter, is passed by reference. With an out parameter, however, the initial value of the referenced variable is discarded by the routine it is passed to. The out parameter is for output only; that is, it tells the function or procedure where to store output, but doesn’t provide any input.

übrigens, delphi ist nicht der name einer programmiersprache. delphi ist eine entwicklungsumgebung, die die programmiersprache object pascal kompiliert. es gibt auch einige andere compiler, die diesen dialekt verstehen.
und man kann nun nicht gerade sagen, dass C# von der syntax her komplett neuerfunden wäre. also: object pascal ist nicht geklaut, es sind nur ein paar gute ideen übernommen worden (und natürlich eigene sachen dazugekommen). ;)

[xOOn]

@Jast upps **dir rechtgeben** ich haben da was verwechselt

[pyranha]

der delphi-compiler ist eindeutig verdammt schnell, ja.
soviel ich weiss liegt das daran, dass in delphi schon gewisse units vorkompiliert sind. In C/C++ sind die alle als Quelltext vorhanden, und werden frisch vor Ort kompiliert. Dauert länger, aber lässt auch mehr möglichkeiten offen :D.

[Schaf]

geh mal in /usr/lib und guck, was daran nicht-vorcompiliert ist :D

bei delphi sind's compilierte units, bei c und c++ sind's libraries ;)

ps: hat vielleicht endlich mal jemand bcc 5.5 für linux gefunden? :rolleyes:

[Jan Krüger]

Nein, aber hast du schon den Intel C-Compiler getestet? Der soll auch nicht übel sein.

[Scavi]

Dass Header und Source trennen nichts bringt, ist mir auch klar und die Entwickler von C haben sich wohl gedacht, wie könnte man am besten Unübersichtlichkeit erzeugen
...du musst nicht unbedingt Header und Source trennen, du kannst zBsp. in deine Klassendeklarationen gleich den Code einfügen, das nennt sich dann INLINE und soll angeblich sogar noch schneller sein. K.A., aber manche meinen, es sei schlechter Programmierstil. Die Trennung von Header und Source hat auch den Vorteil, dass der Compiler immer weiss, welche Methoden oder externen Variablen existieren und welche nicht und dir diese als Fehler angibt. Und es ist notwendig, wenn man mit Strukturen und Klassen arbeiten will, die in mehreren Klassen oder Strukturen benötigt werden.

[Jan Krüger]

Naja, bei Pascal kommen Deklarationen und Definitionen trotzdem in eine Datei, in zwei verschiedenen Blöcken (interface und implementation).
Im Endeffekt ist das reine Geschmackssache. Ich finde beides ganz nett; bei C(++) hat man aber den Vorteil, dass man keine Dateien auseinanderreißen muss, wenn man nur die Interfacedeklarationen weitergeben will.