letzter Beitrag von cbmhardware am
Du hast da ein %s unterschlagen....
Warum so einen Urahn benutzen (Borland C++ 5.5 gibts auch frei), es gibt doch sehr viel schönens auf dem Markt:
http://www.openwatcom.org/
http://www.mingw.org/
http://www.delorie.com/djgpp/
imho hat jeder so seine Eigenheiten....
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.
ZitatBisher 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 :=)
Zitat
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)
Jaja, das Elend mit dem Portieren. Ein klarer Punkt fuer C. Das Umgehen der 64kB-Grenze ist bei BP auch nicht lustig. Zum inline-asm moechte ich mal eines Deiner zitierten Zitate zitieren 
: "Insisting on perfect safety is for people who don't have the balls to live in the real world. <Mary Shafer>".
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. 
Und gefaehrlich ist es auch.
Michael
ZitatInline-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.
Und fieso gibt es diese ganzen schönen Optimierdinger nur in der C/C++ Welt?
Basic und Pascal werden ja zum verrecken nicht optimiert.
Da werden sogar so Bremsen eingebaut wie Bytecodeinterpreter (VB!!!) 
ZitatOriginal 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.
Und wat is mit Tee... erm.... Basic?
Mal abwarten bis FB ein GCC frontend geworden ist, dann ist Basic endlich genauso schnell wie C. Dann gibts keinen Grund mehr das kryptische C zu nutzen. *mal wieder in Klammern und Semikolons verheder*
Koennte mir jemand erklaeren, warum aus folgenden Zeilen 102763 Bytes als EXE werden ? 
Bei Borland Pascal 7 hatte das ganze Programm gut 11kB als EXE.
Vieleicht koennte jemand eine Gegenprobe machen.
Michael
Weis nicht, aber kann sein das du die beiden Libs die da oben stehen statisch linkst, sie also Teil deines Programms werden.
ZitatWeis 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.
ZitatOriginal 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.
