- This topic has 119 hozzászólás, 19 résztvevő, and was last updated 19 years, 2 months telt el by
.
-
Bejegyzés
-
vizsla wrote:Ahol egyébként nem változik meg az érték, mint jelen esetben ==, meg egyéb összehasonlító operátoroknak a *this -t kellene visszaadniuk? Mert ez nem így van…
Az összehasonlító operátoroknak bool-t szokás megadni visszatérési értéknek.
(Még soha nem próbáltam ki, de szvsz bármelyik operátornak megadhatsz bármilyen visszatérési értéket, max. nem fogod tudni annyira kényelmesen használni.)Abban viszont igazad van, hogy az ilyen operátorokat érdemes tagfüggvényként definiálni.
Akkor szokás friend-ként, amikor egymás után akarjuk láncolni az operátorokat. (mivel ha tagfüggvény az operátor, akkor annak az objektumnak _meg kell elõznie_ a kódban, aminek õ a tagfüggvénye.
Pl. ha egy << operátort tagfüggvényként definiálnánk, akkor így kellene használni:Code:endlesss_object >> cout;Ami elég zavaró a kód újraolvasásánál.
Ezért kell friendként definiálni!
Ja, és még1 dolog: a „friend” szónak csak az osztályon belüli prototípus elõtt kell szerepelnie… 🙂 Szal a függvény definíciójában nem. 🙂kl223
Na most itt a gond! Van egy „endless”-ed az kiértékelõdik lesz egy „int” típusod a jobb oldalon a bal oldal viszont !!!soha!!! nem vár „int” típust!
Eddig világos, hogy van egy endlessem a jobb oldalon…
és az int ként értékelõdik ki.
// itt arra gondolsz, hogy a fordító vizsgálja, hogy volt e megfelelõ paraméter ha igen 1, ha nem 0 ????Illetve ha jól értem az a probléma, hogy a másik oldalon meg nem int van? hanem endless?
Azt viszont már nem teljesen értem, hogy mit csináljak, ha egyszer nekem egy endless kellene oda, mert két endless tipus között akarok relációt vizsgálni… Valahogy kasztolni kellene hogy az is int legyen??? De mivel az adattag string tipusu az elég nehéz lessz.
Továbbá amit nagyon nem értek… Hogy a == és a != operátorokkal miért nem volt semmi probléma???
googlie el kerestem már jó sokat, meg olvasgattam is, de csak olyan példát találtam, ahol a ‘<' operátort "halmaz eleme" -ként használják.
vizsla wrote:Ahol egyébként nem változik meg az érték, mint jelen esetben ==, < stb. tagfüggvényként javaslom deklarálásra, egyébként a visszatérésként pedig az objektumok címének megadását, mert ugye, ahogy említettem a jobb oldal visszatérési értéke a bal oldal paramétereként beíródik... innentõl nem kell magyarázni. :)
De hát az == vel semmi gond nem volt… Ahogy a != vel sem… Simán ment friend ként, bool tipust visszaadva.
kl223 al egyetértve szerintem könnyebben olvaható a kód friend ként.Meg az is elég magas, hogy hogyan térjek vissza objektumok címével… Visszatérési értékként max 1 objektum címét tudnám visszaadni.
De ami még magasabb, hogy mit kezdjek egy vagy akár két objektum címével, amikor nekem egy bool típusú visszatérési érték kellene de nagyon…
Ez megint :”jobb oldal visszatérési értéke a bal oldal paramétereként beíródik… „
Amit fentebb irtál „bal_endless ( ( int ) jobb_endless ( ) )” abból trivi a dolog,
de az nem trivi, hogy ez nekem miért kell???„Ha jól értelek, azt mondod, hogy az operator== meg operator> meg egyéb összehasonlító operátoroknak a *this -t kellene visszaadniuk? Mert ez nem így van…”
Nem! Azt mondom, hogy hogy ezek legyenek tagok, barátok helyett…
A másik gondolat az volt, hogy objektum, helyett meg az objektumok címét ajánlatos átadni, mert a jobbérték átmásolódik a balértébe.„Az összehasonlító operátoroknak bool-t szokás megadni visszatérési értéknek.”
Akarod mondani int, mert a bool csak „képzeletbeli” :). Egyénként teljesen mindegy. Nem az a lényeg, az operátor egy „közönséges” függvény (mûvelet), mindegy min végzed… ami esetleg elõfordulhat a kétértelmûség: pl egy int-int, meg egy cím-cím között, ha az egyik tag egy int. Ez utóbbi esetben a fordító nem tudja eldönteni, hogy az int obj. ill. más obj címét szeretnéd, vagy az int-et az obj. címével kapcsolatba hozni.„Akkor szokás friend-ként, amikor egymás után akarjuk láncolni az operátorokat.”
Akkor kell, amikor a balérték nem (tag) konstruktor pl.Code:class Class {
friend XY””Class”” operatorX ( XY””Class””, XY””Class””) //”” az = kisebb-nagyobb jel
}Ebben az esetben konverciós hiba lépne fel… mindenféleképpen, hiszen egyik paraméter sem lehet Class.
Láncolni lehet…, amit te mondasz azt nem, mert a balértéknek nem tag… bár ezt a típust meg lehet úgy is csinálni… ellenben ha az XY pl. csak egy referencia pointer függvény, akkor megnézném az a trágyát, amit lehetne vele kezdeni… hisz épp a lényegét kellene elveszteni, ha meg lehet csinálni egyátalán.„Szal a függvény definíciójában nem.”
Mivel az osztály barátja… és nem a „senkié”. :)))„Illetve ha jól értem az a probléma, hogy a másik oldalon meg nem int van? hanem endless?”
Nem az a baj, hogy nincsen feldolgozó függvényed (bal oldal). Ezért írja ki azt, hogy nem jó paraméter… mert nincs ilyen lehetõség.Na az egyik fordito ezt megeszi
friend int operator<(const int e, const endless &a );
Ami ugye „halmaz eleme” operátorként funkcionál.
De érdekes módon a gcc még ezt sem eszi meg…. Pedig nagyon meg kellene mert hivatalos példákban is láttam ilyet.
Na de most ez lényegtelen mert nekem relációjelként kell.Most már csak az a kérdésem tisztelt vizsla, hogy hogyan lehet ilyen „feldolgozó függvényt” kódba önteni?
Tudnál valami példát mondani, vagy mondjuk ebben az esetben ez hogy nézne ki kódolva?„Továbbá amit nagyon nem értek… Hogy a == és a != operátorokkal miért nem volt semmi probléma???”
Hacsak a késõbbiekben nem ír ki a fordító valami hibát rá, bár ez az operátor c++-ba egy sor dolgot jelent… lehet, hogy valamilyen értelmezésben helyes. De egy szinte biztos! Nem úgy fog mûködni, ahogy elvártad, hacsak nem „véletlenül”.„kl223 al egyetértve szerintem könnyebben olvaható a kód friend ként.”
Hát ahogy a text fileodban benne van, úgy nem csodálkozom. :)))
A függvényt ugyanúgy máshol is ki lehet fejteni, akkor is, ha tag… nem friend függvénye… Hát ez jó volt! 🙂
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz