home *** CD-ROM | disk | FTP | other *** search
/ Turbo Toolbox / Turbo_Toolbox.iso / turbo4 / fragen. < prev    next >
Encoding:
Text File  |  1987-12-08  |  17.6 KB  |  399 lines
  1.     ALLGEMEINE FRAGEN UND ANTWORTEN
  2.     -------------------------------
  3.  
  4.  
  5.    1. Ist die Größe des Programmcodes und der Daten in irgendeiner
  6.    Form begrenzt (wie in der Version 3.0)?
  7.  
  8.    Jedes Modul eines Programms (d.h. jedes Unit und das Hauptprogramm)
  9.    arbeitet mit einem (konstanten) Code-Segment und kann deshalb
  10.    maximal 64 KByte umfassen. Die Gesamtgröße eines Programms ist nur
  11.    durch den verfügbaren Hauptspeicher begrenzt (max. 640 KByte).
  12.  
  13.    Alle globalen Variablen und Konstanten eines Programms werden in einem
  14.    Daten-Segment gespeichert und sind nach wie vor auf 64 KByte beschränkt.
  15.  
  16.    Der Heap hat (wie in der Version 3.0) keine Größenbeschränkung. Die
  17.    entsprechenden Verwaltungsroutinen arbeiten wesentlich schneller
  18.    und effizienter (minimale Blockgröße der Version 3.0: 8 Bytes, in
  19.    der Version 4.0: 1 Byte). Zusätzlich läßt sich eine
  20.    Fehlerbehandlungsroutine installieren, die automatisch aufgerufen
  21.    wird, wenn New oder GetMem der Speicherplatz ausgeht. Kapitel 6 des
  22.    Benutzerhandbuchs enthält ein Beispiel zur dynamischen
  23.    Speicherverwaltung, Kapitel 25 des Referenzhandbuchs erläutert die
  24.    technischen Hintergründe.
  25.  
  26.    2. Ist Turbo Pascal auf MS-DOS-Maschinen lauffähig, die nicht
  27.    direkt "kompatibel" sind?
  28.  
  29.    Die Kommandozeilen-Version des Compilers (TPC.EXE) macht überhaupt
  30.    keinen Gebrauch von PC-spezifischen Eigenschaften, wenn sie mit dem
  31.    Zusatzparameter /Q aufgerufen wird; die Routinen der Units System,
  32.    Dos und Printer sollten auf allen DOS-Maschinen lauffähig sein.
  33.  
  34.    Mit Turbo Pascal erzeugte .EXE-Dateien sind deshalb 100%ig DOS-
  35.    kompatibel, solange nicht ein oder mehrere der PC-spezifischen
  36.    Units (Crt, Graph und Graph3) verwendet werden. Die
  37.    Software-Fließkommafunktionen sind auf jeder DOS-Maschine
  38.    verwendbar; die 8087-Bibliothek setzt voraus, daß ein
  39.    entsprechender Coprozessor installiert ist, der hardwaremäßig in
  40.    derselben Weise angesteuert wird wie bei einem Computer der
  41.    PC-Serie.
  42.  
  43.    3. Unterstützt die Version 4.0 verschieden große Integerwerte?
  44.  
  45.    Sie tut es - und zwar in jeder denkbaren Form vordefinierter
  46.    Integertypen mit 8 Bit (ShortInt, Byte), 16 Bit (Integer, Word) und
  47.    32 Bit (LongInt).
  48.  
  49.    4. Wird es neue Versionen der 3.0-Toolboxen geben?
  50.  
  51.    Ja. Alle Toolboxen werden zur Zeit entsprechend überarbeitet und an
  52.    die Version 4.0 des Compilers angepaßt. Außerdem werden wir
  53.    spezielle Konditionen für den Umtausch alter Versionen anbieten.
  54.  
  55.    5. Läßt sich die Compilierung von Programmteilen von Bedingungen
  56.    abhängig machen (wie in Turbo C)?
  57.  
  58.    Ja - wobei nicht nur die Definition von Symbolen (mit {$DEFINE} und
  59.    {$UNDEF}) und Prüfungen (mit {$IFDEF..$ELSE..$ENDIF}) möglich sind,
  60.    sondern auch Tests von Compiler-Schaltern. Damit lassen sich
  61.    beispielsweise Real-Datentypen abhängig davon definieren, ob der
  62.    Computer mit einem numerischen Coprozessor ausgerüstet ist oder
  63.    nicht. Zusätzlich lassen sich Symbole zur bedingten Compilierung
  64.    auch direkt beim Aufruf des Compilers (d.h. ohne Veränderung des
  65.    Quelltextes) definieren.
  66.  
  67.    6. Wieviel Platz im Daten-Segment belegt das System, wieviel ist
  68.    tatsächlich für das Programm verfügbar?
  69.  
  70.    Der Platzbedarf der Laufzeitbibliothek im Daten-Segment des
  71.    Programms hängt davon ab, welche Units aufgenommen werden:
  72.  
  73.              UNIT         Datengröße (in Bytes)
  74.              ----         ---------------------
  75.              SYSTEM               585
  76.              DOS                    6
  77.              CRT                   26
  78.              PRINTER              256
  79.              GRAPH                834
  80.              TURBO3               256
  81.              GRAPH3                 0
  82.                                =========
  83.                                  1963
  84.  
  85.    Die Gesamtgröße des Daten-Segments beträgt 65520 Bytes. Einem
  86.    Programm, das nur das Unit System verwendet, stehen also
  87.  
  88.              65520 - 585 = 64935 Bytes
  89.  
  90.    für globale Variablen und Konstanten zur Verfügung.
  91.  
  92.    7. Welche Größe kann eine Datenstruktur maximal haben?
  93.  
  94.    Ein Aufruf von GetMem oder New kann maximal 65521 Bytes auf dem
  95.    Heap belegen. Diese Grenze gilt im Prinzip auch für die Deklaration
  96.    statischer (globaler) Variablen.
  97.  
  98.    8. Läßt sich feststellen, wieviel Bytes Code und wieviele Bytes
  99.    Daten die Compilierung eines Programms oder Units erzeugt?
  100.  
  101.    Innerhalb der integrierten Entwicklungsumgebung compilieren Sie das
  102.    entsprechende Modul und wählen dann "Get info" aus dem Menü
  103.    Compile.
  104.  
  105.    Die Kommandozeilen-Version von Turbo Pascal gibt die entsprechenden
  106.    Daten automatisch am Ende einer Compilierung aus.
  107.  
  108.    9. Inwieweit sind von Turbo Pascal erzeugte Module mit Turbo C und
  109.    Turbo Prolog kompatibel?
  110.  
  111.    Mit Turbo C erzeugte .OBJ-Dateien können über den Compiler-Befehl
  112.    {$L} in ein Pascal-Programm aufgenommen werden (siehe CPASDEMO.C
  113.    und CPASDEMO.PAS auf der Diskette II). Entsprechendes gilt für
  114.    .OBJ-Dateien, die mit einem Assembler (MASM oder A86) erzeugt
  115.    werden (siehe Kapitel 25). Turbo Pascal erzeugt selbst keine
  116.    .OBJ-Dateien, sondern speichert separat compilierte Units in einem
  117.    eigenen Format (.TPU). Für dieses eigene Format gibt es eine ganze
  118.    Reihe von Gründen:
  119.  
  120.    - .TPU-Dateien enthalten neben dem Object-Code Informationen für
  121.      die Fehlersuche und die strenge Typ-Prüfung von Pascal bei der
  122.      Einbindung in ein Programm. Trotzdem sind sie wesentlich kleiner
  123.      als .OBJ-Dateien.
  124.    - .TPU-Dateien erlauben ein "intelligentes" Binden - nicht benutzte
  125.      Programmteile werden vom Linker automatisch entfernt.
  126.    - Das .TPU-Format ist wesentlich einfacher zu bearbeiten und einer
  127.      der Gründe für die hohe Geschwindigkeit des Compilers (bis zu 27000
  128.      Zeilen pro Minute).
  129.  
  130.    10. Lassen sich mit {$L} auch Dateien einbinden, die mit anderen
  131.    Compilern erzeugt wurden (FORTRAN etc.)?
  132.  
  133.    Das hängt vom Compiler bzw. der Programmiersprache ab. Turbo Pascal
  134.    erwartet den gesamten Programmcode einer .OBJ-Datei in *einem*
  135.    Segment mit dem Namen CODE, sämtliche Daten müssen ebenfalls in
  136.    einem Segment (mit dem Namen DATA) gespeichert sein.
  137.  
  138.    11. Werden unbenutzte Daten-Deklarationen ebenfalls automatisch vom
  139.    Linker entfernt?
  140.  
  141.    Nein. Alle Daten, die in einem Programm und seinen Units deklariert
  142.    sind, werden auch in die .EXE-Datei eingebunden. Der Linker
  143.    entfernt nur unbenutzten Programmcode.
  144.  
  145.    12. Wenn ein Unit in zwei Modulen eines Programm mit uses angeführt
  146.    ist, wird es dann auch doppelt in die .EXE-Datei aufgenommen?
  147.  
  148.    Nein. Unabhängig davon, wie komplex die gegenseitigen
  149.    Abhängigkeiten einzelner Units und Programmteile aussehen, nimmt
  150.    Turbo Pascal von jeder benötigten Prozedur oder Funktion exakt EINE
  151.    Kopie in die .EXE-Datei auf - nicht mehr und nicht weniger.
  152.  
  153.    13. Was passiert, wenn Compiler-Schalter in den Modulen eines
  154.    Programms unterschiedlich gesetzt sind?
  155.  
  156.    Compiler-Befehle sind "lokal" zum jeweiligen Unit oder dem Haupt-
  157.    programm; auch bei einem MAKE oder BUILD beginnt die Compilierung
  158.    jedes Moduls mit den über die Menüs bzw. durch die Kommandozeilen-
  159.    Parameter gesetzten Standardvorgaben. Die Schalterstellungen
  160.    einzelner Module sind also unabhängig voneinander.
  161.  
  162.    14. Ist die Erzeugung eigener Unit-Bibliotheken (.TPL-Dateien)
  163.    möglich?
  164.  
  165.    Im Prinzip ja. Die Version 4.0 verwendet allerdings nur eine
  166.    einzige Bibliothek (TURBO.TPL). Mit dem Programm TPUMOVER können
  167.    Sie TURBO.TPL eigene Units hinzufügen - es wäre also möglich, für
  168.    jedes größere Projekt eine separate Version von TURBO.TPL zu
  169.    erzeugen.
  170.  
  171.    15. Welche Regeln sind bei der Erstellung von
  172.    Interrupt-Behandlungsroutinen zu berücksichtigen?
  173.  
  174.    Abgesehen davon, daß Sie sich mit dem BIOS des Computers und mit
  175.    Maschinensprache gut auskennen sollten, gibt es einige Punkte im
  176.    Zusammenhang mit Turbo Pascal:
  177.  
  178.    - Verwenden Sie GetIntVec und SetIntVec (aus dem Unit Dos) zur
  179.      Veränderung von Interrupt-Vektoren.
  180.    - Deklarieren Sie die Behandlungsroutine als interrupt und
  181.      verwenden Sie den Compiler-Befehl {$F+} - die Routine muß als FAR
  182.      codiert werden.
  183.    - Verwenden Sie innerhalb der Behandlungsroutine weder DOS-
  184.      Funktionsaufrufe noch Aufrufe der dynamischen Speicherverwaltung
  185.    - der entsprechende Code ist nicht reentrant.
  186.  
  187.    16. Wann ist eine Pascal-Routine als NEAR codiert, wann als FAR?
  188.  
  189.    Die allermeisten Programmierer werden sich um dieses Detail nie zu
  190.    kümmern brauchen - schließlich wählt der Compiler die richtige Art
  191.    des Aufrufs automatisch aus. FAR-Aufrufe und Rücksprünge werden nur
  192.    benutzt, wenn
  193.  
  194.    - die Routine im Interface-Teil eines Units deklariert ist
  195.    - oder der Compiler-Befehl {$F+} gegeben wurde. Dieser Befehl
  196.      sollte für die folgenden Routinen verwendet werden:
  197.  
  198.          + Interrupt-Behandlung
  199.          + Fehlerbehandlung
  200.          + Exit-Prozeduren
  201.  
  202.    Kapitel 25 enthält weitere Details.
  203.  
  204.    17. Lassen sich mit Turbo Pascal reentrante Routinen schreiben?
  205.  
  206.    Ja, wenn Sie die folgenden Regeln berücksichtigen:
  207.  
  208.    - Alle Daten, die die Routine verändert, müssen sich auf dem Stack
  209.      des Prozessors befinden (d.h. lokale Variablen oder übergebene
  210.      Parameter sein).
  211.    - Typisierte Konstanten werden auch dann im Datensegment
  212.      gespeichert, wenn sie lokal deklariert sind. Sie dürfen durch die
  213.      Routine nicht verändert werden.
  214.    - Punkte, an denen die Routine nicht unterbrochen werden darf,
  215.      müssen mit entsprechenden Befehlen (CLI / STI) eingefaßt werden.
  216.    - Die Routine darf keine anderen Routinen aufrufen, die ihrerseits
  217.      nicht ebenfalls reentrant sind (wie z.B. DOS).
  218.  
  219.    18. Wann sollten die neuen IEEE-Realtypen verwendet werden?
  220.  
  221.    Die neuen Realtypen der Version 4.0 (Single, Double, Extended und
  222.    Comp) sind nur dann verfügbar, wenn der Computer mit einem
  223.    numerischen Coprozessor ausgerüstet ist (siehe Kapitel 24).
  224.  
  225.    Programme, die für mehrere (unterschiedlich ausgerüstete) Maschinen
  226.    gedacht sind, können den Typ Real mit bedingter Compilierung
  227.    redeklarieren:
  228.  
  229.        {IFDEF CPU87 }    { wenn ein Coprozessor vorhanden ist }
  230.        {$N+}                 { dann 8087-Bibliothek aktivieren }
  231.        type
  232.          Real     = Extended;  { und Real als Extended deklarieren }
  233.        {$ELSE}
  234.        {$N-}
  235.        {  Ansonsten wird die Software-Bibliothek verwendet   }
  236.        {  und die IEEE-Typen werden als Real redeklariert:   }
  237.        type
  238.          Double   = Real;
  239.          Single   = Real;
  240.          Comp     = Real;
  241.          Extended = Real;
  242.        {$ENDIF}
  243.  
  244.    19. Was bitte ist der Typ Comp?
  245.  
  246.    Der Datentyp Comp speichert extrem große Integerzahlen - ähnlich
  247.    wie bei den BCD-Typen läßt er sich am besten für Operationen
  248.    verwenden, bei denen keine Rundungsfehler auftreten dürfen.
  249.  
  250.    Obwohl Comp keine "Stellen nach dem Komma" definiert, lassen sich
  251.    Geldbeträge sehr einfach mit Comp-Variablen berechnen, wenn man mit
  252.    der Einheit "Pfennig" arbeitet und Ergebnisse bei der Ausgabe durch
  253.    100 dividiert.
  254.  
  255.    Hinweis: Der Typ Comp ist nur bei Verwendung eines numerischen
  256.    Coprozessors verfügbar.
  257.  
  258.    20. Wieviele signifikante Stellen bieten die IEEE-Realtypen?
  259.  
  260.        Typ        signifikante Dezimalstellen    Platzbedarf
  261.        ------------------------------------------------------
  262.        Single               7-8                  4 Bytes
  263.        Double              15-16                 8 Bytes
  264.        Extended            19-20                10 Bytes
  265.        Comp                19-20                 8 Bytes
  266.  
  267.    21. Wo und wie werden Zwischenergebnisse bei Operationen mit
  268.    IEEE-Realtypen gespeichert?
  269.  
  270.  
  271.    Zwischenergebnisse haben bei der Verwendung eines numerischen
  272.    Coprozessors immer das Format Extended - gespeichert werden sie auf
  273.    dem Rechenstack des 8087. Dieser Rechenstack bietet Platz für 8
  274.    Werte, was für normale Berechnungen mehr als ausreichend ist. Das
  275.    Programm FIB8087.PAS auf der Diskette II demonstriert, wie sich
  276.    auch bei rekursiven Funktionsaufrufen Überläufe des Rechenstacks
  277.    vermeiden lassen.
  278.  
  279.    22. Wie werden IEEE-Fließkommazahlen gerundet?
  280.  
  281.    Der numerische Coprozessor verwendet ein Rundungsverfahren aus dem
  282.    Bankwesen, das sich von der Schulmathematik leicht unterscheidet -
  283.    er rundet "Werte in der Mitte" immer zum nächsten *geradzahligen*
  284.    Wert hin. Einige Beispiele dazu:
  285.  
  286.           Round(0.4) -> 0  Round(0.5) -> 0  Round(0.6) -> 1
  287.           Round(1.4) -> 1  Round(1.5) -> 2  Round(1.6) -> 2
  288.                            ===============
  289.  
  290.    23. Lassen sich Ein-/Ausgaben eines Turbo Pascal-Programms
  291.    umleiten?
  292.  
  293.    Solange Sie das Unit Crt *nicht* benutzen, läßt sich ein Turbo
  294.    Pascal-Programm beim Aufruf von der DOS-Kommandoebene aus in
  295.    derselben Weise umleiten wie ein anderes Programm auch. Wenn Sie
  296.    Crt verwenden und sich die Möglichkeit zu Umleitung der
  297.    Ein-/Ausgabe offenhalten wollen, können Sie die Textdatei-
  298.    Variablen Input und Output mit Assign den Standardwegen von DOS
  299.    zuordnen (vgl. Kapitel 25):
  300.  
  301.        Assign(Output,''); Rewrite(Output);
  302.        Assign(Input, ''); Rewrite(Input);
  303.  
  304.    24. Wie lassen sich 3.0-Programme konvertieren, die mit
  305.    Chain-Dateien arbeiten?
  306.  
  307.    Chain und Execute sind mit .EXE-Dateien nicht möglich. Entweder
  308.    compilieren Sie die einzelnen Chain-Dateien als Units oder Sie
  309.    verwenden die neue Prozedur Exec (siehe Kapitel 8 und 26).
  310.  
  311.    25. Werden Overlays in der Version 4.0 unterstützt?
  312.  
  313.    Nein - es gibt auch nur noch wenige Gründe für ihre Verwendung: In
  314.    der Version 4.0 ist der Gesamtumfang eines Programms nicht auf 64
  315.    KByte beschränkt; der Compiler arbeitet außerdem wesentlich
  316.    effizienter und dürfte deshalb in vielen Fällen auch dann mit einem
  317.    64 KByte-Segment auskommen, in denen die Version 3.0 mit Overlays
  318.    arbeiten muß. Falls Sie aus dem einen oder anderen Grund wirklich
  319.    nicht ohne Overlays auskommen, sollten Sie entweder die neue
  320.    Prozedur Exec zur Verbindung von Programmteilen verwenden oder die
  321.    entsprechenden Programme weiterhin mit der Version 3.0 bearbeiten.
  322.    (Ein intelligenter Overlay-Manager für zukünftige Versionen von
  323.    Turbo Pascal ist in Arbeit).
  324.  
  325.    26. Unterstützt die Version 4.0 das temporäre Sperren gemeinsam
  326.    benutzter Dateien und Records für die Verwendung in Netzwerken?
  327.  
  328.    Im Prinzip ja. Das Unit System enthält eine Variable namens
  329.    FileMode, über die die Art der Öffnung von Dateien festgelegt
  330.    werden kann. Die Laufzeitbibliothek enthält keine speziellen
  331.    Funktionen für das Sperren von Records und Dateiteilen (was aber
  332.    durch entsprechende Aufrufe von DOS ohne weiteres möglich ist).
  333.  
  334.    27. Wie sieht es mit der größeren Effektivität der Version 4.0 im
  335.    direkten Vergleich zur Version 3.0 aus?
  336.  
  337.    Die Programme belegen rund 30% weniger Platz auf der Diskette, die
  338.    "typische" Geschwindigkeitssteigerung liegt zwischen 15 und 30%.
  339.  
  340.    28. Unterstützt die Version 4.0 prozedurale Parameter?
  341.  
  342.    Eigentlich nicht - mit dem Operator @ kann einer Routine allerdings
  343.    die Adresse einer anderen Routine übergeben werden. Aufrufe von
  344.    Funktionen und Prozeduren über Zeiger sind möglich, wenn dazu ein
  345.    inline-Makro verwendet wird (siehe PROCPTR.PAS auf der Disk II).
  346.  
  347.    29. Welche Lizenzgebühren müssen für die Weitergabe
  348.    selbstentwickelter Turbo Pascal-Programme an Borland gezahlt
  349.    werden?
  350.  
  351.    Wie bitte? So etwas haben wir noch nie nötig gehabt.
  352.  
  353.    30. Wie sieht es mit der Fehlersuche auf Maschinenebene aus, d.h.
  354.    einem Debugger?
  355.  
  356.    Neben DEBUG kann jeder symbolische Debugger verwendet werden, der
  357.    .MAP-Dateien verarbeitet. Das Programm TPMAP (auf der Diskette II)
  358.    konvertiert die von Turbo Pascal erzeugten .TPM-Dateien in
  359.    .MAP-Dateien und macht so Zeilennummern, Symbolnamen und andere
  360.    Informationen für Programme wie SYMDEB, Periscope und PFIX+
  361.    verfügbar (siehe Kapitel 9).
  362.  
  363.    31. Gibt es etwas ähnliches wie die statischen lokalen Variablen von C?
  364.  
  365.    Globale Variablen, die im Implementations-Teil eines Units
  366.    deklariert sind, werden als lokal zum entsprechenden Unit behandelt
  367.    und können über den Initialisierungs-Teil des Units auf
  368.    vordefinierte Werte gesetzt werden. Diese Variablen behalten ihre
  369.    Werte zwischen mehreren Aufrufen des Units (wie andere globale
  370.    Variablen auch).
  371.  
  372.    Typisierte Konstanten, die innerhalb einer Prozedur oder Funktion
  373.    deklariert sind, werden im Daten-Segment gespeichert und verhalten
  374.    sich exakt wie statische lokale Variablen von C: sie behalten ihren
  375.    Wert zwischen mehreren Aufrufen, sind aber lokal zur entsprechenden
  376.    Routine.
  377.  
  378.    32. Wo sind die größten Probleme bei der Konvertierung von
  379.    3.0-Programmen zu erwarten?
  380.  
  381.    Das hängt natürlich von der Art des Programms ab - mit UPGRADE.EXE
  382.    (auf der Diskette II) und den in Kapitel 8 beschriebenen Schritten
  383.    sollte eine Konvertierung aber nur in seltenen Fällen größere
  384.    Probleme bereiten. UPGRADE kann sogar große Programme in Units
  385.    unterteilen (und dabei selbständig die notwendigen Deklarationen
  386.    der jeweiligen Interface-Teile erzeugen).
  387.  
  388.    - Die Übergabe von Parametern wird in der Version 4.0 wesentlich
  389.      effizienter ausgeführt - dementsprechend dürften bei den meisten
  390.      inline-Routinen Änderungen notwendig sein.
  391.    - Der Compiler führt eine strengere Typ-Prüfung aus und wird
  392.      getrennt deklarierte Typen in einigen Fällen als nicht mit
  393.      einander kompatibel ausweisen.
  394.    - Die Prozeduren MsDos und Intr erwarten einen Parameter des Typs
  395.      Registers, der im Unit Dos deklariert ist und die in der Version
  396.      3.0 notwendige Typ-Definition Regs = record .. (AX, BX, CX, DX..)
  397.      ersetzt.
  398.  
  399.