🚀 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