Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

$nooc

Alter Hase

  • »$nooc« ist der Autor dieses Themas

Beiträge: 873

Wohnort: Österreich / Kärnten

Beruf: Schüler

  • Private Nachricht senden

1

29.01.2007, 13:08

Vererbung

aaaalso..

gurke hat mir den tipp gegeben als übung zu OOP ein inventar zu programmieren. mein ansatz lautet wie folgt:

inventar ist eine klasse
verkettete liste ist eine klasse
item ist eine klasse

das inventar erbt die public funktionen der klasse verkettete liste
verkettete liste erbt public von klasse item

naja.. hab schon ein paar sachen geschrieben, spielt jetzt keine rolle, auf jeden fall scheine ich da ein problem mit der vererbung zu haben!

schreibe ich für das inventar einen eigenen constructor, dann schreit mein compiler:

Zitat von »"Compiler"«


Fehler 1 error C2512: 'CChainedList': Kein geeigneter Standardkonstruktor verfügbar


inventar erbt public von CChainedList (also die verkettete liste)...
die liste hat ihren eigenen constructor.. den brauch ich damit die einen wert bekommt, der die größe des inventars angibt..

weiß jemand was ich da falsch mache?
soll ich code posten, oder gehts so..?

ein kurzer ausschnitt:

C-/C++-Quelltext

1
2
3
4
5
CInventory::CInventory(const unsigned long Size)
{
                // Hier soll der fehler sein .. O_o

    m_InvSize = static_cast<unsigned long>(Size);
}


aja wenn ich schon da bin:
we ihr seht caste ich die variable Size .. aber ich weiß jetzt nicht.. ist das nötig? m_InvSize ist "unsigned long" .. Size ist "const unsigned long".. sollte das gecastet werden? oder ist das s**eiss egal? ^^
Am Anfang der Weisheit steht die eigene Erkenntnis, dass man selbst nichts weiß! - Sokrates

David_pb

Community-Fossil

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

2

29.01.2007, 13:38

Du musst den Konstruktor der Klasse CChainedList aus CInventory() aufrufen. Ansonsten versucht der Compiler den Standardkonstruktor zu verwenden.

Zitat von »"$nooc"«


we ihr seht caste ich die variable Size .. aber ich weiß jetzt nicht.. ist das nötig? m_InvSize ist "unsigned long" .. Size ist "const unsigned long".. sollte das gecastet werden? oder ist das s**eiss egal? ^^


Is egal in dem Fall.

grüße
@D13_Dreinig

Das Gurke

Community-Fossil

Beiträge: 1 996

Wohnort: Pinneberg

Beruf: Schüler

  • Private Nachricht senden

3

29.01.2007, 13:50

Warum erbt denn das Inventar von der Liste? Persönlich würde ich die Liste einfach als ein Member der Klasse anlegen, weil sie kein Element darstellt, auf welches man häufig von aussen zugreifen muss.

$nooc

Alter Hase

  • »$nooc« ist der Autor dieses Themas

Beiträge: 873

Wohnort: Österreich / Kärnten

Beruf: Schüler

  • Private Nachricht senden

4

29.01.2007, 13:54

wie meinst du das?
also den constr. von CChainedList aus CInventory() aufrufen? O_o

wie sieht das aus? ^^
Am Anfang der Weisheit steht die eigene Erkenntnis, dass man selbst nichts weiß! - Sokrates

David_pb

Community-Fossil

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

5

29.01.2007, 13:55

Zitat von »"$nooc"«

wie meinst du das?
also den constr. von CChainedList aus CInventory() aufrufen? O_o

wie sieht das aus? ^^


C-/C++-Quelltext

1
2
3
4
5
6
CInventory::CInventory(const unsigned long Size) 
: CChainedList( xyz )
 { 
                 // Hier soll der fehler sein .. O_o 

     m_InvSize = static_cast<unsigned long>(Size); 
 }


Statt xyz halt die entsprechenden Parameter.
@D13_Dreinig

$nooc

Alter Hase

  • »$nooc« ist der Autor dieses Themas

Beiträge: 873

Wohnort: Österreich / Kärnten

Beruf: Schüler

  • Private Nachricht senden

6

29.01.2007, 13:56

oho danke dir :) es funzt!

@ gurke:
ähm naja.. ich dachte mir .. eine verkette liste ist ja eig. ein objekt für sich... und da ein inventar ja sowas wie eine liste braucht.. ist es vielleicht nicht schlecht wenn das inventar die funktionen der klasse CChainedList erbt, damit es dann die verschiedenen objekte verwalten kann..

also so hätte ich mir das gedacht.. ^^
Am Anfang der Weisheit steht die eigene Erkenntnis, dass man selbst nichts weiß! - Sokrates

Das Gurke

Community-Fossil

Beiträge: 1 996

Wohnort: Pinneberg

Beruf: Schüler

  • Private Nachricht senden

7

29.01.2007, 14:12

