-
TECHNISCHES GEBIET
-
Ausführungsformen beziehen sich auf das Gebiet der Compiler. Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
-
HINTERGRUND
-
Von Menschen lesbarer Code oder Anweisungen werden häufig durch den Einsatz eines Programmes namens Compiler in ausführbare Software umgewandelt. Der Compiler liest den Code und übersetzt diesen in eine maschinenlesbare Form, der von einer Rechnereinheit interpretiert werden kann. Der Code selbst kann in verschiedene Komponenten aufgeteilt werden. In manchen Programmiersprachen kann der Code in die mindestens eine definitorische Komponente, als Quellcode-Dateien bezeichnet, und in die mindestens eine deklarative Komponente, als Header-Dateien bezeichnet, aufgeteilt werden. Quellcode-Dateien können auf Header-Dateien zur Verwendung von deren Deklarationen verweisen. Insbesondere können mehrere Quellcode-Dateien auf die gleiche Header-Datei für deren Deklarationen verweisen. Bei jedem Verweis auf eine Header-Datei, die ein Compiler vorfindet, verarbeitet der Compiler in der Regel die Header-Datei in ihrer Gesamtheit, obwohl dieser diese zuvor bereits verarbeitet haben könnte. Je nach Anzahl und Länge der Header-Dateien kann ein erheblicher Teil der Kompilierungszeit der erneuten Verarbeitung der Header-Dateien zugeordnet werden.
-
KURZDARSTELLUNG
-
Ein Aspekt der Offenbarung enthält ein Verfahren für das Vorparsen von Headern. Das Verfahren beinhaltet das Scannen der mindestens einen Header-Datei auf einer Rechnereinheit in einer tokenisierten Form; anschließend erfolgt ein Parsen der tokenisierten Form auf der Rechnereinheit in mindestens einen abstrakten Syntaxbaum. Das Verfahren beinhaltet anschließend die Erstellung des mindestens einen vorgeparsten Headers für die mindestens eine Header-Datei durch Serialisierung des mindestens einen abstrakten Syntaxbaumes in einer modularen Form auf ein Speichergerät.
-
Ein von der Rechnereinheit lesbares Speichermedium mit darauf gespeichertem Code kann Anweisungen enthalten, die bei der Ausführung durch eine Datenverarbeitungsvorrichtung die Datenverarbeitungsvorrichtung dazu veranlasst, das zuvor beschriebene Verfahren zum Vorparsen der Header auszuführen.
-
In einigen Beispielen umfasst das Verfahren des Weiteren das Auffinden des mindestens einen vorgeparsten Headers auf dem Speichergerät, basierend auf den Direktiven in mindestens einer Quellcode-Datei, das Deserialisieren des mindestens einen abstrakten Syntaxbaumes der vorgeparsten Header auf der Rechnereinheit, und das Kompilieren der mindestens einen Quellcode-Datei mit mindestens einen abstrakten Syntaxbaum auf der Rechnereinheit. Zusätzlich oder alternativ kann das Auffinden des mindestens vorgeparsten Headers den Empfang der mindestens einen Direktive in einer Quellcode-Datei enthalten, wobei die Direktive(n) eine oder mehrere Header-Dateien spezifizier(t/en), und das Auffinden, basierend auf der mindestens einen Direktive in der Quellcode-Datei und des mindestens einen entsprechenden serialisierten vorgeparsten Headers auf dem Speichergerät. Die Direktiven können Direktiven umfassen. In einigen Beispielen ist die eine oder sind die mehreren Header-Dateien unabhängig voneinander kompilierbar. Das Verfahren kann das Einfrieren einer Symbolbindung in der mindestens einen Header-Datei umfassen.
-
In einigen Beispielen enthält das Verfahren des Weiteren die Erkennung einer Änderung in der mindestens einen Header-Datei auf der Rechnereinheit, und das Generieren des mindestens einen neuen abstrakten Syntaxbaumes auf der Rechnereinheit für jede der mindestens einen geänderten Header-Datei. Das Verfahren kann die Erstellung des mindestens einen neuen vorgeparsten Headers für jede der mindestens einen geänderten Header-Datei durch das Serialisieren, in modularer Form, des mindestens einen neuen abstrakten Syntaxbaumes auf ein Speichergerät umfassen. Das Verfahren kann ebenfalls das Auffinden des neuen vorgeparsten Headers für die mindestens eine auf dem Speichergerät geänderte Header-Datei und das Deserialisieren des neuen abstrakten Syntaxbaumes von den neuen vorgeparsten Headern auf der Rechnereinheit für jede der mindestens einen geänderten Header-Datei umfassen. Darüber hinaus kann das Verfahren das Kompilieren einer Quellcode-Datei mittels des neuen abstrakten Syntaxbaumes für jede der mindestens einen geänderten Header-Datei auf der Rechnereinheit umfassen.
-
In einigen Beispielen kann das Serialisieren des mindestens einen abstrakten Syntaxbaumes auf ein Speichergerät in modularer Form für die mindestens eine Header-Datei die Erstellung einer serialisierten Datei für jeden des mindestens einen abstrakten Syntaxbaumes umfassen. Das Verfahren kann des Weiteren die Gruppierung mehrerer Header in einem Modul umfassen, wobei die Vielzahl der Header in einer einzigen serialisierten Datei enthalten ist.
-
Das Scannen der mindestens einen Header-Datei auf einer Rechnereinheit in einer tokenisierten Form kann des Weiteren das Scannen der tokenisierten Form für mindestens ein Symbol umfassen und die Erstellung von mindestens einer Präprozessor-Symboltabelle, basierend auf zumindest einem Symbol. Das Erstellen des mindestens einen vorgeparsten Headers für die mindestens eine Header-Datei kann das Serialisieren, in modularer Form, des mindestens einen abstrakten Syntaxbaumes auf ein Speichergerät umfassen, das Serialisieren, in modularer Form, der tokenisierten Form auf das Speichergerät und das Serialisieren, in modularer Form, der mindestens einen Präprozessor-Symboltabelle auf das Speichergerät. Zusätzlich oder alternativ kann das Verfahren das Auffinden des mindestens einen vorgeparsten Headers auf dem Speichergerät, basierend auf Direktiven in mindestens einer Quellcode-Datei, das Deserialisieren des mindestens einen abstrakten Syntaxbaumes von den vorgeparsten Headern auf der Rechnereinheit, das Deserialisieren der tokenisierten Form der vorgeparsten Header auf der Rechnereinheit, das Deserialisieren der mindestens einen Präprozessor-Symboltabelle der vorgeparsten Header auf der Rechnereinheit und das Kompilieren der mindestens einen Quellcode-Datei mittels des mindestens einen abstrakten Syntaxbaumes, der mindestens einen Präprozessor-Symboltabelle und der tokenisierten Form auf der Rechnereinheit umfassen.
-
In einigen Beispielen umfasst das Scannen der mindestens einen Header-Datei auf einer Rechnereinheit in einer tokenisierten Form des Weiteren das Erstellen von mindestens einer Bezeichnerliste aus mindestens einer Header-Datei und das Entfernen jedes Bezeichners in der mindestens einen Bezeichnerliste, basierend darauf, ob der jeweilige Bezeichner in tokenisierten Form vorhanden ist. Das Erstellen des mindestens einen vorgeparsten Headers für die mindestens eine Header-Datei umfasst des Weiteren das Serialisieren, in einer modularen Form, der mindestens einen Bezeichnerliste auf ein Speichergerät. Zusätzlich oder alternativ umfasst das Verfahren die Prüfung, ob mindestens eine Bezeichnerliste mit mindestens einer Präprozessor-Symboltabelle übereinstimmt.
-
In einigen Beispielen umfasst das Verfahren des Weiteren die Erkennung, ob mindestens zwei abstrakte Syntaxbäume gleich sind und das Zusammenführen von mindestens zwei abstrakten Syntaxbäumen in einen einzigen abstrakten Syntaxbaum, basierend darauf, ob die mindestens zwei abstrakten Syntaxbäume gleich sind.
-
Ein weiterer Aspekt der Offenbarung stellt ein System zur Kompilierung bereit, einschließlich einer Front-End-Komponente, einem Scanner, einem Parser und einem Serialisierungsmodul. Der Scanner ist zum Scannen der mindestens einen Header-Datei in einer tokenisierten Form auf einer Rechnereinheit konfiguriert. Der Parser ist zum Parsen der tokenisierten Form in mindestens einen abstrakten Syntaxbaum auf der Rechnereinheit konfiguriert. Das Serialisierungsmodul ist zum Erstellen vorgeparster Header für die mindestens eine Header-Datei durch Serialisierung in einer modularen Form auf ein Speichergerät des mindestens einen abstrakten Syntaxbaumes auf dem Speichergerät konfiguriert. Das System umfasst des Weiteren ein Back-End-Gerät zur Umwandlung der mindestens einen Quellcode-Datei in einen Objektcode mittels des mindestens einen abstrakten Syntaxbaumes. In einigen Beispielen findet das Serialisierungsmodul die vorgeparsten Header auf dem Speichergerät, basierend auf Direktiven in zumindest einer Quellcode-Datei, und deserialisiert den mindestens einen abstrakten Syntaxbaum vorgeparster Headern auf der Rechnereinheit. Die Back-End-Komponente kann konfiguriert werden, um mindestens eine Quellcode-Datei in einen Objektcode mittels des mindestens einen abstrakten Syntaxbaumes, der/die von den vorgeparsten Header geladen wurde/wurden, umzuwandeln.
-
In einigen Beispielen ist das Serialisierungsmodul konfiguriert, um mindestens eine vorhandene Direktive in einer Quellcode-Datei zu empfangen, wobei die Direktive(n) mindestens eine Header-Datei spezifizier(t/en), und, basierend auf der mindestens einen vorhandenen Direktive in der Quellcode-Datei, den mindestens einen entsprechende serialisierten vorgeparsten Header auf dem Speichergerät findet. Zusätzlich oder alternativ umfassen Direktiven Include-Direktiven.
-
Die Front-End-Komponente kann einen Verifizierer umfassen, der zur Ermittlung konfiguriert ist, ob die eine oder die mehreren Header-Dateien unabhängig kompilierbar ist/sind. In einigen Beispielen umfasst die Front-End-Komponente des Weiteren einen Verifizierer, der zum Einfrieren einer Symbolbindung in der mindestens einen Header-Datei konfiguriert ist. In einigen Beispielen umfasst die Front-End-Komponente eine Änderungserkennung, die zum Erkennen einer Änderung in der mindestens einen Header-Datei auf der Rechnereinheit und zum Generieren des mindestens einen neuen abstrakten Syntaxbaumes auf der Rechnereinheit für jede der mindestens einen geänderten Header-Datei konfiguriert ist. Die Front-End-Komponente kann mindestens einen neuen vorgeparsten Header für jede der mindestens einen geänderten Header-Datei durch Serialisierung, in modularer Form, des mindestens einen neuen abstrakten Syntaxbaumes auf einem Speichergerät erstellen.
-
In einigen Beispielen erstellt das Serialisierungsmodul einen vorgeparsten Header für jeweils mindestens einen abstrakten Syntaxbaum. Der Scanner kann zum Scannen der tokenisierten Form von mindestens einem Symbol und zum Erstellen der mindestens einen Präprozessor-Symboltabelle, basierend mindestens einem Symbol, konfiguriert werden. Das Serialisieren kann zum Erstellen vorgeparster Header auf einem Speichergerät für mindestens eine Header-Datei konfiguriert werden: Serialisieren, in einer modularen Form, für den mindestens einen abstrakten Syntaxbaum auf das Speichergerät, Serialisieren, in einer modularen Form, der tokenisierten Form auf das Speichergerät und Serialisieren, in einer modularen Form, der mindestens einen Präprozessor-Symboltabelle auf das Speichergerät. Zusätzlich oder alternativ kann das Serialisierungsmodul des Weiteren zum Auffinden der vorgeparsten Header auf dem Speichergerät, basierend auf Direktiven in mindestens einer Quellcode-Datei, und zum Deserialisieren des mindestens einen abstrakten Syntaxbaumes von den vorgeparsten Headern auf der Rechnereinheit konfiguriert werden. Das Serialisierungsmodul kann des Weiteren die tokenisierte Form vorgeparster Headern auf der Rechnereinheit und die eine oder mehreren Präprozessor-Symboltabellen aus vorgeparsten Headern auf der Rechnereinheit deserialisieren. Die Back-End-Komponente kann konfiguriert werden, um mindestens eine Quellcode-Datei in einen Objektcode mittels des mindestens einen abstrakten Syntaxbaumes, der mindestens einen Präprozessor-Symboltabelle und der tokenisierten Form vorgeparster Header zu konvertieren.
-
In einigen Beispielen umfasst das System einen Verifizierer, der konfiguriert ist, um mindestens eine Bezeichnerliste aus mindestens einer Header-Datei zu erstellen, und um jeden Bezeichner in der mindestens einen Bezeichnerliste, abhängig davon, ob der jeweilige Bezeichner in der tokenisierten Form vorhanden ist, zu entfernen. Der Serialisierer kann zum Serialisieren der mindestens einen Bezeichnerliste in modularer Form auf ein Speichergerät konfiguriert werden. Zusätzlich oder alternativ kann der Verifizierer zur Sicherstellung, dass die mindestens eine Bezeichnerliste mit der mindestens einen Präprozessor-Symboltabelle übereinstimmt, konfiguriert werden. Das Serialisierungsmodul kann zur Ermittlung konfiguriert werden, ob zwei oder mehr abstrakte Syntaxbäume gleich sind und, abhängig davon, ob die zwei oder mehr abstrakten Syntaxbäume gleich sind, zwei oder mehr abstrakte Syntaxbäume zu einem einzigen abstrakten Syntaxbaum zusammenführen.
-
Weitere Ausführungsformen, Merkmale und Vorteile der Offenbarung sowie Struktur und Funktionsweise der verschiedenen Ausführungsformen der Offenbarung werden nachfolgend mit Bezug auf die begleitenden Zeichnungen genau beschrieben.
-
BESCHREIBUNG DER ZEICHNUNGEN
-
Implementierungen der Erfindung sind mit Bezug auf die zugehörigen Zeichnungen beschrieben. In den Zeichnungen können gleiche Bezugsnummern identische oder funktionell ähnliche Elemente angeben. Die Zeichnung, in der ein Element zum ersten Mal erscheint, ist normalerweise durch die Ziffer ganz links in der entsprechenden Bezugsnummer angegeben.
-
1 ist ein Diagramm eines Kompilierungssystems entsprechend einer Ausführungsform.
-
2 ist ein Diagramm eines Kompilierungssystems mit vorgeparsten Headern entsprechend einer Ausführungsform.
-
3A ist ein Sequenzdiagramm einer typischen Kompilierung von zwei Quellcode-Dateien, die auf die gleiche Header-Datei verweisen.
-
3B ist ein Sequenzdiagramm einer exemplarischen Kompilierung mittels vorgeparster Headern mit zwei Quellcode-Dateien, die entsprechend einer Ausführungsform auf die gleiche Header-Datei verweisen.
-
4 ist ein Sequenzdiagramm einer exemplarischen Kompilierung mittels vorgeparster Header in einer Kette von geänderten Header-Dateien.
-
5 ist ein Ablaufdiagramm eines Verfahrens zur Erstellung vorgeparster Header entsprechend einer Ausführungsform.
-
6 ist ein Ablaufdiagramm eines Verfahrens zum Laden vorgeparster Header zur Verwendung bei einer Kompilierung.
-
7 zeigt ein exemplarisches Rechnersystem, in dem die vorstehend beschriebenen Ausführungsformen oder Teile hiervon implementiert werden können.
-
8 zeigt ein exemplarisches Rechnersystem, in dem die vorstehend beschriebenen Ausführungsformen oder Teile hiervon implementiert werden können.
-
DETAILLIERTE BESCHREIBUNG
-
Des Weiteren sollte sich verstehen, dass, obwohl die Erfindung hierin mit Bezug auf veranschaulichende Ausführungsformen für bestimmte Anwendungen beschrieben ist, die Erfindung nicht darauf beschränkt ist. Dem Fachmann mit Zugang zu den hierin bereitgestellten Lehren werden zusätzliche Modifizierungen, Anwendungen und Ausführungsformen innerhalb des Umfangs davon und zusätzliche Gebiete, in denen die Erfindung von großem Nutzen wäre, ersichtlich.
-
In der folgenden detaillierten Beschreibung der Ausführungsformen weisen Bezugnahmen in der Beschreibung auf „eine Ausführungsform”, „eine exemplarische Ausführungsform” usw. daraufhin, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft beinhalten kann, aber dass nicht unbedingt jede Ausführungsform das besondere Merkmal, die besondere Struktur oder die bestimmte Eigenschaft beinhalten muss. Außerdem beziehen sich solche Ausdrücke nicht unbedingt auf dieselbe Ausführungsform. Wenn ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft im Zusammenhang mit einer Ausführungsform beschrieben ist, so wird weiterhin unterstellt, dass Fachleute die Kenntnis besitzt, ein solches Merkmal, eine Struktur oder Eigenschaft im Zusammenhang mit anderen Ausführungsformen zu bewirken, unabhängig davon, ob sie ausführlich beschrieben sind oder nicht.
-
Ein Teil einer Software kann aus Tausenden von Quellcode-Dateien oder mehr bestehen. Oft können mehr als eine Quellcode-Datei auf die Deklarationen in einer bestimmten Header-Datei zugreifen. Beispielsweise kann eine Header-Datei eine Deklaration für eine Funktion bereitstellen, die auf allgemein in einem Software-Paket verwendete Operationen zugreift. Eine Header-Datei kann jedoch andere Deklarationen, wie Konstanten, Präprozessor-Anweisungen und eine Vielzahl von anderen Deklarationen bereitstellen. Eine Funktionsdeklaration spezifiziert oft von der Funktion zu akzeptierende und zu empfangene Eingaben sowie von dieser zurückzugebende Ausgaben. Eine Funktion oder ein Verfahren kann eine Gruppe von Anweisungen, die mindestens eine Eingabe akzeptiert, eine Reihe von Operationen mit diesen Eingaben ausführt und anschließend wieder mindestens eine Ausgabe, basierend auf den Ergebnissen der Operationen für diese Eingaben, ausgibt. Diesen Vorgang der Ausführung einer Funktion bezeichnet man als „Funktionsaufruf”. Um eine Funktion aufzurufen, kann jede Quellcode-Datei einen Verweis auf die Header-Datei, in der sich eine Funktionsdeklaration befindet, bereitstellen. Hierdurch kann der Compiler die korrekte Verwendung der Funktion überprüfen. Viele Quellcode-Dateien können jedoch die gleiche Funktion aufrufen. Dies führt dazu, dass ein Compiler die Header-Datei liest und verarbeitet, unabhängig davon, ob dieser die gleiche Header-Datei bereits gelesen und verarbeitet hatte. Dies kann Doppelausführungen verursachen.
-
Compiler können mehrere Teile oder Stufen verwenden, um die Quell- und Header-Dateien der Software zu verarbeiten. Diese Teile können verschiedene Operationen mit den Quell- und Header-Dateien ausführen. Diese können den in den Quell- und Header-Dateien enthaltenen Text in eine Vielzahl von Datenstrukturen, die die während der Kompilierung stattfindende Verarbeitung unterstützen, transformieren.
-
1 und 8 zeigen ein Diagramm eines Kompilierungssystems und einer exemplarischen Rechnereinheit. Der Compiler 100 verfügt über eine Front-End-Komponente 102 und eine Back-End-Komponente 112. Die Front-End-Komponente 102 kann für eine erste Verarbeitung der in Quellcode-Dateien 114 und Header-Dateien 116 enthaltenen Texte verantwortlich sein.
-
Die Front-End-Komponente 102 umfasst des Weiteren einen Scanner 104, einen Parser 106 und eine Herabsetzungskomponente 108. Quellcode-Dateien 114 und Header-Dateien 116 können als Textdateien auf einem Speichergerät 802 wie einer Festplatte gespeichert werden. Der Begriff Quellcode-Dateien, wie hier verwendet, bezieht sich auf die mindestens eine Quellcode-Datei. In ähnlicher Weise bezieht sich der Begriff Header-Dateien, wie hier verwendet, auf mindestens eine Header-Datei. Um zuerst den Text in Quellcode-Dateien 114 und Header-Dateien 116 zu verarbeiten, liest der Compiler 100 zuerst die Quellcode-Dateien 114 und Header-Dateien 116 von dem Speichergerät 802 und konvertieren den Text in eine vom Compiler 100 zu interpretierende Datenstruktur. Text kann von einem Compiler in einer tokenisierten Form 216a gelesen werden. Ein Token ist eine Datenstruktur, die ein Wort des Textes repräsentieren kann. Die Front-End-Komponente 102 umfasst ebenfalls den Scanner 104, der für die Umwandlung des in Quellcode-Dateien 114 und Header-Dateien 116 enthaltenen Textes in eine tokenisierte Form 216a verantwortlich ist. Beispielsweise kann der Scanner 104 jedes Wort des in den Quellcode-Dateien 114 und Header-Dateien 116 vorhandenen Textes in einzelne Token umwandeln. Zusammengefügt können die Token einen Satz einer Programmiercodesyntax bilden.
-
Der Scanner 104 kann des Weiteren zum Ersetzen von Definitionen in einer Präprozessor-Symboltabelle durch Token konfiguriert werden. Die Präprozessor-Symboltabelle kann eine Tabelle sein, die Präprozessor-Symbole und deren entsprechende Definitionen enthält. Die Präprozessor-Symbole können in einer Header-Datei oder durch den Compiler selbst definiert werden. Präprozessor-Symbole können ebenfalls Makros oder eine Vielzahl von anderen Arten von Symbolen sein, je nach dem bestimmten Compiler oder der Programmierung. Ein Makro kann ein einen Text definierendes Symbol sein, das jederzeit bei Vorhandensein eines Makro-Symbols in einer Header-Datei oder Quellcode-Datei ersetzt werden kann. Beispielsweise kann ein Makro-Symbol namens „Beispiel” definierten sein, das dem Text „exemplarischer Text” entspricht. Ein Compiler kann jederzeit, wenn dieser auf das Symbol „Beispiel” trifft, das Symbol mit dem Text „exemplarischer Text” ersetzen. Die Symbole und deren Definitionen können dann in eine Tabelle mit dem Namen der Präprozessor-Symboltabelle platziert werden. Dies ermöglicht dann der Präprozessor-Symboltabelle, eine Tabelle aller aktiven Präprozessor-Symbole und deren entsprechender Definitionen zu warten. Stößt der Scanner 104 auf ein Symbol, das in der Präprozessor-Symboltabelle definiert ist, kann dieser das Symbol durch die entsprechende Definition in der Tabelle ersetzen. Unter Verwendung des vorstehenden Beispiels kann der Scanner 104 jedes Mal, wenn der Scanner 104 das Token „Beispiel” antrifft, das Token „Beispiel” durch ein neues Token „exemplarischer Text” ersetzen.
-
Der Prozessscanner 104 benötigt jedoch zur Umwandlung der Quellcode-Dateien und Header-Dateien in Token und zur Erstellung der Präprozessor-Symboltabellen eine gewisse Zeit. Manchmal kann das Scannen 15% der gesamten Kompilierungszeit in Anspruch nehmen. So kann beispielsweise der Scanner 104 für jeden vorhandenen Verweis auf eine bestimmte Header-Datei in den Quellcode-Dateien 114, auf die Scanner 104 trifft, die Header-Datei scannen und Token erstellen, selbst wenn der Scanner 104 die bestimmte Header-Datei zuvor verarbeitet hatte, da auf diese in einer anderen Quellcode-Datei verwiesen wurde.
-
In einer Ausführungsform kann dieser Prozess durch die Speicherung der vom Scanner 104 erstellten Token für eine spätere Wiederverwendung effizienter gestaltet werden. Die Header-Dateien 116 können vom Scanner 104 verarbeitet und Token erstellt werden. Diese Token können dann zu einer Token-Datenbank hinzugefügt oder vortokenisierte Header können von Header-Dateien 116 hinzugefügt werden. Nach einem anschließenden Kompilieren kann der Scanner 104, wenn der Scanner 104 auf eine Header-Datei stößt, die sich in der vortokenisierten Header-Datenbank befindet, die Token aus der Datenbank laden, anstatt die Header-Datei zu scannen. Allerdings müssen die Token zur Fortsetzung des Kompiliervorgangs weiter verarbeitet werden. Beispielsweise müssen diese in abstrakte Syntaxbäume 216b geparst werden.
-
Die Front-End-Komponente 102 umfasst des Weiteren einen Parser 106. Der Parser 106 kann abstrakte Syntaxbäume 216b aus den vom Scanner 104 zur Verfügung gestellten Token erstellen. Nachdem der Text der Quellcode-Dateien 114 und Header-Dateien 116 tokenisiert wurde, muss der Text für eine nachfolgende Kompilierung weiter organisiert werden. Ein abstrakter Syntaxbaum ist eine Datenrepräsentation der Syntaxstruktur einer Quell- oder Header-Datei. Insbesondere kann ein Token eine Textzeichenfolge übertragen, aber der abstrakte Syntaxbaum kann die Bedeutung dieses Textes vermitteln. Auf den abstrakten Syntaxbaum kann ebenfalls eine Reihe von Operationen, wie Fehlerprüfung und Optimierung, ausgeführt werden.
-
Die Front-End-Komponente 102 umfasst des Weiteren eine Herabsetzungskomponente 106. Die Herabsetzungskomponente 106 kann des Weiteren konfiguriert werden, um den abstrakten Syntaxbaum in einen abstrakten Syntaxbaum einer niedrigeren Ebene zu konvertieren. Diese Umwandlung kann eine Vielzahl von Operationen umfassen, wie z. B. Optimierungen oder eine Vielzahl von Bindungs- und Fehlerprüfungen, die abhängig von der Art des Compilers und der spezifischen Programmiersprache sein können. Obwohl hierin Ausführungsformen mit Bezug auf einen abstrakten Syntaxbaum beschrieben sind, kann ein Fachmann auf diesem Gebiet erkennen, dass ein abstrakter Syntaxbaum niedrigerer Ebene ebenfalls verwendet werden kann.
-
Ebenso wie der Scanner 104 benötigt der Parser 106 einen gewissen Zeitraum zum Parsen der Token und zum Generieren des abstrakten Syntaxbaumes. Insbesondere im Fall von Header-Dateien 116 muss der Parser 106 abstrakte Syntaxbäume 216b für jede, in einer Quellcode-Datei referenzierte Header-Datei 116 erstellen, selbst wenn der Parser 106 diese Header-Datei zuvor verarbeitet hatte. Dieser doppelte Aufwand benötigt, je nach der Anzahl und Länge der Header-Dateien, auf die in den Quellcode-Dateien 114 verwiesen wird, eine längere Zeit.
-
Der Compiler 100 umfasst ebenfalls eine Back-End-Komponente 112, die für die Umwandlung abstrakter Syntaxbäume 216b in Objektdateien 118 verantwortlich ist. Objektdateien 118 können Objektcode, ein von einer Rechnereinheit 800 lesbares Format, enthalten (8). Objektdateien können zur Bildung eines ausführbaren Programms durch den Einsatz eines Linker-Programms zusammengefügt werden. Ein Linker ist ein Programm, der Objektdateien zur Erstellung eines einzelnen ausführbaren Programmes oder einer Bibliothek zusammenführen kann. Die Back-End-Komponente 112 kann Objektcode durch den Einsatz abstrakter Syntaxbäume 216b von Header-Dateien 116 und Quellcode-Dateien 114 generieren.
-
Gemäß einer Ausführungsform kann der Compiler 100 effizienter gestaltet werden. 2 ist ein Diagramm eines Kompilierungssystems mittels vorgeparster Header entsprechend einer Ausführungsform. Der Compiler 200 verfügt über eine Front-End-Komponente 202 und eine Back-End-Komponente 212. Die Front-End-Komponente 202 umfasst einen Scanner 204, einen Parser 206 und eine Herabsetzungskomponente 224. Der Scanner 204 kann konfiguriert werden, um Quellcode-Dateien 214 und Header-Dateien 216 zu scannen und um eine tokenisierte Form 216a zu erstellen. Der Parser 206 kann zum Parsen der tokenisierten Form 216a und zur Erstellung abstrakter Syntaxbäume 216b und Herabsetzungskomponente 224 sowie zur Umwandlung abstrakter Syntaxbäume 216b in abstrakte Syntaxbäume niedrigerer Ebene konfiguriert werden.
-
Entsprechend einer Ausführungsform umfasst die Front-End-Komponente 202 ebenfalls ein Serialisierungsmodul 208. Das Serialisierungsmodul 208 kann vorgeparste Header 222 zur Verwendung während des Kompilierens erstellen. Wie hier verwendet, bezieht sich der Begriff „vorgeparster Header” auf mindestens einen vorgeparsten Header. Vorgeparste Header 222 können modularisiert sein, sodass jede der Header-Dateien 216 über eine entsprechende vorgeparste Header-Datei verfügt. Vorgeparste Header 222 können dann bei einer nachfolgenden Kompilierung geladen werden, sodass der Scanner 204, der Parser 206 und die Herabsetzungsungskomponente 224 die entsprechenden Header-Dateien 216 nicht jeweils erneut verarbeiten müssen. Darüber hinaus muss bei einer Änderung einer bestimmten Header-Datei nur die entsprechende vorgeparste Header-Datei oder jede, einen geänderten Header aufweisende Header-Datei aktualisiert werden, anstatt das alle vorgeparsten Header neu verarbeitet werden müssen. In einigen Fällen kann eine Vielzahl von Header-Dateien zu einem einzigen vorgeparsten Header zusammengefasst werden. Beispielsweise können bestimmte Header-Dateien miteinander verbundene Deklarationen bereitstellen, sodass in einer bestimmten Quellcode-Datei zusammen auf eine Vielzahl von Header-Dateien verwiesen wird. In solch einem Fall kann die Vielzahl der Header-Dateien in einem einzigen vorgeparsten Header zusammengefasst werden. In einem weiteren Beispiel können bestimmte Gruppen von Header-Dateien häufiger als andere Gruppen geändert werden. In einem solchen Fall können die weniger häufig geänderten Gruppen zusammengefasst werden, während die öfters geänderten Header einzelne vorgeparste Header-Dateien besitzen können. Unabhängig hiervon kann der Compiler 200 beide vorgeparste Header, die eine Vielzahl von Header-Dateien repräsentieren in Kombination mit vorgeparsten Header, die einzelne Header-Dateien repräsentieren, verarbeiten.
-
Das Serialisierungsmodul 208 kann vorgeparste Header 222 durch das Erstellen eines Abbildes der abstrakten Syntaxbäume 216b der Header-Dateien 216 erstellen und diese auf ein Speichergerät 802 serialisieren. Beim Serialisieren können bekannte Formate wie XML-, zeichenkettenbasierte oder binäre Formate verwendet werden. Das Serialisierungsmodul 208 kann beispielsweise ein Format verwenden, das der compilereigenen Repräsentation des abstrakten Syntaxbaumes für ein effizienteres Laden vorgeparster Header 222 möglichst nahe kommt. Nachdem das Abbild abstrakter Syntaxbäume 216b in vorgeparste Header 222 serialisiert wurde, kann das Abbild durch das Serialisierungsmodul 208 neu gelesen werden. Das Serialisierungsmodul 208 kann dann die vorgeparsten Header 222 zur Verwendung durch die Front-End-Komponente 202 in abstrakte Syntaxbäume 216b deserialisieren.
-
Das Serialisierungsmodul 208 kann weiterhin ein serialisiertes Abbild der Präprozessor-Symboltabelle in vorgeparste Header 222 einfügen. Das Serialisierungsmodul 208 kann ebenfalls ein serialisiertes Abbild der durch den Scanner 204 erstellten Token in vorgeparste Header 222 einfügen. Ähnlich zu den zuvor erläuterten abstrakten Syntaxbäumen 216b kann beim Serialisieren ein Format verwendet werden, das der compilereigenen Repräsentation der Präprozessor-Tabelle, der Token oder beidem ähnelt. Sobald die Abbilder des abstrakten Syntaxbaumes, der Präprozessor-Symboltabelle und der Token in vorgeparste Header 222 serialisiert wurden, können die Abbilder durch das Serialisierungsmodul 208 neu gelesen werden. Das Serialisierungsmodul 208 kann dann die vorgeparsten Header 222 in Präprozessor-Symboltabellen, Token und abstrakte Syntaxbäume 216b zur Verwendung durch die Front-End-Komponente 202 deserialisieren.
-
Nach einer nachfolgenden Kompilierung kann die Front-End-Komponente 202 des Weiteren zum Auffinden einer entsprechenden vorgeparsten Header-Datei aufgrund eines Verweises auf eine Header-Datei in einer Quellcode-Datei konfiguriert werden. Somit kann die Quellcode-Datei weiterhin ihren normalen Aufbau zur Referenzierung von Header-Dateien verwenden, und die Front-End-Komponente 102 kann zum Auffinden der entsprechenden vorgeparsten Header konfiguriert werden. Dies ermöglicht die weitere Verwendung einer vorhandenen Programmcodebasis ohne Änderung des Codes, aber dennoch den Einsatz vorgeparster Header. Beispielsweise kann das Konstrukt zur Referenzierung von Header-Dateien in der Programmiersprache C++ eine Include-Direktive sein. Je nach Art der gewünschten Header-Datei kann das Konstrukt die folgende exemplarische Form annehmen:
#include „sample.h”
-
Im vorstehenden Beispiel ist „sample.h” eine Header-Datei, und diese kann eine entsprechende vorgeparste Header-Datei namens „sample.pph” besitzen. Trifft die Front-End-Komponente 202 auf einen Verweis auf eine Header-Datei, kann diese versuchen, die entsprechende vorgeparste Header-Datei aufzufinden. Somit kann in diesem Beispiel, wenn die Front-End-Komponente 202 auf die Include-Direktive „sample.h” trifft, diese versuchen, „sample.pph” aufzufinden. Ist die Front-End-Komponente 202 bei der Suche nach „sample.pph” erfolgreich, kann das Serialisierungsmodul 208 „sample.pph” in einen abstrakten Syntaxbaum deserialisieren. Dieses kann ebenfalls „sample.pph” in eine Präprozessor-Tabelle, in Token über in beides deserialisieren. Kann der entsprechende vorgeparste Header gefunden werden, dann kann die Front-End-Komponente 202 die Header-Datei, z. B. „sample.h”, lesen und die Verarbeitung anschließend mit dem tokenisierten Header unter Verwendung des Scanners 202 fortsetzen, um eine Präprozessor-Symboltabelle zu erstellen und um einen abstrakten Syntaxbaum mit dem Parser 206 zu generieren.
-
Die Front-End-Komponente 202 umfasst des Weiteren einen Verifizierer 220. Der Verifizierer 220 kann vor der Erstellung eines vorgeparsten Headers zum Prüfen des abstrakten Syntaxbaumes oder der Präprozessor-Symboltabelle auf eine bestimmte Eigenschaft konfiguriert werden. Beispielsweise können sich die Quellcode-Dateien 214 auf eine bestimmte Reihenfolge verlassen, in denen die Header-Dateien 216 vom Compiler 200 zur Nutzung bestimmter Deklarationen geprüft werden. Dies kann ebenfalls als Include-Reihenfolge von Header-Dateien bezeichnet werden.
-
Header-Dateien können andere Header-Dateien für Deklarationen referenzieren. Viele Header-Dateien verweisen auf andere Header-Dateien, wenn diese den Einsatz von Deklarationen in diesen erfordern und können somit als unabhängig voneinander kompilierbar betrachtet werden. Einige Compiler oder Programmiersprachen erlauben jedoch die Nutzung dieser Deklarationen ohne Verweis auf andere Header-Dateien. Stattdessen können sich diese sich auf andere, die Deklarationen enthaltende Header-Dateien verlassen, dass diese zuerst durch den Compiler verarbeitet werden. Dies kann sehr softwarespezifisch sein. Beispielsweise kann ein Entwickler eine Deklaration in einer bestimmten Datei „a.h” verwenden, die in der Datei „declarations.h.” definiert ist. Der Entwickler kann dies basierend auf der Include-Reihenfolge erfahren, dass die Datei „declarations.h” vom Compiler vor der Datei „a.h” ausgewertet wird. Somit muss in diesem speziellen Fall der Entwickler nicht auf die Datei „declarations.h” in der Datei „a.h.” verweisen. Allerdings kann in einem anderen Softwareprogramm, basierend auf einer unterschiedlichen Include-Reihenfolge, „declarations.h” vom Compiler nach „a.h” ausgewertet werden In diesem Fall muss „a.h” auf „declarations.h” verweisen, um dessen Deklarationen zu verwenden.
-
Gemäß einer Ausführungsform kann der Verifizierer 220 zum Prüfen konfiguriert werden, ob eine Header-Datei unabhängig kompilierbar ist, indem die Deklarationen geprüft werden, auf die in der Header-Datei verwiesen wird. Sind die Deklarationen in der Header-Datei oder in der Kette der Header-Dateien, auf die in dieser Header-Datei verwiesen wird, definiert, kann diese als unabhängig kompilierbar angesehen werden. Wird eine Header-Datei nicht als unabhängig kompilierbar angesehen, kann das Serialisierungsmodul 208 nicht zur Erstellung eines vorgeparsten Headers für diese Header-Datei konfiguriert werden.
-
Wie bereits vorstehend erläutert, kann eine bestimmte Art von Deklaration eine Funktionsdeklaration sein. Eine Funktionsdeklaration kann die Ein- und Ausgaben einer Funktion beschreiben. Gelegentlich können mehrere Deklarationen für die gleiche benannte Funktion vorhanden sein. In der Regel erfordern, wenn mehrere Funktionen mit dem gleichen Namen deklariert sind, diese unterschiedliche Ein- und Ausgaben. Dies wird als Funktionsüberladung bezeichnet. Der Akt der Zuordnung einer dieser Funktionsüberladungen zu einem bestimmten Funktionsaufrufausdruck wird als Bindung bezeichnet. Im Allgemeinen kann eine Funktion mit anderen vorhandenen Funktionen mit dem gleichen Namen in der gleichen Header-Datei oder in der Kette der Header-Dateien, die innerhalb der gleichen Header-Datei referenziert werden, gebunden werden. Einige Compiler und Programmiersprachen können jedoch die Bindung einer Funktion an eine andere Header-Datei erlauben, die sich weder in der gleichen Header-Datei noch in einer Kette von Header-Dateien, die innerhalb der gleichen Header-Datei referenziert werden, befindet. Dies kann je nach der Reihenfolge auftreten, in der Header-Dateien vom Compiler geprüft werden. Ähnlich den zuvor erläuternden Deklarationen, kann diese, basierend auf der Include-Reihenfolge und abhängig von der jeweiligen Software, kompiliert werden. In einer Ausführungsform kann der Parser 206 die Bindungen der Funktionen fixieren, sodass diese auf den Umfang der Header-Datei, in der diese definiert sind, oder auf die Kette der referenzierten Header-Dateien innerhalb dieser Header-Datei beschränkt sind. Symbole können in einer ähnlichen Weise ebenfalls an Funktionen gebunden werden. In einer Ausführungsform kann der Parser 206 die Bindungen der Symbole fixieren, sodass diese auf den Umfang der Header-Datei, in der diese definiert sind, oder auf die Kette der referenzierten Header-Dateien innerhalb dieser Header-Datei beschränkt sind.
-
Header-Dateien können ebenfalls Präprozessor-Symbole in diesen enthalten. Oft können jedoch Präprozessor-Symboldefinitionen Bedingungen aufweisen. Beispielsweise kann eine Bedingung prüfen, um zu ermitteln, ob ein Symbol „X” definiert ist oder ob dieses einem bestimmten Wert entspricht. Falls „X” definiert ist, kann der Compiler eine „Wahr”-Operation ausführen, bei der das Symbol als „WAHR” definiert wird. Ist „X” nicht definiert, kann der Compiler eine „Falsch-Operation ausführen, bei der das Symbol als „FALSCH” definiert wird.
-
Viele Compiler lösen alle Präprozessor-Symbole in einer Header-Datei, unabhängig von den diese umgebenden Bedingungen. Im vorherigen Beispiel kann die „Falsch”-Operation ein bestimmtes Symbol als „FALSCH” definieren, wenn das Symbol „X” nicht definiert ist. Ist aber „X” tatsächlich definiert, kann „FALSCH” nicht relevant sein, da die Bedingung nie auf die „Falsch”-Operation trifft. Einige Compiler können dennoch das „FALSCH”-Symbol verarbeiten. Gemäß einer Ausführungsform ist der Verifizierer 220 zur Prüfung konfiguriert, ob ein Symbol verwendet wird. Wird das Symbol nicht verwendet, kann der Verifizierer 220 das Symbol aus dem Satz der Präprozessor-Symboltabelle entfernen, sodass es nicht in der vorgeparsten Header-Datei enthalten ist und nicht bearbeitet werden muss.
-
Die Verarbeitung von Token oder Bezeichner in einer Header-Datei variiert je nach dem Kontext einer Kompilierung. Beispielsweise kann eine Header-Datei den Bezeichner „X” in ihrem Text enthalten. Bei einer Kompilierung kann „X” auch wirklich „X” bedeuten. Bei einer anderen Kompilierung kann jedoch „X” zuvor als Präprozessor-Symbol deklariert worden sein. In einem solchen Fall kann bei einer erneuten Verarbeitung der gleichen Header-Datei „X” ersetzten worden sein, um „Y” oder eine beliebige andere Deklaration zu bedeuten. Das Präprozessor-Symbol kann aufgrund eines Verweises einer Header-Datei auf eine andere Header-Datei deklariert werden, obwohl das Präprozessor-Symbol ebenfalls aufgrund der Include-Sequenz oder des Compilers selbst deklariert werden kann. Daher kann die gleiche Header-Datei nach einer mehrmaligen Verarbeitung eine andere Bedeutung in einem anderen Kontext aufweisen, da einige ihre Bezeichner ersetzt wurden.
-
Ein vorgeparster Header kann jedoch nur den Zustand der Präprozessor-Symboltabelle repräsentieren, und die Bezeichner der entsprechenden Header-Datei basieren auf dem Kontext, in dem diese erstellt wurde. Infolgedessen kann ein vorgeparster Header Konflikte mit anderen Headern oder vorgeparsten Headern in einem anderen Kontext auslösen, wenn deren Bezeichner oder Präprozessor-Symbole bereits als Präprozessor-Symbole in einem anderen Header oder in einem vorgeparsten Header deklariert wurden. In einer Ausführungsform kann der Verifizierer 220 des Weiteren konfiguriert werden, um diese Konflikte zu erkennen. Der Verifizierer 220 kann eine Bezeichnerliste, die nicht selbst Präprozessor-Symbole sind, für jede der Header-Dateien 216 erstellen. Die Bezeichnerlisten können dann in jedem der vorgeparsten Header 222 für den Einsatz während nachfolgender Kompilierungen gespeichert werden. Allerdings können nicht alle, sich in einer bestimmten Header-Datei befindenden Bezeichner den generierten Token in der tokenisierten Form 216a entsprechen. Dies kann aufgrund der Bedingungen für die Bezeichner erfolgen. Beispielsweise könnte ein Bezeichner nur verwendet werden, wenn ein bestimmtes Symbol definiert ist oder wenn ein Symbol einem bestimmten Wert entspricht. Der Verifizierer 220 kann des Weiteren konfiguriert werden, um die Bezeichnerliste durch das Entfernen aller speziellen Bezeichner, die nicht einem generierten Token in der tokenisierten Form 216a entsprechen, zu verringern.
-
Bei einem späteren Kompilieren, bei dem vorgeparste Header 222 verwendet werden, kann der Verifizierer 220 konfiguriert werden, um die Bezeichnerlisten aus jedem der vorgeparsten Header 222 zu laden und um sicherzustellen, dass jeder der Bezeichner nicht in einem Konflikt mit anderen Präprozessor-Symbolen steht. Darüber hinaus kann der Verifizierer 220 ebenfalls prüfen, ob die in den Headern 222 deklarierten Präprozessor-Symbole in keinem Konflikt mit anderen vorgeparsten Präprozessor-Symbolen stehen. Für alle, als konfliktbeladen ermittelten vorgeparsten Header kann der Verifizierer 220 den Scanner 204, den Parser 206 und die Herabsetzungskomponente 224 veranlassen, den vorgeparsten Header entsprechend seiner textbasierten Header-Datei während des Kompilierens erneut zu verarbeiten.
-
In einigen Fällen kann, beispielsweise basierend auf dem Ergebnis des Verifizierers 220 oder wahlweise, keine vorgeparste Header-Datei für eine bestimmte Header-Datei erstellt werden. Diese Header-Datei ohne einen entsprechenden vorgeparsten Header kann als eine ungültige Header-Datei bezeichnet werden. In solchen Fällen kann der Compiler 200 den Text der ungültigen Header-Datei zur Verwendung wähnend des Kompilierens heranziehen. Jedoch können zwei oder mehrere Header, die über entsprechende vorgeparste Header verfügen, intern auf eine ungültige Header-Datei verweisen. In solchen Fällen können, wenn ein ungültiger Header zweimal von einem Compiler in Verbindung mit einem vorgeparsten Header verarbeitet wird, unerwartete Ergebnisse auftreten. Insbesondere können mehrere gleiche Kopien des gleichen abstrakten Syntaxbaumes erstellt werden. Jedoch können ebenfalls andere Fälle auftreten, bei denen entsprechende Kopien des gleichen abstrakten Syntaxbaumes erstellt werden können. Z. B. kann ein ungültiger Header von mehreren Quellcode-Dateien ohne ordnungsgemäße Einschränkungen, die eine mehrmalige Verarbeitung der ungültigen Header verhindern, referenziert werden. In einer Ausführungsform kann das Serialisierungsmodul 208 zur Ermittlung, ob zwei oder mehr abstrakte Syntaxbäume 216b gleich sind, konfiguriert werden. Bei gleichen abstrakten Syntaxbäumen 216b kann das Serialisierungsmodul 208 des Weiteren so konfigurierten werden, dass alle dieser gleichen abstrakten Syntaxbäume 216b zu einem einzigen abstrakten Syntaxbaum zusammengeführt werden. Der verbleibende abstrakte Syntaxbaum kann dann in Verbindung mit den vorgeparsten Headern für eine weitere Kompilierung vom Compiler 200 verwendet werden.
-
Die Front-End-Komponente 202 umfasst des Weiteren eine Änderungserkennung 210. In einer Ausführungsform kann jedoch die Änderungserkennung 210 ein außerhalb des Compilers 200 erfolgender Prozess sein. Die Änderungserkennung 210 kann Änderungen in Header-Dateien 216 erkennen. Bei erkannten Änderungen in bestimmten Header-Dateien kann die Änderungserkennung 210 die Front-End-Komponente 202 darüber informieren, vorgeparste Header bestimmter geänderter Header-Dateien nicht zu verwendet. Stattdessen kann die Front-End-Komponente 202 neue abstrakte Syntaxbäume 216c aus dem Text der Header-Dateien generieren, die mit dem Parser 206 und in Verbindung mit dem Scanner 204 geändert wurden. Somit können die Änderungserkennung 210, das Serialisierungsmodul 208 oder der Scanner 204 und der Parser 206 abstrakte Syntaxbäume 216b laden. Abstrakte Syntaxbäume 216b können dann zu Objektcode verarbeitet werden.
-
Der Compiler 200 umfasst ebenfalls eine für die Umwandlung abstrakter Syntaxbäume 216b in Objektdateien 218 verantwortliche Back-End-Komponente 212. Der Begriff Objektdateien, wie hier verwendet, bezieht sich auf die mindestens eine Objektdatei. Objektdateien 218 können Objektcode, ein von einer Rechnereinheit lesbares Format, enthalten. Objektdateien können zur Bildung eines ausführbaren Programms durch den Einsatz eines Linker-Programms zusammengefügt werden. Ein Linker ist ein Programm, das Objektdateien zur Erstellung eines einzelnen ausführbaren Programmes oder einer Bibliothek zusammenführt.
-
Die Back-End-Komponente 212 kann Objektcode durch den Einsatz abstrakter Syntaxbäume 216b von Header-Dateien 216 und Quellcode-Dateien 214 generieren. Abstrakte Syntaxbäume 216b der Header-Dateien 216 können durch eine Kombination vorgeparster Header 222 und der durch den Parser 206 in Verbindung mit dem Scanner 204 erstellten Header geladen worden sein. Unabhängig hiervon kann die Back-End-Komponente 212 nach dem Laden abstrakter Syntaxbäume 216b Objektdateien 218 generieren.
-
3A ist ein Sequenzdiagramm einer typischen Kompilierung 300 von zwei Quellcode-Dateien, die auf die gleiche Header-Datei verweisen. Das Kompilieren 300 umfasst eine Quellcode-Datei 302 und eine Quellcode-Datei 306, die beide auf eine Header-Datei 304 verweisen. Insbesondere zeigt die Kompilierung 300 die Quellcode-Datei 302, Quellcode-Datei 306 und Header-Datei 304, die von verschiedenen Phasen des Compilers verarbeitet werden können. Während der Kompilierung der Objektdatei 310 kann eine Scanstufe 314 die Quellcode-Datei 306 und die Header-Datei 304 in eine tokenisierte Form 216a scannen. Die Scanstufe 314 kann ebenfalls eine Präprozessor-Symboltabelle erstellen. Die Scanstufe 314 kann durch einen Scanner ausgeführt werden, beispielsweise durch Scanner 204 in 2. Eine Parsstufe 316 kann die Header-Datei 304 und die Quellcode-Datei 306 in abstrakte Syntaxbäume 216b parsen. Die Parsstufe 316 kann durch einen Parser ausgeführt werden, beispielsweise Parser 206 in 2. Eine Herabsetzungsstufe 318 kann dann die abstrakten Syntaxbäume 216b höherer Ebene in abstrakte Syntaxbäume 216b niedrigerer Ebene mittels einer Herabsetzungsungskomponente konvertieren, beispielsweise Herabsetzungskomponente 224 in 2. Eine Back-End-Stufe 320 kann dann von den abstrakten Syntaxbäumen 216b und den von der Scanstufe 314 und der Herabsetzungsstufe 318 erstellten Token die Objektdatei 310 erstellen. Die Back-End-Stufe kann durch eine Back-End-Komponente implementiert werden, beispielsweise Back-End-Komponente 212 in 2. Bei der Kompilierung der Objektdatei 312 können alle vorgenannten Stufen sowohl die Header-Datei 304 als auch die Quellcode-Datei 302 verarbeiten. Somit kann die Verarbeitung der Header-Datei 304 sowohl beim Kompilieren der Objektdatei 310 als auch beim Kompilieren der Objektdatei 312 erfolgen, was zum Einsatz einer höheren Anzahl von Verarbeitungsressourcen führen könnte.
-
Mit dem Einsatz vorgeparster Header kann die hierin beschriebene Kompilierung effizienter gestaltet werden. 3B ist ein Sequenzdiagramm einer exemplarischen Kompilierung 350 von vorgeparsten Headern mit zwei Quellcode-Dateien, die entsprechend einer Ausführungsform auf die gleiche Header-Datei verweisen. Ähnlich der Kompilierung 350 zeigt die Kompilierung 300 die Quellcode-Datei 302, Header-Datei 304, Quellcode-Datei 306, Objektdatei 310 und die Objektdatei 312. Darüber hinaus umfasst die Kompilierung 350 die Scanstufe 314, Parsstufe 316, Herabsetzungsstufe 318 und die Generierungsstufe 320. Ähnlich der Kompilierung 300 müssen Quellcode-Datei 302 und Quellcode-Datei 306 von jeder der Stufen verarbeitet werden. Die Kompilierung 350 umfasst jedoch während des Kompilierens ebenfalls einen vorgeparsten Header 308. Infolgedessen muss die Header-Datei 304 nur einmal von Scanstufe 314, Parsstufe 316 und Herabsetzungsstufe 318 verarbeitet werden. Die Back-End-Stufe 320 kann dann den Inhalt der vorgeparsten Header 308 zweimal verarbeiten, um den vorgeparsten Header 308 in die Objektdatei 310 und die Objektdatei 312 zu integrieren. Hierdurch kann die Kompilierung 350 eine verminderte gesamte Kompilierungszeit im Vergleich zur Kompilierung 300 aufweisen. Obwohl der vorgeparste Header 308 in Bezug auf die Kompilierung 350 verwendet wird, wird ein in der Technik erfahrener Fachmann erkennen, dass der vorgeparste Header 308 bei jeder Kompilierung der Header-Datei 304 verwendet werden kann.
-
4 ist ein Sequenzdiagramm einer exemplarischen Kompilierung 400 mit vorgeparsten Headern in einer Kette von geänderten Header-Dateien. Kompilierung 400 zeigt eine Quellcode-Datei 402, eine Header-Datei 404, eine geänderte Header-Datei 406 und eine Header-Datei 408. Die geänderte Header-Datei 406 kann über eine entsprechende vorgeparste Header-Datei 412 verfügen. In ähnlicher Weise kann die Header-Datei 404 über eine entsprechende vorgeparste Header-Datei 410 verfügen, und die Header-Datei 408 kann ebenfalls einen entsprechenden vorgeparsten Header 414 besitzen. Quellcode-Datei 402 kann eine Header-Datei 404 referenzieren, die des Weiteren auf eine geänderte Header-Datei 406 verweisen könnte. Die geänderte Header-Datei 406 kann ebenfalls auf eine Header-Datei 408 verweisen. Daher kann die Header-Datei 404 von der geänderten Header-Datei 406 und der Header-Datei 408 abhängig sein. Allerdings könnte die geänderte Header-Datei 414 seit dem Erstellen der vorgeparsten Header-Datei 412 geändert worden sein. In einem solchen Fall würde die vorgeparste Header-Datei 412 ungültig sein, da die vorgeparste Header-Datei 412 nicht die neuesten Änderungen an der geänderten Header-Datei 406 widerspiegelt.
-
Während der Kompilierung einer eine untergeordnete Header-Datei umfassende übergeordnete Header-Datei kann die übergeordnete Header-Datei Deklarationen verwenden, die in der untergeordneten Header-Datei enthalten sind. Deshalb können, falls Änderungen in dem untergeordneten Element enthalten sind, diese sich während des Kompilierens auf das übergeordnete Element auswirken, da sich die Deklarationen im untergeordneten Element geändert haben könnten. Infolgedessen kann, da die Header-Datei 404 auf den geänderten Header 406 verweist, der vorgeparste Header 410 ebenfalls ungültig sein. Somit müssen, da der Header-Datei 406 geändert wurde, der vorgeparste Header 410 und der vorgeparste Header 412 neu erstellt werden.
-
Kompilierung 400 zeigt ebenfalls mehrere Verarbeitungsstufen, nachdem eine Header-Datei geändert worden sein könnte. Eine Scanstufe 418 kann zum Scannen der Quellcode-Dateien und Header-Dateien in Token konfiguriert werden. Eine Parsstufe 420 kann konfiguriert werden, um die Token in abstrakte Syntaxbäume 216b zu parsen. Eine Herabsetzungsstufe 422 kann die abstrakten Syntaxbäume 216b in abstrakte Syntaxbäume 216b niedriger Ebene konvertieren, und eine Back-End-Stufe 424 kann eine Objektdatei 416 aus den abstrakten Syntaxbäumen 216b und Token erstellen. Da der vorgeparste Header 410 und der vorgeparste Header 412 ungültig geworden sind, müssen die geänderte Header-Datei 406 und die geänderte Header-Datei 404 von allen Stufen erneut verarbeitet werden. Da die Header-Datei 408 nicht von der geänderten Header-Datei 406 abhängig ist, muss diese nicht erneut verarbeitet werden. Daher ist die vorgeparste Header-Datei 414 nicht ungültig geworden und kann weiterhin von der Back-End-Stufe 422 zur Erstellung der Objektdatei 416 verwendet werden. Infolgedessen müssen nicht alle Header-Dateien für die Kompilierung 400 neu verarbeitet werden, falls eine Header-Datei geändert wurde.
-
5 ist ein Ablaufdiagramm eines Verfahrens 500 zur Erstellung vorgeparster Header entsprechend einer Ausführungsform. Bei Block 510 von Verfahren 500 werden ein oder mehrere Header-Dateien auf einer Rechnereinheit 800 in eine tokenisierte Form 216a gescannt. Die tokenisierte Form 216a kann eine Reihe von Token sein, die Wörter im Text einer oder mehrerer Header-Dateien darstellen. Dies kann durch einen Scanner erfolgen, beispielsweise Scanner 204 in 2. Diese Token können dann auf der Rechnereinheit 800, beispielsweise im Arbeitsspeicher oder wie vorstehend erwähnt, in einer Datenbank gespeichert werden. Die Token können ebenfalls bei der Erstellung einer Präprozessor-Symboltabelle verwendet werden.
-
Bei Block 520 können die tokenisierten Formen 216a auf der Rechnereinheit 800 in abstrakte Syntaxbäume 216b geparst werden. Jeder der Header-Datei kann über einen entsprechenden abstrakten Syntaxbaum verfügen. Dies kann durch einen Parser erfolgen, wie beispielsweise Parser 206 in 2.
-
Bei Block 530 können vorgeparste Header von den bei Block 520 erstellten abstrakten Syntaxbäumen 216b generiert werden. Vorgeparste Header entstehen durch Serialisierung abstrakter Syntaxbäume 216b auf ein Speichergerät 802 in einer modularisierten Form. Vorgeparste Header entstehen ebenfalls durch das Serialisieren einer beliebigen Kombination von abstrakten Syntaxbäumen 216b, Präprozessor-Symboltabellen, Token oder anderen solchen Informationen, die nach der Verarbeitung der Header-Datei als zum Speichern geeignet angesehen werden können. Das Speichergerät 802 kann jede Art von dauerhaftem oder nicht-persistentem Speicher sein, wie z. B. eine Festplatte oder ein Speicher. Das Serialisieren kann durch ein Serialisierungsmodul erfolgen, beispielsweise Serialisierungsmodul 208 in 2. Das Serialisieren kann in Form einer XML-Datei, einer anderen Zeichenfolge oder in Form einer Binärdatei erfolgen. Insbesondere kann das Serialisieren in Form einer Datendarstellung erfolgen, die einer compilerinternen Darstellung der abstrakten Syntaxbäume 216b ähnelt. Dies würde ein schnelleres Laden der abstrakten Syntaxbäume 216b, der Präprozessor-Symboltabellen oder der Token erlauben.
-
Jede der vorgeparsten Header-Dateien kann einer einzelnen Header-Datei entsprechen. Jedoch kann in einer Ausführungsform eine vorgeparste Header-Datei einer Vielzahl von zusammengruppierten Header-Dateien entsprechen. Es können, auch wenn in einer bestimmten Software ein vorgeparster Header eine Vielzahl von Header-Dateien repräsentiert kann, weitere Header-Dateien vorhanden sein, die jeweils eine andere vorgeparste Header-Datei repräsentieren.
-
Das Verfahren 500 kann weiterhin eine Verifikationsstufe umfassen. Die Verifikationsstufe kann prüfen, ob jede der dem vorgeparsten Header entsprechende Header-Datei unabhängig kompilierbar ist. Diese kann ebenfalls die Funktionsbindungen, Symbolbindungen oder beide fixieren, sodass Deklarationen an den Header, in dem diese definiert sind oder an die Kette der Header, die in ihren Headern referenziert werden, gebunden sind. Die Verifikationsstufe kann ebenfalls eine Bezeichnerliste für jede der Header-Dateien erstellen. Die Bezeichner erscheinen im Text einer Header-Datei, jedoch nicht in Präprozessor-Symbolen selbst. Die Bezeichnerliste kann des Weiteren zum Ausschluss von Bezeichnern verfeinert werden, die nicht zur Generierung von Token verwendeten werden. Die Bezeichnerliste kann dann in eine vorgeparste Header-Datei serialisiert werden. Dies kann durch ein Serialisierungsmodul ausgeführt werden, beispielsweise das Serialisierungsmodul 208 in 2. Nachdem ein vorgeparster Header erstellt wurde, kann dieser dann von einem Compiler zur Kompilierung verwendet werden.
-
6 ist ein Ablaufdiagramm eines Verfahrens 600 zum Laden vorgeparster Header zur Verwendung bei einer Kompilierung. Bei 610 Block des Verfahrens 600 wird mindestens ein vorgeparster Header, basierend auf den Direktiven in zumindest einer Quellcode-Dateien, gefunden. Das Auffinden des Platzes kann durch ein Serialisierungsmodul erfolgen, beispielsweise Serialisierungsmodul 208 in 2. Eine Quellcode-Datei kann durch den Einsatz einer Direktive, wie z. B. einer Include-Direktive, auf eine Header-Datei verweisen. Basierend auf dem Verweis auf eine Header-Datei, kann ein vorgeparster Header auf einer Rechnereinheit 800 aufgefunden werden. Hierdurch kann eine einen vorgeparsten Header verwendende Quellcode-Datei, ohne Änderung der Quellcode-Datei in irgendeiner Weise, verwendet werden. Insbesondere kann, wenn eine Quellcode-Datei beispielsweise auf eine Header-Datei „example.h” verweist, der vorgeparste Header, basierend auf dieser Referenz, „example.pph” gefunden und anschließend deserialisiert werden. Somit kann die Quellcode-Datei weiterhin auf „example.h” Bezug nehmen und alternativ ebenfalls auf die vorgeparsten Header verweisen.
-
Bei Block 620 kann mindestens einer der abstrakten Syntaxbäume 216b deserialisiert oder von einem auf der Rechnereinheit 800 gespeicherten vorgeparsten Header geladen werden. Mindestens ein Token, mindestens eine Präprozessor-Symboltabelle, mindestens eine Bezeichnerliste oder eine Kombination hiervon kann ebenfalls von einem auf der Rechnereinheit 800 gespeicherten vorgeparsten Header geladen werden. Wie für Verfahren 500 erläutert, kann der vorgeparste Header eine serialisierte Version der abstrakten Syntaxbäume 216b sein. Jedoch kann der vorgeparste Header ebenfalls serialisierte Versionen der Präprozessor-Symboltabelle, der Bezeichnerliste und Token umfassen. Diese können ein Format wie XML, Text oder Binärdaten besitzen. Somit kann der vorgeparste Header direkt in abstrakte Syntaxbäume 216b, eine Präprozessor-Symboltabelle, eine Bezeichnerliste, in Token oder eine Kombination hiervon deserialisiert werden. Abstrakte Syntaxbäume 216b, Bezeichnerliste, Präprozessor-Symboltabelle und Token können dann in eine Rechnereinheit 800 geladen werden. Beispielsweise können die abstrakten Syntaxbäume 216b in die interne Datenrepräsentation abstrakter Syntaxbäume 216b eines Compilers geladen werden. Ebenso können die Präprozessor-Symboltabelle und Token ebenfalls in jede ihrer jeweiligen Datenstrukturen geladen werden. Dies kann dann dem Compiler das Kompilieren der Quellcode-Dateien mit geladenen abstrakten Syntaxbäumen 216b, Präprozessor-Symboltabellen und Token aus vorgeparsten Header ermöglichen.
-
Das Verfahren 600 kann weiterhin eine Verifikationsstufe umfassen, die die Bezeichnerliste und Präprozessor-Symboltabelle der einzelnen vorgeparsten Header auf eine Konsistenz im Rahmen des aktuellen Kontextes prüft. Beispielsweise kann jeder der Bezeichner in einer Bezeichnerliste geprüft werden, um zu ermitteln, ob diese ebenfalls in einer beliebigen anderen Präprozessor-Symboltabelle definierte Symbole sind, damit die Bezeichner im Kontext ersetzt werden können. Die Präprozessor-Symboltabelle kann ebenfalls auf Symbole geprüft werden, die in anderen Präprozessor-Symboltabellen definiert sind, damit diese im aktuellen Kontext der Symbole ersetzt werden können. Die Verifikationsstufe kann durch einen Verifizierer ausgeführt werden, beispielsweise Verifizierer 220 in 2. Wird festgestellt, dass ein Konflikt für einen bestimmten vorgeparsten Header vorhanden ist, kann die entsprechende textliche Header-Datei während der Kompilierung anstelle des vorgeparsten Headers verwendet werden.
-
Im Verfahren 600 kann ebenfalls die Situation, in der zwei oder mehrere vorgeparste Header-Dateien auf eine gemeinsame Header-Datei verweisen, die nicht über einen entsprechenden vorgeparsten Header verfügt, erkannt werden. In einem solchen Fall kann die gemeinsame Header-Datei zweimal während des Kompilierens verarbeitet werden, sodass zwei oder mehr abstrakte Syntaxbäume 216b erstellt werden können. Wird das Eintreten solch eines Falls erkannt, können die abstrakten Syntaxbäume 216b zur Bildung eines einzigen abstrakten Syntaxbaumes für das Kompilieren zusammengeführt werden.
-
Bei Block 630 wird die mindestens eine Quellcode-Datei mittels des mindestens einen abstrakten Syntaxbaumes 216b auf der Rechnereinheit 800 kompiliert. Das Kompilieren kann ebenfalls die Verwendung von Präprozessor-Symboltabellen, Token oder beides umfassen. Bei der Kompilierung kann eine Kombination von vorgeparsten Headern und Header-Dateien, basierend auf den Anforderungen der Software, verwendet werden. Wird beispielsweise eine bestimmte Header-Datei häufig geändert und möchte ein Entwickler keine vorgeparste Header-Datei verwenden oder kann eine vorgeparste Header-Datei nicht gefunden werden, dann kann der Compiler eine Header-Datei anstatt einer vorgeparsten Header-Datei verwenden.
-
Das Kompilieren kann durch einen Compiler ausgeführt werden, beispielsweise Compiler 200 in 2.
-
7 zeigt eine exemplarische Rechnereinheit 700, auf der zuvor erläuterte Ausführungsformen oder Teile hiervon implementiert werden können. Beispielsweise kann der Compiler 200, einschließlich Teile hiervon, auf der Rechnereinheit 700 mit Hardware, Software, Firmware, materiellen, von der Rechnereinheit lesbaren Medien mit darauf gespeicherten Anweisungen oder eine Kombination hiervon und in einem oder mehreren Rechnersystemen oder anderen Verarbeitungssystemen implementiert werden. Hardware, Software oder eine beliebige Kombination hiervon können jedes der Module, Verfahren und Komponenten in den 1-6 verkörpern.
-
Fachleute wissen, dass Ausführungsformen des offenbarten Gegenstands mit verschiedenen Computersystemkonfigurationen umgesetzt werden können, z. B. Mehrkern-Multiprozessor-Systeme, Minicomputer, Mainframe-Computer, verknüpfte oder geclusterte Computer mit verteilten Funktionen sowie allgegenwärtige oder Mikrocomputer, die in praktisch jedem Gerät eingebettet sein können.
-
Zum Beispiel kann eine Rechnereinheit 800 mit mindestens einem Prozessorbaustein und einem Speicher zur Implementierung der oben beschriebenen Ausführungsformen verwendet werden. Ein Prozessorbaustein kann ein einzelner Prozessor, eine Vielzahl von Prozessoren oder eine Kombination davon sein. Prozessorbausteine können einen oder mehrere Prozessor-„Kerne” haben.
-
Verschiedene Ausführungsformen sind in Bezug auf dieses exemplarische Rechnersystem 700 beschrieben. Nach dem Lesen dieser Beschreibung wird für eine in der relevanten Technik fachkundige Person offensichtlich, wie die Ausführungsformen mittels anderer Rechnersysteme bzw. Rechnerarchitekturen implementiert werden können. Auch wenn Vorgänge als aufeinanderfolgender Prozess beschrieben werden können, können einige der Vorgänge in der Tat parallel, gleichzeitig und/oder in einer verteilten Umgebung und mit Programmcode ausgeführt werden, der lokal oder remote für den Zugriff durch eine Ein- oder Mehrprozessor-Maschine gespeichert ist. Außerdem kann in einigen Ausführungsformen die Reihenfolge der Vorgänge neu geordnet sein, ohne vom Geist des offenbarten Gegenstands abzuweichen.
-
Wie für Fachleute offensichtlich, kann der Prozessorbaustein 704 ein einzelner Prozessor in einem Mehrkern-/Multiprozessor-System sein, zum Beispiel einem System, das allein betrieben wird, oder in einem Cluster von Rechnereinheiten 800, die in einem Cluster oder einer Serverfarm betrieben werden. Der Prozessorbaustein 704 ist mit einer Kommunikationsinfrastruktur 706 verbunden, zum Beispiel einem Bus, einer Nachrichtenwarteschlange, einem Netzwerk oder einem Mehrkern-Nachrichtenübermittlungsschema.
-
Rechnersystem 700 beinhaltet außerdem einen Hauptspeicher 708, zum Beispiel ein Schreib-Lesespeicher mit wahlfreiem Zugriff (RAM) und kann außerdem einen sekundären Speicher 710 beinhalten. Der sekundäre Speicher 710 kann beispielsweise ein Festplattenlaufwerk 712 und ein Wechselspeicherlaufwerk 714 umfassen. Wechselspeicherlaufwerk 714 kann ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein Laufwerk für optische Datenträger, ein Flash-Speicher oder Ähnliches sein. Das Wechselspeicherlaufwerk 714 liest von einem und/oder schreibt auf ein Wechselspeichergerät 718 auf bekannte Weise. Wechselspeichergerät 718 kann eine Diskette, ein Magnetband, einen optischen Datenträger usw. umfassen, von der/dem Wechselspeicherlaufwerk 714 liest und auf die/das/den es schreibt. Wie für Fachleute offensichtlich, beinhaltet Wechselspeichergerät 718 ein von einer Rechnereinheit lesbares Speichermedium, auf dem Software für die Rechnereinheit und/oder Daten gespeichert sind.
-
Das Rechnersystem 700 (optional) umfasst eine Schnittstelle für die Anzeige 702 (die Ein- und Ausgabegeräte wie Tastaturen, Mäuse, usw. umfassen kann), die Grafiken, Text und andere Daten von der Kommunikationsinfrastruktur 706 zur Anzeige auf der Anzeigeneinheit 730 (oder von einem nicht gezeigten Rahmenpuffer) weiterleitet.
-
In alternativen Implementierungen kann der sekundäre Speicher 710 andere ähnliche Mittel umfassen, die das Laden von Programmen für Rechnereinheiten oder anderen Anweisungen in das Rechnersystem 700 ermöglichen. Solche Mittel können zum Beispiel ein Wechselspeichergerät 722 und eine Schnittstelle 720 umfassen. Beispiele solcher Mittel können ein Programmmodul und eine Modulschnittstelle (wie z. B. in Videospielgeräten zu finden), ein Wechselspeicher-Chip (z. B. ein EPROM oder PROM) und dazugehörige Anschlüsse und andere Wechselspeichergeräte 722 und Schnittstellen 720 beinhalten, die die Übertragung von Software und Daten vom Wechselspeichergerät 722 zum Rechnersystem 700 ermöglichen.
-
Rechnersystem 700 kann außerdem eine Kommunikationsschnittstelle beinhalten 724. Die Kommunikationsschnittelle 724 ermöglicht die Übertragung von Software und Daten zwischen dem Rechnersystem 700 und externen Geräten. Die Kommunikationsschnittelle 724 kann ein Modem, eine Netzwerkschnittstelle (zum Beispiel eine Ethernet-Karte), einen Kommunikationsanschluss, einen PCMCIA-Steckplatz mit Karte oder Ähnliches umfassen. Software und Daten, die über die Kommunikationsschnittstelle 724 übertragen werden, können in Form von Signalen sein, die elektronische, elektromagnetische, optische oder andere Signale sein können, die von Kommunikationsschnittstelle 724 empfangen werden können. Diese Signale können der Kommunikationsschnittstelle 724 über einen Kommunikationspfad 726 bereitgestellt werden. Kommunikationspfad 726 überträgt Signale und kann mithilfe von Draht oder Kabel, Glasfaser, eine Telefonleitung, eine Mobiltelefonverbindung, eine HF-Verbindung oder andere Kommunikationskanäle implementiert werden.
-
Einige Ausführungsformen können sich auf Rechnereinheitsprodukte beziehen, die sich auf von jeder Rechnereinheit lesbaren, auf einem Speichermedium gespeicherte Software bezieht. Solche Software führt, wenn sie in einem oder mehreren Datenverarbeitungsgeräten ausgeführt wird, dazu, dass das/die Datenverarbeitungsgerät(e), wie hierin beschrieben, funktionieren.
-
Verschiedene Ausführungsformen können in Hardware, Software, Firmware oder in einer Kombination von diesen implementiert werden. Einige Ausführungsformen können über eine Reihe von parallel, auf mehreren Rechnern ausgeführten Programmen implementiert werden.
-
Die Zusammenfassungs- und Kurzfassungsabschnitte können eine oder mehrere, aber nicht alle exemplarischen Ausführungsformen der vorliegenden Erfindung wie von den Erfindern betrachtet, erweitern und sollen daher die vorliegende Erfindung und die angehängten Ansprüche in keinster Weise einschränken.
-
Die vorliegenden Ausführungsformen wurden vorstehend mittels funktionaler Bausteine beschrieben, die die Implementierung der angegebenen Funktionen und deren Beziehungen veranschaulichen. Grenzen dieser funktionalen Bausteine wurden zum besseren Verständnis der Beschreibung hierin willkürlich definiert. Alternative Grenzen können definiert werden, solange deren spezifizierte Funktionen und Beziehungen angemessen durchgeführt werden.
-
Die vorstehende Beschreibung der spezifischen Ausführungsformen zeigt die allgemeine Eigenschaft der Erfindung so vollständig auf, dass andere durch Anwenden von Wissen auf dem Gebiet derartige spezifische Ausführungsformen leicht für verschiedene Anwendungen ohne übermäßiges Experimentieren modifizieren und/oder anpassen können, ohne von dem allgemeinen Konzept der vorliegenden Erfindung abzuweichen. Daher sind solche Anpassungen und Modifikationen auf Basis der hierin präsentierten Lehre und Anleitung als innerhalb der Bedeutungen und des Bereichs der Äquivalente der offenbarten Ausführungsformen zu betrachten. Es versteht sich dass die hierin verwendete Phraseologie oder Terminologie der Beschreibung dient und nicht der Einschränkung, sodass die Terminologie oder Phraseologie der vorliegenden Spezifikation vom Fachmann unter der Sichtweise von Lehre und Führung zu interpretieren ist.
-
Die Breite und der Umfang der vorliegenden Erfindung sollen durch keinerlei der vorstehend beschriebenen exemplarischen Ausführungsformen eingeschränkt sein.
