Die in Quelltext 12.1 genutzte Möglichkeit, die Hallo-Welt-Ausgabe zu formatieren, ist ja schon einmal recht praktisch — immerhin sind in Zukunft statt drei Zeilen Code nur noch eine Zeile nötig. Allerdings will man vermutlich nicht so häufig die Welt grüßen, sondern stattdessen möglicherweise einen anderen Text ausgeben. Diesen Text werden wir jetzt als Parameter übergeben.

Parameter sind Werte, die beim Aufruf der Prozedur an das Unterprogramm übergeben werden und dort in einer Variablen zur Verfügung stehen. Bei der Definition der Prozedur wird hinter dem Prozedurnamen in Klammern die Parameterliste übergeben. Das ist eine durch Komma getrennte Liste aller Parameter, die beim Aufruf der Prozedur übergeben werden müssen, einschließlich Datentyp. Die Prozedur aus Quelltext 12.1 soll nun so verwendet werden, dass sowohl der auszugebende Text als auch die Einrückung vor der Ausgabe von Aufruf zu Aufruf variiert werden kann. Außerdem wird für die Prozedur auch noch ein passenderer Name ausgewählt.

Die beiden übergebenen Parameter — beim Prozedur-Aufruf in Zeile 7 ist es die Zeichenkette "1. Unterprogramme" und die Zahl 1 — werden innerhalb der Prozedur den Variablen text und einrueckung zugewiesen und können nun genutzt werden. Jedoch nur innerhalb der Prozedur; außerhalb sind die beiden Variablen dem Programm nicht bekannt.

Beim Aufruf einer Prozedur müssen die Parameter nicht in Klammern stehen (sehr wohl aber bei der Definition). Möglich ist also auch ein Aufruf in der Form:

Ob die Klammern gesetzt werden oder nicht, ist weitgehend Geschmacksache — ohne Klammern entspricht es eher der gewohnten BASIC-Syntax, während in vielen anderen Programmiersprachen die Klammern grundsätzlich gesetzt werden müssen und eine Reihe an Programmierern daher die Klammern auch in FreeBASIC bevorzugt. Die Klammern sind aber nur beim Prozeduraufruf optional; im Prozedurkopf müssen sie gesetzt werden.

Der Vorteil an der Prozedur ist, neben der Einsparung von zwei Zeilen bei jedem Aufruf, dass eine Änderung nur noch an einer einzigen Stelle vorgenommen wird anstatt an vielen verschiedenen Stellen. Nehmen wir etwa an, wir entschließen uns irgendwann, alle Überschriften gelb zu schreiben. Dazu müssen wir lediglich die Prozedur anpassten; im Hauptprogramm kann alles so bleiben, wie es ist.

Diese Anpassung an jeder Stelle vorzunehmen, an der eine solche Überschrift angezeigt werden soll, wäre deutlich mühsamer — abgesehen davon, dass eine erhöhte Gefahr besteht, eine Stelle zu vergessen.

Grundsätzlich kann jeder Datentyp an eine Prozedur übergeben werden, auch UDTs und Pointer. Bei Pointern wird an den Datentypen ein PTR angehängt, wie es auch schon von der Variablendeklaration bekannt ist. Sogar ganze Prozeduren und Funktionen können als Parameter übergeben werden.

Innerhalb eines Unterprogrammes können wie gewohnt mit DIM neue Variablen deklariert werden. Es handelt sich bei ihnen um sogenannte lokale Variablen, die nur in der Umgebung gültig sind, in der sie definiert wurden (also innerhalb des Unterprogrammes). Aber auch im Hauptprogramm definierte Variablen sind lokal — sie gelten nur innerhalb des Hauptprogrammes. Allerdings bietet FreeBASIC auch die Möglichkeit, globale Variablen zu deklarieren, auf die sowohl im Hauptprogramm als auch in allen Unterprogrammen uneingeschränkt zugegriffen werden kann. Diese erhalten bei der Deklaration das zusätzliche Schlüsselwort SHARED.

Die erste Zeile deklariert wieder mehrere Variablen desselben Datentyps, während die Variablen in der zweiten Zeile unterschiedliche Datentypen besitzen dürfen. SHARED kann jedoch nur im Hauptprogramm angegeben werden, nicht in Unterprogrammen. Das bedeutet kurz gesagt: Wenn Sie in einem Unterprogramm globale Variablen verwenden wollen, müssen diese im Hauptprogramm mit SHARED deklariert werden.

