🚀 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"