Użytkownik "Edek Pienkowski" <e...@g...com> napisał:

> Skomplikowana to pojęcie relatywne. Alokatory są o tyle niewdzięczne,
> że trudno uzyskać coś lepszego od defaulta.

Dosc latwo tylko ze, .. _nikt tego nie robi_ (i cala elastycznosc z alokatorami
poszla w praktyce w p.. (c) Siara).

AK

do góry

On Mon, 25 Jun 2012 21:40:45 +0000 (UTC), Edek Pienkowski
<e...@g...com> wrote:
>
>Nie ponieważ nie znam COBOL-a. Tak przypuszczałem: "chcesz goto" ->
>"projekt do bani"
>
>Edek
>

Ja nie mowilem o "goto". Ja mowilem o metodzie z 30 parametrami. Jest
to niewtpliwie skutek blednego projektu

A.L.

do góry

W dniu poniedziałek, 25 czerwca 2012 23:37:00 UTC+2 użytkownik AK napisał:

> Tylko powiedz mi Musiu dlaczego w C++ musze sie tyle nameczyc
> (no i jeszcze ten PIMPL niezbedny) jesli w Javie mam to ad hoc

Nie masz. W Javie masz coś innego.

> i bez udziwnien/komplikacji/ograniczen PIMPLa (dziedziczenie) itp ?

Jakiego pimpla? I co ma tu dziedziczenie?

> W Javie/.NET refs sa _wewnetrzym wbudowanym podstawowym mechanizmem_
> obslugi obiektow, wiec Java/.NET sobie moze to o wiele lepiej (i czymi to)
zoptymalizowac

Może. Ale wpływ tego na całość nie jest oczywisty.
Klasy można umownie podzielić na "lekkie" i "ciężkie". Nie pamiętam, żebym
kiedykolwiek stosował xxx_ptr dla lekkich klas, których obiekty albo są na stosie,
albo w kontenerach, albo jako składowe większych klas. Dlatego ewentualny koszt
użycia xxx_ptr nie ma tu znaczenia.
Niemal zawsze, gdy używałem xxx_ptr, odnosiło się to do jakiejś "ciężkiej" klasy,
której obiektu tworzy się rzadko, rzadko się je też przerzuca a jak już się ich
użyje, to na ścieżce krytycznej jest właśnie to użycie i nic więcej.
Przykład obrazkowy: wisi mi, jaki jest koszt użycia xxx_ptr w odniesieniu do klasy
DatabaseConnection.

> PS: i nieprawda jest, ze mam wtedy "deterministyczne" zwalnianie zasobow.
> Mamy tak/podobnie jak w Javie/C# (smieciarka), czyli wolnienie gdy ref_count
> zjedzie do 0.

Nie. W C++ jest deterministycznie, bo zwolnienie jest na pewno i właśnie wtedy. W
Javie zwolnienie jest być może i nie wcześniej, niż. To jest różnica, choć faktycznie
w wielu przypadkach nie jest ona istotna. Ale jeśli chcesz się przepychać nt.
terminologii, to bądźmy precyzyjni.

>> Spieprzyć kod można w dowolnym języku.
>
> Czasem sam jezyk (C++) "pieprzy"" kod.

Każdy język tak robi. Ale każdy inaczej.

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

do góry

On 25.06.2012 23:37, AK wrote:
> Użytkownik "Michoo" <m...@v...pl> napisał:
> Nie ucz ojca dzieci robic (dlaczego kurcze Wam mlodym _ciagle_ sie od lat
> wydaje, ze pozjadaliscie wszytskie rozumy/umiejetnosci
Tu nie chodzi o umiejętności tylko o to, że zderzasz rzadkie przypadki
krańcowe i o jakieś 10 lat przeterminowane praktyki C++ z najnowszą
wersją Javy/C#. Ja zaczynałem naukę C++ na bcb5 12 lat temu. Bcb6, który
wyszedł 10 lat temu był już naprawdę fajnym środowiskiem.
Genryki w C# są od jakiś 7 lat, w javie od 8.

> w stosunku
> do nas "matuzalemow;) ?).
Skoro przez tyle lat nie byłeś w stanie opanować podstawy C (wyliczanie
wartości wyrażeń) to mam silne podstawy sądzić, że twój staż nie idzie w
parze z wiedzą.


> Tylko powiedz mi Musiu dlaczego w C++ musze sie tyle nameczyc
Nikt Cię nie zmusza do męczenia się w C++. Ja się męczyłem w Javie.

> (no i jeszcze ten PIMPL niezbedny)
To jest JEDNA z podanych przeze mnie możliwości. Nie jest niezbędna. W
c++ możesz zresztą użyć alokatora opartego o GC. Tylko po co?

> jesli w Javie mam to ad hoc
W javie to działa inaczej - brak semantyki referencji. Masz raczej const
wskaźnik ze wszelkimi ograniczeniami.

GC ma JEDNĄ zaletę w porównaniu z RC - sprząta cykle. A cykliczne
powiązania między obiektami są po pierwsze rzadkie, po drugie niektóre
GC sobie z cyklami tez specjalnie nie radzą (patrz python).

Do tego gc zachęca do niechlujstwa. I nagle jest problem gdy biblioteka
przy próbie wczytania 100MB pliku potrzebuje 12GB ramu(bo zajęcie 1GB
przy obróbce 10MB to było "jeszcze normalne, teraz ramu jest dużo").

> Przeciez wtedy pisze niby w C++, ale _tak naprawde w Javie_ :)
Raczej pisząc w Javie piszesz w brutalnie wykastrowanym C++.

