🚀 go-pugleaf

Dnia Fri, 16 Mar 2007 16:39:31 +0000, Sektor van Skijlen napisa³(a):

> Typ warto¶ciowy jest typem, którego obiekt jest identyfikowany
> zawsze przez warto¶æ. Wiêc je¶li portfel z t± sam± ilo¶ci±
> pieniêdzy nie jest tym samym portfelem, to portfel nie jest
> typem warto¶ciowym.

Hmm... ale chyba jest dobrym przyk³adem, ¿e czasami chcemy go
potraktowaæ jako typ warto¶ciowy, a czasami jako niewarto¶ciowy:

  if (portfel1==portfel2)  //Czy maj± tyle samo pieniêdzy?
  if (portfel1 IS portfel2)  //Czy to ten sam portfel, czy inny?

> Nic nie zale¿y od ¿adnego kontekstu.
>
> Saldo jest stanem (cz±stkowym) konta. Saldo jest warto¶ci±.
> Konto jest obiektem.

No có¿, ale C++ ju¿ taki dziwny jest, ¿e nie ma "go³ych" warto¶ci
[a przynajmniej nic mi o tym nie wiadomo], tylko wszystko jest
trzymane w jakich¶ obiektach ;) W przypadku tego konta to akurat
da siê sprawy rozdzieliæ:

   if (konto1.saldo==konto2.saldo) //porównanie warto¶ci
   if (konto1==konto2) //porównanie to¿samo¶ci

chyba ¿e kto¶ dla wygody prze³aduje sobie operator== ¿eby
dzia³a³ jako porównanie sk³adników saldo ;)
Ale ju¿ np. dla typu int z twojego przyk³adu:

>   int x = 2;
>   int y = 2;
>
> Powiedz mi teraz, czy "x jest y".

sprawa nie jest taka prosta ;)  bo tutaj porównuj±c x i y
w taki sposób:

   if (x==y) ...

porównujesz warto¶ci. Je¶li chodzi ci o to¿samo¶æ, to ju¿
trzeba by zapisaæ to np. tak:

   if (&x == &y) ...

i wtedy ju¿ wiadomo, czy "x jest y" ;)

Nie wiem tylko, czy dobrze rozumiem to, co próbujesz
wyt³umaczyæ, bo ju¿ siê pogubi³em w tej ca³ej dyskusji... :/

--
SasQ

Dnia Fri, 16 Mar 2007 22:49:45 +0100, SasQ skrobie:
> Dnia Fri, 16 Mar 2007 16:39:31 +0000, Sektor van Skijlen napisa³(a):

> > Typ warto¶ciowy jest typem, którego obiekt jest identyfikowany
> > zawsze przez warto¶æ. Wiêc je¶li portfel z t± sam± ilo¶ci±
> > pieniêdzy nie jest tym samym portfelem, to portfel nie jest
> > typem warto¶ciowym.

> Hmm... ale chyba jest dobrym przyk³adem, ¿e czasami chcemy go
> potraktowaæ jako typ warto¶ciowy, a czasami jako niewarto¶ciowy:

>   if (portfel1==portfel2)  //Czy maj± tyle samo pieniêdzy?
>   if (portfel1 IS portfel2)  //Czy to ten sam portfel, czy inny?

Nie.

if ( portfel1->ilosc_pieniedzy()
      == portfel2->ilosc_pieniedzy() ) // czy maj± tyle samo pieniêdzy

Nie porównujesz "dwóch portfeli", tylko porównujesz stan dwóch portfeli
(pomijaj±c ju¿ bezsens porównywania dwóch stanów z dwóch ró¿nych obiektów, ale
to tak na marginesie).

if ( portfel1 == portfel2 ) // czy to ten sam portfel

Ja wiem, ¿e jak komu¶ odbija kolba i musi sobie nawymy¶laæ wypasione definicje
operatorów (w tym ==), to nic siê na to nie poradzi, ale to bynajmniej nie
powoduje, ¿e portfel nagle staje siê typem warto¶ciowym.

Powtarzam: typ jest warto¶ciowy wtedy (i tylko wtedy), gdy to¿samo¶æ poznajemy
po jego warto¶ci. Je¶li wiêc ilo¶æ pieniêdzy w portfelu nie stanowi o tym, ¿e
to ten sam portfel, to nie jest to typ warto¶ciowy.

> > Nic nie zale¿y od ¿adnego kontekstu.
> >
> > Saldo jest stanem (cz±stkowym) konta. Saldo jest warto¶ci±.
> > Konto jest obiektem.

> No có¿, ale C++ ju¿ taki dziwny jest, ¿e nie ma "go³ych" warto¶ci
> [a przynajmniej nic mi o tym nie wiadomo], tylko wszystko jest
> trzymane w jakich¶ obiektach ;)

A takie co¶ jak np. 119 to jest gdzie trzymane twoim zdaniem?

> W przypadku tego konta to akurat
> da siê sprawy rozdzieliæ:

>    if (konto1.saldo==konto2.saldo) //porównanie warto¶ci
>    if (konto1==konto2) //porównanie to¿samo¶ci

Zgadza siê - z drobn± poprawk±: pierwsze to porównanie warto¶ci salda obu kont
(a nie porównanie warto¶ci obu kont).

> chyba ¿e kto¶ dla wygody prze³aduje sobie operator== ¿eby
> dzia³a³ jako porównanie sk³adników saldo ;)

Za takie PRZE£ADOWANIE to chêtnie bym komu¶ PRZY£ADOWA£.

Ale nawet to nie spowodowa³oby, ¿e nagle konto staje siê typem warto¶ciowym.

Typ warto¶ciowy zyskuje to¿samo¶æ przez warto¶æ. Przypisanie zatem powoduje,
¿e obiekt po lewej staje siê tym samym, co obiekt o poprawej, co mo¿na te¿
sprawdziæ operatorem ==. Przekazanie obiektu jest równie¿ przekazaniem
waro¶ci.

> Ale ju¿ np. dla typu int z twojego przyk³adu:

> >   int x = 2;
> >   int y = 2;
> >
> > Powiedz mi teraz, czy "x jest y".

> sprawa nie jest taka prosta ;)  bo tutaj porównuj±c x i y
> w taki sposób:

>    if (x==y) ...

> porównujesz warto¶ci.

Zgadza siê!

> Je¶li chodzi ci o to¿samo¶æ,

To¿samo¶æ w typach warto¶ciowych okre¶lamy jako to¿samo¶æ warto¶ci.

> to ju¿ trzeba by zapisaæ to np. tak:

>    if (&x == &y) ...

> i wtedy ju¿ wiadomo, czy "x jest y" ;)

I w których operacjach wynik tego porównania ma znaczenie, a w których nie ma?

> Nie wiem tylko, czy dobrze rozumiem to, co próbujesz
> wyt³umaczyæ, bo ju¿ siê pogubi³em w tej ca³ej dyskusji... :/

Najpro¶ciej to jest mniej wiêcej wyt³umaczyæ tak:

Typ warto¶ciowy jest identyfikowany przez warto¶æ. To oznacza, ¿e w przypadku
typów warto¶ciowych porównywanie to¿samo¶ci obiektów typów warto¶ciowych (o
ile w ogóle jest dostêpne w jêzyku - w Javie np. nie jest dostêpne) nie daje
¿adnej istotnej informacji, tzn. takiej, na której mo¿na w czym¶ polegaæ w
programie (je¶li ju¿, to jest to kwestia ¶ci¶le techniczna okre¶lonego
jêzyka).

W jêzykach, w których wszystko jest obiektem, typy warto¶ciowe s± symulowane
poprzez niemodyfikowalne obiekty. To znaczy, ka¿dy obiekt typu warto¶ciowego
musi zostaæ za ka¿dym razem wyprodukowany na nowo.

Ca³a istota sprawy polega na tym, co siê dzieje, je¶li obiekt jest
modyfikowany. Je¶li np. mamy dwa identyfikatory a i b:

a = get(1);
b = a;

Fakt, ¿e a == b po czym¶ takim jest spe³niony zarówno dla typów warto¶ciowych,
jak i obiektowych (z tym, ¿e w przypadku typów obiektowych a i b s±
referencjami, a wiêc równie¿ typami warto¶ciowymi).

Ale je¶li nast±pi modyfikacja obiektu poprzez 'b', to wtedy:
 - w przypadku obiektów warto¶ciowych, 'a' pozostaje przy starej warto¶ci
 - w przypadku obiektów niewarto¶ciowych, obiekt okre¶lany przez 'a' zmieni
   siê równie¿, jest bowiem tym samym obiektem, co 'b'

W jêzykach, które naturalnie wspieraj± typy warto¶ciowe, obiekty typów
warto¶ciowych mog± mieæ taki interfejs, który albo zawsze tworzy oddzieln±
kopiê w przypadku przypisania, albo je¶li wspó³dzieli jaki¶ obiekt z innym
obiektem tego typu, to modyfikacja powoduje zakoñczenie wspó³dzielenia i
wykonanie w³asnej, oddzielnej kopii. Tylko w takich jêzykach mog± istnieæ
modyfikowalne typy warto¶ciowe; w innych jêzykach mog± istnieæ tylko
niezmienialne obiekty warto¶ciowe, wiêc modyfikacja mo¿e polegaæ tylko na
stworzeniu nowej warto¶ci.


Oczywi¶cie teoriê typów warto¶ciowych i niewarto¶ciowych (co ciekawe, te
terminy pojawiaj± siê w coraz wiêkszej ilo¶ci ró¿nych niezwi±zanych ze sob±
dokumentacji, ostatnio widzia³em bodaj¿e w dokumentacji do Qt) mo¿na olaæ,
je¶li kto¶ uwa¿a, ¿e mu nie pasuje. Tylko ¿e alternatyw± jest stwierdzenie, ¿e
mamy kilka ró¿nych definicji porównania, kopiowanie p³ytkie i g³êbokie itd. -
je¶li komu¶ to bardziej odpowiada, to proszê bardzo.

Nawiasem mówi±c, w Rubym spierdzielili sprawê ze stringami totalnie. String w
ogólno¶ci jest typem warto¶ciowym - niestety w Rubym jest on ehm... takim
dziwnie-hybrydowym. To znaczy, modyfikacje przenosz± siê na inne obiekty
oznaczane identyfikatorami:

a = "dupa"
b = a
b[0] = "p"
print a

Ciekaw jestem, czy istnieje w Rubym jaka¶ mo¿liwo¶æ wymuszenia skopiowania.

Ale porównanie z kolei porównuje zawarto¶æ stringa.


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

Dnia Sun, 18 Mar 2007 23:11:57 +0000, Sektor van Skijlen napisa³(a):

>>> Typ warto¶ciowy jest typem, którego obiekt jest identyfikowany
>>> zawsze przez warto¶æ. Wiêc je¶li portfel z t± sam± ilo¶ci±
>>> pieniêdzy nie jest tym samym portfelem, to portfel nie jest
>>> typem warto¶ciowym.
>
>> Hmm... ale chyba jest dobrym przyk³adem, ¿e czasami chcemy go
>> potraktowaæ jako typ warto¶ciowy, a czasami jako niewarto¶ciowy:
>
>>   if (portfel1==portfel2)  //Czy maj± tyle samo pieniêdzy?
>>   if (portfel1 IS portfel2)  //Czy to ten sam portfel, czy inny?
>
> Nie.
>
> if ( portfel1->ilosc_pieniedzy()
>       == portfel2->ilosc_pieniedzy() ) // czy maj± tyle samo
>                                        // pieniêdzy
>
> Nie porównujesz "dwóch portfeli", tylko porównujesz stan dwóch
> portfeli

Aaa no to ju¿ chyba zaczynam qmaæ, co masz na my¶li :)
Je¶li mamy sobie takie co¶:

   int x = 2;
   int y = 2;

i teraz porównujemy je tak:

   if (x == y) ...

to obchodzi nas wy³±cznie fakt, ¿e warto¶ci obiektów s± takie same.
Nie obchodzi nas, ¿e s± to dwa ró¿ne obiekty przechowuj±ce t± sam±
warto¶æ. Równo¶æ warto¶ci traktujemy jako równo¶æ obiektów, a
warto¶æ uto¿samiamy z samym obiektem. O to chodzi? :>

Kolor jest typem warto¶ciowym, bo je¶li mamy:

  Kolor pierwszy = czerwony;
  Kolor drugi = czerwony;

i porównamy je:

  if (pierwszy == drugi) ...

to dla nas bêdzie to "ten sam kolor" [mimo ¿e le¿y w ró¿nych
miejscach].
Przy takim postawieniu sprawy rzeczywi¶cie portfel nie jest
typem warto¶ciowym, bo gdy zrobimy tak:

  Portfel moj  = 500; //w moim portfelu ¶pi 500 z³
  Portfel twoj = 500; //w twoim portfelu ¶pi 500 z³

to kiedy je porównujemy, domy¶lne rozumienie tego porównania
jest inne:

   if (moj == twoj) ...

bo tym razem wygl±da to jak sprawdzenie, czy to s± dwa ró¿ne
portfele, czy mo¿e ten sam, i nie obchodzi nas co jest w ¶rodku i
¿e oboje mamy tyle samo pieniêdzy w swoich portfelach.
Tutaj zawarto¶æ portfela nie jest uto¿samiana z nim samym.
Je¶li by¶my chcieli porównywaæ zawarto¶æ portfeli, to musimy
to jasno powiedzieæ:

  if (moj.zawartosc == twoj.zawartosc) ...

> (pomijaj±c ju¿ bezsens porównywania dwóch stanów z dwóch
>  ró¿nych obiektów, ale to tak na marginesie).

A tego to nie skuma³em :|

> if ( portfel1 == portfel2 ) // czy to ten sam portfel

No spox, teraz wchodzi do garka ;)

> Ja wiem, ¿e jak komu¶ odbija kolba i musi sobie nawymy¶laæ
> wypasione definicje operatorów (w tym ==), to nic siê na to
> nie poradzi, ale to bynajmniej nie powoduje, ¿e portfel
> nagle staje siê typem warto¶ciowym.

Hmm... czyli sugerujesz, ¿e w przypadku portfela robienie
z niego typu warto¶ciowego jest jakim¶ kaskaderstwem i
lepiej u¿yæ semantyki, w której jego zawarto¶æ jest osobnym
obiektem sk³adowym?

> Powtarzam: typ jest warto¶ciowy wtedy (i tylko wtedy), gdy
> to¿samo¶æ poznajemy po jego warto¶ci.

No czyli chyba ka¿dy typ podstawowy taki jest.

Hmm... a jak to jest z referencjami i wska¼nikami?
Albo tablice znakowe - ostatnio na pl.comp.lang.c by³ taki
przypadek, ¿e kole¶ porównywa³ wska¼niki do takiego samego
[ale nie tego samego] ci±gu znaków. Co¶ w stylu:

  char* str1 = "test";
  ...
  if (str1 == "test") ...

i siê dziwi³, czemu ten warunek mu siê nie spe³nia, skoro
"stringi s± te same" ;J  Mo¿e to jest pole dla twojej
teorii? :>  Bo tutaj ewidentnie kto¶ mia³ na my¶li porównanie
warto¶ci, a wysz³o mu porównanie to¿samo¶ci i to go
wpu¶ci³o w maliny.

> Je¶li wiêc ilo¶æ pieniêdzy w portfelu nie stanowi o tym,
> ¿e to ten sam portfel, to nie jest to typ warto¶ciowy.

Czyli to jest wybór arbitralny, czy jednak podyktowany
jakimi¶ w³a¶ciwo¶ciami?

>> No có¿, ale C++ ju¿ taki dziwny jest, ¿e nie ma "go³ych"
>> warto¶ci [a przynajmniej nic mi o tym nie wiadomo], tylko
>> wszystko jest trzymane w jakich¶ obiektach ;)
>
> A takie co¶ jak np. 119 to jest gdzie trzymane twoim zdaniem?

To siê zdecyduj. Niedawno jak pyta³em czy sta³e dos³owne s±
obiektami sta³ymi, czy jedynie warto¶ciami "nie opakowanymi" w
¿adnym obiekcie, to mi odpowiedzia³e¶:
 "S± obiektami sta³ymi. ¦wiadczy o tym fakt, ¿e mo¿na nimi
  inicjalizowaæ sta³e referencje."
A teraz mi tu siejesz trwogê, ¿e s± "go³ymi" warto¶ciami
nie trzymanymi nigdzie? :P
Jakby tego by³o ma³o, to mi jeszcze pó¼niej napisa³e¶, ¿e
  "Wszelkie inne sta³e dos³owne nie le¿± nigdzie w pamiêci"
No to nie rozumiem: obiekty których nigdzie nie ma? :P

>> Je¶li chodzi ci o to¿samo¶æ, to ju¿ trzeba by zapisaæ to
>> np. tak:
>>
>>    if (&x == &y) ...
>>
>> i wtedy ju¿ wiadomo, czy "x jest y" ;)
>
> I w których operacjach wynik tego porównania ma znaczenie,
> a w których nie ma?

Nie rozumiem pytania :|

> Najpro¶ciej to jest mniej wiêcej wyt³umaczyæ tak:
>
> Typ warto¶ciowy jest identyfikowany przez warto¶æ. To oznacza,
> ¿e w przypadku typów warto¶ciowych porównywanie to¿samo¶ci
> obiektów typów warto¶ciowych (o ile w ogóle jest dostêpne w
> jêzyku - w Javie np. nie jest dostêpne) nie daje ¿adnej istotnej
> informacji, tzn. takiej, na której mo¿na w czym¶ polegaæ w
> programie

No tak, w sumie masz racjê. Ale jest jedno ale: zarz±dzanie
takimi obiektami warto¶ciowymi w pamiêci. U¿ytkownik takich
obiektów mo¿e je sobie traktowaæ jak warto¶ciowe, przekazywaæ
go maj±c na my¶li jego warto¶æ, porównywaæ go maj±c na my¶li
porównanie warto¶ci, ale wci±¿ bêd± pewne czê¶ci programu,
w których chcia³by wiedzieæ, w jakim miejscu pamiêci le¿y
ten obiekt, albo czy dwa obiekty le¿± w ró¿nych miejscach
pamiêci, czy mo¿e jest to to samo miejsce pamiêci.

> W jêzykach, w których wszystko jest obiektem, typy warto¶ciowe
> s± symulowane poprzez niemodyfikowalne obiekty. To znaczy,
> ka¿dy obiekt typu warto¶ciowego musi zostaæ za ka¿dym razem
> wyprodukowany na nowo.

Hmm... co¶ mi to przypomina...
Czy obiekt klasy TrybGraficzny móg³by byæ typem warto¶ciowym?
Chodzi mi o taki obiekt przechowuj±cy informacje o parametrach
trybu graficznego. Co¶ mi siê zdaje, ¿e tak, bo tutaj:

  TrybGraficzny pierwszy = { 800, 600, 16 };
  TrybGraficzny drugi = { 800, 600, 16 };
  ...
  if (pierwszy==drugi) ...

porównanie oznacza porównanie warto¶ci, a nie to¿samo¶ci.
W moim kodzie chcia³em dodatkowo zagwarantowaæ sta³o¶æ
takich obiektów, tzn. ¿eby by³y w³a¶nie niemodyfikowalne.
Raz utworzone z pewnymi warto¶ciami maj± je ju¿ do koñca
¿ycia [bo parametry tego samego trybu graficznego nigdy
siê nie zmieniaj±]. S± one produkowane raz, przez obiekt
wyci±gaj±cy je z karty graficznej, i pó¼niej ju¿ siê
nie zmieniaj±. Mog± byæ jedynie kopiowane, ale wykonanie
kopii sprawia, ¿e mamy wci±¿ "ten sam" tryb graficzny,
tylko przechowywany w dwóch miejscach ;J
[to mia³o zagwarantowaæ, ¿e nikt niepowo³any nie stworzy
sobie w³asnego obiektu klasy TrybGraficzny z dowolnie
ustawionymi, nieprawid³owymi warto¶ciami].
Czy ten mój TrybGraficzny nie jest przypadkiem idealnym
przyk³adem typu warto¶ciowego? :J [o ile dobrze to zrozumia³em]

> W jêzykach, które naturalnie wspieraj± typy warto¶ciowe

O jakich jêzykach mowa? Wola³bym to wiedzieæ, bo wtedy
móg³bym sobie popatrzeæ jak tam to jest zrobione i mo¿e
u³atwi³oby mi to zrozumienie sprawy na przyk³adach ;)

> Oczywi¶cie teoriê typów warto¶ciowych i niewarto¶ciowych [...]
> mo¿na olaæ, je¶li kto¶ uwa¿a, ¿e mu nie pasuje. Tylko ¿e
> alternatyw± jest stwierdzenie, ¿e mamy kilka ró¿nych definicji
> porównania, kopiowanie p³ytkie i g³êbokie itd.

Móg³by¶ u¶ci¶liæ na czym polega zwi±zek typów warto¶ciowych
z p³ytkim/g³êbokim kopiowaniem?

> Nawiasem mówi±c, w Rubym spierdzielili sprawê ze stringami
> totalnie. String w ogólno¶ci jest typem warto¶ciowym - niestety
> w Rubym jest on ehm... takim dziwnie-hybrydowym. To znaczy,
> modyfikacje przenosz± siê na inne obiekty oznaczane
> identyfikatorami:
>
> a = "dupa"
> b = a
> b[0] = "p"
> print a

A czy w Javie przypadkiem nie jest tak samo?
No chyba ¿e tam siê wtedy robi kopia przy modyfikacji przez b.
Ju¿ nie pamiêtam...

--
SasQ

Dnia Mon, 19 Mar 2007 02:18:29 +0100, SasQ skrobie:
> > Nie porównujesz "dwóch portfeli", tylko porównujesz stan dwóch
> > portfeli

> Aaa no to ju¿ chyba zaczynam qmaæ, co masz na my¶li :)

No, mniej wiêcej o to chodzi.

Oczywi¶cie i tak w efekcie wszystko mo¿na po czê¶ci sprowadziæ do absurdu, ale
jedna rzecz i tak zawsze bêdzie zachowana: obiekty typów warto¶ciowych zawsze
maj± swoj± w³asn± kopiê zawarto¶ci.

>   if (moj.zawartosc == twoj.zawartosc) ...

> > (pomijaj±c ju¿ bezsens porównywania dwóch stanów z dwóch
> >  ró¿nych obiektów, ale to tak na marginesie).

> A tego to nie skuma³em :|

Jaki jest sens sprawdzania, czy dwa portfele zawieraj± tyle samo pieniêdzy?

Mo¿na, tylko po co? Je¶li ju¿, to chcemy sprawdziæ, czy np. w portfelu jest
"wystarczaj±ca ilo¶æ" pieniêdzy.

Mo¿emy nawet na upartego zrobiæ co¶ takiego (opiszê to ju¿ bardziej
abstrakcyjnie): chcemy "zbalansowaæ" jakie¶ stany z dwóch obiektów, pod
warunkiem, ¿e opisuj±one jak±¶ ilo¶æ. Chcemy wiêc sprawdziæ, czy który¶ z nich
ma warto¶æ wiêksz± ni¿ drugi. Ale robimy to w tym celu, ¿e chcemy wykonaæ
równomierne roz³o¿enie warto¶ci w obu obiektach, wiêc i tak zamiast robiæ
jakie¶ porównania, to odejmujemy warto¶ci od siebie.

W wiêkszo¶ci przypadków za¶, sprawdzenie stanu polega na porównaniu go z jak±¶
istniej±c± warto¶ci±, mo¿e sta³±, mo¿e te¿ z innym stanem, który wyznacza,
powiedzmy, wymagany "poziom" stanów - chocia¿ te¿ tam zwykle siê u¿ywa
operatora <, a nie ==.

Ja wiem, ¿e teoretycznie mo¿e taka sytuacja istnieæ, ale skoro jest ona taka
unikalna, to nie ma co mówiæ o typowo¶ci takiego porównania - jest ono w³a¶nie
czym¶ bardzo nietypowym.

> > Ja wiem, ¿e jak komu¶ odbija kolba i musi sobie nawymy¶laæ
> > wypasione definicje operatorów (w tym ==), to nic siê na to
> > nie poradzi, ale to bynajmniej nie powoduje, ¿e portfel
> > nagle staje siê typem warto¶ciowym.

> Hmm... czyli sugerujesz, ¿e w przypadku portfela robienie
> z niego typu warto¶ciowego jest jakim¶ kaskaderstwem i
> lepiej u¿yæ semantyki, w której jego zawarto¶æ jest osobnym
> obiektem sk³adowym?

I tak zwykle tak w³a¶nie jest. I nawet op³aca siê takie co¶ opakowaæ w
strukturê z bardzo istotnego powodu: w ten sposób mo¿na dostosowaæ do takiego
konta ró¿ne inne elementy definicji typu. W przeciwnym razie za ka¿dym razem
trzeba pamiêtaæ, ¿eby operacjê wykonaæ poprawnie.

> > Powtarzam: typ jest warto¶ciowy wtedy (i tylko wtedy), gdy
> > to¿samo¶æ poznajemy po jego warto¶ci.

> No czyli chyba ka¿dy typ podstawowy taki jest.

Ciep³o, ale to stwierdzenie jest nieprecyzyjne. Bo co uwa¿amy za typ
podstawowy?

> Hmm... a jak to jest z referencjami i wska¼nikami?

Referencje - je¶li chodzi o C++ - to jest akurat taki do¶æ wyj±tkowy typ. W
zasadzie to nawet nie powinien byæ uwa¿any za oddzielny typ. Jest to
podstawowa forma, w jakiej istnieje ka¿dy obiekt okre¶lany symbolem i oznacza
co¶, co ma swoje odwzorowanie w pamiêci. Wska¼nik na to co¶ wskazuje.
I wska¼nik ju¿ jest typem warto¶ciowym.

> Albo tablice znakowe - ostatnio na pl.comp.lang.c by³ taki
> przypadek, ¿e kole¶ porównywa³ wska¼niki do takiego samego
> [ale nie tego samego] ci±gu znaków. Co¶ w stylu:

>   char* str1 = "test";
>   ...
>   if (str1 == "test") ...

> i siê dziwi³, czemu ten warunek mu siê nie spe³nia, skoro
> "stringi s± te same" ;J  Mo¿e to jest pole dla twojej
> teorii? :>  Bo tutaj ewidentnie kto¶ mia³ na my¶li porównanie
> warto¶ci, a wysz³o mu porównanie to¿samo¶ci i to go
> wpu¶ci³o w maliny.

No w³a¶nie... widzisz, chodzi tutaj o to, ¿e string w sposób naturalny jest
typem warto¶ciowym i jak siê porównuje stringi, to nigdy nikomu nie chodzi o
porównanie ich to¿samo¶ci.

Tu problem polega na tym, ¿e w C nie my¶lano o specjalizowanym zastosowaniu
operatora ==, a tekst w cudzys³owiu jest tylko uproszczonym zapisem tablicy z
zerem na koñcu (a po nim przej±³ to tak C++).

> > Je¶li wiêc ilo¶æ pieniêdzy w portfelu nie stanowi o tym,
> > ¿e to ten sam portfel, to nie jest to typ warto¶ciowy.

> Czyli to jest wybór arbitralny, czy jednak podyktowany
> jakimi¶ w³a¶ciwo¶ciami?

No, gdyby portfel z t± sam± ilo¶ci± pieniêdzy by³ zawsze tym samym
portfelem... tyle ¿e wtedy portfel by³by powi±zany z warto¶ci±.

W Smalltalku na przyk³ad istnieje co¶ takiego jak "symbol", który jest
specjaln± form± napisu. Niby to samo, ale ró¿ni siê tym, ¿e ka¿dy symbol jest
unikalny. To oznacza, ¿e jak napiszesz nazwê symbolu, który ju¿ istnieje, to
ten istniej±cy zostanie znaleziony i zwrócony. W takim przypadku nie ma w
ca³ym systemie dwóch obiektów typu symbol o tej samej zawarto¶ci. W takiej
sytuacji - zauwa¿ - porównanie to¿samo¶ci daje zawsze ten sam wynik, co
porównanie zawarto¶ci.

Ale ogólnie jest to podyktowane odpowiednimi w³a¶ciwo¶ciami, szczególnie
pojêæ, jakie tworzysz w projekcie programu.

Podawa³em przyk³ad "salda" i "koloru" jako typów warto¶ciowych. Chodzi o
podobieñstwo do tych typów, i co np. jest dla ciebie tym samym. Co to znaczy,
¿e "kolor jest ten sam", co znaczy "saldo jest to samo", a co znaczy z kolei
"portfel jest ten sam"?

A je¶li i tak nie wiesz, to najpro¶ciej stwierdziæ to w ten sposób:

Utwórz a
b = a
Zmodyfikuj b

Je¶li spodziewasz siê, ¿e po takim czym¶ 'a' powinno zostaæ zmodyfikowane, to
jest to typ obiektowy.

Typy obiektowe poza tym czêsto posiadaj± powi±zania. Powi±zania te czêsto
powoduj± nawet, ¿e nie da siê ich klonowaæ. Typy warto¶ciowe nigdy nie
posiadaj± powi±zañ.

> >> No có¿, ale C++ ju¿ taki dziwny jest, ¿e nie ma "go³ych"
> >> warto¶ci [a przynajmniej nic mi o tym nie wiadomo], tylko
> >> wszystko jest trzymane w jakich¶ obiektach ;)
> >
> > A takie co¶ jak np. 119 to jest gdzie trzymane twoim zdaniem?

> To siê zdecyduj. Niedawno jak pyta³em czy sta³e dos³owne s±
> obiektami sta³ymi, czy jedynie warto¶ciami "nie opakowanymi" w
> ¿adnym obiekcie, to mi odpowiedzia³e¶:
>  "S± obiektami sta³ymi. ¦wiadczy o tym fakt, ¿e mo¿na nimi
>   inicjalizowaæ sta³e referencje."

Wzglêdem jêzyka tak. Ale fizycznie one nie musz± istnieæ.

> A teraz mi tu siejesz trwogê, ¿e s± "go³ymi" warto¶ciami
> nie trzymanymi nigdzie? :P

W praktyce tak :)

Nie no, formalnie to one oczywi¶cie s± obiektami sta³ymi, a tak¿e jest prawd±,
¿e do przechowywania warto¶ci jaki¶ obiekt musi byæ. Ale ten obiekt jest
traktowany wy³±cznie instrumeentalnie.

> Jakby tego by³o ma³o, to mi jeszcze pó¼niej napisa³e¶, ¿e
>   "Wszelkie inne sta³e dos³owne nie le¿± nigdzie w pamiêci"
> No to nie rozumiem: obiekty których nigdzie nie ma? :P

No s±. W programie ;)

Tzn. dok³adnie to jest tak: formalnie, to s± obiekty sta³e. Tzn. jeszcze
inaczej: to MOG¡ BYÆ obiekty sta³e. Problem po prostu polega na tym, ¿e co
prawda C++ pozwala ci zrobiæ tak:

const int& a = 5, & b = 5;

A nawet tak:

if ( &a == &b )

Ale to porównanie nie zwróci ci ¿adnej sensownej informacji. Mo¿e ci zwróciæ
true, mo¿e ci zwróciæ false. No dobrze, je¶li tym sta³ym nadasz ró¿ne
warto¶ci, to wtedy powinno ci zawsze zwróciæ false ;)

Litera³ zapisany w jêzyku sam z siebie jest jedynie warto¶ci±. Dopiero gdy
zostanie u¿yty, mo¿e siê z niego zrobiæ obiekt - ale dopiero gdy zostanie
u¿yty jako obiekt i dopiero w miejscu, w którym bêdzie u¿yty jako obiekt tym
obiektem bêdzie. Wcze¶niej jest tylko zapisem w programie.

> >> Je¶li chodzi ci o to¿samo¶æ, to ju¿ trzeba by zapisaæ to
> >> np. tak:
> >>
> >>    if (&x == &y) ...
> >>
> >> i wtedy ju¿ wiadomo, czy "x jest y" ;)
> >
> > I w których operacjach wynik tego porównania ma znaczenie,
> > a w których nie ma?

> Nie rozumiem pytania :|

Pytanie proste: co mo¿esz umie¶ciæ za tym 'if', ¿eby twój program mia³ sens?

> > Najpro¶ciej to jest mniej wiêcej wyt³umaczyæ tak:
> >
> > Typ warto¶ciowy jest identyfikowany przez warto¶æ. To oznacza,
> > ¿e w przypadku typów warto¶ciowych porównywanie to¿samo¶ci
> > obiektów typów warto¶ciowych (o ile w ogóle jest dostêpne w
> > jêzyku - w Javie np. nie jest dostêpne) nie daje ¿adnej istotnej
> > informacji, tzn. takiej, na której mo¿na w czym¶ polegaæ w
> > programie

> No tak, w sumie masz racjê. Ale jest jedno ale: zarz±dzanie
> takimi obiektami warto¶ciowymi w pamiêci. U¿ytkownik takich
> obiektów mo¿e je sobie traktowaæ jak warto¶ciowe, przekazywaæ
> go maj±c na my¶li jego warto¶æ, porównywaæ go maj±c na my¶li
> porównanie warto¶ci, ale wci±¿ bêd± pewne czê¶ci programu,
> w których chcia³by wiedzieæ, w jakim miejscu pamiêci le¿y
> ten obiekt, albo czy dwa obiekty le¿± w ró¿nych miejscach
> pamiêci, czy mo¿e jest to to samo miejsce pamiêci.

No ale po co?

W³a¶nie na tym polega istota typów warto¶ciowych: informacja, jak± one nios±,
to jest wy³±cznie warto¶æ. Obiekty, które s± typów warto¶ciowych, mog± zatem
pojawiaæ siê i znikaæ co chwilê, kompilator w zale¿no¶ci od opcji
optymalizacji mo¿e tych obiektów tworzyæ wiêcej, lub mniej i tak dalej. Po
prostu te obiekty s± jedynie u¿yte instrumentalnie - ich to¿samo¶æ nie powinna
ciê interesowaæ; te obiekty kompilator niech sobie tworzy, jak mu siê podoba,
a dla ciebie istotna powinna byæ tylko warto¶æ.

> > W jêzykach, w których wszystko jest obiektem, typy warto¶ciowe
> > s± symulowane poprzez niemodyfikowalne obiekty. To znaczy,
> > ka¿dy obiekt typu warto¶ciowego musi zostaæ za ka¿dym razem
> > wyprodukowany na nowo.

> Hmm... co¶ mi to przypomina...

Tak. Javowy String ;)

> Czy obiekt klasy TrybGraficzny móg³by byæ typem warto¶ciowym?
> Chodzi mi o taki obiekt przechowuj±cy informacje o parametrach
> trybu graficznego. Co¶ mi siê zdaje, ¿e tak, bo tutaj:

>   TrybGraficzny pierwszy = { 800, 600, 16 };
>   TrybGraficzny drugi = { 800, 600, 16 };
>   ...
>   if (pierwszy==drugi) ...

> porównanie oznacza porównanie warto¶ci, a nie to¿samo¶ci.

Tak, ale to nie jest jeszcze takie proste.

Tak, jak mówi³em o Smalltalkowych symbolach: mo¿esz stworzyæ grupê obiektów,
która bêdzie symbolicznie oznaczaæ okre¶lone warto¶ci.

