🚀 go-pugleaf

Dnia Tue, 06 Mar 2007 00:15:37 +0100, Mariusz Lotko skrobie:
> >> A jeśli obiektami są smart pointery, to co porównuję?
> > 
> > To samo. Przecież ich wartości również są wskaźnikami.

> Ale napisałeś (parę linijek wyżej), że porównywanie wskaźników, to
> porównywanie tożsamości.

Tożsamości obiektów wskazywanych przez te wskaźniki. To nie zmienia faktu, że
wskaźniki są wartościami i ich porównanie jest porównaniem wartości.

> Czy tożsamość przeradza się  w wartość jeśli
> obiekt jest inteligentny (smart)? ;-)

Nic takiego nie napisałem. Przecież te wartości to również wskaźniki.

Nie pomerdały ci się czasem obiekty wskazujące i obiekty wskazywane?

> >> > Po pierwsze, równość dwóch obiektów powinna wynikać z równości ich
> >> > wartości. Jeśli obiekt nie ma wartości, to nie powinien mieć określonej
> >> > porównywalności, bo po prostu nie ma czego porównać. Porównujemy więc
> >> > WARTOŚĆ (a nie za-WARTOŚĆ).
> > 
> >> OK, w takim razie jakiś przykład obiektu bez wartości?
> > 
> > struct X
> > {
> > int a;
> > int* b;
> > };

> Czyli tak: jak mam wskaźnik osobno, to mogę go porównać, jak mam int osobno
> to również mogę porównać, a jak je wezmę razem do kupy to już nie?

W żadnym z tych przypadków.

> >> Że jak? Piersza linijka większości porządnych operatorów == ! Po co
> >> porównywać zawartość tego samego obiektu?
> > 
> > A niby po co chcesz to sprawdzać? Jesteś pewny, że w każdym przypadku
> > będzie to tańsze?

> Mogę domniemywać, szczególnie jeśli obiekt składa się nie tylko z typów
> prostych, a więc "rekursywnie" będą wywołane inne operatory porównania jeśli
> tego nie zrobię.

Teoretycznie można - ale w założeniu obiekty wartościowe są obiektami małymi,
bo w obiektach dużych nie opłaca się tak określać wartości.

Obiekty wartościowe powinny być szczególnie przeznaczone do tego, żeby
identyfikować się przez wartość, a co za tym idzie, tanio się porównywać i
tanio kopiować.

Nie ma ściśle określone, co to znaczy, że obiekt jest duży, ale jeśli
porównanie tożsamości obiektów porównywanych przed porównaniem ich wartości
jest opłacalne, to znaczy, że obiekt jest "za duży" jak na obiekt wartościowy.

> > Jeśli w danym obiekcie w operatorze == nastąpi porównanie tylko jednej
> > wartości, to oszczędzasz tylko w przypadku, gdy masz ten sam obiekt. Jeśli
> > nie, to masz dodatkowe, niepotrzebne porównanie. Czyli koszt jest mniejszy
> > w przypadku równości, ale większy w przypadku nierówności.
> > 
> >> > W Javie np. masz:
> >> > 
> >> > Klasa a, b;
> >> > int c, d;
> >> > 
> >> > i masz
> >> > a == b
> >> > c == d
> >> > 
> >> > i bez różnicy. Szkoda tylko, że dla "String t, s" jest to samo ;)
> >> > 
> >> > Nie możesz jednak w żaden sposob (inny niż przez odpowiednie metody)
> >> > porównać wartości a i b, ani porównać referencji c i d.
> > 
> >> W C++ też musisz wiedzieć co porównujesz. Bo jeśli a i b są wskażnikami,
> >> to masz analogiczny problem. Z tym, że zamiast equals() używasz * do
> >> wyłuskania wartości.
> > 
> > Nieprawda. Jeśli c i d są typami wartościowymi, to ich wskaźniki w ogóle
> > nie powinny cię interesować.

> Ale mogą i język C++ tego nie zabrania. Jaki więc sens ma Twoja teoria w
> odniesieniu do tego języka?

Moja teoria ma odniesienie do projektowania, a nie do języka.

Nie zabrania ona używania wskaźników do obiektów wartościowych, ale pod
warunkiem, że ich używanie jest sprawą czysto językową (typu przekazanie przez
wskaźnik/referencję, czy konieczność weryfikacji w operatorze przypisania),
nie może natomiast służyć do wydawania decyzji na podstawie określania
tożsamości obiektu. To ostatnie może być brane pod uwagę tylko przez metody
danej klasy z uwagi na konieczność posiadania dostępu do różnych detali
implementacyjnych. Zewnętrze tego nie powinno potrzebować.

> >> > Pierwsze nie ma sensu dlatego, że jeśli w typach wartościowych liczy
> >> > się dla nas wartość, to nie liczy się tożsamość. Porównując wartość do
> >> > wspomnianego koloru, interesuje nas kolor, a nie np. czy kartki
> >> > papieru, na których zapisano kod koloru, są te same, czy inne.
> > 
> >> W szczególności może się zdarzyć, że będziemy chcieli porównać kolor tego
> >> samego egzemplarza kartki. Wówczas porównanie będzie prostsze i wykonalne
> >> nawet dla daltonisty. Stąd chyba nie warto od tożsamości się odcinać.
> > 
> > Ale PO CO?
> > 
> > Zwróć uwagę na to, co napisałem poniżej: nigdy nie porównuje się dwóch
> > wartości stanów z dwóch różnych obiektów, jeśli nie mamy z innego źródła
> > informacji o tym, jaka ta wartość jest.