>
> Zwlaszcza, ze shared_ptr jest "atomowy" rowniez w sensie wielowatkowosci,
> a wiec naprawde _cholernie_ kosztowny w stosunku do jednowatkowosci.
> Tyle, ze ja sobie "mutexowania" w shared_ptr wylaczyc nie moge
> nawet gdybym w dokumentacji duzymi bukwami napisal, ze
> program/modul jest jednowatkowy.
Jakiego, kwa, muteksowania? Dobra implementacja ma użyte CAS,
prawdopodobnie w formie lock cmpxchg - cały koszt przy odpowiedniej
optymlizacji po stronie twórców biblioteki to blokada magistrali na
jeden dodatkowy transfer.

> Przecie smart_ptr to szablon, a wiec macro a wiec kompilator g.. wie o
> kontekscie uzycia (nie umie zoptymalizowac).
Kłamstwo.

> W Javie/.NET refs sa _wewnetrzym wbudowanym podstawowym mechanizmem_
> obslugi obiektow, wiec Java/.NET sobie moze to o wiele lepiej
Teoretycznie może i cały czas mnie dziwi, że mimo, że JIT powinien być
świetnym rozwiązaniem (kilka lat temu naprawdę tej technologii
kibicowałem) i dawać znaczącego boosta to ciągle się tak nie dzieje.

> (i czymi
> to) zoptymalizowac
Za to nie może zoptymalizować innych rzeczy. No i robi głównie
mikrooptymalizacje a nie makrooptymalizację.

>
> PS: i nieprawda jest, ze mam wtedy "deterministyczne" zwalnianie zasobow.
> Mamy tak/podobnie jak w Javie/C# (smieciarka), czyli wolnienie gdy
> ref_count
> zjedzie do 0.
Jeżeli masz porządnie napisaną aplikację to jesteś w stanie wyznaczyć
punkty w których stan powinien być stabilny i dzięki temu łatwo
zweryfikować ewentualne wycieki.

> (No ale o cykle to juz musze niestety zadbac/pilnowac sam:).
Najdłużej debugowaną przeze mnie pod względem wycieków aplikacją był
kodserwera w pythonie, który ciekł kilka GB na tydzień. Wszystko właśnie
z powodu cykli.


>
>> Spieprzyć kod można w dowolnym języku.
>
> Czasem sam jezyk (C++) "pieprzy"" kod.
Java też robi to notorycznie. Ja wolę już "pieprzenie" na modłę C++.

>
>> P.S.
>> Przypominam, że miałeś udowodnić jak to kolejność ewaluacji operatorów
>> w C/C++ jest dowolna.
>
> a nie chce mi sie teraz:) Moze jutro ?
Ani jutro ani pojutrze nic nie udowodnisz, bo po portu nie masz racji.

> I badz precyzyjny: pisalem ze "kolejnosc evaluacji operatorow" _o tym
> samym priotrytecie_
> jest dowolna.
> Nawiasy w tym przypadku sa opuszczane juz na etapie (umownego) parsingu.
Cały czas mieszasz Example 6 z Example 7 w 5.1.2.3 standardu C. Jeszcze
nie zdecydowałem, czy wbrew temu co lansujesz mimo tylu lat pracy po
prostu NIE ZNASZ C, czy trollujesz.

--
Pozdrawiam
Michoo

do góry

Użytkownik "Michoo" <m...@v...pl> napisał:

>> a nie chce mi sie teraz:) Moze jutro ?
> Ani jutro ani pojutrze nic nie udowodnisz, bo po portu nie masz racji.

A jak udowodnie ze (a+b)+c to jest w C _dokladnie_ to samo co a+(b+c)
to odszczekasz te wszystkie banialuki co powypisywales i na moje
zwyczajowe: "Czolem Mlodziezy" odkrzykniesz " Czolem Mistrzu " ? :)

AK

do góry

On Monday, June 25, 2012 9:59:11 PM UTC+1, Michoo wrote:
> On 25.06.2012 22:08, AK wrote:
> > Użytkownik "Edek Pienkowski" <e...@g...com> napisał:
> >
> >> Ja to mało wydajny jestem, ale już od dawna marudzą, że tool startuje
> >> aż w 2 minuty, i to pomimo tego, że wcześniej startował w 6. Ciężkie
> >> życie...
> >
> > No to sobie wbij do glowy, ze wlasnie to wychwalene "reczne" malloc jest
> > _najbardziej kosztowna funkcja w C/C++_.
> Jakie, kurcze, "ręczne" malloc? Jeżeli w c++ oprzesz sobie cały
> interface na shared_ptr<T> to masz dokładnie to co robi java/C#

A potem odkrywasz istnienie kontenerow.

RW

do góry

Dnia Mon, 25 Jun 2012 20:57:34 -0500, A.L. napisal:

> On Mon, 25 Jun 2012 21:40:45 +0000 (UTC), Edek Pienkowski
> <e...@g...com> wrote:
>>
>>Nie ponieważ nie znam COBOL-a. Tak przypuszczałem: "chcesz goto" ->
>>"projekt do bani"
>>
>>Edek
>>
>>
> Ja nie mowilem o "goto". Ja mowilem o metodzie z 30 parametrami. Jest to
> niewtpliwie skutek blednego projektu

Ja o zmiennych mówiłem, nie parametrach. Zmiennych lokalnych dla funkcji.

Edek

do góry

On 26.06.2012 15:07, AK wrote:
> Użytkownik "Michoo" <m...@v...pl> napisał:
>
>>> a nie chce mi sie teraz:) Moze jutro ?
>> Ani jutro ani pojutrze nic nie udowodnisz, bo po portu nie masz racji.
>
> A jak udowodnie ze (a+b)+c to jest w C _dokladnie_ to samo co a+(b+c)
Przy założeniu, że a,b i c to dowolne zmienne (Bo dla unsigned int
oczywiście jest to prawda.) nie udowodnisz, bo standard daje wyraźne
przykłady (jeden już podałem) dla twórców implementacji w jakich m.in.
przypadkach tak nie jest.

Ale chętnie (jeszcze) wysłucham co masz do powiedzenia.

> to odszczekasz te wszystkie banialuki co powypisywales
A jak już zrozumiesz, że nie masz racji to odszczekasz wszystkie swoje
banialuki?

> i na moje
> zwyczajowe: "Czolem Mlodziezy" odkrzykniesz " Czolem Mistrzu " ? :)
I będziesz odnosił się z minimalnym szacunkiem do młodszych a
mądrzejszych? Może być nawet i "Czołem Mistrzu".

--
Pozdrawiam
Michoo

do góry

On Tue, 26 Jun 2012 14:01:06 +0000 (UTC), Edek Pienkowski
<e...@g...com> wrote:

>Dnia Mon, 25 Jun 2012 20:57:34 -0500, A.L. napisal:
>
>> On Mon, 25 Jun 2012 21:40:45 +0000 (UTC), Edek Pienkowski
>> <e...@g...com> wrote:
>>>
>>>Nie ponieważ nie znam COBOL-a. Tak przypuszczałem: "chcesz goto" ->
>>>"projekt do bani"
>>>
>>>Edek
>>>
>>>
>> Ja nie mowilem o "goto". Ja mowilem o metodzie z 30 parametrami. Jest to
>> niewtpliwie skutek blednego projektu
>
>Ja o zmiennych mówiłem, nie parametrach. Zmiennych lokalnych dla funkcji.
>
>Edek

Przeczytalem jeszcze raz twoj oryginalny post. I teraz nic nie
rozumiem.

A.L.

do góry

Użytkownik "A.L." <l...@a...com> napisał:

> Przeczytalem jeszcze raz twoj oryginalny post. I teraz nic nie
> rozumiem.

No to jest nas dwoch.

AK

do góry