Gerade wenn Sie eine Variable in nahezu allen Ihren Unterprogrammen benötigen, ist SHARED ein praktisches Mittel, eine ständige Übergabe als Parameter zu umgehen. Bei Unachtsamkeit kann es jedoch schnell zu großen Problemen kommen. Quelltext 12.3 demonstriert ein solches Problem: In diesem Beispiel wird davon ausgegangen, dass die Laufvariable i in so vielen Unterprogrammen benötigt wird, dass sie als globale Variable deklariert werden kann. Warum das keine gute Idee ist, sieht man in der Ausgabe.

Was ist passiert? Im Hauptprogramm startet die Schleife mit i=1. Während des ersten Schleifendurchlaufs wird das Unterprogramm aufgerufen und auch dort eine Schleife durchlaufen — in diesem Fall von 1 bis 1. Wir erinnern uns, dass nach dem Durchlauf die Laufvariable noch einmal erhöht wird; sie hat nun also den Wert 2. Mit diesen Voraussetzungen kehrt das Programm aus der Prozedur zurück in die Schleife des Hauptprogrammes. i hat sich also während des Aufrufs der Prozedur verändert, und mit diesem veränderten Wert arbeitet die Schleife nun weiter.

Quelltext 12.3 arbeitet also nicht alle Werte ab, die es eigentlich hätte abarbeiten sollen. Es hätte bei „geeigneter“ Programmierung der Prozedur sogar passieren können, dass sich das Programm in einer Endlosschleife verfängt und immer dieselben Werte ausgibt. Bei Verzicht auf die globale Variable i wäre das Problem gar nicht aufgetaucht. Natürlich muss dann i in der Prozedur neu deklariert werden.

Im Übrigen sind solche Fallstricke der Grund, warum die Laufvariablen in diesem Buch meist im Schleifenkopf neu deklariert werden (FOR i AS INTEGER). Auch dadurch lässt sich sicherstellen, dass sie nicht versehentlich in Konflikt mit einer gleichnamigen Variablen gerät.

Selbst wenn Sie eine Variable global deklarieren, können Sie sie in einem Unterprogramm oder einer anderen Blockstruktur neu deklarieren. In diesem Fall „vergisst“ das Programm die globale Variable solange, bis die Blockstruktur verlassen wird.

Noch eine letzte Anmerkung: Im Hauptprogramm definierte Konstanten gelten global, sind also auch im Unterprogramm verfügbar. Da Konstanten nicht mehr verändert werden können, kann es hier auch nicht zum Konflikt zwischen zwei Programmteilen kommen.

Statische Variablen sind ein weiteres Konzept, das bei Unterprogrammen zum Tragen kommen kann. Man versteht darunter Variablen, die wie lokale Variablen nur innerhalb des Unterprogrammes gültig sind, deren Wert aber nach Beendigung des Unterprogrammes nicht verloren geht, sondern gespeichert wird. Wenn dasselbe Unterprogramm erneut aufgerufen wird, erhält die Variable den zuletzt gespeicherten Wert wieder zurück. In einem einfachen Beispiel soll eine statische Variable eingesetzt werden, um lediglich zu zählen, wie oft die Prozedur bereits aufgerufen wurde.

Um eine statische Variable zu deklarieren, wird das Schlüsselwort STATIC statt DIM verwendet. Hier besteht die einzige Möglichkeit, der Variablen einen Initialwert zuzuweisen (tut man es nicht, wird die Variable standardmäßig mit dem Wert 0 belegt). Diese Zuweisung wird nur beim allerersten Aufruf der STATIC-Zeile durchgeführt und später ignoriert — aus diesem Grund wird in Quelltext 12.5 i nicht ständig wieder auf 0 gesetzt. Sie können die Auswirkung des Initialwerts gern testen, indem Sie den Wert verändern. Spätere Zuweisungen erfolgen dagegen bei jedem Durchlauf, weshalb folgende Variante nicht wie gewünscht funktioniert:

Da i bei jedem Durchlauf gleich nach der Deklaration auf 0 gesetzt wird, ist der eigentliche Zweck, den Wert zwischen den Prozedur-Aufrufen zu speichern, hinfällig.

Wenn alle im Unterprogramm deklarierten Variablen statisch sein sollen, kann man der Einfachheit halber das Unterprogramm selbst als statisch deklarieren. Quelltext 12.5 lässt sich dann auch folgendermaßen schreiben:

STATIC steht in dieser Version ganz am Ende der Kopfzeile des Unterprogrammes — also ggf. hinter der Parameterliste. Die Variablendeklaration kann nun über DIM erfolgen (allerdings ist auch STATIC möglich), und wieder wird der Initialwert nur beim ersten Durchlauf berücksichtigt.

