Borland Turbo C 2.0


  • cbmhardware
  • 2280 Aufrufe 26 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Borland Turbo C 2.0

    Ich habe mir kurz den Compiler aus dem Borland-Museum runtergeladen. Irgendwie werde ich das Gefuehl nicht los, das der irgendwie seine Tuecken hat.

    Quellcode

    1. #include <stdio.h>
    3. main (int argc,char *argv[])
    4. {
    5. FILE *stream;
    8. if (argc <= 1) { printf("Bitte Dateinamen angeben.");exit(1); }
    11. printf("\n Dateiname : ");
    12. printf(argv[1]);
    14. }
    Alles anzeigen


    Warum funktioniert folgendes nicht ?:

    Quellcode

    1. printf("\n Dateiname : ",argv[1]);


    So steht es in meinem Buch. Nur TC2.0 zeigt dann nichts mehr an.

    Sollte man lieber sofort djgpp nehmen ? - Bei den ungenauen Fehlermeldungen von dem TC-Compiler, koennte man auch die Pocken kriegen.

    Michael
    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von cbmhardware ()

  • Oops, Du hast recht. In dem Beispiel war ein Zaehler. Den habe ich rausgelassen. Dabei ist das %s unter die Raeder gekommen.
    Compiler doch nicht doof, ich blind.

    danke,
    Michael
    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von cbmhardware ()

  • Ich weiss. Ist nur zum Ueben. Mir ist ein Buch in die Finger gefallen und die 1.1MB TC waren in einer Minute installiert.
    Bis ich durch dieses C-Gestruepp mal durch bin, wird sicher noch einige Zeit vergehen.

    Muss demnaechst mal den ZIP-Picker von djgpp benutzen.

    Michael
    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -

  • Ich habe mal djgpp mit der Rhide-IDE installiert. Das sieht eigentlich ganz gut aus.
    So habe ich eine IDE fuer DOS und Win98. Dann muss ich mich nicht jedesmal umstellen.

    Zum ein bischen C ueben und spaeter vieleicht kleine Tools, sollte das imo reichen.

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

    Michael
    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -

  • 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 :=)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von sauhund ()


  • 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
    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -

  • 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.

  • 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.

  • 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*
    SELECT signatur FROM dummesprueche WHERE forumsbezug > 0
    0 rows returned.

  • Koennte mir jemand erklaeren, warum aus folgenden Zeilen 102763 Bytes als EXE werden ? :schreck!:

    Bei Borland Pascal 7 hatte das ganze Programm gut 11kB als EXE.



    C-Quellcode

    1. #include <stdio.h>
    2. #include <conio.h>
    4. void userhelp()
    5. {
    7. clrscr();
    8. textcolor (WHITE);
    9. cprintf("--- XSender V1.3 ---\n\r\n\r");
    10. textcolor(LIGHTGREEN);
    11. cprintf("Feierabend\n\r");
    16. }
    20. main(int argc, char *argv[])
    21. {
    23. FILE *stream;
    24. char *ch;
    25. char buf[32768];
    27. clrscr();
    31. // Dateiname und groesse ueberpruefen
    32. if (argc <= 1) {textattr(BLINK | (BLACK) | LIGHTRED);cprintf("\nBitte Dateinamen angeben !\n\a");exit(1); }
    33. if ((stream=fopen(argv[1],"r")) == NULL){textattr(BLINK | (BLACK) | LIGHTRED); cprintf("\nDatei nicht vorhanden !\n\a");exit(1);}
    34. if (filelength (fileno (stream)) > 32768) {textattr(BLINK | (BLACK) | LIGHTRED);cprintf("\nDie Datei ist zu gross!\n\a");exit(1);}
    36. textcolor(WHITE);cprintf("--- XSender V1.3 ---\n\r");
    38. printf("# Buffering File : %s",argv[1],"\n\r");
    40. stream= fopen(argv[1],"r"); // Datei oeffnen
    41. ch = fgets(buf,filelength (fileno (stream)),stream); // Array einlesen
    42. fclose(stream); // Datei schliessen
    44. // putchar(buf[2]); // nur zur Kontrolle
    47. userhelp();
    49. }
    Alles anzeigen



    Vieleicht koennte jemand eine Gegenprobe machen.

    Michael
    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von cbmhardware ()

  • 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.

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

    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.

  • Ich benutze djgpp. Der Compiler ist gpp ? - Irgendwie wird der von der Rhide-IDE aufgerufen. Ich muss mal die Einstellungen suchen.

    Habe einfach ein paar Zeilen in freier Zeit getippt und noch nicht viele Gedanken gemacht.

    Danke fuer die Tipps !

    Habe es mit TC 2.0 kompiliert : 16,5 kB.

    Michael
    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -

  • 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.