> Twoja teoria stoi na glinianych nóżkach. Wprawdzie nie mam pamięci
> absolutnej, ale gdzieś mi kołacze po głowie, że kilka Twoich "nigdy"
> już mi się w życiu zdarzyło. A że nie pamiętam, to chyba nie skończyło
> się to żadną katastrofą programistyczną, którą trzebaby w pośpiechu
> naprawiać.

To lepiej sobie przypomnij - bo sytuacji, żeby ktokolwiek w jakimś programie
sprawdzał, czy "a.x == b.x, ale ile wynosi a.x nie mam zielonego pojęcia", ja
sobie nie przypominam.

> >> > Dlatego właśnie obiekty nie mają zwykle takiej ogólnej "wartości", mają
> >> > ich zwykle wiele i różne wartości mogą nas interesować przy
> >> > porównaniach.
> > 
> >> Piszesz trochę w kontekście bazodanowym, gdzie jest np. poszukiwanie
> >> obiektów spełniających określone kryteria. Jest jednak cała gama klas,
> >> dla których bez większych trudności można zdefiniować operatory
> >> porównania.
> > 
> > To są to wtedy typy wartościowe.
> > 
> > Java próbuje symulować to poprzez wprowadzanie obiektów niezmienialnych,
> > jak właśnie String (w C# wyszło to o tyle lepiej, że tam jest dla tego
> > typu poprawnie zdefiniowany operator porównania). Niestety z przyczyn
> > wydajnościowych wymaga to dodatkowych wygibasów jak StringBuilder.
> > 
> >> Mimo to nie odważyłbym się na takie wyraźne i jednoznaczne nazwanie
> >> pierwszych obiektów wartościowymi a drugich niewartościowymi.
> > 
> > Dlaczego?

> Bo świat to nie tylko bazy danych.

A co mają do tego bazy danych?

> >> > Ja wiem, że zaraz ktoś rzuci szczególnym przypadkiem, że co z
> >> > obiektami, które mają jedno pole, a zatem tylko jeden stan cząstkowy?
> >> > 
> >> > Otóż tutaj właśnie odgrywa rolę kwestia tożsamości obiektów. Jeśli
> >> > bowiem interesuje nas tożsamość obiektu, to nie interesuje nas jego
> >> > wartość (jeśli nie podlega ona bieżącemu przetwarzaniu, tzn. np.
> >> > właśnie chcielibyśmy tą wartość porównać z odpowiadającym temu czemuś
> >> > stanem w innym obiekcie).
> > 
> >> Weźmy obiekty w rodzaju mutable string. Da się jednoznacznie zdefiniować
> >> operator porównania, w pewnej chwili dwa obiekty będą równe, a za chwilę
> >> nie, więc trudno tu mówić o tożsamości.
> > 
> > Tak, ale mutable string - jeśli mówimy o czymś takim, jak StringBuilder -
> > nie jest już typem wartościowym, gdyż zmienność obiektu wchodzi w
> > interakcję z jego tożsamością.
> > 
> > Porównanie tego typu z innym mogłoby się odbywać tylko poprzez -
> > najczęściej niejawne - pozyskanie String'a - czyli typu już wartościowego
> > - i porównanie go z innym stringiem.

> Rozumiem, że String jest niezmienialny a SB zmienialny, ale dlaczego jeden
> jest wartościowy, a drugi już nie - wstyd się przyznać, ale nie mogę.

Bo modyfikacja w obiekcie typu StringBuilder jest widziana w każdym miejscu,
gdzie jest trzymana referencja do tego obiektu.

W przypadku typu String z przyczyn oczywistych ta zależność nie zachodzi.

> >> > Natomiast porównanie stanów dwóch obiektów nie ma po prostu sensu. Co
> >> > na przykład da ci informacja, że pewne dwa samochody są "tego samego
> >> > koloru", dopóki nie wiesz, jaki to kolor?
> > 
> >> Uwierz mi, w wielu sytuacjach ma to sens.
> > 
> > Nie wierzę :)

> Znowu zrobię niecodzienną w świecie informatyki wycieczkę: załóżmy jesteś na
> dyskotece i jesteś stanu wolnego. Jeśli nie zainteresujesz się stanem
> obiektu "kobieta" (czy też jest "wolny") przed zagajeniem, to ryzykujesz
> stratę zębów od jej chłopaka-dresiarza.

Czyli właśnie strzeliłeś sobie gola ;)

Jak najbardziej chcemy sprawdzić, czy dziewczyna.stan == "wolny".

Ale nie ma sensu sprawdzanie, czy dziewczyna.stan == me.stan, jeśli nie wiemy
jaki jest stan jednego z tych obiektów.

> >> Dziwię się Twoją opinią, bo sprawiasz wrażenie człowieka, który ma
> >> doświadczenie zawodowe i trochę linii kodu wyprodukował.
> > 
> > I mówię to właśnie na podstawie tego :)
> > 
> > Jeśli chcemy stwierdzić, czy dwa obiekty są w "tym samym stanie", to
> > musimy mieć chociaż przybliżone pojęcie o tym, jaki ten stan jest.

> A jeśli chcemy je tylko pogrupować według stanu?

To jest zupełnie inna sprawa - to nie jest porównywanie, tylko porządkowanie
(zgodnie z terminologią STL - operator <).


-- 
//  _    ___         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"