Linker (Computerprogramm) - Versionsgeschichte

Dexxor: /* Statisches Linken */ entwickeln ≠ übersetzen

2023-12-02T09:01:05Z

Statisches Linken: entwickeln ≠ übersetzen

← Nächstältere Version		Version vom 2. Dezember 2023, 11:01 Uhr
Zeile 9:		Zeile 9:
	Das ''statische Linken'' erfolgt typischerweise am Ende der [[Softwareentwicklung\|Entwicklung des Programms]]. Das Ergebnis ist ein fertig zusammengesetztes Programm, das bei vollständig statisch gelinkten Programmen aus einer einzigen [[Datei]] besteht.		Das ''statische Linken'' erfolgt typischerweise am Ende der [[Softwareentwicklung\|Entwicklung des Programms]]. Das Ergebnis ist ein fertig zusammengesetztes Programm, das bei vollständig statisch gelinkten Programmen aus einer einzigen [[Datei]] besteht.

	Beim statischen Linken werden die Programmmodule der Anwendung einmalig ~~''zum~~ ~~Entwicklungszeitpunkt''~~ aufgelöst, im Gegensatz zum dynamischen Linken, bei dem dies jedes Mal zur [[Laufzeit (Informatik)\|Laufzeit]] geschieht.		Beim statischen Linken werden die Programmmodule der Anwendung einmalig zur [[Übersetzungszeit]] aufgelöst, im Gegensatz zum dynamischen Linken, bei dem dies jedes Mal zur [[Laufzeit (Informatik)\|Laufzeit]] geschieht.

	Ein Vorteil ist beim statischen Linken die erhöhte [[Portable Software\|Portabilität]] einer Anwendung, da diese ''nicht'' auf die Bereitstellung von Programmmodulen z. B. durch das [[Betriebssystem]] angewiesen ist, da die Anwendung diese selbst mitführt; eine [[Installation (Computer)\|Installation]] des Programms ist somit nicht erforderlich.<ref>[http://www-vs.informatik.uni-ulm.de/teach/ss10/bs/docs/BS_D1_12_Hauptspeicher.pdf Kapitel über Hauptspeicher, Folie 6] (PDF) informatik.uni-ulm.de ''Betriebssysteme'' – Vorlesung im Hauptstudium</ref> Nachteile sind ein potentiell höherer [[Speicherbedarf]], da Programmmodule nicht von anderen Programmen mitverwendet werden können, und die Notwendigkeit, die Gesamtanwendung neu zu kompilieren und zu linken, falls für ein Teilmodul eine verbesserte [[Version (Software)\|Version]] herausgegeben wurde.<ref name="drepper">{{cite web\|url=http://people.redhat.com/drepper/no_static_linking.html\|archiveurl=https://web.archive.org/web/20041221091001/http://people.redhat.com/drepper/no_static_linking.html\|archivedate=2004-12-21\|title=Static Linking Considered Harmful\|author=[[Ulrich Drepper]]\|quote=''There are still too many people out there who think (or even insist) that static linking has benefits. This has never been the case and never will be the case. […]''\|publisher=redhat.com\|language=englisch\|accessdate=2012-01-13}}</ref>		Ein Vorteil ist beim statischen Linken die erhöhte [[Portable Software\|Portabilität]] einer Anwendung, da diese ''nicht'' auf die Bereitstellung von Programmmodulen z. B. durch das [[Betriebssystem]] angewiesen ist, da die Anwendung diese selbst mitführt; eine [[Installation (Computer)\|Installation]] des Programms ist somit nicht erforderlich.<ref>[http://www-vs.informatik.uni-ulm.de/teach/ss10/bs/docs/BS_D1_12_Hauptspeicher.pdf Kapitel über Hauptspeicher, Folie 6] (PDF) informatik.uni-ulm.de ''Betriebssysteme'' – Vorlesung im Hauptstudium</ref> Nachteile sind ein potentiell höherer [[Speicherbedarf]], da Programmmodule nicht von anderen Programmen mitverwendet werden können, und die Notwendigkeit, die Gesamtanwendung neu zu kompilieren und zu linken, falls für ein Teilmodul eine verbesserte [[Version (Software)\|Version]] herausgegeben wurde.<ref name="drepper">{{cite web\|url=http://people.redhat.com/drepper/no_static_linking.html\|archiveurl=https://web.archive.org/web/20041221091001/http://people.redhat.com/drepper/no_static_linking.html\|archivedate=2004-12-21\|title=Static Linking Considered Harmful\|author=[[Ulrich Drepper]]\|quote=''There are still too many people out there who think (or even insist) that static linking has benefits. This has never been the case and never will be the case. […]''\|publisher=redhat.com\|language=englisch\|accessdate=2012-01-13}}</ref>

Acky69: gesch.LZ, zus. Links, Redundanz raus, Ausdruck

2023-12-01T11:21:45Z

gesch.LZ, zus. Links, Redundanz raus, Ausdruck

← Nächstältere Version		Version vom 1. Dezember 2023, 13:21 Uhr
Zeile 1:		Zeile 1:
	[[Datei:Linker.svg\|mini\|200px\|[[Bibliothek (Programmierung)#Statische Bibliotheken\|Bibliotheken]] (lib) und/oder Objektdateien (obj) werden vom Linker zu Bibliotheken, [[Bibliothek (Programmierung)#Dynamische Bibliotheken\|Dynamischen Bibliotheken]] (dll) oder [[Ausführbare Datei\|ausführbaren Dateien]] (exe) zusammengefügt (gelinkt).]]		[[Datei:Linker.svg\|mini\|200px\|[[Bibliothek (Programmierung) #Statische Bibliotheken\|(Statische) Bibliotheken]] (lib) und/oder Objektdateien (obj) werden vom Linker zu Bibliotheken, [[Bibliothek (Programmierung) #Dynamische Bibliotheken\|Dynamischen Bibliotheken]] (dll) oder [[Ausführbare Datei\|ausführbaren Dateien]] (exe) zusammengefügt (gelinkt).]]
	Unter einem '''Linker''' oder '''Binder''' (auch: ~~„Bindelader“~~) versteht man ein [[Computerprogramm]], das einzelne [[Modul (Software)\|Programmmodule]] zu einem ausführbaren Programm zusammenstellt (verbindet). Auf [[IBM]]-[[Großrechner]]systemen wird der Linker ''linkage editor'' (englisch) genannt.<ref>{{Literatur \|Hrsg=IBM Corporation \|Titel=Operating System 360, Linkage Editor, Program Logic Manual \|Ort=New York \|Datum=1967}}</ref>		Unter einem '''Linker''' oder '''Binder''' (auch: '''Bindelader''') versteht man ein [[Computerprogramm]], das einzelne [[Modul (Software)\|Programmmodule]] zu einem ausführbaren Programm zusammenstellt (verbindet). Auf [[IBM]]-[[Großrechner]]systemen wird der Linker ''linkage editor'' (englisch) genannt.<ref>{{Literatur \|Hrsg=IBM Corporation \|Titel=Operating System 360, Linkage Editor, Program Logic Manual \|Ort=New York \|Datum=1967}}</ref>

	Die meisten Programme enthalten Bestandteile oder Module, die in anderen Programmen ~~Verwendung~~ ~~finden~~ können. Mehrere ~~kompilierte~~ Module mit ~~Funktionen~~ (~~so genannte~~ ''Objektdateien'') können zu Funktionsbibliotheken (''[[Programmbibliothek]]en'') zusammengefasst werden. Der Code wird durch den Linker zum Hauptprogramm hinzugefügt, falls die entsprechende Funktion benötigt wird.		Die meisten Programme enthalten Bestandteile oder Module, die in anderen Programmen verwendet werden können. Mehrere [[kompiliert]]e Module mit [[Funktion (Programmierung)\|Funktionen]] (''Objektdateien'') können zu Funktionsbibliotheken (''[[Programmbibliothek]]en'') zusammengefasst werden. Der [[Quelltext\|Code]] wird durch den Linker zum Hauptprogramm hinzugefügt, falls die entsprechende Funktion benötigt wird.

	Um ein Programmmodul in einem anderen Programm verwenden zu können, müssen die symbolischen Adressen der Funktionen und Variablen des Moduls in ~~Speicheradressen~~ umgewandelt werden. Diese Aufgabe übernimmt der Linker. Der Linkvorgang erfolgt nach der [[Kompilierung]] und ist meistens der letzte Arbeitsschritt zur Erstellung eines Programms~~. Man unterscheidet generell zwischen statischem und dynamischem Linken~~.		Um ein Programmmodul in einem anderen Programm verwenden zu können, müssen die symbolischen Adressen der Funktionen und [[Variable (Programmierung)\|Variablen]] des Moduls in [[Speicheradresse]]n umgewandelt werden. Diese Aufgabe übernimmt der Linker. Der Linkvorgang erfolgt nach der [[Kompilierung]] und ist meistens der letzte Arbeitsschritt zur Erstellung eines Programms.

	== Statisches Linken ==		== Statisches Linken ==
	Das ''statische Linken'' ~~ist der Vorgang, der~~ typischerweise am Ende der Entwicklung des Programms ~~erfolgt~~. Das Ergebnis ist ein fertig zusammengesetztes Programm. ~~Dieses besteht~~ bei vollständig statisch gelinkten Programmen aus einer einzigen [[Datei]].		Das ''statische Linken'' erfolgt typischerweise am Ende der [[Softwareentwicklung\|Entwicklung des Programms]]. Das Ergebnis ist ein fertig zusammengesetztes Programm, das bei vollständig statisch gelinkten Programmen aus einer einzigen [[Datei]] besteht.
⚫	Beim statischen Linken wird die Programmmoduleauflösung der Anwendung zum Entwicklungszeitpunkt einmalig durchgeführt, im Gegensatz zum ''dynamischen Linken'', bei dem dies jedes Mal zur Laufzeit geschieht. Ein Vorteil ist beim statischen Linken ~~eine~~ erhöhte [[Portable Software\|Portabilität]] einer Anwendung, da diese nicht auf die Bereitstellung von Programmmodulen z. B. durch das Betriebssystem angewiesen ist, da die Anwendung diese selbst mitführt. ~~Eine~~ Installation des Programms ist somit nicht erforderlich.<ref>[http://www-vs.informatik.uni-ulm.de/teach/ss10/bs/docs/BS_D1_12_Hauptspeicher.pdf Kapitel über Hauptspeicher, Folie 6] (PDF) informatik.uni-ulm.de ''Betriebssysteme'' – Vorlesung im Hauptstudium</ref> Nachteile sind ein potentiell höherer Speicherbedarf, da Programmmodule nicht von anderen Programmen mitverwendet werden können, ~~als auch~~ die Notwendigkeit, die Gesamtanwendung neu zu kompilieren und zu linken, falls für ein Teilmodul eine verbesserte Version herausgegeben wurde.<ref name="drepper">{{cite web\|url=http://people.redhat.com/drepper/no_static_linking.html\|archiveurl=https://web.archive.org/web/20041221091001/http://people.redhat.com/drepper/no_static_linking.html\|archivedate=2004-12-21\|title=Static Linking Considered Harmful\|author=[[Ulrich Drepper]]\|quote=''There are still too many people out there who think (or even insist) that static linking has benefits. This has never been the case and never will be the case. […]''\|publisher=redhat.com\|language=englisch\|accessdate=2012-01-13}}</ref>

			Beim statischen Linken werden die Programmmodule der Anwendung einmalig ''zum Entwicklungszeitpunkt'' aufgelöst, im Gegensatz zum dynamischen Linken, bei dem dies jedes Mal zur [[Laufzeit (Informatik)\|Laufzeit]] geschieht.
⚫	Wegen dieser Nachteile unterstützen einige C-Bibliotheken unter Unix-artigen Betriebssystemen das statische Linken oft nicht mehr vollständig.<ref name="drepper" /> So erzwingt beispielsweise die [[glibc]] ein dynamisches Linken bei Modulen, die die Benutzer[[authentifizierung]] betreffen. Programme, die diese Module verwenden, sind immer auf die Anwesenheit einer passenden „Laufzeitversion“ der glibc angewiesen.

		⚫	Ein Vorteil ist beim statischen Linken die erhöhte [[Portable Software\|Portabilität]] einer Anwendung, da diese ''nicht'' auf die Bereitstellung von Programmmodulen z. B. durch das [[Betriebssystem]] angewiesen ist, da die Anwendung diese selbst mitführt; eine [[Installation (Computer)\|Installation]] des Programms ist somit nicht erforderlich.<ref>[http://www-vs.informatik.uni-ulm.de/teach/ss10/bs/docs/BS_D1_12_Hauptspeicher.pdf Kapitel über Hauptspeicher, Folie 6] (PDF) informatik.uni-ulm.de ''Betriebssysteme'' – Vorlesung im Hauptstudium</ref> Nachteile sind ein potentiell höherer [[Speicherbedarf]], da Programmmodule nicht von anderen Programmen mitverwendet werden können, und die Notwendigkeit, die Gesamtanwendung neu zu kompilieren und zu linken, falls für ein Teilmodul eine verbesserte [[Version (Software)\|Version]] herausgegeben wurde.<ref name="drepper">{{cite web\|url=http://people.redhat.com/drepper/no_static_linking.html\|archiveurl=https://web.archive.org/web/20041221091001/http://people.redhat.com/drepper/no_static_linking.html\|archivedate=2004-12-21\|title=Static Linking Considered Harmful\|author=[[Ulrich Drepper]]\|quote=''There are still too many people out there who think (or even insist) that static linking has benefits. This has never been the case and never will be the case. […]''\|publisher=redhat.com\|language=englisch\|accessdate=2012-01-13}}</ref>

		⚫	Wegen dieser Nachteile unterstützen einige [[C (Programmiersprache)\|C]]-Bibliotheken unter [[Unixoides Betriebssystem\|Unix-artigen Betriebssystemen]] das statische Linken oft nicht mehr vollständig.<ref name="drepper" /> So erzwingt beispielsweise die [[glibc]] ein dynamisches Linken bei Modulen, die die Benutzer[[authentifizierung]] betreffen. Programme, die diese Module verwenden, sind immer auf die Anwesenheit einer passenden „Laufzeitversion“ der glibc angewiesen.

	== Dynamisches Linken ==		== Dynamisches Linken ==

Rmcharb: Änderung 227844226 von 94.135.230.190 rückgängig gemacht; keine enzykl. Verbesserung

2022-11-10T11:15:55Z

Änderung 227844226 von 94.135.230.190 rückgängig gemacht; keine enzykl. Verbesserung

← Nächstältere Version		Version vom 10. November 2022, 13:15 Uhr
Zeile 23:		Zeile 23:
	Die Funktion <code>void function(int x);</code> ist eine gänzlich andere als <code>void function(float x);</code>. Beide Funktionen haben verschiedene Implementierungen, verschiedene Bezeichnungen in der [[Objektcode\|Objektdatei]] und haben nichts weiter miteinander zu tun, als dass sie den gleichen Namen tragen. Überladen ist also nur der Funktionsname.		Die Funktion <code>void function(int x);</code> ist eine gänzlich andere als <code>void function(float x);</code>. Beide Funktionen haben verschiedene Implementierungen, verschiedene Bezeichnungen in der [[Objektcode\|Objektdatei]] und haben nichts weiter miteinander zu tun, als dass sie den gleichen Namen tragen. Überladen ist also nur der Funktionsname.

	Problematisch für das Verständnis und für den Übersetzer sind Aufrufe folgender Art: Wir müssen das deutsche Schulsystem verändern. Zudem müssen wir die Fächeraufteilung praktischer aufteilen und dafür sorgen ,dass die Schüler wichtige und relevante Informationen bekommen, welche sie im wahren Leben nutzen können.		Problematisch für das Verständnis und für den Übersetzer sind Aufrufe folgender Art:

	<syntaxhighlight lang="C">		<syntaxhighlight lang="C">

94.135.230.190 am 10. November 2022 um 11:15 Uhr

2022-11-10T11:15:21Z

← Nächstältere Version		Version vom 10. November 2022, 13:15 Uhr
Zeile 23:		Zeile 23:
	Die Funktion <code>void function(int x);</code> ist eine gänzlich andere als <code>void function(float x);</code>. Beide Funktionen haben verschiedene Implementierungen, verschiedene Bezeichnungen in der [[Objektcode\|Objektdatei]] und haben nichts weiter miteinander zu tun, als dass sie den gleichen Namen tragen. Überladen ist also nur der Funktionsname.		Die Funktion <code>void function(int x);</code> ist eine gänzlich andere als <code>void function(float x);</code>. Beide Funktionen haben verschiedene Implementierungen, verschiedene Bezeichnungen in der [[Objektcode\|Objektdatei]] und haben nichts weiter miteinander zu tun, als dass sie den gleichen Namen tragen. Überladen ist also nur der Funktionsname.

	Problematisch für das Verständnis und für den Übersetzer sind Aufrufe folgender Art:		Problematisch für das Verständnis und für den Übersetzer sind Aufrufe folgender Art: Wir müssen das deutsche Schulsystem verändern. Zudem müssen wir die Fächeraufteilung praktischer aufteilen und dafür sorgen ,dass die Schüler wichtige und relevante Informationen bekommen, welche sie im wahren Leben nutzen können.

	<syntaxhighlight lang="C">		<syntaxhighlight lang="C">

92.208.169.7: /* Dynamisches Linken */ Keinen Beleg für eine Abweichung der Schreibung des Lemmas gefunden, daher Link auf Lemmanamen angepasst

2022-09-23T10:20:33Z

Dynamisches Linken: Keinen Beleg für eine Abweichung der Schreibung des Lemmas gefunden, daher Link auf Lemmanamen angepasst

← Nächstältere Version		Version vom 23. September 2022, 12:20 Uhr
Zeile 13:		Zeile 13:

	== Dynamisches Linken ==		== Dynamisches Linken ==
	Es ist auch möglich, das Auflösen der Funktions- und Variablennamen zu verschieben, bis das Programm tatsächlich ausgeführt wird. In diesem Fall spricht man von dynamischem Linken. Je nach Betriebssystem geschieht dies durch das Laden vollständiger [[Programmbibliothek#Dynamische Bibliotheken\|''dynamischer Bibliotheken'']] (auch bekannt als ''[[Dynamic Link Library\|~~dynamically~~ ~~linked~~ ~~library~~ (DLL)]]'' oder ''shared library'') oder das gezielte Laden eines Unterprogramms aus einer Programmbibliothek. Dies hat den Vorteil, dass Bibliotheken oder Programme nachträglich leicht ausgetauscht werden können, die aufrufenden Programme kleiner werden und der Speicher nur einmal benötigt wird, wenn mehrere Programme dieselben Komponenten verwenden. Der Nachteil besteht darin, dass sichergestellt werden muss, dass die richtige Bibliothek in der richtigen Version installiert ist (siehe z. B. [[DLL-Konflikt]]). Nachgeladene Bibliotheken werden oft als [[Plug-in]]s bezeichnet.		Es ist auch möglich, das Auflösen der Funktions- und Variablennamen zu verschieben, bis das Programm tatsächlich ausgeführt wird. In diesem Fall spricht man von dynamischem Linken. Je nach Betriebssystem geschieht dies durch das Laden vollständiger [[Programmbibliothek#Dynamische Bibliotheken\|''dynamischer Bibliotheken'']] (auch bekannt als ''[[Dynamic Link Library\|Dynamic Link Library (DLL)]]'' oder ''shared library'') oder das gezielte Laden eines Unterprogramms aus einer Programmbibliothek. Dies hat den Vorteil, dass Bibliotheken oder Programme nachträglich leicht ausgetauscht werden können, die aufrufenden Programme kleiner werden und der Speicher nur einmal benötigt wird, wenn mehrere Programme dieselben Komponenten verwenden. Der Nachteil besteht darin, dass sichergestellt werden muss, dass die richtige Bibliothek in der richtigen Version installiert ist (siehe z. B. [[DLL-Konflikt]]). Nachgeladene Bibliotheken werden oft als [[Plug-in]]s bezeichnet.

	Mischformen der statischen und dynamischen Link-Art sind der Normalfall. Dabei werden gewisse Unterprogramme dem aufrufenden Programm statisch hinzugebunden, andere werden dynamisch nachgeladen.		Mischformen der statischen und dynamischen Link-Art sind der Normalfall. Dabei werden gewisse Unterprogramme dem aufrufenden Programm statisch hinzugebunden, andere werden dynamisch nachgeladen.

Y2kbug: Suchpfad verlinkt

2022-08-04T10:27:28Z

Suchpfad verlinkt

← Nächstältere Version		Version vom 4. August 2022, 12:27 Uhr
Zeile 47:		Zeile 47:

	== Namenskonflikte ==		== Namenskonflikte ==
	Bei dem Vorgang des Linkens entsteht ein einziger großer, nicht-hierarchischer, gemeinsamer [[Namensraum]]. Dadurch kommt es bei großen oder sehr verzweigten Projekten oft zu Namenskonflikten. Für diese Fälle sind ''weak links'' üblich, bei denen die Linkreihenfolge entscheidet, welches Modul wo verwendet wird. Programmiersprachen wie z. B. [[C++]] lösen das Problem dadurch, dass Modulinhalte über hierarchisch aufgebaute Namen angesprochen werden. Ungelöst bleibt damit jedoch beispielsweise das Problem der Anwesenheit einer Bibliothek in verschiedenen Versionen; das Problem ist zum Zeitpunkt des Linkens nur dadurch lösbar, dass dem Linker je nach benötigter Bibliothek unterschiedliche ~~Suchpfade~~ mitgegeben werden – jede der in Frage kommenden Bibliotheken unterscheidet sich zwar von der Bezeichnung her, ist aber inhaltlich für einen Linker ununterscheidbar, da in ihr die gleichen Symbole vorhanden sind. Nach dem ersten, statischen Linken ist die Angelegenheit dagegen unproblematisch, da sich die verwendete Bibliothek von da an anhand ihres Namens aufrufen lässt.		Bei dem Vorgang des Linkens entsteht ein einziger großer, nicht-hierarchischer, gemeinsamer [[Namensraum]]. Dadurch kommt es bei großen oder sehr verzweigten Projekten oft zu Namenskonflikten. Für diese Fälle sind ''weak links'' üblich, bei denen die Linkreihenfolge entscheidet, welches Modul wo verwendet wird. Programmiersprachen wie z. B. [[C++]] lösen das Problem dadurch, dass Modulinhalte über hierarchisch aufgebaute Namen angesprochen werden. Ungelöst bleibt damit jedoch beispielsweise das Problem der Anwesenheit einer Bibliothek in verschiedenen Versionen; das Problem ist zum Zeitpunkt des Linkens nur dadurch lösbar, dass dem Linker je nach benötigter Bibliothek unterschiedliche [[Suchpfad]]e mitgegeben werden – jede der in Frage kommenden Bibliotheken unterscheidet sich zwar von der Bezeichnung her, ist aber inhaltlich für einen Linker ununterscheidbar, da in ihr die gleichen Symbole vorhanden sind. Nach dem ersten, statischen Linken ist die Angelegenheit dagegen unproblematisch, da sich die verwendete Bibliothek von da an anhand ihres Namens aufrufen lässt.

	== Literatur ==		== Literatur ==

ZabesBot: Bot: Räume alte Interwikilinks auf

2022-01-16T22:11:56Z

Bot: Räume alte Interwikilinks auf

← Nächstältere Version		Version vom 17. Januar 2022, 00:11 Uhr
Zeile 94:		Zeile 94:

	[[Kategorie:Programmierwerkzeug]]		[[Kategorie:Programmierwerkzeug]]

	[[tr:Bağlayıcı]]

Aka: /* Überschreiben */ Abkürzung korrigiert

2021-02-15T18:03:39Z

Überschreiben: Abkürzung korrigiert

← Nächstältere Version		Version vom 15. Februar 2021, 20:03 Uhr
Zeile 44:		Zeile 44:

	=== Überschreiben ===		=== Überschreiben ===
	Mit dem vom „Überladen“ zu unterscheidenden „[[Überschreiben (OOP)\|Überschreiben]]“ wird ein [[Dynamische Bindung\|dynamisches Binden]] bezeichnet, das im Programmablauf entsprechend reagiert, wenn im Quelltext eine Methode (d.h. ein Unterprogramm) einer Basisklasse von der gleichnamigen und gleich parametrisierten Methode der abgeleiteten Klasse überdeckt wird. Zur Laufzeit wird diejenige Methode gerufen, die der Instanz der Daten entspricht. Das wird durch die [[Tabelle virtueller Methoden]] ermöglicht, einem Grundkonzept der Implementation von [[Objektorientierte Programmierung\|objektorientierter Programmierung]].		Mit dem vom „Überladen“ zu unterscheidenden „[[Überschreiben (OOP)\|Überschreiben]]“ wird ein [[Dynamische Bindung\|dynamisches Binden]] bezeichnet, das im Programmablauf entsprechend reagiert, wenn im Quelltext eine Methode (d. h. ein Unterprogramm) einer Basisklasse von der gleichnamigen und gleich parametrisierten Methode der abgeleiteten Klasse überdeckt wird. Zur Laufzeit wird diejenige Methode gerufen, die der Instanz der Daten entspricht. Das wird durch die [[Tabelle virtueller Methoden]] ermöglicht, einem Grundkonzept der Implementation von [[Objektorientierte Programmierung\|objektorientierter Programmierung]].

	== Namenskonflikte ==		== Namenskonflikte ==

87.254.97.74: /* Überschreiben */ Klarstellungen

2020-11-26T10:48:07Z

Überschreiben: Klarstellungen

← Nächstältere Version		Version vom 26. November 2020, 12:48 Uhr
Zeile 44:		Zeile 44:

	=== Überschreiben ===		=== Überschreiben ===
	Mit dem vom „Überladen“ zu unterscheidenden „[[Überschreiben (OOP)\|Überschreiben]]“ wird ein [[Dynamische Bindung\|dynamisches Binden]] bezeichnet, ~~bei~~ ~~dem~~ eine Methode (ein Unterprogramm) einer Basisklasse von der gleichnamigen und gleich parametrisierten Methode der abgeleiteten Klasse überdeckt wird. Zur Laufzeit wird diejenige Methode gerufen, die der Instanz der Daten entspricht. Das wird ~~vermittelt~~ durch die [[Tabelle virtueller Methoden]], ~~ein~~ Grundkonzept der [[Objektorientierte Programmierung\|~~objektorientierten~~ Programmierung]].		Mit dem vom „Überladen“ zu unterscheidenden „[[Überschreiben (OOP)\|Überschreiben]]“ wird ein [[Dynamische Bindung\|dynamisches Binden]] bezeichnet, das im Programmablauf entsprechend reagiert, wenn im Quelltext eine Methode (d.h. ein Unterprogramm) einer Basisklasse von der gleichnamigen und gleich parametrisierten Methode der abgeleiteten Klasse überdeckt wird. Zur Laufzeit wird diejenige Methode gerufen, die der Instanz der Daten entspricht. Das wird durch die [[Tabelle virtueller Methoden]] ermöglicht, einem Grundkonzept der Implementation von [[Objektorientierte Programmierung\|objektorientierter Programmierung]].

	== Namenskonflikte ==		== Namenskonflikte ==

87.254.97.74: /* Sprachspezifische Varianten beim Laden */ Beim zweiten Lesen fiel mir die unterschiedliche Verwendung von "realisieren" auf.

2020-11-26T06:25:06Z

Sprachspezifische Varianten beim Laden: Beim zweiten Lesen fiel mir die unterschiedliche Verwendung von "realisieren" auf.

← Nächstältere Version		Version vom 26. November 2020, 08:25 Uhr
Zeile 19:		Zeile 19:
	== Sprachspezifische Varianten beim Laden ==		== Sprachspezifische Varianten beim Laden ==
	=== Überladen ===		=== Überladen ===
	Unter „[[Überladen]]“ wird das mehrfache Definieren eines Unterprogramms mit gleichem Bezeichner in Abhängigkeit von der Parameterauswahl verstanden, realisiert durch interne Umbenennung (engl. ''name mangling''). Die nachstehenden Beispiele sind nur in C++ oder Java möglich, ''nicht'' aber in reinem C, wo die Überladung von Funktionen nicht vorgesehen ist und der Versuch, eine solche zu ~~realisieren~~, einen Übersetzungsfehler auslösen würde.		Unter „[[Überladen]]“ wird das mehrfache Definieren eines Unterprogramms mit gleichem Bezeichner in Abhängigkeit von der Parameterauswahl verstanden, realisiert durch interne Umbenennung (engl. ''name mangling''). Die nachstehenden Beispiele sind nur in C++ oder Java möglich, ''nicht'' aber in reinem C, wo die Überladung von Funktionen nicht vorgesehen ist und der Versuch, eine solche zu verlangen, einen Übersetzungsfehler auslösen würde.

	Die Funktion <code>void function(int x);</code> ist eine gänzlich andere als <code>void function(float x);</code>. Beide Funktionen haben verschiedene Implementierungen, verschiedene Bezeichnungen in der [[Objektcode\|Objektdatei]] und haben nichts weiter miteinander zu tun, als dass sie den gleichen Namen tragen. Überladen ist also nur der Funktionsname.		Die Funktion <code>void function(int x);</code> ist eine gänzlich andere als <code>void function(float x);</code>. Beide Funktionen haben verschiedene Implementierungen, verschiedene Bezeichnungen in der [[Objektcode\|Objektdatei]] und haben nichts weiter miteinander zu tun, als dass sie den gleichen Namen tragen. Überladen ist also nur der Funktionsname.

← Nächstältere Version		Version vom 2. Dezember 2023, 11:01 Uhr
Zeile 9:		Zeile 9:
	Das ''statische Linken'' erfolgt typischerweise am Ende der [[Softwareentwicklung\|Entwicklung des Programms]]. Das Ergebnis ist ein fertig zusammengesetztes Programm, das bei vollständig statisch gelinkten Programmen aus einer einzigen [[Datei]] besteht.		Das ''statische Linken'' erfolgt typischerweise am Ende der [[Softwareentwicklung\|Entwicklung des Programms]]. Das Ergebnis ist ein fertig zusammengesetztes Programm, das bei vollständig statisch gelinkten Programmen aus einer einzigen [[Datei]] besteht.

	Beim statischen Linken werden die Programmmodule der Anwendung einmalig ~~''zum~~ ~~Entwicklungszeitpunkt''~~ aufgelöst, im Gegensatz zum dynamischen Linken, bei dem dies jedes Mal zur [[Laufzeit (Informatik)\|Laufzeit]] geschieht.		Beim statischen Linken werden die Programmmodule der Anwendung einmalig zur [[Übersetzungszeit]] aufgelöst, im Gegensatz zum dynamischen Linken, bei dem dies jedes Mal zur [[Laufzeit (Informatik)\|Laufzeit]] geschieht.

	Ein Vorteil ist beim statischen Linken die erhöhte [[Portable Software\|Portabilität]] einer Anwendung, da diese ''nicht'' auf die Bereitstellung von Programmmodulen z. B. durch das [[Betriebssystem]] angewiesen ist, da die Anwendung diese selbst mitführt; eine [[Installation (Computer)\|Installation]] des Programms ist somit nicht erforderlich.<ref>[http://www-vs.informatik.uni-ulm.de/teach/ss10/bs/docs/BS_D1_12_Hauptspeicher.pdf Kapitel über Hauptspeicher, Folie 6] (PDF) informatik.uni-ulm.de ''Betriebssysteme'' – Vorlesung im Hauptstudium</ref> Nachteile sind ein potentiell höherer [[Speicherbedarf]], da Programmmodule nicht von anderen Programmen mitverwendet werden können, und die Notwendigkeit, die Gesamtanwendung neu zu kompilieren und zu linken, falls für ein Teilmodul eine verbesserte [[Version (Software)\|Version]] herausgegeben wurde.<ref name="drepper">{{cite web\|url=http://people.redhat.com/drepper/no_static_linking.html\|archiveurl=https://web.archive.org/web/20041221091001/http://people.redhat.com/drepper/no_static_linking.html\|archivedate=2004-12-21\|title=Static Linking Considered Harmful\|author=[[Ulrich Drepper]]\|quote=''There are still too many people out there who think (or even insist) that static linking has benefits. This has never been the case and never will be the case. […]''\|publisher=redhat.com\|language=englisch\|accessdate=2012-01-13}}</ref>		Ein Vorteil ist beim statischen Linken die erhöhte [[Portable Software\|Portabilität]] einer Anwendung, da diese ''nicht'' auf die Bereitstellung von Programmmodulen z. B. durch das [[Betriebssystem]] angewiesen ist, da die Anwendung diese selbst mitführt; eine [[Installation (Computer)\|Installation]] des Programms ist somit nicht erforderlich.<ref>[http://www-vs.informatik.uni-ulm.de/teach/ss10/bs/docs/BS_D1_12_Hauptspeicher.pdf Kapitel über Hauptspeicher, Folie 6] (PDF) informatik.uni-ulm.de ''Betriebssysteme'' – Vorlesung im Hauptstudium</ref> Nachteile sind ein potentiell höherer [[Speicherbedarf]], da Programmmodule nicht von anderen Programmen mitverwendet werden können, und die Notwendigkeit, die Gesamtanwendung neu zu kompilieren und zu linken, falls für ein Teilmodul eine verbesserte [[Version (Software)\|Version]] herausgegeben wurde.<ref name="drepper">{{cite web\|url=http://people.redhat.com/drepper/no_static_linking.html\|archiveurl=https://web.archive.org/web/20041221091001/http://people.redhat.com/drepper/no_static_linking.html\|archivedate=2004-12-21\|title=Static Linking Considered Harmful\|author=[[Ulrich Drepper]]\|quote=''There are still too many people out there who think (or even insist) that static linking has benefits. This has never been the case and never will be the case. […]''\|publisher=redhat.com\|language=englisch\|accessdate=2012-01-13}}</ref>