W twoim przypadku najlepiej by by³o np. stworzyæ listê tych warto¶ci i mieæ je
jako "sta³e". Podobnie jak sta³e enum. Zaznaczasz przy tym, ¿e:

 - tylko twoja klasa ma mo¿liwo¶æ tworzenia takich obiektów. U¿ytkownikowi
   wolno jedynie korzystaæ z ju¿ gotowych
 - ka¿dy obiekt typu TrybGraficzny jest unikalny

I w takim przypadku, oczywi¶cie, najsensowniej jest, je¶li porównujesz te
obiekty po to¿samo¶ci. Tyle ¿e skoro obiekty s± unikalne, to i tak da ono ten
sam wynik, co porównanie zawarto¶ci. Ale fakt, ¿e zoptymalizowa³e¶ to na
porównanie to¿samo¶ci, to tylko kwestia implementacji.

Je¶li ilo¶æ trybów jest dynamiczna, to wtedy musisz zorganizowaæ jakie¶
mapowanie na unikalne warto¶ci (w sensie, na co¶, co jest ³atwiej porównaæ).

> W moim kodzie chcia³em dodatkowo zagwarantowaæ sta³o¶æ
> takich obiektów, tzn. ¿eby by³y w³a¶nie niemodyfikowalne.
> Raz utworzone z pewnymi warto¶ciami maj± je ju¿ do koñca
> ¿ycia [bo parametry tego samego trybu graficznego nigdy
> siê nie zmieniaj±]. S± one produkowane raz, przez obiekt
> wyci±gaj±cy je z karty graficznej, i pó¼niej ju¿ siê
> nie zmieniaj±. Mog± byæ jedynie kopiowane, ale wykonanie
> kopii sprawia, ¿e mamy wci±¿ "ten sam" tryb graficzny,
> tylko przechowywany w dwóch miejscach ;J
> [to mia³o zagwarantowaæ, ¿e nikt niepowo³any nie stworzy
> sobie w³asnego obiektu klasy TrybGraficzny z dowolnie
> ustawionymi, nieprawid³owymi warto¶ciami].
> Czy ten mój TrybGraficzny nie jest przypadkiem idealnym
> przyk³adem typu warto¶ciowego? :J [o ile dobrze to zrozumia³em]

Tak, jak najbardziej. W takim przypadku po prostu przygotowujesz zestaw
wszystkich mo¿liwych warto¶ci na pocz±tku, a potem pos³ugujesz siê do nich
wska¼nikiem jako symbolem okre¶lonego trybu.

Zauwa¿ zreszt±, co dla ciebie w praktyce oznacza stwierdzenie, ¿e "tryb
graficzny x to ten sam tryb co y".

To nie znaczy, ¿e "x i y" maj± t± sam± rozdzielczo¶æ pionow±, tê sam±
rozdzielczo¶æ poziom± i tê sam± g³êboko¶æ kolorów".

To znaczy, ¿e x np. oznacza tryb graficzny numer 4, a y te¿ tryb graficzny
numer 4. A tryb graficzny numer 4 to dopiero ma... itd.

Zauwa¿ te¿, ¿e nie wykonujesz ¿adnych operacji na obiektach typu
TrybGraficzny, które mog³yby wyprodukowaæ nowe obiekty typu TrybGraficzny.
Gddyby takie by³y, to oczywi¶cie te¿ musia³yby byæ wykonane tak, ¿eby w wyniku
dostaæ inny obiekt typu TrybGraficzny.

> > W jêzykach, które naturalnie wspieraj± typy warto¶ciowe

> O jakich jêzykach mowa? Wola³bym to wiedzieæ, bo wtedy
> móg³bym sobie popatrzeæ jak tam to jest zrobione i mo¿e
> u³atwi³oby mi to zrozumienie sprawy na przyk³adach ;)

C++, na przyk³ad. Nie mówiê, ¿e w ogóle tylko C++, bo istnieje jeszcze parê
innych, których to dotyczy.

W D jest to mo¿e nawet odrobinê lepiej zrobione (chodzi mi o "auto class").

> > Oczywi¶cie teoriê typów warto¶ciowych i niewarto¶ciowych [...]
> > mo¿na olaæ, je¶li kto¶ uwa¿a, ¿e mu nie pasuje. Tylko ¿e
> > alternatyw± jest stwierdzenie, ¿e mamy kilka ró¿nych definicji
> > porównania, kopiowanie p³ytkie i g³êbokie itd.

> Móg³by¶ u¶ci¶liæ na czym polega zwi±zek typów warto¶ciowych
> z p³ytkim/g³êbokim kopiowaniem?

Widzisz, problem polega na tym, ¿e rozró¿nienie miêdzy kopiowaniem p³ytkim, a
g³êbokim jest konieczne, bo czasem potrzebne jest nam wspó³dzielenie
wewnêtrznych danych (w tym modyfikowalnych), a czasem chcemy mieæ w³asn±
kopiê. Kopiowanie obiektów warto¶ciowych odpowiada kopiowaniu g³êbokiemu. Z t±
tylko ró¿nic±, ¿e w zale¿no¶ci od mo¿liwo¶ci jêzyka mo¿emy to zorganizowaæ
przez copy-on-write (czyli kopiowanie jest efektywnie p³ytkie, ale tylko do
pierwszej modyfikacji).

Pojêcia kopiowania p³ytkiego i g³êbokiego s± pojêciami niskiego poziomu i ich
u¿ywanie jest konieczne, je¶li jêzyk nie dostarcza ¿adnych bardziej ogólnych
narzêdzi pozwalaj±cych na zrobienie takiego typu, czy te¿ najpro¶ciej mówi±c,
programista uwa¿a, ¿e tak mu lepiej.

> > Nawiasem mówi±c, w Rubym spierdzielili sprawê ze stringami
> > totalnie. String w ogólno¶ci jest typem warto¶ciowym - niestety
> > w Rubym jest on ehm... takim dziwnie-hybrydowym. To znaczy,
> > modyfikacje przenosz± siê na inne obiekty oznaczane
> > identyfikatorami:
> >
> > a = "dupa"
> > b = a
> > b[0] = "p"
> > print a

> A czy w Javie przypadkiem nie jest tak samo?
> No chyba ¿e tam siê wtedy robi kopia przy modyfikacji przez b.
> Ju¿ nie pamiêtam...

W javie przede wszystkim tej trzeciej instrukcji nie skompilujesz.

Na tym w³a¶nie polega myk ze zorganizowaniem typu warto¶ciowego przez
niemodyfikowalny typ obiektowy.


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

Sektor van Skijlen wrote:

> A ja, jak widzê, trafi³em na kogo¶ zakompleksionego, kto musi siê
> dowarto¶ciowaæ przez pomiatanie innymi.

Ciekawa uwaga. Niejeden psycholog okre¶li³by to stwierdzenie
mianem "projekcji"
(http://pl.wikipedia.org/wiki/Projekcja_%28psychologia%29).

Gwoli informacji: ja nic nie muszê. Je¶li co¶ robiê to dlatego, ¿e chcê.

Pozdrawiam _Ciebie_ i do niezobaczenia. ¯yczê powodzenia w krzewieniu
nowej teorii nt. obiektowo¶ci.

--
Mariusz Lotko

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

[...]

> O ile sobie przypominasz, wskazywa³em ci ju¿ kiedy¶, ¿e jest mo¿liwe
> takie zorganizowanie warto¶ci ca³kowitych, ¿e ka¿dej liczbie
> odpowiada obiekt.

Nawet ca³a klasa równowa¿no¶ci.

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

[...]

> O ile sobie przypominasz, wskazywa³em ci ju¿ kiedy¶, ¿e jest mo¿liwe
> takie zorganizowanie warto¶ci ca³kowitych, ¿e ka¿dej liczbie
> odpowiada obiekt.

Nawet ca³a klasa abstrakcji zdefiniowana przez relacjê równowa¿no¶ci
okre¶lon± na parach liczb naturalnych :>

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

[...]

> Skoro tak, to nie potrzebujemy osobnych operatorów porównania -
> powinien byæ dostêpny jeden operator porównania.

Hej, ju¿ chyba wiem, o co ci chodzi.  Jedna relacja równo¶ci, a wiele
relacji równowa¿no¶ci.  Innymi s³owy -- porównanie zawarto¶ci obiektów
by³oby równoznaczne nie tyle z porównaniem tych obiektów, tylko ze
sprawdzeniem zaistnienia pomiêdzy tymi obiektami pewnej -- okre¶lonej
przez programistê -- relacji równowa¿no¶ci.

--
http://www.piotr.dembiñski.prv.pl

pdemb@gazeta.pl (Piotr Dembiñski) writes:

> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
> writes:
>
> [...]
>
>> Skoro tak, to nie potrzebujemy osobnych operatorów porównania -
>> powinien byæ dostêpny jeden operator porównania.
>
> Hej, ju¿ chyba wiem, o co ci chodzi.  Jedna relacja równo¶ci,
> a wiele relacji równowa¿no¶ci.  Innymi s³owy -- porównanie
> zawarto¶ci obiektów by³oby równoznaczne nie tyle z porównaniem tych
> obiektów, tylko ze sprawdzeniem zaistnienia pomiêdzy tymi obiektami
> pewnej -- okre¶lonej przez programistê -- relacji równowa¿no¶ci.

Innymi s³owy -- i mo¿e bardziej poprawnie -- sprawdzenia przez
komputer, czy para sprawdzanych obiektów nale¿y do klasy abstrakcji
okre¶lonej na parach obiektów przez pewn± relacjê równowa¿no¶ci.

--
http://www.piotr.dembiñski.prv.pl

Mariusz Lotko <imie.nazwisko@wp.pl> writes:

[...]

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

No to jest mutable color.

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

[...]

> (Na marginesie: to bardzo dobrze, ¿e literatura do OO twierdzi, ¿e
> programowanie obiektowe jest modelowaniem rzeczywisto¶ci. Tak bowiem
> nale¿y t± sprawê t³umaczyæ pocz±tkuj±cym. Im wiêcej jednak cz³owiek
> programuje obiektowo, tym bardziej siê przekonuje, ¿e to nie ma nic
> wspólnego z prawd±.  To jest jeden ze znaków rozpoznawczych, czy
> kto¶ potrafi my¶leæ samodzielnie rzeczywi¶cie dysponuje
> do¶wiadczeniem zawodowym, czy recytuje z pamiêci wiedzê ksi±¿kow±.)

Twierdzisz, ¿e domkniêcia i iteratory nie wystêpuj± w rzeczywisto¶ci?

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
writes:

[...]

> Typ warto¶ciowy jest typem, którego obiekt jest identyfikowany
> zawsze przez warto¶æ.

Ja to rozumiem tak, ¿e w typach warto¶ciowych warto¶æ jest
to¿samo¶ci±, a to¿samo¶æ warto¶ci±.

Dnia Wed, 21 Mar 2007 11:28:28 +0100, Piotr Dembiñski skrobie:
> pdemb@gazeta.pl (Piotr Dembiñski) writes:

> > Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
> > writes:
> >
> > [...]
> >
> >> Skoro tak, to nie potrzebujemy osobnych operatorów porównania -
> >> powinien byæ dostêpny jeden operator porównania.
> >
> > Hej, ju¿ chyba wiem, o co ci chodzi.  Jedna relacja równo¶ci,
> > a wiele relacji równowa¿no¶ci.  Innymi s³owy -- porównanie
> > zawarto¶ci obiektów by³oby równoznaczne nie tyle z porównaniem tych
> > obiektów, tylko ze sprawdzeniem zaistnienia pomiêdzy tymi obiektami
> > pewnej -- okre¶lonej przez programistê -- relacji równowa¿no¶ci.

> Innymi s³owy -- i mo¿e bardziej poprawnie -- sprawdzenia przez
> komputer, czy para sprawdzanych obiektów nale¿y do klasy abstrakcji
> okre¶lonej na parach obiektów przez pewn± relacjê równowa¿no¶ci.

O! Mo¿na to tak dok³adnie okre¶liæ.

Oczywi¶cie zak³adaj±c, ¿e "klasa abstrakcji" jest okre¶lana przez jedn± z
w³a¶ciwo¶ci dwóch obiektów.

Przy takim za³o¿eniu zreszt± te obiekty nawet mog± byæ ró¿nych klas
wyj¶ciowych.

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

Dnia Wed, 21 Mar 2007 11:55:50 +0100, Piotr Dembiñski skrobie:
> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

> [...]

> > (Na marginesie: to bardzo dobrze, ¿e literatura do OO twierdzi, ¿e
> > programowanie obiektowe jest modelowaniem rzeczywisto¶ci. Tak bowiem
> > nale¿y t± sprawê t³umaczyæ pocz±tkuj±cym. Im wiêcej jednak cz³owiek
> > programuje obiektowo, tym bardziej siê przekonuje, ¿e to nie ma nic
> > wspólnego z prawd±.  To jest jeden ze znaków rozpoznawczych, czy
> > kto¶ potrafi my¶leæ samodzielnie rzeczywi¶cie dysponuje
> > do¶wiadczeniem zawodowym, czy recytuje z pamiêci wiedzê ksi±¿kow±.)

> Twierdzisz, ¿e domkniêcia i iteratory nie wystêpuj± w rzeczywisto¶ci?

No, na przyk³ad. Co do iteratorów, to jeszcze mo¿na by siê spieraæ.

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

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
writes:

[...]

>> Twierdzisz, ¿e domkniêcia i iteratory nie wystêpuj±
>> w rzeczywisto¶ci?
>
> No, na przyk³ad. Co do iteratorów, to jeszcze mo¿na by siê spieraæ.

Domkniêcia s± jeszcze ³atwiejsze.  IMO ka¿dy nie komunikuj±cy siê
z otoczeniem, spe³niaj±cy dowoln± funkcjê komputer tworzy domkniêcie.

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
writes:

> Dnia Wed, 21 Mar 2007 11:28:28 +0100, Piotr Dembiñski skrobie:
>> pdemb@gazeta.pl (Piotr Dembiñski) writes:
>
>> > Sektor van Skijlen
>> > <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:
>> >
>> > [...]
>> >
>> >> Skoro tak, to nie potrzebujemy osobnych operatorów porównania -
>> >> powinien byæ dostêpny jeden operator porównania.
>> >
>> > Hej, ju¿ chyba wiem, o co ci chodzi.  Jedna relacja równo¶ci,
>> > a wiele relacji równowa¿no¶ci.  Innymi s³owy -- porównanie
>> > zawarto¶ci obiektów by³oby równoznaczne nie tyle z porównaniem
>> > tych obiektów, tylko ze sprawdzeniem zaistnienia pomiêdzy tymi
>> > obiektami pewnej -- okre¶lonej przez programistê -- relacji
>> > równowa¿no¶ci.
>
>> Innymi s³owy -- i mo¿e bardziej poprawnie -- sprawdzenia przez
>> komputer, czy para sprawdzanych obiektów nale¿y do klasy abstrakcji
>> okre¶lonej na parach obiektów przez pewn± relacjê równowa¿no¶ci.
>
> O! Mo¿na to tak dok³adnie okre¶liæ.
>
> Oczywi¶cie zak³adaj±c, ¿e "klasa abstrakcji" jest okre¶lana przez
> jedn± z w³a¶ciwo¶ci dwóch obiektów.

ZTCW to pojêcie klasy abstrakcji istnieje w matematyce i przynale¿y
do algebry abstrakcyjnej, nie trzeba ¿adnego cudzys³owiu.

> Przy takim za³o¿eniu zreszt± te obiekty nawet mog± byæ ró¿nych klas
> wyj¶ciowych.

No ale po to definiujemy klasy, ¿eby odzwierciedla³y pewne klasy
abstrakcji.  Plus mo¿na zawsze definiowaæ klasy abstrakcji wewn±trz
lub w poprzek klas zdefiniowanych w programie, poprzez okre¶lenie
metod porównuj±cych.

Nawiasem mówi±c to kluczowa dla refaktoryzacji relacja równoznaczno¶ci
(semantical equivalence) jest szczególnym przypadkiem relacji
równowa¿no¶ci zdefiniowanej na tekstach programów komputerowych.

--
http://www.piotr.dembiñski.prv.pl

pdemb@gazeta.pl (Piotr Dembiñski) writes:

[...]

> Nawiasem mówi±c to kluczowa dla refaktoryzacji relacja
> równoznaczno¶ci (semantical equivalence) jest szczególnym
> przypadkiem relacji równowa¿no¶ci zdefiniowanej na tekstach
> programów komputerowych.

Oczywi¶cie nie równoznaczno¶ci programów, tylko równoznaczno¶ci
odniesieñ i dzia³añ programów.

Dnia Wed, 21 Mar 2007 16:07:41 +0100, Piotr Dembiñski skrobie:
> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
> writes:

> [...]

> >> Twierdzisz, ¿e domkniêcia i iteratory nie wystêpuj±
> >> w rzeczywisto¶ci?
> >
> > No, na przyk³ad. Co do iteratorów, to jeszcze mo¿na by siê spieraæ.

> Domkniêcia s± jeszcze ³atwiejsze.  IMO ka¿dy nie komunikuj±cy siê
> z otoczeniem, spe³niaj±cy dowoln± funkcjê komputer tworzy domkniêcie.

Moment, rozwi±¿my najpierw problem niejednoznaczno¶ci okre¶lenia "domkniêcie".

Je¶li pod pojêciem "domkniêcie" masz na my¶li lokaln± funkcjê maj±c± dostêp do
¶rodowiska funkcji zewnêtrznej, to porównanie tego z komputerem odciêtym od
sieci przebija o wiele d³ugo¶ci metody porównawcze "rogatego szefa Dilberta".


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

Dnia Tue, 20 Mar 2007 18:03:10 +0000, Sektor van Skijlen napisa³(a):

> Oczywi¶cie i tak w efekcie wszystko mo¿na po czê¶ci sprowadziæ do
> absurdu, ale jedna rzecz i tak zawsze bêdzie zachowana: obiekty
> typów warto¶ciowych zawsze maj± swoj± w³asn± kopiê zawarto¶ci.

Tzn?

>>> (pomijaj±c ju¿ bezsens porównywania dwóch stanów z dwóch
>>>  ró¿nych obiektów, ale to tak na marginesie).
>>
>> A tego to nie skuma³em :|
>
> Jaki jest sens sprawdzania, czy dwa portfele zawieraj±
> tyle samo pieniêdzy?

Je¶li jeden z nich jest mój, to takie porównanie daje mi
informacjê, czy kto¶ ma tyle samo kasy co ja ;J

> Mo¿na, tylko po co? Je¶li ju¿, to chcemy sprawdziæ, czy
> np. w portfelu jest "wystarczaj±ca ilo¶æ" pieniêdzy.

Niepotrzebnie ograniczasz mo¿liwo¶ci ;)
I w³a¶nie tego nie mo¿emy zrozumieæ: twoja teoria, ¿e istnieje
podzia³ na obiekty warto¶ciowe i resztê, ma jak dla mnie sens,
ale nie mogê zrozumieæ, po co wyci±gaæ z tego jakie¶ ograniczenia.

