LPC (Programmiersprache) - Versionsgeschichte

Gestumblindi am 22. September 2024 um 17:45 Uhr

2024-09-22T17:45:13Z

← Nächstältere Version		Version vom 22. September 2024, 19:45 Uhr
Zeile 36:		Zeile 36:
	Von der sprachlichen Seite abgesehen unterscheidet sich LPC auch in mehreren Punkten in Bezug auf die Definition der [[Laufzeitumgebung]] von anderen [[Programmiersprache]]n. Durch die ursprüngliche Zielsetzung als Sprache eines Online-Rollenspiels, bei dem mehrere Entwickler mit unterschiedlichen Rechten eigenen Code einbringen können, enthält die Laufzeitumgebung beispielsweise sogenannte ''privilegierte Funktionen'', die nur nach vorheriger Überprüfung durch ein ''Master-Objekt'' des MUDs von einem normalen Objekt aufgerufen werden können.		Von der sprachlichen Seite abgesehen unterscheidet sich LPC auch in mehreren Punkten in Bezug auf die Definition der [[Laufzeitumgebung]] von anderen [[Programmiersprache]]n. Durch die ursprüngliche Zielsetzung als Sprache eines Online-Rollenspiels, bei dem mehrere Entwickler mit unterschiedlichen Rechten eigenen Code einbringen können, enthält die Laufzeitumgebung beispielsweise sogenannte ''privilegierte Funktionen'', die nur nach vorheriger Überprüfung durch ein ''Master-Objekt'' des MUDs von einem normalen Objekt aufgerufen werden können.

	Aktuelle LPC-Laufzeitumgebungen ~~unterstützt~~ keine [[Thread (Informatik)\|Threads]]. In einem einzelnen Thread werden nacheinander alle anfallenden Aufgaben erledigt. Dadurch ergibt sich notwendigerweise eine Begrenzung der Laufzeit, die für die Behandlung eines zusammenhängenden Ereignisses gesetzt ist. In LDMuds kann diese Begrenzung dynamisch für einzelne Funktionsaufrufe aufgehoben oder gesetzt werden.		Aktuelle LPC-Laufzeitumgebungen unterstützen keine [[Thread (Informatik)\|Threads]]. In einem einzelnen Thread werden nacheinander alle anfallenden Aufgaben erledigt. Dadurch ergibt sich notwendigerweise eine Begrenzung der Laufzeit, die für die Behandlung eines zusammenhängenden Ereignisses gesetzt ist. In LDMuds kann diese Begrenzung dynamisch für einzelne Funktionsaufrufe aufgehoben oder gesetzt werden.

	Eine weitere Besonderheit ist die fast vollständige Gleichwertigkeit der eingebauten Funktionen (''efuns'') mit von der Klassenbibliothek eines MUDs (''MUDlib'') vorgegebenen ''simul_efuns''. Auf diese Weise ist es möglich, Standardfunktionen zu überschreiben oder den Zugriff darauf zu verbieten.		Eine weitere Besonderheit ist die fast vollständige Gleichwertigkeit der eingebauten Funktionen (''efuns'') mit von der Klassenbibliothek eines MUDs (''MUDlib'') vorgegebenen ''simul_efuns''. Auf diese Weise ist es möglich, Standardfunktionen zu überschreiben oder den Zugriff darauf zu verbieten.

Aka: /* Geschichte */ https

2023-11-25T17:08:35Z

Geschichte: https