Jedes Unterprogramm vor seinem ersten Aufruf zu definieren, stößt sehr schnell an eine logische Grenze. Wenn das Unterprogramm A das Unterprogramm B aufruft, muss Unterprogramm B zuerst definiert werden, um beim Aufruf in Unterprogramm A bereits bekannt zu sein. Was passiert nun aber, wenn sich beide Unterprogramme gegenseitig aufrufen wollen?

An dieser Stelle kommt die DECLARE-Zeile ins Spiel. Sie ist vom Aufbau identisch mit der Kopfzeile des Unterprogrammes, nur mit vorangestelltem Schlüsselwort DECLARE. Allerdings wird der Inhalt des Unterprogrammes an dieser Stelle noch nicht festgelegt. Die DECLARE-Zeile dient nur dazu, dem Compiler mitzuteilen: Irgendwann später wird die Definition eines Unterprogrammes mit diesem Namen und dieser Parameterliste folgen. Ein Aufruf kann dann auch schon erfolgen, bevor das Unterprogramm festgelegt wird — der Compiler kennt ja bereits seinen Namen.

Quelltext 12.7 bewirkt dasselbe wie Quelltext 12.2. In der ersten Zeile wird die Prozedur deklariert (aber noch nicht definiert, d. h. noch nicht inhaltlich festgelegt). Die Definition der Prozedur kann nun (fast) an beliebiger Stelle des Programmes stattfinden: zu Beginn (nach der DECLARE-Zeile) oder ganz am Ende wie in Quelltext 12.7 — sogar irgendwann mitten im Hauptprogramm, was aber im Sinne der Übersichtlichkeit keinesfalls empfehlenswert wäre. Eine sehr häufige Vorgehensweise ist die Deklaration möglichst früh im Programm und die Definition der Unterprogramme ganz am Ende.

Nun lassen sich auch Prozeduren realisieren, die sich wechselseitig aufrufen.² Quelltext 12.8 ist kein übermäßig sinnvolles Programm, sollte aber das Prinzip veranschaulichen.

Uns sind bisher bereits FreeBASIC-eigene Anweisungen begegnet, bei denen nicht alle Parameter angegeben werden mussten; z. B. bei LOCATE und COLOR. Solche optionalen Parameter sind auch bei eigenen Unterprogrammen möglich. Dazu muss dem Compiler mitgeteilt werden, welcher Wert für den Parameter verwendet werden soll, wenn dieser beim Aufruf nicht mit angegeben wurde. Beispielsweise könnte man in Quelltext 12.2 einen zusätzlichen Parameter für die Überschriftsfarbe einführen. Wird sie nicht angegeben, verwendet die Prozedur den Standardwert 14 (gelb).

Die Wertzuweisung für den bzw. die optionalen Parameter muss sowohl in der DECLARE-Zeile als auch in der Kopfzeile des Unterprogrammes stehen, und natürlich sollte in beiden Zeilen derselbe Wert angegeben werden.

Optionale Parameter bieten sich vor allem am Ende der Parameterliste an, weil sie dort am einfachsten weggelassen werden können. Um einen optionalen Parameter auszulassen, der mitten in der Liste steht, müssen (genauso wie z. B. beim Auslassen des ersten Parameters von COLOR) die korrekte Anzahl an Kommata gesetzt werden.

Häufig benötigt man zwei oder mehrere völlig verschiedene Parameterlisten, will jedoch bei einem einheitlichen Namen für das Unterprogramm bleiben. Wir wollen eine weitere Überschrift-Prozedur bauen, bei der die Einrückung nicht durch einen Zahlenwert, sondern durch einen Einrückungs-String festgelegt werden soll, der dunkelgrau ausgegeben wird (das Beispiel ist zugegebenermaßen etwas konstruiert, ist aber zur Veranschaulichung gut geeignet). Die Prozedur soll weiterhin ueberschrift heißen, da es sich ja prinzipiell um dieselbe Art von Anweisung handelt.

Wenn Sie nun beide Versionen der Prozedur untereinander schreiben und zu compilieren versuchen, erhalten Sie die Fehlermeldung:

Auch ein Hinzufügen der DECLARE-Zeilen behebt das Problem noch nicht. Sie müssen dem Compiler mitteilen, dass er mehrere Unterprogramme desselben Namens zu erwarten hat. Dazu fügen Sie in der ersten DECLARE-Zeile hinter dem Prozedurnamen das Schlüsselwort OVERLOAD (zu deutsch: Überladung) hinzu. Egal, wie viele Unterprogramme mit gleichem Namen Sie letztlich bereitstellen wollen: Das Schlüsselwort OVERLOAD muss und darf nur in der DECLARE-Zeile des ersten dieser Unterprogramme auftauchen.

