🚀 go-pugleaf

Dnia Sun, 09 Oct 2005 20:39:56 -0500, A.L. skrobie:
> Zajrzalem zeby sprawdzic, zdziwilem sie ze tak. I od razu
> zobaczylem, cytuje

> ---------------------------------------------------------------------------
> Zawartosc:      pl.comp.objects FAQ (Frequently Asked Questions and
> Summary)
> Data:           1998.08.18
> Wersja:         3.2
> Moderator:      Kuba Chabik  vasquez@sprocket.ict.pwr.wroc.pl
> Autorzy:        Kuba Chabik
>                 Kamil Konieczny  kkoniec@mks.com.pl
> ---------------------------------------------------------------------------

> Koniec cytatu. I rozrzewnilem sie...

He he ;)

Coś mi się wydaje, że to jest jakiś zapomniany bot, który się zapodział gdzieś
na jakimś serwerze. Rok w dacie ostatniej aktualizacji wskazuje na to, że to
już jest daleka historia ;)

Wszystko wskazywałoby na to, że w zasadzie w technologiach obiektowych panuje
totalny zastój ;))))


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java does not have pointers!"

On Mon, 10 Oct 2005 22:41:15 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> 
>Coś mi się wydaje, że to jest jakiś zapomniany bot, który się zapodział gdzieś
>na jakimś serwerze. Rok w dacie ostatniej aktualizacji wskazuje na to, że to
>już jest daleka historia ;)
>
>Wszystko wskazywałoby na to, że w zasadzie w technologiach obiektowych panuje
>totalny zastój ;))))

W ogole panuje totalny zastoj, bo niczego nowego nei wymyslono od
lat i jakos nie widac na horyzoncie. "Aspect programming" jakos mial
kiepski start i bolesny upadek, a to byla jedyna nowosc ostatni...

A.L.

Dnia Mon, 10 Oct 2005 19:11:47 -0500, A.L. skrobie:
> On Mon, 10 Oct 2005 22:41:15 +0000 (UTC), Sektor van Skijlen
> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> >Wszystko wskazywałoby na to, że w zasadzie w technologiach obiektowych panuje
> >totalny zastój ;))))

> W ogole panuje totalny zastoj, bo niczego nowego nei wymyslono od
> lat i jakos nie widac na horyzoncie. "Aspect programming" jakos mial
> kiepski start i bolesny upadek,

Cóż, najlepszym komentarzem chyba jest link ze strony:

http://www.aspectprogramming.com/papers.html

zatytułowany "The Future of AOP". Wystarczy kliknąć, żeby mieć jasność, jak ta
przyszłość AOP faktycznie wygląda (tylko trzeba się dobrze trzymać krzesła).

Zresztą, jeśli mam być szczery (oglądając temat pobieżnie) naprawdę nie widzę
w tym żadnej szczególnej nowości - abstrakcje i podmiana implementacji są
obecne w programowaniu już od bardzo dawna. Wątpię, żebym zmienił zdanie
drążąc temat dłużej, więc mi się nie chce.

> a to byla jedyna nowosc ostatni...

Myślę, że w dużej mierze bierze się to stąd, że trudności w przebiciu się
jakiejś nowości rosną wykładniczo. Jeśli stare wynalazki sprawdzają się
wystarczająco dobrze, to po co wymyślać nowe?

Nadomiar złego istnieje jeszcze tzw. bierny opór przeciwko nowościom, a nawet
nie tyle nowościom, ile po prostu rzeczom, jakich jeszcze nie próbowano (bo
trudno za nowość uważać metody Agile, czy np. expecta, zamiast którego uparcie
używa się nie nadającego się do tej roboty Perla). Nawet zastosowanie tego
innego rozwiązania "z sukcesem" wcale nie rokuje nadziei na taką zmianę.

Przykład: spektakularny sukces jednego z projektów u nas, prowadzonego
metodami Agile, jakoś nie skłonił działu, który cały czas leci "tradycyjnym
procesem" do choćby drobnego rozpatrzenia tej metody i sprawdzenia jej
sprawności wobec metod Agile. I to mimo niejednej porażki tradycyjnego procesu
(może niekoniecznie zakończonych jakąś wpadką, ale jak najbardziej
zakończonych przysyłaniem "ekip ratunkowych" oraz promocji "darmowe wieczory i
weekendy" dla pracowników - mam na myśli nadgodziny oczywiście, tylko tak się
to u nas ostatnio nazywa ;)).

Inny ciekawy przykład: inspekcje Fagana. Z moich obserwacji wynika, że co
najmniej 80% zgłaszanych błędów to są niejasne komentarze, brzydkie nazwy,
albo niestosowanie się do standardów kodowania. Na pewno dobrze jest, żeby
takie rzeczy zgłaszać, ale można to urządzić na zasadzie zgłaszania autorowi i
sprawdzenia przez kierownika - bicie piany w postaci spotkania jest całkowicie
zbędne. Zwłaszcza, że jeśli wśród pozostałych 20% znajdzie się jakiś błąd
naprawdę poważny i logiczny, to na pewno wychodzi potem podczas UT, CT i SST.

Z tej samej beczki: czy istnieje coś takiego jak "design, wedle którego od
początku do końca tworzony jest kod"? Tylko w teorii. W praktyce design
ewoluuje wraz z pisanym kodem. Klient to akceptuje, bo i tak w trakcie zgłasza
dodatkowe ficzery, o których nie pomyślał wcześniej.

Jeśli się teraz zbierze do kupy zarówno "tradycyjny" opór przed nowościami,
jak i brak czegoś naprawdę odkrywczego w różnych "nowościach", to wychodzi na
to, że ten zastój jeszcze dłuuugo potrwa.

Z drugiej strony nie jest to też żaden powód do smutku - wszystko chodzi w
miarę stabilnie i nikt się nie musi martwić o przyszłość - chyba, że ta
przyszłość wygląda mniej więcej tak, jak pod wskazanym linkiem.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java does not have pointers!"

On Tue, 11 Oct 2005 21:32:03 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
 
>
>Myślę, że w dużej mierze bierze się to stąd, że trudności w przebiciu się
>jakiejś nowości rosną wykładniczo. Jeśli stare wynalazki sprawdzają się
>wystarczająco dobrze, to po co wymyślać nowe?

Przerazajace jet tylko to ze juz minelo 5 lat 21 stulecia i wyglada
na to ze za kolejnych lat 10 bedziemy programowac tak jak za Krola
Cwieczka...

A.L.

Dnia Thu, 13 Oct 2005 19:28:28 -0500, A.L. skrobie:
> On Tue, 11 Oct 2005 21:32:03 +0000 (UTC), Sektor van Skijlen
> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
>  
> >
> >Myślę, że w dużej mierze bierze się to stąd, że trudności w przebiciu się
> >jakiejś nowości rosną wykładniczo. Jeśli stare wynalazki sprawdzają się
> >wystarczająco dobrze, to po co wymyślać nowe?

> Przerazajace jet tylko to ze juz minelo 5 lat 21 stulecia i wyglada
> na to ze za kolejnych lat 10 bedziemy programowac tak jak za Krola
> Cwieczka...

Wszystko niestety na to wskazuje.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java does not have pointers!"

"A.L." <alewando@kapturek62.com> wrote:

> Przerazajace jet tylko to ze juz minelo 5 lat 21 stulecia i wyglada
> na to ze za kolejnych lat 10 bedziemy programowac tak jak za Krola
> Cwieczka...

Czyli jak bedziemy programowac ?

Zamiast pod Windows za pomoca Eclipse w Javie, to pod Linuksem za pomoca
Emacsa w Haskellu ?

Pytam powaznie.


Reaserch w programowaniu nastepuje caly czas dosc dynamicznie. Tylko, ze
teraz smietanka komputerowej inteligencji zrzeszyla sie przy Haskellu i
programowaniu funkcyjnym. Ah, i dla nich Emacs jest optymalnym narzedziem, w
koncu "Emasc mozna sobie zaprogramowac tak, aby robil to wszystko co dowolne
inne IDE, zas w druga strone sie nie da".


ps. Poczytaj sobie ten papier (dostepny online):

"Arrows, Robots, and Functional Reactive Programming"
Hudak, Courtney, Nilsson, Peterson


mp

On Mon, 17 Oct 2005 21:50:38 +0200, "Michal Przybylek"
<mrp@neostrada.pl> wrote:

>"A.L." <alewando@kapturek62.com> wrote:
>
>> Przerazajace jet tylko to ze juz minelo 5 lat 21 stulecia i wyglada
>> na to ze za kolejnych lat 10 bedziemy programowac tak jak za Krola
>> Cwieczka...
>
>Czyli jak bedziemy programowac ?
>
>Zamiast pod Windows za pomoca Eclipse w Javie, to pod Linuksem za pomoca
>Emacsa w Haskellu ?
>
>Pytam powaznie.
>
>
>Reaserch w programowaniu nastepuje caly czas dosc dynamicznie. Tylko, ze
>teraz smietanka komputerowej inteligencji zrzeszyla sie przy Haskellu i

W przemysle nie pracuje "smeitanka" i przemyslowi na ogol obojetnie
wisi co ta smietanka robi.

A.L.

"A.L." <alewando@kapturek62.com> wrote:

> >Czyli jak bedziemy programowac ?
> >
> >Zamiast pod Windows za pomoca Eclipse w Javie, to pod Linuksem za pomoca
> >Emacsa w Haskellu ?
> >
> >Pytam powaznie.
> >
> >
> >Reaserch w programowaniu nastepuje caly czas dosc dynamicznie. Tylko, ze
> >teraz smietanka komputerowej inteligencji zrzeszyla sie przy Haskellu i
>
> W przemysle nie pracuje "smeitanka" i przemyslowi na ogol obojetnie
> wisi co ta smietanka robi.

No wiec sie pytam - jak chcieli bysmy programowac, a jak programujemy, ze
jest zle ? Bo:

Jak dla mnie mamy _dobre_ jezyki programowania. Takie, w ktorych _mozna_
pisac dobre programy (przypomne tylko, ze jeszcze calkiem niedawno dominowal
jezyk, w ktorym _nie dalo sie_ tworzyc dobrych programow). Jasne, ze
wolalbym Haskell, Lisp, lub Smalltalk, ale skoro jest tak, a nie inaczej, to
moge polubic tez Jave i C#.

Jak dla mnie, mamy _bardzo dobre_ narzedzia do tworzenia oprogramowania.
Takie o jakich kilkanascie lat temu moglismy tylko pomarzyc. Jezeli
programowanie w Smalltalku 20 lat temu wygladalo podobnie jak programowania
w Dolphinie teraz, to ja sie tylko ciesze, ze nie musialem programowac 20
lat temu.


I tyle...

A co do AOP. To nie jest tak, ze AOP sie nie przyjal. AOP jest w dziale
"badania". Nie mamy na razie dobrego AOP.

Mi ze spojrzen na AOP najblizsza jest wizja "filtrow kompozycyjnych". Tylko,
ze to caly czas jest _bardzo_ niedopracowane.


mp

On Tue, 18 Oct 2005 18:43:39 +0200, "Michal Przybylek"
<mrp@neostrada.pl> wrote:

>"A.L." <alewando@kapturek62.com> wrote:
>
>> >Czyli jak bedziemy programowac ?
>> >
>> >Zamiast pod Windows za pomoca Eclipse w Javie, to pod Linuksem za pomoca
>> >Emacsa w Haskellu ?
>> >
>> >Pytam powaznie.
>> >
>> >
>> >Reaserch w programowaniu nastepuje caly czas dosc dynamicznie. Tylko, ze
>> >teraz smietanka komputerowej inteligencji zrzeszyla sie przy Haskellu i
>>
>> W przemysle nie pracuje "smeitanka" i przemyslowi na ogol obojetnie
>> wisi co ta smietanka robi.
>
>No wiec sie pytam - jak chcieli bysmy programowac, a jak programujemy, ze
>jest zle ? Bo:
>
>Jak dla mnie mamy _dobre_ jezyki programowania. Takie, w ktorych _mozna_
>pisac dobre programy (przypomne tylko, ze jeszcze calkiem niedawno dominowal
>jezyk, w ktorym _nie dalo sie_ tworzyc dobrych programow). Jasne, ze
>wolalbym Haskell, Lisp, lub Smalltalk, ale skoro jest tak, a nie inaczej, to
>moge polubic tez Jave i C#.
>

Dobre programy da sie tworzyc w KAZDYM jezyku. To z programista cos
nei klapuje jak nie potrafi...

>Jak dla mnie, mamy _bardzo dobre_ narzedzia do tworzenia oprogramowania.
>Takie o jakich kilkanascie lat temu moglismy tylko pomarzyc.

Postep jest inkrementalny, w rodzaju "kwiatek do kozucha", a jak dla
mnie to jest nijaki. Zerowy, inaczej. Owszem, mamy wiecej guzikow na
IDE ale to jest wsio.

A jezyki?... Owszem, wykonano kilka zasadniczych krokow. Do tylu.

A.L.

"A.L." <alewando@kapturek62.com> wrote:

> >Jak dla mnie, mamy _bardzo dobre_ narzedzia do tworzenia oprogramowania.
> >Takie o jakich kilkanascie lat temu moglismy tylko pomarzyc.
>
> Postep jest inkrementalny, w rodzaju "kwiatek do kozucha", a jak dla
> mnie to jest nijaki. Zerowy, inaczej. Owszem, mamy wiecej guzikow na
> IDE ale to jest wsio.
>
> A jezyki?... Owszem, wykonano kilka zasadniczych krokow. Do tylu.

W stosunku np. do C++ ?

Sorry, patrzymy na to co bylo lat temu z 10 z hakiem. Pamietam dokladnie
jakie wtedy byly narzedzia i pamietam jak sie wtedy pisalo w C++ (z C nadal
mam stycznosc).

I na Boga, nie jest naprawde zle. Moglo by byc lepiej, ale zle nie jest.

A zamiast narzekac moze powiedz w koncu co Ci nie pasi i jak sobie
wyobrazasz to, aby bylo tak aby Ci pasilo.


mp

"A.L." <alewando@kapturek62.com> wrote:

> A jezyki?... Owszem, wykonano kilka zasadniczych krokow.
> Do tylu.

Aha, na temat obserwacji krokowych (kiedy to na stwierdzenie dlaczego jakis
jezyk jest "krok wstecz" za innym jezykiem domagalem sie uzasadnienia):

- Java jest krok wstecz za C++, bo nie ma wskaznikow,
- Java jest krok wstecz za C++, bo ma odsmiecanie,
- Java jest krok w przod przed Smalltalkiem, bo ma lokalne klasy,
- Smalltalk jest dwa kroki wstecz za Simula, bo ma dynamiczne typy i nie ma
lokalnych klas.

Wiecej nie pamietam.

Dopiszesz sie do kacika ?


mp

"Michal Przybylek" <mrp@neostrada.pl> wrote:

> > A jezyki?... Owszem, wykonano kilka zasadniczych
> > krokow. Do tylu.
>
> Aha, na temat obserwacji krokowych

A jak pojdziesz na comp.lang.functional to sie dowiesz dlaczego wszystkie
inne jezyki sa wiele krokow wstecz za jezykami funkcyjnymi :-)


mp

Dnia Tue, 18 Oct 2005 20:47:52 +0200, Michal Przybylek skrobie:
> "A.L." <alewando@kapturek62.com> wrote:

> > A jezyki?... Owszem, wykonano kilka zasadniczych krokow.
> > Do tylu.

> Aha, na temat obserwacji krokowych (kiedy to na stwierdzenie dlaczego jakis
> jezyk jest "krok wstecz" za innym jezykiem domagalem sie uzasadnienia):

Nie wiem właściwie, które z tych uzasadnień są w jakikolwiek sposób prawdziwe,
a które ironiczne, już się gubię.

> - Java jest krok wstecz za C++, bo nie ma wskaznikow,

Bo nie ma _referencji_. Tych prawdziwych referencji, które pozwalają
zidentyfikować każdy obiekt (w sensie ogólnym) pojawiający się w języku.
Na szczęście jest C#.

(btw. czy to jest może aluzja do mojej sygnaturki? ;)

> - Java jest krok wstecz za C++, bo ma odsmiecanie,

Bo nie pozwala stosować innego sposobu tworzenia obiektów, niż na stercie
odśmiecanej. Na szczęście - jak powiedziałem - jest C#.

Natomiast Java jest istotnie parę ładnych kroków wstecz za C++, bo:

 - nie pozwala operować funkcjami jako obiektami języka
 - nie pozwala operować zmiennymi typów ścisłych (jedynie ich wartościami)
 - nie dostarcza zaawansowanych metod generycznych (te Javowe generyki to jest
   jeden wielki pic na wodę; zwykły lukier składniowy)
 - nie pozwala stosować mechanizmu RAII
 - nie pozwala tworzyć własnych typów danych ze szczegółowo opisaną obsługą
   (które np. nie mają zezwolenia na modyfikacje, na kopiowanie, na pobieranie
   adresu, na tworzenie w inny niż odgórnie ustalony sposób, lub też te
   zezwolenia udzielane są wybiórczo; w tym wszystkim oczywiście też brak
   przeciążania operatorów)
 - nie daje możliwości odróżniania obiektów stanu od wartości (C# też
   niestety, bo jest robiony na to samo kopytko)

> - Java jest krok w przod przed Smalltalkiem, bo ma lokalne klasy,

Biorąc pod uwagę, co Java wniosła w stosunku do Smalltalka, to akurat jest
dość mało istotny szczegół.

> - Smalltalk jest dwa kroki wstecz za Simula, bo ma dynamiczne typy i nie ma
> lokalnych klas.

Dynamiczne typy są dobre. W językach skryptowych.

Większość tych stwierdzeń jest moim zdaniem zresztą bez sensu, nawet biorąc
poprawkę na ironię.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java does not have pointers!"

Dnia Tue, 18 Oct 2005 20:52:01 +0200, Michal Przybylek skrobie:
> "Michal Przybylek" <mrp@neostrada.pl> wrote:

> > > A jezyki?... Owszem, wykonano kilka zasadniczych
> > > krokow. Do tylu.
> >
> > Aha, na temat obserwacji krokowych

> A jak pojdziesz na comp.lang.functional to sie dowiesz dlaczego wszystkie
> inne jezyki sa wiele krokow wstecz za jezykami funkcyjnymi :-)

I że wszyscy nie używający Lispu to idioci?


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java does not have pointers!"

"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > A jak pojdziesz na comp.lang.functional to sie dowiesz dlaczego
wszystkie
> > inne jezyki sa wiele krokow wstecz za jezykami funkcyjnymi :-)
>
> I że wszyscy nie używający Lispu to idioci?

Generalnie nie. Pozatym oni akurat Lispu nie lubia, bo Lisp ma dynamiczne
typy.


mp

On Wed, 19 Oct 2005 14:50:11 +0200, "Michal Przybylek"
<mrp@neostrada.pl> wrote:

>"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
 
>> Większość tych stwierdzeń jest moim zdaniem zresztą bez sensu,
>> nawet biorąc poprawkę na ironię.
>
>Prosze o wiecej szacunku. Stwierdzenia byly generowane przez "informatyczne
>autorytety na skale swiatowa", jak tez sie pozniej dowiedzialem.
>

Rozumiem ze to ma byc ironia.

A.L.

"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> Nie wiem właściwie, które z tych uzasadnień są w jakikolwiek
> sposób prawdziwe, a które ironiczne, już się gubię.

[...]

Wszystkie sa nieironiczne.

> (btw. czy to jest może aluzja do mojej sygnaturki? ;)

Nie, nie czytam sygnaturek.

> Większość tych stwierdzeń jest moim zdaniem zresztą bez sensu,
> nawet biorąc poprawkę na ironię.

Prosze o wiecej szacunku. Stwierdzenia byly generowane przez "informatyczne
autorytety na skale swiatowa", jak tez sie pozniej dowiedzialem.


mp

"A.L." <alewando@kapturek62.com> wrote:

> >> Większość tych stwierdzeń jest moim zdaniem zresztą bez sensu,
> >> nawet biorąc poprawkę na ironię.
> >
> >Prosze o wiecej szacunku. Stwierdzenia byly generowane przez
> >"informatyczne autorytety na skale swiatowa", jak tez sie pozniej
> >dowiedzialem.
> >
>
> Rozumiem ze to ma byc ironia.

Wlasnie nie. Ja tylko przekazuje wierne odzwierciedlenie pewnego kawalka
rzeczywistosci. Relacjonuje. I odcinam sie od jakichkolwiek wnioskow.


mp

Dnia Wed, 19 Oct 2005 14:45:12 +0200, Michal Przybylek skrobie:
> "Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > > A jak pojdziesz na comp.lang.functional to sie dowiesz dlaczego
> wszystkie
> > > inne jezyki sa wiele krokow wstecz za jezykami funkcyjnymi :-)
> >
> > I że wszyscy nie używający Lispu to idioci?

> Generalnie nie. Pozatym oni akurat Lispu nie lubia, bo Lisp ma dynamiczne
> typy.

No tak. Dynamiczna typizacja nareszcie stała się niemodna ;)


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sektor van Skijlen napisał:

>  - nie dostarcza zaawansowanych metod generycznych (te Javowe generyki to jest
>    jeden wielki pic na wodę; zwykły lukier składniowy)
częściowo masz rację... ale nie jęsli to jest porównanie do C++ (templatów)
bo:
1) class My < T extends MyInterface, U extends My2<T> >
2) copy(List<? super T> dest, List<? extends T> src)
3) metaprogramowanie
4) brainfuck
-- 
jarekr

On Tue, 18 Oct 2005 22:46:13 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
 
>
>Natomiast Java jest istotnie parê ³adnych kroków wstecz za C++, bo:
>
> - nie pozwala operowaæ funkcjami jako obiektami jêzyka

A co to sa "funkcje"?...

> - nie pozwala operowaæ zmiennymi typów ¶cis³ych (jedynie ich warto¶ciami)

Ze co?...

> - nie dostarcza zaawansowanych metod generycznych (te Javowe generyki to jest
>   jeden wielki pic na wodê; zwyk³y lukier sk³adniowy)

Niby dlaczego?..

> - nie pozwala stosowaæ mechanizmu RAII

Ze co?..

> - nie pozwala tworzyæ w³asnych typów danych ze szczegó³owo opisan± obs³ug±
>   (które np. nie maj± zezwolenia na modyfikacje, na kopiowanie, na pobieranie
>   adresu, na tworzenie w inny ni¿ odgórnie ustalony sposób, lub te¿ te

Ach... Ma Pan na mysli Eiffel?.. Bo C++ tez tego nie dostarcza. By the
way, co to jest "pobieranie adresu"?...

>   zezwolenia udzielane s± wybiórczo; w tym wszystkim oczywi¶cie te¿ brak
>   przeci±¿ania operatorów)

Doskonale ze nie ma operator overlaoding.

> - nie daje mo¿liwo¶ci odró¿niania obiektów stanu od warto¶ci (C# te¿
>   niestety, bo jest robiony na to samo kopytko)

Co to jest "obiekt stanu"?...
 
Panie Sektor, kiedy Pan ostatnio uzywal Javy?...

A.L.

Dnia Thu, 20 Oct 2005 17:00:16 +0200, Jarek Ratajski skrobie:
> Sektor van Skijlen napisał:

> >  - nie dostarcza zaawansowanych metod generycznych (te Javowe generyki to jest
> >    jeden wielki pic na wodę; zwykły lukier składniowy)
> częściowo masz rację... ale nie jęsli to jest porównanie do C++ (templatów)
> bo:
> 1) class My < T extends MyInterface, U extends My2<T> >

Nie rozśmieszaj mnie.

class_requires<is_base_and_derived<T,MyInterface>::value>();
class_requires<is_base_and_derived<U,My2<Y>>::value>();

> 2) copy(List<? super T> dest, List<? extends T> src)

Bardzo podobnie.

> 3) metaprogramowanie

Sprawdź sobie boost::mpl i dopiero się pokazuj, co więcej potrafi Java.

> 4) brainfuck

To chyba to, co brałeś przed napisaniem tego postu.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sektor van Skijlen napisał:
> 
>>> - nie dostarcza zaawansowanych metod generycznych (te Javowe generyki to jest
>>>   jeden wielki pic na wodę; zwykły lukier składniowy)
>>
>>częściowo masz rację... ale nie jęsli to jest porównanie do C++ (templatów)
>>bo:
>>1) class My < T extends MyInterface, U extends My2<T> >
> 
> 
> Nie rozśmieszaj mnie.
> 
> class_requires<is_base_and_derived<T,MyInterface>::value>();
> class_requires<is_base_and_derived<U,My2<Y>>::value>();

O znowu się czegoś dowiedziałem o C++ od Ciebie - dzięki (przyda mi się).
Za czasów kiedy pisałem w C++ nijak na tak ładne rozwiązanie nie wpadłem 
i nie znalazłem w sieci tego rozwiązania (wtedy boost jako "standard" 
sie chyba dopiero rodził)

Jest tylko jedne kłopot - sądząc po googlu... to nie jest za często 
stosowane.

