- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- bitpork: MOD Júni 28- Augusztus 2- szombat jelen állás szerint.
- Magga: PLEX: multimédia az egész lakásban
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Android másképp: Lineage OS és társai
- Random25: Windows 11 telepítés Pendriveról
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
Új hozzászólás Aktív témák
-
dobragab
addikt
válasz
pvt.peter
#3696
üzenetére
Jól értem hogy az a
void*valami userdata, amit a callback regisztrálásánál megadhatsz, és amikor visszahívódik, akkor a callback megkapja? Mert akkor különböző callback-eket érdemes regisztrálni a különböző típusú user data-hoz.void A_callback(void * data)
{
A& a = *static_cast<A*>(data);
// ...
}
void B_callback(void * data)
{
B& b = *static_cast<B*>(data);
// ...
}
register_callback(A_callback, &a);
register_callback(B_callback, &b);Ha ez a helyzet, akkor még lehet rajta ezen túl is szépíteni, elsősorban annak függvényében, hogy a
// ...részeknek egymáshoz van-e bármi köze. Ha mégsem, légyszí mutass valami példakódot, akár mockolt osztálynevekkel. -
dabadab
titán
válasz
pvt.peter
#3692
üzenetére
"Tehát adott egy void* típusú pointer ami reprezentálhat több egymással semmilyen kapcsolatban nem álló típust ami szintén egymással semmilyen kapcsolatban nem álló interfész megvalósítása."
Hát, ez így első nekifutásra az "elbaszott design" c. kategóriába való, ezt szépen nem lehet megoldani.
-
EQMontoya
veterán
válasz
pvt.peter
#3692
üzenetére
Erre nincs szép megoldás.
Minden egyes alkalommal, amikor void*-ot castolsz valamire, egy éhező kisgyerek élve felfal egy kiscicát.
Ha egy függvény argumentuma void*, és az nem egy memóriakezelésért felelő függvény, akkor ott komoly tervezési hibák történtek. Minden egyes alkalommal, amikor egy ilyet lefordítasz, az univerzumban felsír egy feketelyuk és szegény Bjarne-nek kicsit szúrni kezd az oldala.
C++-ban void*-ot csak a gonosz azon teremtményei használnak, akik az ősi feketemágia (C) hívei továbbra is. Ha nem küzdünk ellenük, egyszercsak azt vesszük észre, hogy már nem tudjuk megállítani a világuralomra törésüket, és mindannyiunkat birkává fognak static_castolni. Ezt Te sem akarod, ugye?
-
Karma
félisten
-
ToMmY_hun
senior tag
válasz
pvt.peter
#3140
üzenetére
Nemrég én is feltettem ezt a kérdést, de nem kaptam rá választ.
Én Bjarne Stroustrup The C++ Programming Language 4th edition-t kezdtem el olvasni, eléggé frankó iromány. Kicsit száraz és nagy terjedelmű, cserébe alapos és a 11-es szabványnak megfelelő nyelvi elemeket használja. -
modder
aktív tag
válasz
pvt.peter
#2160
üzenetére
az eredeti példát kiegészítettem másoló konstruktorral:
http://pastebin.com/ryGfdzyzAmi egyébként ilyen egyszerű esetben nem szükséges, mert a nyelv csak byteról bytra lemásolja az eredeti objektumot inicializálásnál, tehát:
// copy konstruktor hívódik, amikor egy objektumot egy másik objektummal inicializálsz
Dog pajti2 = *makeDog();A nyelv átmásolja az egyenlőség jel jobb oldalán álló objektumot byteról byte-ra, vagy ha létezik, akkor a másoló konstruktor segítségével az egyenlőségjel bal oldalán lévő objektumba. Másoló konstruktor csak inicializálásnál hívódik meg, ami az új függvény deklarációja és egyből értékadás.
bővebben:
http://www.fredosaurus.com/notes-cpp/oop-condestructors/copyconstructors.html
(van példa kód, hogy mikor hívódik meg) -
modder
aktív tag
válasz
pvt.peter
#2074
üzenetére
Szia, Karmának igaza van mindkét esetben. A heap vagy stack nem befolyásol semmit a virtuális függvények terén, a new operátor pedig tényleg hibát dobna az első esetben. Javítva:
A b = B();
b.valami();
// most vonatkoztassunk el attól, hogy ugyanaz a változónév
B b = B();
b.valami()(már régen c++-tam)
-
-
modder
aktív tag
válasz
pvt.peter
#2057
üzenetére
Hali. Polimorfizmus (többalakúság, ugyanolyan ős típusú objektumok másképpen viselkedhetnek). Amikor több osztályod van, ami ugyanazokat a tulajdonságokat (metódusokat) definiálja, ezért közös ősből származik, de mégis minden osztály egy kicsit másképpen viselkedik, vagyis kicsit más az implementációjuk, viszont az interfészük (amit az osztály használója lát) megegyezik.
Most hirtelen a Java JDBC API jut eszembe:
//Create the connection using the static getConnection method
Connection con = DriverManager.getConnection (connectionURL);
//Create a Statement class to execute the SQL statement
Statement stmt = con.createStatement();Itt a DriverManager egy factory osztály, ami olyan Connection példányt ad vissza, ami adatbázis specifikus a szerint, hogy milyen adatbázis típus szerepel a connection URL-ben. A Connection csak egy interfész, minden konkrét adatbázis JDBC driver a sajátját specifikálja, és a konkrét, con változóhoz kötött példány lehet, hogy mondjuk MysqlConnection típus lesz. Itt a lényeg az, hogy a MysqlConnection a Connection-ből származik, és felülírja a Connection metódusait.
Ami fontos megjegyezni futás időben fog eldőlni, hogy melyik metódus fog meghívódni, mert fordításkor lehetetlen eldönteni a fenti kódrészletből, hogy a con változó konkrétan milyen osztály lesz.
C++-ban explicite ki kell írnod a virtual kulcsszót a függvény elé. Ha nem teszed ki, akkor is felülírhatod a metódust, de nem biztos, hogy azt az eredményt fogod kapni, amit vársz. Például
class A {
public:
void valami() { std::cout << "A"; }
virtual void virt() { std::cout << "A"; }
}
class B : A {
public:
void valami() { std::cout << "B"; }
void virt() { std::cout << "B"; }
}A b = new B();
b.valami(); // "A" fog kiíródni, mert valami() nem virtuális, tehát a változó "statikus" típusa alapján dől el, hogy melyik metódus fog meghívódni. A statikus típus pedig "A"B b = new B();
b.valami(); // itt a statikus típus "B", tehát "B" fog kiírodóni.Ezzel szemben
A b = new B();
b.virt(); // itt "B" fog kiíródni azért, mert a virt() függvény virtuális. futás időben a virtuális függvény táblából a program megnézi, hogy melyik konkrét függvény hívódjon meg. Mindezt a b változó futásidejű (dinamikus) típusa alapján, ami itt "B"Heterogén kollekciókban szokták hasznát venni, amikor (mint az első példában) egy közöt ős van, ami szolgáltatja az interfészt, de többféle implementációt tárolsz egy tömbben vagy listában. Amikor végigiterálsz rajtuk, hogy meghívd mindegyiken valamelyik metódusát, nem kell foglalkoznod a konkrét típussal, ami nagyban leegyszerűsíti a programozó munkáját. Ez annyira az általános elvárt működés, hogy Javában minden metódus virtuális. Ha nem akarod, hogy valamelyiket felül lehessen írni, akkor a final kulcsszót kell elé tenni.
Amikor egy osztályt kiterjeszthetőségre tervezel, ki kell választanod azokat a metódusait, amiket felül lehet majd írni, és virtuálissá teszed őket. Ezzel elég körültekintőnek kell lenned, mert egy felülírt virtuális metódus a származtatott osztályban el is ronthatja az alap működést.
-
mgoogyi
senior tag
válasz
pvt.peter
#2057
üzenetére
röviden:
polimorf osztályoknál van értelme, amikor specializálod a működését az ősosztálynak és minden leszármazottat kezelhetsz úgy, mint ha az egy ősosztálybeli objektum lenne.
pl. minden almát és körtét kezelhetsz gyümölcsként
pl. Akkor van ennek haszna, mikor van egy rakás valamilyen gyümölcsöd mondjuk egy halmazban és együtt akarod kezelni őket, mert pl. az adott helyzetben számodra nem lényeg, hogy milyen specializált gyümölcsről van szó.Amikor örökölsz, akkor a virtuális függvények mindig befigyelnek!
hosszan:
class Gyumolcs
{
...
virtual void print() {printf("gyumolcs")}
...
};
class Alma() : public Gyumolcs
{
...
virtual void print() {printf("alma")}
...
};
class Korte() : public Gyumolcs
{
...
virtual void print() {printf("korte")}
...
};
Gyumolcs * a = new Alma();
a->print(); //azt írja ki, hogy alma, pedig ez egy Gyumolcs pointer
/*mivel: a virtuális függvényeknél futási időben dől el (dinamikusan), hogy mi hívódik (megnézi, hogy valójában milyen objektumról van szó és annak a függvényét hívja - a háttérben egyébként van az objektumnak egy virtuális táblája és abból nézi ki, hogy mit kell hívni)
ha nem virtuális lenne a függvény, akkor fordítási időben (statikusan dőlne el, mit kell hívni és "gyumolcs" íródna ki)*/
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Kerékpárosok, bringások ide!
- One otthoni szolgáltatások (TV, internet, telefon)
- Bluetooth hangszórók
- Milyen TV-t vegyek?
- Víztisztító berendezések - kancsók - szűrőbetétek
- Budakeszi, Páty, Telki, Budajenő, Zsámbék, Tök, Perbál topik
- Autós topik
- Villanyszerelés
- BestBuy topik
- Gitáros topic
- További aktív témák...
- Uhh Lenovo ThinkPad P15 G2 Tervező Vágó Laptop -75% 15,6" i5-11500H 16/1TB RTX A2000 4GB /1 Millió/
- Esport PC - i5 13400F, GTX 1080ti és 16gb DDR5
- Ohh Lenovo ThinkPad P15 G2 Tervező Vágó Laptop -75% 15,6" i5-11500H 32/1TB RTX A2000 4GB /1 Millió/
- AZTA! HP EliteBook 840 G8 Fémházas Laptop Ultrabook 14" -60% i7-1185G7 16/512 FHD IPS Iris Xe
- Sony PlayStation 5 (PS5) Játékkonzol - Lemezes verzió, dobozában!
- Bomba ár! Dell Latitude E6400 - Intel P8400 I 3GB I 160GB I 14,1" I Intel VGA I Garancia!
- Csere-Beszámítás! Számítógép PC Játékra! Intel I7 6700/ RX 580 8GB / 32GB DDR4 / 500GB SSD
- BANKMENTES részletfizetés Noblechairs HERO RL valódi bőr Gamer Szék
- BESZÁMÍTÁS! ASUS B450 R7 1700X 16GB DDR4 512GB SSD RX 580 8GB Rampage SHIVA Corsair 450W
- BESZÁMÍTÁS! Intel Core i7 4790 4 mag 8 szál processzor garanciával hibátlan működéssel
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest