🚀 go-pugleaf

Dnia Wed, 07 Mar 2007 19:59:52 +0100, Mariusz Lotko skrobie:
> Sektor van Skijlen wrote:

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

> I w _każdym_ systemie tak to modelujesz? Z pełną otoczką? Piękny przykład
> wzorca "swiss army knife".

Nie używaj pojęć, których znaczenia nie rozumiesz.

Swiss army knife to by było, gdyby ten portfel mógł przechowywać pieniądze,
laptopy, meble, samochody, kontenery i elektrownie.

Ilość pieniędzy nie jest wartością portfela. Jest jego stanem. Portfel nie
może mieć wartości - i to nie dlatego, że poza tym może mieć jeszcze wiele
innych stanów i atrytbutów.

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

> Idąc Twoją logiką: niekoniecznie. Obiekt kolor ma jeszcze atrybuty: data
> naniesienia, technika wykonania i stopień nasłonecznienia, które pozwalają
> obliczyć rzeczywisty kolor w czasie :> Wtedy nie da się porównać dwóch
> "czerwonych". Odsyłam do ekspertów - lakierników samochodowych.

Nie przypominam sobie, żebym mówił o lakierze samochodowym. Mówiłem o kolorze.
Kolor może być również atrybutem (a nie wartością, acz przypadkiem też nie
stanem) lakieru.

No to jak, zrozumiałeś już, co to takiego jest wartość, czy douczysz się i
zgłosisz za tydzień?

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

> W operatorze porównania? Nie sądzę...

W operatorze przypisania.

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

> W pewnych przypadkach może tak być.

Statystycznie jest to 99% przypadków.

> Implementując operator warto
> oszacować prawdopodobieństwo porównywania tych samych obiektów.

Zrób sobie małą statystykę użycia takiego typu i ilość porównań, dla których
trafiasz na równość i dla których trafiasz na nierówność.

Prosty przykład - iteratory. Masz pętlę, w której przechodzisz przez wszystkie
iteratory w zakresie od jednego do drugiego. Ile masz w tym momencie porównań,
które wyjdą równe, a ile, które wyjdą nierówne? Tu policzyć bardzo łatwo:

Dla zakresu o długości N, będziesz miał N-1 porównań, które się okażą
nierównością, i jedno, które okaże sie równością. Różnica rośnie wraz z
długością zakresu i tylko w przypadku gdy zakres ma 1 element porównanie jest
szybsze. Dla dwóch elemmentów jest już mniej więcej tak samo kosztowne, wraz z
powiększaniem się długości zakresu porównanie, które najpierw sprawdza
tożsamość, jest kosztowniejsze.

Podałem ci tylko przykład, jak należy prowadzić taką analizę - to, że ten
przykład jest negatywny dla twojej tezy, nie ma znaczenia. Myślę, że dałoby
się znaleźć przykład, który by twoją tezę potwierdzał, ale to nie ma większego
znaczenia.

W odróżnieniu od ciebie jednak, ja rozumiem konieczność wykonania analizy,
która dowiedzie, czy to się nam opłaca, czy nie. Ty przyjmujesz "w ciemno", że
sprawdzanie najpierw tożsamości będzie zawsze bardziej opłacalne. W
ostateczności zgadzasz się nawet, że "najczęściej".

No to podaj mi przykład typu wartościowego, w którym to się opłaca, i oszacuj
ilość porównań trafionych i nietrafionych w typowych algorytmach, które go
używają. Wtedy będziemy wiedzieli, o czym rozmawiamy.

> Generalnie jednak - nie zgadzam się.

Ależ masz pełne prawo się nie zgadzać. Ja w odróżnieniu od ciebie potrafię to
uzasadnić.

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

> Znowu ogólnik: "zwykle"... "Sprzedajesz" nam teorię, która ma działać w
> praktyce, ułatwiać ją. Chciałbyś, żeby Twój samochód "zwykle" działał?

Oczywiście teoretycznie może istnieć taki wzorzec, który typom nie stawia
żadnych wymagań, ale w praktyce nie spotkałem się z takim.

Wymagania co do typów zawsze określają poszczególne operacje, które na typie
można wykonać. I te operacje świadczą też o tym, czy typ jest wartościowy, czy
nie.

Przykładowo, typ przechowywany w std::list musi być typem wartościowym.
Niestety, tak jest skonstruowany szablon std::list. Świadczą o tym następujące
wymagania względem typu:
 - przypisywalny
 - kopiowalny
 - domyślnie-konstruowalny

Poza tym wiele algorytmów STL, które mogłyby pracować również na zakresie
wziętym z listy, wymagają dodatkowo, żeby był porównywalny.

Dostarczając do swojego typu wszystkie możliwe rzeczy, żeby spełnić wymagania,
de facto czynisz z niego typ wartościowy - co może się niekoniecznie zgadzać z
logiką twojego programu.

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

> Jak wyżej: zależy od kontekstu.

Nic nie zależy od żadnego kontekstu.

Saldo jest stanem (cząstkowym) konta. Saldo jest wartością. Konto jest
obiektem.

> Możemy nie wiązać obiektów transakcji do
> konta, a zrobić wiązanie odwrotne: każda transakcja ma referencję do konta.

Ale co to ma do rzeczy?

Transakcja też jest obiektem, tzw. "wartość transakcji" jest atrybutem obiektu
transakcji, a ilość pieniędzy, na którą opiewa transakcja, jest wartością.

> I podobnie z właścicielem. Krótko mówiąc "konto jest anonimowe" i
> przechowuje jedynie swoje saldo (wartość) oraz numer (tożsamość).

Numer jest atrybutem obiektu (unikalnym, więc jest ściśle związany z
tożsamością), właściciel też jest obiektem (w bazie banku jest osobnym
obiektem, który może być podmapowany do kilku kont). Saldo jest stanem konta,
a wartość salda to ilość pieniędzy znajdujących się na koncie.

> Nie wiem, czy to ma sens, ale nie możesz chyba wykluczyć, że w jakimś
> tam systemie może mieć.

Niestety nie. Przykro mi.

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

> Element ze zbioru (tu: typ, klasa).

To znaczy?


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