> W wiêkszo¶ci przypadków za¶, sprawdzenie stanu polega na
> porównaniu go z jak±¶ istniej±c± warto¶ci±, mo¿e sta³±, mo¿e
> te¿ z innym stanem, który wyznacza, powiedzmy, wymagany "poziom"
> stanów - chocia¿ te¿ tam zwykle siê u¿ywa operatora <, a nie ==.

Mów trochê ja¶niej, jak chcesz ¿eby¶my zrozumieli ;)
Ja np. preferujê obrazowe wyja¶nienia na przyk³adach ;)

> Ja wiem, ¿e teoretycznie mo¿e taka sytuacja istnieæ, ale skoro
> jest ona taka unikalna, to nie ma co mówiæ o typowo¶ci takiego
> porównania - jest ono w³a¶nie czym¶ bardzo nietypowym.

Ale jest. Wiêc czemu siê ograniczaæ i go zabraniaæ? Mo¿e akurat
w tym 1 na 1000 przypadków komu¶ to bêdzie potrzebne?

>> Powtarzam: typ jest warto¶ciowy wtedy (i tylko wtedy), gdy
>> to¿samo¶æ poznajemy po jego warto¶ci.
>>
>> No czyli chyba ka¿dy typ podstawowy taki jest.
>
> Ciep³o, ale to stwierdzenie jest nieprecyzyjne. Bo co uwa¿amy
> za typ podstawowy?

:) Typy wbudowane mia³em na my¶li. Czyli te podstawowe, z których
buduje siê inne typy, bardziej z³o¿one.

>> Hmm... a jak to jest z referencjami i wska¼nikami?
>
> Referencje - je¶li chodzi o C++ - to jest akurat taki do¶æ
> wyj±tkowy typ. W zasadzie to nawet nie powinien byæ uwa¿any za
> oddzielny typ.

No tak, to raczej sposób dostêpu do obiektu, ni¿ osobny typ.

> Jest to podstawowa forma, w jakiej istnieje ka¿dy obiekt
> okre¶lany symbolem i oznacza co¶, co ma swoje odwzorowanie
> w pamiêci.

Hehe ja sobie to wyobra¿am jako etykietê ;)
Referencja to taka etykieta nadana miejscu w pamiêci. Tylko ¿e
w C++ jest to taka dodatkowa etykieta do ju¿ istniej±cego
miejsca w pamiêci, a "zwyczajne" nazwy to s± "te g³ówne" nazwy
danego miejsca w pamiêci:

  int nazwa;             Nazwa +-----------------+
                               | obiekt typu int |
                               +-----------------+

  int& ref = nazwa;      Nazwa +-----------------+
                           ref | obiekt typu int |
                               +-----------------+

I takie rozumienie siê nawet zgadza, bo u¿ywanie referencji
niczym siê w C++ nie ró¿ni sk³adniowo od u¿ywania "zwyk³ej"
nazwy obiektu. Jedynie przy przekazaniu do funkcji jako parametr
wychodzi rozró¿nienie [sztuczne? :P] polegaj±ce na tworzeniu kopii
obiektów gdy siê je przekazuje jako "zwyk³±" nazwê, i przekazywaniu
samych adresów lub inline'owanu bezpo¶redniego dostêpu gdy siê
przekazuje jako referencjê.

> Wska¼nik na to co¶ wskazuje.

Ano :J

  int* wsk = &nazwa;       wsk +------------------------+
                               | adres obiektu typu int |
                               +-----------+------------+
                                           |
                                           v
                         Nazwa +-----------------+
                           ref | obiekt typu int |
                               +-----------------+

Osobny obiekt, osobny obszar pamiêci, osobna nazwa ;J
Dlatego mo¿na te¿ mieæ referencjê wska¼nika:

  int*& refwsk = &wsk;     wsk  +------------------------+
                         refwsk | adres obiektu typu int |
                                +-----------+------------+
                                            |
                                            v
                          Nazwa +-----------------+
                            ref | obiekt typu int |
                                +-----------------+

> I wska¼nik ju¿ jest typem warto¶ciowym.

Nom, jak by nie patrzeæ to jest. Gdy przypiszê go do drugiego,
to ten drugi "przejmuje to¿samo¶æ" tego pierwszego, staje siê nim
[hehe "The return of the body switchers" :D]  Gdy je porównujê, to
nie obchodzi mnie ¿e ten drugi to osobny obiekt, tylko interesuje
mnie, czy maj± t± sam± warto¶æ [pokazuj± na to samo miejsce].
I tu rzeczywi¶cie nie wyobra¿am sobie sytuacji, w której bym
oczekiwa³ od porównania wska¼ników porównania czy s± to te same
obiekty w tym samym miejscu pamiêci, czy mo¿e le¿± w ró¿nych.
ALE.. mo¿e po prostu mam s³ab± wyobra¼niê ;)  W koñcu czasami
przekazuje siê wska¼nik przez referencjê lub jako wska¼nik do
wska¼nika, a wtedy rozchodzi siê o ich po³o¿enie w pamiêci,
a nie warto¶æ. Nie wiem tylko jak z tym porównaniem wtedy.

>> Albo tablice znakowe - ostatnio na pl.comp.lang.c by³ taki
>> przypadek, ¿e kole¶ porównywa³ wska¼niki do takiego samego
>> [ale nie tego samego] ci±gu znaków. Co¶ w stylu:
>>
>>   char* str1 = "test";
>>   ...
>>   if (str1 == "test") ...
>>
>> i siê dziwi³, czemu ten warunek mu siê nie spe³nia, skoro
>> "stringi s± te same" ;J  Mo¿e to jest pole dla twojej teorii? :>
>> Bo tutaj ewidentnie kto¶ mia³ na my¶li porównanie warto¶ci, a
>> wysz³o mu porównanie to¿samo¶ci i to go wpu¶ci³o w maliny.
>
> No w³a¶nie... widzisz, chodzi tutaj o to, ¿e string w sposób
> naturalny jest typem warto¶ciowym i jak siê porównuje stringi,
> to nigdy nikomu nie chodzi o porównanie ich to¿samo¶ci.

Chyba ¿e jest mened¿erem pamiêci zarz±dzaj±cym stringami ;)
Wtedy fakt, gdzie w pamiêci le¿y obiekt, ma wiêksze znaczenie
ni¿ to, co on zawiera. Z punktu widzenia takiego mened¿era
mo¿e byæ istotne, czy dwa obiekty to ten sam obiekt w tym
samym miejscu pamiêci, czy mo¿e le¿± w ró¿nych miejscach i
s± to ró¿ne obiekty [mimo ¿e mog± przechowywaæ t± sam± warto¶æ].
Bo np. kto¶ kaza³ mu "zwolnij TEGO stringa", i on sobie chce
porównaæ, czy "TEN string" to przypadkiem nie jest który¶ z
obs³ugiwanych przez niego, albo ¿eby nie zwolniæ dwa razy
"tego samego" stringa - i tutaj "ten sam" oznacza "le¿±cy w
tym samym miejscu pamiêci", a nie "maj±cy t± sam± warto¶æ".

Wygl±da wiêc na to, ¿e obiekt mo¿e byæ warto¶ciowy z jednego
punktu widzenia, a niewarto¶ciowy z innego punktu widzenia,
zale¿nie od tego kto i jak go rozumie i u¿ywa [zale¿nie od
interfejsu, którego u¿ywa u¿ytkownik?.. :/].

> Tu problem polega na tym, ¿e w C nie my¶lano o specjalizowanym
> zastosowaniu operatora ==

No i tego czasami brakuje. Szczególnie chcia³oby siê móc
przeci±¿yæ operator+ ¿eby mo¿liwy by³ taki zapis:

  string s;
  s = "abcd" + x + "defg" + y + "hijk";

Na szczê¶cie s± jeszcze strumienie do stringów ;J
Pewnie jako "³atka" na powy¿sze braki ;)

> a tekst w cudzys³owiu jest tylko uproszczonym zapisem tablicy
> z zerem na koñcu (a po nim przej±³ to tak C++).

To akurat jeszcze ujdzie, bo gwarantuje, ¿e bêdzie to tak samo jak
w Assemblerze i nic wiêcej nie bêdzie tam wpychane do pamiêci ;J

>> Czyli to jest wybór arbitralny, czy jednak podyktowany jakimi¶
>> w³a¶ciwo¶ciami?
>
> No, gdyby portfel z t± sam± ilo¶ci± pieniêdzy by³ zawsze tym
> samym portfelem...

Aha, czyli zale¿y od tego, jak rozumiemy ten portfel w ¶wiecie
rzeczywistym.

> Podawa³em przyk³ad "salda" i "koloru" jako typów warto¶ciowych.
> Chodzi o podobieñstwo do tych typów, i co np. jest dla ciebie
> tym samym. Co to znaczy, ¿e "kolor jest ten sam", co znaczy
> "saldo jest to samo", a co znaczy z kolei "portfel jest ten sam"?

Hmm... W takim razie o co ta ca³a dyskusja? :J  Gdy w C++ kto¶
prze³adowuje operator porównania, to implementuje sobie jedn± z
tych dwóch semantyk, zale¿nie jak mu pasuje ;J  Chce ¿eby porównanie
porównywa³o warto¶æ [przewa¿nie tak jest], to tak robi [porównuje
sk³adniki, które stanowi± widoczn± warto¶æ obu obiektów]. Chce
¿eby porównanie sprawdza³o czy obiekty s± te same - da siê zrobiæ
[hmm... porównuj±c wska¼niki this? :P nie wiem, nie znam sie a¿ tak
dobrze na tym ;J].

> A je¶li i tak nie wiesz, to najpro¶ciej stwierdziæ to w ten sposób:
>
> Utwórz a
> b = a
> Zmodyfikuj b
>
> Je¶li spodziewasz siê, ¿e po takim czym¶ 'a' powinno zostaæ
> zmodyfikowane, to jest to typ obiektowy.

Heh... w C++ to w³a¶ciwie nigdy bym siê nie spodziewa³ takiego
przebiegu zdarzeñ ;D  Gdyby tak siê dzia³o, uzna³bym to za b³±d,
bo jestem przyzwyczajony traktowaæ nazwy obiektów jako aliasy
dla ich warto¶ci, czyli tak samo jak dla typów wbudowanych ;J
Jedyny wyj±tek, gdzie ta intuicja siê zmienia, to referencje.
Je¶li b jest referencj± do a, to wszystko gra i buczy ;J

> Typy obiektowe poza tym czêsto posiadaj± powi±zania. Powi±zania
> te czêsto powoduj± nawet, ¿e nie da siê ich klonowaæ.

A to nie spotka³em siê jeszcze. Jaki¶ przyk³ad mo¿esz podaæ?

> Typy warto¶ciowe nigdy nie posiadaj± powi±zañ.

Jesoo, czemu to wszystko takimi ogólnikami gadasz? :P
Spox, mo¿e ty wiesz o czym mówisz i masz wyra¼n± wizjê o co
biega z tymi powi±zaniami, masz w g³owie jakie¶ konkretne
przyk³ady, ale nie wychodzi to poza obszar twojej g³owy, gdy
mówisz tak ogólnie :P a ja siê tego sam nie domy¶lê, co tak
naprawdê chodzi³o ci po g³owie gdy to pisa³e¶ ;J
Prosi³bym o jakie¶ bardziej konkretne przyk³ady.

>>>> No có¿, ale C++ ju¿ taki dziwny jest, ¿e nie ma "go³ych"
>>>> warto¶ci [a przynajmniej nic mi o tym nie wiadomo], tylko
>>>> wszystko jest trzymane w jakich¶ obiektach ;)
>>>
>>> A takie co¶ jak np. 119 to jest gdzie trzymane twoim zdaniem?
>>
>> To siê zdecyduj. Niedawno jak pyta³em czy sta³e dos³owne s±
>> obiektami sta³ymi, czy jedynie warto¶ciami "nie opakowanymi"
>> w ¿adnym obiekcie, to mi odpowiedzia³e¶:
>>  "S± obiektami sta³ymi. ¦wiadczy o tym fakt, ¿e mo¿na nimi
>>   inicjalizowaæ sta³e referencje."
>
> Wzglêdem jêzyka tak. Ale fizycznie one nie musz± istnieæ.

Hmm... Dla mnie obiekt to co¶, co istnieje namacalnie, czyli
zajmuje jaki¶ obszar pamiêci. Nie musi mieæ nazwy, bo s± przecie¿
obiekty anonimowe [np. te alokowane na stercie, czy obiekty
tymczasowe], ale jako¶ nie wyobra¿am sobie obiektu-ducha, którego
nie ma :|  [nie le¿y nigdzie w pamiêci]

>> A teraz mi tu siejesz trwogê, ¿e s± "go³ymi" warto¶ciami nie
>> trzymanymi nigdzie? :P
>
> W praktyce tak :)

Znów nic nie mówi±cy ogólnik ;J

> Nie no, formalnie to one oczywi¶cie s± obiektami sta³ymi, a
> tak¿e jest prawd±, ¿e do przechowywania warto¶ci jaki¶ obiekt
> musi byæ.

Ano w³a¶nie.

> Ale ten obiekt jest traktowany wy³±cznie instrumeentalnie.

Masz na my¶li co¶ w rodzaju "naczynia na warto¶æ"?

>> Jakby tego by³o ma³o, to mi jeszcze pó¼niej napisa³e¶, ¿e
>>   "Wszelkie inne sta³e dos³owne nie le¿± nigdzie w pamiêci"
>> No to nie rozumiem: obiekty których nigdzie nie ma? :P
>
> No s±. W programie ;)
>
> Tzn. dok³adnie to jest tak: formalnie, to s± obiekty sta³e.
> Tzn. jeszcze inaczej: to MOG¡ BYÆ obiekty sta³e.

Heh... zakrêcone to wszystko jak tampon w p**dzie :P
Chcia³bym to jednak dobrze zrozumieæ, dlatego spróbujê to
trochê jako¶ zrekapitulowaæ, a ty mnie popraw gdybym gdzie¶
co¶ ¼le mówi³:

Obiekt reprezentuje w programie jaki¶ element ze ¶wiata
rzeczywistego i pozwala nam siê do niego odwo³ywaæ, jako
do pewnego "czego¶" ["bytu"? :P], które "gdzie¶ tam istnieje".
Mo¿emy siê do tego "czego¶" odwo³ywaæ w programie, a to "co¶"
mo¿e nam odpowiedzieæ, zrobiæ co¶, przechowaæ jak±¶ warto¶æ itp.

Obiekty mog± posiadaæ warto¶æ, czyli aktualny stan. Je¶li ten
stan mo¿e siê zmieniaæ w czasie dzia³ania programu [mo¿emy
przypisaæ do obiektu nowy stan], to taki obiekt nazywamy
obiektem zmiennym [lub zmienn±, jak w matematyce lub w
tradycyjnym programowaniu]. Je¶li pocz±tkowego stanu obiektu
nie mo¿na zmieniaæ [nie mo¿na mu przypisaæ nowej warto¶ci], to
nazywamy go obiektem sta³ym [lub inaczej sta³±].

Zazwyczaj obiekty s± alokowane w jakim¶ ci±g³ym i jednolitym
obszarze pamiêci i tam w³a¶nie przechowuj± swój stan. S± jednak
sytuacje, w których obiekty mog± nie byæ nigdzie alokowane
[np. je¶li s± to sta³e dos³owne, lub obiekty tymczasowe].

Sta³e dos³owne to takie obiekty sta³e, które s± podane dos³ownie
w kodzie programu, "z marszu" [ang. "on-the-fly"]. Takie obiekty
nie posiadaj± nazwy, wiêc nie mo¿na siê do nich odwo³ywaæ nigdzie
indziej w programie poza miejscem, gdzie zosta³y dos³ownie podane.
Kompilator mo¿e nawet wogóle nie alokowaæ ich nigdzie w pamiêci,
tylko wplataæ w kod wynikowy wszêdzie tam, gdzie bêdzie to potrzebne,
jako czê¶æ instrukcji maszynowej, lub generowaæ bezpo¶rednio w
rejestrze je¶li tak jest szybciej. I tu jedynym wyj±tkiem s± sta³e
tekstowe, które s± alokowane w pamiêci statycznej. Jednak nawet
wtedy kompilator mo¿e zaalokowaæ kilka sta³ych tekstowych podanych
w ró¿nych miejscach programu jako jeden i ten sam obszar pamiêci,
je¶li wszystkie te sta³e tekstowe maj± t± sam± tre¶æ.