>>2) copy(List<? super T> dest, List<? extends T> src)
> 
> 
> Bardzo podobnie.
>>3) metaprogramowanie
> 
> 
> Sprawdź sobie boost::mpl i dopiero się pokazuj, co więcej potrafi Java.

Absolutnie źle mnie zrozumiałeś. W javie (genericsy) nie ma 
metaprogramowania ani trochę.

I to jest zaleta. Przynajmniej patrząc na to co pamiętam z C++.

Poza tym, boost::mpl stracił w moich oczach dawno temu - jak niechcący 
zaglądnąłem do źródeł i zobaczyłem ile konstrukcji jest "sficzerowanych" 
chamskimi makrami. Prawda, że na oko 95% tych makr (a może troche więcej 
-ale na pewno nie wszystkie) to poprawki na problemy z kompilatorami 
(wyjątkowo często na msvc).

To, że z C++ da sie zasymulować prawie dowolny język korzystając z makr 
i derektyw typu #pragma to fakt. Ale tak się składa, że w praktyce to 
może nie być zaleta :-).

>>4) brainfuck
> To chyba to, co brałeś przed napisaniem tego postu.
To było odnosnie lukru syntaktycznego - brainfuck to język, który w 
zasadzie nie ma lukru syntaktycznego. Sorry, ale ten zarzut jest 
naprawde absurdalny dla mnie - bo akurat zaczynałem programowanie od 
assemblera i makroassemblera i długo (z pięknym uporem) C/C++ widziałem 
tylko jako mały lukier syntaktyczny :-)
(kilkaset kilo makr do (dobrego) makroassemblera tworzy język cholernie 
podobny do C (wizualnie).
A jak pamiętam kiedyś zdobyłem piękny zestaw makr do C, które robiły 
"prawie" C++.
  (prawie (w obu przypadkach) to znaczy z dużymi problemami w 
dziedzinach tak istotnych jak kontrola typów.. ale przynajmniej wizualne 
podobieństwo dało się uzyskać)).

Konkretnie:
To że genericsy javowe generują kod wynikowy taki jaki się daje uzyskać 
bez ich stosowania to nie znaczy, ze jest to tylko lukier syntaktyczny.
Wprowadzja dodatkową kontrole typów na poziomie kompilacji (po to je 
wprowadzono) więc ten twój argument - zbijam.

-- 
http://www.99-bottles-of-beer.net/language-java-866.html

jarekr <jhratajski@popraw.literowki.pzcota.otne.pl> writes:

[...]

> To, że z C++ da sie zasymulować prawie dowolny język korzystając 
> z makr i derektyw typu #pragma to fakt.

To coś w rodzaju Dziesiątej Zasady Greenspuna (czy jakoś tak) :)

Dnia Thu, 20 Oct 2005 10:26:00 -0500, A.L. skrobie:
> On Tue, 18 Oct 2005 22:46:13 +0000 (UTC), Sektor van Skijlen
> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
>  
> >
> >Natomiast Java jest istotnie par? ?adnych kroków wstecz za C++, bo:
> >
> > - nie pozwala operowa? funkcjami jako obiektami j?zyka

> A co to sa "funkcje"?...

Obiekty językowe, które mogą być wywoływane z argumentami. Metody są tylko ich
specjalizacją.

Nieważne, czy nazwiemy to funkcją, czy metodą. C++ potrafi je przechowywać (i
to na wiele różnych sposobów), C# również. Java nie.

> > - nie pozwala operowa? zmiennymi typów ?cis?ych (jedynie ich warto?ciami)

> Ze co?...

Przekaż mi pan zmienną do metody. Tak, żeby metoda mogła ją zapisać.

> > - nie dostarcza zaawansowanych metod generycznych (te Javowe generyki to jest
> >   jeden wielki pic na wod?; zwyk?y lukier sk?adniowy)

> Niby dlaczego?..

Sprawdź sobie pan boost::mpl (co ja mówię! Głupie STL!), to się dowiesz.

> > - nie pozwala stosowa? mechanizmu RAII

> Ze co?..

Widzę, że się nie przygotowałeś pan do dyskusji.
Google twoim przyjacielem.

> > - nie pozwala tworzy? w?asnych typów danych ze szczegó?owo opisan? obs?ug?
> >   (które np. nie maj? zezwolenia na modyfikacje, na kopiowanie, na pobieranie
> >   adresu, na tworzenie w inny ni? odgórnie ustalony sposób, lub te? te

> Ach... Ma Pan na mysli Eiffel?..

Nie, mówiłem o C++, a nie o językach niszowych.

> Bo C++ tez tego nie dostarcza.

Akurat to, o czym napisałem, dostarcza.

> By the way, co to jest "pobieranie adresu"?...

Żargonowe określenie pobrania unikalnego identyfikatora obiektu w danym
systemie.

> >   zezwolenia udzielane s? wybiórczo; w tym wszystkim oczywi?cie te? brak
> >   przeci??ania operatorów)

> Doskonale ze nie ma operator overlaoding.

Taaa... równie doskonale że nie ma również enum i typedef.

Kiedyś ludzie mówili, że doskonale, że Java nie ma niczego takiego, jak wzorce
w C++. Po czym dodano generyki.

> > - nie daje mo?liwo?ci odró?niania obiektów stanu od warto?ci (C# te?
> >   niestety, bo jest robiony na to samo kopytko)

> Co to jest "obiekt stanu"?...

A co, nie wiedziałeś pan, że obiekty mają stan?

> Panie Sektor, kiedy Pan ostatnio uzywal Javy?...

Coś jest nie tak, panie AL, z tym, co napisałem? Co na przykład?

örnen klantö trofflön tööla...

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> Nieważne, czy nazwiemy to funkcją, czy metodą. C++ potrafi
> je przechowywać (i to na wiele różnych sposobów), C# również.
> Java nie.

He, he. Widze, ze Jave znasz tak dobrze jak Lisp :-)


mp

Sektor van Skijlen napisał(a):
>>>Natomiast Java jest istotnie par? ?adnych kroków wstecz za C++, bo:
>>>
>>>- nie pozwala operowa? funkcjami jako obiektami j?zyka
> 
> 
>>A co to sa "funkcje"?...
> 
> 
> Obiekty językowe, które mogą być wywoływane z argumentami. Metody są tylko ich
> specjalizacją.
> 
> Nieważne, czy nazwiemy to funkcją, czy metodą. C++ potrafi je przechowywać (i
> to na wiele różnych sposobów), C# również. Java nie.

ten temat obrabiasz średnio raz na dwa miesiące na jakiejś grupie i 
absolutnie jesteś odporny na kontratak. to że w javie, żeby wykonywać 
operacje na funkcjach potrzeba czasem więcej linijek kodu niż w C++ jest 
słabym argumentem. (w dowolnym assemblerze wskaźnik do funkcji ustawić 
można w jednej linijce i nawet sie typem nie trzeba przejmować !).

>>>- nie pozwala operowa? zmiennymi typów ?cis?ych (jedynie ich warto?ciami)
> 
> 
>>Ze co?...
> 
> 
> Przekaż mi pan zmienną do metody. Tak, żeby metoda mogła ją zapisać.
> 
Panu A.L. chodziło, jak mniemam o sens twojego zdania - teraz lekko 
doprecyzowałeś. (nadal dziwnie, ale już chyba wiem o co Ci chodzi (ale 
nie wierzę ...bo to kuriozalny argument) )
Lepiej pokaż konkretnie (kod).

>>>- nie dostarcza zaawansowanych metod generycznych (te Javowe generyki to jest
>>>  jeden wielki pic na wod?; zwyk?y lukier sk?adniowy)
> 
> 
>>Niby dlaczego?..
> 
> 
> Sprawdź sobie pan boost::mpl (co ja mówię! Głupie STL!), to się dowiesz.

znajdzie zapewne tak piękne fragmenty jak:
> #include <boost/mpl/aux_/config/msvc.hpp>
> #include <boost/mpl/aux_/config/workaround.hpp>
> 
> #if    !defined(BOOST_MPL_CFG_NO_DEPENDENT_ARRAY_TYPES) \
>     && !defined(BOOST_MPL_PREPROCESSING_MODE) \
>     && ( BOOST_WORKAROUND(__BORLANDC__, < 0x600) \
>         || BOOST_WORKAROUND(BOOST_MSVC, <= 1300) \
>         )
> 
> #   define BOOST_MPL_CFG_NO_DEPENDENT_ARRAY_TYPES
> 
> #endif
> 
> #endif

albo
> template< BOOST_MPL_AUX_NTTP_DECL(long, N) > struct advance_backward;
> 
> #   define BOOST_PP_ITERATION_PARAMS_1 \
>     (3,(0, BOOST_MPL_LIMIT_UNROLLING, <boost/mpl/aux_/advance_backward.hpp>))
> #   include BOOST_PP_ITERATE()




>>>- nie pozwala stosowa? mechanizmu RAII
> 
> 
>>Ze co?..
> 
> 
> Widzę, że się nie przygotowałeś pan do dyskusji.
> Google twoim przyjacielem.

Możliwe, ze sie przygotował bo google bzdury pisze  - na temat RAII jest 
ok. ale na temat tego jak to się trzeba męczyć w javie (używając finally 
... ) - to juz piękne bzdury.
Tak w Javie nie ma RAII - są inne konstrukcje (mniej wygodne - z użyciem 
dodatkowej klasy - wrappera, ale ponieważ potrzeba korzystania jest 
dosyć rzadka - jest to mało uciążliwe) ( w końcu wszelkie biblioteki do 
obsługi różnych zasobów są dawno popisane  )


> >>>- nie pozwala tworzy? w?asnych typów danych ze szczegó?owo opisan? obs?ug?
>>>  (które np. nie maj? zezwolenia na modyfikacje, na kopiowanie, na pobieranie
>>>  adresu, na tworzenie w inny ni? odgórnie ustalony sposób, lub te? te
> 
> 
>>Ach... Ma Pan na mysli Eiffel?..
> 
> 
> Nie, mówiłem o C++, a nie o językach niszowych.
> 
> 
>>Bo C++ tez tego nie dostarcza.
> 
> 
> Akurat to, o czym napisałem, dostarcza.


>>By the way, co to jest "pobieranie adresu"?...
> 
> 
> Żargonowe określenie pobrania unikalnego identyfikatora obiektu w danym
> systemie.
> 
> 
>>>  zezwolenia udzielane s? wybiórczo; w tym wszystkim oczywi?cie te? brak
>>>  przeci??ania operatorów)
Wybiórczo?, zezwolenia w C++? O ile ktoś sie do d... nie dobierze 
rzutując na jakiś void*.

A w javie jakoś te aplety, servlety, ejb i inne inszety działają i 
"wyoranie się z java security" nie jest takim trywialnym zagadnieniem.


>>Doskonale ze nie ma operator overlaoding.
> 
> 
> Taaa... równie doskonale że nie ma również enum i typedef.

Fatalnie:

http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

Powiedz, że standardowy enum w C++ jest lepszy :-)


> Kiedyś ludzie mówili, że doskonale, że Java nie ma niczego takiego, jak wzorce
> w C++. Po czym dodano generyki.

Jasne... pewnie dlatego "Generic java" - projekt, który po prostu 
niedawno wszedł do standardowej dystrybucji (po pewnych modyfikacjach) 
był utworzony gdzieś około roku 1998.
Z drugiej strony, mimo że osobiście bardzo lubię generyki,  to. 
zastanawiam się czy w dużych projektach ograniczenie sie do używania 
tylko generycznych kolekcji nie byłoby dobrym rozwiązaniem.


>>>- nie daje mo?liwo?ci odró?niania obiektów stanu od warto?ci (C# te?
>>>  niestety, bo jest robiony na to samo kopytko)
> 
> 
>>Co to jest "obiekt stanu"?...
> 
> 
> A co, nie wiedziałeś pan, że obiekty mają stan?


też nie wiem o co Ci chodzi - pomysłów różnych mam ze 6 - ale żaden mi 
do końca nie pasuje.

-- 
http://www.99-bottles-of-beer.net/language-java-866.html

Dnia Thu, 20 Oct 2005 20:04:11 +0200, jarekr skrobie:
> > class_requires<is_base_and_derived<T,MyInterface>::value>();
> > class_requires<is_base_and_derived<U,My2<Y>>::value>();

> O znowu się czegoś dowiedziałem o C++ od Ciebie - dzięki (przyda mi się).
> Za czasów kiedy pisałem w C++ nijak na tak ładne rozwiązanie nie wpadłem 
> i nie znalazłem w sieci tego rozwiązania (wtedy boost jako "standard" 
> sie chyba dopiero rodził)

Nie no to jest tak wymyślone "naprędce". To całe is_base_and_derived to nawet
jest w boost::type_traits, ale class_requires to trzeba se zrobić samemu w
taki sposób, żeby się sypało podczas kompilacji gdy ...::value jest false.

> Jest tylko jedne kłopot - sądząc po googlu... to nie jest za często 
> stosowane.

Oczywiście, bo jest to znacznie mniej potrzebne, niż się ludziom wydaje.
Co więcej, jest to też często zabójcze! Nałożenie dowolnego ograniczenia na
typ-parametr powoduje od razu bardzo możliwe ograniczenia użycia takiego
wzorca. Przykładowo, pamiętam jak jakaś klasa używała własnego type-traita do
sprawdzenia, czy dany typ jest integer. A ja sobie zrobię np. własny typ
integer i co? Wiem, że powinienem się w takim przypadku "dopisać do listy" i
to rozwiązuje problem, ale z drugiej strony to może spowodować, że mój typ
będzier traktowany jak całkowity nawet jeśli spełnia "nie wszystkie" warunki.

Jeśli już, to powinno się definiować w miarę możliwości osobne definicje dla
różnych kwalifikacji typów.

W istocie w Javie to ograniczanie typów (tak samo zresztą jak w C#) bierze się
wcale nie stąd, że "ludzie potrzebują ograniczania typów", tylko stąd, że tego
wymaga runtime języka (inaczej: język nie będzie działał bez tych ograniczeń).
W przypadku Javy jest to bardzo proste przełożenie: jeśli używany typ nie ma
ograniczeń, to będzie implementowany przez Object; jeśli ma ograniczenie na
bycie wyprowadzonym z określonej klasy/interfejsu - wtedy będzie
implementowany przez referencję do tej właśnie klasy/interfejsu. Generyki
zapewniają ci tylko tyle, że zrobią za ciebie rzutowanie.

> Absolutnie źle mnie zrozumiałeś. W javie (genericsy) nie ma 
> metaprogramowania ani trochę.

Aha, jeśli tak to się zgodzę. Nie sprecyzowałeś po prostu.

> I to jest zaleta. Przynajmniej patrząc na to co pamiętam z C++.

No nie wiem. Jak słyszę takie rzeczy, że w Javie czegoś brakuje, co ma C++ i
że to jest zaleta, to mnie dosłownie pusty śmiech ogarnia. Jeszcze większy,
jak się po jakimś czasie okazuje, że to zostało częściowo potem dodane, tak
jak było z generykami.

> Poza tym, boost::mpl stracił w moich oczach dawno temu - jak niechcący 
> zaglądnąłem do źródeł i zobaczyłem ile konstrukcji jest "sficzerowanych" 
> chamskimi makrami. Prawda, że na oko 95% tych makr (a może troche więcej 
> -ale na pewno nie wszystkie) to poprawki na problemy z kompilatorami 
> (wyjątkowo często na msvc).

Nie masz się czym przejmować; boostowcy przesadzają z komplikowaniem kodu. To
jeszcze niczego nie oznacza.

> To, że z C++ da sie zasymulować prawie dowolny język korzystając z makr 
> i derektyw typu #pragma to fakt. Ale tak się składa, że w praktyce to 
> może nie być zaleta :-).

Ale tu nie chodzi o makra; te są używane wyłącznie instrumentalnie. Da się to
wszystko napisać zupełnie bez makr, a nawet prościej. W metaprogramowaniu
chodzi głównie o wykonywanie operacji na wartościach i typach podczas
kompilacji. To nie wymaga jakichś specjalnych sztuczek, ani nie jest wcale tak
często stosowane.

Ale mimo niewielu zastosowań jego istnienie jest nieocenione! Tym bardziej
zatem nie rozumiem, dlaczego jego brak w języku miałby być zaletą, skoro w
niczym nie przeszkadza.

> >>4) brainfuck
> > To chyba to, co brałeś przed napisaniem tego postu.
> To było odnosnie lukru syntaktycznego - brainfuck to język, który w 
> zasadzie nie ma lukru syntaktycznego.

No jak to - przecież wszystko jest na operatorach, nie ma w ogóle słów
kluczowych ;)))))

> Sorry, ale ten zarzut jest naprawde absurdalny dla mnie - bo akurat
> zaczynałem programowanie od assemblera i makroassemblera i długo (z pięknym
> uporem) C/C++ widziałem tylko jako mały lukier syntaktyczny :-)
> (kilkaset kilo makr do (dobrego) makroassemblera tworzy język cholernie 
> podobny do C (wizualnie).
> A jak pamiętam kiedyś zdobyłem piękny zestaw makr do C, które robiły 
> "prawie" C++.
>   (prawie (w obu przypadkach) to znaczy z dużymi problemami w 
> dziedzinach tak istotnych jak kontrola typów.. ale przynajmniej wizualne 
> podobieństwo dało się uzyskać)).

I chyba destruktorów, których nie jesteś w stanie zasymulować w C w żaden
sposób. A jest to bardzo istotny element C++.

> Konkretnie:
> To że genericsy javowe generują kod wynikowy taki jaki się daje uzyskać 
> bez ich stosowania to nie znaczy, ze jest to tylko lukier syntaktyczny.
> Wprowadzja dodatkową kontrole typów na poziomie kompilacji (po to je 
> wprowadzono) więc ten twój argument - zbijam.

Eeee tam. No dobrze - dodają statyczną weryfikację poprawności typu. Ale to
wszystko.

Istotnym elementem wzorców w C++ jest ich "efficiency". Dlatego jest to
właśnie "polimorfizm statyczny". W Javie nie ma żadnego statycznego
polimorfizmu; jest to dynamiczny polimorfizm z drobnym wsparciem statycznym.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sektor van Skijlen napisał:

> Oczywiście, bo jest to znacznie mniej potrzebne, niż się ludziom wydaje.
> Co więcej, jest to też często zabójcze! Nałożenie dowolnego ograniczenia na
> typ-parametr powoduje od razu bardzo możliwe ograniczenia użycia takiego
> wzorca. Przykładowo, pamiętam jak jakaś klasa używała własnego type-traita do
> sprawdzenia, czy dany typ jest integer. A ja sobie zrobię np. własny typ
> integer i co? Wiem, że powinienem się w takim przypadku "dopisać do listy" i
> to rozwiązuje problem, ale z drugiej strony to może spowodować, że mój typ
> będzier traktowany jak całkowity nawet jeśli spełnia "nie wszystkie" warunki.
> 
> Jeśli już, to powinno się definiować w miarę możliwości osobne definicje dla
> różnych kwalifikacji typów.
> 
> W istocie w Javie to ograniczanie typów (tak samo zresztą jak w C#) bierze się
> wcale nie stąd, że "ludzie potrzebują ograniczania typów", tylko stąd, że tego
> wymaga runtime języka (inaczej: język nie będzie działał bez tych ograniczeń).
> W przypadku Javy jest to bardzo proste przełożenie: jeśli używany typ nie ma
> ograniczeń, to będzie implementowany przez Object; jeśli ma ograniczenie na
> bycie wyprowadzonym z określonej klasy/interfejsu - wtedy będzie
> implementowany przez referencję do tej właśnie klasy/interfejsu. Generyki
> zapewniają ci tylko tyle, że zrobią za ciebie rzutowanie.

Sektor ! To jest naprawdę wspaniałe jak mnie uczysz jak działają 
generyki w javie :-). (fakt, że przynajmniej technicznie trochę prawdy 
napisałeś)

Ale "filozoficznie" - absolutnie sie nie zgadzam. Jeśli robię jakiś 
framework z użyciem generics i narzucam, ze jakiś tam typ X można 
konkretyzować tylko klasami które np. dziedziczą z jakiejś mojej klasy 
Y, implementują jakiś interfejs.. daje mi to konkretną kontrolę i 
możliwość w miarę bezpiecznej ewolucji frameworku. Mam pewność, ze jeśli 
ktoś czegoś tam nie odziedziczy to mu się kod nie skompiluje ( kontrola 
na zasadzie:  akurat przypadkiem klasa Z ma metodę setValue() którą 
wywołuje to jak dla mnie nie jest szczęśliwe rozwiązanie)

W przypadku C++ kilka razy się potknąłem o ten problem, fakt, głownie z 
powodu przeciążania operatorów. Zaskakująco dużo istotnych typów potrafi 
  mieć przypadkiem pokryty operator + , -> czy inne takie. Niekoniecznie 
w sposób zgodny z tym jaki twórca  generycznego kodu w którym się tego 
użyje przewidywał).


>>Absolutnie źle mnie zrozumiałeś. W javie (genericsy) nie ma 
>>metaprogramowania ani trochę.
> 
> 
> Aha, jeśli tak to się zgodzę. Nie sprecyzowałeś po prostu.
> 
> 
>>I to jest zaleta. Przynajmniej patrząc na to co pamiętam z C++.
> 
> 
> No nie wiem. Jak słyszę takie rzeczy, że w Javie czegoś brakuje, co ma C++ i
> że to jest zaleta, to mnie dosłownie pusty śmiech ogarnia. Jeszcze większy,
> jak się po jakimś czasie okazuje, że to zostało częściowo potem dodane, tak
> jak było z generykami.
Widzisz bo to właśnie był sens Javy (i obecna moja tendencja do unikania 
  C++). Wyrypanie tych pięknych ficzerów:
	- bez których da się spokojnie żyć,						- i  z których umiejętnie 
korzystać potrafi 1% programistów,
	- i z których korzysta 50% reszty programistów absolutnie wypaczając sens

Dokładniej:
Makra, meta programowanie, operator overloading.
( strzelam, że obecnie mnóstwo ludzi korzysta z meta programowania do 
rozwijania prostych pętli ... co jak się nieumiejętnie robi (nie 
sprawdza) zabija wydajność zamiast poprawiać)

Powiem więcej - mimo, że w  mniejszych projektach nie mam oporów z 
korzystaniem z java generics... to przy większych projektach zespołowych 
w javie... prawdopodobnie optowałbym za nie korzystaniem z genericsów (w 
sensie tworzenia własnych typów). Czytelność i prostota kodu to jest 
element, którego nie można pominąć, a nie wiem czy chciałbym oglądać 
"generyczny" kod stworzony przez człowieka, który właśnie w swoim kraju 
przeszedł kurs "learn java in 21 hours". ( w zasadzie to w ogóle nie 
chciałbym pracować z żadnym kodem tworzonym przez takiego gościa ... 
niestety jakoś ciągle mnie i wszystkich znajomych ten problem spotyka i 
dotychczasową zaletą javy było to, że przynajmniej dawało się taki kod 
fragmentami zrozumieć i na szybkiego załatać).

Operator overloading - już raz płakałem, że tego nie mam w Javie - ale 
zaraz zrozumiałem, że miałby to wtedy także konkretny, (absolutnie 
niegłupi, tylko bardzo *kreatywny* ) pan X.

>>Poza tym, boost::mpl stracił w moich oczach dawno temu - jak niechcący 
>>zaglądnąłem do źródeł i zobaczyłem ile konstrukcji jest "sficzerowanych" 
>>chamskimi makrami. Prawda, że na oko 95% tych makr (a może troche więcej 
>>-ale na pewno nie wszystkie) to poprawki na problemy z kompilatorami 
>>(wyjątkowo często na msvc).
> 
> 
> Nie masz się czym przejmować; boostowcy przesadzają z komplikowaniem kodu. To
> jeszcze niczego nie oznacza.

Jeśli to jest ta piękna biblioteka, która ma uratować C++ 
(standaryzacja) .. to wiele znaczy.

>>To, że z C++ da sie zasymulować prawie dowolny język korzystając z makr 
>>i derektyw typu #pragma to fakt. Ale tak się składa, że w praktyce to 
>>może nie być zaleta :-).
> 
> 
> Ale tu nie chodzi o makra; te są używane wyłącznie instrumentalnie. Da się to
> wszystko napisać zupełnie bez makr, a nawet prościej. W metaprogramowaniu
> chodzi głównie o wykonywanie operacji na wartościach i typach podczas
> kompilacji. To nie wymaga jakichś specjalnych sztuczek, ani nie jest wcale tak
> często stosowane.
> 
> Ale mimo niewielu zastosowań jego istnienie jest nieocenione! Tym bardziej
> zatem nie rozumiem, dlaczego jego brak w języku miałby być zaletą, skoro w
> niczym nie przeszkadza.

Zależy jak się na to patrzy. W Javie jest coś takiego jak 
instrumentacja, refleksja, generowanie kodu w runtime... załatwia się 
tym podobną klasę problemów co meta programowaniem w C++ (czyli dość 
specyficzne, mocno technologiczne problemy).
Niestety, w praktyce załatwia się też całą masę problemów, które można 
zrobić zwyczajnie (korzystając z podstawowych własności każdego języka 
"obiektowego").
Taka, kurde.... moda. A potem kod się kompiluje pięknie tylko trzeba 
debugować, żeby odkryć czegoż to jeszcze nie dodaliśmy do naszej klasy, 
co akurat niejawnie używane jest w bibliotece XY.

