🚀 go-pugleaf

Sektor van Skijlen wrote:

> Dnia Mon, 05 Mar 2007 07:07:55 +0100, Mariusz Lotko skrobie:
>> > No w³a¶nie o to chodzi, ¿e nie. Je¶li okre¶lamy dany typ jako
>> > warto¶ciowy, to to¿samo¶æ przechowuj±cego j± obiektu nie powinna nas
>> > interesowaæ w ogóle.
>
>> A zatem powszechnie stosowany "trik" polegaj±cy na sprawdzeniu to¿samo¶ci
>> obiektu w pierszej linijce operatora == uwa¿asz za b³êdny?
>
> Tak.

Wybacz, ale powy¿szym stwierdzeniem sk³aniasz mnie do stwierdzenia u Ciebie
paranoi... Przecie¿ stosowanie tego jest oczywiste. Po co mam sprawdzaæ,
czy mam tyle samo pieniêdzy w swoim portfelu co... w swoim?

>
>> Podobnie w operatorze =, w którym zapobiega to przypisania obiektu
>> samemu sobie?
>
> Tu ju¿ nie, ale to jest zwi±zane z tzw. kwesti± jêzykow±. W przypadku C++
> jest to konieczne, je¿eli obiekt podawany jako argument operatora = jest
> przekazywany przez referencjê.
>
> Nie by³oby natomiast tego problemu w przypadku, gdyby ten obiekt by³ tam
> przekazywany przez warto¶æ.
>
> Gdyby hipotetycznie w Javie by³a mo¿liwo¶æ zrobienia czego¶ podobnego, to
> tam te¿ nie ma konieczno¶ci dodawania takiego sprawdzenia:

Z tym, ¿e w obu przypadkach nie chodzi o "przykr± konieczno¶æ", a
o "wspania³± mo¿liwo¶æ" szybkiego stwierdzenia, ¿e chodzi o "te same"
a wiêc na pewno "takie same" obiekty.

>> > Zauwa¿, po co w C++ stosuje siê wska¼niki i referencje do takich typów
>> > jak int, czy std::string. Je¶li ju¿, to stosuje siê albo uogólnienie
>> > przekazywania (const T&), albo przekazuje siê do zmodyfikowania (T&,
>> > T*). Czy widzia³e¶ kiedykolwiek w jakim¶ rzeczywistym programie, ¿eby
>> > kto¶ porównywa³ dwa wska¼niki do int (pomijaj±c przypadek, gdy wska¼nik
>> > do int jest u¿ywany jako iterator do tablicy int-ów - czyli
>> > zastosowanie jest inne, ni¿ warto¶æ referencji)?
>
>> Tak, w dowolnej konkretyzacji szablonu int'em. Nie ka¿demu chce siê
>> robiæ specjalne implementacje dla typów prostych.
>
> Przy uogólnianiu oczywi¶cie jest to prawda, z t± tylko ró¿nic±, ¿e tam typ
> parametryczny T traktuje siê prawdopodobnie zawsze jak typ obiektowy, wiêc
> sprawa konkretyzacji na int nie ma i tak znaczenia.

"Prawdopodobnie" to dla mnie trochê za ma³o. Szczególnie w przypadku
szablonów, które wed³ug mojej praktyki z regu³y s± po prostu przeznaczone
dla obiektów oferuj±cych okre¶lony interfejs. I innych ograniczeñ w ich
u¿yciu w³a¶ciwie nie ma.

> Ale je¶li jest traktowany jako typ obiektowy, a nie warto¶ciowy, to
> równie¿ istnieje przekazywanie przez referencjê, czy nieu¿ywanie operatora
> == (bo nie wiadomo, czy zdefiniowany) itd. - czyli typu T nie uwa¿a siê za
> warto¶ciowy.

Takich za³o¿eñ raczej te¿ siê nie podejmuje w C++. Je¶li co¶ nie jest
zdefiniowane, to poinformuje nas o tym kompilator w czasie konkretyzacji
szablonu.

>> > Dlatego to¿samo¶ci± dla obiektów warto¶ciowych jest warto¶æ. Obiekty
>> > mog± sobie t± warto¶æ przekazywaæ jak chc±, a nawet - jak pamiêtasz,
>> > dyskutowali¶my o tym - warto¶ci mog± byæ symulowane przez
>> > predefiniowane unikalne obiekty i w takim przypadku porównanie
>> > to¿samo¶ci takich obiektów jest równowa¿ne porównaniu warto¶ci, choæ to
>> > ju¿ jest szczegó³ implementacyjny.
>
>> Nie zgadzam siê. Ka¿dy obiekt jest uproszczeniem rzeczywisto¶ci, a co za
>> tym idzie z du¿ym prawdopodobieñstwem mog± pojawiæ siê obiekty o tych
>> samych warto¶ciach, które nie s± tymi samymi obiektami.
>
> Je¶li mówimy ju¿ o rzeczywisto¶ci - podaj mi przyk³ad obiektu z
> rzeczywisto¶ci, który posiada jednocze¶nie warto¶æ i to¿samo¶æ.

Konto bankowe. To¿samo¶æ: numer, warto¶æ: saldo.
Nie chcia³bym mieæ konta w banku, który ma k³opot z odró¿nieniem
warto¶ci mojego konta od jego to¿samo¶ci.




--
Mariusz Lotko