Obiekty tymczasowe to te¿ s± obiekty, które nie posiadaj± nazwy,
a kompilator mo¿e nie alokowaæ ich w pamiêci je¶li tak mu jest
wygodniej. Obiekty tymczasowe s± szczególnie zaprojektowane by
u³atwiæ kompilatorowi optymalizacje, by nie musia³y robiæ
zbytniego narzutu w sytuacji, gdy programista nie mo¿e dok³adnie
nad tym panowaæ. Je¶li zak³adamy, ¿e takie optymalizacje mog±
byæ robione dla niektórych typów obiektów [np. wbudowanych], a
dla niektórych nie [bo np. nie mieszcz± siê w rejestrze], a nie
mamy wp³ywu na to jak i kiedy kompilator bêdzie optymalizowa³,
to musimy zak³adaæ ¿e robi to zawsze i dla wszystkich obiektów
[tak na wszelki wypadek :P]. Dlatego nie da siê pobraæ adresu
obiektu tymczasowego. Tylko w ten sposób mo¿na zagwarantowaæ,
¿e kompilator bêdzie móg³ zrobiæ te optymalizacje dla ka¿dego
obiektu, dla którego uzna to za stosowne.

Zwyk³e obiekty te¿ mog± byæ w ten sposób optymalizowane, ale
tutaj ju¿ nie ma na to takiego nacisku, wiêc kompilator mo¿e
to zrobiæ tylko wtedy, gdy nie pobieramy adresu obiektu.
Je¶li siê pobiera adres obiektu, to kompilator musi zadbaæ o to,
¿eby ten obiekt by³ gdzie¶ zaalokowany. Tym razem jednak to my
mo¿emy zdecydowaæ, ¿e nie chcemy optymalizacji, pobieraj±c adres
obiektu. W przypadku obiektów tymczasowych i sta³ych dos³ownych
nie mieli¶my nad tym w³adzy - decydowa³ kompilator, a my musieli¶my
siê na to godziæ i obiecaæ, ¿e nie pobierzemy nigdy adresu takiego
obiektu nawet wtedy, gdyby jednak kompilator nie zrobi³ tej
optymalizacji i obiekt le¿a³by jednak gdzie¶ w pamiêci.

> Problem po prostu polega na tym, ¿e co prawda C++ pozwala ci
> zrobiæ tak:
>
>  const int& a = 5, & b = 5;

No spoko, od niedawna ju¿ o tym wiem ;)
Wolno przykleiæ referencjê-do-sta³ej do obiektu tymczasowego
lub sta³ej dos³ownej. Zastanawiam siê tylko, czemu w tym przypadku
nikt siê ju¿ nie martwi o optymalizacje i nieistnienie obiektów
tymczasowych/sta³ych dos³ownych w pamiêci? ;P  W czym taka referencja
jest lepsza od wska¼nika? [choæby i nawet sta³ego wska¼nika do sta³ej]
Czy wtedy obiekt jest jednak alokowany w pamiêci?
Czy mo¿e nie jest to jedynie inny zapis [bardziej dos³owny] dla
definicji obiektu sta³ego?
Bo jako¶ nie widzê ró¿nicy miêdzy tym:

   const int a = 5;           a +-----+
                                |  5  |
                                +-----+
a tym:

   const int& a = 5;          a +-----+
                                |  5  |
                                +-----+

oprócz tego, ¿e:
1. W pierwszym przypadku kompilator widzi deklaracjê nazwy "a" jako
   nazwy dla obiektu sta³ego o pocz±tkowej warto¶ci 5, wiêc alokuje
   pamiêæ pod niego, wpisuje tam 5 i zapamiêtuje sobie, ¿e do tego
   obszaru pamiêci mo¿na siê odwo³aæ poprzez nazwê "a".
2. W drugim przypadku kompilator widzi deklaracjê nazwy "a" jako
   referencji-do-sta³ej, która ma referowaæ do warto¶ci sta³ej
   dos³ownej 5, wiêc chc±c nie chc±c musi zameldowaæ t± warto¶æ
   gdzie¶ w pamiêci i przypisaæ do tego miejsca referencjê [nazwê]
   "a" zapamiêtuj±c, ¿e od tej chwili do tego obszaru pamiêci mo¿na
   siê odwo³aæ poprzez nazwê "a".

Czyli ró¿nica by by³a tylko w tym, ¿e w pierwszym przypadku kompilator
automatycznie wi±¿e nazwê obiektu z przydzielonym dla niego wcze¶niej
obszarem pamiêci, a w drugim przypadku przydziela obszar pamiêci, z
którym my sami ka¿emy mu zwi±zaæ pewn± nazwê.

Blah, zamota³em siê :PPP

> A nawet tak:
>
>  if ( &a == &b )

Hmm... o ile dobrze my¶lê, ¿e pobranie adresu referencji oznacza
pobranie adresu obszaru pamiêci, który ona referuje... to takie
porównanie bêdzie prawdziwe je¶li obie warto¶ci sta³e dos³owne
zosta³y zameldowane pod tym samym adresem?

> Ale to porównanie nie zwróci ci ¿adnej sensownej informacji.

No wtedy to rzeczywi¶cie, ma³o nam takie co¶ daje :P

> Litera³ zapisany w jêzyku sam z siebie jest jedynie warto¶ci±.

Czyli nie jest obiektem? :|
No qrka, na moje oko to jest. Dlaczego? Na rzecz obiektu powinno siê
daæ wywo³aæ metody, je¶li on jakie¶ ma. No i id±c dalej tym tropem:
obiekt dowolnego typu ma zwykle pewien zestaw metod, nawet je¶li
programista ¿adnych nie zadeklarowa³. Przyk³adem jest np. destruktor.
Dla typów wbudowanych mo¿na wywo³aæ destruktor [który wtedy nie robi
nic], np. tak:

  int x = 7;
  x.~int();    //OK

Co ciekawe, da siê to zrobiæ tak¿e dla sta³ej dos³ownej, tylko ¿e
trzeba j± uj±æ w nawiasy, ¿eby unikn±æ dziwacznej sk³adni, której
kompilator móg³by nie zrozumieæ.

  7.~int();     //b³±d sk³adni
  (7).~int();	//OK

Zastanawiam siê tylko, czy ujêcie w nawiasy nie powoduje powstania
jakiego¶ tymczasowego obiektu jako wyniku wyra¿enia w nawiasie.
Bo je¶li tak, to wniosek by³by ¿e jednak sta³e dos³owne nie s±
obiektami :P

> Dopiero gdy zostanie u¿yty, mo¿e siê z niego zrobiæ obiekt - ale
> dopiero gdy zostanie u¿yty jako obiekt i dopiero w miejscu, w
> którym bêdzie u¿yty jako obiekt tym obiektem bêdzie. Wcze¶niej
> jest tylko zapisem w programie.

No co¶ tam mi ju¿ ¶wita, ale pewno¶ci nie mam jeszcze w tym temacie :/

>> Nie rozumiem pytania :|
>
> Pytanie proste: co mo¿esz umie¶ciæ za tym 'if', ¿eby twój program
> mia³ sens?

A to ju¿ zale¿y od konkretnego przypadku. Je¶li porównywane obiekty
traktujê jako warto¶ci, wtedy nie obchodzi mnie gdzie one le¿± w
pamiêci, ale czy maj± t± sam± warto¶æ, bo to oznacza dla mnie "równo¶æ".
Je¶li zarz±dzam obiektami w pamiêci [tworzê dynamicznie, niszczê,
realokujê itp.], to wtedy nie obchodzi mnie co w nich jest, tylko ¿e
s± obiektami i gdzie w pamiêci le¿±. Wtedy równo¶æ oznacza dla mnie,
czy le¿± w tym samym miejscu pamiêci [jest to ten sam obiekt].

Np. funkcja dostaje dwa adresy obiektów i chce sprawdziæ, czy
dosta³a adresy dwóch ró¿nych obiektów, czy tego samego. Wtedy
obchodz± mnie bardziej ich to¿samo¶ci [adresy w pamiêci], ni¿
(za)warto¶ci.

Chocia¿ tu jest jeszcze jedna kwestia: wska¼nik jest traktowany
jako warto¶æ - adres. Wiêc w tym przypadku te¿ tak naprawdê
porównywane s± warto¶ci - adresy obiektów, a nie same obiekty.
Wiêc mo¿e w porównaniu zawsze chodzi o porównanie warto¶ci? :P

>> No tak, w sumie masz racjê. Ale jest jedno ale: zarz±dzanie takimi
>> obiektami warto¶ciowymi w pamiêci. U¿ytkownik takich obiektów mo¿e
>> je sobie traktowaæ jak warto¶ciowe, przekazywaæ go maj±c na my¶li
>> jego warto¶æ, porównywaæ go maj±c na my¶li porównanie warto¶ci,
>> ale wci±¿ bêd± pewne czê¶ci programu, w których chcia³by
>> wiedzieæ, w jakim miejscu pamiêci le¿y ten obiekt, albo czy dwa
>> obiekty le¿± w ró¿nych miejscach pamiêci, czy mo¿e jest to to
>> samo miejsce pamiêci.
> 
> No ale po co?

¯eby np. nie zwolniæ dwa razy tego samego obiektu
[patrz: operator przypisania i przypisanie do samego siebie].

> W³a¶nie na tym polega istota typów warto¶ciowych: informacja,
> jak± one nios±, to jest wy³±cznie warto¶æ.

Oficjalnie tak, a nieoficjalnie s± one mimo wszystko obiektami
i maj± pewn± niezale¿n± to¿samo¶æ [adres w pamiêci]. Nie zawsze
trzeba to braæ pod uwagê, ale "nie zawsze" != "nigdy" ;P

> Obiekty, które s± typów warto¶ciowych, mog± zatem pojawiaæ
> siê i znikaæ co chwilê, kompilator w zale¿no¶ci od opcji
> optymalizacji mo¿e tych obiektów tworzyæ wiêcej, lub mniej
> i tak dalej.

Hmm... jakie¶ konkretne przyk³ady? Bo znów wyobra¼nia mnie zawodzi ;J

>> Czy obiekt klasy TrybGraficzny móg³by byæ typem warto¶ciowym?
>> Chodzi mi o taki obiek przechowuj±cy informacje o parametrach trybu
>> graficznego. Co¶ mi siê zdaje, ¿e tak, bo tutaj:
> 
>>   TrybGraficzny pierwszy = { 800, 600, 16 }; TrybGraficzny drugi = {
>>   800, 600, 16 }; ...
>>   if (pierwszy==drugi) ...
> 
>> porównanie oznacza porównanie warto¶ci, a nie to¿samo¶ci.
> 
> Tak, ale to nie jest jeszcze takie proste.

O ¿esz w morde je¿a :/  A ju¿ sie cieszy³em :P

> W twoim przypadku najlepiej by by³o np. stworzyæ listê tych
> warto¶ci i mieæ je jako "sta³e".

Taki by³ w³a¶nie plan. Obiekt pewnej klasy, który reprezentuje
kartê graficzn±, mia³ sobie pobieraæ informacje o dostêpnych
na niej trybach graficznych i tworzyæ tak± sta³± dla danej karty
listê oferowanych trybów graficznych [równie¿ sta³ych]. Inne
obiekty mog³yby sobie pobraæ takie obiekty TrybGraficzny z
informacj± o danym trybie, skopiowaæ sobie takie obiekty na
w³asny u¿ytek [zapamiêtaæ gdzie¶ na boku by po chwili u¿yæ
w jakim¶ innym wywo³aniu do obiektu karty graficznej], ale
zabronione mia³o byæ tworzenie sobie przez "byle kogo" [czyt.
obiekty inne ni¿ ten co obs³uguje kartê graficzn±] nowych
obiektów klasy TrybGraficzny i modyfikowanie tych ju¿ istniej±cych
kopii skopiowanych od obiektu karty graficznej, ¿eby nie móg³
powstaæ obiekt z nieprawid³owymi danymi na temat trybu graficznego.

> Podobnie jak sta³e enum. Zaznaczasz przy tym, ¿e:
>
> - tylko twoja klasa ma mo¿liwo¶æ tworzenia takich obiektów.
>  U¿ytkownikowi wolno jedynie korzystaæ z ju¿ gotowych

No to my¶limy o tym samym, jak widaæ ;)
Szkoda, bo ju¿ my¶la³em ¿e wpad³em na co¶ oryginalnego :P ;)

> - ka¿dy obiekt typu TrybGraficzny jest unikalny

W jakim sensie "unikalny"? Niepowtarzalny? [mo¿e istnieæ tylko
jeden obiekt z tak ustawionymi parametrami trybu graficznego]?
Ja bym jednak wola³, ¿eby da³o siê je kopiowaæ, bo czasem
u¿ytkownik mo¿e woleæ sobie przechowaæ jakie¶ dane na w³asn±
rêkê, a mnie to nie robi ¿adnej szkody, dopóki te parametry
trybu pozostaj± poprawne ;J

> I w takim przypadku, oczywi¶cie, najsensowniej jest, je¶li
> porównujesz te obiekty po to¿samo¶ci.

??
Masz na my¶li ¿ebym to tak zoptymalizowa³, ¿e zamiast porównywaæ
warto¶æ [poszczególne parametry trybów], to porównywaæ adresy
ca³ych obiektów?  No, co¶ w tym jest, ale wyklucza mo¿liwo¶æ
tworzenia kopii, de facto poprawnych a wiêc nieszkodliwych ;J

> Tyle ¿e skoro obiekty s± unikalne, to i tak da ono ten sam
> wynik, co porównanie zawarto¶ci.

No otó¿ to.

> Ale fakt, ¿e zoptymalizowa³e¶ to na porównanie to¿samo¶ci,
> to tylko kwestia implementacji.

No raczej tak. U¿ytkownik nadal widzia³by to jako tryb1==tryb2.

> Je¶li ilo¶æ trybów jest dynamiczna, to wtedy musisz zorganizowaæ
> jakie¶ mapowanie na unikalne warto¶ci (w sensie, na co¶, co jest
> ³atwiej porównaæ).

Ilo¶æ trybów dla danej karty graficznej jest raczej sta³a przez
ca³y czas dzia³ania programu ;J  wiêc wystarczy jak sobie zbudujê
listê trybów przy inicjalizacji [w konstruktorze] i mo¿e ona byæ
nawet sta³a [mo¿e wystarczy nawet zwyk³a tablica ;J].

>> W moim kodzie chcia³em dodatkowo zagwarantowaæ sta³o¶æ
>> takich obiektów, tzn. ¿eby by³y w³a¶nie niemodyfikowalne.
>> Raz utworzone z pewnymi warto¶ciami maj± je ju¿ do koñca
>> ¿ycia [bo parametry tego samego trybu graficznego nigdy
>> siê nie zmieniaj±]. S± one produkowane raz, przez obiekt
>> wyci±gaj±cy je z karty graficznej, i pó¼niej ju¿ siê
>> nie zmieniaj±. Mog± byæ jedynie kopiowane, ale wykonanie
>> kopii sprawia, ¿e mamy wci±¿ "ten sam" tryb graficzny,
>> tylko przechowywany w dwóch miejscach ;J
>> [to mia³o zagwarantowaæ, ¿e nikt niepowo³any nie stworzy
>> sobie w³asnego obiektu klasy TrybGraficzny z dowolnie
>> ustawionymi, nieprawid³owymi warto¶ciami].
>> Czy ten mój TrybGraficzny nie jest przypadkiem idealnym
>> przyk³adem typu warto¶ciowego? :J [o ile dobrze to zrozumia³em]
>
> Tak, jak najbardziej. W takim przypadku po prostu przygotowujesz
> zestaw wszystkich mo¿liwych warto¶ci na pocz±tku, a potem
> pos³ugujesz siê do nich wska¼nikiem jako symbolem okre¶lonego
> trybu.

My¶la³em te¿ nad rozwi±zaniem takim, ¿eby zamiast przechowywaæ w
ka¿dym obiekcie klasy TrybGraficzny pe³ne informacje o typie, to
zrobiæ z niego co¶ na kszta³t "uchwytu" tudzie¿ "proxy". Dla
u¿ytkownika nic by to nie zmienia³o, bo nadal móg³by u¿ywaæ tego
samego interfejsu i otrzymaæ te same informacje o trybie, ale
wewnêtrznie te dane nie musia³yby wtedy byæ przechowywane w
obiekcie, tylko pobierane na ¿±danie z jednego ¼ród³a [np. z
jakiej¶ wewnêtrznej struktury danych w klasie karty graficznej].
Wtedy porównanie dwóch trybów tak¿e mo¿na by by³o przyspieszyæ,
bo zamiast porównywaæ poszczególne parametry, wystarczy³oby
porównaæ ten "numer trybu" czy te¿ wska¼nik przechowywany
wewn±trz obiektu klasy TrybGraficzny ;J

> Zauwa¿ zreszt±, co dla ciebie w praktyce oznacza stwierdzenie,
> ¿e "tryb graficzny x to ten sam tryb co y".
> 
> To nie znaczy, ¿e "x i y" maj± t± sam± rozdzielczo¶æ pionow±,
> tê sam± rozdzielczo¶æ poziom± i tê sam± g³êboko¶æ kolorów".

Jak to nie? :P  Przecie¿ o to siê w³a¶nie dok³adnie rozchodzi :P

> To znaczy, ¿e x np. oznacza tryb graficzny numer 4, a y te¿
> tryb graficzny numer 4.

No nie wiem... dla usera to jest raczej nieistotne, który ten
tryb jest tam w kolejno¶ci na karcie graficznej [jaki ma numer],
tylko w³a¶nie parametry tego trybu, i czy dwa podane tryby maj±
takie same parametry, bo wtedy s± przez u¿ytkownika traktowane
jako ten sam tryb, tylko pamiêtany w ró¿nych miejscach.

> A tryb graficzny numer 4 to dopiero ma... itd.

