Ko sto vidis radi.

Milim da je ipak bolje da operator+ bude globalan i eventualno friend.
friend ili ne zavisi od svrhe klase.

Evo i odgovora na tvoje pitanje:

Prema 13.5.2 plus mozes da preopteretis.
Prema 13.5.2.1 binarni operator moze da bude clan klase onako kako je opisano u 9.3, a prema 9.3.1.3 i const.

13.5.7 je zaniljiv ali te ne kaci.

Mene su ucili u skoli, pa valjda se zato toga uvek i drzim, sledece.

Operator + treba raditi uvek ovako:

friend Klasa& operator+ (const Klasa&, const Klasa&);

Sad kada razmisljam, ne vidim primere gde ovo ne bi bilo prikladno, ali to ne znaci da ih nema. Postoji i jedna vise logicka ideja vezana za friend stanje ovog operatora - Ako ga preklopis u klasi, a dovodis drugi objekat iste te klase, na neki nacin govoris da "+" pripada prvom clanu. Posto je operacija sabiranja komutativna, to je pomalo besmisleno. Ovako si napravio sabiranje objekata klase potpuno odvojeno od njih samih, cime ukazujes na komutativnost.
Sve ovo ne vazi ako je redosled sabiranja bitan za klasu o kojoj govoris. U tom slucaju bih ja napisao:

Klasa& operator+ (const Klasa& drugiSabirak);

Well... i ja koristim friend operator+ ali cudno mi je bilo ovo oko konstantnosti, o cemu knjiga govori da f-ja clan, operator+, ne moze da bude konstantna...

Izgleda da nisam shvatio iz prve sta je ustvari tvoja dilema.
Samo da kazem da se apsolutno slazem s tobom i da je besmisleno reci kako ne sme biti const funkcija. Nikako ne mogu shvatiti zasto bi to neko rekao.
Bilo bi zgodno da se javi neko sa suprotnim argumentom, do tada cemo podrazumevati kako je to glupost ;)

Do sada sam mislio da je greska u prevodu... Ali, imam knjigu C++ za 21 dan i u elektronskom obliku koja je 3. izdanje... A knjiga koju (fizicki :) ) imam je 2. izdanje.

I opet, isto pise... operator+ ne moze biti const ( u 3. izdanju originalne knjige na engleskom )...

Mozda smaram ali, mislim da je ovo vazna tema jer, mozda i stvarno ne sme biti const u nekim slucajevima pa je bolje ostaviti je da bude ne-const...

Za sada... jos uvek mislim da ona MOZE biti const... :)

P.S. Mozda je Jesse Liberty bio u kafanici pred pisanje ove lekcije :)

Pitanje ko je u pravu ta knjiga( C++ za 21 dan - Jesse Liberty ) ili standard?

Hm ...

Vidim i slucaj kada moze biti const i kada ne mora ... ne bih se ogranicio na bilo koji od dva da MORA ...
Volja programeru kako ce da uradi ...

evo primera kada const skodi:

Da zaboravih dodati oko citave price:

const bi trebalo da ukaze na to da je nesto "nepromenljivo", odnosno da nece biti menjano i da kompajler
ukoliko se to nesto pokusa menjati, namirise konceptualnu gresku u programu ...

Mislim da je uvedena ta konvencija da operator+ (ili bilo koji drugi) ne sme biti const iz prostog razloga
sto kompajler ne moze (mada i moze ali kada su oni to smisljali, verovatno su rekli "ko ce da se bakce sa tim")
da prokljuvi da li operater unutar metode koja ga definise nesto menja u klasi i vraca referencu ili vraca novu instancu ...

Jel ovo ima smisla?

Nema bas, zato sto const upravo i sluzi da proveri sta ti to radis unutar metode. Ako ne bi radio to - ne bi nicemu ni sluzio. Za njega nema razlike izmedju operatora + i neke druge metode. Samo njegovo postojanje dokazuje da je neko "hteo da se bakce s tim" :)
Inace const je dozvola kompajleru da optimizuje neke delove koda i dobar je pomocnik programeru. Kada se stekne navika stavljanja const-a svuda gde treba, odmah primetite neke greske koje pravite usled menjanja primene odredjene metode. Ovo se najcesce desava kada npr. imate metodu koja vraca neki privatni clan, pa nekoliko dana kasnije pozelite da menjate nesto u klasi i shvatite da mozete iskoristiti tu funkciju. Kompajler vam to zabrani, a vi budete naterani da lepo isprogramirate svoju klasu i sve akcije koje menjaju samu klasu stavite u odgovarajuce metode.

@DjoleReject

U tom slucaju sto si naveo, onda mi se cini da i ima smisla ... :)

Elem, odlican info, nisam ranije razmisljao da je enforceovana provera const metoda, sada znam da jeste ...