> 
> I chyba destruktorów, których nie jesteś w stanie zasymulować w C w żaden
> sposób. A jest to bardzo istotny element C++.

z tego co pamiętam destruktory miałem - ale nie ja pisałem te makra więc 
  100% pewności nie mam jak to było zrobione (musiałbym sie bardzo 
umotywować, żeby to teraz na starej amidze odnaleźć :-) )

> 
> Eeee tam. No dobrze - dodają statyczną weryfikację poprawności typu. Ale to
> wszystko.
> 
> Istotnym elementem wzorców w C++ jest ich "efficiency". Dlatego jest to

Ale w jakim sensie  *efficiency* ?
To oczywiście była wielka kłótnia przy wprowadzaniu java generics jak to 
ma być kompilowane. W praktyce gdyby przyjęto model z C++ - 
kompilowaniem nowego kodu dla każdej konkretyzacji... to niewiele by się 
  zmieniło (poza rozmiarami programów wynikowych).
(OK. byłyby duże zmiany w refleksji - ale to jest ( w kontekście 
porównania z C++) wewnątrzjavowy problem).

-- 
http://www.99-bottles-of-beer.net/language-java-866.html

Dnia Fri, 21 Oct 2005 18:16:40 +0200, Michal Przybylek skrobie:
> "Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > Nieważne, czy nazwiemy to funkcją, czy metodą. C++ potrafi
> > je przechowywać (i to na wiele różnych sposobów), C# również.
> > Java nie.

> He, he. Widze, ze Jave znasz tak dobrze jak Lisp :-)

Dobrze, możliwe że w Javie mam braki. Tak samo mam braki np. w perlu. Ale jak
nie wiem, to polegam na ludziach, którzy wiedzą. Jak np. pytam o kwestię
rozwiązywania problemu, rozwiązywanego przez wskaźniki do funkcji, w Javie, to
dostaję odpowiedź, że jedyna metoda do uzyskania podobnego efektu to
listenery.

Znasz coś innego? Chętnie posłucham, może chętnie posłuchają też specjaliści
od Javy z mojej firmy i czegoś ciekawego się nauczą.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Fri, 21 Oct 2005 18:27:59 +0200, jarekr skrobie:
> ten temat obrabiasz średnio raz na dwa miesiące na jakiejś grupie

W szczególności przypominam sobie dwa (zgaduję, że pierwszy był dwa miesiące
temu), a ten pierwszy był na pl.comp.lang.c.

> i absolutnie jesteś odporny na kontratak.

Z bardzo prostej przyczyny: nikt jeszcze nie podał żadnego racjonalnego
kontrargumentu. Masz okazję, chwilowo nie wiem dlaczego nie skorzystałeś.

> to że w javie, żeby wykonywać 
> operacje na funkcjach potrzeba czasem więcej linijek kodu niż w C++
> jest słabym argumentem.

Nie bądź śmieszny. To nie jest tylko "trochę więcej linijek" (nb. nie rozumiem
dlaczego fakt, że trzeba się więcej opisać w dokładnie tym samym stylu, ma być
słabym argumentem).

> (w dowolnym assemblerze wskaźnik do funkcji ustawić 
> można w jednej linijce i nawet sie typem nie trzeba przejmować !).

Ale nie rozumiem, co to ma do tematu ;)

> >>>- nie pozwala operowa? zmiennymi typów ?cis?ych (jedynie ich warto?ciami)
> > 
> > 
> >>Ze co?...
> > 
> > 
> > Przekaż mi pan zmienną do metody. Tak, żeby metoda mogła ją zapisać.
> > 
> Panu A.L. chodziło, jak mniemam o sens twojego zdania - teraz lekko 
> doprecyzowałeś. (nadal dziwnie, ale już chyba wiem o co Ci chodzi (ale 
> nie wierzę ...bo to kuriozalny argument) )
> Lepiej pokaż konkretnie (kod).

Oj przestań, nawet mnie nie próbuj zanudzać stwierdzeniami, że w Javie się "po
prostu piszę inaczej", że powinienem zmienić mój sposób myślenia i stosować
inne techniki, bo się rozpłaczę do rozpuku. To samo słyszę nt. każdego
narzekania na właściwości Javy i to narzekania nie tylko takich gołodziobów
jak ja, którzy jedynie "stosują jak muszą", ale prawdziwych praktyków, którzy
na z niejednego pieca projektach zęby zjedli.

> >>>- nie dostarcza zaawansowanych metod generycznych (te Javowe generyki to jest
> >>>  jeden wielki pic na wod?; zwyk?y lukier sk?adniowy)
> > 
> > 
> >>Niby dlaczego?..
> > 
> > 
> > Sprawdź sobie pan boost::mpl (co ja mówię! Głupie STL!), to się dowiesz.

> znajdzie zapewne tak piękne fragmenty jak:
> > #include <boost/mpl/aux_/config/msvc.hpp>
> > #include <boost/mpl/aux_/config/workaround.hpp>

Ty sobie lepiej zajrzyj do implementacji Swings. Bo to, co pokazałeś niżej, to
jest tylko workaround na badziewny kompilator (co nawet widać po tych dwóch
pierwszych linijkach). Gdyby to był kod pisany tylko pod kompilatory
rzeczywiście zgodne ze standardem, nie byłoby żadnych makr. Zresztą, niech
dzisiaj będzie dzień dziecka:

Po pierwsze, to ja mimo wszystko wolę mieć dowolny kompilator do wyboru, niż
jedno centrum decyzyjne tworzące język i jego implementację.

Po drugie, co mnie obchodzi implementacja? Do implementacji zaglądam jak
jestem ciekawy, jak to goście wykoncypowali. Użytkownika interesuje jedynie
interfejs.

> >>>- nie pozwala stosowa? mechanizmu RAII
> > 
> > 
> >>Ze co?..
> > 
> > 
> > Widzę, że się nie przygotowałeś pan do dyskusji.
> > Google twoim przyjacielem.

> Możliwe, ze sie przygotował bo google bzdury pisze

Trzeba umieć szukać. Kiedyś chciałem znaleźć na googlach informacje o pewnym
dialekcie języka Brainfuck - Doublefuck. Niestety po wpisaniu tego hasła
wszystko co znalazł raczej nie było związane z programowaniem, nawet
ezoterycznym...

> - na temat RAII jest 
> ok. ale na temat tego jak to się trzeba męczyć w javie (używając finally 
> ... ) - to juz piękne bzdury.

Widzę właśnie, jak uważnie to przeczytałeś.

Dodanie finally w Javie było po prostu koniecznością, ale jeśli już bawimy się
w takie finally, to dodajmy finally w sposób całkowicie poza wyjątkami, po
prostu na koniec definicji metody (albo po prostu w dowolnym miejscu w
definicji metody, również wielokrotnie - będą wykonane w kolejności odwrotnej
do definicji). Gdybyśmy mogli mieć np.:

File f = new File( "nazwa.txt" );
finally { f.close(); }

to już mamy co prawda ręczne bo ręczne ale zawsze jakieś tam RAII. Natomiast
cały problem polega na tym, że w Javie RAII osiągnąć się nie da w ogóle.

> Tak w Javie nie ma RAII - są inne konstrukcje (mniej wygodne - z użyciem 
> dodatkowej klasy - wrappera, ale ponieważ potrzeba korzystania jest 
> dosyć rzadka - jest to mało uciążliwe) 

No, bardzo chętnie się dowiem, jakie to techniki w Javie są stosowane zamiast
RAII i zapewniają tą samą skuteczność zarządzania zasobami. I nie rozśmieszaj
mnie znów argumentem, że to rzadka potrzeba i nic nie szkodzi, że mało
wygodne.

> ( w końcu wszelkie biblioteki do 
> obsługi różnych zasobów są dawno popisane  )

Tak, szczególnie takich, o których twórcy owych bibliotek nie mieli szans
wiedzieć w czasie pisania.

> >>By the way, co to jest "pobieranie adresu"?...
> > 
> > 
> > Żargonowe określenie pobrania unikalnego identyfikatora obiektu w danym
> > systemie.
> > 
> > 
> >>>  zezwolenia udzielane s? wybiórczo; w tym wszystkim oczywi?cie te? brak
> >>>  przeci??ania operatorów)
> Wybiórczo?, zezwolenia w C++? O ile ktoś sie do d... nie dobierze 
> rzutując na jakiś void*.

Oj ty młody i naiwny...

Masz tu klasę:

class Value
{
public:
	int in;

private:
	int operator&() const { return 0; }
	template <class T>
	operator T&();

	template <class T>
	operator const T&() const;
};

Wiszę ci półkę, jak mi zmienną typu Value zrzutujesz na void*. Powodzenia.

> A w javie jakoś te aplety, servlety, ejb i inne inszety działają i 
> "wyoranie się z java security" nie jest takim trywialnym zagadnieniem.

Mnie średnio interesuje, jakie security muszą przejść te różne napletki i
serwetki. To ma się nijak do języka - jest to zupełnie osobna kwestia, którą
dana aplikacja musi przejść niezależnie od języka, w którym jest napisana.

> > Kiedyś ludzie mówili, że doskonale, że Java nie ma niczego takiego, jak wzorce
> > w C++. Po czym dodano generyki.

> Jasne... pewnie dlatego "Generic java" - projekt, który po prostu 
> niedawno wszedł do standardowej dystrybucji (po pewnych modyfikacjach) 
> był utworzony gdzieś około roku 1998.

Całkiem nieźle. Niedawno, czyli będzie to tak ze dwa lata temu (nie pamiętam,
od kiedy dokładnie generyki są w Javie). Nawet licząc, że stało się to po
czterech latach od momentu utworzenia i nawet licząc duży overhead formalny,
to trzeba przyznać, że goście "długo główkowali". Jak na to, co wymyślili, to
powinno im to zająć góra dwa miesiące, no, trzy powiedzmy, jeśli liczymy, że
dwa z tych miesięcy zajął formalny overhead.

Skoro jednak zajęło im to aż tyle czasu, to widzę tylko jedno racjonalne
wyjaśnienie: po prostu generyki zrobili zapaleńcy, którzy doskonale zdawali
sobie sprawę z tego, że są one potrzebne (dla każdego człowieka, który wie,
czym się różni statyczna i dynamiczna typizacja, zwłaszcza w języku
wspierającym OO, jest to co najmniej oczywiste). Ale nikt nie miał zamiaru
dodawać ich do języka; edukatorzy i piewcy woleli robić z siebie idiotów i
udowadniać na wszelkie możliwe sposoby, że wzorce są beee... Dopiero gdy się
okazało, że taktyka namawiania ludzi do "porzucenia starego sposobu myślenia"
przestaje skutkować, zwłaszcza jak się pojawiła konkurencja - postanowiono
skorzystać.

> Z drugiej strony, mimo że osobiście bardzo lubię generyki,  to. 
> zastanawiam się czy w dużych projektach ograniczenie sie do używania 
> tylko generycznych kolekcji nie byłoby dobrym rozwiązaniem.

Tak, najlepiej to w ogóle ograniczcie ilość używanych klas do biblioteki
standardowej i tak po jednej klasie na pakiet. Oczywiście że trzeba wprowadzić
takie ograniczenia, żeby sobie programiści Javy rączek nie poparzyli.

Nie wiem, jak to się dzieje, że jakoś ANI RAZU (!) nie zdarzyło mi się widzieć
w C++ jakiegoś "bardzo nieładnego" kodu, który by wykorzystywał wzorce albo
przeciążanie operatorów. Dokładnie było odwrotnie: kody używające tych
właściwości były napisane wręcz z wzorcową starannością. Natomiast najgorzej
i najniechlujniej napisany kod to był kod pisany "w stylu języka C".

Jestem przekonany, że nie jestem jedynym, ani wyjątkiem, ani ewenementem pod
tym względem. Tylko jakoś nie słyszę, żeby ktoś wyciągnął z tego jeden
najbardziej oczywisty w tej sytuacji wniosek: nie należy się obawiać
programistów używających wzorców i przeciążania operatorów. Należy się,
however, jak ognia bać programistów, którzy więcej pisali w C, niż w C++.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Fri, 21 Oct 2005 23:26:13 +0200, jarekr skrobie:
> Sektor van Skijlen napisał:
> > W istocie w Javie to ograniczanie typów (tak samo zresztą jak w C#) bierze się
> > wcale nie stąd, że "ludzie potrzebują ograniczania typów", tylko stąd, że tego
> > wymaga runtime języka (inaczej: język nie będzie działał bez tych ograniczeń).
> > W przypadku Javy jest to bardzo proste przełożenie: jeśli używany typ nie ma
> > ograniczeń, to będzie implementowany przez Object; jeśli ma ograniczenie na
> > bycie wyprowadzonym z określonej klasy/interfejsu - wtedy będzie
> > implementowany przez referencję do tej właśnie klasy/interfejsu. Generyki
> > zapewniają ci tylko tyle, że zrobią za ciebie rzutowanie.

> Sektor ! To jest naprawdę wspaniałe jak mnie uczysz jak działają 
> generyki w javie :-). (fakt, że przynajmniej technicznie trochę prawdy 
> napisałeś)

Ja tylko uzasadniam swoje zdanie.

> Ale "filozoficznie" - absolutnie sie nie zgadzam. Jeśli robię jakiś 
> framework z użyciem generics i narzucam, ze jakiś tam typ X można 
> konkretyzować tylko klasami które np. dziedziczą z jakiejś mojej klasy 
> Y, implementują jakiś interfejs.. daje mi to konkretną kontrolę i 
> możliwość w miarę bezpiecznej ewolucji frameworku.

No jasne i co jeszcze.

Patrzysz na to od dupy strony: nie porównuj tego z wzorcami C++, tylko
porównaj to z tym, gdybyś sam ręcznie robił to, co generyki robią za ciebie.
To znaczy, porównaj z kodem, który byś pisał rzeczywiście obiektowo, bez
generyków.

> Mam pewność, ze jeśli ktoś czegoś tam nie odziedziczy to mu się kod nie
> skompiluje ( kontrola na zasadzie:  akurat przypadkiem klasa Z ma metodę
> setValue() którą wywołuje to jak dla mnie nie jest szczęśliwe rozwiązanie)

No to ci podałem przecież - możesz sobie użyć is_base_and_derived. Nawet chyba
jeszcze jest jedna rzecz, o której zapomniałem - static_assert. Właśnie ma
sypiącą się specjalizację dla parametru false.

> W przypadku C++ kilka razy się potknąłem o ten problem, fakt, głownie z 
> powodu przeciążania operatorów. Zaskakująco dużo istotnych typów potrafi 
>   mieć przypadkiem pokryty operator + , -> czy inne takie. Niekoniecznie 
> w sposób zgodny z tym jaki twórca  generycznego kodu w którym się tego 
> użyje przewidywał).

Wiesz, nie wiem, w jakiej firmie pracujesz/pracowałeś, że w ogóle takie rzeczy
są możliwe.

W mojej obecnej firmie w każdym razie takie coś nie miałoby szans dotrwać
nawet do UT.

W mojej poprzedniej firmie, w której trzeba przyznać, że panował niemalże
totalny bałagan jeśli chodzi o tworzenie kodu, nie było żadnego procesu,
planowanie było jedną wielką fikcją (no cóż to jest spóźnić się z release'm o
dwa miesiące), pojęcie testowania jednostkowego było dopiero w fazie "a
wiecie, mam taki pomysł" - ale przynajmniej była instytucja kierownika, nawet
trochę nieformalna. I na przeciążanie operatorów trzeba było napisać specjalne
podanie do kierownika (że tak powiem).

Nie potrafię sobie wyobrazić, jak pracuje firma, w której każdy może sobie od
niechcenia przeciążać operatory jak mu się podoba.

> >>Absolutnie źle mnie zrozumiałeś. W javie (genericsy) nie ma 
> >>metaprogramowania ani trochę.
> > 
> > 
> > Aha, jeśli tak to się zgodzę. Nie sprecyzowałeś po prostu.
> > 
> > 
> >>I to jest zaleta. Przynajmniej patrząc na to co pamiętam z C++.
> > 
> > 
> > No nie wiem. Jak słyszę takie rzeczy, że w Javie czegoś brakuje, co ma C++ i
> > że to jest zaleta, to mnie dosłownie pusty śmiech ogarnia. Jeszcze większy,
> > jak się po jakimś czasie okazuje, że to zostało częściowo potem dodane, tak
> > jak było z generykami.
> Widzisz bo to właśnie był sens Javy (i obecna moja tendencja do unikania 
>   C++). Wyrypanie tych pięknych ficzerów:
>         - bez których da się spokojnie żyć,                                             
>	  - i z których umiejętnie korzystać potrafi 1% programistów,
>         - i z których korzysta 50% reszty programistów absolutnie wypaczając sens

i bez których najczęściej nie da się napisać czytelnego i zrozumiałego kodu.

> Dokładniej:
> Makra,

Pomińmy preprocesor. Poza koniecznością wykorzystania __FILE__ i __LINE__
(ewentualnie __FUNCTION__ w gcc) nie ma on w C++ prawie żadnych zastosowań.

> meta programowanie,

Tak jasne! Zastąpmy je znacznie bardziej zawodnym (i znacznie mniej wydajnym)
dynamizmem.

> operator overloading.

No oczywiście, przecież ten poniższy kod jest bardzo czytelny:

	a.setVal(s.add(b.multiply(x.at(g.subtract(1))).divide(6)))

Nie to co C++:

	a = s + (b * x[g-1])/6;

> ( strzelam, że obecnie mnóstwo ludzi korzysta z meta programowania do 
> rozwijania prostych pętli ... co jak się nieumiejętnie robi (nie 
> sprawdza) zabija wydajność zamiast poprawiać)

Nie strzelaj lepiej, albo najpierw poćwicz trochę, jak chcesz trafiać.
Obecnie prawie nikt nie korzysta z metaprogramowania tak naprawdę. Problem
jest faktycznie rozdmuchany. Ale mocno korzystają z tego niektóre biblioteki
i naprawdę to wszystko do czego powinno to być wykorzystywane.

> Powiem więcej - mimo, że w  mniejszych projektach nie mam oporów z 
> korzystaniem z java generics... to przy większych projektach zespołowych 
> w javie... prawdopodobnie optowałbym za nie korzystaniem z genericsów (w 
> sensie tworzenia własnych typów). Czytelność i prostota kodu to jest 
> element, którego nie można pominąć, a nie wiem czy chciałbym oglądać 
> "generyczny" kod stworzony przez człowieka, który właśnie w swoim kraju 
> przeszedł kurs "learn java in 21 hours". ( w zasadzie to w ogóle nie 
> chciałbym pracować z żadnym kodem tworzonym przez takiego gościa ... 

No, może w ogóle to od tego zacznijmy. Ja mam przede wszystkim poważne
wątpliwości, czy taki gościu jest w stanie poprawnie używać generyków. Skoro
nie będzie w stanie to nie będzie ich używał.

Faktem jest, że ja ostatnio - co może nie było konieczne, ale szlag mnie
trafia, jak widzę taki kod, zresztą na inspekcji ludzie byli tego samego
zdania - poprawiłem takie oto kwiatki:

const std::string& name = std::string( "/usr/name/bin" );

i tym podobne.

> niestety jakoś ciągle mnie i wszystkich znajomych ten problem spotyka i 
> dotychczasową zaletą javy było to, że przynajmniej dawało się taki kod 
> fragmentami zrozumieć i na szybkiego załatać).

Podejrzewam, że problemy, na które się natknąłeś są java-specific.

W przypadku C++ jeśli miałem kiedykolwiek jakiekolwiek problemy z brzydkim
kodem w C++, to były one tworzone przez ludzi, którzy albo byli wyślizgani w
języku C i wszystko robili na chama, albo byli wyślizgani w Javie i wydawało
im się, że w C++ też tak jest dobrze.

> Operator overloading - już raz płakałem, że tego nie mam w Javie - ale 
> zaraz zrozumiałem, że miałby to wtedy także konkretny, (absolutnie 
> niegłupi, tylko bardzo *kreatywny* ) pan X.

Wychodzi jednak na to - jak wspomniałem - że prawdziwym problemem jest nie
niebezpieczna potencjalnie właściwość języka, tylko zła organizacja pracy.

Wygląda na to więc, że Java jest językiem dedykowanym dla firm typu "krzak", w
których nie ma żadnej sensownej organizacji pracy. Z jednej strony to dziwne,
skoro dla Javy wymyśla się tyle wypasionych technik zarządzania projektem. Z
drugiej strony, to raczej nie dziwi, skoro Java wymusza stosowanie
odśmiecacza, który - jak już nieraz zaznaczałem - potrafi skutecznie ukrywać
błędy w oprogramowaniu.

> > Nie masz się czym przejmować; boostowcy przesadzają z komplikowaniem kodu. To
> > jeszcze niczego nie oznacza.

> Jeśli to jest ta piękna biblioteka, która ma uratować C++ 
> (standaryzacja) .. to wiele znaczy.

Ja podejrzewam, że głównie te komplikacje wynikają z ograniczeń kompilatorów
oraz chęci robienia niestandardowej konfiguracji (np. inne nazwy). Bez
wypasionych ficzerów sterowania biblioteką, w najprostszej postaci, myślę że
dałoby się to zrobić znacznie prościej.

> > Ale mimo niewielu zastosowań jego istnienie jest nieocenione! Tym bardziej
> > zatem nie rozumiem, dlaczego jego brak w języku miałby być zaletą, skoro w
> > niczym nie przeszkadza.

> Zależy jak się na to patrzy. W Javie jest coś takiego jak 
> instrumentacja, refleksja, generowanie kodu w runtime... załatwia się 
> tym podobną klasę problemów co meta programowaniem w C++ (czyli dość 
> specyficzne, mocno technologiczne problemy).

No, chyba na tym się kończą podobieństwa.

> Niestety, w praktyce załatwia się też całą masę problemów, które można 
> zrobić zwyczajnie (korzystając z podstawowych własności każdego języka 
> "obiektowego").
> Taka, kurde.... moda. A potem kod się kompiluje pięknie tylko trzeba 
> debugować, żeby odkryć czegoż to jeszcze nie dodaliśmy do naszej klasy, 
> co akurat niejawnie używane jest w bibliotece XY.

Zapominasz znów, że to są problemy Java-specific. W przypadku C++ jeśli kod
"metowy" jest zły, to się po prostu nie skompiluje. Jak się skompiluje, to
najczęściej oznacza, że jest dobry. Natomiast stosowanie metod dynamicznych,
co jest bardzo powszeche w Javie, oznacza w praktyce konieczność robienia
bardzo rozbudowanych testów jednostkowych zapewniających poprawność. Często
też konieczność debugowania tego, czy te instrukcje w runtime poskładały się
do kupy tak, jak powinny.

> > I chyba destruktorów, których nie jesteś w stanie zasymulować w C w żaden
> > sposób. A jest to bardzo istotny element C++.

> z tego co pamiętam destruktory miałem -

Nie bardzo mi się chce wierzyć.

Sam miałbym problemy z ich zaimplementowaniem, mając na uwadze dowolny poziom
zagnieżdżania kontekstów wewnątrz jednej funkcji.

> > Eeee tam. No dobrze - dodają statyczną weryfikację poprawności typu. Ale to
> > wszystko.
> > 
> > Istotnym elementem wzorców w C++ jest ich "efficiency". Dlatego jest to

> Ale w jakim sensie  *efficiency* ?

W każdym. Zużycie pamięci i mocy procesora.

> To oczywiście była wielka kłótnia przy wprowadzaniu java generics jak to 
> ma być kompilowane. W praktyce gdyby przyjęto model z C++ - 
> kompilowaniem nowego kodu dla każdej konkretyzacji... to niewiele by się 
>   zmieniło (poza rozmiarami programów wynikowych).

Nie wiem, może Java ma tak badziewne VM, że takie ulepszenie nie zrobiłoby jej
róznicy.

Ale nie mam pewności. Jeśli różnica w stosie 100 milionów intów to różnica
pomiędzy 400 MB i 1.5 GB, to moim zdaniem gra była warta świeczki.

> (OK. byłyby duże zmiany w refleksji - ale to jest ( w kontekście 
> porównania z C++) wewnątrzjavowy problem).

No tak właśnie słyszałem, że to był jeden z głównych powodów.

Z drugiej strony, ciekaw jestem w takim razie, jak wygląda refleksja w
przypadku typu int.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sektor van Skijlen napisał:

>>Ale "filozoficznie" - absolutnie sie nie zgadzam. Jeśli robię jakiś 
>>framework z użyciem generics i narzucam, ze jakiś tam typ X można 
>>konkretyzować tylko klasami które np. dziedziczą z jakiejś mojej klasy 
>>Y, implementują jakiś interfejs.. daje mi to konkretną kontrolę i 
>>możliwość w miarę bezpiecznej ewolucji frameworku.
> 
> 
> No jasne i co jeszcze.
> 
> Patrzysz na to od dupy strony: nie porównuj tego z wzorcami C++, tylko
> porównaj to z tym, gdybyś sam ręcznie robił to, co generyki robią za ciebie.
> To znaczy, porównaj z kodem, który byś pisał rzeczywiście obiektowo, bez
> generyków.