Hmm... po czê¶ci masz racjê, bo w wiêkszo¶ci przypadków albo
pobierany bêdzie tryb z listy i przechowywany gdzie¶, albo
bêdzie podawany spowrotem klasie karty graficznej, ¿eby np.
ustawiæ ten tryb dla ekranu monitora. Ale ju¿ gdy zechcemy
wylistowaæ dostêpne tryby, by u¿ytkownik programu móg³ sobie
wybraæ odpowiedni tryb wed³ug jego parametrów, to jednak
trzeba te informacje o trybie wydostaæ.
[i tu mam jeszcze pewne niejasno¶ci, jakie informacje bêd±
przechowywane w obiekcie TrybGraficzny: czy bêdzie to tylko
szeroko¶æ, wysoko¶æ i g³êbia kolorów, czy mo¿e jakie¶
dok³adniejsze informacje o formacie pixela itp.].

> Zauwa¿ te¿, ¿e nie wykonujesz ¿adnych operacji na obiektach
> typu TrybGraficzny, które mog³yby wyprodukowaæ nowe obiekty
> typu TrybGraficzny.

Nowe obiekty mo¿e tworzyæ jedynie obiekt, który obs³uguje
kartê graficzn±, bo tylko on zna poprawne warto¶ci i mo¿e
je wpisaæ do obiektów klasy TrybGraficzny.
Nikt inny nie powinien tworzyæ nowych obiektów, aby nie
wyprodukowa³ sobie trybu graficznego z b³êdnymi parametrami :P
Zauwa¿ jednak, ¿e tworzenie nowych mo¿e byæ dozwolone, ALE
tylko na podstawie tych ju¿ istniej±cych, poprawnych [czyli
konstrukcja kopiuj±ca jest OK, nic nie psuje]. Zabroniona
powinno byæ te¿ modyfikacja ju¿ istniej±cych obiektów.

> Gddyby takie by³y, to oczywi¶cie te¿ musia³yby byæ wykonane
> tak, ¿eby w wyniku dostaæ inny obiekt typu TrybGraficzny.

Jak inny? Nie czajê... Chyba raczej taki sam? :/

>> Móg³by¶ u¶ci¶liæ na czym polega zwi±zek typów warto¶ciowych z
>> p³ytkim/g³êbokim kopiowaniem?
>
> Widzisz, problem polega na tym, ¿e rozró¿nienie miêdzy
> kopiowaniem p³ytkim, a g³êbokim jest konieczne, bo czasem
> potrzebne jest nam wspó³dzielenie wewnêtrznych danych (w tym
> modyfikowalnych), a czasem chcemy mieæ w³asn± kopiê.

To wiem.

> Kopiowanie obiektów warto¶ciowych odpowiada kopiowaniu
> g³êbokiemu.

To ju¿ te¿ wiem, bo wspomina³e¶ o tym. Nie wiem tylko,
dlaczego tak ;J  Wska¼nik te¿ przechowuje warto¶æ, która
jest adresem innego obiektu, a ten inny obiekt nie jest
kopiowany, gdy kopiujesz wska¼nik ;J

> Pojêcia kopiowania p³ytkiego i g³êbokiego s± pojêciami niskiego
> poziomu i ich u¿ywanie jest konieczne, je¶li jêzyk nie dostarcza
> ¿adnych bardziej ogólnych narzêdzi

No ale sk±d jêzyk mia³by wiedzieæ, jak post±piæ w konkretnym
przypadku? Sk±d ma wiedzieæ, które sk³adniki mo¿e skopiowaæ
p³ytko [przepisaæ warto¶æ], a które musi g³êboko [sklonowaæ]?

-- 
SasQ

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

> Dnia Wed, 21 Mar 2007 16:07:41 +0100, Piotr Dembiñski skrobie:
>> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
>> writes:
>
>> [...]
>
>> >> Twierdzisz, ¿e domkniêcia i iteratory nie wystêpuj±
>> >> w rzeczywisto¶ci?
>> >
>> > No, na przyk³ad. Co do iteratorów, to jeszcze mo¿na by siê
>> > spieraæ.
>
>> Domkniêcia s± jeszcze ³atwiejsze.  IMO ka¿dy nie komunikuj±cy siê
>> z otoczeniem, spe³niaj±cy dowoln± funkcjê komputer tworzy
>> domkniêcie.
>
> Moment, rozwi±¿my najpierw problem niejednoznaczno¶ci okre¶lenia
> "domkniêcie".
>
> Je¶li pod pojêciem "domkniêcie" masz na my¶li lokaln± funkcjê maj±c±
> dostêp do ¶rodowiska funkcji zewnêtrznej, to porównanie tego
> z komputerem odciêtym od sieci przebija o wiele d³ugo¶ci metody
> porównawcze "rogatego szefa Dilberta".

A mi siê zawsze wydawa³o, ¿e domkniêcie to funkcja zachowuj±ca stan.

Dnia Thu, 01 Mar 2007 10:51:10 +0000, Sektor van Skijlen napisa³(a):

> Kopiowanie nie zachodzi dla obiektów typów niewarto¶ciowych, a
> jedynie dla obiektów typów warto¶ciowych. Kopiowaniu podlega
> wtedy owa "warto¶æ", która mo¿e byæ dowolnie przenoszona
> pomiêdzy poszczególnymi obiektami.
>
> Natomiast obiekty niewarto¶ciowe, jak sama nazwa wskazuje,
> warto¶ci nie maj±, wiêc one podlegaj± klonowaniu - tworzy siê
> nowy obiekt o nowej to¿samo¶ci. W obiektach warto¶ciowych
> to¿samo¶ci± jest warto¶æ.

Co¶ w temacie typów warto¶ciowych ;)
http://www.two-sdg.demon.co.uk/curbralan/papers/ValuedIdioms.pdf

--
SasQ

Jasna dupa!

Prawie rok up�yn�� od tej korespondencji, a tu nagle odpowied�! Dos�ownie
jakbym znalaz� paczk� cukierk�w mi�towych za szaf� podczas przed�wi�tecznego
sprz�tania :)

Ale ok - mog� to poci�gn�� :)

Dnia Wed, 16 Jan 2008 01:45:20 +0100, SasQ skrobie:
> Dnia Sun, 18 Mar 2007 23:11:57 +0000, Sektor van Skijlen napisa�(a):

> >>> Typ warto�ciowy jest typem, kt�rego obiekt jest identyfikowany
> >>> zawsze przez warto��. Wi�c je�li portfel z t� sam� ilo�ci�
> >>> pieni�dzy nie jest tym samym portfelem, to portfel nie jest
> >>> typem warto�ciowym.
> >
> >> Hmm... ale chyba jest dobrym przyk�adem, �e czasami chcemy go
> >> potraktowa� jako typ warto�ciowy, a czasami jako niewarto�ciowy:
> >
> >>   if (portfel1==portfel2)  //Czy maj� tyle samo pieni�dzy?
> >>   if (portfel1 IS portfel2)  //Czy to ten sam portfel, czy inny?
> >
> > Nie.
> >
> > if ( portfel1->ilosc_pieniedzy()
> >       == portfel2->ilosc_pieniedzy() ) // czy maj� tyle samo
> >                                        // pieni�dzy
> >
> > Nie por�wnujesz "dw�ch portfeli", tylko por�wnujesz stan dw�ch
> > portfeli

> Aaa no to ju� chyba zaczynam qma�, co masz na my�li :)
> Je�li mamy sobie takie co�:

>    int x = 2;
>    int y = 2;

> i teraz por�wnujemy je tak:

>    if (x == y) ...

> to obchodzi nas wy��cznie fakt, �e warto�ci obiekt�w s� takie same.

Zn�w nie do ko�ca zrozumia�e�. Przy takim podej�ciu to si� mo�emy buja� z tym
w niesko�czono��.

Oczywi�cie, to co napisa�e� powy�ej, jest prawd�, jak najbardziej, ale po
prostu zaczynasz i�� z rozumowaniem wci�� w przepa��, tylko po przeciwnej
stronie.

> Nie obchodzi nas, �e s� to dwa r�ne obiekty przechowuj�ce t� sam�
> warto��. R�wno�� warto�ci traktujemy jako r�wno�� obiekt�w, a
> warto�� uto�samiamy z samym obiektem. O to chodzi? :>

Nie. Nie ma czego� takiego, jak "r�wno�� obiekt�w".

Je�li przyjmiemy okre�lenie, �e obiekt mo�e by� obiektem warto�ciowym, to
wtedy stwierdzenie "a jest b" okre�la nam, �e a i b posiadaj� te same
warto�ci. Tylko dlatego, �e istnieje poj�cie warto�ci dla takich obiekt�w. I
dlatego w�a�nie uto�samiamy dane "a" z warto�ci�, jak� obiekt referowany przez
"a" ("referowa�" mo�na r�wnie� przez sam� nazw�, tak to nazwijmy) ma aktualnie
zapisan� w swojej wewn�trznej reprezentacji. R�wnie dobrze jednak "a" mo�e
referowa� do sta�ej i wtedy symbolicznie uto�samia si� to z sam� warto�ci�.
Nadal jednak "a jest b" b�dzie wyra�a� to samo.

Cech� obiekt�w warto�ciowych jest identyfikacja po warto�ci, to znaczy, regu�y
opisuj�ce cokolwiek z u�yciem a b�d� zawsze identyczne, gdy a zast�pisz b, pod
warunkiem, �e a == b.

> Kolor jest typem warto�ciowym, bo je�li mamy:

>   Kolor pierwszy = czerwony;
>   Kolor drugi = czerwony;

> i por�wnamy je:

>   if (pierwszy == drugi) ...

> to dla nas b�dzie to "ten sam kolor" [mimo �e le�y w r�nych
> miejscach].

Zgadza si� - a je�li u�yjesz gdzie� koloru pierwszy, to r�wnie dobrze mo�esz
u�y� koloru drugi i efekt b�dzie zawsze ten sam.

> Przy takim postawieniu sprawy rzeczywi�cie portfel nie jest
> typem warto�ciowym, bo gdy zrobimy tak:

>   Portfel moj  = 500; //w moim portfelu �pi 500 z�
>   Portfel twoj = 500; //w twoim portfelu �pi 500 z�

> to kiedy je por�wnujemy, domy�lne rozumienie tego por�wnania
> jest inne:

>    if (moj == twoj) ...

> bo tym razem wygl�da to jak sprawdzenie, czy to s� dwa r�ne
> portfele, czy mo�e ten sam, i nie obchodzi nas co jest w �rodku i
> �e oboje mamy tyle samo pieni�dzy w swoich portfelach.
> Tutaj zawarto�� portfela nie jest uto�samiana z nim samym.
> Je�li by�my chcieli por�wnywa� zawarto�� portfeli, to musimy
> to jasno powiedzie�:

>   if (moj.zawartosc == twoj.zawartosc) ...

No w�a�nie.

Wszystko ma mocny zwi�zek z tym, co dla ciebie oznacza stwierdzenie "a jest
b".

> > (pomijaj�c ju� bezsens por�wnywania dw�ch stan�w z dw�ch
> >  r�nych obiekt�w, ale to tak na marginesie).

> A tego to nie skuma�em :|

Nie no jakie� tam zastosowania do tego mo�na by znale�� - np. je�li jeden z
obiekt�w "osi�gn��" jak��-tam warto�� stanu, kt�r� osi�gn�� r�wnie� inny
obiekt, to co� tam szczeg�lnego mo�na zrobi�... po prostu rzadko tego typu
por�wnania maj� jakikolwiek sens. Zwykle por�wnuje si� to z jak�� sta��, aby
stwierdzi� jakie� warunki nt. tego stanu. Np. jaki ma sens por�wnanie
zawarto�ci jednego i drugiego portfela? Mo�na co najwy�ej sprawdzi�, czy jest
w nim "wystarczaj�co pieni�dzy" na jak�� transakcj�, ewentualnie mo�na na tych
warto�ciach wykonywa� jakie� operacje, np. zsumowa� zawarto�� dw�ch portfeli.
Ale stwierdzanie, czy w jednym portfelu jest tyle samo pieni�dzy, co w drugim,
ma akurat ma�o sensu.

> > if ( portfel1 == portfel2 ) // czy to ten sam portfel

> No spox, teraz wchodzi do garka ;)

> > Ja wiem, �e jak komu� odbija kolba i musi sobie nawymy�la�
> > wypasione definicje operator�w (w tym ==), to nic si� na to
> > nie poradzi, ale to bynajmniej nie powoduje, �e portfel
> > nagle staje si� typem warto�ciowym.

> Hmm... czyli sugerujesz, �e w przypadku portfela robienie
> z niego typu warto�ciowego jest jakim� kaskaderstwem i
> lepiej u�y� semantyki, w kt�rej jego zawarto�� jest osobnym
> obiektem sk�adowym?

Tak, dok�adnie tak. Niekoniecznie zreszt� jako obiekt sk�adowy, zwykle robi
si� do tego odpowiednie metody, kt�re t� warto�ci� operuj�. Ale ilo��
pieni�dzy jest akurat tylko jednym z istniej�cych stan�w portfela.

> > Powtarzam: typ jest warto�ciowy wtedy (i tylko wtedy), gdy
> > to�samo�� poznajemy po jego warto�ci.

> No czyli chyba ka�dy typ podstawowy taki jest.

Niekoniecznie jest to prawda we wszystkich j�zykach, ale w wielu tak.

> Hmm... a jak to jest z referencjami i wska�nikami?

To te� warto�ci. Je�li chodzi o referencj� w C++ to jest to zrobione troch�
bardziej jak trik j�zykowy, konkretnie nie ma �adnego dost�pu do warto�ci w
przypadku referncji.

Wska�nik jest warto�ci�. To, na co wska�nik wskazuje, mo�e by� obiektem (lub
funkcj�).

> Albo tablice znakowe - ostatnio na pl.comp.lang.c by� taki
> przypadek, �e kole� por�wnywa� wska�niki do takiego samego
> [ale nie tego samego] ci�gu znak�w. Co� w stylu:

>   char* str1 = "test";
>   ...
>   if (str1 == "test") ...

> i si� dziwi�, czemu ten warunek mu si� nie spe�nia, skoro
> "stringi s� te same" ;J  Mo�e to jest pole dla twojej
> teorii? :>  Bo tutaj ewidentnie kto� mia� na my�li por�wnanie
> warto�ci, a wysz�o mu por�wnanie to�samo�ci i to go
> wpu�ci�o w maliny.

Ale to nie jest kwestia tego, �e == por�wnuje warto�ci i co z nimi.

To, co w tym por�wnaniu zosta�o por�wnane to wska�niki na tablice znakowe
s�u��ce do przechowania warto�ci string�w, a nie "warto�ci string�w".

char* to nie jest "string". String to mo�e by� np. std::string.

> > Je�li wi�c ilo�� pieni�dzy w portfelu nie stanowi o tym,
> > �e to ten sam portfel, to nie jest to typ warto�ciowy.

> Czyli to jest wyb�r arbitralny, czy jednak podyktowany
> jakimi� w�a�ciwo�ciami?

Czy jeste� w stanie stwierdzi�, �e istnieje co� takiego jak "warto��" w
przypadku portfela? Czyli co� takiego, co potrafi portfel jednoznacznie
okre�li�.

> >> No c�, ale C++ ju� taki dziwny jest, �e nie ma "go�ych"
> >> warto�ci [a przynajmniej nic mi o tym nie wiadomo], tylko
> >> wszystko jest trzymane w jakich� obiektach ;)
> >
> > A takie co� jak np. 119 to jest gdzie trzymane twoim zdaniem?

> To si� zdecyduj. Niedawno jak pyta�em czy sta�e dos�owne s�
> obiektami sta�ymi, czy jedynie warto�ciami "nie opakowanymi" w
> �adnym obiekcie, to mi odpowiedzia�e�:
>  "S� obiektami sta�ymi. �wiadczy o tym fakt, �e mo�na nimi
>   inicjalizowa� sta�e referencje."
> A teraz mi tu siejesz trwog�, �e s� "go�ymi" warto�ciami
> nie trzymanymi nigdzie? :P

Same warto�ci, owszem, nie s� trzymane nigdzie. Mog� by� w okre�lonych
warunkach sta�ymi obiektami, ale sta�e obiekty typ�w warto�ciowych mo�na
uto�samia� z samymi warto�ciami.

> Jakby tego by�o ma�o, to mi jeszcze p�niej napisa�e�, �e
>   "Wszelkie inne sta�e dos�owne nie le�� nigdzie w pami�ci"
> No to nie rozumiem: obiekty kt�rych nigdzie nie ma? :P

Powiedzmy to w ten spos�b: istnieje sta�y obiekt, je�li posiada jak�� nadan�
nazw� w systemie nazw, lokalizacj�, gdzie mog� si� znajdowa� (bo mog� si�
znajdowa� np. wewn�trz innego, niekoniecznie sta�ego obiektu). Samo 119 jest
tylko symbolicznym okre�leniem warto�ci, co nie znaczy, �e nie mo�na
"sztucznie" z tego zrobi� obiektu sta�ego, przypisuj�c do sta�ej referencji.

> > Najpro�ciej to jest mniej wi�cej wyt�umaczy� tak:
> >
> > Typ warto�ciowy jest identyfikowany przez warto��. To oznacza,
> > �e w przypadku typ�w warto�ciowych por�wnywanie to�samo�ci
> > obiekt�w typ�w warto�ciowych (o ile w og�le jest dost�pne w
> > j�zyku - w Javie np. nie jest dost�pne) nie daje �adnej istotnej
> > informacji, tzn. takiej, na kt�rej mo�na w czym� polega� w
> > programie

> No tak, w sumie masz racj�. Ale jest jedno ale: zarz�dzanie
> takimi obiektami warto�ciowymi w pami�ci. U�ytkownik takich
> obiekt�w mo�e je sobie traktowa� jak warto�ciowe, przekazywa�
> go maj�c na my�li jego warto��, por�wnywa� go maj�c na my�li
> por�wnanie warto�ci, ale wci�� b�d� pewne cz�ci programu,
> w kt�rych chcia�by wiedzie�, w jakim miejscu pami�ci le�y
> ten obiekt, albo czy dwa obiekty le�� w r�nych miejscach
> pami�ci, czy mo�e jest to to samo miejsce pami�ci.

