W dniu piątek, 23 listopada 2018 10:34:25 UTC+1 użytkownik AK napisał:
> > Przecież to syf w porównaniu do C++ z Qt...
>
> Nie wypowiadaj sie na tematy o ktorych masz dokladnie zerowe pojecie.

Wystarczająco dobre, by wiedzieć, że VM to syf i patologia leczona plastrami
nikotynowymi...

> Tylko ze... Qt to nie standard,

Praktycznie to już standard. Jak znasz C++ a nie znasz Qt, to nie jesteś pełno
sprawnym programistą C++

> ba! Nawet nie darmowe (GPL)

Od 2009 jest do wyboru licencja Gpl, Lgpl i komercyjna...

> i ciezkie
> (jako biblioteka) jak cholera.

Jak masz wolne 3,5 kEUR to możesz mieć "lekkie" exe (biblioteki linkowane
statycznie).
A co masz w Java czy .Net ?!? Musisz rozprowadzać swoje "kody bajtowe" razem z
ogromnym VM i biliotekami!!!

do góry

On 2018-11-23 17:42, s...@g...com wrote:

> Wystarczająco dobre, by wiedzieć, że VM to syf i patologia
> leczona plastrami nikotynowymi...

Wez sie czlowieku przestan osmieszac i wbij sobie w lepetyne,
ze Twoj ukochany procesor to tez w gruncie rzeczy VM-ka.

AK

do góry

On 2018-11-23 17:42, s...@g...com wrote:

> Od 2009 jest do wyboru licencja Gpl, Lgpl i komercyjna...

No mowie przecie: nie darmowe

AK

do góry

On Friday, November 23, 2018 at 3:47:50 PM UTC+1, AK wrote:
> On 2018-11-23 14:46, Maciej Sobczak wrote:
>
> > Dlaczego? Jest konsekwentny. W odróżnieniu np. od Javy, gdzie int jest
wartościowy
> > ale Integer nie jest, albo nie da się zrobić List<int>, albo gdzie wskaźniki
> > nazywane dla zmyłki referencjami są jednak wartościowe, itd.
>
> Kazdy Javowiec dobrze wie dlaczego jest ta dwoistosc (ze wzgledow
> wydajnosciowych dla typow prostych).

Jak ich przekonano, że to dobre, to wierzą; nawet uwierzą, że strictfp wynika z
Wielkiego Planowania I Przewidywania. :)
To jest przykład na to, że koślowość wynika z ważniejszej potrzeby: zachowania
kompatybilności bajtkodu. BTW, nie możesz stworzyć metody, która byłby większa niż
64kB w bajtkodzie, bo kompatybilność.

> W C++ nie ma żadnej (a to "podobno" obiektowy jezyk:).

Akurat w C++ typy całkowite po prostu są. Chociaż zawsze można je opakować w klasy i
dodać anonimowe pola char[64], żeby dotrzymać kroku w wymaganiach pamięciowych Javy.
:)

w.

do góry

> > Alternatywą w C++ są wskaźniki (różnych rodzajów).
>
> Jaaasne :) I t wycieki

Napisałem "różnych rodzajów" właśnie dlatego, że o wyciekach też pomyślano.

BTW:

https://www.google.com/search?q=Java+memory+leak

> PS: Zeby nie bylo. Doceniam, ze po 40 latach komitet laskawie
> zauwazyl, ze nalezy ustandaryzowac cus tak niezbednego jak
> shared_ptr (C++11).

Bo, jak na ironię, to wcale nie wymagało standaryzacji. Pamiętaj też, że w pewnej
klasie programów (zwykle akurat tam, gdzie taki shared_ptr w ogóle może być
potrzebny) zupełnie praktycznym standardem jest Boost. Tzn. standardem na takiej
samej zasadzie, jak dla niektórych standardem jest Java czy .NET.
I w takim C++Boostowym standardzie shared_ptr już był.
Dlatego Twoja krytyka, czy też może docenianie komitetu, w tym zakresie nie ma
większego znaczenia.

--
Maciej Sobczak * http://www.inspirel.com

do góry

> > Dlaczego? Jest konsekwentny. W odróżnieniu np. od Javy, gdzie int jest
wartościowy
> > ale Integer nie jest, albo nie da się zrobić List<int>, albo gdzie wskaźniki
> > nazywane dla zmyłki referencjami są jednak wartościowe, itd.
>
> Kazdy Javowiec dobrze wie dlaczego jest ta dwoistosc (ze wzgledow
> wydajnosciowych dla typow prostych).