Ali mi i dalje nije jasno zasto u konkretnom primeru operator+ ne moze da bude const osim
ako u klasi String nije implementiran bas onako kao sto sam dao u primeru (da operator vraca referencu na samu instancu
klase a da operator+ appenduje rhs), a pretpostavljam da nije ...

Jedino sto mi pada na pamet zasto ne bi valjalo da stoji const - kreiranje temporary string instance u slucaju:

String nesto = nestoDrugo + nestoTrece ...

Gde instanca nestoDrugo kreira String, doda sebe u novu instancu doda nestoTrece u novu instancu i vrati novu instancu

Onda nesto koristi copy constructor ako je vracena instanca const pa se ona posle oslobadja ...
Ako nije const, kontam da bi jednostavno mogla da se koristi ta vec napravljena instanca i da nesto uzme njenu vrednost bez
dodatnog copy konstruktora i destructora te privremene instance ...

Za ovo nemam srca da pitam jel ima smisla ... :)

ajmo redom:

@glorius

Nabavi čestitu knjigu za C++. Moj profesor Objektnog progamiranja kaže, a ja se slažem :), da su sve te knjige nauči nešto za 21 dan čista glupost (sve čekam kada će da izađe naučite da programirate svoj grafički OS za 21 dan). Naravno, pomenutu knjigu nisam čitao, pa možda i nije prikladno da govorim o njoj. Ali sve te "za 21 dan" knjige mi deluju kao šablonsko đubre za glupe Amerikance koji očekuju sve na gotovo i sve u nekoj instant varijanti (naravno, nisu svi amerikanci glupi, ali volim da koristim ovaj stereotip, jer ga svi razumemo ^_^). Knjiga koju ti ja toplo preporučujem je Laslo Kraus, "Programski jezik C++ sa rešenim zadacima". Zbirku zadataka istog autora pod imenom "Rešeni zadaci iz C++" ti ne preporučujem iz prostog razloga što je dobar deo primera iz te zbirke već urađen (i detaljno objašnjen) u samoj knjizi. Knjiga nije skupa (mislim da je 800 dinara original) i vredi. Uglavnom je tipa praktičnog priručnika, ali se kroz nju prožima i malo C++ filozofije (npr polimorfizam). Mogu ti preporučiti i druge knjige, kao i on-line resurse. Npr intervjui sa B. Stroustrupom (http://en.wikipedia.org/wiki/Bjarne_Stroustrup) su posebno interesantni, a naročito ovaj (http://public.research.att.com/~bs/ieee_interview.pdf) - i ako već hoćeš da čitaš nešto od nekog stranog stručnjaka, bolje uzmi nešto njegovo, nešto sa dušom, nego te generičke "za 21 dan" knjige :)

A što se tiče const funkcija, apsolutno ne postoji ni jedan jedini razlog zašto ta funkcija ne bi smela da bude const. Čak smatram da je dobra praksa deklarisati je kao konstantnu, iz prostog razloga što će ti dozvoliti sabiranje dva konstantna objekta.

Nego, zašto bi u opšte hteo da preklapaš operator sabiranja kod klase Employee? Šta tu ima da se sabira? Mislim ono, MOŽEŠ da ga preklopiš da radi šta god ti srce ište, ali smatra se dobrom praksom da se operatori preklapaju tako da semantika C-a bude očuvana, što će reći da bude intuitivno jasno šta funkcija radi, zbog svih onih koji će koristiti tu funkciju kasnije, a koji ne moraju nužno imati uvid u implementaciju tog operatora (http://en.wikipedia.org/wiki/Operator_overloading).

@vlaiv:
Uprvo zbog pravila očuvanja semantike nema svaka funkcija koja preklapa operator plus NE TREBA, VEĆ MORA biti deklarisana konstantnom. U tvom primeru programer je, kao što si sam rekao, odlučio da + znači njemu nešto interesantno, što nije korektno. U takvim slučajevima se ne preklapaju klase već se piše nova metoda, i ona se deklariše kao konstantna ili nekonstantna shodno tome šta radi. Ali operacija sabiranja ne menja ništa i ako ćeš to da promeniš, ne treba da je preklapaš :). A što se tiče tvog poslednjeg odgovora, to jest pitanja (koje mi deluje malo zbunjujuće, al' 'ajd' da probam): u izrazu tipa NeštoA = NeštoB + NeštoC, gde su NeštoA,NeštoB i NeštoC objekti neke klase Nešto (ne tvoje :)) a + pravilno preklopljen operator koji ne menja semantiku, rezultat sabiranja NIJE konstantan objekat klase Nešto, već najobičniji (nekonstantan, što će reći promenjiv) objekat klase Nešto. Ali bez obzira na to, rezultati se operatorom dodele (=) UVEK dodeljuju PO REFERENCI (osim ako si i njega preklopio tako da narušiš semantiku xD). Nadam se da je sada sve jasnije :)