 |
Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
kawe
Anmeldungsdatum: 25.03.2012
Beiträge: 41
|
 Verfasst am: 12.11.2012, 18:17 Titel: Pattern zu virtuellen Funktionen/Interfaces diskutieren -wo? |
 |
|
Hallo,
da ich, wie vielleicht manch anderer hier, aus der 'polymorphen' Ecke (Java) komme, würde ich gerne eine Vorgehensweise vorstellen /mit euch diskutieren, wie man mit den bereits vorhandenen Mitteln der aktuellen FreeBASIC-Version virtuelle Funktionen und Interfaces implementieren kann.
Vielleicht ist das ja auch ein alter Hut, dann könnte vielleicht jemand die entsprechenden Links nennen (oder veröffentlichen). Ich habe jedenfalls bisher wenig Brauchbares in den Foren dazu gefunden.
Falls Interesse besteht (ich habe bereits jeweils ein kleines Beispiel zu virtuellen Funktionen und Interfaces erstellt), könnt ihr mir vielleicht auf die Sprünge helfen, wie man das als normaler Forumsgast am besten tun sollte (erstmal hier, als Code-Beispiele, fb_porticula, ... ???).
Das sind ja schon immer ein paar Dutzend Zeilen Code,  .
lG
Zuletzt bearbeitet von kawe am 12.11.2012, 18:25, insgesamt einmal bearbeitet |
|
| Nach oben |
|
 |
