Borland Turbo C 2.0

selbst den M$ compiler gibts kostenlos... diesen uralten scheiss würde ich mir echt nicht antun, da gewöhnst du dir nur dinge an die sich dann später böse rächen.

Quote

Bisher konnte ich noch keine Vorteile gegenueber Pascal mit Inline-ASM erkennen. Nur die Typenstrenge ist natuerlich nicht da.

portabilität, die mit pascal zu erreichen dürfte schwierig werden. (und inline assembler gehört echt verboten, zumindest heutzutage braucht den niemand mehr wirklich)

und wenn du einen etwas moderneren kompiler (gcc4 meinetwegen) nimmst und da alle warnings anmachst und die warnings zu errors machst (-W -Wall -Wextra -Werr) dann hast du mehr typenstrenge als dir lieb ist :=)

Quote

Inline-asm Ist natuerlich nicht portierbar, aber wenn man das tatsaechliche Optimum braucht, geht es imo nicht anders. Mit ausreichend Assembler, steckt ein Pascal-Programm, C in den Sack. Auch wenn der Vergleich etwas hinkt.

ich wage das zu bezweifeln. um einen modernen compiler an effizienz zu übertreffen musst du schon *sehr* gut assembler beherrschen. klar das es ein paar sonderfälle gibt in denen inline-asm sinn macht, aber in fast allen fällen geht es auch ohne.

(davon ab, inline asm geht natürlich auch prima in C =))

Im Übrigen: Inline-ASM hat die dumme Eigenschaft, dass die meisten Optimierer in den Compilern den Bereich davor und danach nicht optimieren können, weil sie den Assembbler-Code nicht verstehen.

Resultat: Die kleine Optimierung, die man vielleicht einbauen wollte, kann sich im Endeffekt leicht ins Gegenteil verkehren, weil alles darum schlechter optimiert ist.

Resultat: Man sollte genau wissen, was man macht (und es nicht nur vermuten), und: Messen, messen, messen, ob das Ergebnis wirklich das erwartete ist.

Für alle die Denken, dass man doch so viel kleverer sein kann als der Compiler: Versucht mal Itanium-Code (oder den von anderen Prozessoren mit VLIW) zu optimieren.

Gruß,
- Spiro.

Quote

Original von BastetFurry
Und fieso gibt es diese ganzen schönen Optimierdinger nur in der C/C++ Welt?

Wer sagt das? Natürlich läßt sich ein Optimierer auch bei anderen Sprachen nutzen. Andererseits werden die Optimierer immer besser; ältere Compiler können da normalerweise nicht mithalten.

Falls du also ein Uralt-Pascal hast könnte das Probleme machen.

Ich vermute (!), dass moderne Delphi-Varianten sehr gut optimiert werden.

Auch kann ich mir vorstellen, dass der gcc aus Pascal-Quelltexte Code erzeugt, der einem C-Quelltext in nichts nachsteht. Möglicherweise ist er sogar besser, da (IIRC) in Pascal kein Pointer-Aliasing erlaubt ist. Für die letzte Aussage aber bitte nicht steinigen, es ist schon seeeeehr lange her, dass ich mich mit Pascal beschäftigt habe.

Gruß,
- Spiro.

Quote

Weis nicht, aber kann sein das du die beiden Libs die da oben stehen statisch linkst, sie also Teil deines Programms werden.

das würde ich auch mal vermuten... schon wenn du nur printf benutzt führt das dazu das fast die komplette fileio lib angelinkt wird.... wenn du nur conio benutzt sollte das schon deutlich kürzer werden.

Quote

Original von cbmhardware
Koennte mir jemand erklaeren, warum aus folgenden Zeilen 102763 Bytes als EXE werden ?

Gegencheck mit Borland C++ 3.1, default-Projekt (also keine Einstellungen geändert). D.h., u.a. mit Speichermodell "small": 15.673 Byte.

Nach TDSTRIP (entfernen der Debug-Symbole): 12.112 Byte, Debug-Symbole (.TDS): 3.561 Byte.

Du solltest allerdings die Warnungen abstellen, indem du noch io.h und stdlib.h per #include einbindest.

Dann beschwert er sich noch, dass userhelp() ohne Prototypen aufgerufen wird. Du solltest lieber void userhelp(void) schreiben, zumindest, wenn es ein C Programm sein soll (bei C++ sieht das anders aus).

Übrigens sollte dein main() entweder als void main(...) deklariert sein (womit es aber nicht mehr Standard-C ist), oder aber einen Rückgabewert haben (return ...). Der Compiler beschwert sich weiterhin, dass der Wert von ch nie benutzt wird.

Ein exit() in der main() finde ich persönlich "unschön", ich würde es eher durch ein return ersetzen. Allerdings ist das nur persönlicher Geschmack.

Über die Sicherheitsaspekte von fgets() sage ich hier mal nichts...

Grundsätzlich ist es so, dass Turbo Pascal besser gelinkt hat, sprich: Es konnten deutlich mehr Teile weggelassen werden, so dass die ausführbaren Dateien letztendlcih zumeist kleiner waren als entsprechende C-Programme. So groß wie dein Programm sollte es allerdings nicht werden.

Auch ja: Compiliere ich das Programm als C++, dann ist es 34 Byte größer.

Gruß,
- Spiro.

Oh, entschuldige, wegen des Titel des Threads war ich von BC 2.0 ausgegangen.

Hm... Meine Version von djgpp (habe ich mir mal installiert, um Pete bei mnib zu unterstützen) nutzt gcc 4.0.1 (gcc --version). Das komilierte Programm ist dann tatsächlich 101.259 Byte groß!

Klingt so, als ob die Libraries "ungünstig" sind und extrem große Mengen reingelinkt werden (wie sauhund schon richtig sagte).

Gruß,
- Spiro.