Teoretycznie jest to prawda, ale do czego mia�oby to s�u�y�?

Sensownym przyk�adem niezwyk�ego typu warto�ciowego jest string. Nikt nie
zaprzeczy, �e jest to warto�� - identyfikacja tego, czy jest to "ten sam
string" polega na sprawdzeniu, czy sk�ada si� z tych samych znak�w. Natomiast
co do miejsca w pami�ci - c�, w przypadku stringa z gcc w "pami�ci" siedzi
dok�adnie jeden wska�nik na "jak�� pami��" (w kt�rej upchni�ta jest tablica
znak�w i dodatkowe dane). Ta pami�� jest w zupe�nie innym miejscu, wi�c jakie
ma znaczenie fakt, gdzie akurat siedzi ten jeden wska�nik do tej pami�ci?

> > W j�zykach, w kt�rych wszystko jest obiektem, typy warto�ciowe
> > s� symulowane poprzez niemodyfikowalne obiekty. To znaczy,
> > ka�dy obiekt typu warto�ciowego musi zosta� za ka�dym razem
> > wyprodukowany na nowo.

> Hmm... co� mi to przypomina...
> Czy obiekt klasy TrybGraficzny m�g�by by� typem warto�ciowym?
> Chodzi mi o taki obiekt przechowuj�cy informacje o parametrach
> trybu graficznego. Co� mi si� zdaje, �e tak, bo tutaj:

>   TrybGraficzny pierwszy = { 800, 600, 16 };
>   TrybGraficzny drugi = { 800, 600, 16 };
>   ...
>   if (pierwszy==drugi) ...

> por�wnanie oznacza por�wnanie warto�ci, a nie to�samo�ci.

Oczywi�cie, jak najbardziej, ale nie tak ca�kiem prosto.

Tryb graficzny to typowy przyk�ad typu o ograniczonym zestawie warto�ci
(teoretycznie ka�dy typ warto�ciowy ma ograniczony zestaw warto�ci, ale w
przypadku takich np. BigInteger czy zwyk�ego float to si� nie sprawdza :).
Powinno si� mie� do tego celu:
 - zestaw warto�ci szybkich w obs�udze (np. liczb ca�kowitych), kt�re
   przyporz�dkowuje si� danemu trybowi
 - tablic�, gdzie dla ka�dego z tych tryb�w przechowuje si� jego
   charakterystyki

I teoretycznie m�g�by to by� nawet typ o zmiennej li�cie dopuszczalnych
warto�ci. Co oznacza, �e dysponujesz na starcie PREDEFINIOWANYM zestawem
tryb�w, kt�ry jest zebrany w okre�lonej tablicy, a zmienna przechowuje tylko
liczb� ca�kowit� okre�laj�c� jego identyfikator.

W takim przypadku pierwszy == drugi wewn�trznie por�wnuje oczywi�cie liczby
ca�kowite, ale logicznie chodzi tutaj o to, �e por�wnuje si�, czy tryb
"pierwszy" to ten sam tryb, co "drugi". Jest tak, je�li oba przechowuj�
identyfikator tego samego trybu, czyli ten sam identyfikator.

> W moim kodzie chcia�em dodatkowo zagwarantowa� sta�o��
> takich obiekt�w, tzn. �eby by�y w�a�nie niemodyfikowalne.
> Raz utworzone z pewnymi warto�ciami maj� je ju� do ko�ca
> �ycia [bo parametry tego samego trybu graficznego nigdy
> si� nie zmieniaj�]. S� one produkowane raz, przez obiekt
> wyci�gaj�cy je z karty graficznej, i p�niej ju� si�
> nie zmieniaj�. Mog� by� jedynie kopiowane, ale wykonanie
> kopii sprawia, �e mamy wci�� "ten sam" tryb graficzny,
> tylko przechowywany w dw�ch miejscach ;J
> [to mia�o zagwarantowa�, �e nikt niepowo�any nie stworzy
> sobie w�asnego obiektu klasy TrybGraficzny z dowolnie
> ustawionymi, nieprawid�owymi warto�ciami].
> Czy ten m�j TrybGraficzny nie jest przypadkiem idealnym
> przyk�adem typu warto�ciowego? :J [o ile dobrze to zrozumia�em]

Tak, ale w�a�nie dlatego najlepiej zrealizowa� go w ten spos�b, �eby m�c
dysponowa� predefiniowanym zestawem warto�ci, kt�rymi - dla wygody - operujesz
"behind the scene" odwo�uj�c si� po identyfikatorach do okre�lonych
"warto�ci".

> > W j�zykach, kt�re naturalnie wspieraj� typy warto�ciowe

> O jakich j�zykach mowa? Wola�bym to wiedzie�, bo wtedy
> m�g�bym sobie popatrze� jak tam to jest zrobione i mo�e
> u�atwi�oby mi to zrozumienie sprawy na przyk�adach ;)

Na przyk�ad C++ i C#. Java te� niby wspiera, ale tylko swoje w�asne wbudowane.
W przypadku C# zreszt� nie pami�tam jak dok�adnie jest z por�wnywaniem typ�w
struct, wi�c te� nie wiem na ile to wsparcie jest naturalne.

C++, w odr�nieniu od wielu innych j�zyk�w (co jest zreszt� cech�
odziedziczon� z C) postawi� na nierozr�nianie typ�w warto�ciowych i
niewarto�ciowych, pozostawiaj�c to u�ytkownikowi. Konsekwencj� tego jednak
jest konieczno�� stosowania * i & w przypadku typ�w niewarto�ciowych. R�ni go
to od C# i Javy, gdzie postawiono na rozr�nianie tych typ�w, niestety
paskudn� konsekwencj� w przypadku Javy (przyk�adowo) jest fakt, �e typ�w
warto�ciowych nie mo�na definiowa�, a nadomiar z�ego typ w naturalnie spos�b
warto�ciowy String jest w Javie zrobiony jako niewarto�ciowy - przez co Java
jest do dzi� chyba jedynym j�zykiem, w kt�rym jedynym bezpiecznym sposobem
sprawdzenia, czy string s jest niepusty, jest:

if ( !"".equals( s ) )

co w ka�dym normalnym j�zyku (Qrczak by doda� "oraz C++" :) pisze si�:

if ( s != "" )

A dodatkowo Java i C# do��czy�y rado�nie do j�zyka C w gronie j�zyk�w, kt�re
rozr�niaj� "null string" i "pusty string". Ja swojego wsp�pracownika w
projekcie (lepiej si� znaj�cego na Javie) za nic tak nie goni�em, jak za
dopuszczanie do powstawania "null string".

> > Oczywi�cie teori� typ�w warto�ciowych i niewarto�ciowych [...]
> > mo�na ola�, je�li kto� uwa�a, �e mu nie pasuje. Tylko �e
> > alternatyw� jest stwierdzenie, �e mamy kilka r�nych definicji
> > por�wnania, kopiowanie p�ytkie i g��bokie itd.

> M�g�by� u�ci�li� na czym polega zwi�zek typ�w warto�ciowych
> z p�ytkim/g��bokim kopiowaniem?

Zwi�zek jest dok�adnie �aden.

Albo stosujemy teori� typ�w warto�ciowych i niewarto�ciowych (i wtedy m�wimy o
kopiowaniu warto�ci, w tym warto�ci tych typ�w lub warto�ci
referencji/wska�nika, a w przypadku typ�w niewarto�ciowych co najwy�ej o
klonowaniu, kt�re dodatkowo nie musi by� operacj� dost�pn� dla ka�dego typu
lub niekoniecznie tworzy� faktycznie wiern� kopi� swojego wzorca), albo
twierdzimy, �e to nam jest niepotrzebne i wtedy m�czymy si� z poj�ciami
p�ytkiego i g��bokiego kopiowania i uwa�amy, �eby kopiowa� tam, a nie kopiowa�
tu itd.

> > Nawiasem m�wi�c, w Rubym spierdzielili spraw� ze stringami
> > totalnie. String w og�lno�ci jest typem warto�ciowym - niestety
> > w Rubym jest on ehm... takim dziwnie-hybrydowym. To znaczy,
> > modyfikacje przenosz� si� na inne obiekty oznaczane
> > identyfikatorami:
> >
> > a = "dupa"
> > b = a
> > b[0] = "p"
> > print a

> A czy w Javie przypadkiem nie jest tak samo?
> No chyba �e tam si� wtedy robi kopia przy modyfikacji przez b.
> Ju� nie pami�tam...

To zale�y.

W Javie przytomnie zdecydowano, �e String jest typem sta�ym (nie mo�na
modyfikowa� tego obiektu w miejscu - obiekt typu string posiada swoj� tablic�
znak�w nadan� w momencie tworzenia once forever). Natomiast StringBuffer i
StringBuilder jak najbardziej (nazwy tych typ�w zas�uguj� na osobny w�tek: oba
robi� dok�adnie to samo i maj� nawet chyba taki sam interfejs, a r�ni� si�
tylko tym, �e w jednym z nich operacje s� synchronizowane: kt�ry to z nich,
kto potrafi odpowiedzie� z pami�ci?).


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

We hate the truth, and they hide it from
us. We desire flattery, and they flatter us. We like to be deceived, and
they deceive us.

So each degree of good fortune which raises us in the world removes us
farther from truth, because we are most afraid of wounding those whose
affection is most useful and whose dislike is most dangerous. A prince may
be the byword of all Europe, and he alone will know nothing of it. I am not
astonished. To tell the truth is useful to those to whom it is spoken, but
disadvantageous to those who tell it, because it makes them disliked. Now
those who live with princes love their own interests more than that of the
prince whom they serve; and so they take care not to confer on him a benefit
so as to injure themselves.

This evil is no doubt greater and more common among the higher classes; but
the lower are not exempt from it, since there is always some advantage in
making men love us. Human life is thus only a perpetual illusion; men
deceive and flatter each other. No one speaks of us in our presence as he
does of us in our absence. Human society is founded on mutual deceit; few
friendships would endure if each knew what his friend said of him in his
absence, although he then spoke in sincerity and without passion.

Man is, then, only disguise, falsehood, and hypocrisy, both in himself and
in regard to others. He does not wish any one to tell him the truth; he
avoids telling it to others, and all these dispositions, so removed from
justice and reason, have a natural root in his heart.

101. I set it down as a fact that if all men knew what each said of the
other, there would not be four friends in the world. This is apparent from
the quarrels which arise from the indiscreet tales told from time to time. I
say, further, all men would be...

102. Some vices only lay hold of us by means of others, and these, like
branches, fall on removal of the trunk.

103. The example of Alexander's chastity has not ma

because they do not pray.

Et tu conversus confirma fratres tuos. But before, conversus Jesus respexit
Petrum.147

Saint Peter asks permission to strike Malchus and strikes before hearing the
answer. Jesus Christ replies afterwards.

The word, Galilee, which the mob pronounced as if by chance, in accusing
Jesus Christ before Pilate, afforded Pilate a reason for sending Jesus
Christ to Herod. And thereby the mystery was accomplished, that He should be
judged by Jews and Gentiles. Chance was apparently the cause of the
accomplishment of the mystery.

745. Those who have a difficulty in believing seek a reason in the fact that
the Jews do not believe. "Were this so clear," say they, "why did the Jews
not believe"? And they almost wish that they had believed, so as not to be
kept back by the example of their refusal. But it is their very refusal that
is the foundation of our faith. We should be much less disposed to the
faith, if they were on our side. We should then have a more ample pretext.
The wonderful thing is to have made the Jews great lovers of the things
foretold, and great enemies of their fulfilment.

746. The Jews were accustomed to great and striking miracles, and so, having
had the great miracles of the Red Sea and of the land of Canaan as an
epitome of the great deeds of their Messiah, they therefore looked for more
striking miracles, of which those of Moses were only the patterns.

747. The carnal Jews and the heathen have their calamities, and Christians
also. There is no Redeemer for the heathen, for they do not so much as hope
for one. There is no Redeemer for the Jews; they hope for Him in vain. There
is a Redeemer only for Christians