Wybacz - ale nie rozumiem co masz na myśli. Właśnie porównywaliśmy z 
wzorcami  C++.


>>W przypadku C++ kilka razy się potknąłem o ten problem, fakt, głownie z 
>>powodu przeciążania operatorów. Zaskakująco dużo istotnych typów potrafi 
>>  mieć przypadkiem pokryty operator + , -> czy inne takie. Niekoniecznie 
>>w sposób zgodny z tym jaki twórca  generycznego kodu w którym się tego 
>>użyje przewidywał).
> 
> 
> Wiesz, nie wiem, w jakiej firmie pracujesz/pracowałeś, że w ogóle takie rzeczy
> są możliwe.

Tak naprawdę potykałem się najwięcej jak miałem własną firmę krzak dawno 
temu. W zasadzie dotyczyło to prób korzystania z różnych ściąganych z 
googla bibliotek, algorytmów, źródeł, których chciałem używać... 
odkryłem że w C++ to się nie da (z wymienionego powodu) (a javy wtedy 
nie znałem za bardzo).

> W mojej obecnej firmie w każdym razie takie coś nie miałoby szans dotrwać
> nawet do UT.
> 
> W mojej poprzedniej firmie, w której trzeba przyznać, że panował niemalże
> totalny bałagan jeśli chodzi o tworzenie kodu, nie było żadnego procesu,
> planowanie było jedną wielką fikcją (no cóż to jest spóźnić się z release'm o
> dwa miesiące), pojęcie testowania jednostkowego było dopiero w fazie "a
> wiecie, mam taki pomysł" - ale przynajmniej była instytucja kierownika, nawet
> trochę nieformalna. I na przeciążanie operatorów trzeba było napisać specjalne
> podanie do kierownika (że tak powiem).
> 
> Nie potrafię sobie wyobrazić, jak pracuje firma, w której każdy może sobie od
> niechcenia przeciążać operatory jak mu się podoba.

Dokładnie też sobie nie wyobrażam - dlatego właśnie unikam firm i 
projektów w C++.

>>>>Absolutnie źle mnie zrozumiałeś. W javie (genericsy) nie ma 
>>>>metaprogramowania ani trochę.
>>>
>>>
>>>Aha, jeśli tak to się zgodzę. Nie sprecyzowałeś po prostu.
>>>
>>>
>>>
>>>>I to jest zaleta. Przynajmniej patrząc na to co pamiętam z C++.
>>>
>>>
>>>No nie wiem. Jak słyszę takie rzeczy, że w Javie czegoś brakuje, co ma C++ i
>>>że to jest zaleta, to mnie dosłownie pusty śmiech ogarnia. Jeszcze większy,
>>>jak się po jakimś czasie okazuje, że to zostało częściowo potem dodane, tak
>>>jak było z generykami.
>>
>>Widzisz bo to właśnie był sens Javy (i obecna moja tendencja do unikania 
>>  C++). Wyrypanie tych pięknych ficzerów:
>>        - bez których da się spokojnie żyć,                                             
>>	  - i z których umiejętnie korzystać potrafi 1% programistów,
>>        - i z których korzysta 50% reszty programistów absolutnie wypaczając sens
> 
> 
> i bez których najczęściej nie da się napisać czytelnego i zrozumiałego kodu.
> 
> 
>>Dokładniej:
>>Makra,
> 
> 
> Pomińmy preprocesor. Poza koniecznością wykorzystania __FILE__ i __LINE__
> (ewentualnie __FUNCTION__ w gcc) nie ma on w C++ prawie żadnych zastosowań.
> 
> 
>>meta programowanie,
> 
> 
> Tak jasne! Zastąpmy je znacznie bardziej zawodnym (i znacznie mniej wydajnym)
> dynamizmem.

Zawodny.... zgadzam się.
Mniej wydajny? w jakim sensie?

>>operator overloading.
> 
> 
> No oczywiście, przecież ten poniższy kod jest bardzo czytelny:
> 
> 	a.setVal(s.add(b.multiply(x.at(g.subtract(1))).divide(6)))
> 
> Nie to co C++:
> 
> 	a = s + (b * x[g-1])/6;
> 
> 
>>( strzelam, że obecnie mnóstwo ludzi korzysta z meta programowania do 
>>rozwijania prostych pętli ... co jak się nieumiejętnie robi (nie 
>>sprawdza) zabija wydajność zamiast poprawiać)
> 
> 
> Nie strzelaj lepiej, albo najpierw poćwicz trochę, jak chcesz trafiać.
> Obecnie prawie nikt nie korzysta z metaprogramowania tak naprawdę. Problem
> jest faktycznie rozdmuchany. Ale mocno korzystają z tego niektóre biblioteki
> i naprawdę to wszystko do czego powinno to być wykorzystywane.
> 
> 
>>Powiem więcej - mimo, że w  mniejszych projektach nie mam oporów z 
>>korzystaniem z java generics... to przy większych projektach zespołowych 
>>w javie... prawdopodobnie optowałbym za nie korzystaniem z genericsów (w 
>>sensie tworzenia własnych typów). Czytelność i prostota kodu to jest 
>>element, którego nie można pominąć, a nie wiem czy chciałbym oglądać 
>>"generyczny" kod stworzony przez człowieka, który właśnie w swoim kraju 
>>przeszedł kurs "learn java in 21 hours". ( w zasadzie to w ogóle nie 
>>chciałbym pracować z żadnym kodem tworzonym przez takiego gościa ... 
> 
> 
> No, może w ogóle to od tego zacznijmy. Ja mam przede wszystkim poważne
> wątpliwości, czy taki gościu jest w stanie poprawnie używać generyków. Skoro
> nie będzie w stanie to nie będzie ich używał.
> 
> Faktem jest, że ja ostatnio - co może nie było konieczne, ale szlag mnie
> trafia, jak widzę taki kod, zresztą na inspekcji ludzie byli tego samego
> zdania - poprawiłem takie oto kwiatki:
> 
> const std::string& name = std::string( "/usr/name/bin" );
> 
> i tym podobne.
> 
> 
>>niestety jakoś ciągle mnie i wszystkich znajomych ten problem spotyka i 
>>dotychczasową zaletą javy było to, że przynajmniej dawało się taki kod 
>>fragmentami zrozumieć i na szybkiego załatać).
> 
> 
> Podejrzewam, że problemy, na które się natknąłeś są java-specific.

Jesteś coraz bardziej doskonały w swoim zacietrzewieniu.

> W przypadku C++ jeśli miałem kiedykolwiek jakiekolwiek problemy z brzydkim
> kodem w C++, to były one tworzone przez ludzi, którzy albo byli wyślizgani w
> języku C i wszystko robili na chama, albo byli wyślizgani w Javie i wydawało
> im się, że w C++ też tak jest dobrze.

He, he - dokładnie mam to samo tylko u mnie problemy są z ludźmi 
wyślizganymi w C (tworzą absurdalny kod) i  C++ (tworzą ciekawe i 
sprytne koncepcje... które w javie nie działają, nie mają sensu, albo są 
dramatycznie niewydajne).

>>Operator overloading - już raz płakałem, że tego nie mam w Javie - ale 
>>zaraz zrozumiałem, że miałby to wtedy także konkretny, (absolutnie 
>>niegłupi, tylko bardzo *kreatywny* ) pan X.
> 
> 
> Wychodzi jednak na to - jak wspomniałem - że prawdziwym problemem jest nie
> niebezpieczna potencjalnie właściwość języka, tylko zła organizacja pracy.

Idealną organizację pracy to możesz mieć z 2-3 ma dobrymi kumplami.
Co innego jak  pracujesz nad kodem, który jest rozwijany 6-7 lat w 
różnych krajach (równocześnie) i połowy deweloperów nie kojarzysz nawet 
z nazwiska. Trzeba sie zabezpieczać na wszelkie sposoby.
I jeśli zostawi się jakąś furtkę to zawsze znajdzie sie ktoś kto w nią 
wlizie (bez pozwolenia). W takim projekcie jedyną rozsądną formą 
sprawdzania jest ... automatyzacja - (kontrola stylu, cyclomatic 
complexity, unit testy etc.). Wybór bardziej koszernego języka jest 
jedną z form tej automatyzacji. W zasadzie myślę, ze nie patrzysz na 
problem z tego punktu widzenia co ja. Dla mnie różnice miedzy C++ 
(dobrze opakowanym w boost, stl, gc,  itp) a Javą (z puntku widzenia 
samego języka) są małe. Jest to ten sam, hakerski, imperatywny, bez 
polotu język (tylko przynoszący zysk).
Idąc dalej w projektach, gdzie mogę to narzucić nie używam javy ... 
tylko jej mocno ograniczonego podzbioru (narzuconego kontrolą stylu, 
miarami  itp).

> Wygląda na to więc, że Java jest językiem dedykowanym dla firm typu "krzak", w
> których nie ma żadnej sensownej organizacji pracy. Z jednej strony to dziwne,
> skoro dla Javy wymyśla się tyle wypasionych technik zarządzania projektem. Z
> drugiej strony, to raczej nie dziwi, skoro Java wymusza stosowanie
> odśmiecacza, który - jak już nieraz zaznaczałem - potrafi skutecznie ukrywać
> błędy w oprogramowaniu.

Przeczytaj sobie cały ten swój paragraf jeszcze raz. Zastanów się co 
piszesz. Weź sie, kurde, umyj.

Spędziłem kiedyś parę tygodni poszukując wycieku pamięci w średnim 
projekcie w C++ bez odśmiecacza... i znalazłem, że gdzieś było użyte 
delete ... zamiast delete[]. To mi wystarczyło. Nadal pisałem w C++, ale 
dostawiłem sobie odsmieczacz, potem dostawiłem obsługe wątków rozsądną i 
kilka takich ficzerów i mój team odkrył, że piszemy w javie :-).
Mieliśmy z tego nawet ostrą radochę. W końcu przy kolejnym projekcie
pozostało skończyć z hipokryzją i zwyczajnie zacząć pisać w normalnej javie.

>>>Nie masz się czym przejmować; boostowcy przesadzają z komplikowaniem kodu. To
>>>jeszcze niczego nie oznacza.
> 
> 
>>Jeśli to jest ta piękna biblioteka, która ma uratować C++ 
>>(standaryzacja) .. to wiele znaczy.
> 
> 
> Ja podejrzewam, że głównie te komplikacje wynikają z ograniczeń kompilatorów
> oraz chęci robienia niestandardowej konfiguracji (np. inne nazwy). Bez
> wypasionych ficzerów sterowania biblioteką, w najprostszej postaci, myślę że
> dałoby się to zrobić znacznie prościej.

Też tak myśle :-)

>>>Ale mimo niewielu zastosowań jego istnienie jest nieocenione! Tym bardziej
>>>zatem nie rozumiem, dlaczego jego brak w języku miałby być zaletą, skoro w
>>>niczym nie przeszkadza.
> 
> 
>>Zależy jak się na to patrzy. W Javie jest coś takiego jak 
>>instrumentacja, refleksja, generowanie kodu w runtime... załatwia się 
>>tym podobną klasę problemów co meta programowaniem w C++ (czyli dość 
>>specyficzne, mocno technologiczne problemy).
> 
> 
> No, chyba na tym się kończą podobieństwa.
> 
> 
>>Niestety, w praktyce załatwia się też całą masę problemów, które można 
>>zrobić zwyczajnie (korzystając z podstawowych własności każdego języka 
>>"obiektowego").
>>Taka, kurde.... moda. A potem kod się kompiluje pięknie tylko trzeba 
>>debugować, żeby odkryć czegoż to jeszcze nie dodaliśmy do naszej klasy, 
>>co akurat niejawnie używane jest w bibliotece XY.
> 
> 
> Zapominasz znów, że to są problemy Java-specific. W przypadku C++ jeśli kod
> "metowy" jest zły, to się po prostu nie skompiluje. Jak się skompiluje, to
> najczęściej oznacza, że jest dobry. Natomiast stosowanie metod dynamicznych,
Nie jest tak jak piszesz - skompiluje sie i wylezie problem dopiero np. 
na testach - podawałem już dlaczego.

> co jest bardzo powszeche w Javie, oznacza w praktyce konieczność robienia
> bardzo rozbudowanych testów jednostkowych zapewniających poprawność. Często
> też konieczność debugowania tego, czy te instrukcje w runtime poskładały się
> do kupy tak, jak powinny.
Dokładnie tak jest w jednym i w drugim języku. Zaczynam poważnie 
podejrzewać, że nie masz wielkiej styczności z C++ :-)

>>>I chyba destruktorów, których nie jesteś w stanie zasymulować w C w żaden
>>>sposób. A jest to bardzo istotny element C++.
> 
> 
>>z tego co pamiętam destruktory miałem -
> 
> 
> Nie bardzo mi się chce wierzyć.
> 
> Sam miałbym problemy z ich zaimplementowaniem, mając na uwadze dowolny poziom
> zagnieżdżania kontekstów wewnątrz jednej funkcji.

Stary, jak to ? przecież w makrach da się wszystko zrobić :-)
w C też.


>>>Eeee tam. No dobrze - dodają statyczną weryfikację poprawności typu. Ale to
>>>wszystko.
>>>
>>>Istotnym elementem wzorców w C++ jest ich "efficiency". Dlatego jest to
> 
> 
>>Ale w jakim sensie  *efficiency* ?
> 
> 
> W każdym. Zużycie pamięci i mocy procesora.
Pomyliłeś się w jednym i drugim.
Bo to nie jest takie proste jak Ci się wydaje.
Głównym powodem takiej a nie innej implementacji java generics są ... 
urządzenia mobilne. Chcieli chłopaki objętość programów ograniczyć... bo 
stwierdzili, że to może być większy problem niż rozmiar danych.
(wcale nie mam pewności co do tej tezy  -ale nie ja ją wymyśliłem a nie 
jestem specem od oprogramowania małych urządzonych, żeby sie wypowiadać).
(Fakt, że na normalne komputery do zastosowań nawet desktopowych 
objętość kodu programu ma marginalne znaczenie)

Co do zużycia procesora - to jest zagadnienie już inne - ale patrząc na 
to, że finalnemu kodowi w asemblerze zupełnie zwisa jaki co ma typ to 
ten argument jest taki sobie.

>>To oczywiście była wielka kłótnia przy wprowadzaniu java generics jak to 
>>ma być kompilowane. W praktyce gdyby przyjęto model z C++ - 
>>kompilowaniem nowego kodu dla każdej konkretyzacji... to niewiele by się 
>>  zmieniło (poza rozmiarami programów wynikowych).
> 
> 
> Nie wiem, może Java ma tak badziewne VM, że takie ulepszenie nie zrobiłoby jej
> róznicy.
> 
> Ale nie mam pewności. Jeśli różnica w stosie 100 milionów intów to różnica
> pomiędzy 400 MB i 1.5 GB, to moim zdaniem gra była warta świeczki.

Argument dobry i prawdziwy ale jednak dość specyficzny... lepiej było 
stos stu  milionów booleanów podać. (to dopiero byłby dramat).
(pomyśl o std::vector<bool> kiedyś ktoś walnął tym samym argumentem co 
ty porównując C z C++ :-) ).
Co za problem zdobyć na tak specyficzny przypadek odpowiednio 
przygotowaną implementację.
Fakt jest taki, że java generics ma słabą stronę pod tytułem tablice.
(nie wiem czy to będzie zmienione, poprawione w przyszłości- są różne 
koncepcje. )


>>(OK. byłyby duże zmiany w refleksji - ale to jest ( w kontekście 
>>porównania z C++) wewnątrzjavowy problem).
> 
> 
> No tak właśnie słyszałem, że to był jeden z głównych powodów.
> 
> Z drugiej strony, ciekaw jestem w takim razie, jak wygląda refleksja w
> przypadku typu int.

Całkiem nieźle - (kiedyś mnie to pozytywnie zaskoczyło). Sprawdź sobie.

-- 
http://www.99-bottles-of-beer.net/language-java-866.html

Dnia Sat, 22 Oct 2005 12:19:43 +0200, jarekr skrobie:
> Sektor van Skijlen napisał:

> >>Ale "filozoficznie" - absolutnie sie nie zgadzam. Jeśli robię jakiś 
> >>framework z użyciem generics i narzucam, ze jakiś tam typ X można 
> >>konkretyzować tylko klasami które np. dziedziczą z jakiejś mojej klasy 
> >>Y, implementują jakiś interfejs.. daje mi to konkretną kontrolę i 
> >>możliwość w miarę bezpiecznej ewolucji frameworku.
> > 
> > 
> > No jasne i co jeszcze.
> > 
> > Patrzysz na to od dupy strony: nie porównuj tego z wzorcami C++, tylko
> > porównaj to z tym, gdybyś sam ręcznie robił to, co generyki robią za ciebie.
> > To znaczy, porównaj z kodem, który byś pisał rzeczywiście obiektowo, bez
> > generyków.

> Wybacz - ale nie rozumiem co masz na myśli. Właśnie porównywaliśmy z 
> wzorcami  C++.

Na razie to dywagowaliśmy, jakiej jakości jest "ficzer" generyków dodatny w
Javie i czy coś to dobrego językowi przyniosło. W tym celu należy porównać
pisanie z generykami i pisanie tego samego bez nich.

> >>W przypadku C++ kilka razy się potknąłem o ten problem, fakt, głownie z 
> >>powodu przeciążania operatorów. Zaskakująco dużo istotnych typów potrafi 
> >>  mieć przypadkiem pokryty operator + , -> czy inne takie. Niekoniecznie 
> >>w sposób zgodny z tym jaki twórca  generycznego kodu w którym się tego 
> >>użyje przewidywał).
> > 
> > 
> > Wiesz, nie wiem, w jakiej firmie pracujesz/pracowałeś, że w ogóle takie rzeczy
> > są możliwe.

> Tak naprawdę potykałem się najwięcej jak miałem własną firmę krzak dawno 
> temu. W zasadzie dotyczyło to prób korzystania z różnych ściąganych z 
> googla bibliotek, algorytmów, źródeł, których chciałem używać... 
> odkryłem że w C++ to się nie da (z wymienionego powodu) (a javy wtedy 
> nie znałem za bardzo).

Nie rozumiem. Znaczy się co, miałeś problem z korzystaniem z tego z uwagi na
szurnięte użycie przeciążania operatorów?

> > Nie potrafię sobie wyobrazić, jak pracuje firma, w której każdy może sobie od
> > niechcenia przeciążać operatory jak mu się podoba.

> Dokładnie też sobie nie wyobrażam - dlatego właśnie unikam firm i 
> projektów w C++.

Ależ niemożliwość przeciążąnia operatorów niczego ci nie załatwi.

W Javie można zrobić kupę różnych głupot również z wielu innych powodów. Pod
tym względem Java może jest mniej harmful, niż C++, ale wcale to nie oznacza,
że się pod tym względem bardziej nadaje do tworzenia oprogramowania.

Zresztą dla mnie argument jest z gruntu kuriozalny: chcemy mieć dobre
oprogramowanie, to zatrudniajmy dobrych programistów i przede wszystkim
PATRZMY IM NA RĘCE. Nie ma lepszego filtra na dobry kod niż dobry, zaufany
kierownik; narzędzia do mierzenia złożoności (różne Mckejby i klocworki) kodu
trochę pomagają, ale tylko trochę.

> >>meta programowanie,
> > 
> > Tak jasne! Zastąpmy je znacznie bardziej zawodnym (i znacznie mniej wydajnym)
> > dynamizmem.

> Zawodny.... zgadzam się.
> Mniej wydajny? w jakim sensie?

Nie rozśmieszaj mnie nawet. Tłukę ten temat już od dłuższego czasu.

> >>operator overloading.
> > 
> > No oczywiście, przecież ten poniższy kod jest bardzo czytelny:
> > 
> >       a.setVal(s.add(b.multiply(x.at(g.subtract(1))).divide(6)))
> > 
> > Nie to co C++:
> > 
> >       a = s + (b * x[g-1])/6;
> > 

> >>niestety jakoś ciągle mnie i wszystkich znajomych ten problem spotyka i 
> >>dotychczasową zaletą javy było to, że przynajmniej dawało się taki kod 
> >>fragmentami zrozumieć i na szybkiego załatać).
> > 
> > 
> > Podejrzewam, że problemy, na które się natknąłeś są java-specific.

> Jesteś coraz bardziej doskonały w swoim zacietrzewieniu.

No przecież mówiłeś akurat o problemach, które w C++ by nie zaistniały z
przyczyn zasadniczych. Więc nie rozumiem, o co ci chodzi z tym
zacietrzewieniem.

> > W przypadku C++ jeśli miałem kiedykolwiek jakiekolwiek problemy z brzydkim
> > kodem w C++, to były one tworzone przez ludzi, którzy albo byli wyślizgani w
> > języku C i wszystko robili na chama, albo byli wyślizgani w Javie i wydawało
> > im się, że w C++ też tak jest dobrze.

> He, he - dokładnie mam to samo tylko u mnie problemy są z ludźmi 
> wyślizganymi w C (tworzą absurdalny kod) i  C++ (tworzą ciekawe i 
> sprytne koncepcje... które w javie nie działają, nie mają sensu, albo są 
> dramatycznie niewydajne).

No właśnie to mnie interesuje. Jak może programista C++ źle pisać w Javie?
Przykłady poproszę.

> >>Operator overloading - już raz płakałem, że tego nie mam w Javie - ale 
> >>zaraz zrozumiałem, że miałby to wtedy także konkretny, (absolutnie 
> >>niegłupi, tylko bardzo *kreatywny* ) pan X.
> > 
> > 
> > Wychodzi jednak na to - jak wspomniałem - że prawdziwym problemem jest nie
> > niebezpieczna potencjalnie właściwość języka, tylko zła organizacja pracy.

> Idealną organizację pracy to możesz mieć z 2-3 ma dobrymi kumplami.

Idealnej, to od tego zacznijmy, miał nigdy nie będziesz.

W naszej firmie mamy jednak organizację pracy wystarczającą do zapewnienia
dobrej jakości kodu - pod KAŻDYM względem.

> Co innego jak  pracujesz nad kodem, który jest rozwijany 6-7 lat w 
> różnych krajach (równocześnie) i połowy deweloperów nie kojarzysz nawet 
> z nazwiska. Trzeba sie zabezpieczać na wszelkie sposoby.

No właśnie nad takim pracuję.

> I jeśli zostawi się jakąś furtkę to zawsze znajdzie sie ktoś kto w nią 
> wlizie (bez pozwolenia).

Zdarzały się takie próby. Jak oglądał to jakiś kierownik w Stanach, to
faktycznie niektórzy włazili. U nas jednak się to jeszcze nie zdarzyło. U nas
kierownicy są tak skuteczni, że żadnemu takiemu sabotażyście nie przepuszczą.

U nas na WSZYSTKO trzeba mieć pozwolenie. Od kierownika. Każdy kawałek kodu,
który powstaje, albo jest zmieniany, musi przejść przez jego oczy.

> W takim projekcie jedyną rozsądną formą 
> sprawdzania jest ... automatyzacja - (kontrola stylu, cyclomatic 
> complexity,

Taaa... najnormalniej w świecie oszukujecie się. Faktem jest, że to jest też
dobre, bo powstrzyma zapędy różnych cwaniaczków od robienia syfu, ale to nie
jest lekarstwo na wszystkie problemy.

> unit testy etc.).

Nie wiem, co takiego jest niezwykłego w UT, przecież to normalny etap pracy
nad oprogramowaniem.

> Wybór bardziej koszernego języka jest jedną z form tej automatyzacji.

Co za szurnięty argument...

Jeśli potrzeba nam faktycznie jakiegoś sprawdzania, czy użytkownik nie użył
czasem takiej-a-takiej zakazanej konstrukcji, to można albo zrobić narzędzie,
które samo to sprawdzi, albo to tak czy siak wyjdzie na inspekcji.

To samo dotyczy C++ jak i Javy.

> W zasadzie myślę, ze nie patrzysz na 
> problem z tego punktu widzenia co ja. Dla mnie różnice miedzy C++ 
> (dobrze opakowanym w boost, stl, gc,  itp) a Javą (z puntku widzenia 
> samego języka) są małe. Jest to ten sam, hakerski, imperatywny, bez 
> polotu język (tylko przynoszący zysk).
> Idąc dalej w projektach, gdzie mogę to narzucić nie używam javy ... 
> tylko jej mocno ograniczonego podzbioru (narzuconego kontrolą stylu, 
> miarami  itp).

To ja nie rozumiem, z jakiego punktu widzenia ty patrzysz na problem.
Mogę to określić w ten sposób:

Masz zespół kilku programistów, którzy nad kodem nie mają żadnej kontroli (w
każdej chwili ten kod może wziąć kto inny i namieszać).

Nikt nie ma kontroli nad tym, jak oni ten kod piszą.