Damit hast du auch Recht ;) Nur ist die verkettete Liste etwas technisches. Nach Möglichkeit möchtest du mit OOP sozusagen "sprechenden" Code erreichen. Klar könnte der Benutzer die geerbte Methode push_back aufrufen, aber das widerspricht imho ein wenig der Grundidee von OOP (abgesehen davon das evtl mehr als diese Aktion nötig sind).

Besser wäre es doch eine addItem Methode zum implementieren. Diese übernimmt ein Item, fügt es in die Liste und macht noch was (einen Sound abspielen / Geld ändern / Textbox / Event feuern ...).

Um es kurz zu machen: Es gibt (imho) keinen Grund die ganze Liste nach aussen sichtbar zu machen ;)

Oder willst du das Inventarobjelt irgendwo als Listenobjekt "behandeln"? Sollte das der Fall sein macht dein Ansatz Sinn, auch wenn ich den Grund dafür nicht ganz verstehe *g*

Edit: Ich skizziere mal eben einen Ansatz, den ich nehmen würde ...

Ein Inventarobjekt hält eine unbestimmte Anzahl an Gegenständen. Beide Klassen würde ich als Vorlage nehmen, sie also rein abstrakt implementieren. Damit kannst du beliebige Gegenstände und auch Inventarobjekte erstellen (vllt für Sortierfunktionen oder dergleichen).

Die Inventory Klasse hält einen Vector (der wahlfreie Zugriff ist doch praktisch) oder eine Multimap (ist vllt etwas komfortabler als der Vektor) in welchem die virtuellen Items gelagert werden.

Bisher also:
Basisklasse Klasse virtInventory
Basisklasse Klasse virtItem

Auf Basis dieser Klassen implementierst du dann "mal eben" zwei "funktionierende". Einfach von diesen ableiten.

Nun könnte es ja passieren, dass man mehr als einen "Inventarbeutel" haben möchte. Folglich würde ich mir einen Inventorymanager schreiben. Dieser hält eine Liste / Vector / Map mit virtInventory Objekten.

Dieser Klasse würde ich dann auch Methoden zum Auslesen aller Gegenstände aus allen Inventaren mitgeben. Desweiteren würde ich noch einige komfortable addItem Funktionen integrieren, so dass der Endanwender nur in "speziellen" Fällen direkt mit einem Inventory Item interagieren muss. Der Manager übernimmt also reine Wrapperfunktionen (und kann daher imho auch ruhig Singleton sein).

$nooc

Alter Hase

  • »$nooc« ist der Autor dieses Themas

Beiträge: 873

Wohnort: Österreich / Kärnten

Beruf: Schüler

  • Private Nachricht senden

8

29.01.2007, 14:20

so ganz hab ich das jetzt nicht verstanden muss ich zugeben...

aber.. die liste ist ja nicht nach außen hin sichtbar..
nach außen hin sind nur die methoden AddItem(), RemoveItem()..
der rest.. also strukturen etc. ist alles private.

aber wie soll ich das sonst machen? sollen diese methoden member funktionen von der klasse CInventory werden? jetzt bin ich etwas ratlos um ehrlich zu sein ^^

*edit:

da fällt mir gerade wieder ein grund ein warum die liste ein eig. objekt ist...
ich dachte mir.. wenn ich dann ein objekt habe.. ein item .. zum beispiel wie du gesagt hast einen beutel der nur edelsteine beinhalten kann oder sagen wir der beutel kann x-verschiedene items tragen ... dann brauch ich ja für dieses item (den beutel) wieder sowas wie eine verkette liste... und naja.. dann kann die klasse "Beutel" halt wieder von CInventory() erben..
Am Anfang der Weisheit steht die eigene Erkenntnis, dass man selbst nichts weiß! - Sokrates

Das Gurke

Community-Fossil

Beiträge: 1 996

Wohnort: Pinneberg

Beruf: Schüler

  • Private Nachricht senden

9

29.01.2007, 14:28

Siehe mein Edit, da steht mein Ansatz ;)

Hmm, aber sicher ist sie nach aussen hin "sichtbar" sie ist bloss nicht public ;) Wirf mal Intellisense an, das wird dir auch die vererbten Member der Liste mit anzeigen.

Das du die Liste BRAUCHST ist korrekt, nur warum erbst du von ihr? Mach sie einfach als Member und wrappe die Zugriffe die du nach aussenhin brauchst.

Edit: Das oben im Edit sollte EINEN Ansatz heissen, nicht meinen :oops: Es gibt sicherlich mehr und vllt auch besseren als diesen. Ich bin damit aber gerade sehr glücklich und nutze ihn auch produktiv =)

$nooc

Alter Hase

  • »$nooc« ist der Autor dieses Themas

Beiträge: 873

Wohnort: Österreich / Kärnten

Beruf: Schüler

  • Private Nachricht senden

10

29.01.2007, 14:41

puh.. das klingt ganz schön heftig! aber ich werde es versuchen ;)
aber wrappen ist mir jetz nicht wirklich ein begriff ^^

edit:
aja und.. "abstrakte klasse implementieren" sagt mir jetzt leider auch nichts :D
Am Anfang der Weisheit steht die eigene Erkenntnis, dass man selbst nichts weiß! - Sokrates

Werbeanzeige