Sektor van Skijlen wrote:
> Jasna dupa!
>
> Prawie rok up�yn�� od tej korespondencji, a tu nagle odpowied�! Dos�ownie
> jakbym znalaz� paczk� cukierk�w mi�towych za szaf� podczas przed�wi�tecznego
> sprz�tania :)
>
> Ale ok - mog� to poci�gn�� :)
>
> Dnia Wed, 16 Jan 2008 01:45:20 +0100, SasQ skrobie:
>> Dnia Sun, 18 Mar 2007 23:11:57 +0000, Sektor van Skijlen napisa�(a):
>
>>>>> Typ warto�ciowy jest typem, kt�rego obiekt jest identyfikowany
>>>>> zawsze przez warto��. Wi�c je�li portfel z t� sam� ilo�ci�
>>>>> pieni�dzy nie jest tym samym portfelem, to portfel nie jest
>>>>> typem warto�ciowym.
>>>> Hmm... ale chyba jest dobrym przyk�adem, �e czasami chcemy go
>>>> potraktowa� jako typ warto�ciowy, a czasami jako niewarto�ciowy:
>>>>   if (portfel1==portfel2)  //Czy maj� tyle samo pieni�dzy?
>>>>   if (portfel1 IS portfel2)  //Czy to ten sam portfel, czy inny?
>>> Nie.
>>>
>>> if ( portfel1->ilosc_pieniedzy()
>>>       == portfel2->ilosc_pieniedzy() ) // czy maj� tyle samo
>>>                                        // pieni�dzy
>>>
>>> Nie por�wnujesz "dw�ch portfeli", tylko por�wnujesz stan dw�ch
>>> portfeli
>
>> Aaa no to ju� chyba zaczynam qma�, co masz na my�li :)
>> Je�li mamy sobie takie co�:
>
>>    int x = 2;
>>    int y = 2;
>
>> i teraz por�wnujemy je tak:
>
>>    if (x == y) ...
>
>> to obchodzi nas wy��cznie fakt, �e warto�ci obiekt�w s� takie same.
>
> Zn�w nie do ko�ca zrozumia�e�. Przy takim podej�ciu to si� mo�emy buja� z tym
> w niesko�czono��.
>
> Oczywi�cie, to co napisa�e� powy�ej, jest prawd�, jak najbardziej, ale po
> prostu zaczynasz i�� z rozumowaniem wci�� w przepa��, tylko po przeciwnej
> stronie.
>
>> Nie obchodzi nas, �e s� to dwa r�ne obiekty przechowuj�ce t� sam�
>> warto��. R�wno�� warto�ci traktujemy jako r�wno�� obiekt�w, a
>> warto�� uto�samiamy z samym obiektem. O to chodzi? :>
>
> Nie. Nie ma czego� takiego, jak "r�wno�� obiekt�w".
>
> Je�li przyjmiemy okre�lenie, �e obiekt mo�e by� obiektem warto�ciowym, to
> wtedy stwierdzenie "a jest b" okre�la nam, �e a i b posiadaj� te same
> warto�ci. Tylko dlatego, �e istnieje poj�cie warto�ci dla takich obiekt�w. I
> dlatego w�a�nie uto�samiamy dane "a" z warto�ci�, jak� obiekt referowany przez
> "a" ("referowa�" mo�na r�wnie� przez sam� nazw�, tak to nazwijmy) ma aktualnie
> zapisan� w swojej wewn�trznej reprezentacji. R�wnie dobrze jednak "a" mo�e
> referowa� do sta�ej i wtedy symbolicznie uto�samia si� to z sam� warto�ci�.
> Nadal jednak "a jest b" b�dzie wyra�a� to samo.
>
> Cech� obiekt�w warto�ciowych jest identyfikacja po warto�ci, to znaczy, regu�y
> opisuj�ce cokolwiek z u�yciem a b�d� zawsze identyczne, gdy a zast�pisz b, pod
> warunkiem, �e a == b.
>
>> Kolor jest typem warto�ciowym, bo je�li mamy:
>
>>   Kolor pierwszy = czerwony;
>>   Kolor drugi = czerwony;
>
>> i por�wnamy je:
>
>>   if (pierwszy == drugi) ...
>
>> to dla nas b�dzie to "ten sam kolor" [mimo �e le�y w r�nych
>> miejscach].
>
> Zgadza si� - a je�li u�yjesz gdzie� koloru pierwszy, to r�wnie dobrze mo�esz
> u�y� koloru drugi i efekt b�dzie zawsze ten sam.
>
>> Przy takim postawieniu sprawy rzeczywi�cie portfel nie jest
>> typem warto�ciowym, bo gdy zrobimy tak:
>
>>   Portfel moj  = 500; //w moim portfelu �pi 500 z�
>>   Portfel twoj = 500; //w twoim portfelu �pi 500 z�
>
>> to kiedy je por�wnujemy, domy�lne rozumienie tego por�wnania
>> jest inne:
>
>>    if (moj == twoj) ...
>
>> bo tym razem wygl�da to jak sprawdzenie, czy to s� dwa r�ne
>> portfele, czy mo�e ten sam, i nie obchodzi nas co jest w �rodku i
>> �e oboje mamy tyle samo pieni�dzy w swoich portfelach.
>> Tutaj zawarto�� portfela nie jest uto�samiana z nim samym.
>> Je�li by�my chcieli por�wnywa� zawarto�� portfeli, to musimy
>> to jasno powiedzie�:
>
>>   if (moj.zawartosc == twoj.zawartosc) ...
>
> No w�a�nie.
>
> Wszystko ma mocny zwi�zek z tym, co dla ciebie oznacza stwierdzenie "a jest
> b".
>
>>> (pomijaj�c ju� bezsens por�wnywania dw�ch stan�w z dw�ch
>>>  r�nych obiekt�w, ale to tak na marginesie).
>
>> A tego to nie skuma�em :|
>
> Nie no jakie� tam zastosowania do tego mo�na by znale�� - np. je�li jeden z
> obiekt�w "osi�gn��" jak��-tam warto�� stanu, kt�r� osi�gn�� r�wnie� inny
> obiekt, to co� tam szczeg�lnego mo�na zrobi�... po prostu rzadko tego typu
> por�wnania maj� jakikolwiek sens. Zwykle por�wnuje si� to z jak�� sta��, aby
> stwierdzi� jakie� warunki nt. tego stanu. Np. jaki ma sens por�wnanie
> zawarto�ci jednego i drugiego portfela? Mo�na co najwy�ej sprawdzi�, czy jest
> w nim "wystarczaj�co pieni�dzy" na jak�� transakcj�, ewentualnie mo�na na tych
> warto�ciach wykonywa� jakie� operacje, np. zsumowa� zawarto�� dw�ch portfeli.
> Ale stwierdzanie, czy w jednym portfelu jest tyle samo pieni�dzy, co w drugim,
> ma akurat ma�o sensu.
>
>>> if ( portfel1 == portfel2 ) // czy to ten sam portfel
>
>> No spox, teraz wchodzi do garka ;)
>
>>> Ja wiem, �e jak komu� odbija kolba i musi sobie nawymy�la�
>>> wypasione definicje operator�w (w tym ==), to nic si� na to
>>> nie poradzi, ale to bynajmniej nie powoduje, �e portfel
>>> nagle staje si� typem warto�ciowym.
>
>> Hmm... czyli sugerujesz, �e w przypadku portfela robienie
>> z niego typu warto�ciowego jest jakim� kaskaderstwem i
>> lepiej u�y� semantyki, w kt�rej jego zawarto�� jest osobnym
>> obiektem sk�adowym?
>
> Tak, dok�adnie tak. Niekoniecznie zreszt� jako obiekt sk�adowy, zwykle robi
> si� do tego odpowiednie metody, kt�re t� warto�ci� operuj�. Ale ilo��
> pieni�dzy jest akurat tylko jednym z istniej�cych stan�w portfela.
>
>>> Powtarzam: typ jest warto�ciowy wtedy (i tylko wtedy), gdy
>>> to�samo�� poznajemy po jego warto�ci.
>
>> No czyli chyba ka�dy typ podstawowy taki jest.
>
> Niekoniecznie jest to prawda we wszystkich j�zykach, ale w wielu tak.
>
>> Hmm... a jak to jest z referencjami i wska�nikami?
>
> To te� warto�ci. Je�li chodzi o referencj� w C++ to jest to zrobione troch�
> bardziej jak trik j�zykowy, konkretnie nie ma �adnego dost�pu do warto�ci w
> przypadku referncji.
>
> Wska�nik jest warto�ci�. To, na co wska�nik wskazuje, mo�e by� obiektem (lub
> funkcj�).
>
>> Albo tablice znakowe - ostatnio na pl.comp.lang.c by� taki
>> przypadek, �e kole� por�wnywa� wska�niki do takiego samego
>> [ale nie tego samego] ci�gu znak�w. Co� w stylu:
>
>>   char* str1 = "test";
>>   ...
>>   if (str1 == "test") ...
>
>> i si� dziwi�, czemu ten warunek mu si� nie spe�nia, skoro
>> "stringi s� te same" ;J  Mo�e to jest pole dla twojej
>> teorii? :>  Bo tutaj ewidentnie kto� mia� na my�li por�wnanie
>> warto�ci, a wysz�o mu por�wnanie to�samo�ci i to go
>> wpu�ci�o w maliny.
>
> Ale to nie jest kwestia tego, �e == por�wnuje warto�ci i co z nimi.
>
> To, co w tym por�wnaniu zosta�o por�wnane to wska�niki na tablice znakowe
> s�u��ce do przechowania warto�ci string�w, a nie "warto�ci string�w".
>
> char* to nie jest "string". String to mo�e by� np. std::string.
>
>>> Je�li wi�c ilo�� pieni�dzy w portfelu nie stanowi o tym,
>>> �e to ten sam portfel, to nie jest to typ warto�ciowy.
>
>> Czyli to jest wyb�r arbitralny, czy jednak podyktowany
>> jakimi� w�a�ciwo�ciami?
>
> Czy jeste� w stanie stwierdzi�, �e istnieje co� takiego jak "warto��" w
> przypadku portfela? Czyli co� takiego, co potrafi portfel jednoznacznie
> okre�li�.
>
>>>> No c�, ale C++ ju� taki dziwny jest, �e nie ma "go�ych"
>>>> warto�ci [a przynajmniej nic mi o tym nie wiadomo], tylko
>>>> wszystko jest trzymane w jakich� obiektach ;)
>>> A takie co� jak np. 119 to jest gdzie trzymane twoim zdaniem?
>
>> To si� zdecyduj. Niedawno jak pyta�em czy sta�e dos�owne s�
>> obiektami sta�ymi, czy jedynie warto�ciami "nie opakowanymi" w
>> �adnym obiekcie, to mi odpowiedzia�e�:
>>  "S� obiektami sta�ymi. �wiadczy o tym fakt, �e mo�na nimi
>>   inicjalizowa� sta�e referencje."
>> A teraz mi tu siejesz trwog�, �e s� "go�ymi" warto�ciami
>> nie trzymanymi nigdzie? :P
>
> Same warto�ci, owszem, nie s� trzymane nigdzie. Mog� by� w okre�lonych
> warunkach sta�ymi obiektami, ale sta�e obiekty typ�w warto�ciowych mo�na
> uto�samia� z samymi warto�ciami.
>
>> Jakby tego by�o ma�o, to mi jeszcze p�niej napisa�e�, �e
>>   "Wszelkie inne sta�e dos�owne nie le�� nigdzie w pami�ci"
>> No to nie rozumiem: obiekty kt�rych nigdzie nie ma? :P
>
> Powiedzmy to w ten spos�b: istnieje sta�y obiekt, je�li posiada jak�� nadan�
> nazw� w systemie nazw, lokalizacj�, gdzie mog� si� znajdowa� (bo mog� si�
> znajdowa� np. wewn�trz innego, niekoniecznie sta�ego obiektu). Samo 119 jest
> tylko symbolicznym okre�leniem warto�ci, co nie znaczy, �e nie mo�na
> "sztucznie" z tego zrobi� obiektu sta�ego, przypisuj�c do sta�ej referencji.
>
>>> Najpro�ciej to jest mniej wi�cej wyt�umaczy� tak:
>>>
>>> Typ warto�ciowy jest identyfikowany przez warto��. To oznacza,
>>> �e w przypadku typ�w warto�ciowych por�wnywanie to�samo�ci
>>> obiekt�w typ�w warto�ciowych (o ile w og�le jest dost�pne w
>>> j�zyku - w Javie np. nie jest dost�pne) nie daje �adnej istotnej
>>> informacji, tzn. takiej, na kt�rej mo�na w czym� polega� w
>>> programie
>
>> No tak, w sumie masz racj�. Ale jest jedno ale: zarz�dzanie
>> takimi obiektami warto�ciowymi w pami�ci. U�ytkownik takich
>> obiekt�w mo�e je sobie traktowa� jak warto�ciowe, przekazywa�
>> go maj�c na my�li jego warto��, por�wnywa� go maj�c na my�li
>> por�wnanie warto�ci, ale wci�� b�d� pewne cz�ci programu,
>> w kt�rych chcia�by wiedzie�, w jakim miejscu pami�ci le�y
>> ten obiekt, albo czy dwa obiekty le�� w r�nych miejscach
>> pami�ci, czy mo�e jest to to samo miejsce pami�ci.
>
> Teoretycznie jest to prawda, ale do czego mia�oby to s�u�y�?
>
> Sensownym przyk�adem niezwyk�ego typu warto�ciowego jest string. Nikt nie
> zaprzeczy, �e jest to warto�� - identyfikacja tego, czy jest to "ten sam
> string" polega na sprawdzeniu, czy sk�ada si� z tych samych znak�w. Natomiast
> co do miejsca w pami�ci - c�, w przypadku stringa z gcc w "pami�ci" siedzi
> dok�adnie jeden wska�nik na "jak�� pami��" (w kt�rej upchni�ta jest tablica
> znak�w i dodatkowe dane). Ta pami�� jest w zupe�nie innym miejscu, wi�c jakie
> ma znaczenie fakt, gdzie akurat siedzi ten jeden wska�nik do tej pami�ci?
>
>>> W j�zykach, w kt�rych wszystko jest obiektem, typy warto�ciowe
>>> s� symulowane poprzez niemodyfikowalne obiekty. To znaczy,
>>> ka�dy obiekt typu warto�ciowego musi zosta� za ka�dym razem
>>> wyprodukowany na nowo.
>
>> Hmm... co� mi to przypomina...
>> Czy obiekt klasy TrybGraficzny m�g�by by� typem warto�ciowym?
>> Chodzi mi o taki obiekt przechowuj�cy informacje o parametrach
>> trybu graficznego. Co� mi si� zdaje, �e tak, bo tutaj:
>
>>   TrybGraficzny pierwszy = { 800, 600, 16 };
>>   TrybGraficzny drugi = { 800, 600, 16 };
>>   ...
>>   if (pierwszy==drugi) ...
>
>> por�wnanie oznacza por�wnanie warto�ci, a nie to�samo�ci.
>
> Oczywi�cie, jak najbardziej, ale nie tak ca�kiem prosto.
>
> Tryb graficzny to typowy przyk�ad typu o ograniczonym zestawie warto�ci
> (teoretycznie ka�dy typ warto�ciowy ma ograniczony zestaw warto�ci, ale w
> przypadku takich np. BigInteger czy zwyk�ego float to si� nie sprawdza :).
> Powinno si� mie� do tego celu:
>  - zestaw warto�ci szybkich w obs�udze (np. liczb ca�kowitych), kt�re
>    przyporz�dkowuje si� danemu trybowi
>  - tablic�, gdzie dla ka�dego z tych tryb�w przechowuje si� jego
>    charakterystyki
>
> I teoretycznie m�g�by to by� nawet typ o zmiennej li�cie dopuszczalnych
> warto�ci. Co oznacza, �e dysponujesz na starcie PREDEFINIOWANYM zestawem
> tryb�w, kt�ry jest zebrany w okre�lonej tablicy, a zmienna przechowuje tylko
> liczb� ca�kowit� okre�laj�c� jego identyfikator.
>
> W takim przypadku pierwszy == drugi wewn�trznie por�wnuje oczywi�cie liczby
> ca�kowite, ale logicznie chodzi tutaj o to, �e por�wnuje si�, czy tryb
> "pierwszy" to ten sam tryb, co "drugi". Jest tak, je�li oba przechowuj�
> identyfikator tego samego trybu, czyli ten sam identyfikator.
>
>> W moim kodzie chcia�em dodatkowo zagwarantowa� sta�o��
>> takich obiekt�w, tzn. �eby by�y w�a�nie niemodyfikowalne.
>> Raz utworzone z pewnymi warto�ciami maj� je ju� do ko�ca
>> �ycia [bo parametry tego samego trybu graficznego nigdy
>> si� nie zmieniaj�]. S� one produkowane raz, przez obiekt
>> wyci�gaj�cy je z karty graficznej, i p�niej ju� si�
>> nie zmieniaj�. Mog� by� jedynie kopiowane, ale wykonanie
>> kopii sprawia, �e mamy wci�� "ten sam" tryb graficzny,
>> tylko przechowywany w dw�ch miejscach ;J
>> [to mia�o zagwarantowa�, �e nikt niepowo�any nie stworzy
>> sobie w�asnego obiektu klasy TrybGraficzny z dowolnie
>> ustawionymi, nieprawid�owymi warto�ciami].
>> Czy ten m�j TrybGraficzny nie jest przypadkiem idealnym
>> przyk�adem typu warto�ciowego? :J [o ile dobrze to zrozumia�em]
>
> Tak, ale w�a�nie dlatego najlepiej zrealizowa� go w ten spos�b, �eby m�c
> dysponowa� predefiniowanym zestawem warto�ci, kt�rymi - dla wygody - operujesz
> "behind the scene" odwo�uj�c si� po identyfikatorach do okre�lonych
> "warto�ci".
>
>>> W j�zykach, kt�re naturalnie wspieraj� typy warto�ciowe
>
>> O jakich j�zykach mowa? Wola�bym to wiedzie�, bo wtedy
>> m�g�bym sobie popatrze� jak tam to jest zrobione i mo�e
>> u�atwi�oby mi to zrozumienie sprawy na przyk�adach ;)
>
> Na przyk�ad C++ i C#. Java te� niby wspiera, ale tylko swoje w�asne wbudowane.
> W przypadku C# zreszt� nie pami�tam jak dok�adnie jest z por�wnywaniem typ�w
> struct, wi�c te� nie wiem na ile to wsparcie jest naturalne.
>
> C++, w odr�nieniu od wielu innych j�zyk�w (co jest zreszt� cech�
> odziedziczon� z C) postawi� na nierozr�nianie typ�w warto�ciowych i
> niewarto�ciowych, pozostawiaj�c to u�ytkownikowi. Konsekwencj� tego jednak
> jest konieczno�� stosowania * i & w przypadku typ�w niewarto�ciowych. R�ni go
> to od C# i Javy, gdzie postawiono na rozr�nianie tych typ�w, niestety
> paskudn� konsekwencj� w przypadku Javy (przyk�adowo) jest fakt, �e typ�w
> warto�ciowych nie mo�na definiowa�, a nadomiar z�ego typ w naturalnie spos�b
> warto�ciowy String jest w Javie zrobiony jako niewarto�ciowy - przez co Java
> jest do dzi� chyba jedynym j�zykiem, w kt�rym jedynym bezpiecznym sposobem
> sprawdzenia, czy string s jest niepusty, jest:
>
> if ( !"".equals( s ) )

niekoniecznie lepiej wyglada tak: s.equals("")
albo w ogole s.isEmpty()

Dnia Tue, 01 Apr 2008 19:39:25 +0100, Radoslaw Jocz skrobie:
> > warto�ciowy String jest w Javie zrobiony jako niewarto�ciowy - przez co Java
> > jest do dzi� chyba jedynym j�zykiem, w kt�rym jedynym bezpiecznym sposobem
> > sprawdzenia, czy string s jest niepusty, jest:
> >
> > if ( !"".equals( s ) )

> niekoniecznie lepiej wyglada tak: s.equals("")
> albo w ogole s.isEmpty()

�adniej wygl�da, oczywi�cie, tylko ma paskudn� wad� - je�li s jest null to
rzuca NullPointerException.


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

Dnia Wed, 02 Apr 2008 09:54:47 +0200, Piotr Kobzda skrobie:
> Sektor van Skijlen wrote:
> > Dnia Tue, 01 Apr 2008 19:39:25 +0100, Radoslaw Jocz skrobie:
> >>> warto�ciowy String jest w Javie zrobiony jako niewarto�ciowy - przez co Java
> >>> jest do dzi� chyba jedynym j�zykiem, w kt�rym jedynym bezpiecznym sposobem
> >>> sprawdzenia, czy string s jest niepusty, jest:
> >>>
> >>> if ( !"".equals( s ) )
> >
> >> niekoniecznie lepiej wyglada tak: s.equals("")
> >> albo w ogole s.isEmpty()
> >
> > �adniej wygl�da, oczywi�cie, tylko ma paskudn� wad� - je�li s jest null to
> > rzuca NullPointerException.

> Dlaczego paskudn�?  Ja zwykle w�a�nie NPE rzucam gdy mam nieoczekiwanego
> nulla, a dzi�ki s.equals("") mam oczekiwany efekt za darmo.

Problem polega w�a�nie na tym, �e wyj�tki, jako forma Runtime Error, objawiaj�
si� dopiero w dzia�aniu. Rozumiem, �e mo�esz chcie�, aby taki wyj�tek w�a�nie
wyst�pi�, ale musisz mie� pe�n� �wiadomo�� tego, �e tak w�a�nie jest.

Natomiast w Javie - podobnie jak w j�zyku C - w wi�kszo�ci przypadk�w null
traktuje si� jak pusty string (w�a�nie dlatego, �e mo�liwo�� bycia przez
string null-em jest nadmiarow� i nieu�ywan� w�a�ciwo�ci�, w wyniku czego
jedynie sprawia problemy). Znalaz�em co prawda w bibliotece standardowej kilka
przypadk�w, kiedy podanie null zamiast stringa traktowano jako okre�lony
szczeg�lny przypadek - ale wsz�dzie tam ow� szczeg�lno�� mo�na by�o zaznaczy�
inaczej, natomiast w wi�kszo�ci przypadk�w jak przyjmujemy w metodzie stringa,
to chcemy dosta� stringa, a nie null.

W Javie, podobnie jak w j�zyku C, zapewnienie tego jest niemo�liwe. Ju� nawet
w bazach danych si� da.

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

Sektor van Skijlen wrote:
> Dnia Tue, 01 Apr 2008 19:39:25 +0100, Radoslaw Jocz skrobie:
>>> warto�ciowy String jest w Javie zrobiony jako niewarto�ciowy - przez co Java
>>> jest do dzi� chyba jedynym j�zykiem, w kt�rym jedynym bezpiecznym sposobem
>>> sprawdzenia, czy string s jest niepusty, jest:
>>>
>>> if ( !"".equals( s ) )
>
>> niekoniecznie lepiej wyglada tak: s.equals("")
>> albo w ogole s.isEmpty()
>
> �adniej wygl�da, oczywi�cie, tylko ma paskudn� wad� - je�li s jest null to
> rzuca NullPointerException.

Dlaczego paskudn�?  Ja zwykle w�a�nie NPE rzucam gdy mam nieoczekiwanego
nulla, a dzi�ki s.equals("") mam oczekiwany efekt za darmo.


piotr