Fórumok
Hi,
lenne egy osztaly melynek van egy fv.re mutato pointere:
class A
{
public:
typedef void (*callfv)();
callfv fv;
A(callfv f)
{
this->fv = f;
}
};
es egy masik osztaly ahol peldanyositjuk az "A" osztalyt:
class B
{
public:
B()
{
A a = new A(valami);
}
void valami();
};
"A" osztalynal definialt fuggvenyre mutato pointernek szeretnem adni "B" osztaly fuggvenyet. Ha a fv. static akkor mukodik is, de ha az osztaly tagfv.je akkor nem.
megoldhato ez valahogy ?
elore is koszi
zsomi
Hozzászólások
Erre találták ki a tisztán virtuális osztályokat.
Esetleg használhatsz típusbiztos callback sablonokat valamelyik library-ból (gtkmm, sigc++, ultimate++, stb.) vagy használhatod a Qt előfordítós gányolását.
koszi a sigc++ tetszik, de megertenem a dolgot, igy a tisztan virtualis osztalyokrol vagy a problemarol nem kuldenel valami doksit, vagy nem irnad ide ha nem tul hosszu az ok.
szép napokat
zsömi
http://en.wikipedia.org/wiki/Virtual_function
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
Nonstatic member fv implicit kapja az objektum pointeret az elso parameterkent (amire kesobb this-kent hivatkozol), szoval nem kompatibilis a ket deklaracio.
A nem static member function re mutato pointer egy kulon allatfaj, a pontos használatát most nem tudom felidézni,de a Mester konyveben (Stroustrup) benne van:
15.5 Pointers to Members
Talán ez a fejezet tárgyalja.
Konkrétan ez a rész lehet Neked érdekes:
typedef void (Std_interface::* Pstd_mem) (); // pointer to member type
void f(Std_interface* p)
{
Pstd_mem s = &Std_interface::suspend;
p->suspend(); // direct call
(p->*s)(); // call through pointer to member
}
Itt van minden mit tudni akarsz a fv pointerekről, meg az is amit nem...
http://www.parashift.com/c++-faq-lite/pointers-to-members.html
(Az itt látható virtualis-fv-es megoldás _nem_ az amire zsolt gondolt...)
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
thx
szép napokat
zsömi
Gyakran visszatérő kérdés ez: Hogyan lehet a callback fv egy osztály metódusa?
Lehet, csak kell neki egy további paraméter, ami a példány címét fogja tartalmazni.
Az egyszerűség kedvéért gányoltam egy példát, van benne három változat: C-ben egyszerű paraméter, C-ben struktúra-paraméter, és C++-osztály, neked az utolsó kell, gondolom.
http://web.axelero.hu/lzsiga/cback.cc
Thx,
kozben en is megoldottam, es igazabol a problemam oka teljesen mas, volt csak rosszul kozelitettem meg eloszor.
A te kododbol ezt a reszt akartam altalanositani:
void cbmetod (int par)
{
printf ("callback-metódus vagyok, member=%d, par=%d\n",
member, par);
}
static void cbstatic (int par, intptr_t cbp)
{
((cbclass *)cbp)->cbmetod (par);
}
megpedig azert, mert elkezdtem gtk-val foglalkozni, es a gtkmm-t szidtak (bugos, meg ...). Igy a c++ projektre szerettem volna ha egy osztalyon belul csak egy static altalanos fv.-m van es azt hivja mindenki es az automatikusan meghivja az osztaly tagfuggvenyet. No sikerult megoldani, ugy, hogy egy struct-ba beletettem az osztaly meghivando tagfuggvenyet meg az osztalyt magat, plussz meg egy (void*) vagy itt gpointer valtozot, ami majd talan jo lesz valamire :)
igy ma este mar csak egy altalanos BaseGtkForm.h (template) lesz belole amit szarmaztatok es egyszerusodik az eletem.
ha gondolod, vagy gondolja valaki belinkelem az elkeszult fajlt.
nem tudom ertheto voltam e?
szép napokat
zsömi
A gtkmm-et nem tudom ki szídta neked, amikor én használtam teljesen jó volt. Egy-két dolog volt ami nem tűnt logikusnak, de mivel pont előtte a Gimp forrásában kellett turkálnom valamiért, azt biztosan tudtam, hogy a Gtk+-nál 100x kényelmesebb...
Szerintem feleslegesen kezdesz C++ wrappert írni saját magad, biztosan nem lesz olyan kényelmes mint a gtkmm, és tuti több lesz benne a bug. :)
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
Egyetertek, nem akarok wrappert irni, csak magamnak egy ket alap osztalyt. Nagyon kis gtk-s progikat tervezek irni es azokhoz a nyelv gyakorlasa miatt jobb ha ezeket en irom meg.
szép napokat
zsömi
Pl. a rosegarden szerzője szídja:
http://www.telegraph-road.org/writings/gtkmm_vs_qt.html
Ez nekem elég volt, hogy ne kezdjem el megtanulni a gtk-t :-)
Lehet, hogy tévedés volt részemről.
este elolvasom, bar nekem tetszik a gtk. Igaz meg csak ismerkedunk.
szép napokat
zsömi
Óóó, hát én soha nem ajánlanám a gtkmm-et a Qt ellenében...
Én csak azt mondtam, hogy ha valaki C++-ban programozik, és Gtk-s szoftvert akar fejleszteni, akkor inkább gtkmm-et használjon, mint sima gtk-t.
Ha elég a Gtk look-and-feel, akkor a statikusan fordított Qt-t ajánlanám a legújabb QGTKStyle-lal, senki nem fogja észrevenni a különbséget.
Ha csak simán C++, és GUI, akkor is Qt...
Persze Qt alatt szigorúan a Qt4-re gondolok...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
A Gtk C apija szamomra is horror, de ruby-n keresztul egesz szeretheto tudna lenni, ha lenne idom ra.
--