← Nächstältere Version		Version vom 25. November 2023, 19:08 Uhr
Zeile 4:		Zeile 4:

	== Geschichte ==		== Geschichte ==
	Die Bezeichnung LPC leitet sich vom Erfinder der Sprache, [[Lars Pensjö]], ab.<ref>Xyllomer.de: {{Internetquelle \| url=~~http~~://www.xyllomer.de/system/lpc.php \| titel=The LPC Reference Manual \| zugriff=2016-04-20}}</ref> Pensjö entwickelte LPC Anfang der 1990er-Jahre und orientierte sich dabei an der Programmiersprache C. Von der ähnlichen Syntax abgesehen gibt es jedoch nur wenige Gemeinsamkeiten der beiden Sprachen.		Die Bezeichnung LPC leitet sich vom Erfinder der Sprache, [[Lars Pensjö]], ab.<ref>Xyllomer.de: {{Internetquelle \| url=https://www.xyllomer.de/system/lpc.php \| titel=The LPC Reference Manual \| zugriff=2016-04-20}}</ref> Pensjö entwickelte LPC Anfang der 1990er-Jahre und orientierte sich dabei an der Programmiersprache C. Von der ähnlichen Syntax abgesehen gibt es jedoch nur wenige Gemeinsamkeiten der beiden Sprachen.

	Bei den ursprünglichen Implementierungen von LPC waren [[Compiler]] und [[Bytecode]]-[[Interpreter]] Bestandteile eines einzelnen Programms, das grundlegende, für den Betrieb eines Multi User Dungeons notwendige Funktionalität zur Verfügung stellte, den sogenannten ''Gamedriver'' oder kurz ''Driver''. Auch das MUD Amylaar trug wesentliche Teil zum Treiber bei. Dazu gehört vor allem der Betrieb als [[Server]], zu dem mit einem [[Telnet]]- oder einem speziellen MUD-[[Client]] eine Verbindung hergestellt werden kann. Diese Software wurde unter dem Namen [[LPMud]] verbreitet; eine moderne Weiterentwicklung auf Basis des ursprünglichen LPMud-Quellcodes hört auf die Bezeichnung [[LDMud]] (nach den Initialen des Maintainers). Eine weitere Implementierung desselben Konzeptes inklusive der Sprache LPC ist [[MudOS]].		Bei den ursprünglichen Implementierungen von LPC waren [[Compiler]] und [[Bytecode]]-[[Interpreter]] Bestandteile eines einzelnen Programms, das grundlegende, für den Betrieb eines Multi User Dungeons notwendige Funktionalität zur Verfügung stellte, den sogenannten ''Gamedriver'' oder kurz ''Driver''. Auch das MUD Amylaar trug wesentliche Teil zum Treiber bei. Dazu gehört vor allem der Betrieb als [[Server]], zu dem mit einem [[Telnet]]- oder einem speziellen MUD-[[Client]] eine Verbindung hergestellt werden kann. Diese Software wurde unter dem Namen [[LPMud]] verbreitet; eine moderne Weiterentwicklung auf Basis des ursprünglichen LPMud-Quellcodes hört auf die Bezeichnung [[LDMud]] (nach den Initialen des Maintainers). Eine weitere Implementierung desselben Konzeptes inklusive der Sprache LPC ist [[MudOS]].

Aka: typografische Anführungszeichen

2022-10-20T19:16:12Z

typografische Anführungszeichen

← Nächstältere Version		Version vom 20. Oktober 2022, 21:16 Uhr
Zeile 41:		Zeile 41:

	=== Unterschiede bei der Objektorientierung ===		=== Unterschiede bei der Objektorientierung ===
	LPC kennt im Gegensatz zu vielen [[Objektorientierte Programmierung\|objektorientierten Programmiersprachen]] keine Unterscheidung zwischen [[Klasse (Objektorientierung)\|Klassen]] und [[Objekt (Programmierung)\|Objekten]]. Im Normalfall wird aus einer [[Quelltext]]-[[Datei]] ein einzelnes Objekt erzeugt. Alle im Speicher befindlichen Objekte können jedoch dupliziert (''geklont / cloned'') werden. Der Vorgang des ''Clonens'' ist vergleichbar mit dem der [[Objekt (Programmierung)\|Instanziierung]] bei anderen Programmiersprachen; allerdings sind der Klon (''clone'') und das Original (''blueprint'') gleichberechtigt und können beide theoretisch auf die gleiche Weise eingesetzt werden. Dabei ist aber zu berücksichtigen, dass das Objektuniversum der LPC-Welt jedem Objekt ein quasi-physisches ~~"befindet~~-sich-~~in"~~-Attribut zuordnet (das Avatar-Objekt des Spielers befindet sich in einem Raum, die Habseligkeiten des Spielers befinden sich in diesem virtuellen Körper usw.), und dass ein Blueprint, der einmal die Welt betreten hat, zwar noch bewegt, aber nicht mehr geklont werden kann; nur wenn das Blueprint-Objekt zerstört und aus dem Quelltext neu erzeugt wird, befindet es sich wieder außerhalb der Welt. (Das Enthaltensein ist eine elementare Eigenschaft des Gamedrivers, nicht der MUDlib.)		LPC kennt im Gegensatz zu vielen [[Objektorientierte Programmierung\|objektorientierten Programmiersprachen]] keine Unterscheidung zwischen [[Klasse (Objektorientierung)\|Klassen]] und [[Objekt (Programmierung)\|Objekten]]. Im Normalfall wird aus einer [[Quelltext]]-[[Datei]] ein einzelnes Objekt erzeugt. Alle im Speicher befindlichen Objekte können jedoch dupliziert (''geklont / cloned'') werden. Der Vorgang des ''Clonens'' ist vergleichbar mit dem der [[Objekt (Programmierung)\|Instanziierung]] bei anderen Programmiersprachen; allerdings sind der Klon (''clone'') und das Original (''blueprint'') gleichberechtigt und können beide theoretisch auf die gleiche Weise eingesetzt werden. Dabei ist aber zu berücksichtigen, dass das Objektuniversum der LPC-Welt jedem Objekt ein quasi-physisches „befindet-sich-in“-Attribut zuordnet (das Avatar-Objekt des Spielers befindet sich in einem Raum, die Habseligkeiten des Spielers befinden sich in diesem virtuellen Körper usw.), und dass ein Blueprint, der einmal die Welt betreten hat, zwar noch bewegt, aber nicht mehr geklont werden kann; nur wenn das Blueprint-Objekt zerstört und aus dem Quelltext neu erzeugt wird, befindet es sich wieder außerhalb der Welt. (Das Enthaltensein ist eine elementare Eigenschaft des Gamedrivers, nicht der MUDlib.)

	=== Besondere Konstrukte ===		=== Besondere Konstrukte ===
	LPC kennt das Konzept des ''Shadowing''. Dabei handelt es sich um eine Möglichkeit, alle Zugriffe auf eine Funktion eines Objektes von außen abzufangen, beispielsweise um sie zu filtern oder ganz zu unterbinden, ähnlich dem [[Decorator]]-Muster. Das Prinzip wird angewandt, indem ein Objekt mit der ''efun'' shadow() sich als ~~"Schatten"~~ eines beliebigen anderen Objektes registriert. Bei einem Aufruf einer Funktion des Zielobjektes, der nicht innerhalb des Zielobjektes direkt geschieht, wird dann die gleichnamige Funktion im Schatten-Objekt aufgerufen, falls dieses Objekt eine solche Funktion enthält. Existiert im Schatten-Objekt keine Funktion gleichen Namens, wird der Aufruf wie ein normaler Funktionsaufruf in einem Objekt ohne Schatten behandelt. Das Schatten-Objekt hat ebenfalls die Möglichkeit, Funktionen im Zielobjekt, das es ~~"überschattet"~~, aufzurufen.		LPC kennt das Konzept des ''Shadowing''. Dabei handelt es sich um eine Möglichkeit, alle Zugriffe auf eine Funktion eines Objektes von außen abzufangen, beispielsweise um sie zu filtern oder ganz zu unterbinden, ähnlich dem [[Decorator]]-Muster. Das Prinzip wird angewandt, indem ein Objekt mit der ''efun'' shadow() sich als „Schatten“ eines beliebigen anderen Objektes registriert. Bei einem Aufruf einer Funktion des Zielobjektes, der nicht innerhalb des Zielobjektes direkt geschieht, wird dann die gleichnamige Funktion im Schatten-Objekt aufgerufen, falls dieses Objekt eine solche Funktion enthält. Existiert im Schatten-Objekt keine Funktion gleichen Namens, wird der Aufruf wie ein normaler Funktionsaufruf in einem Objekt ohne Schatten behandelt. Das Schatten-Objekt hat ebenfalls die Möglichkeit, Funktionen im Zielobjekt, das es „überschattet“, aufzurufen.

	=== Besondere Datentypen ===		=== Besondere Datentypen ===
Zeile 54:		Zeile 54:

	== Hallo-Welt-Programm in LPC ==		== Hallo-Welt-Programm in LPC ==
	Das folgende Objekt gibt ''beim ersten Laden'' den Text ~~"Hallo~~, Welt!" aus, da die create()-Methode üblicherweise beim Laden/Clonen von Objekten automatisch aufgerufen wird.		Das folgende Objekt gibt ''beim ersten Laden'' den Text „Hallo, Welt!“ aus, da die create()-Methode üblicherweise beim Laden/Clonen von Objekten automatisch aufgerufen wird.

	<pre>		<pre>

87.254.97.74: /* Unterschiede bei der Objektorientierung */ Klonverbot

2021-03-22T00:40:24Z

Unterschiede bei der Objektorientierung: Klonverbot

← Nächstältere Version		Version vom 22. März 2021, 02:40 Uhr
Zeile 41:		Zeile 41:

	=== Unterschiede bei der Objektorientierung ===		=== Unterschiede bei der Objektorientierung ===
	LPC kennt im Gegensatz zu vielen [[Objektorientierte Programmierung\|objektorientierten Programmiersprachen]] keine Unterscheidung zwischen [[Klasse (Objektorientierung)\|Klassen]] und [[Objekt (Programmierung)\|Objekten]]. Im Normalfall wird aus einer [[Quelltext]]-[[Datei]] ein einzelnes Objekt erzeugt. Alle im Speicher befindlichen Objekte können jedoch dupliziert (''geklont / cloned'') werden. Der Vorgang des ''Clonens'' ist vergleichbar mit dem der [[Objekt (Programmierung)\|Instanziierung]] bei anderen Programmiersprachen; allerdings sind der Klon (''clone'') und das Original (''blueprint'') gleichberechtigt und können beide theoretisch auf die gleiche Weise eingesetzt werden.		LPC kennt im Gegensatz zu vielen [[Objektorientierte Programmierung\|objektorientierten Programmiersprachen]] keine Unterscheidung zwischen [[Klasse (Objektorientierung)\|Klassen]] und [[Objekt (Programmierung)\|Objekten]]. Im Normalfall wird aus einer [[Quelltext]]-[[Datei]] ein einzelnes Objekt erzeugt. Alle im Speicher befindlichen Objekte können jedoch dupliziert (''geklont / cloned'') werden. Der Vorgang des ''Clonens'' ist vergleichbar mit dem der [[Objekt (Programmierung)\|Instanziierung]] bei anderen Programmiersprachen; allerdings sind der Klon (''clone'') und das Original (''blueprint'') gleichberechtigt und können beide theoretisch auf die gleiche Weise eingesetzt werden. Dabei ist aber zu berücksichtigen, dass das Objektuniversum der LPC-Welt jedem Objekt ein quasi-physisches "befindet-sich-in"-Attribut zuordnet (das Avatar-Objekt des Spielers befindet sich in einem Raum, die Habseligkeiten des Spielers befinden sich in diesem virtuellen Körper usw.), und dass ein Blueprint, der einmal die Welt betreten hat, zwar noch bewegt, aber nicht mehr geklont werden kann; nur wenn das Blueprint-Objekt zerstört und aus dem Quelltext neu erzeugt wird, befindet es sich wieder außerhalb der Welt. (Das Enthaltensein ist eine elementare Eigenschaft des Gamedrivers, nicht der MUDlib.)

	=== Besondere Konstrukte ===		=== Besondere Konstrukte ===

Polluks: /* Komplexeres Beispielobjekt */

2020-11-05T21:32:45Z

Komplexeres Beispielobjekt

← Nächstältere Version		Version vom 5. November 2020, 23:32 Uhr
Zeile 69:		Zeile 69:
	Das folgende Beispiel bezieht sich auf die Anwendung von LPC zusammen mit einer vorhandenen Klassenbibliothek, die nicht zum Lieferumfang von LPMud gehört. Es implementiert einen Apfel und erbt von einem Standardobjekt, das vom Spieler essbare Nahrung implementiert. Dazu gehört unter anderem die zur Implementierung des Ess-Vorgangs im Spiel notwendige Logik. Im erbenden Objekt müssen so nur noch die Werte von Eigenschaften eingestellt werden, die im Rahmen der Möglichkeiten der Basisklasse die Auswirkungen des Verzehrs bestimmten. Die in diesem Beispiel referenzierte MUDlib stellt hierzu die Funktion SetProp() zur Verfügung. Die Namen der Eigenschaften sind dabei Präprozessor-Makros. Es ist, je nach MUD, auch üblich, auf Eigenschaften über einzelne [[Accessor-Methode\|Accessor-Funktionen]] zuzugreifen.		Das folgende Beispiel bezieht sich auf die Anwendung von LPC zusammen mit einer vorhandenen Klassenbibliothek, die nicht zum Lieferumfang von LPMud gehört. Es implementiert einen Apfel und erbt von einem Standardobjekt, das vom Spieler essbare Nahrung implementiert. Dazu gehört unter anderem die zur Implementierung des Ess-Vorgangs im Spiel notwendige Logik. Im erbenden Objekt müssen so nur noch die Werte von Eigenschaften eingestellt werden, die im Rahmen der Möglichkeiten der Basisklasse die Auswirkungen des Verzehrs bestimmten. Die in diesem Beispiel referenzierte MUDlib stellt hierzu die Funktion SetProp() zur Verfügung. Die Namen der Eigenschaften sind dabei Präprozessor-Makros. Es ist, je nach MUD, auch üblich, auf Eigenschaften über einzelne [[Accessor-Methode\|Accessor-Funktionen]] zuzugreifen.

			<syntaxhighlight lang="cpp">
	<pre>
	<nowiki>
	inherit "/std/food";		inherit "/std/food";

	#include ~~<~~properties.h~~>~~		#include <properties.h>
	#include ~~<~~language.h~~>~~		#include <language.h>
	#include ~~<~~food.h~~>~~		#include <food.h>

	void create()		void create()
Zeile 96:		Zeile 95:
	F_MSG_ROOM: "isst einen leckeren roten Apfel."]) );		F_MSG_ROOM: "isst einen leckeren roten Apfel."]) );
	}		}
			</syntaxhighlight>
	</nowiki>
	</pre>

	== Einzelnachweise ==		== Einzelnachweise ==

