brauche hilfe bei (klasseA**)klasseB**
-
also, um es deutlich zu machen:
class TypA; class TypB; // class TypB : public TypA !!! class KlasseA { ... void funktion(TypA** foo); } class KlasseB : public KlasseA { ... void funktion(TypB** foo); } ################################################### void KlasseB::funktion(TypB** foo) { KlasseA::funktion((TypA**)foo); <<<<<<<<<<<<<<<<<<< }
diese umständliche konvertierung lässt sich leider nicht vermeiden, allerdings meckert der compiler an dieser stelle nicht, obwohl an der stelle im programm datenverlust eintritt.
habe zu lange kein c++ buch mehr in den händen gehalten. hoffe ihr könnt mir schnell helfen! BITTE!!!
-
Wo ist denn die Frage?
Wenn TypB von TypA erbt, dann ist ein TypB auch ein TypA. Du brauchst an der Stelle also nicht einmal casten.. Da es sich nur um Zeiger handelt tritt auch kein Datenverlust ein, du kannst in KlasseA::funktion bloß nicht auf die Member zugreifen, die TypB hat, TypA aber nicht.
-
Lideric schrieb:
Du brauchst an der Stelle also nicht einmal casten.
Da irrst du dich. Ein Zeiger auf B kann zwar implizit in ein Zeiger auf A konvertiert werden, aber ein B** nicht in ein A**.
hoffe ihr könnt mir schnell helfen! BITTE!!!
Mir ist nicht klar, was du eigentlich erreichen willst. A** und B** sind nicht verwandt.
-
HumeSikkins schrieb:
Mir ist nicht klar, was du eigentlich erreichen willst. A** und B** sind nicht verwandt.
gibt es da wirklich keinerlei beziehung trotz der vererbung (class TypB : public TypA)?
es ist mir schon klar, dass nach den standart vererbungsregeln TypB auch TypA ist. wie kann ich denn zeiger auf TypB in zeiger auf TypA umwandeln...
ahaaa, ich glaube ich merke gerade, dass ich einen logischen fehler gemacht habe. zeiger von einem typ kann man ja nich konvertieren. ein zeiger ist ein zeiger.
hm. trotzdem ein aber. hoffe ihr versteht was ich vorhabe und mir kann vielleicht jemand sagen, wie ich diesen fehler umgehen kann.
-
alex-t schrieb:
HumeSikkins schrieb:
Mir ist nicht klar, was du eigentlich erreichen willst. A** und B** sind nicht verwandt.
gibt es da wirklich keinerlei beziehung trotz der vererbung (class TypB : public TypA)?
Zum Glück nicht.
Ansonsten wäre sowas möglich:// Annahme: B ist Basisklasse. D1 und D2 erben jeweils von B D1 d1; // wir haben ein D1-Objekt... D1* pD1 = &d1; // ...und einen Pointer darauf B** p = &pD1 // Zum Glück nicht erlaubt. Aber was wäre wenn? D2* pD2; // pD2 ist ein Pointer auf D2 und völlig inkompatibel mit D1! B** p2 = &pD2 // Zum Glück nicht erlaubt. Aber was wäre wenn? *p2 = *p; // BUM! Auf einmal zeigt ein D2-Pointer (pD2) auf ein D1-Objekt!
Lustig wäre das z.B. in Verbindung mit Arrays.
void add(B* arr[5], int i, B* e) { arr[i] = e; } int main() { D1 d1; D2 d2; B* arr[5]; // OK. Alles fein. add(arr, 0, &d1); add(arr, 1, &d2); // Jetzt wird's kritisch D1* kabumArray[5]; // Man stelle sich vor D1** und B** wären kompatibel // Whups! add(kabumArray, 0, &d2); // -> add((B**)kabumArray, 0, &d2); // Whups! Wir rufen die Funktion funcFromD1 auf einem D2-Objekt auf kabumArray[0]->funcFromD1(); }
hoffe ihr versteht was ich vorhabe und mir kann vielleicht jemand sagen, wie ich diesen fehler umgehen kann
Ich glaube du solltest nicht versuchen die Fehlermeldung zu umgehen sondern dein Design zu verbessern.
-
HumeSikkins schrieb:
Ich glaube du solltest nicht versuchen die Fehlermeldung zu umgehen sondern dein Design zu verbessern.
hatte mich etwas undeutlich ausgedrückt. mit umgehen meinte ich nicht diesen fehler beseitigen. habe schon eingesehen, dass ich da von anfang an einen riesigen denkfehler gemacht habe. das ist eigentlich auch mir schon klar, dass es kompletter unfug war.
mit dem umgehen wollte ich ausdrücken, dass ich eine andere lösung, also ein redesign suche. und HumeSikkins, denke du hast schon verstanden worum es mir geht, und ich glaube ich verstehe langsam was ich noch alles machen muss, damit ich ans ziel komme.
also, um mal am anfang anzufangen:
mir liegt vor, eine wrapper klasse(n sammlung) für eine datenbankschnittstelle.
die db-api ist in c. funktional, aber nicht komfortabel.
die wrapper klasse, sehr schön! schönes stück arbeit. erweitert die api und ist in meinen augen eine höhere schicht.
da es aber noch höher gehen kann, meiner bescheidenen meinung, will ich diese wrapper klasse nochmal wrappen.
macht in meinen augen auch sinn, weil ich diese oberste schicht systemabhängig machen möchte und dann auch gleichzeitig in einer bibliothek kapseln möchte. somit würde ich dann nur die oberste schicht an ein neues system anpassen und hätte eine lösung für eine weitere platform.zu meiner wrapper klasse kommen dann noch funktionalitäten wie z.b. ein dateilogger.
deswegen möchte ich auch eine api einfügen die zwar stark von der ersten wrapperklasse abhängig ist, die intern allerdings erweitert ist.meine erste idee, und ich muss zugeben, ich habe da nicht sehr lange drüber nachgedacht, war: die vorhandenen klassen, die die datenbank, datensätze, und spalten repräsentieren abzuleiten. die methoden der unterklassen überschreiben und dort die methoden der oberklasse aufrufen, und dort eben den logger und später weitere funktionalitäten einbinden, der benutzer würde davon nichts merken, es würde einiges automatisch ablaufen und die typkonvertierung zu den platform-freundlichen typen würde dort auch stattfinden.
leider habe ich mich da etwas zu früh gefreut. die datenbank klasse zu wrappen war gar kein problem und war selbst mit den exceptions nach 15 minuten fertig, aber die datensätze und die spalten sind so programmiert, dass sie zwar technisch 1a sind und von der performance unschlagbar, aber für mich eben nicht zu wrappen, so wie ich gerne würde.
das zauberwort gegen meine idee heisst: zeiger.
es ist klar, dass zeiger manchmal so übergeben werden Column *pColumn. und datensätze werden auch noch so übergeben Dataset** ppDataset.
und wenn ich die klassen Column, und Dataset auch noch ableite, dann kann ich das ja nicht in den unterklassen für die aufrufe der methoden der oberklasse konvertieren, da es ja zeiger und keine objekte sind!jetzt ist mir das klar...
ich hoffe ich habe niemandem kopfschmerzen bereitet.
aber falls jemandem ein design tipp einfällt, würde ich mich darüber sehr freuen.ich denke, es bleibt mir aber nichts anderes übrig, als die klasse nachzubauen. informatik unterricht: aus ist-beziehung eine hat-beziehung machen