Quisslich
Anmeldungsdatum: 09.09.2012
Beiträge: 38
|
| Verfasst am: 12.11.2012, 18:30 Titel: |
|
|
| hört sich nicht uninteressant an. Stells doch einfach mal vor. |
|
| Nach oben |
|
|
MOD
Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007
Beiträge: 1003
|
| Verfasst am: 12.11.2012, 19:15 Titel: |
|
|
| Kurze Codebeispiele kannst du hier posten, ansonsten das Pastesystem des Portals. Ähnliche Codes sind im englischen Forum auch gepostet worden, allerdings bleibt dazu zu sagen, dass die nächste FB-Version wohl mit virtuellen und abstrakten Methoden kommen wird, einen Vorgeschmack kann man sich hier holen: http://www.freebasic.net/forum/viewtopic.php?f=17&t=19095&start=75#p181009 |
|
| Nach oben |
|
|
kawe
Anmeldungsdatum: 25.03.2012
Beiträge: 41
|
| Verfasst am: 12.11.2012, 19:57 Titel: |
|
|
| MOD hat Folgendes geschrieben: | | Kurze Codebeispiele kannst du hier posten, ansonsten das Pastesystem des Portals. Ähnliche Codes sind im englischen Forum auch gepostet worden, allerdings bleibt dazu zu sagen, dass die nächste FB-Version wohl mit virtuellen und abstrakten Methoden kommen wird, einen Vorgeschmack kann man sich hier holen: http://www.freebasic.net/forum/viewtopic.php?f=17&t=19095&start=75#p181009 |
Ok, danke, ich warte mal noch ein bisschen die Resonanz ab, vielleicht ist das ja wirklich alles schon Schnee von gestern.
Meine Code-Beispiele wären so etwa 100 Zeilen lang.
Die Beiträge, die ich bisher hier gefunden habe, machen jedoch explizite Fallunterscheidungen (IF a is ... THEN ... ELSEIF a is ... ...). Das geht natürlich, ist aber sicher nicht optimal.
Mein Weg wäre kurz gesagt, ein den Umständen entsprechend einfacher Umweg über Zeiger auf Funktionen.
Bei der Gelegenheit ist mir da auch eine Unregelmäßigkeit (Bug? Feature? Irrtum meinerseits?) in der 0.24 zum Schlüsselwort DIM in Zusammenhang mit abgeleiteten Klassen aufgefallen, deren Diskussion hier aber nur Sinn macht, wenn ich das ganze Fass aufmache ...
Dass virtuelle Funktionen nach FreeBASIC kommen, habe ich mir gedacht (danke für den Link) - die Frage wären dann ja nur noch
1. wie lange dauert das bis dahin und
2. wird es auch ein Interface-ähnliches Konstrukt geben? |
|
| Nach oben |
|
|
MOD
Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007
Beiträge: 1003
|
| Verfasst am: 12.11.2012, 20:01 Titel: |
|
|
Ist vorgesehen. Du kannst aber natürlich schon abstrakte Methoden in einen Type packen und davon dann ein 'Extends' machen, das ist dann erstmal so ähnlich.
Wenn dir ein Bug aufgefallen ist, kannst du ja einen neuen Thread dazu aufmachen. |
|
| Nach oben |
|
|
kawe
Anmeldungsdatum: 25.03.2012
Beiträge: 41
|
| Verfasst am: 14.11.2012, 17:47 Titel: virtuelle Funktionen in fb 0.24 |
|
|
Ich habe für's erste gerade zwei Dateien im Portal hochgeladen (#1562 und #1563).
Bevor jemandem durch meine weiteren Ausführungen langweilig wird, komme ich erstmal zu der Sache, die ich gerne meinerseits diskutieren würde (zum Rest sage ich später noch was):
Ersetzt man in #1563 die letzten Zeilen (130- ...) durch
| Code: |
'--- demonstrate virtual sub and destructor calls
Scope
Dim As Middle m => Middle()
Print"---"
m.novirt()
Print"---"
End Scope
Print"***"
Scope
Dim As Lower l => Lower()
Print "---"
l.novirt()
Print "***"
End Scope
Sleep
|
kommt man, wie erwartet, zum selben Ergebnis wie im Originalbeispiel.
Versucht man hier aber, wie im Zeigerbeispiel des Originals, die Deklaration auf Oberklassen-, die Instanziierung auf Unterklassenebene,
ist das Ergebnis weniger erfreulich:
| Code: |
'--- demonstrate virtual sub and destructor calls
Scope
Dim As Upper m => Middle()
Print"---"
m.novirt()
Print"---"
End Scope
Print"***"
Scope
Dim As Upper l => Lower()
Print "---"
l.novirt()
Print "***"
End Scope
Sleep
|
Was hier tatsächlich passiert, verstehe ich nicht ganz.
Klar ist, dass die DIM Anweisung Speicher reserviert. Und klar ist, dass, wenn sie lediglich den Speicher für den *deklarierten* Typ (Upper) reserviert, das ganze nicht funktionieren kann.
Also muss doch entweder DIM die Allokation entsprechend dem 'wahren' Typ (Unterklasse) vornehmen - oder der Compiler sollte dieses Konstrukt einfach mit einer Typinkompatibilität ablehnen!?
Ich denke schon, dass die Idee des "DIM"s mit der Polymorphie ihre Probleme haben könnte, da sie ja, anders als New(), bei der Deklaration Speicher reserviert.
Ist da nicht die Ablehnung des letzten Codebeispiels durch den Compiler der einzige Ausweg?
Was meint ihr? |
|
| Nach oben |
|
|
kawe
Anmeldungsdatum: 25.03.2012
Beiträge: 41
|
| Verfasst am: 14.11.2012, 19:14 Titel: |
|
|
... nun der Vollständigkeit halber noch kurz zur eigentlichen Absicht der Codebeispiele #1562 und #1563. Vielleicht helfen sie ja dem einem oder anderen Quereinsteiger noch, bevor auch FreeBASIC ganz virtuell wird.
Die beiden Beispiele sollen zeigen, dass es spätestens ab fb 0.24 sehr wohl möglich ist, virtuelle Funktionen zu implementieren.
Ich denke vielen, die wie ich aus der rein virtuellen Java-Ecke kommen, ist die Mächtigkeit der Zeiger auf Funktionen nicht (mehr) vertraut(?).
Das erste Beispiel demonstriert dabei in erster Linie die *Notwendigkeit* virtueller Funktionen anhand des Destructors. Ein nicht-virtueller Destructor kann nicht korrekt aufräumen, wenn die Referenz nicht den wahren Typ preisgibt. Dann muss dieser wahre Typ am "Ende" aber doch bekannt sein oder explizit abgefragt werden, um noch "von Hand" nachzubessern; was die gemeinsame Verwendung von Instanzen verschieder Unterklassen ja erheblich behindern würde ...
Was ich dann im zweiten Beispiel nachgestellt habe, ist letztendlich nichts anderes, als das was auch der Compiler tun muss, wenn er Funktionen virtualisieren will. Er erstellt eine Tabelle virtueller Funktionszeiger.
Wenn man diese aber selbst, z. B. als Membervariablen, in der entsprechenden Klasse hält (da der Compiler einem das ja noch nicht abnimmt), kann das ganze trotzdem noch einigermaßen übersichtlich bleiben, hier durch:
1. Delegation der zu "virtualisierenden" Funktion an einen Funktionszeiger
2. Setzen des Zeigers bei Instanziierung (z. B. im Constructor) der eigenen und "überschreibenden" Klasse
3. Auslagerung der Implementierung in eine (statische, s. u.) Memberfunktion der entsprechenden Klasse
4. Verwendung der eigenen Instanz über casten des "Instance"-Pointers (s. u.)
Zeiger auf nicht-statische Memberfunktionen sind ja (bisher) nicht möglich, weshalb die "instance"-Variable ('THIS') als Parameter übergeben wird. Ich habe für diese Einschränkung großes Verständnis, denn bei statischen Funktionen stehen alle notwendigen Daten (Adresse der Funktion) ganz leicht zur Compilezeit zur Verfügung. Bei nicht-statischen Memberfunktionen muss ja versteckt(!) noch die Adresse der Instanz übergeben werden ...
Was ich hingegen zunächst nicht verstanden hatte war, warum ich in der Signatur der "überschreibenden" Funtionen nicht den "wahren" Typ von "THIS" verwenden sollte (Compilerwarnung!), also z. B. den Zeiger
| Code: | | fptr_destructor As Sub (As Instance) |
nicht auf eine Sub | Code: | | virt_destructor(instance As Lower) |
statt | Code: | | virt_destructor(instance As Instance) |
verweisen lassen sollte.
Ich sah aber schnell ein, dass der Compiler hier aus Sicht des Überladens argumentieren *muss* und andernfalls im Zweifelsfall raten müsste.
Der vergleichsweise geringe Preis dafür ist das Casten bei Bedarf, exemplarisch im Codebeispiel durch | Code: | [...]
Var pThis => Cptr(Middle Ptr, @instance)
pThis->other_novirt
[...]
|
(... hier könnte man vielleicht an anderer Stelle mal darüber diskutieren, warum man hier einen Zeiger verwendet; etwas, was, glaube ich, auch nicht allen, die nicht aus der C-Ecke kommen, direkt klar ist.) |
|
| Nach oben |
|
|
kawe
Anmeldungsdatum: 25.03.2012
Beiträge: 41
|
| Verfasst am: 16.11.2012, 01:01 Titel: Re: virtuelle Funktionen in fb 0.24 |
|
|
| Zitat: | | Was hier tatsächlich passiert, verstehe ich nicht ganz. |
Ich verstehe es nun, glaube ich. Das ganze scheint ungefähr so abzulaufen:
"DIM" weist der deklarierten Variable auf jeden Fall und auch für Objekt-Variablen (UDTs) den Speicherplatz fest anhand des *deklarierten* Typs zu.
Um das zu bewerkstelligen wird das Initiatorobjekt zunächst temporär kreiert.
Nun gibt es zwei Möglichkeiten:
Entweder dieses entspricht (exakt) dem deklarierten Typ.
Dann wird ihr Speicherplatz der deklarierten Variable zugewiesen. Fertig.
Man sieht beim "DIM"en den Constructoraufruf - mehr nicht.
Falls der Typ aber nicht (exakt) passt, wird die temporäre Variable "zugeschnitten"; Auch eine Konvertierung über einen geeigneten Cast-Operator kommt dabei in Frage.
Handelt sich beim Ergebnis (vor oder nach dem Casten) schließlich um einen "passenden" Unterklassentyp, wird dessen "Überbau" einfach weggelassen und der Rumpf auf den durch das "DIM"en allokierten Speicherplatz kopiert. Das temporäre Objekt wird im Anschluss über seinen Destructor entsorgt.
Dass das ganze so in einem polymorphen Umfeld nicht (immer) funktionieren kann, ist klar - Ein Objekt kann ja dann sehr wohl auf seine Unterklassenfunktionalität und -member zugreifen, auch wenn sie als "Oberklasse" deklariert ist ...
Kann jemand dieses Vorgehen des "DIM"ens mit Intitator bestätigen?
Die zunächst verwirrende Ausgabe des obigen Beispiels bestätigt jedenfalls diese Annahme.
Wenn dem so ist, kommt man damit aber wohl spätestens mit Einführung virtueller Funktionen in Schwierigkeiten, oder?
Andere Sprachen wie C++ oder Java machen (zumindest für komplexe Typen) nicht ohne Grund die Speicherzuweisung nicht über die Deklaration sondern bei der Zuweisung anhand des wahren Typs der Instanz.
Wie mir langsam klar wird, liegt bei mir und auch bei vielen anderen Neulingen, die andere Sprachen kennen, hier ohnehin eines der größten Potentiale für Missverständnisse von FB ...
Ich glaube, über kurz oder lang kommt man nicht umhin, beim "DIM"en Initiatoren, die nicht Type-exakt passende UDTs erzeugen (auch Cast-Operatoren auf andere UDTs bringen ja hier dieselben Probleme), zu verbieten - zumindest, solange das "DIM"en die Speicherzuweisung anhand des deklarierten Typs und nicht anhand des zugewiesenen Objekts vornimmt.
Der Weg über Zeiger und New() scheint mir da im Augenblick der (einzige) Weg zu sein, der "polymorphismus"-fest ist ... |
|
| Nach oben |
|
|
MOD
Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007
Beiträge: 1003
|
| Verfasst am: 16.11.2012, 18:00 Titel: |
|
|
| Zitat: | | Dass das ganze so in einem polymorphen Umfeld nicht (immer) funktionieren kann, ist klar - Ein Objekt kann ja dann sehr wohl auf seine Unterklassenfunktionalität und -member zugreifen, auch wenn sie als "Oberklasse" deklariert ist ... |
Hier liegt das Problem, erst durch VIRTUAL bekommst du das Verhalten, das du hier möchtest. Das fällt dir in Java nicht auf, weil da alles virtuelle Methoden sind.
Also wenn eine Variable als Elternklasse deklariert und über den Konstruktor der Kindklasse initialisiert wird, passiert nun folgendes:
Ohne VIRTUAL: Die Variable ist und bleibt eine Instanz der Elternklasse
Mit VIRTUAL (ab fbc 0.25): Die Variable wird zu einer Instanz der Kindklasse
So in etwa kann man sich das vorstellen. Lad dir doch mal die von mir verlinkte Vorabversion von 0.25 runter und probier es aus. (Nicht vergessen, es ist eine Vorabversion aus dem Code im fbc Repository, da werden auch noch kleine Fehler usw. drinnen sein.) |
|
| Nach oben |
|
|
Flo
aka kleiner_hacker
Anmeldungsdatum: 23.06.2006
Beiträge: 1210
|
| Verfasst am: 16.11.2012, 21:37 Titel: Re: virtuelle Funktionen in fb 0.24 |
|
|
| kawe hat Folgendes geschrieben: | Andere Sprachen wie C++ oder Java machen (zumindest für komplexe Typen) nicht ohne Grund die Speicherzuweisung nicht über die Deklaration sondern bei der Zuweisung anhand des wahren Typs der Instanz.
|
Nein: in beiden Sprachen weist du in Wirklichkeit Pointer/Referenzen zu, niemals (bzw in C++ selten) echte Objekte.
Und wenn du in C++ folgendes tust:
| Code: |
Derived objekt(initialisierungs, daten);
Base foo = (Base)objekt;
|
dann wird objekt beschnitten, und du has genau dasselbe Problem wie in FB.
| Zitat: |
Der Weg über Zeiger und New() scheint mir da im Augenblick der (einzige) Weg zu sein, der "polymorphismus"-fest ist ... |
richtig. aber das ist auch der einzige Weg in Java und C++.
_________________
MFG
Flo
Satoru Iwata: Wer Spaß am Spielen hat, fragt nicht nach Grafik.
zum korrekten Verstaendnis meiner Beitraege ist die regelmaessige Wartung des Ironiedetektors unerlaesslich. |
|
| Nach oben |
|
|
kawe
Anmeldungsdatum: 25.03.2012
Beiträge: 41
|
| Verfasst am: 16.11.2012, 22:44 Titel: Re: virtuelle Funktionen in fb 0.24 |
|
|
| Flo hat Folgendes geschrieben: | | kawe hat Folgendes geschrieben: | Andere Sprachen wie C++ oder Java machen (zumindest für komplexe Typen) nicht ohne Grund die Speicherzuweisung nicht über die Deklaration sondern bei der Zuweisung anhand des wahren Typs der Instanz.
|
Nein: in beiden Sprachen weist du in Wirklichkeit Pointer/Referenzen zu, niemals (bzw in C++ selten) echte Objekte.
|
Na, habe ich doch gesagt: Nicht bei der Deklaration wird über den wahren Typ (und damit auch dessen Größe) entschieden, sondern bei der Instanziierung. Dass das bedeutet, dass solche Objekte über Referenzen angesprochen werden, egal ob man sie nun so nennt oder nicht, versteht sich von selbst - aber das war eigentlich gar nicht mein Thema. Java selbst zeigt ja deutlich, dass das eigentlich so gesehen gar kein Thema ist. Die Syntax des Zugriffs auf dynamisch erzeugte Variablen kann völlig transparent gestaltet werden. Der Unterschied liegt in Erzeugung, Initialisierung/Zuweisung und Entsorgung - nicht syntaktisch, sondern im Ablauf - und das (insbesondere Initialisierung und Zuweisung) hat mich die letzten Tage umgetrieben ...
Mir ging es eigentlich genau umgekehrt darum, dass das *DIM*en eigentlich wegen der Speicherzuweisung per Deklaration implizite Typkonvertierungen, auch und gerade von Unterklasseninstanzen, lieber verbieten sollte.
| Zitat: |
und wenn du in C++ folgendes tust:
Derived objekt(initialisierungs, daten);
Base foo = (Base)objekt;
dann wird objekt beschnitten, und du has genau dasselbe Problem wie in FB.
|
Oops, ja - aber ehrlicher wäre es für mich, den Code
| Code: | | Base foo = Derived(); |
heranzuziehen.
Du hast doch explizit gecastet ... aber mein Beispiel sieht für mich eher wie 'DIM as Base foo = Derived()' aus (siehe mein eigenes Beispiel von oben: 'Dim As Upper m => Middle() ') und lässt doch im C++-Fall die Derived-Instanz unversehrt, oder täusche ich mich da!?
Ich gebe zu, dass ich seit 10 Jahren nur noch sehr sporadisch auf C++-Pfaden bin,  .
Zuletzt bearbeitet von kawe am 16.11.2012, 23:57, insgesamt einmal bearbeitet |
|
| Nach oben |
|
|
kawe
Anmeldungsdatum: 25.03.2012
Beiträge: 41
|
| Verfasst am: 16.11.2012, 23:10 Titel: |
|
|
| MOD hat Folgendes geschrieben: |
Hier liegt das Problem, erst durch VIRTUAL bekommst du das Verhalten, das du hier möchtest. Das fällt dir in Java nicht auf, weil da alles virtuelle Methoden sind.
[...]
Lad dir doch mal die von mir verlinkte Vorabversion von 0.25 runter und probier es aus. |
Danke für den Link  , ich habe die Version gezogen und sie funzt bisher einwandfrei ....
Mein Beispielcode verhält sich exakt so wie in fb 0.24. Ich werde ihn auf "echte" virtuelle Methoden umstellen und berichten ...
Ich fühle mich allerdings ein wenig missverstanden,  . Ich habe kein Problem mit virtuellen Methoden, und mein Virtualisierungsbeispiel ist nicht anderes, als was nun der Compiler für mich tut. Zeiger auf Funktionen der Unterklasse an die Oberklasse zu übergeben ist schließlich auch in fb 0.24 nichts Verbotenes - setzt aber die Unversehrtheit der ganzen Instanz voraus, auch wenn die Variable deklarativ vom Oberklassentyp ist.
Mir ging es doch nur ums 'DIM'en   . Ich bin doch nur der Meinung, dass das 'DIM'en entweder den "Unterklassenteil" der Instanz (auch in fb 0.24!) erhalten - oder andernfalls die implizite(!) "Konvertierung" zur Oberklasse schlichtweg ablehnen sollte (s.o.), und das eben insbesondere im Hinblick des kommenden Polymorphismus.
... ich melde mich, wenn ich mein Beispiel umgestellt habe ... |
|
| Nach oben |
|
|
Flo
aka kleiner_hacker
Anmeldungsdatum: 23.06.2006
Beiträge: 1210
|
| Verfasst am: 17.11.2012, 04:23 Titel: Re: virtuelle Funktionen in fb 0.24 |
|
|
| kawe hat Folgendes geschrieben: |
Du hast doch explizit gecastet ... aber mein Beispiel sieht für mich eher wie 'DIM as Base foo = Derived()' aus (siehe mein eigenes Beispiel von oben: 'Dim As Upper m => Middle() ') und lässt doch im C++-Fall die Derived-Instanz unversehrt, oder täusche ich mich da!?
Ich gebe zu, dass ich seit 10 Jahren nur noch sehr sporadisch auf C++-Pfaden bin, . |
afaik täuschst du dich.
auch C++ verkrüppelt dir hier deine abgeleitete Klasse, wenn du sie in eine Base-variable zwingst.
du kannst polymorphie lediglich mit pointern machen, nie mir den direkten Klassen. Das scheitert schon daran, dass Base nicht weiß, wieviel Speicher sie für eventuelle Kindklassen bereithalten muss.
Aber eine Compilerwarnung a'la "hier wird jezt Derived verkrüppelt, das ist vermutlich nicht, was du willst!" wäre hilfreich.
_________________
MFG
Flo
Satoru Iwata: Wer Spaß am Spielen hat, fragt nicht nach Grafik.
zum korrekten Verstaendnis meiner Beitraege ist die regelmaessige Wartung des Ironiedetektors unerlaesslich. |
|
| Nach oben |
|
|
kawe
Anmeldungsdatum: 25.03.2012
Beiträge: 41
|
| Verfasst am: 18.11.2012, 14:10 Titel: |
|
|
| Zitat: | afaik täuschst du dich.
auch C++ verkrüppelt dir hier deine abgeleitete Klasse, wenn du sie in eine Base-variable zwingst. |
Ja, Du hast recht. Ich habe extra mal wieder ein paar Stunden C++ wiederholt und eigens seit Ewigkeiten einen C++-Compiler installiert,  .
Ergebnis: Das Instanziierungsverhalten von FreeBASIC enspricht bezüglich der diversen Constructor- und Destructoraufrufe exakt jenem von C++, soweit ich das nun beurteilen kann.
Da war ja meinerseits wirklich mal Wiederholungsbedarf zu diesem Thema angesagt.
Da genau das meine Annahme war (FreeBASIC weiche im Instanziierungsverhalten von Väterchen C++ ab), ist damit meinerseits jede Unklarheit beseitigt. Danke.
| Zitat: | | du kannst polymorphie lediglich mit pointern machen, nie mir den direkten Klassen. Das scheitert schon daran, dass Base nicht weiß, wieviel Speicher sie für eventuelle Kindklassen bereithalten muss. |
Ein keliner Rest Trotz bleibt an dieser Stelle aber dann doch noch.
Auch ein statisch instanziiertes Objekt könnte seinen Speicher (erst) anhand der Initialisierung (z. B. Variablen-Initiator) zugewiesen bekommen (die Zuweisung ist dafür natürlich zu spät). Es ist nicht so - basta - und so ist es für den Compiler einfacher (andernfalls müsste er sich ja für die Variable auch den zugewiesenen Typ z. B. für die Entsorgung merken) - ob das dann mehr Sinn macht? Aber hätte C++, dann hätte wohl auch FreeBASIC ...
Jedenfalls haben 10 Jahre Java, wo man bei diesen Fragen niemals in die Verlegenheit des Zweifels kommt (immer dynamisch, immer virtuell und (fast) nie an Objektentsorgung denken), tatsächlich bei mir deutliche Spuren des Vergessens zu diesen Thema hinterlassen.
Danke nochmal ... |
|
| Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
