Új hozzászólás Aktív témák

• #4342 jattila48 aktív tag MageRG #4341

  Új Válasz 2022-01-18 20:09:40 #4342

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  jattila48

  aktív tag

  válasz MageRG #4341 üzenetére

  Általános "szabály" (inkább javaslat):
  Az ős osztály destruktora publikus és virtuális,
  vagy protected és nem virtuális.

  Nálad az első eset érvényes, mert polimorf módon használod az osztályt.

• #4337 doc nagyúr MageRG #4335

  Új Válasz 2022-01-17 17:26:47 #4337

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  doc

  nagyúr

  válasz MageRG #4335 üzenetére

  attol fugg hogy mi van a 'kikommentelt' reszben
  Alapesetben igen, az ososztaly pointeren keresztul delete-elve csak azt szabaditja fel a fordito, ami az ososztalyban van. Ezert kell virtualis desktruktort hasznalni, igy a leszarmazott destruktora is lefut.

• #4336 dabadab titán MageRG #4335

  Új Válasz 2022-01-17 17:26:25 #4336

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dabadab

  titán

  válasz MageRG #4335 üzenetére

  Delete esetén ha a statikus (az első példában Base, a másodikban void) és a dinamikus (Derived) típus különbözik, akkor a dinamikus típusnak a statikus leszármazottjának kell lennie ÉS a statikus típus destruktorának virtuálisnak kell lennie, máskülönben undefined behaviour.

  Szóval mindkét példa definiáltlan működés, saccra a gyakorlatban annyi történik, hogy az első példában meghívódik a Base destruktora (így a Derived saját dolgai felszabadítatlanul maradnak), a második példában meg csak egy free() a pointerrel.

• #3186 jattila48 aktív tag MageRG #3185

  Új Válasz 2016-02-24 11:35:36 #3186

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  jattila48

  aktív tag

  válasz MageRG #3185 üzenetére

  Attól tartok, nem egészen érted miről van szó. A member pointerek nem függenek egyetlen példánytól sem, hanem az osztály (nem az objektum!) tagjaira hivatkozó fordítás idejű konstansok. Úgy kell elképzelni, mint offset-et, ami az osztály kezdetéhez képest mutatja az adott tag helyét az osztályban. Pl. struct semmi{int a; int b;} osztályban a semmi::* pa=&semmi::a és semmi::* pb=&semmi::b deklarációkkal a pa=0 és pb=4 konstans értékeket vesz fel (feltehetőleg), mivel az a tag offsetje az osztályhoz lépest 0, a b-é pedig 4 (ha az a mérete 4 byte volt). Ugyanígy (nem virtuális) tfv.-ekre is, csak ekkor nem az offset, hanem a tfv. címe mint fordítás idejű konstans kerül a member function pointerbe. A HandleClass::mfp nálam ilyen member function pointer, ami történetesen a BodyClass::f tfv.-ének címét tartalmazza (és ez független a BodyClass bármely példányától, egy közönséges fv. cím). Ezért, mivel nem függ sem a HandleClass, sem a BodyClass egyetlen példányától sem, nyugodtan lehet statikus, hiszen minden példányban ugyanaz a konstans érték. Amikor (pimpl->*hc.mfp)(2); formában hívom a BodyClass f tfv.-ét, akkor ez nem azt jelenti, hogy az mpf a pimpl által mutatott objektum tagja lenne (mint ahogy a ->* miatt első ránézésre tűnik), hanem a BodyClass::f tfv. kapja a pimpl-et első paraméterként, 2-őt második paraméterként, (mint ahogy a tfv.-ek első paramétere mindig az aktuális példányra mutató this pointer), az mpf pedig történetesen a hc statikus tagja. Egyébként ahogy írtam, ha az mpf-et const-ként deklarálom akkor működik, különben pedig futási hibával elszáll. A VS kever valamit, mert a gcc jól fordítja. A VS is lefordítja, csak szerintem rosszul.

Új hozzászólás Aktív témák