!(B* -> A*)
-
anon4354645 schrieb:
Skym0sh0 schrieb:
doch das tust du, ansonsten würdest du eben nicht public erben wollen, denn genau das sagt öffentlich verbung ja aus -> is-a
Bitte ordentlich lesen. Ich habe Vererbung nicht mal erwähnt.
indirekt schon, denn die beschriebene Konvertierung gibt es nur bei public-Vererbung. Skym0sh0 weiß das. Du anscheinend nicht.
@nurf Dann habe ich das gleiche Problem wie vorher.
Nope.
class base{}; class A:public base{}; class B:public base{}; class public_derivation: public base{}; class protected_derivation: protected base{}; class private_derivation: private base{}; int main() { A *a; B *b; base *base_ptr; a = b; // Nö b = a; // Nö a = base_ptr; // Nö b = base_ptr; // Nö base_ptr = a; // Ja base_ptr = b; // Ja public_derivation *public_ptr; protected_derivation *protected_ptr; private_derivation *private_ptr; base_ptr = public_ptr; // Ja base_ptr = protected_ptr; // Nö base_ptr = private_ptr; // Nö }
-
SeppJ schrieb:
indirekt schon, denn die beschriebene Konvertierung gibt es nur bei public-Vererbung. Skym0sh0 weiß das. Du anscheinend nicht.
Also wenn ich nach etwas mit Eigenschaft A und B Frage und mit jemand etwas mit Eigenschaft A gibt, habe ich genau danach gefragt. Gut zu wissen. Logic(!)
SeppJ schrieb:
Nope.
Doch. B braucht so immer noch einen virtuellen Destruktor. (Den du irgendwie vergessen hast..)
Also noch mal: B soll sich verhalten wie eine eigene, normale Klasse. Ohne irgendwelche impliziten Konvertierungen oder sonst was. Es geht nur darum Tipparbeit zu sparen. Das ist das einzige was ich will. Es sollen keine tiefgründigen Abhängigkeiten modelliert werden.
-
anon4354645 schrieb:
Es geht nur darum Tipparbeit zu sparen.
Copy&Paste
Und das ist ernst gemeint.
-
Das Problem dabei ist halt, dass Änderungen sich nicht überall gleich auswirken.

Könnte man so etwas nicht mal in die Sprache bauen?
-
anon4354645 schrieb:
SeppJ schrieb:
indirekt schon, denn die beschriebene Konvertierung gibt es nur bei public-Vererbung. Skym0sh0 weiß das. Du anscheinend nicht.
Also wenn ich nach etwas mit Eigenschaft A und B Frage und mit jemand etwas mit Eigenschaft A gibt, habe ich genau danach gefragt. Gut zu wissen. Logic(!)
Falls das Ironie sein soll: Fail? Dein B (es gibt implizite Konvertierung) ist äquivalent zu A (public Vererbung wurde genutzt). Daher ist es vollkommen ausreichend, von A oder B zu sprechen.
SeppJ schrieb:
Nope.
Doch.
Ähh, nein? Zeile 16,17 in meinem Beispiel.
Virtueller Destruktor: Wenn du keine Pointerkonvertierungen haben willst, ist wohl davon auszugehen, dass niemals im Programm base* vorkommen werden. Selbst wenn: Dann mach eben einen virtuellen Destruktor. Was spricht dagegen? Dadurch werden A* und B* auch nicht kompatibel.
Also noch mal: B soll sich verhalten wie eine eigene, normale Klasse. Ohne irgendwelche impliziten Konvertierungen oder sonst was. Es geht nur darum Tipparbeit zu sparen. Das ist das einzige was ich will. Es sollen keine tiefgründigen Abhängigkeiten modelliert werden.
Und inwiefern wird dies nicht durch private-Vererbung, gemeinsame Basisklasse oder Komposition erfüllt? Irgendeine Art von Modellierungsabhängigkeit muss ja bestehen, sonst können die Klassen nicht den gleichen Code benutzen. Als kleinster Nenner muss also mindestens eine "ist in der gleichen Art implementiert"-Beziehung vorliegen.
-
SeppJ schrieb:
Falls das Ironie sein soll: Fail? Dein B (es gibt implizite Konvertierung) ist äquivalent zu A (public Vererbung wurde genutzt).
Nur so als Anmerkung: Er wollte doch gerade keine implizite Konvertierung?
-
anon4354645 schrieb:
Das Problem dabei ist halt, dass Änderungen sich nicht überall gleich auswirken.

Könnte man so etwas nicht mal in die Sprache bauen?Gleiches Interface für mehrere Klassen ist bereits eingebaut über Vererbung.
Du hast im Grunde nur 3 Möglichkeiten.
1. Du schaffst dir eine Basisklasse und erbst die anderen Klassen davon, die geerbten Klassen sind untereinander nicht kompatibel. Das ist die sichere und sauber Methode.
2. Du fängst an Macros zu bauen die die Funktion enthalten. Das würde erreichen was du willst. Ich würde dir aber davon abraten, da Macros fehleranfällig sind und der Code damit fehleranfällig wird.
3. Das von Shade vorgeschlagene Copy n Paste, da es sich ja um 2 vollkommen getrennte Klassen handeln soll.
-
Xebov schrieb:
1. Du schaffst dir eine Basisklasse und erbst die anderen Klassen davon, die geerbten Klassen sind untereinander nicht kompatibel. Das ist die sichere und sauber Methode.
2. Du fängst an Macros zu bauen die die Funktion enthalten. Das würde erreichen was du willst. Ich würde dir aber davon abraten, da Macros fehleranfällig sind und der Code damit fehleranfällig wird.
3. Das von Shade vorgeschlagene Copy n Paste, da es sich ja um 2 vollkommen getrennte Klassen handeln soll.
1. finde ich nicht so sauber. sauebr fände ichs, wenn man wirklich nur allen methoden gleiche namen gibt aber keinerlei beziehung zwischen den klassen hat. und das geht leider nur mit der guttenberg taktik
2. da stimme ich dir voll und ganz zu
3. und hier auch
-
anon4354645 schrieb:
Das Problem dabei ist halt, dass Änderungen sich nicht überall gleich auswirken.

Könnte man so etwas nicht mal in die Sprache bauen?Dein Problem ist nicht die Sprache, sondern deine Modellierung.
PS:
man kann sich Code automatisch generieren lassen wenn man wirklich zu tippfaul ist. Aber im ernst: tipparbeit beim Programmieren ist vielleicht 0,00000000000001% der Zeit. Also wayne?
-
klingt nach einem X/Y problem.
-
cooky451 schrieb:
SeppJ schrieb:
Falls das Ironie sein soll: Fail? Dein B (es gibt implizite Konvertierung) ist äquivalent zu A (public Vererbung wurde genutzt).
Nur so als Anmerkung: Er wollte doch gerade keine implizite Konvertierung?
Es ging darum, dass er gemeint hat, dass eine implizite Konvertierungsmöglichkeit zwischen Zeigern auf nutzerdefinierte Datentypen nicht äquivalent wäre zu einer public-Vererbungsbeziehung. Aber die Diskussion ist so langsam ziemlich meta, wie man an dieser einfachen
Zusammenfassung merkt.