Nie zgadzam się. Nie ma żadnego powodu robić takiej dwoistości, żeby uzyskać
wydajność. W szczególności wydajność nie jest powodem, dla którego List<int> nie
działa. Jakoś w innych językach działa i nikt tym językom nie zarzuca braku
wydajności. To, że w Javie nie działa List<int> wynika z tego, że projektanci Javy
nie mieli jaj, żeby od początku zrobić prawdziwe generyki, zamiast tego zrobili jakąś
cienką nakładkę na referencyjno-obiektowy system pod spodem. Dlatego musi być
List<Integer> - bo akurat to da się *łatwo* zaimplementować przez tzw. wymazywanie
typów ("type erasure" dla poliglotów) tak, żeby wyszło z tego List<Object>, bo to już
umieli wcześniej. Tymczasem zarówno Ada jak i C++ potrafią zrobić kontener z
elementami typu prostego tak samo, jak kontener z elementami referencyjnymi i w obu
przypadkach jest tak samo (tzn. maksymalnie) wydajnie.

Nie gloryfikuj amatorszczyzny. Schizofrenia Javowego systemu typów nie ma żadnego
związku z wydajnością.

> Jest jednak zawsze alternatywa int:Integer

Ale właśnie ta alternatywa jest kompletnie po nic. To nie jest ficzer, to jest
właśnie defekt, bo nie ma powodu, żeby liczbę naturalną wyrażać na więcej, niż jeden
sposób. To jest ten moment, kiedy patrzysz w popękane lustro i cieszysz się, że jest
Ciebie tak wielu. Nie, masz po prostu popsute lutro.

> i w zaleznosci od potrzeb

Potrzeba jest zawsze jedna. To język zmusza programistę do myślenia na dwa sposoby o
tym samym. To jest właśnie defekt (popsute lustro).

> W C++ nie ma żadnej (a to "podobno" obiektowy jezyk:).

Nie ma żadnego problemu, żeby zrobić list<shared_ptr<int> >. Ale taka "alternatywa"
nie ma związku z obiektowością. Zwłaszcza, że lista liczb to w ogóle nie jest problem
obiektowy.

Nie mieszaj pojęć.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On Saturday, November 24, 2018 at 9:05:30 PM UTC+1, Maciej Sobczak wrote:
> > PS: Zeby nie bylo. Doceniam, ze po 40 latach komitet laskawie
> > zauwazyl, ze nalezy ustandaryzowac cus tak niezbednego jak
> > shared_ptr (C++11).
>
> Bo, jak na ironię, to wcale nie wymagało standaryzacji. Pamiętaj też, że w pewnej
klasie programów (zwykle akurat tam, gdzie taki shared_ptr w ogóle może być
potrzebny) zupełnie praktycznym standardem jest Boost. Tzn. standardem na takiej
samej zasadzie, jak dla niektórych standardem jest Java czy .NET.
> I w takim C++Boostowym standardzie shared_ptr już był.

Akurat C++ w zakresie swobody reprezentacji obiektów w pamięci daje duże możliwości.
W projekcie przy którym pracowałem mieliśmy:

* zwykłe wskaźniki,
* referencje,
* std::unique_ptr,
* std::shared_ptr,
* własny, intruzywyny shared_ptr,
* odśmiecacz mark & sweep.

w.

do góry

> Zastanawiam się, czy to jest pojęcie wyłącznie akademickie.

Jeżeli ktoś po tej dyskusji ma jeszcze resztki zainteresowania tematem, to zachęcam
do lektury:

http://www.inspirel.com/articles/Supporting_Loop_Inv
ariants.html

To jest opis implementacji niezmienników - a konkretnie tego, jak można niezmienniki
statycznie weryfikować.

--
Maciej Sobczak

do góry

W dniu 23.11.2018 o 19:54, Wojciech Muła pisze:
> To jest przykład na to, że koślowość wynika z ważniejszej potrzeby: zachowania
kompatybilności bajtkodu. BTW, nie możesz stworzyć metody, która byłby większa niż
64kB w bajtkodzie, bo kompatybilność.

Z drugiej strony to zaleta, nie ma kobyłowatych metod

do góry

On Saturday, December 1, 2018 at 3:15:03 PM UTC+1, Borneq wrote:
> W dniu 23.11.2018 o 19:54, Wojciech Muła pisze:
> > To jest przykład na to, że koślowość wynika z ważniejszej potrzeby: zachowania
kompatybilności bajtkodu. BTW, nie możesz stworzyć metody, która byłby większa niż
64kB w bajtkodzie, bo kompatybilność.
>
> Z drugiej strony to zaleta, nie ma kobyłowatych metod

Chyba, że akurat korzystasz z jakiegoś generator kodu i nie
masz dużej kontroli nad tym, co się dzieje pod spodem.

w.

do góry