Da bei uns beide Überschrifts-Prozeduren größtenteils dasselbe machen, lohnt es sich übrigens, die Arbeit der zweiten Prozedur in die erste auszulagern.

Hinweis: Die andere Parameterbezeichnung in der ersten DECLARE-Zeile wurde nur deshalb so gewählt, dass der Quelltext nicht den Seitenrahmen sprengt.

Der erste ueberschrift-Aufruf in Zeile 4 springt in das erste der beiden Unterprogramme, der zweite Aufruf in Zeile 5 dagegen in das zweite. Dies ist klar festgelegt, da sich der Datentyp des zweiten Parameters unterscheidet und daher immer nur eine der beiden Prozeduren infrage kommt. Bei der Verwendung von OVERLOAD ist immer darauf zu achten, dass der Compiler zweifelsfrei entscheiden kann, wann er welches der Unterprogramme aufzurufen hat. Das geschieht durch eine unterschiedliche Parameterzahl und/oder durch verschiedene Datentypen. Der Name des Unterprogramms zusammen mit der Parameterliste wird auch als Signatur des Unterprogramms bezeichnet — diese Signatur muss innerhalb eines Programmes eindeutig sein.

Die Übergabe einer großen Datenmenge — insbesondere auch, wenn die Anzahl der Elemente nicht von vornherein feststeht — kann recht bequem über ein Array erfolgen. Dazu muss in der Parameterliste an den Array-Namen lediglich ein Klammer-Paar angehängt werden — allerdings ohne Angabe der Array-Grenzen. Es ist dabei egal, wie viele Dinensionen das Array besitzt; die Übergabe erfolgt immer nur durch den Array-Namen mit dem angehängten Klammer-Paar.

Den Mittelwert aller Werte eines Arrays könnte man folgendermaßen berechnen:

Die Funktion hat den Vorteil, dass Start- und Endwert nicht festgelegt sind. Sie reagiert sehr flexibel auf das übergebene Array. Zumindest funktioniert das gut, solange sichergestellt ist, dass ein eindimensionales Array übergeben wird. Die Funktion erkennt die Anzahl der Dimensionen nicht. Bei Übergabe eines mehrdimensionalen Array wird kein Compilerfehler erzeugt, sondern die Funktion behandelt die im Array-Speicher liegenden Werte so, als ob es ein eindimensionales Array wäre. Das zurückgegebene Resultat ist dann mit großer Wahrscheinlichkeit sinnlos.

Natürlich kann die Funktion vor dem Start der Berechnung prüfen, ob die Anzahl der Dimensionen UBOUND(w, 0)=1 beträgt. Man kann aber auch den Compiler anweisen, nur eine bestimmte Anzahl an Dimensionen zuzulassen. Bei einer falschen Dimensionenzahl würde das Programm dann gar nicht compilieren. Wenn man diese Möglichkeit nutzen will, muss für jede Dimension ein ANY angegeben werden.

Analog dazu muss dann auch die Kopfzeile des Unterprogrammes mit der korrekten Anzahl an ANY versehen werden. Nun kann an die Funktion f1 nur noch ein eindimensionales Array übergeben werden und an die Funktion f2 nur noch ein zweidimensionales Array; eine falsche Dimensionenzahl führt zu einem Compilierfehler.

Als komplettes Programm könnte das dann so aussehen:

Es ist also nicht möglich, die Länge der Array-Parameter festzulegen — nur die Anzahl der Dimensionen kann vorgegeben werden. Wenn es notwendig ist, dass das Array eine genau definierte untere bzw. obere Grenze besitzt, überprüfen Sie die Grenzen mit LBOUND() bzw. UBOUND() und brechen Sie das Unterprogramm ab, wenn die Grenzen nicht passen.

Während die Übergabe eines oder mehrerer Arrays kein Problem darstellt, ist die Rückgabe eines Arrays als Funktionswert nicht möglich. Beim Rückgabewert darf es sich aber selbstverständlich um ein UDT handeln (vgl. Kapitel 7), welches auch ein Array beinhalten kann. Eine weitere Lösung werden wir uns im nächsten Abschnitt ansehen.