Grueslayer: Die Links drehen sich alle um MUDs, nicht um LPC.

2020-08-24T06:53:55Z

Die Links drehen sich alle um MUDs, nicht um LPC.

← Nächstältere Version		Version vom 24. August 2020, 08:53 Uhr
Zeile 98:		Zeile 98:
	</nowiki>		</nowiki>
	</pre>		</pre>

	== Weblinks ==
	* [http://www.bearnip.com/lars/proj/ldmud.html Alternatives LPC-Projekt von Lars Düning]
	* [http://www.lysator.liu.se/mud/profword.html "Lpc, the stuff that dreams are made of"]
	* [http://www.mudpedia.org/wiki/LPMudlib_family_tree Stammbaum]

	== Weblinks zu MUDlibs ==
	* [telnet://mud.tubmud.de:7680 Tubmud-Zugang]

	== Newsgroups ==
	* [news://de.alt.mud/ de.alt.mud] ([http://groups.google.com/group/de.alt.mud bei Google Groups])

	== Einzelnachweise ==		== Einzelnachweise ==
Zeile 114:		Zeile 103:

	{{SORTIERUNG:Lpc}}		{{SORTIERUNG:Lpc}}

	[[Kategorie:Skriptsprache]]		[[Kategorie:Skriptsprache]]
	[[Kategorie:Objektorientierte Programmiersprache]]		[[Kategorie:Objektorientierte Programmiersprache]]

Grueslayer: Änderung 195327356 von Trustable rückgängig gemacht; nein.

2020-01-01T20:05:24Z

Änderung 195327356 von Trustable rückgängig gemacht; nein.

← Nächstältere Version		Version vom 1. Januar 2020, 22:05 Uhr
Zeile 1:		Zeile 1:
	'''LPC''' ist eine [[Objektorientierte Programmierung\|objektorientierte]] [[Programmiersprache]], in der Syntax ähnlich wie [[C (Programmiersprache)\|C]] oder [[C++]], für Netzwerk-Textabenteuerspiele ([[Multi User Dungeon]]s, kurz MUDs).		'''LPC''' ist eine [[Objektorientierte Programmierung\|objektorientierte]] [[Programmiersprache]], in der Syntax ähnlich wie [[C (Programmiersprache)\|C]] oder [[C++]], für Netzwerk-Textabenteuerspiele ([[Multi User Dungeon]]s, kurz MUDs).

	LPC-MUDs erlauben in der Regel, zur [[Laufzeit (Informatik)\|Laufzeit]] Programme hinzuzufügen, zu starten und auch nachträglich zu ändern, ohne das ganze Spiel neu zu starten. Der LPC-Code wird von einem [[Compiler]] zuerst in einen [[Bytecode]] umgewandelt und danach von einem [[Interpreter]] ausgeführt.		LPC ist eine Mischung aus Interpreter- und Compilersprache. LPC-MUDs erlauben in der Regel, zur [[Laufzeit (Informatik)\|Laufzeit]] Programme hinzuzufügen, zu starten und auch nachträglich zu ändern, ohne das ganze Spiel neu zu starten. Der LPC-Code wird von einem [[Compiler]] zuerst in einen [[Bytecode]] umgewandelt und danach von einem [[Interpreter]] ausgeführt.

	== Geschichte ==		== Geschichte ==
Zeile 91:		Zeile 91:
	SetProp(P_MATERIAL, ([ MAT_FRUIT: 100 ]) );		SetProp(P_MATERIAL, ([ MAT_FRUIT: 100 ]) );
	SetProp(P_FOOD_INFO,		SetProp(P_FOOD_INFO,
	([ F_HEAL: ({ 10,10}),		([ F_HEAL: ({10,10}),
	F_SOAK: 5,		F_SOAK: 5,
	F_MSG: "Du isst den leckeren roten Apfel.",		F_MSG: "Du isst den leckeren roten Apfel.",

Trustable: Satz entfernt. Jede Sprache kann kompiliert oder interpretiert werden.

2019-12-29T21:51:32Z

Satz entfernt. Jede Sprache kann kompiliert oder interpretiert werden.

← Nächstältere Version		Version vom 29. Dezember 2019, 23:51 Uhr
Zeile 1:		Zeile 1:
	'''LPC''' ist eine [[Objektorientierte Programmierung\|objektorientierte]] [[Programmiersprache]], in der Syntax ähnlich wie [[C (Programmiersprache)\|C]] oder [[C++]], für Netzwerk-Textabenteuerspiele ([[Multi User Dungeon]]s, kurz MUDs).		'''LPC''' ist eine [[Objektorientierte Programmierung\|objektorientierte]] [[Programmiersprache]], in der Syntax ähnlich wie [[C (Programmiersprache)\|C]] oder [[C++]], für Netzwerk-Textabenteuerspiele ([[Multi User Dungeon]]s, kurz MUDs).

	~~LPC ist eine Mischung aus Interpreter- und Compilersprache.~~ LPC-MUDs erlauben in der Regel, zur [[Laufzeit (Informatik)\|Laufzeit]] Programme hinzuzufügen, zu starten und auch nachträglich zu ändern, ohne das ganze Spiel neu zu starten. Der LPC-Code wird von einem [[Compiler]] zuerst in einen [[Bytecode]] umgewandelt und danach von einem [[Interpreter]] ausgeführt.		LPC-MUDs erlauben in der Regel, zur [[Laufzeit (Informatik)\|Laufzeit]] Programme hinzuzufügen, zu starten und auch nachträglich zu ändern, ohne das ganze Spiel neu zu starten. Der LPC-Code wird von einem [[Compiler]] zuerst in einen [[Bytecode]] umgewandelt und danach von einem [[Interpreter]] ausgeführt.

	== Geschichte ==		== Geschichte ==
Zeile 91:		Zeile 91:
	SetProp(P_MATERIAL, ([ MAT_FRUIT: 100 ]) );		SetProp(P_MATERIAL, ([ MAT_FRUIT: 100 ]) );
	SetProp(P_FOOD_INFO,		SetProp(P_FOOD_INFO,
	([ F_HEAL: ({ 10,10}),		([ F_HEAL: ({ 10,10}),
	F_SOAK: 5,		F_SOAK: 5,
	F_MSG: "Du isst den leckeren roten Apfel.",		F_MSG: "Du isst den leckeren roten Apfel.",

Aka: /* Unterschiede zu anderen C-ähnlichen Sprachen */ Halbgeviertstrich

2019-11-14T21:28:59Z

Unterschiede zu anderen C-ähnlichen Sprachen: Halbgeviertstrich

← Nächstältere Version		Version vom 14. November 2019, 23:28 Uhr
Zeile 27:		Zeile 27:
	Das wirkt sich auch auf Rückgabewerte und Parameter von Funktionen aus: im Normalfall müssen in der [[Signatur (Programmierung)\|Funktionssignatur]] weder die Argumente noch Rückgabewert mit Typen versehen werden. Man kann jedoch durch Angabe von [[Präprozessor]]-Direktiven eine Überprüfung auf gültige Argumente zum Übersetzungszeitpunkt erzwingen:		Das wirkt sich auch auf Rückgabewerte und Parameter von Funktionen aus: im Normalfall müssen in der [[Signatur (Programmierung)\|Funktionssignatur]] weder die Argumente noch Rückgabewert mit Typen versehen werden. Man kann jedoch durch Angabe von [[Präprozessor]]-Direktiven eine Überprüfung auf gültige Argumente zum Übersetzungszeitpunkt erzwingen:

	* ''#pragma strong_types'' - Typen für Argumente und Rückgabewert müssen angegeben werden		* ''#pragma strong_types'' – Typen für Argumente und Rückgabewert müssen angegeben werden
	* ''#pragma strict_types'' - der Rückgabewert von an fremden Objekten gerufenen Methoden muss gecastet werden		* ''#pragma strict_types'' – der Rückgabewert von an fremden Objekten gerufenen Methoden muss gecastet werden

	=== Die Klassenbibliothek eines MUDs ===		=== Die Klassenbibliothek eines MUDs ===

Invisigoth67: form

2018-09-02T11:51:23Z

form

← Nächstältere Version		Version vom 2. September 2018, 13:51 Uhr
Zeile 65:		Zeile 65:

	== Komplexeres Beispielobjekt ==		== Komplexeres Beispielobjekt ==
	LPC wird hauptsächlich zur Beschreibung von Objekten in Rollenspielen eingesetzt. Solche Objekte sind in vielen Fällen Gegenstände, Einwohner oder Räume einer virtuellen Welt. Die [[Klassenbibliothek]] (MUDlib) enthält deshalb typischerweise Objekte, die ganz allgemein einen Gegenstand - oder eine bestimmte Klasse von Gegenständen - repräsentiert. Ähnliches gilt für Räume, Monster und alle anderen Objekte, die häufig in verschiedenen Variationen erzeugt werden müssen.		LPC wird hauptsächlich zur Beschreibung von Objekten in Rollenspielen eingesetzt. Solche Objekte sind in vielen Fällen Gegenstände, Einwohner oder Räume einer virtuellen Welt. Die [[Klassenbibliothek]] (MUDlib) enthält deshalb typischerweise Objekte, die ganz allgemein einen Gegenstand – oder eine bestimmte Klasse von Gegenständen – repräsentiert. Ähnliches gilt für Räume, Monster und alle anderen Objekte, die häufig in verschiedenen Variationen erzeugt werden müssen.

	Das folgende Beispiel bezieht sich auf die Anwendung von LPC zusammen mit einer vorhandenen Klassenbibliothek, die nicht zum Lieferumfang von LPMud gehört. Es implementiert einen Apfel und erbt von einem Standardobjekt, das vom Spieler essbare Nahrung implementiert. Dazu gehört unter anderem die zur Implementierung des Ess-Vorgangs im Spiel notwendige Logik. Im erbenden Objekt müssen so nur noch die Werte von Eigenschaften eingestellt werden, die im Rahmen der Möglichkeiten der Basisklasse die Auswirkungen des Verzehrs bestimmten. Die in diesem Beispiel referenzierte MUDlib stellt hierzu die Funktion SetProp() zur Verfügung. Die Namen der Eigenschaften sind dabei Präprozessor-Makros. Es ist, je nach MUD, auch üblich, auf Eigenschaften über einzelne [[Accessor-Methode\|Accessor-Funktionen]] zuzugreifen.		Das folgende Beispiel bezieht sich auf die Anwendung von LPC zusammen mit einer vorhandenen Klassenbibliothek, die nicht zum Lieferumfang von LPMud gehört. Es implementiert einen Apfel und erbt von einem Standardobjekt, das vom Spieler essbare Nahrung implementiert. Dazu gehört unter anderem die zur Implementierung des Ess-Vorgangs im Spiel notwendige Logik. Im erbenden Objekt müssen so nur noch die Werte von Eigenschaften eingestellt werden, die im Rahmen der Möglichkeiten der Basisklasse die Auswirkungen des Verzehrs bestimmten. Die in diesem Beispiel referenzierte MUDlib stellt hierzu die Funktion SetProp() zur Verfügung. Die Namen der Eigenschaften sind dabei Präprozessor-Makros. Es ist, je nach MUD, auch üblich, auf Eigenschaften über einzelne [[Accessor-Methode\|Accessor-Funktionen]] zuzugreifen.