Nikt tego kodu po nich nie ogląda.

Każdy sobie pisze jak mu się podoba i nikt nie sprawdza, co każdy gość
naskrobał.

Może to, że ja z takim sposobem tworzenia oprogramowania nie miałem do
czynienia nigdy od czasu rozpoczęcia pracy w mojej bieżącej firmie, powoduje
właśnie tą różnicę w punktach widzenia.

> > Wygląda na to więc, że Java jest językiem dedykowanym dla firm typu "krzak", w
> > których nie ma żadnej sensownej organizacji pracy. Z jednej strony to dziwne,
> > skoro dla Javy wymyśla się tyle wypasionych technik zarządzania projektem. Z
> > drugiej strony, to raczej nie dziwi, skoro Java wymusza stosowanie
> > odśmiecacza, który - jak już nieraz zaznaczałem - potrafi skutecznie ukrywać
> > błędy w oprogramowaniu.

> Przeczytaj sobie cały ten swój paragraf jeszcze raz. Zastanów się co 
> piszesz. Weź sie, kurde, umyj.

Nie obawiaj się o moją świadomość podczas pisania. To akurat mówi każdy, kto
przeprowadził rzeczową analizę o tym, jakie zmiany w języku wprowadza
obowiązkowy odśmiecacz i jakie są jego zalety i wady.

> Spędziłem kiedyś parę tygodni poszukując wycieku pamięci w średnim 
> projekcie w C++ bez odśmiecacza... i znalazłem, że gdzieś było użyte 
> delete ... zamiast delete[].

A mogę zapytać, w jaki sposób to znalazłeś? Czy może poprzez debugowanie kodu?
Jeśli tak, to rzeczywiście, nie dziwię się, dlaczego musisz używać
"ograniczonych języków".

> To mi wystarczyło. Nadal pisałem w C++, ale dostawiłem sobie odsmieczacz,

Typowe podejście w stylu łatania bezpiecznika drutem.

Odśmiecacz _NIE_ załatwi ci problemu wycieków pamięci. Pozwoli ci tylko co
najwyżej mieć tą pamięć pod kontrolą, co najczęściej oznacza, że jesteś w
stanie powstrzymać co najwyżej tzw. progresywne wycieki pamięci. Mające
znaczenie tylko gdy są faktycznie częste, a aplikacja ma chodzić długo bez
restartu.

Jeśli masz jakieś przekonujące argumenty, że jednak odśmiecacz ma zalety, to
zapoznaj się najpierw z tym poniżej:

http://warp.povusers.org/grrr/java.html

> > Zapominasz znów, że to są problemy Java-specific. W przypadku C++ jeśli kod
> > "metowy" jest zły, to się po prostu nie skompiluje. Jak się skompiluje, to
> > najczęściej oznacza, że jest dobry. Natomiast stosowanie metod dynamicznych,
> Nie jest tak jak piszesz - skompiluje sie i wylezie problem dopiero np. 
> na testach - podawałem już dlaczego.

Pokaż mi jak i dlaczego - niczego nie napisałeś jak do tej pory o tym,
dlaczego tego typu problemy są w C++ przy wzorcach. O ewentualnych przykładach
nie wspominając.

> > co jest bardzo powszeche w Javie, oznacza w praktyce konieczność robienia
> > bardzo rozbudowanych testów jednostkowych zapewniających poprawność. Często
> > też konieczność debugowania tego, czy te instrukcje w runtime poskładały się
> > do kupy tak, jak powinny.
> Dokładnie tak jest w jednym i w drugim języku. Zaczynam poważnie 
> podejrzewać, że nie masz wielkiej styczności z C++ :-)

Dokładnie tak jest w jednym i w drugim języku, ale o ile w C++ jest występuje
to tylko w tych miejscach, w których rzeczywiście dynamizmu używamy, o tyle w
Javie występują one po prostu WSZĘDZIE, bo WSZĘDZIE używa się dynamizmu.

Skoro ty nie wiesz takich prostych rzeczy, to pewnie dlatego, że od początku
traktowałeś C++ jak Javę bez odśmiecacza. Co też odpowiednio świadczy o twojej
znajomości C++.

> > Sam miałbym problemy z ich zaimplementowaniem, mając na uwadze dowolny poziom
> > zagnieżdżania kontekstów wewnątrz jednej funkcji.

> Stary, jak to ? przecież w makrach da się wszystko zrobić :-)

Nie wstawienie odpowiednich kawałków kodu w arbitralnych miejscach.

> w C też.

No jasne, pożartujmy sobie jeszcze.

> >>>Eeee tam. No dobrze - dodają statyczną weryfikację poprawności typu. Ale to
> >>>wszystko.
> >>>
> >>>Istotnym elementem wzorców w C++ jest ich "efficiency". Dlatego jest to
> > 
> > 
> >>Ale w jakim sensie  *efficiency* ?
> > 
> > 
> > W każdym. Zużycie pamięci i mocy procesora.
> Pomyliłeś się w jednym i drugim.
> Bo to nie jest takie proste jak Ci się wydaje.

Oczywiście, że jest proste.

Jeśli mam choćbyu ten cały stos intów, to overhead na każdy obiekt klasy
opakowującej doskonale obniża wydajność, jeśli porównać to z używaniem
"gołych" intów. I to wydajność pod "każdym" względem.

> Głównym powodem takiej a nie innej implementacji java generics są ... 
> urządzenia mobilne.

Taaa.. bardzo jestem ciekawy, skąd ty masz takie informacje.

> Chcieli chłopaki objętość programów ograniczyć... bo 
> stwierdzili, że to może być większy problem niż rozmiar danych.

Zaraz się chyba rozpłaczę do rozpuku. W sytuacji gdy różnica w objętości
pomiędzy kodem a danymi liczy się w rzędach wielkości, goście martwią się, że
im się kod niebezpiecznie rozrasta.

> (wcale nie mam pewności co do tej tezy  -ale nie ja ją wymyśliłem a nie 
> jestem specem od oprogramowania małych urządzonych, żeby sie wypowiadać).

To może powiedz mi, kto ją w takim razie wymyślił.

> (Fakt, że na normalne komputery do zastosowań nawet desktopowych 
> objętość kodu programu ma marginalne znaczenie)

Objętość kodu programu ma marginalne znaczenie w ogóle. Zwłaszcza
wystarczająco dobrze o tym świadczy popularność optymalizacji przez rozwijanie
pętli i wywołań.

Z tego, co ja wiem, to generyki są jakie są tylko i wyłącznie dlatego, że jest
to jedyna metoda, żeby wpasowały się w aktualne reguły wirtualnej maszyny
(przynajmniej tak twierdził Anders Hejlsberg).

> Co do zużycia procesora - to jest zagadnienie już inne - ale patrząc na 
> to, że finalnemu kodowi w asemblerze zupełnie zwisa jaki co ma typ to 
> ten argument jest taki sobie.

Ale nie zwisa mu to, ile razy dereferuje wskaźnik i ile szurniętych operacji
musi wykonać, żeby przeprowadzić operację na takich wartościach.

> >>To oczywiście była wielka kłótnia przy wprowadzaniu java generics jak to 
> >>ma być kompilowane. W praktyce gdyby przyjęto model z C++ - 
> >>kompilowaniem nowego kodu dla każdej konkretyzacji... to niewiele by się 
> >>  zmieniło (poza rozmiarami programów wynikowych).
> > 
> > 
> > Nie wiem, może Java ma tak badziewne VM, że takie ulepszenie nie zrobiłoby jej
> > róznicy.
> > 
> > Ale nie mam pewności. Jeśli różnica w stosie 100 milionów intów to różnica
> > pomiędzy 400 MB i 1.5 GB, to moim zdaniem gra była warta świeczki.

> Argument dobry i prawdziwy ale jednak dość specyficzny... lepiej było 
> stos stu  milionów booleanów podać. (to dopiero byłby dramat).

Ty chyba jesteś chory. Ale dobra, niech dzisiaj znów będzie dzień dziecka:

Możliwe, że przykład nt. 100 milionów intów jest mało praktyczny. Ale nie ma
żadnej różnicy pomiędzy tym, czy mamy jeden zbiornik po 100 milionów, czy dwa
po 50. Tak? Skoro tak, to znaczy że nie ma również różnicy pomiędzy
posiadaniem jednego zbiornika, który ma 20 milionów intów, i drugiego, który
posiada 20 milionów liczb zespolonych?

I tak rozdrabniając to coraz bardziej, dochodzimy do bardziej praktycznych
przykładów, a stosunek zajętości pamięci programu w Javie i programu w C++,
gdzie używa się typów wartościowych, pozostaje prawie taki sam. Może i różnica
trzykrotnej objętości jest przesadzona, ale weź też pod uwagę, że ta zajętość
pamięci w przypadku Javy jest i tak wzięta z przesadnym optymizmem. Dlatego w
najlepszym razie program w Javie może zająć jedynie dwa razy więcej pamięci,
niż program w C++.

Jeśli zaś program w C++ zajmuje ci w czasie działania 500 MB pamięci, to
wykonujący to samo program w Javie...

No dobra. Koniec dnia dziecka na dzisiaj.

> (pomyśl o std::vector<bool> kiedyś ktoś walnął tym samym argumentem co 
> ty porównując C z C++ :-) ).

No nie rozumiem o co ci chodzi. Przecież w vector<bool> każdy element zajmuje
jeden bit. Więc vector<bool> zajmie ci zawsze tyle, co ilość bitów wyrównana
do pełnych ośmiu plus stały overhead (12 bajtów).

Nie zawsze też interesuje nas dynamiczny wektor bitowy; czasem pewnie też
sensownie jest użyć statycznego zbiornika z bitami, czyli bitset.

> Co za problem zdobyć na tak specyficzny przypadek odpowiednio 
> przygotowaną implementację.

Tak, a potem na jeszcze specyficzną i jeszcze specyficzną...

I pamiętaj tylko potem, że musisz użyć VectorBoolean a nie Vector<boolean>.

> Fakt jest taki, że java generics ma słabą stronę pod tytułem tablice.
> (nie wiem czy to będzie zmienione, poprawione w przyszłości- są różne 
> koncepcje. )

Ciekawi mnie, dlaczego tak jest, swoją drogą (nb. trzeba przyznać panu AL:
rzeczywiście "eleganckie rozszerzenie języka").


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sektor van Skijlen napisał:

> Z bardzo prostej przyczyny: nikt jeszcze nie podał żadnego racjonalnego
> kontrargumentu. Masz okazję, chwilowo nie wiem dlaczego nie skorzystałeś.
> 
> 
>>to że w javie, żeby wykonywać 
>>operacje na funkcjach potrzeba czasem więcej linijek kodu niż w C++
>>jest słabym argumentem.
> 
> 
> Nie bądź śmieszny. To nie jest tylko "trochę więcej linijek" (nb. nie rozumiem
> dlaczego fakt, że trzeba się więcej opisać w dokładnie tym samym stylu, ma być
> słabym argumentem).
> 
> 
>>(w dowolnym assemblerze wskaźnik do funkcji ustawić 
>>można w jednej linijce i nawet sie typem nie trzeba przejmować !).
> 
> 
> Ale nie rozumiem, co to ma do tematu ;)
Do jest do tego co dopiero przed chwilą napisałeś (musiałem wyprzedzić 
dyskusje). Przeczytaj swój paragraf.

>>>>>- nie pozwala operowa? zmiennymi typów ?cis?ych (jedynie ich warto?ciami)
>>>
>>>
>>>>Ze co?...
>>>
>>>
>>>Przekaż mi pan zmienną do metody. Tak, żeby metoda mogła ją zapisać.
>>>
>>
>>Panu A.L. chodziło, jak mniemam o sens twojego zdania - teraz lekko 
>>doprecyzowałeś. (nadal dziwnie, ale już chyba wiem o co Ci chodzi (ale 
>>nie wierzę ...bo to kuriozalny argument) )
>>Lepiej pokaż konkretnie (kod).
> 
> 
> Oj przestań, nawet mnie nie próbuj zanudzać stwierdzeniami, że w Javie się "po
> prostu piszę inaczej", że powinienem zmienić mój sposób myślenia i stosować
> inne techniki, bo się rozpłaczę do rozpuku. To samo słyszę nt. każdego
> narzekania na właściwości Javy i to narzekania nie tylko takich gołodziobów
> jak ja, którzy jedynie "stosują jak muszą", ale prawdziwych praktyków, którzy
> na z niejednego pieca projektach zęby zjedli.

Przestań pleść dyrdymały i napisz w końcu - kod - o co Ci chodzi?


>>>>>- nie dostarcza zaawansowanych metod generycznych (te Javowe generyki to jest
>>>>> jeden wielki pic na wod?; zwyk?y lukier sk?adniowy)
>>>
>>>
>>>>Niby dlaczego?..
>>>
>>>
>>>Sprawdź sobie pan boost::mpl (co ja mówię! Głupie STL!), to się dowiesz.
> 
> 
>>znajdzie zapewne tak piękne fragmenty jak:
>>
>>>#include <boost/mpl/aux_/config/msvc.hpp>
>>>#include <boost/mpl/aux_/config/workaround.hpp>
> 
> 
> Ty sobie lepiej zajrzyj do implementacji Swings. Bo to, co pokazałeś niżej, to
Nie wiem co to jest Swings.
> jest tylko workaround na badziewny kompilator (co nawet widać po tych dwóch
> pierwszych linijkach). Gdyby to był kod pisany tylko pod kompilatory
> rzeczywiście zgodne ze standardem, nie byłoby żadnych makr. Zresztą, niech
> dzisiaj będzie dzień dziecka:
> 
> Po pierwsze, to ja mimo wszystko wolę mieć dowolny kompilator do wyboru, niż
> jedno centrum decyzyjne tworzące język i jego implementację.

Bzdury pleciesz.
W javie jest jedno centrum (SUN) zarządzające standardem. Dostarcza też 
jedną implementację.
Inne implementacje dostarcza IBM, BEA (JRockit). Korzystałem z tych 
implementacji wielokrotnie - wiem, ze są bardzo dobrze zgodne z sunowską 
javą.
Jest też (absurdalny)  gcj. (zgodny ale powolny )
Te wszystkie implementacje muszą spełniać pewne standardy (albo dostają
czerwoną kartkę jak MS Java). Dzięki temu nie mam w kodzie ton makr, 
które muszą naprawiać niekompatybilności i inne takie.


> Po drugie, co mnie obchodzi implementacja? Do implementacji zaglądam jak
> jestem ciekawy, jak to goście wykoncypowali. Użytkownika interesuje jedynie
> interfejs.

TO ty zasugerowałeś zebym zaglądał do boost::mpl. Pech chciał, że 
zaglądnąłem.

>>>>>- nie pozwala stosowa? mechanizmu RAII
>>>
>>>
>>>>Ze co?..
>>>
>>>

> No, bardzo chętnie się dowiem, jakie to techniki w Javie są stosowane zamiast
> RAII i zapewniają tą samą skuteczność zarządzania zasobami. I nie rozśmieszaj
> mnie znów argumentem, że to rzadka potrzeba i nic nie szkodzi, że mało
> wygodne.

Znowu się rozwodzisz nad finally -  a ja napisałem jest inna prosta 
technika.

Po prostu zamiast takiego zapisu jak w C++:
{
	DBConnection db("bla");/*klasa DBConnection ma odpowiednio napsiany 
destruktor i konstruktor*/

	[kod koprzystający z db]
}

mam taki (java):
{
	dbManager.execute ( new DBMethod()  {
			public void run(final DBContext context)
			{
				DBConnection db =				context.createConnection("bla");
				[kod koprzystający z db]
			}
		} );
}

po prostu o ile w C++ kluczowe zarządzanie zasobami mam w konstruktorze 
i destruktorze to w Javie wywalam do odpowiedniego menadżera.
Dla programisty końcowego efekt jest podobny. Może sobie tworzyć ile 
chce  - po wylezieniu z funkcji (klamry) - wszystko jest zamykane. (bo 
metoda execute w menadżerze ma finally :-) .)

>>( w końcu wszelkie biblioteki do 
>>obsługi różnych zasobów są dawno popisane  )
> 
> 
> Tak, szczególnie takich, o których twórcy owych bibliotek nie mieli szans
> wiedzieć w czasie pisania.
>>>
>>>>> zezwolenia udzielane s? wybiórczo; w tym wszystkim oczywi?cie te? brak
>>>>> przeci??ania operatorów)
>>
>>Wybiórczo?, zezwolenia w C++? O ile ktoś sie do d... nie dobierze 
>>rzutując na jakiś void*.
> 
> 
> Oj ty młody i naiwny...
> 
> Masz tu klasę:
> 
> class Value
> {
> public:
> 	int in;
> 
> private:
> 	int operator&() const { return 0; }
> 	template <class T>
> 	operator T&();
> 
> 	template <class T>
> 	operator const T&() const;
> };
> 
> Wiszę ci półkę, jak mi zmienną typu Value zrzutujesz na void*. Powodzenia.

to weź to Panie nie naiwny:
#include <iostream>

class Value
{
public:
	int in;

private:
	int operator&() const { return 0; }
	template <class T>
	operator T&();

	template <class T>
	operator const T&() const;
};


class BadValue
{
public:
	int in;
};

class Proof
{
public:
	BadValue*  v;
};

class BadUnion
{
public:
	const Value& v;
	
	BadUnion( const Value& argV)
	: v(argV)
	{
	}		
};

int main()
{

	Value v2;

	v2.in = 3;
	std::cout<<"\ntest a:"<<v2.in;

	BadUnion bu(v2);
				
	Proof* cham = (Proof*)&bu;

	std::cout<<"\ntest b:"<<(int)cham<<"\n";
		
	//i tu mam void*
	void* cham2 = (void*)&(*(cham->v));
	std::cout<<"\ntest f:"<<(int)cham2<<"\n";

	BadValue* cham3 = (BadValue*)(cham2);
	std::cout<<"\ntest c:"<<cham3->in<<"\n";
	cham3->in = 666; //tu jest zło :-)
	std::cout<<"\ntest d:"<<v2.in<<"\n";	
}


gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)

(nie przykładałem sie do nazw i kodu - tak z palca strzeliłem za drobną 
poprawką - przyznam, sie ze pierwszy pomysł nie działał (referencje nie 
mogą być częścią uni ) )
>>A w javie jakoś te aplety, servlety, ejb i inne inszety działają i 
>>"wyoranie się z java security" nie jest takim trywialnym zagadnieniem.
> 
> 
> Mnie średnio interesuje, jakie security muszą przejść te różne napletki i
> serwetki. To ma się nijak do języka - jest to zupełnie osobna kwestia, którą
> dana aplikacja musi przejść niezależnie od języka, w którym jest napisana.
> 
> 
>>>Kiedyś ludzie mówili, że doskonale, że Java nie ma niczego takiego, jak wzorce
>>>w C++. Po czym dodano generyki.
> 
> 
>>Jasne... pewnie dlatego "Generic java" - projekt, który po prostu 
>>niedawno wszedł do standardowej dystrybucji (po pewnych modyfikacjach) 
>>był utworzony gdzieś około roku 1998.
> 
> 
> Całkiem nieźle. Niedawno, czyli będzie to tak ze dwa lata temu (nie pamiętam,
> od kiedy dokładnie generyki są w Javie). Nawet licząc, że stało się to po
> czterech latach od momentu utworzenia i nawet licząc duży overhead formalny,
> to trzeba przyznać, że goście "długo główkowali". Jak na to, co wymyślili, to
> powinno im to zająć góra dwa miesiące, no, trzy powiedzmy, jeśli liczymy, że
> dwa z tych miesięcy zajął formalny overhead.

nie czytasz, nie wiesz, pleciesz - generic java działało gdzieś od 1999 
własnie...
a tylko tyle czasu Sun nie mógł się zdecydować czy to wpleść do 
dystrybucji. (zresztą imho - nie musiał - to był krok czysto 
marketingowy - ja z generic java korzystałem swobodnie dużo wcześniej).

> Skoro jednak zajęło im to aż tyle czasu, to widzę tylko jedno racjonalne
> wyjaśnienie: po prostu generyki zrobili zapaleńcy, którzy doskonale zdawali
> sobie sprawę z tego, że są one potrzebne (dla każdego człowieka, który wie,
> czym się różni statyczna i dynamiczna typizacja, zwłaszcza w języku
> wspierającym OO, jest to co najmniej oczywiste). Ale nikt nie miał zamiaru
> dodawać ich do języka; edukatorzy i piewcy woleli robić z siebie idiotów i
> udowadniać na wszelkie możliwe sposoby, że wzorce są beee... Dopiero gdy się
> okazało, że taktyka namawiania ludzi do "porzucenia starego sposobu myślenia"
> przestaje skutkować, zwłaszcza jak się pojawiła konkurencja - postanowiono
> skorzystać.
dokładnie tylko i wyłacznie konkurencja - dla tego samego powodu w javie 
są annotacje. nie ma tego w C++ i chyba nie płaczesz.
Nie będe Cie przekonywać, że są niezbędne. (bo nie są)

>>Z drugiej strony, mimo że osobiście bardzo lubię generyki,  to. 
>>zastanawiam się czy w dużych projektach ograniczenie sie do używania 
>>tylko generycznych kolekcji nie byłoby dobrym rozwiązaniem.
> 
> 
> Tak, najlepiej to w ogóle ograniczcie ilość używanych klas do biblioteki
> standardowej i tak po jednej klasie na pakiet. Oczywiście że trzeba wprowadzić
> takie ograniczenia, żeby sobie programiści Javy rączek nie poparzyli.

męczy już mnie twoja buta.
> Nie wiem, jak to się dzieje, że jakoś ANI RAZU (!) nie zdarzyło mi się widzieć
> w C++ jakiegoś "bardzo nieładnego" kodu, który by wykorzystywał wzorce albo
> przeciążanie operatorów. Dokładnie było odwrotnie: kody używające tych
> właściwości były napisane wręcz z wzorcową starannością. Natomiast najgorzej
> i najniechlujniej napisany kod to był kod pisany "w stylu języka C".
> 
> Jestem przekonany, że nie jestem jedynym, ani wyjątkiem, ani ewenementem pod
> tym względem. Tylko jakoś nie słyszę, żeby ktoś wyciągnął z tego jeden
> najbardziej oczywisty w tej sytuacji wniosek: nie należy się obawiać
> programistów używających wzorców i przeciążania operatorów. Należy się,
> however, jak ognia bać programistów, którzy więcej pisali w C, niż w C++.

No to własnie przeżywam to samo, tylko poziom wyżej.
Ja się obawiam zarówno programistów C i takich co przenoszą 
doświadczenia z C++ do javy.

-- 
http://www.99-bottles-of-beer.net/language-java-866.html

Sektor van Skijlen napisał:

> 
> Na razie to dywagowaliśmy, jakiej jakości jest "ficzer" generyków dodatny w
> Javie i czy coś to dobrego językowi przyniosło. W tym celu należy porównać
> pisanie z generykami i pisanie tego samego bez nich.

Nie - w tej częsci dyskutowaliśmy o constraintach na parametry w generykach.


>>Tak naprawdę potykałem się najwięcej jak miałem własną firmę krzak dawno 
>>temu. W zasadzie dotyczyło to prób korzystania z różnych ściąganych z 
>>googla bibliotek, algorytmów, źródeł, których chciałem używać... 
>>odkryłem że w C++ to się nie da (z wymienionego powodu) (a javy wtedy 
>>nie znałem za bardzo).
> 
> 
> Nie rozumiem. Znaczy się co, miałeś problem z korzystaniem z tego z uwagi na
> szurnięte użycie przeciążania operatorów?

No jasne. Z uwagi na użycie przeciążania operatórów - w kodzie 
sprowadzanym z zewnątrz, własnym i do tego jeszcze w STL.
Napisz, że zawsze używasz  operatorów w tym samym (semantycznie) sensie.
Sorry już samo cout<<"text"; superuje, że choćby z << jest ... "kłopot".



> 
> Ależ niemożliwość przeciążąnia operatorów niczego ci nie załatwi.
> 
> W Javie można zrobić kupę różnych głupot również z wielu innych powodów. Pod
> tym względem Java może jest mniej harmful, niż C++, ale wcale to nie oznacza,
> że się pod tym względem bardziej nadaje do tworzenia oprogramowania.

Właśnied dokładnie... to JEST dla mnie wzgląd.
> Zresztą dla mnie argument jest z gruntu kuriozalny: chcemy mieć dobre
> oprogramowanie, to zatrudniajmy dobrych programistów i przede wszystkim
> PATRZMY IM NA RĘCE. Nie ma lepszego filtra na dobry kod niż dobry, zaufany
> kierownik; narzędzia do mierzenia złożoności (różne Mckejby i klocworki) kodu
> trochę pomagają, ale tylko trochę.

Rozumiem, że widzisz rozwiązanie - piszmy w C++ tylko patrzmy wszystkim 
na ręce. ( a kto patrzy kierownikowi ? ).
To ja już jednak wolę automatyzację, sporadyczne sprawdzanie itp.
Taniej wychodzi - a w Javie starcza zupełnie. Mogę sobie swobodnie 
wrzucić jakiś absurdalny kod (np. wyprodukowanyw Elbonii fragment 
dotyczący gui)  do projektu i mam pewność, że co najwyżej sam un kod się 
wykrzaczy a reszta programu nie ucierpi ani troche (nikt mi pamięci nie 
pomaże, a jak będzie trzeba to się nawet temu fragmentowi odetnie IO i 
reszte :-) ) .


>>Zawodny.... zgadzam się.
>>Mniej wydajny? w jakim sensie?
> 
> 
> Nie rozśmieszaj mnie nawet. Tłukę ten temat już od dłuższego czasu.

Nie tłucz - napisz konkrety.

> 
> No przecież mówiłeś akurat o problemach, które w C++ by nie zaistniały z
> przyczyn zasadniczych. Więc nie rozumiem, o co ci chodzi z tym
> zacietrzewieniem.

Jak to by nie zaistaniały ? a co to C++ to jakiś inny, bezpieczny język 
jest ?

> 
>>He, he - dokładnie mam to samo tylko u mnie problemy są z ludźmi 
>>wyślizganymi w C (tworzą absurdalny kod) i  C++ (tworzą ciekawe i 
>>sprytne koncepcje... które w javie nie działają, nie mają sensu, albo są 
>>dramatycznie niewydajne).
> 
> 
> No właśnie to mnie interesuje. Jak może programista C++ źle pisać w Javie?
> Przykłady poproszę.

Najczęstszy przykład to jak wygląda walka o tzw. wydajność.

Typowy programista (długoletni w C++) widzi świat bardzo statycznie.
Zapominając, że we pomimo, że fragment kodu wygląda:
	(MyObject)list.get(4);
to  w kodzie faktycznie uruchamianym może nie być:
	- wywołania funkcji (inlining automatyczny),
	- sprawdzania zakresu tablicy, (wewnątrz get ),
	- sprawdzania zgodności typów (bo poco - sztuka jest sztuka).

Kompilator HotSpot wie o lokalnym kontekśćie programu o wiele więcej niż 
statyczny kompilator C++ i z tego powodu pewne trywialne operacje... 
mogą po prostu być wymazywane.
Niewiedza o tym prowadzi do konstruowania potworków z omijaniem 
rzutowania itp.
Najgorzej wygląda sprawdzanie wydajności - typowy programista C++ ma 
świadomość, że po skompilowaniu programu już się nie da z niego nic 
wycisnąc... a tu prosze  te opcje, które dotycza wydajności i który taki 
zrozpoczony gość szuka przy opiesie javac są dostępne w komendzie java.
Co gorsza tworzy sie benchmarki, które mierzą (niepotrzebnie) czas 
uruchamiania, kompilacji i potem wyciąga się durne wnioski

Po prawdzie to pamietam, że przechodząc z C++ ileś razy wrypałem sie w 
jakieś bardzo zabawne  pułapki - ale nie przypomnę sobie teraz.
> 
> 
>>I jeśli zostawi się jakąś furtkę to zawsze znajdzie sie ktoś kto w nią 
>>wlizie (bez pozwolenia).
> 
> 
> Zdarzały się takie próby. Jak oglądał to jakiś kierownik w Stanach, to
> faktycznie niektórzy włazili. U nas jednak się to jeszcze nie zdarzyło. U nas
> kierownicy są tak skuteczni, że żadnemu takiemu sabotażyście nie przepuszczą.
> 
> U nas na WSZYSTKO trzeba mieć pozwolenie. Od kierownika. Każdy kawałek kodu,
> który powstaje, albo jest zmieniany, musi przejść przez jego oczy.

No to wam bardzo wspólczuje. Może jednak kierownik każe wam przejś na 
jave jeśli zależy mu na zdrowiu swoich oczu.

>>W takim projekcie jedyną rozsądną formą 
>>sprawdzania jest ... automatyzacja - (kontrola stylu, cyclomatic 
>>complexity,
> 
> 
> Taaa... najnormalniej w świecie oszukujecie się. Faktem jest, że to jest też
> dobre, bo powstrzyma zapędy różnych cwaniaczków od robienia syfu, ale to nie
> jest lekarstwo na wszystkie problemy.
> 
> 
>>unit testy etc.).
> 
> 
> Nie wiem, co takiego jest niezwykłego w UT, przecież to normalny etap pracy
> nad oprogramowaniem.
A pisze, że niezwykłe coś jest?
> 
>>Wybór bardziej koszernego języka jest jedną z form tej automatyzacji.
> 
> 
> Co za szurnięty argument...

Całkiem oczooszczędny :-)
> Jeśli potrzeba nam faktycznie jakiegoś sprawdzania, czy użytkownik nie użył
> czasem takiej-a-takiej zakazanej konstrukcji, to można albo zrobić narzędzie,
> które samo to sprawdzi, albo to tak czy siak wyjdzie na inspekcji.
> 
> To samo dotyczy C++ jak i Javy.

Czy piszesz o tej swojej klasie Value - widzisz w C++ zrobienie czegoś 
zabezpieczającego choćby skutecznego w 95% jest cholernie trudne.

>>W zasadzie myślę, ze nie patrzysz na 
>>problem z tego punktu widzenia co ja. Dla mnie różnice miedzy C++ 
>>(dobrze opakowanym w boost, stl, gc,  itp) a Javą (z puntku widzenia 
>>samego języka) są małe. Jest to ten sam, hakerski, imperatywny, bez 
>>polotu język (tylko przynoszący zysk).
>>Idąc dalej w projektach, gdzie mogę to narzucić nie używam javy ... 
>>tylko jej mocno ograniczonego podzbioru (narzuconego kontrolą stylu, 
>>miarami  itp).
> 
> 
> To ja nie rozumiem, z jakiego punktu widzenia ty patrzysz na problem.
> Mogę to określić w ten sposób:
> 
> Masz zespół kilku programistów, którzy nad kodem nie mają żadnej kontroli (w
> każdej chwili ten kod może wziąć kto inny i namieszać).
To się nazywa kupić. My niestety nie mamy prawa własności do kodu.

> Nikt nie ma kontroli nad tym, jak oni ten kod piszą.
Może musisz podrzucić swojego kierownika ?

> Nikt tego kodu po nich nie ogląda.
Czyżby mieli inne zajęcia po godzinach ?

> Każdy sobie pisze jak mu się podoba i nikt nie sprawdza, co każdy gość
> naskrobał.

Dzięki, ogólnie, ciesze się że tak doskonale znasz moją firmę - jak ktoś 
z moich współpracowników to przeczyta - to się pięknie załamie :-).
Zwłaszcza, że mnóstwo z nich przyszło do nas uciekajac przed niezłym 
syfem w polskich i zagranicznych firemkach.

> Może to, że ja z takim sposobem tworzenia oprogramowania nie miałem do
> czynienia nigdy od czasu rozpoczęcia pracy w mojej bieżącej firmie, powoduje
> właśnie tą różnicę w punktach widzenia.


> Nie obawiaj się o moją świadomość podczas pisania. To akurat mówi każdy, kto
> przeprowadził rzeczową analizę o tym, jakie zmiany w języku wprowadza
> obowiązkowy odśmiecacz i jakie są jego zalety i wady.

No, zacytuje "pusty śmiech" mnie ogarnia. Lepiej zrób analize jakie 
zmiany wprowadza opcjonalny odśmiecacz - albo 4 używane na raz w jednym 
programie w C++.

>>Spędziłem kiedyś parę tygodni poszukując wycieku pamięci w średnim 
>>projekcie w C++ bez odśmiecacza... i znalazłem, że gdzieś było użyte 
>>delete ... zamiast delete[].
> 
> 
> A mogę zapytać, w jaki sposób to znalazłeś? Czy może poprzez debugowanie kodu?
debugowanie w takim przypadku nie pomaga.
zrobiłem coś w stylu zliczania instancji i kontroli pamięci (na wszytkie 
moje typy  -to mogłem łatwo)--  nie pomogło.
sprawa dotyczyła exportowania gdzieś głupiej tablicy 2 doubli.
(nie pamiętam jak znalazłem to w końcu - czy z jakimś narzędziem czy 
przez przypadek  - pamietam, że długo wiedziałem w których kilku 
linijkach jest problem ... ale nie czaiłem co jest nie tak.
w końcu jak się korzysta z stl to się o takich rzeczach jak delete[] 
zapomina dość szybko :-) )

> Jeśli tak, to rzeczywiście, nie dziwię się, dlaczego musisz używać
> "ograniczonych języków".

>>To mi wystarczyło. Nadal pisałem w C++, ale dostawiłem sobie odsmieczacz,
> 
> 
> Typowe podejście w stylu łatania bezpiecznika drutem.
> 
> Odśmiecacz _NIE_ załatwi ci problemu wycieków pamięci. Pozwoli ci tylko co
> najwyżej mieć tą pamięć pod kontrolą, co najczęściej oznacza, że jesteś w
> stanie powstrzymać co najwyżej tzw. progresywne wycieki pamięci. Mające
> znaczenie tylko gdy są faktycznie częste, a aplikacja ma chodzić długo bez
> restartu.
> 
> Jeśli masz jakieś przekonujące argumenty, że jednak odśmiecacz ma zalety, to
> zapoznaj się najpierw z tym poniżej:
> 
> http://warp.povusers.org/grrr/java.html
znowu mnie uczysz javy ? i to puszczając stronke jakiegoś frustrata?
Memory leaks w programach w javie to dla mnie chleb powszedni 
(sprawdzanie głównie czy aby nie ma)- tyle, ze mam dość fajne narzędzia 
do analizy sterty  - które powodują,  że błyskawicznie znajduje się 
winnych (jeśli sa - w javie trzeba się troche postarać).
  Fajne narzędzia to znaczy - umożliwiają np. monitorowanie sterty na 
systemie produkcyjnym i to co do ostatniego bajta - nieważne z jakiej 
biblioteki pochodzi.

(BTW> w javie pod tym wzgledem, przeszkadza przyzwyczajenie z C++, w C++ 
jak się da delete na obieklcie który jest w użyciu to sie program 
wywali, i programista C++ jest przyzwyczajony do problemu dokładnie 
odwrotnego - szukania nadmiarowych delete, a nie jak w javie 
nadmiarowych użyć)

>>>Zapominasz znów, że to są problemy Java-specific. W przypadku C++ jeśli kod
>>>"metowy" jest zły, to się po prostu nie skompiluje. Jak się skompiluje, to
>>>najczęściej oznacza, że jest dobry. Natomiast stosowanie metod dynamicznych,
>>
>>Nie jest tak jak piszesz - skompiluje sie i wylezie problem dopiero np. 
>>na testach - podawałem już dlaczego.
> 
> 
> Pokaż mi jak i dlaczego - niczego nie napisałeś jak do tej pory o tym,
> dlaczego tego typu problemy są w C++ przy wzorcach. O ewentualnych przykładach
> nie wspominając.
Sam łatwo napiszesz przykład złośliwy.... tylko po co?
Nie wyciągne teraz odpowiednika z rzeczywistości, ale akurat taki 
problem się może pojawić - koniec.

>>>co jest bardzo powszeche w Javie, oznacza w praktyce konieczność robienia
>>>bardzo rozbudowanych testów jednostkowych zapewniających poprawność. Często
>>>też konieczność debugowania tego, czy te instrukcje w runtime poskładały się
>>>do kupy tak, jak powinny.
>>
>>Dokładnie tak jest w jednym i w drugim języku. Zaczynam poważnie 
>>podejrzewać, że nie masz wielkiej styczności z C++ :-)
> 
> 
> Dokładnie tak jest w jednym i w drugim języku, ale o ile w C++ jest występuje
> to tylko w tych miejscach, w których rzeczywiście dynamizmu używamy, o tyle w
> Javie występują one po prostu WSZĘDZIE, bo WSZĘDZIE używa się dynamizmu.

Ciekawostka.

> Skoro ty nie wiesz takich prostych rzeczy, to pewnie dlatego, że od początku
> traktowałeś C++ jak Javę bez odśmiecacza. Co też odpowiednio świadczy o twojej
> znajomości C++.

Nie mogłem tak traktować, C++ znałem na wylot na długo (lata) zanim 
pierwszy fragment programu w javie zobaczyłem na oczy.

>>>Sam miałbym problemy z ich zaimplementowaniem, mając na uwadze dowolny poziom
>>>zagnieżdżania kontekstów wewnątrz jednej funkcji.
> 
> 
>>Stary, jak to ? przecież w makrach da się wszystko zrobić :-)
> 
> 
> Nie wstawienie odpowiednich kawałków kodu w arbitralnych miejscach.
A nie mozna pokryć makrem { i  } ?(nie wiem to pytanie - nie chce mi sie 
sprawdzać )

>>w C też.
> 
> 
> No jasne, pożartujmy sobie jeszcze.

>>>
>>>W każdym. Zużycie pamięci i mocy procesora.
>>
>>Pomyliłeś się w jednym i drugim.
>>Bo to nie jest takie proste jak Ci się wydaje.
> 
> 
> Oczywiście, że jest proste.
> 
> Jeśli mam choćbyu ten cały stos intów, to overhead na każdy obiekt klasy
> opakowującej doskonale obniża wydajność, jeśli porównać to z używaniem
> "gołych" intów. I to wydajność pod "każdym" względem.
> 
> 
>>Głównym powodem takiej a nie innej implementacji java generics są ... 
>>urządzenia mobilne.
> 
> 
> Taaa.. bardzo jestem ciekawy, skąd ty masz takie informacje.

Widzisz, ja ten projekt oglądałem jak się rozwijał.

>>Chcieli chłopaki objętość programów ograniczyć... bo 
>>stwierdzili, że to może być większy problem niż rozmiar danych.
> 
> 
> Zaraz się chyba rozpłaczę do rozpuku. W sytuacji gdy różnica w objętości
> pomiędzy kodem a danymi liczy się w rzędach wielkości, goście martwią się, że
> im się kod niebezpiecznie rozrasta.

>>(wcale nie mam pewności co do tej tezy  -ale nie ja ją wymyśliłem a nie 
>>jestem specem od oprogramowania małych urządzonych, żeby sie wypowiadać).
> 
> 
> To może powiedz mi, kto ją w takim razie wymyślił.

JSR-14 - to oni.

>>(Fakt, że na normalne komputery do zastosowań nawet desktopowych 
>>objętość kodu programu ma marginalne znaczenie)
> 
> 
> Objętość kodu programu ma marginalne znaczenie w ogóle. Zwłaszcza
> wystarczająco dobrze o tym świadczy popularność optymalizacji przez rozwijanie
> pętli i wywołań.
Czyżby w takim razie wydajność nie miała znaczenia (pisze o rozwijaniu 
pętli) :-) ?

> Z tego, co ja wiem, to generyki są jakie są tylko i wyłącznie dlatego, że jest
> to jedyna metoda, żeby wpasowały się w aktualne reguły wirtualnej maszyny
> (przynajmniej tak twierdził Anders Hejlsberg).

Argument równie sensowny jak ten, że const referencje nie bedą działać 
na AMDkach. JVM to prawie chamski assembler - naprawde ma w ... d - co 
też jest przez kompilator javac tworzone ( i ile jest tego kodu).

Jest jeden ważny ficzer obecnej implementacji - zgodność starego 
skompilowanego kodu z nowym (przy generykach) - ale to nie jest ficzer 
przesądzający. W końcu mogli np. kazać stare biblioteki przekompilować.


>>Co do zużycia procesora - to jest zagadnienie już inne - ale patrząc na 
>>to, że finalnemu kodowi w asemblerze zupełnie zwisa jaki co ma typ to 
>>ten argument jest taki sobie.
> 
> 
> Ale nie zwisa mu to, ile razy dereferuje wskaźnik i ile szurniętych operacji
> musi wykonać, żeby przeprowadzić operację na takich wartościach.
Bzdura - juzo tym pisałem. Po co ma to robić? To nie C++ tu runtime wie 
z czym pracuje.

> 
>>Argument dobry i prawdziwy ale jednak dość specyficzny... lepiej było 
>>stos stu  milionów booleanów podać. (to dopiero byłby dramat).
> 
> 
> Ty chyba jesteś chory. Ale dobra, niech dzisiaj znów będzie dzień dziecka:
> 
> Możliwe, że przykład nt. 100 milionów intów jest mało praktyczny. Ale nie ma
> żadnej różnicy pomiędzy tym, czy mamy jeden zbiornik po 100 milionów, czy dwa
> po 50. Tak? Skoro tak, to znaczy że nie ma również różnicy pomiędzy
> posiadaniem jednego zbiornika, który ma 20 milionów intów, i drugiego, który
> posiada 20 milionów liczb zespolonych?
> 
> I tak rozdrabniając to coraz bardziej, dochodzimy do bardziej praktycznych
> przykładów, a stosunek zajętości pamięci programu w Javie i programu w C++,
> gdzie używa się typów wartościowych, pozostaje prawie taki sam. Może i różnica
> trzykrotnej objętości jest przesadzona, ale weź też pod uwagę, że ta zajętość
> pamięci w przypadku Javy jest i tak wzięta z przesadnym optymizmem. Dlatego w
> najlepszym razie program w Javie może zająć jedynie dwa razy więcej pamięci,
> niż program w C++.
> 
> Jeśli zaś program w C++ zajmuje ci w czasie działania 500 MB pamięci, to
> wykonujący to samo program w Javie...
> 
> No dobra. Koniec dnia dziecka na dzisiaj.
No dobra - tak czy siak zostało mi jeszcze 2 gb wolnego :-)

>>(pomyśl o std::vector<bool> kiedyś ktoś walnął tym samym argumentem co 
>>ty porównując C z C++ :-) ).
> 
> 
> No nie rozumiem o co ci chodzi. Przecież w vector<bool> każdy element zajmuje
> jeden bit. Więc vector<bool> zajmie ci zawsze tyle, co ilość bitów wyrównana
> do pełnych ośmiu plus stały overhead (12 bajtów).
> Nie zawsze też interesuje nas dynamiczny wektor bitowy; czasem pewnie też
> sensownie jest użyć statycznego zbiornika z bitami, czyli bitset.
>>Co za problem zdobyć na tak specyficzny przypadek odpowiednio 
>>przygotowaną implementację.
> 
> 
> Tak, a potem na jeszcze specyficzną i jeszcze specyficzną...
> 
> I pamiętaj tylko potem, że musisz użyć VectorBoolean a nie Vector<boolean>.
Na sto milionów booleanów - będę pamiętał raczej. Jak mi poleci 
OutOfMemory - tym bardziej :-)

>>Fakt jest taki, że java generics ma słabą stronę pod tytułem tablice.
>>(nie wiem czy to będzie zmienione, poprawione w przyszłości- są różne 
>>koncepcje. )
> 
> 
> Ciekawi mnie, dlaczego tak jest, swoją drogą (nb. trzeba przyznać panu AL:
> rzeczywiście "eleganckie rozszerzenie języka").

Zaglądnij na forum java generics na java sun - tam sie to tłucze 3 razy 
dziennie.

-- 
http://www.99-bottles-of-beer.net/language-java-866.html

Dnia Sat, 22 Oct 2005 16:39:18 +0200, jarekr skrobie:
> >>(w dowolnym assemblerze wskaźnik do funkcji ustawić 
> >>można w jednej linijce i nawet sie typem nie trzeba przejmować !).
> > 
> > 
> > Ale nie rozumiem, co to ma do tematu ;)
> Do jest do tego co dopiero przed chwilą napisałeś (musiałem wyprzedzić 
> dyskusje). Przeczytaj swój paragraf.

Nie, nie rozumiem, co ma argument dotyczący asemblera do rzeczy. Asembler
traktujemy jak kod wynikowy, jaki by ten asembler nie był. Co mnie obchodzi
asembler?

> >>>>>- nie pozwala operowa? zmiennymi typów ?cis?ych (jedynie ich warto?ciami)
> >>>
> >>>
> >>>>Ze co?...
> >>>
> >>>
> >>>Przekaż mi pan zmienną do metody. Tak, żeby metoda mogła ją zapisać.
> >>>
> >>
> >>Panu A.L. chodziło, jak mniemam o sens twojego zdania - teraz lekko 
> >>doprecyzowałeś. (nadal dziwnie, ale już chyba wiem o co Ci chodzi (ale 
> >>nie wierzę ...bo to kuriozalny argument) )
> >>Lepiej pokaż konkretnie (kod).
> > 
> > 
> > Oj przestań, nawet mnie nie próbuj zanudzać stwierdzeniami, że w Javie się "po
> > prostu piszę inaczej", że powinienem zmienić mój sposób myślenia i stosować
> > inne techniki, bo się rozpłaczę do rozpuku. To samo słyszę nt. każdego
> > narzekania na właściwości Javy i to narzekania nie tylko takich gołodziobów
> > jak ja, którzy jedynie "stosują jak muszą", ale prawdziwych praktyków, którzy
> > na z niejednego pieca projektach zęby zjedli.

> Przestań pleść dyrdymały i napisz w końcu - kod - o co Ci chodzi?

Jaki kod mam ci pokazać, skoro mówię o rzeczy, której w Javie zrobić NIE
MOŻNA? A w innych językach - cóż, w różnych językach jest to możliwe na różne
sposoby (poza Javą, każdy znany mi język to umożliwia).

Jeśli nie rozumiesz o czym mówię, to nie krępuj się; wytnik po prostu ten
akapit i daj sobie spokój. Powiedziałem wyraźnie w jednym zdaniu najpierw,
potem doprecyzowałem w drugim akapicie - jest to właściwość, jakiej Java po
prostu nie posiada, w odróżnieniu od chyba wszystkich pozostałych
imperatywnych języków (mówię "chyba", bo przecież wszystkich nie znam).

> > Po pierwsze, to ja mimo wszystko wolę mieć dowolny kompilator do wyboru, niż
> > jedno centrum decyzyjne tworzące język i jego implementację.

> Bzdury pleciesz.
> W javie jest jedno centrum (SUN) zarządzające standardem. Dostarcza też 
> jedną implementację.
> Inne implementacje dostarcza IBM, BEA (JRockit). Korzystałem z tych 
> implementacji wielokrotnie - wiem, ze są bardzo dobrze zgodne z sunowską 
> javą.

Implementację CZEGO? Kompilatora, czy VM?

> Jest też (absurdalny)  gcj. (zgodny ale powolny )
> Te wszystkie implementacje muszą spełniać pewne standardy (albo dostają
> czerwoną kartkę jak MS Java).

Taa... o ile pamiętam, to MS dostał tą kartkę za wprowadzanie "nielegalnych
rozszerzeń" (a nie za braki w zgodności z istniejącą wersją języka). Nazywanie
tego strzeżeniem standardu jest co najmniej kpiną i hipokryzją.

MS się zresztą nie przejął specjalnie wyrokiem, tylko wypuszczał swoją Javę
dalej pod nazwą J++. A potem zrobili C#.

Sun zawłaszczył Javę po to, żeby się częściowo zabezpieczyć przed konkurencją,
przecież to jasne. Nawet kiedy Rational próbował zrobić implementację Javy na
.NET, to Sun wytoczył mu proces.

> Dzięki temu nie mam w kodzie ton makr, 
> które muszą naprawiać niekompatybilności i inne takie.

Po prostu, zwyczajny język katedralny. Nie, sory, mnie te makra w najmniejszym
stopniu nie przeszkadzają (a w szczególności wali mnie to, jak jest napisana
implementacja). Naprawdę, wolę już mieć język, który się naprawdę rozwija i
jego właściwości są poddawane publicznej dyskusji. Bo wtedy taki język ma
szansę się rzeczywiście rozwijać. I już przeboleję to, że nie wszystkie
kompilatory są wystarczająco zgodne; nie potrzebuję, żeby AT&T wytaczała
proces np. Microsoftowi za niezgodność ze standardem. Wystarczy, jeśli po
prostu nie będę używał ich kompilatora, jeśli ta niezgodność mi przeszkadza.

Może powiedzmy to bardziej szczerze: nie ma tych ton makr, bo po prostu nie ma
w tym języku makr. Dywagowanie, dlaczego makra nie są używane do naprawienia
problemów kompatybilności jest co najmniej bezcelowe.

> > Po drugie, co mnie obchodzi implementacja? Do implementacji zaglądam jak
> > jestem ciekawy, jak to goście wykoncypowali. Użytkownika interesuje jedynie
> > interfejs.

> TO ty zasugerowałeś zebym zaglądał do boost::mpl. Pech chciał, że 
> zaglądnąłem.

To co, mam rozumieć, że jak ty mi podpowiesz, żebym sobie zobaczył jakąś
bibliotekę Javy, to powinienem zajrzeć do jej implementacji?

> > No, bardzo chętnie się dowiem, jakie to techniki w Javie są stosowane zamiast
> > RAII i zapewniają tą samą skuteczność zarządzania zasobami. I nie rozśmieszaj
> > mnie znów argumentem, że to rzadka potrzeba i nic nie szkodzi, że mało
> > wygodne.

> Znowu się rozwodzisz nad finally -  a ja napisałem jest inna prosta 
> technika.

> Po prostu zamiast takiego zapisu jak w C++:
> {
>         DBConnection db("bla");/*klasa DBConnection ma odpowiednio napsiany 
> destruktor i konstruktor*/

>         [kod koprzystający z db]
> }

> mam taki (java):
> {
>         dbManager.execute ( new DBMethod()  {
>                         public void run(final DBContext context)
>                         {
>                                 DBConnection db =                               context.createConnection("bla");
>                                 [kod koprzystający z db]
>                         }
>                 } );
> }

> po prostu o ile w C++ kluczowe zarządzanie zasobami mam w konstruktorze 
> i destruktorze to w Javie wywalam do odpowiedniego menadżera.

O jaciekrence...

A czegoś takiego, żeby można tego było użyć po ludzku?

Bo takiego czegoś to można również użyć w C# (tyle że wyszłoby znacznie
prościej i krócej).

I co, do każdego typu będziesz sobie tworzył takie opakowanie, żeby ci się
zrobiło ładne RAII? Zaleta C++ nie polega na tym, że można sobie samemu
zaplanować akcje w konstruktorze i destruktorze, tylko że zwykle w
istniejących już typach konstruktor i destruktor mają odpowiednio zaplanowane
działanie. Trzeba ich tylko po prostu użyć.

Wiesz, na dobrą sprawę, to preprocesora C też możesz używać w Javie. Co to za
problem.

> Dla programisty końcowego efekt jest podobny. Może sobie tworzyć ile 
> chce  - po wylezieniu z funkcji (klamry) - wszystko jest zamykane. (bo 
> metoda execute w menadżerze ma finally :-) .)

Ale dla programisty początkowego różnica jest diametralna.

A może użyjesz generyków, żeby móc to zastosować do różnych typów?

Wiemy przecież, że nie użyjesz, bo te generyki są zbyt jujowe, żeby się tak
dało.

> int main()
> {

>         Value v2;

>         v2.in = 3;
>         std::cout<<"\ntest a:"<<v2.in;

>         BadUnion bu(v2);
>                                 
>         Proof* cham = (Proof*)&bu;

>         std::cout<<"\ntest b:"<<(int)cham<<"\n";
>                 
>         //i tu mam void*
>         void* cham2 = (void*)&(*(cham->v));
>         std::cout<<"\ntest f:"<<(int)cham2<<"\n";

>         BadValue* cham3 = (BadValue*)(cham2);
>         std::cout<<"\ntest c:"<<cham3->in<<"\n";
>         cham3->in = 666; //tu jest zło :-)
>         std::cout<<"\ntest d:"<<v2.in<<"\n";    
> }

> gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)

Ta, jasne. I sądzisz, że będzie ci to działało na każdej platformie i każdej
wersji każdego kompilatora z każdym zestawem opcji? Oj ty młody i naiwny ;)

Użyłeś tutaj niegwarangowanej właściwości: że referencja będzie
zaimplementowana tak, jak wskaźnik, oraz, że możesz swobodnie dokonać
"rzutowania przez unię" referencji na wskaźnik. Nie ma takiej gwarancji
niestety w standardzie; kompilator mógł cię oszukać. Nawet na tym samym
kompilatorze w tej samej wersji może ci to działać lub nie w zależności od
opcji kompilacji.

Zatem to już jest pierwszy minus.

Drugi minus: Popatrz, ile musiałeś się namęczyć i natworzyć własnych typów
danych i narzutować po kilka razy, żeby uzyskać void* będący i tak jedynie
hipotetycznym adresem tego obiektu w pamięci (jak wspomniałem, jest to
nie gwarantowane przez standard, podobnie np. jak to że dla dwóch kolejno
zadeklarowanych zmiennych lokalnych x i y tego samego typu nie musi być
prawdą, że &x+1 == &y).

Przykro mi, niezaliczone. Zgłosi się pan za tydzień.

> (nie przykładałem sie do nazw i kodu - tak z palca strzeliłem za drobną 
> poprawką - przyznam, sie ze pierwszy pomysł nie działał (referencje nie 
> mogą być częścią uni ) )

Ten pomysł też tak naprawdę nie działa.

Rzutowanie dowolnego wskaźnika na void* działa i będzie działać. Można go też
zrzutować spowrotem i też będzie działać. To standard gwarantuje.

To, co ty wyczyniłeś, nie gwarantuje, bo nigdzie nie jest napisane, że pola
typów referencyjnych mają taką samą reprezentację, jak wskaźniki do tych
typów.

> dokładnie tylko i wyłacznie konkurencja - dla tego samego powodu w javie 
> są annotacje. nie ma tego w C++ i chyba nie płaczesz.
> Nie będe Cie przekonywać, że są niezbędne. (bo nie są)

Oczywiście, że nie płaczę, podobnie jak w C++ mam RTTI i też mi to jak dziura
w zębie potrzebne.

A co do annotacji - cóż, najwyraźniej faktycznie zadziałała konkurencja, nawet
wiadomo dokładnie która i na czym te annotacje wzorowano.

> No to własnie przeżywam to samo, tylko poziom wyżej.

Rzekłbym, niżej. Albo po lewo.

> Ja się obawiam zarówno programistów C i takich co przenoszą 
> doświadczenia z C++ do javy.

Cóż, faktem jest, że doświadczenia w tych językach się nie krzyżują. Ale, jak
wspomniałem, bardzo chętnie się dowiem, jakież to techniki bazowane na C++ są
niefortunnie stosowane w Javie. Jakieś przykłady, chętnie ze źródłami.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sektor van Skijlen napisał(a):
> Dnia Sat, 22 Oct 2005 16:39:18 +0200, jarekr skrobie:
> 
>>>>(w dowolnym assemblerze wskaźnik do funkcji ustawić 
>>>>można w jednej linijce i nawet sie typem nie trzeba przejmować !).
>>>
>>>
>>>Ale nie rozumiem, co to ma do tematu ;)
>>
>>Do jest do tego co dopiero przed chwilą napisałeś (musiałem wyprzedzić 
>>dyskusje). Przeczytaj swój paragraf.
> 
> 
> Nie, nie rozumiem, co ma argument dotyczący asemblera do rzeczy. Asembler
> traktujemy jak kod wynikowy, jaki by ten asembler nie był. Co mnie obchodzi
> asembler?

To jest ogólny argument na to ile linijek sie trzeba napisać w jakim
języku. Zajrzyj na 99 bottles, żeby zobaczyć do czego to prowadzi.


> 
> 
>>Przestań pleść dyrdymały i napisz w końcu - kod - o co Ci chodzi?
> 
> 
> Jaki kod mam ci pokazać, skoro mówię o rzeczy, której w Javie zrobić NIE
> MOŻNA? A w innych językach - cóż, w różnych językach jest to możliwe na różne
> sposoby (poza Javą, każdy znany mi język to umożliwia).
> 
> Jeśli nie rozumiesz o czym mówię, to nie krępuj się; wytnik po prostu ten
> akapit i daj sobie spokój. Powiedziałem wyraźnie w jednym zdaniu najpierw,
> potem doprecyzowałem w drugim akapicie - jest to właściwość, jakiej Java po
> prostu nie posiada, w odróżnieniu od chyba wszystkich pozostałych
> imperatywnych języków (mówię "chyba", bo przecież wszystkich nie znam).


Nie... weż wreszcie w C++ mi pokaż odpowiednik tego czego nie można w javie.

>>>Po pierwsze, to ja mimo wszystko wolę mieć dowolny kompilator do wyboru, niż
>>>jedno centrum decyzyjne tworzące język i jego implementację.
> 
> 
>>Bzdury pleciesz.
>>W javie jest jedno centrum (SUN) zarządzające standardem. Dostarcza też 
>>jedną implementację.
>>Inne implementacje dostarcza IBM, BEA (JRockit). Korzystałem z tych 
>>implementacji wielokrotnie - wiem, ze są bardzo dobrze zgodne z sunowską 
>>javą.
> 
> 
> Implementację CZEGO? Kompilatora, czy VM?

Dokładnie jednego i drugiego. Można sobie co więcej zamiennie stosować
np. kompilator z IBM do javy sunowskiej - jak chcesz - wymagania są
DOKŁADNIE napisane.

>>Jest też (absurdalny)  gcj. (zgodny ale powolny )
>>Te wszystkie implementacje muszą spełniać pewne standardy (albo dostają
>>czerwoną kartkę jak MS Java).
> 
> 
> Taa... o ile pamiętam, to MS dostał tą kartkę za wprowadzanie "nielegalnych
> rozszerzeń" (a nie za braki w zgodności z istniejącą wersją języka). Nazywanie
> tego strzeżeniem standardu jest co najmniej kpiną i hipokryzją.
> 
> MS się zresztą nie przejął specjalnie wyrokiem, tylko wypuszczał swoją Javę
> dalej pod nazwą J++. A potem zrobili C#.
> 
> Sun zawłaszczył Javę po to, żeby się częściowo zabezpieczyć przed konkurencją,
> przecież to jasne. Nawet kiedy Rational próbował zrobić implementację Javy na
> .NET, to Sun wytoczył mu proces.


TO czemu GNU, IBMowi i BEI nie zabronił - nie kumam. A moze jednak
java na .NET to może nie być do końca Java ?  (Ja to nazwałbym  nauczyli 
sie na przykładzie ms javy )

>>Dzięki temu nie mam w kodzie ton makr, 
>>które muszą naprawiać niekompatybilności i inne takie.
> 
> 
> Po prostu, zwyczajny język katedralny. Nie, sory, mnie te makra w najmniejszym
Idź sie naprawde umyj. TO jest naprawde ciekawe, że w tej chwili jeden z
   najczęsciej przemysłowo stosowanych jezyków jest katedralny :-)


> Może powiedzmy to bardziej szczerze: nie ma tych ton makr, bo po prostu nie ma
> w tym języku makr. Dywagowanie, dlaczego makra nie są używane do naprawienia
> problemów kompatybilności jest co najmniej bezcelowe.

A jednak - posiadanie języka w którym nie trzeba łatać i można sobie
podmieniać dostawce kompilatora (bo np. BEA JRockit czasem jest istotnie
szybsza od sunowskiej) ma pewne plusy.


> 
>>TO ty zasugerowałeś zebym zaglądał do boost::mpl. Pech chciał, że 
>>zaglądnąłem.
> 
> 
> To co, mam rozumieć, że jak ty mi podpowiesz, żebym sobie zobaczył jakąś
> bibliotekę Javy, to powinienem zajrzeć do jej implementacji?

Cała dyskusja była  na temat jakie to piękne rzeczy można templatami
stworzyć w C++ co miało być widać w boost::mpl. Ale boost::mpl jest 
daleki od piękna - i taka jest niestety codzienność C++.

>>>No, bardzo chętnie się dowiem, jakie to techniki w Javie są stosowane zamiast
>>>RAII i zapewniają tą samą skuteczność zarządzania zasobami. I nie rozśmieszaj
>>>mnie znów argumentem, że to rzadka potrzeba i nic nie szkodzi, że mało
>>>wygodne.
> 
> 
>>Znowu się rozwodzisz nad finally -  a ja napisałem jest inna prosta 
>>technika.
> 
> 
>>Po prostu zamiast takiego zapisu jak w C++:
>>{
>>        DBConnection db("bla");/*klasa DBConnection ma odpowiednio napsiany 
>>destruktor i konstruktor*/
> 
> 
>>        [kod koprzystający z db]
>>}
> 
> 
>>mam taki (java):
>>{
>>        dbManager.execute ( new DBMethod()  {
>>                        public void run(final DBContext context)
>>                        {
>>                                DBConnection db =                               context.createConnection("bla");
>>                                [kod koprzystający z db]
>>                        }
>>                } );
>>}
> 
> 
>>po prostu o ile w C++ kluczowe zarządzanie zasobami mam w konstruktorze 
>>i destruktorze to w Javie wywalam do odpowiedniego menadżera.
> 
> 
> O jaciekrence...
> 
> A czegoś takiego, żeby można tego było użyć po ludzku?

To jest po ludzku - ja tego używam, w kodach różnych OR mapperów to
znajdziesz itp.

> Bo takiego czegoś to można również użyć w C# (tyle że wyszłoby znacznie
> prościej i krócej).

Super. Ja też sie ciesze, że C# daje rade.

> I co, do każdego typu będziesz sobie tworzył takie opakowanie, żeby ci się
> zrobiło ładne RAII? Zaleta C++ nie polega na tym, że można sobie samemu
> zaplanować akcje w konstruktorze i destruktorze, tylko że zwykle w
> istniejących już typach konstruktor i destruktor mają odpowiednio zaplanowane
> działanie. Trzeba ich tylko po prostu użyć.
> 
> Wiesz, na dobrą sprawę, to preprocesora C też możesz używać w Javie. Co to za
> problem.

Wiem, ale nie używam preprocesora C.

>>Dla programisty końcowego efekt jest podobny. Może sobie tworzyć ile 
>>chce  - po wylezieniu z funkcji (klamry) - wszystko jest zamykane. (bo 
>>metoda execute w menadżerze ma finally :-) .)
> 
> 
> Ale dla programisty początkowego różnica jest diametralna.
> 
> A może użyjesz generyków, żeby móc to zastosować do różnych typów?
> 
> Wiemy przecież, że nie użyjesz, bo te generyki są zbyt jujowe, żeby się tak
> dało.

Szczerze mówiąc - używam w tym celu :-)


> 
>>gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
> 
> 
> Ta, jasne. I sądzisz, że będzie ci to działało na każdej platformie i każdej
> wersji każdego kompilatora z każdym zestawem opcji? Oj ty młody i naiwny ;)

A ty piszesz kod, który działa na każdej platformie, z każdym zestawem
opcji ? (to bedzie ciekawe - biorąc pod uwagę, ze każdy release
kompilatorów C++ uzupełnia kolejne braki (pamietam jak długo czekałem na
"export template")

> Użyłeś tutaj niegwarangowanej właściwości: że referencja będzie
> zaimplementowana tak, jak wskaźnik, oraz, że możesz swobodnie dokonać
> "rzutowania przez unię" referencji na wskaźnik. Nie ma takiej gwarancji
> niestety w standardzie; kompilator mógł cię oszukać. Nawet na tym samym
> kompilatorze w tej samej wersji może ci to działać lub nie w zależności od
> opcji kompilacji.
Swoją drogą zamierzałem użyc jeszcze bardziej niegwarantowanej własności
(unia).

> Zatem to już jest pierwszy minus.
> 
> Drugi minus: Popatrz, ile musiałeś się namęczyć i natworzyć własnych typów
> danych i narzutować po kilka razy, żeby uzyskać void* będący i tak jedynie
> hipotetycznym adresem tego obiektu w pamięci (jak wspomniałem, jest to
> nie gwarantowane przez standard, podobnie np. jak to że dla dwóch kolejno
> zadeklarowanych zmiennych lokalnych x i y tego samego typu nie musi być
> prawdą, że &x+1 == &y).

Działa... nie jest to takie wielkie namęczenie. Zauważ, że kod napisałem
dość czytelnie. Można to pewnie było w 2 linijki walnąć.

> Przykro mi, niezaliczone. Zgłosi się pan za tydzień.
taa minusy wsadź sobie w...
ja uważam, że wisisz mi połówkę.
działa - możesz sprawdzić.
Poza tym:
1. właśnie widzisz co oznacza brak standardu i dlaczego tyle jest makr w
bibliotekach standardowych - wychodzi na to, że całkiem nie taki
hakerski kod w C++ może zupełnie różnie działać... pięknie.

2. naprawdę myślisz że znajdziesz kompilator w którym sobie nie poradze
? (czy może szybko taki machniesz)


>>(nie przykładałem sie do nazw i kodu - tak z palca strzeliłem za drobną 
>>poprawką - przyznam, sie ze pierwszy pomysł nie działał (referencje nie 
>>mogą być częścią uni ) )
> 
> 
> Ten pomysł też tak naprawdę nie działa.
> 
> Rzutowanie dowolnego wskaźnika na void* działa i będzie działać. Można go też
> zrzutować spowrotem i też będzie działać. To standard gwarantuje.
> 
> To, co ty wyczyniłeś, nie gwarantuje, bo nigdzie nie jest napisane, że pola
> typów referencyjnych mają taką samą reprezentację, jak wskaźniki do tych
> typów.

Działa - działa. :-)
Mam to na ekranie - możesz sam sobie sprawdzić.
Powiem więcej - uznasz porażkę - albo ja uznam, ze nie warto z tobą
dyskutować bo masz pan błone półprzepuszczalną.


>>dokładnie tylko i wyłacznie konkurencja - dla tego samego powodu w javie 
>>są annotacje. nie ma tego w C++ i chyba nie płaczesz.
>>Nie będe Cie przekonywać, że są niezbędne. (bo nie są)
> 
> 
> Oczywiście, że nie płaczę, podobnie jak w C++ mam RTTI i też mi to jak dziura
> w zębie potrzebne.
> 
> A co do annotacji - cóż, najwyraźniej faktycznie zadziałała konkurencja, nawet
> wiadomo dokładnie która i na czym te annotacje wzorowano.
> 
> 
> 
> 
> Cóż, faktem jest, że doświadczenia w tych językach się nie krzyżują. Ale, jak
> wspomniałem, bardzo chętnie się dowiem, jakież to techniki bazowane na C++ są
> niefortunnie stosowane w Javie. Jakieś przykłady, chętnie ze źródłami.

(odpisałem w innym msg) ale tak dla dodatku ( troche mi sie przypomniało)
  number 1 - double checked locking... który, zeby było zabawniej w C++
też nie ma gwarancji działania :-)
number 2 - metody wirtualne w konstruktorze - nie ma chyba programisty
C++, który by po przejsciu na javę się na tym nie wyłożył
number 3 - jest dużo koncepcji typu
	object = null; } // 	ludzie wierzą, że to przypisanie działa jak delete
(chyba zapełniają pustkę po delect object; )   -ale to fakt
jest nie od ludzi mądrych - tyle, że nie mogłem pominąć - bo to jest
wręcz wyznacznik kodu pisanego przez konwertytę
number 4 - nieużywanie tablic - w javie są normalne i porządne tablice
	ale doświadczony programista C++ nawet na nie nie patrzy tylko
	używa ślepo wszędzie List<> itp. - to jest np. mój problem :-) 	
number 5 - brak zrozumienia  dla koncepcji
	niestatycznych klas wewnętrznych ogólnie	
	- te w javie dodają jednak troche lukru syntaktycznego  i 	
	rozwiązują mnóstwo pozornych braków Javy


-- 
http://www.99-bottles-of-beer.net/language-java-866.html

jarekr <jhratajski@popraw.literowki.pzcota.otne.pl> napisał(a): 
> > Cóż, faktem jest, że doświadczenia w tych językach się nie krzyżują. Ale, 
jak
> > wspomniałem, bardzo chętnie się dowiem, jakież to techniki bazowane na C++ 
są
> > niefortunnie stosowane w Javie. Jakieś przykłady, chętnie ze źródłami.
> 
> (odpisałem w innym msg) ale tak dla dodatku ( troche mi sie przypomniało)
>   number 1 - double checked locking... który, zeby było zabawniej w C++
> też nie ma gwarancji działania :-)
> number 2 - metody wirtualne w konstruktorze - nie ma chyba programisty
> C++, który by po przejsciu na javę się na tym nie wyłożył
> number 3 - jest dużo koncepcji typu
> 	object = null; } // 	ludzie wierzą, że to przypisanie działa jak 
delete
> (chyba zapełniają pustkę po delect object; )   -ale to fakt
> jest nie od ludzi mądrych - tyle, że nie mogłem pominąć - bo to jest
> wręcz wyznacznik kodu pisanego przez konwertytę
> number 4 - nieużywanie tablic - w javie są normalne i porządne tablice
> 	ale doświadczony programista C++ nawet na nie nie patrzy tylko
> 	używa ślepo wszędzie List<> itp. - to jest np. mój problem :-) 	
> number 5 - brak zrozumienia  dla koncepcji
> 	niestatycznych klas wewnętrznych ogólnie	
> 	- te w javie dodają jednak troche lukru syntaktycznego  i 	
> 	rozwiązują mnóstwo pozornych braków Javy

Moze dlatego ze programisci ktorzy przesiadali sie z C++ na Jave nie do konca 
byli dobrymi programistami?? Przesiadali sie ze wzgledu na to ze w C++ nie 
zagrzali miejsca ze wzgledu wlasnie na ich watla wiedze?? Ja uzywam C++, 
Pythona, Javy czetsosc w kolejnosci podania i jakos nie mam problemow i nie 
stosuje "technik" ktore podales. Siadajac do innego jezyka zdaje sobie sprawe 
z roznic pomiedzy nimi i nie probuje naciagc jednego aby upodobnic do 
drugiego.

Pozdro.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Dnia Sat, 22 Oct 2005 21:55:27 +0200, jarekr skrobie:
> > Sun zawłaszczył Javę po to, żeby się częściowo zabezpieczyć przed konkurencją,
> > przecież to jasne. Nawet kiedy Rational próbował zrobić implementację Javy na
> > .NET, to Sun wytoczył mu proces.

> TO czemu GNU, IBMowi i BEI nie zabronił - nie kumam.

Bo ustawili się karnie w szeregu i złożyli uroczystą przysięgę, z ręką na
Biblii, że nigdy, ale to nigdy nie dodadzą żadnego rozszerzenia.

> A moze jednak java na .NET to może nie być do końca Java ?  (Ja to nazwałbym
> nauczyli sie na przykładzie ms javy )

Nie wiem, możliwe. I tak zresztą chyba (jak pamiętam) powstało J#, do czego
pewnie Sun nie mógł się przyczepić, bo nie nazywało się Java.

> >>Dzięki temu nie mam w kodzie ton makr, 
> >>które muszą naprawiać niekompatybilności i inne takie.
> > 
> > 
> > Po prostu, zwyczajny język katedralny. Nie, sory, mnie te makra w najmniejszym
> Idź sie naprawde umyj. TO jest naprawde ciekawe, że w tej chwili jeden z
>    najczęsciej przemysłowo stosowanych jezyków jest katedralny :-)

A co ma przepraszam jedno do drugiego? Kiedyś wszystkie produkty softwarowe
były katedralne.

> >>mam taki (java):
> >>{
> >>        dbManager.execute ( new DBMethod()  {
> >>                        public void run(final DBContext context)
> >>                        {
> >>                                DBConnection db =                               context.createConnection("bla");
> >>                                [kod koprzystający z db]
> >>                        }
> >>                } );
> >>}
> > 
> > 
> >>po prostu o ile w C++ kluczowe zarządzanie zasobami mam w konstruktorze 
> >>i destruktorze to w Javie wywalam do odpowiedniego menadżera.
> > 
> > 
> > O jaciekrence...
> > 
> > A czegoś takiego, żeby można tego było użyć po ludzku?

> To jest po ludzku - ja tego używam, w kodach różnych OR mapperów to
> znajdziesz itp.

Kochany, TO jest po ludzku:

{
	ifstream f( "file" );
	...
	auto_ptr<X> x = CreateX( f );
	...
	if ( costam )
		return x.release();
}

> > Bo takiego czegoś to można również użyć w C# (tyle że wyszłoby znacznie
> > prościej i krócej).

> Super. Ja też sie ciesze, że C# daje rade.

C# daje radę bez żadnych szurniętych opakowań. A i z tymi opakowaniami wygląda
to znacznie prościej:

{
        dbManager.execute( delegate( const DBContext context ) {
                        DBConnection db = context.createConnection("...");
                        ...
        } );
}

> >>Dla programisty końcowego efekt jest podobny. Może sobie tworzyć ile 
> >>chce  - po wylezieniu z funkcji (klamry) - wszystko jest zamykane. (bo 
> >>metoda execute w menadżerze ma finally :-) .)
> > 
> > 
> > Ale dla programisty początkowego różnica jest diametralna.
> > 
> > A może użyjesz generyków, żeby móc to zastosować do różnych typów?
> > 
> > Wiemy przecież, że nie użyjesz, bo te generyki są zbyt jujowe, żeby się tak
> > dało.

> Szczerze mówiąc - używam w tym celu :-)

I do plików też masz odpowiednią implementację createConnection?

> >>gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
> > 
> > 
> > Ta, jasne. I sądzisz, że będzie ci to działało na każdej platformie i każdej
> > wersji każdego kompilatora z każdym zestawem opcji? Oj ty młody i naiwny ;)

> A ty piszesz kod, który działa na każdej platformie, z każdym zestawem
> opcji ? (to bedzie ciekawe - biorąc pod uwagę, ze każdy release
> kompilatorów C++ uzupełnia kolejne braki (pamietam jak długo czekałem na
> "export template")

Może cię to zaskoczy, ale tak. Tak właśnie dokładnie piszę. To nic, że każdy
release kompilatorów uzupełnia się o kolejne braki. Jak czegoś się nie da
zrobić, to po prostu nie używam, trudno.

Na export template ja wcale nie czekałem i czekać nie będę. Ten ficzer jest
cokolwiek szurnięty, a jego przydatność jest znikoma. Btw. skoro czekałeś, to
się pewnie doczekałeś; mogę wiedzieć w jakiej implementacji?

> > Użyłeś tutaj niegwarangowanej właściwości: że referencja będzie
> > zaimplementowana tak, jak wskaźnik, oraz, że możesz swobodnie dokonać
> > "rzutowania przez unię" referencji na wskaźnik. Nie ma takiej gwarancji
> > niestety w standardzie; kompilator mógł cię oszukać. Nawet na tym samym
> > kompilatorze w tej samej wersji może ci to działać lub nie w zależności od
> > opcji kompilacji.
> Swoją drogą zamierzałem użyc jeszcze bardziej niegwarantowanej własności
> (unia).

Bez różnicy. Unia jest formą rzutowania.

> > Zatem to już jest pierwszy minus.
> > 
> > Drugi minus: Popatrz, ile musiałeś się namęczyć i natworzyć własnych typów
> > danych i narzutować po kilka razy, żeby uzyskać void* będący i tak jedynie
> > hipotetycznym adresem tego obiektu w pamięci (jak wspomniałem, jest to
> > nie gwarantowane przez standard, podobnie np. jak to że dla dwóch kolejno
> > zadeklarowanych zmiennych lokalnych x i y tego samego typu nie musi być
> > prawdą, że &x+1 == &y).

> Działa...

I co z tego, że tobie akurat działa?

> nie jest to takie wielkie namęczenie.

No nie wiem - dwa dodatkowe typy danych i trzy zakręcone rzutowania. Opisałeś
się tego badziewia znacznie więcej, niż ja. Muszę przyznać, że jestem z siebie
dumny ;)

> Zauważ, że kod napisałem
> dość czytelnie.

Na tyle, na ile czytelnie w ogóle można coś takiego napisać.

> > Przykro mi, niezaliczone. Zgłosi się pan za tydzień.
> taa minusy wsadź sobie w...
> ja uważam, że wisisz mi połówkę.

O tym możemy jeszcze podyskutować.

> działa - możesz sprawdzić.

Kochany, możesz mi wierzyć albo nie, ale jakiś czas temu gościu podesłał na
pl.comp.lang.c kod, który jakoby miałby robić w języku C listy bez użycia
malloc(). Moment... to było chyba to:

#include <stdio.h>

struct point
{
    int x;
    struct point *nast;
};

int main ()
{
    int a;
    struct point *poprz, *biezacy, *start;
    start = biezacy;
    while (a != 0)
    {
        scanf("%d",&a);
        biezacy->x=a;
        poprz = biezacy;
        poprz->nast=++biezacy;
    }
    biezacy=start;
    while (biezacy->x != 0)
    {
        printf("%d\n",biezacy->x);
        biezacy=biezacy->nast;
    }

    return 0;
}

I był z tym wszystkim jeden drobny problem: na gcc 2.95 ten program NAPRAWDĘ
DZIAŁA i wcale się nie sypie, co można by wnioskować z kodu.

I co, cwaniaczku? Program działa to program jest poprawny?

> Poza tym:
> 1. właśnie widzisz co oznacza brak standardu

Jaki znów brak standardu, o czym ty do mnie rozmawiasz?

> i dlaczego tyle jest makr w bibliotekach standardowych

Wiesz chociaż, do czego one służą, ty młody i naiwny?

> 2. naprawdę myślisz że znajdziesz kompilator w którym sobie nie poradze
> ? (czy może szybko taki machniesz)

W zupełności wystarczy, żeby kompilator implementował pola typu referencyjnego
np. na dwóch bajtach jako delta od czegoś-tam. Albo nawet może być na czterech
bajtach. Albo może być to na 8 bajtach (gdzie wskaźnik ma 4), a pierwsze 4 nie
zawierają wcale wartości wskaźnika do obiektu. Na dobrą sprawę zresztą w ogóle
wystarczy, żeby w tych nawet tej samej ilości bajtów pamięci co sizeof
wskaźnika była zapisana wartość, która jak najbardziej jest odniesieniem do
obiektu, ale te cztery bajty razem wcale nie są wskaźnikiem do tego samego
obiektu. I leżysz.

Standard pozwala na takie rzeczy. Nie wiem, czy są kompilatory, które z tego
korzystają. Jest niewykluczone (nie analizowałem tego, więc nie wiem), że
kompilator może nawet w ramach optymalizacji takiego pola NIE UTWORZYĆ W
OGÓLE (mógłby, jeśli np. klasa jest zdefiniowana lokalnie w funkcji i wiadomo,
że nikt jej na zewnątrz nie używa).

Standard C++ wyraźnie mówi, na przykład, że ustalony jest jedynie rozmiar
typów char, signed char i unsigned char i że wynosi on 1. Rozmiary pozostałych
typów są implementation-defined. A sizeof pobrany z typu referencyjnego zwraca
rozmiar typu referowanego.

> >>(nie przykładałem sie do nazw i kodu - tak z palca strzeliłem za drobną 
> >>poprawką - przyznam, sie ze pierwszy pomysł nie działał (referencje nie 
> >>mogą być częścią uni ) )
> > 
> > 
> > Ten pomysł też tak naprawdę nie działa.
> > 
> > Rzutowanie dowolnego wskaźnika na void* działa i będzie działać. Można go też
> > zrzutować spowrotem i też będzie działać. To standard gwarantuje.
> > 
> > To, co ty wyczyniłeś, nie gwarantuje, bo nigdzie nie jest napisane, że pola
> > typów referencyjnych mają taką samą reprezentację, jak wskaźniki do tych
> > typów.

> Działa - działa. :-)
> Mam to na ekranie - możesz sam sobie sprawdzić.

Dobrze. To skompiluj mi takie coś:

char t[] = { 2, 0, 0, 0 };
int x [] = { 10, 20, 30 };
cout << x[*(int*)t] << endl;

Ja na swoim prywatnym też mogę odpalić i stwierdzić, że działa.

Kochany, empirycznie to sobie możesz szukać punktu G u kobiety.

Jeśli mamy rozmawiać o tym, co w języku MOŻNA zrobić, to trzymajmy się tego,
co napisał standard. Albo piszesz program, który jest poprawny zgodnie ze
standardem języka, albo piszesz program, który przypadkiem działa, bo akurat w
pamięci trafiły ci się przypadkiem takie dane, jakie ci są potrzebne.

> > Cóż, faktem jest, że doświadczenia w tych językach się nie krzyżują. Ale, jak
> > wspomniałem, bardzo chętnie się dowiem, jakież to techniki bazowane na C++ są
> > niefortunnie stosowane w Javie. Jakieś przykłady, chętnie ze źródłami.

> (odpisałem w innym msg) ale tak dla dodatku ( troche mi sie przypomniało)
>   number 1 - double checked locking... który, zeby było zabawniej w C++
> też nie ma gwarancji działania :-)

Czyli skucha. Nie pytałem cię o złe nawyki już w C++ przeniesione do Javy,
tylko o nawyki, które są dobre w C++, a okazują się złe w Javie.

> number 2 - metody wirtualne w konstruktorze - nie ma chyba programisty
> C++, który by po przejsciu na javę się na tym nie wyłożył

Przede wszystkim w C++ nikt _nie woła_ metod wirtualnych spod konstruktora.

Osobny problem, however, polega na tym, że metody spod konstruktora są wołane
W OGÓLE. A taką metodę można przypadkiem sobie gdzieś w klasie potomnej
przedefiniować.

Pewnie bym się na tym wyłożył, to fakt. Na zasadzie, że bym nie przewidział. A
po takim doświadczeniu opakował modyfikatorem final KAŻDĄ metodę w klasie,
która jest wołana spod konstruktora. Niewykluczone nawet, że po pewnym czasie
każdą metodę bym odruchowo robił final, odblokowując ją dopiero wtedy, gdy coś
nie działa.

Pozostawianie metod domyślnie z zezwoleniem na przedefiniowanie to naprawdę
szurnięty pomysł. Nie obchodzi mnie to, że w Smalltalku też tak jest (przy
okazji: ciekawe, dlaczego Opera nie wymawia Smalltalk 'smOltOk', tylko coś w
rodzaju 'smelltick' ;). Metoda powinna mieć JAWNIE zaznaczone, że ma
zezwolenie na przedefiniowanie w klasie pochodnej. W tym sensie, uważam że
podejście C# jest najlepsze z możliwych (tak, uważam że lepsze, niż w C++):
musisz zarówno jawnie nadać metodzie prawa do przedefiniowania w klasie
pochodnej, jak i jawnie zaznaczyć, że przedefiniowujesz metodę (a nie tworzysz
nową). Dzięki takiemu podejściu rzeczywiście wiesz, co robisz.

W Javie nie wiesz. Możesz stworzyć sobie metodę w klasie pochodnej, której
nazwa i lista argumentów przypadkiem pokryje ci się z metodą istniejącą w
klasie bazowej. Możesz sobie wywołać jakąś swoją metodę, myśląc że ona coś-tam
ciekawego robi, co sam zdefiniowałeś - a tu myk! użytkownik przedefiniował
metodę w klasie pochodnej i ta metoda robi zupełnie co innego.

Nieważne zresztą. To nie ja się upieram przy twierdzeniu, że Java jest
bezpiecznym językiem.

Tutaj zresztą również skucha. To jest tylko i wyłącznie kwestia zapomnienia o
różnicach techniczno-językowych pomiędzy C++ a Javą, a takich można by
wymienić jeszcze bardzo wiele: nie stawiamy średnika po definicji klasy, klasę
bazową określamy słowem super, po this dajemy kropkę, a nie strzałkę itd. itd.

Prosiłem o pokazanie _technik programowania_ stosowanych w C++ i będących
niewłaściwymi w Javie.

> number 3 - jest dużo koncepcji typu
>         object = null; } //     ludzie wierzą, że to przypisanie działa jak delete
> (chyba zapełniają pustkę po delect object; )   -ale to fakt
> jest nie od ludzi mądrych - tyle, że nie mogłem pominąć - bo to jest
> wręcz wyznacznik kodu pisanego przez konwertytę

Słyszałem od tzw. niektórych (ci niektórzy czytają tą grupę i więdzą, że o
nich mówię), że to właściwie jedyny sposób na to, żeby się jawnie pozbyć
obiektu. Być może obiekt nie zniknie fizycznie, bo jeszcze się przez jakiś
czas pobełta w śmietniku, ale można już założyć, że obiektu nie ma. Jest to w
Javie jedyny sposób na - też nie takie niezawodne, ale w pewnych granicach tak
- usunięcie obiektu.

Przykładowo, jeśli chcemy usunąć obiekt, który jest trzymany przez inny obiekt
(i może być tam akurat null), to żeby ten obiekt usunąć, należy zapisać
referencję nullem. I mieć nadzieję, że nikt sobie nigdzie tej referencji nie
zapamiętał.

Nb. jakbyś pytał, dlaczego moim zdaniem odśmiecacz ukrywa błędy projektowe, to
to jest właśnie ten przypadek:

Problem: polega na tym, że ktoś sobie zapamiętał odniesienie do obiektu i
zamierza go używać, podczas gdy powinien używać tylko w pojedynczym kontekście
i za każdym razem pobierać to odniesienie za pomocą odpowiedniej metody (bo
być może za każdym wywołaniem metody będzie to inne odniesienie, a odniesienie
uzyskane poprzednio może wskazywać na już nieistniejący obiekt).

W środowisku z odśmiecaczem: problem jest niewidoczny, przynajmniej pozornie.
Obiekt nie zostanie usunięty, zapisanie odniesienia nową wartością nic tego
obiektu nie wzrusza, cwaniaczek nadal używa sobie starego obiektu.

W środowisku bez odśmiecacza: problem objawia się próbą odniesienia do
zwolnionego obiektu - rzadko się zdarza, żeby program się w ten sposób nie
posypał, bo w tym momencie jeździ po pamięci jak chce.

Na czym polega problem ze środowiskiem z odśmiecaczem? Na tym właśnie, że tego
błędu nie widać. Obiekt bowiem powinien być usunięty, a na jego miejsce
utworzony nowy. Stary powinien zniknąć, bo reprezentuje coś, co już dawno nie
powinno istnieć. Ponieważ jakiś szurnięty programista postąpił niezgodnie z
protokołem i zapamiętał sobie odniesienie do obiektu, więc w ten sposób
program dalej działa i nawet produkuje wyniki, tylko "coś jest nie tak".

Oczywiście, że teoretycznie w programie bez odśmiecacza jest znacznie gorzej.
Ale to tylko pozór. Program się sypie, bo MA SIĘ SYPAĆ. W programie jest
ewidentny błąd i program ten NIE powinien działać. To co jest w takim razie
gorsze: to, że program się sypie, czy to, że program działa nie do końca
dobrze? W którym z nich łatwiej jest znaleść taki błąd, co więcej, w którym z
nich łatwiej sobie z niego w ogóle zdać sprawę?

Oczywiście, że to bardzo źle, że sobie można pojeździć po pamięci, ale ja
wcale nie mówiłem o języku, który ma bezpośredni dostęp do pamięci, tylko o
języku bez odśmiecacza, co nie jest tożsame. Spokojnie wyobrażam sobie język,
w którym nie ma odśmiecacza, ale każdy obiekt i wszelkie odwołania do nich są
skrzętnie notowane i dba się o to, żeby w miarę możliwości "nie reużywać
adresów" przydzielanej pamięci. A najlepiej to w ogóle mieć po prostu unikalne
idenfikatory dla każdego obiektu, które są niepowtarzalne. W takiej sytuacji
program po prostu rzuciłby wyjątkiem odwołania się do niepoprawnego
odniesienia do obiektu. Czyli wysypałby się tak właśnie, jak się miał wysypać.

Właśnie dlatego też zresztą stało się w Javie konieczne dodanie słabych
odniesień.

> number 4 - nieużywanie tablic - w javie są normalne i porządne tablice
>         ale doświadczony programista C++ nawet na nie nie patrzy tylko
>         używa ślepo wszędzie List<> itp. - to jest np. mój problem :-)  

No dobra. Powiedzmy, że wreszcie podałeś punkt wart dyskusji.

Normalne i porządne to znaczy jakie? Czy są skracalne/rozszerzalne? Czy
posiadają taką funkcjonalność jak std::vector?

> number 5 - brak zrozumienia  dla koncepcji
>         niestatycznych klas wewnętrznych ogólnie        
>         - te w javie dodają jednak troche lukru syntaktycznego  i       
>         rozwiązują mnóstwo pozornych braków Javy

Powtórzę: pytałem o stosowane w kodzie "teoretycznie działające" konstrukcje,
stosowane w porządnym pisaniu w C++, ale dające złe efekty w Javie. Doczekam
się ich kiedyś?


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sektor van Skijlen napisał:
[...]

Wiesz co kolejny post może i warty dyskusji.. ale ja bym chciał, żebyś 
się zadeklarował:
a) wisisz mi połówke bo mój kod działa,
	albo
b) C++ nie gwarantuje Ci niczego takiego jak:
>  tworzy? w?asnych typów danych ze szczegó?owo opisan? obs?ug?
>> >   (które np. nie maj? zezwolenia na modyfikacje, na kopiowanie, na pobieranie
>> >   adresu, na tworzenie w inny ni? odgórnie ustalony sposób, lub te? te

Bo w szczególności mogę użyć sobie cech kompilatora, środowiska ( i to 
nawet nie wchodząc w jakieś rozszerzenia )-  zwyczajnie exploitując 
niedodefiniowane fragmenty specyfikacji.

-- 
http://www.99-bottles-of-beer.net/language-java-866.html

tomasz sobkowiak napisał(a):

>>>niefortunnie stosowane w Javie. Jakieś przykłady, chętnie ze źródłami.
>>
>>(odpisałem w innym msg) ale tak dla dodatku ( troche mi sie przypomniało)
>>  number 1 - double checked locking... który, zeby było zabawniej w C++
>>też nie ma gwarancji działania :-)
>>number 2 - metody wirtualne w konstruktorze - nie ma chyba programisty
>>C++, który by po przejsciu na javę się na tym nie wyłożył
>>number 3 - jest dużo koncepcji typu
>>	object = null; } // 	ludzie wierzą, że to przypisanie działa jak 
> 
> delete
> 
>>(chyba zapełniają pustkę po delect object; )   -ale to fakt
>>jest nie od ludzi mądrych - tyle, że nie mogłem pominąć - bo to jest
>>wręcz wyznacznik kodu pisanego przez konwertytę
>>number 4 - nieużywanie tablic - w javie są normalne i porządne tablice
>>	ale doświadczony programista C++ nawet na nie nie patrzy tylko
>>	używa ślepo wszędzie List<> itp. - to jest np. mój problem :-) 	
>>number 5 - brak zrozumienia  dla koncepcji
>>	niestatycznych klas wewnętrznych ogólnie	
>>	- te w javie dodają jednak troche lukru syntaktycznego  i 	
>>	rozwiązują mnóstwo pozornych braków Javy
> 
> 
> Moze dlatego ze programisci ktorzy przesiadali sie z C++ na Jave nie do konca 
> byli dobrymi programistami?? Przesiadali sie ze wzgledu na to ze w C++ nie 
> zagrzali miejsca ze wzgledu wlasnie na ich watla wiedze?? Ja uzywam C++, 
> Pythona, Javy czetsosc w kolejnosci podania i jakos nie mam problemow i nie 
> stosuje "technik" ktore podales. Siadajac do innego jezyka zdaje sobie sprawe 
> z roznic pomiedzy nimi i nie probuje naciagc jednego aby upodobnic do 
> drugiego.

Tu nie chodzi o naciąganie - a o siłę przyzwyczajenia.

BTW: potrafisz z marszu powiedzieć jaka jest różnica w javie miedzy 
dwoma definicjami tego samego pola w klasie:
a)	private int x = 0;
	
b) 	private int x;

?

I przypomniałem sobie numer 6, który chyba jest numerem 1:

GOOGLE ORIENTED PROGRAMMING :-)
	- przekonaj gościa, który n - lat pisał w C++, żeby zamiast klepania 
jakiegoś swojego fragmenciku złapał kod na googlu.

(sorry, ale w C++ używanie kodu znalezionego ad-hoc jest co najmniej 
utrudnione:
	- brak standardu dokumentacji,
	- brak zgodności w kompilatorach (nie chodzi o 100% ale choćby o 90%),
	- brak standardowego GC,
	- brak standardu dystrybucji bibliotek,
	- brak możliwości wymuszania bezpieczeństwa,
	- brak standardu GUI )

Pamiętam, że to był dla mnie duży szok (po przejściu na javę) jak 
odkryłem, ze w zasadzie o ile tylko umiem rozsądnie sformułować 
zagadnienie to nie tylko znajde odpowiednie biblioteki ale też w parę 
minut będę ich mógł użyć.
Koszt użycia zewnętrznych źródeł jest na tyle niski, że do projektu w 
javie można zaciągać nawet najprostsze nasto-linijkowe fragmenty (jak 
również całkiem duże biblioteki). Nie chodzi tu o podstawowe algorytmy, 
które są w bibliotekach standardowych.
Nikt mnie nie przekona, ze w C++ jest tak samo łatwo. W C++ nadal 
sporadycznie programuję, też ciągnę z googla (znaleźć równie jest łatwo 
jak w javie), ale szlag mnie trafia jak muszę przekopywać się przez 
dokumentację za każdym razem w innym formacie, odkrywać, że musze 
przerzucać vector<double> na double[] i z powrotem jeszcze, używać 
delete i wskaźników i jeszcze kląć bo się okazuje (i to dopiero w 
działaniu!!!), ze lib jest skompilowany z innym niż moje wyrównaniem pól 
w strukturach (ulubione).


-- 
http://www.99-bottles-of-beer.net/language-java-866.html

Dnia Sun, 23 Oct 2005 00:31:53 +0200, jarekr skrobie:
> Sektor van Skijlen napisał:
> [...]

> Wiesz co kolejny post może i warty dyskusji.. ale ja bym chciał, żebyś 
> się zadeklarował:
> a) wisisz mi połówke bo mój kod działa,

Niczego ci nie wiszę, bo twój kod jest napisany sprzecznie ze standardem.
Działanie tego kodu na jakiejś wersji jakiegoś kompilatora po skompilowaniu
bez optymalizacji niczego nie dowodzi.

>         albo
> b) C++ nie gwarantuje Ci niczego takiego jak:
> >  tworzy? w?asnych typów danych ze szczegó?owo opisan? obs?ug?
> >> >   (które np. nie maj? zezwolenia na modyfikacje, na kopiowanie, na pobieranie
> >> >   adresu, na tworzenie w inny ni? odgórnie ustalony sposób, lub te? te

> Bo w szczególności mogę użyć sobie cech kompilatora, środowiska ( i to 
> nawet nie wchodząc w jakieś rozszerzenia )-  zwyczajnie exploitując 
> niedodefiniowane fragmenty specyfikacji.

Czy ty sam przynajmniej wiesz, o czym mówisz?


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sektor van Skijlen wrote:

>No oczywiście, przecież ten poniższy kod jest bardzo czytelny:
>
>	a.setVal(s.add(b.multiply(x.at(g.subtract(1))).divide(6)))
>
>Nie to co C++:
>
>	a = s + (b * x[g-1])/6;
>  
>

No, tak.  Ale typy numeryczne są przecież w Javie typami wbudowanymi i
można używać operatorów.

A jedynym zastosowaniem przeciążenia operatorów jest chyba tylko
programowanie na macierzach i liczbach zespolonych.

-- 
Pozdrawiam serdecznie,
Mariusz Maslowski

jarekr wrote:

> Po prawdzie to pamietam, że przechodząc z C++ ileś razy wrypałem sie w
> jakieś bardzo zabawne  pułapki - ale nie przypomnę sobie teraz.


Ja ci przypomnę. 
Jak porównywałem sobie dwa stringi za pomocą ==, zamiast metody equals().
Oraz jak chciałem wkładać typy proste do kolekcji (np. int do
HashArray), a trzeba je owinąć w te śmieszne Number, czy Integer, które
są z kolei nie modyfikowalne.  Czyli jak chcesz zmienić wartość elementu
kolekcji to stary do śmieci i podstawić new Integer(nowa wartość).



-- 
Pozdrawiam serdecznie,
Mariusz Maslowski

Mariusz Maslowski <maslowski73@wp.pl> writes:

> No, tak. Ale typy numeryczne są przecież w Javie typami wbudowanymi
> i można używać operatorów.
>
> A jedynym zastosowaniem przeciążenia operatorów jest chyba tylko
> programowanie na macierzach i liczbach zespolonych.

I dużych liczbach całkowitych, i ułamkach dziesiętnych, i ułamkach
zwykłych, i interval arithmetic. W samej Javie jest BigInteger
i BigDecimal.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote:

> I dużych liczbach całkowitych, i ułamkach dziesiętnych,
> i ułamkach zwykłych, i interval arithmetic.

A po co uzywac duzych liczb calkowitych, ulamkow dziesietnych, ulamkow
zwyklych, badz interval arithmetic ?...

I czy na tyle czesto uzywac, ze trzeba wprowadzac dla tego specjalny
mechanizm wspierany bezposrednio w jezyku ?


mp

Dnia Mon, 24 Oct 2005 16:43:37 +0200, Michal Przybylek skrobie:
> "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote:

> > I dużych liczbach całkowitych, i ułamkach dziesiętnych,
> > i ułamkach zwykłych, i interval arithmetic.

> A po co uzywac duzych liczb calkowitych, ulamkow dziesietnych, ulamkow
> zwyklych, badz interval arithmetic ?...

> I czy na tyle czesto uzywac, ze trzeba wprowadzac dla tego specjalny
> mechanizm wspierany bezposrednio w jezyku ?

Sprawa rozbija się o dość nie na miejscu spór o to, czy warto dodać daną
właściwość umożliwiającą tworzenie generycznych typów danych, zakładając że
znamy wszystkie możliwe zastosowania tego ficzera.

To mniej więcej taka sama głupota, jak twierdzenie, że po co nam destruktory,
skoro nie mamy jawnego zwalniania pamięci (jeden z absurdalnych argumentów
wysuwanych przez twórców Javy).

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> To mniej więcej taka sama głupota, jak twierdzenie, że po co nam 
> destruktory,
> skoro nie mamy jawnego zwalniania pamięci (jeden z absurdalnych argumentów
> wysuwanych przez twórców Javy).

Konkret prosze.
Gdzie jest taka wypowiedz tworcow(y) Javy ?.
Nie twierdze ze jej nie ma ale.. chcialbym przeczytac.

AK

"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> Sprawa rozbija się o dość nie na miejscu spór o to, czy warto dodać daną
> właściwość umożliwiającą tworzenie generycznych typów danych, zakładając
> że znamy wszystkie możliwe zastosowania tego ficzera.

Na moje sprawa sie rozbija o to, kiedy oplaca sie cos dodawac do jezyka.

Niektorych ludzi po prostu podniecaja "definiowanie wlasnych operatorow",
"domkniecia funkcji", "typy algebraiczne", "pattern-matching", "liczby
nieograniczonej dlugosci" itp. Ja za to sie pytam - ok, ale po co ? O ile to
ulatwi _typowym_ programistom pisanie _wiekszosci_ aplikacji ?


mp