Über eine wichtige Frage haben wir uns bisher noch keine Gedanken gemacht: Was passiert eigentlich mit einem Parameter, wenn er innerhalb des Unterprogrammes verändert wird? Ändert sich dann auch sein Wert außerhalb der Funktion? Hierbei spielt es eine entscheidende Rolle, ob der Parameter nur als Wert übergeben wird oder als Referenz auf den Variablenwert. Im ersten Fall wird gewissermaßen eine Kopie der Variablen erstellt und diese übergeben. Was auch immer das Unterprogramm mit dieser Kopie anstellt, das Original bleibt davon unberührt. Wird aber die Variable selbst übergeben (oder genauer gesagt eine Referenz auf seine Speicherstelle), dann bleiben Änderungen innerhalb des Unterprogrammes auch nach dessen Beendigung erhalten. Es wurde ja direkt das Original verändert.

FreeBASIC unterstützt beide Konzepte. Parameter können mit den Schlüsselwörtern BYREF oder BYVAL versehen werden, um zu kennzeichnen, ob die Übergabe by reference (also als Original) oder by value (als Wert, also als Kopie) übergeben werden sollen.

Jeder Parameter wird innerhalb der Funktion verdoppelt. Wie Sie sehen, „vergisst“ das Programm die Änderung von b, wenn die Prozedur verlassen wird, während die Verdopplung von a beibehalten wird. Wird weder BYREF noch BYVAL angegeben, dann wird die Art der Parameterübergabe automatisch ermittelt:

Wenn Sie eine größere Kompatibilität zu anderen Dialektformen oder anderen Sprachen erreichen wollen, empfiehlt es sich, unabhängig vom Standardverhalten alle Parameter, bei denen eine bestimmte Übergabeart erforderlich ist, entsprechend mit BYREF oder BYVAL auszuzeichnen (außer Arrays, bei denen diese Angabe ja nicht erlaubt ist). Betroffen sind dabei alle Parameter, deren Wert innerhalb des Unterprogrammes verändert wird. Parameter, die im Unterprogramm nicht verändert werden, brauchen nicht gesondert ausgezeichnet zu werden.

Beachten Sie auch, dass die Angaben zu BYREF und BYVAL sowohl in der DECLARE-Zeile als auch in der Kopfzeile des Unterprogrammes erfolgen sollten.

Auch wenn ein Array nicht BYVAL übergeben werden kann, könnten Sie ein berechtigtes Interesse daran haben, eine Veränderung durch das Unterprogramm zu verhindern. Wenn Sie hinter einem Parameternamen, zwischen dem AS und der Angabe für den Datentyp, ein CONST einfügen, kann auf diesen Parameter innerhalb des Unterprogrammes nur lesend zugegriffen werden. Sollten Sie dennoch versuchen, den Wert des Parameters zu ändern, quittiert der Compiler dies durch eine Fehlermeldung.³ AS CONST ist jedoch nicht auf Arrays beschränkt.

In der abgedruckten Form stellt Quelltext 12.15 einen korrekten Quellcode dar. Wenn Sie jedoch das Kommentarzeichen in der vorletzten Zeile entfernen, können Sie den Codeschnipsel nicht mehr compilieren.

Damit die Parameter vom aufrufenden Befehl zum aufgerufenen Unterprogramm gelangen, werden sie zunächst der Reihe nach in den Stack gelegt (das ist ein Stapelspeicher, aus dem immer das zuletzt hineingelegte Element als erstes wieder herausgenommen wird — vergleichbar mit einem Stapel Teller, auf den man immer nur oben einen Teller hinzufügen oder herunternehmen kann) und innerhalb des Unterprogrammes wieder ausgelesen. Da sich FreeBASIC selbständig um die Verwaltung des Stacks kümmert, brauchen wir uns meistens mit den Details nicht auseinanderzusetzen. Gelegentlich werden sie jedoch wichtig.

Zunächst einmal ist wichtig, welcher Parameter zuerst in den Stack gelegt wird (und damit als letztes wieder ausgelesen werden kann). Dazu gibt es drei verschiedene Aufrufkonventionen:

Wichtig werden die Unterschiede vor allem bei der Verwendung externer Bibliotheken, da hier natürlich sichergestellt werden muss, dass sich die Bibliothek und das eigene Programm über die Konvention einig sind. Es gibt FreeBASIC-intern aber ebenfalls einen Fall, in dem die Aufrufkonvention wichtig wird, nämlich bei der Verwendung variabler Parameterlisten, auf die wir gleich zu sprechen kommen.

Da nun zwischenzeitlich doch schon eine ganze Menge an Informationen zu den Unterprogrammen zusammengekommen ist (und das sind noch nicht alle), hier noch einmal zusammenfassend der Zwischenstand zum Aufbau der Syntax: