(C++) operator^ probléma

 ( Dgzt | 2012. január 7., szombat - 19:56 )

Hellosztok!

Van egy Nagyegesz osztályom. Ez adott. Le kell kezelnem a

Nagyegesz operator^(unsigned int,unsigned int);

-t, de ha az osztályon kívül írom ezt vagy osztályon belül friend-del, akkor ezt kapom:

nagyegesz.h:50:39: error: ‘Nagyegesz operator^(unsigned int, unsigned int)’ must have an argument of class or enumerated type

A == ; != és egyéb operátorok működnek tökéletesen, csak ezzel van van. Szerintetek mi lehet a probléma?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Te most at akarod definialni a ket unsigned int kozti xort? Raadasul ugy, hogy Nagyegesz legyen az eredmeny?

--
There are free things in life i'll never understand
Spelling and counting

Pontosan, első unsigned int az alap kell hogy legyen, a második unsigned int meg a kitevő. És sajnos ezen nem tudok változtatni, mert így adták meg.
---------------------------
Oszt jónapot!

gondolj bele kicsit es rajossz, hogy ez kivitelezhetetlen :)

--
NetBSD - Simplicity is prerequisite for reliability

nem lehet ilyet, legalabb az egyik argumentumnak user defined-nak kell lenni

--
NetBSD - Simplicity is prerequisite for reliability

A programkód így néz ki:
...
unsigned alap1=3;
unsigned kitevo1=101;
Nagyegesz nf;
nf=alap1^kitevo1;
...

Van más mód, hogy ezt a kódot működésre bírjam, úgy, hogy ehhez a részhez, amit most írtam nem nyúlok?
Én ezért gondoltam arra, amit fentebb írtam, de más nem jut eszembe.

(csak a Nagyegesz osztályon belül dolgozhatok)
---------------------------
Oszt jónapot!

Mi lenne, ha sed-del az

operandus1 operátor operandus2

formát átalakítanád

függvény(operandus1, operandus2)

alakra?


tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Sajnos nem játszik ez, mert ehhez a részhez nem nyúlhatok, csak a Nagyegesz osztályt írhatom.
---------------------------
Oszt jónapot!

Van ugye ez a kód. Nem nyúlsz hozzá, de meg kell kapd, tehát abból egy temporary file-t írhatsz, mielőtt megemésztenéd. Tehát tekintsük ezt az előemésztést az emésztés részének. :)

Mondjuk valóban nem látom a pontos feladatot. Érdekességképpen elmesélem, hogy nekem a gputils-ban lévő PIC assemblerrel gyűlt meg a bajom. Egész egyszerűen bizonyos MCU-k egyes utasításait nem ismerte. Erre kitaláltam, hogy a forráskódot megírom szépen, de egy scripttel végigrohanok a file-on, írok egy temporary file-t, amelyben a nem ismert mnemonikokat

DB konstans

formában helyettesítem, majd erre a file-ra eresztettem az assembler-t. Volt, ahova macro hivatkozást kellett írnom, hiszen a konstans függött az operandustól. Sebaj, megírtam a macro-kat, s a temporary file-ba include-oltam a macro-kat tartalmazó file-t.

A módszer bevált, jól használható volt.


tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Randa megoldás, de ha már be tudsz include-olni egy osztályt, akkor melléteszel egy macro-t ami kicseréli az elso unsigned intet Nagyegész osztályra. Nagyegésznek csinálsz egy konstruktort, hogy az konvertálja az alapot. A macro-t meg valahogy ugy kéne megírni, hogy csak az ilyen kifejezéekbe nyúljon bele vagy csak ebbe.
Vagy csak kicseréled függvényhívásra, mint ahogy feljebb mondták.

Tanár Úr kérem, ez baromság! :D

Ez a beadandó feladatom. Kaptam egy main.cpp -t, ami használ Nagyegesz osztályt, amivel lehet összeadni, kivonni, faktort számolni, stb. Abban van ez a kód részlet, ami hatványt számol. Nekem a Nagyegesz osztályt kell megcsinálnom. Csak az a bibi, a tanár kiadta, hogy a main.cpp -t nem szabad módosítani.
---------------------------
Oszt jónapot!

Ja, hogy nem gyakorlati feladat, hanem elméleti. Akkor passz, nem értek hozzá. A valós feladatok annyiban jobbak, hogy bármilyen megoldás szóbajöhet, csak az eredmény számít.


tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Hatvanyt? A gond az, hogy C++-ban a ^ nem hatvany, soha nem is volt az.

Ha megis, az az iskolapeldaja annak, hogy mire NEM szabad az operator overloadingot hasznalni.

Lehet, hogy ez csak az én tapasztalatom eddig, de úgy vettem észre, hogy elég sok tanár szeret a hatványozás témakörén (ill a hatványozás operátor hiányán) lovagolni ;)

Igaz, lehet, velem van a probléma, de szerintem egy kezemen meg tudom számolni, hogy hányszor volt szükségem hatványozásra programkódban. (Igen, elismerem, van, ahova kell.)

----------------
Lvl86 Troll

Melyik iskola, milyen szak?

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

Pécs, Programtervező Informatikus.
---------------------------
Oszt jónapot!

Lehet, hogy nem jó neked és biztos, hogy nagyon ronda.

main.cpp
nagyegesz.h

unsigned c = aaa ^ bbb;
cout << "Eredmeny: " << c << endl;

$ g++ main.cpp
$ ./a.out
Eredmeny: 125
$

Hulye egy hazi az teny. De nem gond vajon, ha az unsigned char-bol szepen Nagyegesz char-t csinal? :)

--
There are free things in life i'll never understand
Spelling and counting

De, lehetséges.
Már csak az a kérdés, hogy az eredeti main.cpp-ben volt/van-e unsigned char.

Egyebkent a regi Qt is hasonloan mukodott. Ott volt a moc, ami a nem c++-os Qt reszeket kicserelte c++-ra, es utana kapta csak meg a gcc.

--
There are free things in life i'll never understand
Spelling and counting

ugy erti class-nak, structnak vagy valami hasonlonak, (unsigned) intekre (es egyeb primitiv tipusokra) nem mukodik, legalabb az egyik argumentum legyen mas

es a g++-os hibauzenet is pont ugyanezt irja

Igen, van rá mód, hogy működésre bírd, de nem úgy fog működni, ahogy szeretnéd, hogy működjön, ugyanis két int között nem tudod felüldefiniálni a ^ operátort, mert az alapból definiálva van int visszatérési értékkel. Szóval mivel bármit csinálsz, nem tudsz változtatni azon, hogy mit fog meghívni, ezért biztos, hogy int visszatérési érték lesz, úgyhogy annyit tudsz csinálni, hogy írsz a Nagyegész osztálynak egy kostruktort, ami egy int-et vár. Így már le fog fordulni, de ettől még a hatványozás nem fog tudni int-nél nagyobb számot visszaadni.

Nagyegesz& operator=(const double& i);. Az alap1^kitevo1-et meg írd át: pow(alap1, kitevo1).

dupla

egy nem programozó kérdése:
gondolom a Nagyegeszben vannak ilyesmik:
Nagyegesz( const uint kicsi );
Nagyegesz& operator=( const uint kicsi );
ha igen akkor a
Nagyegesz nagy ; ... ; nagy = ( x ^ y )
Nagyegesz nagy( x ^ y )
Nagyegesz nagy = ( x ^ y )
helyzetek kezelve vannak. Milyen helyzeteket akarsz ezeken kívül kezelni?
ncs

szerk: közben látom leírtad a helyzetet... :)

Neked sztem a Nagyegesz operator^(unsigned int& other) -ra van szukseged.

Nem, az akkor működne, ha ilyet akarna:

Nagyegész n = 10;
Nagyegész n2 = n ^ 2;

De nem ilyet akar, hanem ilyet:

unsigned n = 10;
Nagyegész n2 = n ^ 2;

Ezt márpedig sajnos nem lehet felüldefiniálni AFAIK.

Igy van. A C++ FAQ-ban le is irjak miert:

If C++ let you redefine the meaning of operators on built-in types, you wouldn't ever know what 1 + 1 is: it would depend on which headers got included and whether one of those headers redefined addition to mean, for example, subtraction.

Magyarul, ha engedelyezve lenne ez a lehetoseg, akkor igaz lenne az az allitas, hogy 2 * 2 neha 5.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Köszönöm a segítségeteket!

Úgyhogy szerintem kimondható, hogy ez így ebben a formában megoldhatatlan.
---------------------------
Oszt jónapot!

+1, valóban megoldhatatlan, tehát nem létezik olyan nagyegesz.h, ami a fenti (unsigned alap1; unsigned kitevo1) kód eredményén változtat. Mindig a beépített ^ fog meghívódni a két unsignedre.

Ha viszont az egyik unsigned-et Nagyegeszre lehet cserélni a main.cpp-ben, akkor a feladat megoldhato. Például így:

class Nagyegesz {
 public:
  Nagyegesz(unsigned a) {}
 private:
  Nagyegesz();
};
  
Nagyegesz operator^(const Nagyegesz& a, const Nagyegesz& b) {
  return a;
}
 
int main() {
  Nagyegesz a = 5;
  unsigned b = 6; 
  a ^ b;
  b ^ a;
  return 0;
}

#define ^ [valamimás]

:)

--
joco voltam szevasz

Nem mintha lenne bármilyen más operátor, amit két unsigned között felül lehetne definiálni :)

Jobban belegondolva nem mond akkora hulyeseget.
#define ^ ^(Nagyegesz)
Es ettol kezdve az a^b kifejezesnel a jobb oldal mar Nagyegesz tipusu lesz (mert castolja).

szerk: na jo, a ^ nem azonosito..

--
There are free things in life i'll never understand
Spelling and counting

Hülye kérdés:
A ^ biztos hatványozást akar jelenteni? (Így szól a feladat?) Mert ha nem, akkor hagyd ki az egész operator^-t, működni fog.

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

Igen, hatványozás. Fentebb bemásoltam ezt a feladatrészt és ott van, hogy "alap" és "kitevo" a változó neve.
---------------------------
Oszt jónapot!

Háhá... Most esett le.

"Az alábbi main() függvényt NE módosítsák. Kivéve, ha esetleg valami elírást lenne benne. "

Nem csodálkoznék, ha direkt lenne elírva és ki az akinek leesik. :)

Szóval a jelenlegi programkód így néz ki:

...
unsigned alap1=3;
unsigned kitevo1=101;
Nagyegesz nf;
nf=alap1^kitevo1;
...

És ebből csinálom ezt:

...
Nagyegesz alap1=3;
Nagyegesz kitevo1=101;
Nagyegesz nf;
nf=alap1^kitevo1;
...

És a problémát megoldottam. (Szerintem)
---------------------------
Oszt jónapot!

kitevo maradhat primitiv tipus
kommentben ird oda hogy mit valtoztattal es miert

--
NetBSD - Simplicity is prerequisite for reliability

És egy óriási nagy virtuális tockos a feladat kiírójának, hogy görénykedik a ^ operátorral, ami nem erre való...
:-)

+1

A jobbasszociativitást is tudja? :)

:) csak megoldódott, IQ feladat volt inkább mint c++.
"It should be noted that these operators have a lower precedence than the arithmetic operators, so if ^ were to be overloaded for exponentiation, x ^ y + z may not work as intended."
http://en.wikibooks.org/wiki/C++_Programming/Operators/Operator_Overloading

Nem, az nem kell. :)
---------------------------
Oszt jónapot!