🚀 go-pugleaf

Dnia Mon, 05 Mar 2007 23:58:08 +0100, Mariusz Lotko skrobie:
> 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?

Portfel nie jest typem wartościowym.

Ilość pieniędzy w portfelu jest jedynie jednym ze stanów tego obiektu,
podobnie jak ilość kart kredytowych w środku, kolor portfela i materiał, z
którego go wykonano.

Typem wartościowym może być kolor. Porównanie dwóch obiektów typu kolor można
porównać ze sprawdzeniem, czy na dwóch kartkach papieru zapisany tam kod
koloru jest ten sam. Ty chcesz, żeby przed odczytaniem numeru z każdej kartki
najpierw sprawdzić, czy te obie kartki to czasem nie jest jedna i ta sama
kartka. Jaki to ma sens?

> >> 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.

To jest przykra konieczność. Musisz to po prostu zrobić, bo inaczej będzie
wylot.

Ta "wspaniała możliwość" z kolei powoduje droższe porównanie.

> >> > 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.

Tak, dokładnie. Ale typy wartościowe zwykle mają inny interfejs, niż typy
obiektowe.

> > 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.

Powodując, że dla danego typu nie da się tego szablonu zastosować, więc nie ma
tematu.

> >> > 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.

Oraz wartość: właściciel (można go potem kiedyś zmienić)
Oraz obiekt: historia transakcji
Oraz...

Czy ty w ogóle wiesz, co to jest "wartość"?

> Nie chciałbym mieć konta w banku, który ma kłopot z odróżnieniem
> wartości mojego konta od jego tożsamości.

Na razie to masz problem z odróżnieniem wartości od stanu.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"