🚀 go-pugleaf

Sebastian Nibisz wrote:

> Na dzień dzisiejszy projekt biblioteki nie kompiluje się na kompilatorze
> GCC (a przynajmniej od wersji 3.4 w dół), ponieważ w szablonie jednej z
> klas, skorzystałem z dobrodziejstwa specjalizacji metod, co niestety jest
> trochę niestandardowe. Postaram sie to zmienić później.

tylko nie cofaj w rozwoju kodu :)
branch 3.4 jest juz dawno zamkniety, a wkrotce takze ten los spotka 4.1,
wiec radze sie skupic tylko na kompilowalnosci pod gcc >= 4.2

Użytkownik "Paweł" <root@[127.0.0.1]> napisał:

> tylko nie cofaj w rozwoju kodu :)
> branch 3.4 jest juz dawno zamkniety, a wkrotce takze ten los spotka 4.1,
> wiec radze sie skupic tylko na kompilowalnosci pod gcc >= 4.2

Nie sluchaj tego czlowieka !

>> Postaram sie to zmienić później.

Postaraj sie koniecznie :)
W zaprzyjaznionej firmie gcc 3.x bedzie jeszcze przez lata uzywany
(jak chyba w wiekszosci), a bardzo chcialbym wyprobowac Twoja biblioteke.

AK

> Na dzień dzisiejszy projekt biblioteki nie kompiluje się na kompilatorze 
> GCC (a przynajmniej od wersji 3.4 w dół), ponieważ w szablonie jednej z 
> klas, skorzystałem z dobrodziejstwa specjalizacji metod, co niestety jest 
> trochę niestandardowe. Postaram sie to zmienić później. Bibliotekę można 
> przekompilować na kompilatorach VC8 oraz VC9, na wsześniejszych nie 
> sprawdzałem.

Udostępniłem wersję 0.8.2 biblioteki SGCL w której poprawiłem kompatybilność 
kodu z kompilatorem GCC (wersja 3.4.2)
Dodałem testowy plik projektu dla środowiska Dev-Cpp.

 Pozdrawiam.

 - Bastek -

Sebastian

Jeszcze jedno pytanie z gatunku naiwnych:

Czym sie rozni/codaje wiecej ta biblioteka
w stosunku od boostowego/MSowego
shared_pointer-a ?

AK 

> Jeszcze jedno pytanie z gatunku naiwnych:
>
> Czym sie rozni/codaje wiecej ta biblioteka
> w stosunku od boostowego/MSowego
> shared_pointer-a ?

Shared poiner jest niestety wielce niedoskonałym sposobem odśmiecania, gdyż 
działa w oparciu o mechanizm zliczania referencji i ma cztery podstawowe 
wady:

1. Nie zwalnia struktur cyklicznych.
2. Operacje na wskaźnikach są kosztowne (wymaga operacji atomowych).
3. Zwalnianie większych struktur, może doprowadzić do przepełnienia ramki 
stosu.

    struct Node
    {
        shared_ptr<Node> Next;
    };

    {
        shared_ptr<Node> root(new Node);
        shared_ptr<Node> node(root);

        for (int x = 0; x < 1000000; ++x)
        {
            node = node->Next = shared_ptr<Node>(new Node);
        }
    }  // <- KATASTROFA !!!

4.  Zwalnianie większych struktur, może na dłuższy okres wstrzymać działanie 
aplikacji (wymaga operacji atomowych).

Oczywiście niezaprzeczalna zaletą shared poiner, jest możliwość 
deterministycznego zwalniania zasobów, co w typowym systemie GC jest 
niemożliwe do uzyskania.

SGCL jest w pełni wspóbieżnym systemem GC (osobny wątek aplikacji), opartym 
na algorytmie mark & sweep. Wątek GC działa niezależnie od innych wątków 
aplikacji i nie musi być z nimi w żaden sposób synchronizowany.

Prawde powiedziawszy, na chwilę obecną, nie spotkałem jeszcze takiej 
implementacji systemu GC w jakimkolwiek języku czy środowisku.

Pozdrawiam.

- Bastek - 

Sebastian Nibisz wrote:
> SGCL jest w pełni wspóbieżnym systemem GC (osobny wątek aplikacji), 
> opartym na algorytmie mark & sweep. Wątek GC działa niezależnie od 
> innych wątków aplikacji i nie musi być z nimi w żaden sposób 
> synchronizowany.
> 
> Prawde powiedziawszy, na chwilę obecną, nie spotkałem jeszcze takiej 
> implementacji systemu GC w jakimkolwiek języku czy środowisku.

.NET CLR

-- 

Artur

>> Prawde powiedziawszy, na chwilę obecną, nie spotkałem jeszcze takiej 
>> implementacji systemu GC w jakimkolwiek języku czy środowisku.
>
> .NET CLR

.NET CLR może mieć co najwyżej odśmiecacz przyrostowy a wątek GC musi być 
synchronizowany z wątkami aplikacji.

Pozdrawiam.

- Bastek - 

Użytkownik "Sebastian Nibisz" <EBA_K@poczta.onet.pl> napisał:
> Shared poiner jest niestety wielce niedoskonałym sposobem odśmiecania, 
> gdyż działa w oparciu o mechanizm zliczania referencji i ma cztery 
> podstawowe wady:

Swieta prawda

> Oczywiście niezaprzeczalna zaletą shared poiner, jest możliwość 
> deterministycznego zwalniania zasobów, co w typowym systemie GC jest 
> niemożliwe do uzyskania.

Mozna przebolec.
Rachunek zalet do wad zdecydowanie na korzysc gc.

> SGCL jest w pełni wspóbieżnym systemem GC (osobny wątek aplikacji), 
> opartym na algorytmie mark & sweep. Wątek GC działa niezależnie od innych 
> wątków aplikacji i nie musi być z nimi w żaden sposób synchronizowany.

To mnie wlasnie w Twojej implementacji zainteresowalo.
Nie widzialem 'smieciarki' do C++ o takim podejsciu.

> Prawde powiedziawszy, na chwilę obecną, nie spotkałem jeszcze takiej 
> implementacji systemu GC w jakimkolwiek języku czy środowisku.

Nie slyszalem tez, bo zwyczajnie sie nie znam/nie siedze w odsmiecarkach,
ale jelsi tak to gratuluje lecz.. podejrzewalbym jednak Jave i/lub .NET :).

AK

Sebastian Nibisz wrote:
>>> Prawde powiedziawszy, na chwilę obecną, nie spotkałem jeszcze takiej 
>>> implementacji systemu GC w jakimkolwiek języku czy środowisku.
>>
>> .NET CLR
> 
> .NET CLR może mieć co najwyżej odśmiecacz przyrostowy a wątek GC musi 
> być synchronizowany z wątkami aplikacji.

Nie cieprie GC :) to sie wogole nie sprawdza przy przetwarzaniu duzej 
ilosci danych , duze chwilowe alokacje, przynajmiej ten z NET.

Witam

Adam Karpierz wrote:

>> Oczywiście niezaprzeczalna zaletą shared poiner, jest możliwość
>> deterministycznego zwalniania zasobów, co w typowym systemie GC jest
>> niemożliwe do uzyskania.
> 
> Mozna przebolec.
> Rachunek zalet do wad zdecydowanie na korzysc gc.

To zależy od celu. Taka generalizacja jest bardziej wadliwa niż wady smart
pointerów.

Powiedziałbym tak:

Średnio na komputerach klasy PC i lepszych z dużą ilością RAM-u GC może
ułatwić pisanie programu mielącego RAM.

Tam gdzie RAM trzeba szanować należy również przemyśleć skutki pracy z GC.

Pomijam aspekty wpływu GC an lenistwo i ignorancję koderów oraz ich zaufanie
do jego świątobliwości GC w sytuacjach kiedy np. potrzeba alokować/zwalniać
zasoby mające mocne ograniczenia (liczbowe/ilościowe) -- i to jest bardzo
groźne. Mam na myśli deskryptory plików, sokety, połączenia do baz danych,
rurki, obiekty i transakcje rozproszone itd.

Poza tym w swojej ocenie pominął Pan obiekty pośrednie czyli Alokatory,
które mogą łączyć zalety/wady GC i smart pointerów.

Temat był wiele razy walcowany. Takie jednolinijkowe podsumawania nikomu nie
są potrzebne.

Raczej cenne jest to, że w C/C++ można mieć GC i można go nie mieć w
zależności od potrzeb. I to jest ewidentna zaleta C/C++.

W innych językach, aby pokombinować przy GC trzeba się nahakować -- patrz
manuale o tunigu GC w Javie.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

>>> Oczywiście niezaprzeczalna zaletą shared poiner, jest możliwość
>>> deterministycznego zwalniania zasobów, co w typowym systemie GC jest
>>> niemożliwe do uzyskania.
>>
>> Mozna przebolec.
>> Rachunek zalet do wad zdecydowanie na korzysc gc.
>
> To zależy od celu. Taka generalizacja jest bardziej wadliwa niż wady smart
> pointerów.

Taka generalizacja z małymi wyjątakami, jest jak najbardziej prawidłowa. 
Poza systemami z bardzo ograniczonymi zasobami pamięciowymi, smart pointery 
ze zliczaniem referencji, średnio się nadają do zarządzania pamięcią RAM.

> Powiedziałbym tak:
>
> Średnio na komputerach klasy PC i lepszych z dużą ilością RAM-u GC może
> ułatwić pisanie programu mielącego RAM.

Ułatwić, czyli skrócić czas powstawania aplikacji a jak wiadomo czas to 
pieniądź. Nikt nie będzie sie bawił w dużą optymalizację zużycia pamięci RAM 
w aplikacji dla typowego sprzętu PC, bo to nie ma większego sensu.

> Tam gdzie RAM trzeba szanować należy również przemyśleć skutki pracy z GC.

Biorąc pod uwagę rosnącą w ostatnim czasie, popularność języków z wbudowanym 
systemem GC, jest coraz mniej obszarów w których pamięć aż tak bardzo trzeba 
szanować.

> Pomijam aspekty wpływu GC an lenistwo i ignorancję koderów oraz ich 
> zaufanie
> do jego świątobliwości GC w sytuacjach kiedy np. potrzeba 
> alokować/zwalniać
> zasoby mające mocne ograniczenia (liczbowe/ilościowe) -- i to jest bardzo
> groźne. Mam na myśli deskryptory plików, sokety, połączenia do baz danych,
> rurki, obiekty i transakcje rozproszone itd.

GC nadaje się tylko i wyłacznie do zarządzania pamięcią RAM. Kto tego nie 
rozumie, nie lepiej z GC nie korzysta.

Pozdrawiam.

- Bastek - 

Brawo !

AK 

Witam

Sebastian Nibisz wrote:

> Ułatwić, czyli skrócić czas powstawania aplikacji a jak wiadomo czas to
> pieniądź.

O tak to ma sens, ale wszystko w ten sam sposób moge sprowadzić do
pieniędzy. Co więcej teorię przeciwną również.

> Biorąc pod uwagę rosnącą w ostatnim czasie, popularność języków z
> wbudowanym systemem GC, jest coraz mniej obszarów w których pamięć aż tak
> bardzo trzeba szanować.

A tą ilość/liczbę jak określasz? W liniach kodu, w sztukach sprzedanych
instalacji.
 
> GC nadaje się tylko i wyłacznie do zarządzania pamięcią RAM. Kto tego nie
> rozumie, nie lepiej z GC nie korzysta.

O tak! Święta prawda. Powiedz mi teraz ile koderów tak uważa, co więcej ile
koderów ma to w pamięci. Generalnie jest tak, że tylko ci "> intemediate" o
tym pamiętają, zeby np. plik zamknac, żeby zamknąc połaczenie do bazy, zeby
posprzatac rozproszone obiekty itd. A kodu tego typu powstaje dosc troche w
jezykach z GC. Po prostu ogólnie zakłada się nieskończoność zasobów i jak
system się nasyca, to winą zwala się na system -- dać mu trzeba więcej
węgla -- a nie na kichane "wycieki" w programie (GC zwalnia zasoby kiedy
chce).

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

>> Ułatwić, czyli skrócić czas powstawania aplikacji a jak wiadomo czas to
>> pieniądź.
>
> O tak to ma sens, ale wszystko w ten sam sposób moge sprowadzić do
> pieniędzy. Co więcej teorię przeciwną również.

Ale po co sobie utrudniac życie, dla frajdy?

>> Biorąc pod uwagę rosnącą w ostatnim czasie, popularność języków z
>> wbudowanym systemem GC, jest coraz mniej obszarów w których pamięć aż tak
>> bardzo trzeba szanować.
>
> A tą ilość/liczbę jak określasz? W liniach kodu, w sztukach sprzedanych
> instalacji.

W ilościach nowych projektów tworzonych w języku C++. Od kilka lat, 
procentowo ta ilość systematycznie spada.

>> GC nadaje się tylko i wyłacznie do zarządzania pamięcią RAM. Kto tego nie
>> rozumie, nie lepiej z GC nie korzysta.
>
> O tak! Święta prawda. Powiedz mi teraz ile koderów tak uważa, co więcej 
> ile
> koderów ma to w pamięci. Generalnie jest tak, że tylko ci "> intemediate" 
> o
> tym pamiętają, zeby np. plik zamknac, żeby zamknąc połaczenie do bazy, 
> zeby
> posprzatac rozproszone obiekty itd. A kodu tego typu powstaje dosc troche 
> w
> jezykach z GC. Po prostu ogólnie zakłada się nieskończoność zasobów i jak
> system się nasyca, to winą zwala się na system -- dać mu trzeba więcej
> węgla -- a nie na kichane "wycieki" w programie (GC zwalnia zasoby kiedy
> chce).

To że istnieją niekompetentni programiści, nie jest w żadnym stopniu winą 
istnienia systemów GC.

Pozdrawiam.

- Bastek - 

Witam

Sebastian Nibisz wrote:

>>> Ułatwić, czyli skrócić czas powstawania aplikacji a jak wiadomo czas to
>>> pieniądź.
>>
>> O tak to ma sens, ale wszystko w ten sam sposób moge sprowadzić do
>> pieniędzy. Co więcej teorię przeciwną również.
> 
> Ale po co sobie utrudniac życie, dla frajdy?

Dla ustalenia uwagi. Nie mam nic przeciwko SGCL ani Śmieciuchowi, ani innemu
GC dla C++ i C.

Podkreślę moje stanowisko.

Zarówno Ty jak i Pan Karpierz oraz wszyscy lokalni Ajatollahowie GC :-)
znają i umieją pisać w C, C++ lub innych brzydkich językach !!!

Mając to w pamięci. Kiedy mówisz o zasobach w językach z GC używasz wzorca
projektowego "język C", czyli jezeli coś ma być napisane
alokując/zwalniając zasoby inne niż RAM mówisz: "Piszemy jak w C!". 
To jest użycie wzorca projektowego "język C".

Teraz postaw się w sytuacji (która mnie dotknęła) wytłumacz to przeciętnemu
koderowi języka z GC (i tylko jednego języka, bo tacy jednojęzykowcy są
tanii).

Co mu powiesz? Wyłożysz mu C? Ile to bedzie kosztować? Szkolenie z podstaw C
też kosztuje. Ja chętnie szkolę, ale czy to jest tanie -- nie sądzę?
Jest tańsze niż wykłady firm consultingowych, ale nadal nie jest tanie.

>>> Biorąc pod uwagę rosnącą w ostatnim czasie, popularność języków z
>>> wbudowanym systemem GC, jest coraz mniej obszarów w których pamięć aż
>>> tak bardzo trzeba szanować.
>>
>> A tą ilość/liczbę jak określasz? W liniach kodu, w sztukach sprzedanych
>> instalacji.
> 
> W ilościach nowych projektów tworzonych w języku C++. Od kilka lat,
> procentowo ta ilość systematycznie spada.

Aha. No ja na to patrzę przez inny pryzmat.

Metryka używalności:

        max ( liczba użytkowników, liczba instalacji )

Przykład: Amazon -- tak o sobie piszą:

Platform: Linux, Oracle, C++, Perl, Mason, Java, Jboss, Servlets

Przykład 2: Linux sam w sobie.

Przykład 3: Winsdows + M$ Office (+ .NET).

Ta metryka jest obiektywna dla starych programów również jak i dla nowych
rewelacyjnych języków dedykowanych np. VHDL, STL (dla PLC). 
Jeśli patrzysz na komórki, to mówisz Java, ale zapominasz, że poniżej Javy
jest C, który napędza to cudo. Co więcej to właśnie w C napisane są
kluczowe (ze względu na wydajność) kawałki kodu.

Kolejna metryka:

        Łańcuch utrzymywalności i rozwijalności: Ile procentowo linii kodu 
        z danej aplikacji (biblioteki) w danym języku jest używane po 3, 7 
        i 15 latach funkcjonowania.

Podkreślam w danej aplikacji i w danym języku.

Około 7 lat temu napisałem pierwsze linijki kodu "dla przemysłu" i patrzę z
tego punktu widzenia. 
Na SF powstaje całe dzikie mnóstwo projektów. I co z tego jeśli one równie
szybko giną co powstały.
Co więcej, bardzo ciekawy jest dla mnie Python. Język, który sam dla siebie
nie istnieje, zawsze ciągnie za sobą kogoś z grupy "ciężki kaliber", o tym
należy pamiętać -- uwaga: CPython jest wiodąca produkcją, a zatem język C
dostaje bonusowe punkty chociaż niby nikt go nie lubi i co więcej domyślnie
nie ma w nim GC, a Python ma GC. Zreszta guru Pythona zazwyczaj są guru C.

> To że istnieją niekompetentni programiści, nie jest w żadnym stopniu winą
> istnienia systemów GC.

NIE! Nie jest winą GC. 

GC dla ludzi znających C, C++ i języki bez GC jest istotnie obniżeniem
kosztów w sytuacji kiedy tego trzeba. Miałem osobiście przypadki kiedy
powodowało wzrost kosztów.

Dla ludzi, nie mających pojęcia o tym, może powodować drastyczny wzrost
kosztów w projektach korzystających z zasobów innych niż RAM na skutek nie
przewidzianych katastrof.

Podsumowując -- wiem, że są sytuacje kiedy GC może być wygodne, ale GC to
jest bardzo rozleniwiająca brzytwa -- generalnie goli elegancko, ale słabo
obeznani potrafią poderżnąc sobie i innym gardło. A nalezy pamiętać, że
określony kod jest uzywany zazwyczaj w zakresie 10 - 1000 razy większym
podwzględem zasobów niż przewidziane przez koderów obciążenie.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Dnia Tue, 26 Feb 2008 15:02:01 +0100, Sebastian Nibisz skrobie:
> >> Biorąc pod uwagę rosnącą w ostatnim czasie, popularność języków z
> >> wbudowanym systemem GC, jest coraz mniej obszarów w których pamięć aż tak
> >> bardzo trzeba szanować.
> >
> > A tą ilość/liczbę jak określasz? W liniach kodu, w sztukach sprzedanych
> > instalacji.

> W ilościach nowych projektów tworzonych w języku C++. Od kilka lat, 
> procentowo ta ilość systematycznie spada.

A jakimi statystykami się w tym podpierasz?

Owszem, nie przeczę, nawet na własne oczy ostatnio obserwuję wycofywanie się z
C++ i przechodzenie na Javę, tylko jeden drobny szczegół - aplikacje przestają
być standalowe, a zaczynają być webowe.

Powtarzam jeszcze raz - istnieją statystyki, w których PHP jest na pierwszym
miejscu, w wielu innych PHP stoi bardzo wysoko. Czy świadczy to o tym, że:

 - PHP jest najpopularniejszym (lub prawie najpopularniejszym) językiem
   programowania
 - Aplikacje webowe są najczęściej podejmowanymi projektami oprogramowania

?

Ile znasz firm produkujących oprogramowanie dla urządzeń, komputerów
pokładowych samochodów, samolotów, infrastruktury telekomunikacyjnej, centrów
obliczeniowych, produkcji baz danych itd., które CHWALĄ SIĘ jakiego języka
programowania używają?


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

Nie było i nie jest moim zamysłem, prowadzenie wojny dziejowej z językiem 
C++.
Faktem jest, że restrykcje dotyczące zużycia przez aplikacje pamięci, są 
dzisiaj znacznie mniejsze niż kiedyś.
Faktem jest, że język C++ się praktycznie nie rozwija i że jeżeli taki stan 
się utrzyma, będzie wiódł prym lidera tylko do czasu.
Faktem jest, że istnieją dziedziny w których, podobnie jak obecnie język C, 
język C++ długo nie będzie zagrożony.

Pozdrawiam.

- Bastek -

Dnia Wed, 27 Feb 2008 10:37:56 +0100, Sebastian Nibisz skrobie:
> Nie było i nie jest moim zamysłem, prowadzenie wojny dziejowej z językiem 
> C++.
> Faktem jest, że restrykcje dotyczące zużycia przez aplikacje pamięci, są 
> dzisiaj znacznie mniejsze niż kiedyś.

To prawda, ale dotyczy to tylko części rynku oprogramowania. Dotyczy aplikacji
standalowych oraz aplikacji webowych, nie dotyczy jednak aplikacji na
systemach wbudowanych.

> Faktem jest, że język C++ się praktycznie nie rozwija i że jeżeli taki stan 
> się utrzyma, będzie wiódł prym lidera tylko do czasu.

Już go i tak nie wiedzie. Niestety jak na razie w wielu zastosowaniach jak na
razie jedynymi sensownymi alternatywami dla tego języka wydają się być D i C#.
Zastępowanie C++ jednak tym językom niespecjalnie idzie, a ostatnie dodatki do
C# umacniają go akurat nie w tych obszarach, w których C++ rządzi.

> Faktem jest, że istnieją dziedziny w których, podobnie jak obecnie język C, 
> język C++ długo nie będzie zagrożony.

I o tym właśnie mówię - a co gorsza, są to prężnie rozwijające się gałęzie
produkcji oprogramowania, w przeciwieństwie do aplikacji standalowych.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

> Dla ustalenia uwagi. Nie mam nic przeciwko SGCL ani Śmieciuchowi, ani 
> innemu
> GC dla C++ i C.
>
> Podkreślę moje stanowisko.

Ok, ale nawet gdybyś był przeciwko, to masz do tego prawo i z pewnością 
pretensji bym o to do Ciebie nie miał.

> Mając to w pamięci. Kiedy mówisz o zasobach w językach z GC używasz wzorca
> projektowego "język C", czyli jezeli coś ma być napisane
> alokując/zwalniając zasoby inne niż RAM mówisz: "Piszemy jak w C!".
> To jest użycie wzorca projektowego "język C".
>
> Teraz postaw się w sytuacji (która mnie dotknęła) wytłumacz to 
> przeciętnemu
> koderowi języka z GC (i tylko jednego języka, bo tacy jednojęzykowcy są
> tanii).
>
> Co mu powiesz? Wyłożysz mu C? Ile to bedzie kosztować? Szkolenie z podstaw 
> C
> też kosztuje. Ja chętnie szkolę, ale czy to jest tanie -- nie sądzę?
> Jest tańsze niż wykłady firm consultingowych, ale nadal nie jest tanie.

Ale to świadczy jedynie o tym, że koder jest niedouczony. Nawet ucząc się 
tylko języka z GC, koder powinien sie dowiedzieć co to jest GC i do czego 
tego wykorzystywać nie można.

>> To że istnieją niekompetentni programiści, nie jest w żadnym stopniu winą
>> istnienia systemów GC.
>
> NIE! Nie jest winą GC.
>
> GC dla ludzi znających C, C++ i języki bez GC jest istotnie obniżeniem
> kosztów w sytuacji kiedy tego trzeba. Miałem osobiście przypadki kiedy
> powodowało wzrost kosztów.
>
> Dla ludzi, nie mających pojęcia o tym, może powodować drastyczny wzrost
> kosztów w projektach korzystających z zasobów innych niż RAM na skutek nie
> przewidzianych katastrof.
>
> Podsumowując -- wiem, że są sytuacje kiedy GC może być wygodne, ale GC to
> jest bardzo rozleniwiająca brzytwa -- generalnie goli elegancko, ale słabo
> obeznani potrafią poderżnąc sobie i innym gardło. A nalezy pamiętać, że
> określony kod jest uzywany zazwyczaj w zakresie 10 - 1000 razy większym
> podwzględem zasobów niż przewidziane przez koderów obciążenie.

j/w

Pozdrawiam.

- Bastek - 

>> Faktem jest, że restrykcje dotyczące zużycia przez aplikacje pamięci, są
>> dzisiaj znacznie mniejsze niż kiedyś.
>
> To prawda, ale dotyczy to tylko części rynku oprogramowania. Dotyczy 
> aplikacji
> standalowych oraz aplikacji webowych, nie dotyczy jednak aplikacji na
> systemach wbudowanych.

Z tego co zauważyłem, to i w niektórych systemach wbudowanych znika powoli 
problem z ilościa dostępnej pamięci.

>> Faktem jest, że język C++ się praktycznie nie rozwija i że jeżeli taki 
>> stan
>> się utrzyma, będzie wiódł prym lidera tylko do czasu.
>
> Już go i tak nie wiedzie. Niestety jak na razie w wielu zastosowaniach jak 
> na
> razie jedynymi sensownymi alternatywami dla tego języka wydają się być D i 
> C#.
> Zastępowanie C++ jednak tym językom niespecjalnie idzie, a ostatnie 
> dodatki do
> C# umacniają go akurat nie w tych obszarach, w których C++ rządzi.

Język D nie jest na chwilę obecną zbyt atrakcyjny, gdyż nie posiada wsparcia 
w postaci ciekawych bibliotek.
Język C# wraz z jego bibliotekami byłby silnym rywalem C++, gdyby nie był 
tak uwiązany do jednej platformy systemowej. Na chwilę obecną, 
(nie)nieprzenośność aplikacji napisanych w tym języku, jest jednym z 
głównych powodów niższej jego popularności.

>> Faktem jest, że istnieją dziedziny w których, podobnie jak obecnie język 
>> C,
>> język C++ długo nie będzie zagrożony.
>
> I o tym właśnie mówię - a co gorsza, są to prężnie rozwijające się gałęzie
> produkcji oprogramowania, w przeciwieństwie do aplikacji standalowych.

Tak, ale tutaj niewiele sie w tej materii zmieni. Znam firmy z gałęzi 
przemysłu energetycznego, które do dzisiaj rozwijają oraz sprzedają 
programy, napisane w zamierzchłych czasach dla DOS.

Pozdrawiam.

- Bastek -

Sebastian Nibisz wrote:
>> Co mu powiesz? Wyłożysz mu C? Ile to bedzie kosztować? Szkolenie z 
>> podstaw C
>> też kosztuje. Ja chętnie szkolę, ale czy to jest tanie -- nie sądzę?
>> Jest tańsze niż wykłady firm consultingowych, ale nadal nie jest tanie.
> 
> Ale to świadczy jedynie o tym, że koder jest niedouczony. Nawet ucząc 
> się tylko języka z GC, koder powinien sie dowiedzieć co to jest GC i do 
> czego tego wykorzystywać nie można.

Ile % koderów piszacych wylacznie w PHP, C#, Java ma o tym pojecie ?
Sadze ze mniej niz 1%.

Ostatnio prowadzilem dyskuje tj tlumaczylem koledze ktory od lat pisze 
apliakcje webowe w PHP i jest dobry w tym co robi, na czym polegaja 
roznice przekazania paramteru przez referencje const referencje wskaznik 
przez wartosc.

Sedno w tym ze wiekszosc nie ma o tym pojecia a takie slowa jak stos czy 
sterta to szyszeli ze sa.

Ich niedouczenie wynika wlasnie z tego faktu iz oni nie musza tego 
wiedziec aby napisac program, bo robi to za nich automat.

Czlowiek ma taka nature ze jak dostanie zupe w proszku to nie bedzie 
wnikac jak to sie dzieje ze ona tam sie znalazla tylko podswiadomie 
bedzie chcial sie ograniczyc do poznania wiedzy jak jak przyzadzic aby 
moc ja zjesc.

-- 

Artur

On 27 Lut, 14:39, "Sebastian Nibisz" <EB...@poczta.onet.pl> wrote:

> >> Faktem jest, że restrykcje dotyczące zużycia przez aplikacje pamięci, są
> >> dzisiaj znacznie mniejsze niż kiedyś.
>
> > To prawda, ale dotyczy to tylko części rynku oprogramowania. Dotyczy
> > aplikacji
> > standalowych oraz aplikacji webowych, nie dotyczy jednak aplikacji na
> > systemach wbudowanych.
>
> Z tego co zauważyłem, to i w niektórych systemach wbudowanych znika powoli
> problem z ilościa dostępnej pamięci.

Nie rozumiem tego powyżej.
Co to znaczy, że gdzieś znika problem z ilością pamięci? Nigdzie nie
znika. Kupuje się większy hardware po to, żeby na nim puszczać większy
software. Problemu pamięci to nie rozwiązuje, jedynie pozwala dalej
ślizgać się po krawędzi. Ja problemy z pamięcią widzę zarowno na
płytach z 64MB jak i z <put-your-favorite-number>GB, bo po prostu
chodzą na nich różne systemy, które mają różne wymagania. Tak samo nie
ma sensu mówić, że autobusy rozwiązują problem samochodów osobowych z
ilością miejsc dla pasażerów. Kto stał w tłoku w szczycie zrozumie.
Inaczej: dla każdej ilości pamięci istnieją programy, które się w niej
nie mieszczą. Problem nigdzie nie "znika". Co więcej, większe programy
są pisane również po to, żeby wykorzystać okazje stwarzane przez
większy hardware. Kręcimy się tak od kilku dekad - każdego roku ktoś z
radością ogłasza, że problem pamięci lub CPU lub dysków itd. "znika",
bo oto np. firma X wyprodukowała dysk twardy o zawrotnej pojemności
80MB (megabajtów), i teraz ludzie w ekstazie nie mają pomysłu, co tam
trzymać. Całą walizkę dyskietek 5.25" można tam zmieścić. Łał.

Bilu też kiedyś myślał, że 640kB każdemy wystarczy - a dzisiaj Visty
poniżej 2GB nie ma po co nawet uruchamiać.

Pytam się więc - co to znaczy, że problem z pamięcią znika?

> >> Faktem jest, że język C++ się praktycznie nie rozwija

Język C++ rozwija się na dwóch płaszczyznach, z dwoma różnymi
prędkościami.
Jedna płaszczyzna to definicja języka, czyli standard - tempo rozwoju
to jedna iteracja na dekadę. Czy to wolno? Moim zdaniem akurat -
przemysł ledwo nadąża z wymianą kompilatorów w tym tempie. Hint:
przemysł to nie jest koleś z laptopem i Ubuntu aktualizowanym z
automatu.
Druga płaszczyzna to biblioteki i narzędzia orbitujące (np. generatory
kodu). To się rozwija dużo szybciej i spokojnie pozwala na
przedłużenie życia C++ w dowolnym obszarze. Hint: nie potrzeba było
zmieniać standardu, żeby pojawił się przykładowy Boost.

> >> i że jeżeli taki
> >> stan
> >> się utrzyma, będzie wiódł prym lidera tylko do czasu.

C++ nie wiedzie prymu lidera, bo nie musi. To jest język, który
świetnie się sprawdza w wymagających zastosowaniach i nie musi być na
topie popularności we wszelkich innych.

Wracając do GC - sam GC nie jest problemem. Problemem jest sytuacja, w
której twórca języka po wrzuceniu do niego GC otrzepuje ręce i
oznajmia, że wszystkie problemy rozwiązał. Efekty takiej
amatorszczyzny widać w Javie, gdzie np. w tutorialu dla początkujących
co chwila jest wołami przypominane, jakie to ważne, żeby zawsze
zamykać strumienie i inne takie. I to jeszcze w odpowiedniej
kolejności. W XXI wieku to jest po prostu *żenujące* (chociaż
początkujący czytelnicy akurat tego nie zauważą), niezależnie od
dostępnych gigabajtów.
To jest też dowód na to, że w Javie GC więcej problemów pozostawił,
niż rozwiązał.

Dodanie GC do C++ może przedłużyć mu życie w wielu obszarach. A
ponieważ wiadomo, że tak się właśnie stanie, to nie ma po co ogłaszać
zgonu.
Co ciekawe, dodanie GC do C++ jest dużo łatwiejsze, niż dodanie
sensownego systemu zarządzania czasem życia obiektów w Javie. Nie
podejmuję się prorokować, jak będą wyglądały rankingi języków za ~5
lat - ale wiem, że będą ciekawe.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Seweryn Habdank-Wojewódzki wrote:
>>>> Ułatwić, czyli skrócić czas powstawania aplikacji a jak wiadomo czas to
>>>> pieniądź.
>>>
>>> O tak to ma sens, ale wszystko w ten sam sposób moge sprowadzić do
>>> pieniędzy. Co więcej teorię przeciwną również.
>> 
>> Ale po co sobie utrudniac życie, dla frajdy?
> 
> Dla ustalenia uwagi. Nie mam nic przeciwko SGCL ani Śmieciuchowi, ani
> innemu GC dla C++ i C.
> 
> Podkreślę moje stanowisko.
> 
> Zarówno Ty jak i Pan Karpierz oraz wszyscy lokalni Ajatollahowie GC :-)
> znają i umieją pisać w C, C++ lub innych brzydkich językach !!!
> 
> Mając to w pamięci. Kiedy mówisz o zasobach w językach z GC używasz wzorca
> projektowego "język C", czyli jezeli coś ma być napisane
> alokując/zwalniając zasoby inne niż RAM mówisz: "Piszemy jak w C!".
> To jest użycie wzorca projektowego "język C".

Nonsens.

Piszemy jak w każdym normalnym języku. Zasoby istotne się po sobie zwalnia i
są do tego narzędzia właściwe (czyli with / using, try finally, itd).

Destruktory z C++ są rozwiązaniem cienkim. Cienkim z jednego, prozaicznego,
ale kluczowego(!), powodu. Z poziomu destruktora nie da się poinformować o
błędzie (poza wywaleniem całego programu, jakże wychwalanemu przez
astronautów i ajatollachów C++, ale w Rzeczywistym Świecie(tm) zazwyczaj
Kompletnie Do Dupy(tm)).

> Teraz postaw się w sytuacji (która mnie dotknęła) wytłumacz to
> przeciętnemu koderowi języka z GC (i tylko jednego języka, bo tacy
> jednojęzykowcy są tanii).
> 
> Co mu powiesz?

Powiem mu, że jak plik otworzył, to musi dopilnować jego zamknięcia. Cała
filozofia.


>>>> Biorąc pod uwagę rosnącą w ostatnim czasie, popularność języków z
>>>> wbudowanym systemem GC, jest coraz mniej obszarów w których pamięć aż
>>>> tak bardzo trzeba szanować.
>>>
>>> A tą ilość/liczbę jak określasz? W liniach kodu, w sztukach sprzedanych
>>> instalacji.
>> 
>> W ilościach nowych projektów tworzonych w języku C++. Od kilka lat,
>> procentowo ta ilość systematycznie spada.
> 
> Aha. No ja na to patrzę przez inny pryzmat.
> 
> Metryka używalności:
> 
>         max ( liczba użytkowników, liczba instalacji )
> 

Słaba to metryka. Co z tego, że coś ma miliard użytkowników, skoro żyje z
tego jeden człowiek (zostało napisane raz i już sobie jest). Dużo ciekawsza
jest metryka w czym większy procent ludzi pisze. A tu C++ jedzie w dół,
coraz ostrzej.

BTW. W 6 na 7 podanych przez ciebie przypadkach mowa jest o C a nie C++.
Z tego wynika jedno -- o ile C zostanie, bo zapotrzebowanie na "przenośny
assembler" jest i w przewidywalnej przyszłości będzie, to C++ nie ma
takiej "z góry upatrzonej pozycji na którą może się wycofać".


>> To że istnieją niekompetentni programiści, nie jest w żadnym stopniu winą
>> istnienia systemów GC.
> 
> NIE! Nie jest winą GC.
> 
> GC dla ludzi znających C, C++ i języki bez GC jest istotnie obniżeniem
> kosztów w sytuacji kiedy tego trzeba. Miałem osobiście przypadki kiedy
> powodowało wzrost kosztów.

Te przypadki są statystycznie nieisotne.

> Dla ludzi, nie mających pojęcia o tym, może powodować drastyczny wzrost
> kosztów w projektach korzystających z zasobów innych niż RAM na skutek nie
> przewidzianych katastrof.

Jakież to katastrofy są nieprzewidziane? Brak close łatwo zauważyć.


> Podsumowując -- wiem, że są sytuacje kiedy GC może być wygodne, ale GC to
> jest bardzo rozleniwiająca brzytwa -- generalnie goli elegancko, ale słabo
> obeznani potrafią poderżnąc sobie i innym gardło. A nalezy pamiętać, że
> określony kod jest uzywany zazwyczaj w zakresie 10 - 1000 razy większym
> podwzględem zasobów niż przewidziane przez koderów obciążenie.

To też nie jest prawda.


pzdr
\SK
-- 
"Never underestimate the power of human stupidity" -- L. Lang

Użytkownik "Artur Bać" <artur_nospam@ebasoft.com.pl> napisał:

>> Ale to świadczy jedynie o tym, że koder jest niedouczony. Nawet ucząc się 
>> tylko języka z GC, koder powinien sie dowiedzieć co to jest GC i do czego 
>> tego wykorzystywać nie można.
>
> Ile % koderów piszacych wylacznie w PHP, C#, Java ma o tym pojecie ?
> Sadze ze mniej niz 1%.

Dla mnie pierwszy lepszy Ayatollah C++ jest tym czym ten
wysmiewany(?) przez Ciebie koder Javy czy C#.
Dlaczego ? Ano dlatego ze Ayatollah nawet nie slyszal co to jest np:
cal by name czy call by need
Jest wiec zwyczajnie niedouczonym koderem.

> Ostatnio prowadzilem dyskuje tj tlumaczylem koledze ktory od lat pisze 
> apliakcje webowe w PHP i jest dobry w tym co robi, na czym polegaja 
> roznice przekazania paramteru przez referencje const referencje wskaznik 
> przez wartosc.

Bo to glupie.
Do dzisiaj nie moge sie nadziwic jak mozna wprowadzac tak idiotyczne
slowo jak const zamiast np in.
Natomiast wskazniki ?
A _po co_ w ogole potrzebne wskazniki jako parametry, jesli sa
rerefencje i (tfu) const referencje ?
Chyba po to aby utrudniac zycie.

> Sedno w tym ze wiekszosc nie ma o tym pojecia a takie slowa jak stos czy 
> sterta to szyszeli ze sa.

I bardzo dobrze !
Po jaka cholere programiscie 'wiedza' gdzie jest umieszczana zmienna lokalna 
?
Jemu wystarczy wiedza ze jest dostepna jedynie w jej scope _i tyle_.
Poza tym wskaz mi _gdzie_ stos procesora wystepuje w standardzie C ?

> Ich niedouczenie wynika wlasnie z tego faktu iz oni nie musza tego 
> wiedziec aby napisac program, bo robi to za nich automat.

No wlasnie !
I o to chodzi !

AK

Sebastian Kaliszewski wrote:
>> Teraz postaw się w sytuacji (która mnie dotknęła) wytłumacz to
>> przeciętnemu koderowi języka z GC (i tylko jednego języka, bo tacy
>> jednojęzykowcy są tanii).
>>
>> Co mu powiesz?
> 
> Powiem mu, że jak plik otworzył, to musi dopilnować jego zamknięcia. Cała
> filozofia.

Przyklad z niby bardziej odpornego C# od javy, pokazujacy jak bardzo nie 
swiadomosc detali lub poleganie na automacie krzywdzi i jak latwo mozna 
pasc ofiara automatow i GC.

Sam w to wpadlem swego czasu i niestety zabolalo, aplikacja byla juz 
wersja produkcyjna i zawiodla w momncie gdy bylo ztroche a pozno na 
zabawe z kodem.

void Cos() {
  FileStream x = new ....
  using( BinaryWriter br = new BinaryReader (x) ) {
   	//blabla
  }
}

Pytanie 1:
Kiedy fs zwolni zasoby 'handle' do plikow.

a) po zakonczeniu scope using
b) po zakonczeniu scope Cos
c) po zakonczeniu programu lub gdy gc sie zlituje tj niewiadomo kiedy.

odpowiedz prawidlowa
c) br oleje fs, a destruktor fs niewiadomo kiedy bedzie wykonany.
dokladnie dzieje sie tak chyba z tego co rozumie iz dopuki ostatnia 
referencja nie zginie doputy wszelkie wywolania Dispose() zostana 
zignorowane a tu mamy az 2 kopie jedna posiada BianryWriter a druga jest 
zadeklarowana w obrebie metody.
Tak wiec zycze powodzenia z wolaniem metody Close na BianryWriter.


FaileStream z NET ma implementacje:

public virtual void Close()
{
     this.Dispose(true);
     GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
     if (disposing && (this._asyncActiveEvent != null))
     {
         this._CloseAsyncActiveEvent(Interlocked.Decrement(ref 
this._asyncActiveCount));
     }
}
private void _CloseAsyncActiveEvent(int asyncActiveCount)
{
     if ((this._asyncActiveEvent != null) && (asyncActiveCount == 0))
     {
         this._asyncActiveEvent.Close();
         this._asyncActiveEvent = null;
     }
}



Pytanie 2:
Kiedy progrmaista sie o tym zorientuje
a) mozliwe ze nigdy
b) gdy aplikacja sypnie sie u klienta
c) w trakcie testow
d) ciezko powiedziec, wszystkie mozliwosci sa relane

najblizsza prawdy
d) a jak sie sypnie to komunikat exception wyzuci sie z bardzo 
idiotycznym problemem kernela32.

W tak prostych przypadkach siadmosc kiedy zasoby sa zwalniane jest 
przydatna bo pozwala zrozumiec istote problemu.

Dnia 27-02-2008, Śr o godzinie 20:13 +0100, Artur Bać pisze:

> c) po zakonczeniu programu lub gdy gc sie zlituje tj niewiadomo kiedy.
> 
> odpowiedz prawidlowa
> c) br oleje fs, a destruktor fs niewiadomo kiedy bedzie wykonany.

Nieprawda.

Nie mam pod ręką dokumentacji do .NET, ale ze źródeł Mono
mono-1.2.6/mcs/class/corlib/System.IO/BinaryWriter.cs:

                public virtual void Close() {
                        Dispose (true);
                }

                void IDisposable.Dispose() {
                        Dispose (true);
                }

                protected virtual void Dispose (bool disposing)
                {
                        if (disposing && OutStream != null)
                                OutStream.Close();
                        
                        buffer = null;
                        m_encoding = null;
                        disposed = true;
                }

> dokladnie dzieje sie tak chyba z tego co rozumie iz dopuki ostatnia 
> referencja nie zginie doputy wszelkie wywolania Dispose() zostana 
> zignorowane

Nic podobnego. Dispose jest zwykłą metodą, a using woła Dispose.
Nie ma żadnego liczenia referencji.

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

Marcin ‘Qrczak’ Kowalczyk wrote:
> Dnia 27-02-2008, Śr o godzinie 20:13 +0100, Artur Bać pisze:
> 
>> c) po zakonczeniu programu lub gdy gc sie zlituje tj niewiadomo kiedy.
>>
>> odpowiedz prawidlowa
>> c) br oleje fs, a destruktor fs niewiadomo kiedy bedzie wykonany.
> 
> Nieprawda.

> Nic podobnego. Dispose jest zwykłą metodą, a using woła Dispose.
> Nie ma żadnego liczenia referencji.
> 

BinryWriter wola swoje Dispose ktore wola Dispose FaileStream
Nie bede polemizowal z kodem mono , wkleilem kod filestream z NET
uzyskany NET reflektorem i widac tam liczenie referencji i igonorowanie 
Close() samego FileStream. W tym wypdaku wolanie Close BinaryWriter nic 
nie zmienia.

A pozatym szukalem powodu exception przez pare godzin mowiacego o 
przekroczeniu ilosci handle do plikow rzucenego przez kernel ...

Witam

Sebastian Kaliszewski wrote:

>> Co mu powiesz?
> 
> Powiem mu, że jak plik otworzył, to musi dopilnować jego zamknięcia. Cała
> filozofia.

A on zapyta: Czemu zamykać, jeśli "sam się zamknie" [w domyśle "gdzieś
kiedyś"].

Po za tym, wspomniałeś wcześniej obłędach. Jak zamykasz pliki w Javie w
sytuacjach awaryjnych? To samo masz w Javie problem z wyjkątkami i
wykonaniem zamknięcia pliku. Musisz przeanalizować wszystkie możliwe
ścieżki wykonanania. To w C i C++ jest naturalne, w Javie jest to extra
umiejętność. W każdym razie mój testwy koder Java miał kłopoty z taką
analizą. Może to moja wina, że skomplikowałem zadanie.
 
> Słaba to metryka. Co z tego, że coś ma miliard użytkowników, skoro żyje z
> tego jeden człowiek (zostało napisane raz i już sobie jest). Dużo
> ciekawsza jest metryka w czym większy procent ludzi pisze. A tu C++ jedzie
> w dół, coraz ostrzej.

Tak wiem, ta metryka jest bardzo dobra dla Pythona.
 
> BTW. W 6 na 7 podanych przez ciebie przypadkach mowa jest o C a nie C++.
> Z tego wynika jedno -- o ile C zostanie, bo zapotrzebowanie na "przenośny
> assembler" jest i w przewidywalnej przyszłości będzie, to C++ nie ma
> takiej "z góry upatrzonej pozycji na którą może się wycofać".

Nie ma to znaczenia. Ja i tak pozostanę Ajatollahem C++. A dyskusja dotyczy
także C bo ten język RÓWNIEŻ nie ma GC.

Pozdrawiam. 

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

> void Cos() {
>  FileStream x = new ....
>  using( BinaryWriter br = new BinaryReader (x) ) {
>   //blabla
>  }
> }
>
> Pytanie 1:
> Kiedy fs zwolni zasoby 'handle' do plikow.

Kiedy GC przyjdzie na to ochota. Nie zawołałes Dispose dla obiektu 
FileStream, tak więc skazałeś się na łaskę systemu GC.

Powinno byc tak:

using (FileStream fs = new FileStream(...))
{
    using (BinaryWriter br = new BinaryWriter(fs))
    {
        // blabla
    }
}

Pozdrawiam.

- Bastek - 

Sebastian Nibisz wrote:
> Kiedy GC przyjdzie na to ochota. Nie zawołałes Dispose dla obiektu 
> FileStream, tak więc skazałeś się na łaskę systemu GC.
> 
> Powinno byc tak:
> 

To akurat wiem.

Ale irytujace w tym jest to ze wszystkie referencje musza zawolac 
Close/Dispose inaczej zasoby -> handle do plikow nei sa zwalniane.

I obawiam sie ze nie jeden juz sie nacial na to.

Dnia 27-02-2008, Śr o godzinie 21:19 +0100, Artur Bać pisze:

> wkleilem kod filestream z NET
> uzyskany NET reflektorem i widac tam liczenie referencji i igonorowanie 
> Close() samego FileStream.

http://msdn2.microsoft.com/en-us/library/system.io.filestream.dispose.aspx

"Dispose() - Infrastructure. Releases all resources used by the Stream.
(Inherited from Stream.)"

Nie ma mowy o jakimś zliczaniu referencji.

Implementacja w Mono:

        ~FileStream ()
        {
                Dispose (false);
        }

#if NET_2_0
        protected override void Dispose (bool disposing)
#else
        protected virtual void Dispose (bool disposing)
#endif
        {
                if (handle != MonoIO.InvalidHandle) {
                        FlushBuffer ();

                        if (owner) {
                                MonoIOError error;

                                MonoIO.Close (handle, out error);
                                if (error != MonoIOError.ERROR_SUCCESS) {
                                        // don't leak the path information for isolated storage
                                        string fname = (anonymous) ? Path.GetFileName (name) : name;
                                        throw MonoIO.GetException (fname, error);
                                }

                                handle = MonoIO.InvalidHandle;
                        }
                }

                canseek = false;
                access = 0;
                if (disposing) {
                        buf = null;
                }
        }

Jak widać, nie ma żadnego zliczania referencji (pole "owner" z reguły
jest true, jest false chyba tylko dla stdin/stdout/stderr).

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

Seweryn Habdank-Wojewódzki wrote:

> A on zapyta: Czemu zamykać, jeśli "sam się zamknie" [w domyśle "gdzieś
> kiedyś"].

Dobre , usmialem sie ale masz w tym duzo racji.
Typowe myslenie przecierz ja juz nie korzystam z tego, 'wali mnie to'.

Dnia 27-02-2008, Śr o godzinie 21:28 +0100, Seweryn Habdank-Wojewódzki
pisze:

> > Powiem mu, że jak plik otworzył, to musi dopilnować jego zamknięcia. Cała
> > filozofia.
> 
> A on zapyta: Czemu zamykać, jeśli "sam się zamknie" [w domyśle "gdzieś
> kiedyś"].

Odpowiesz: żeby nie marnować uchwytów pliku, których system operacyjny
nie pozwala mieć naraz zbyt wiele.

Naprawdę nie widzę problemu.

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

>> Powiem mu, że jak plik otworzył, to musi dopilnować jego zamknięcia. Cała
>> filozofia.
>
> A on zapyta: Czemu zamykać, jeśli "sam się zamknie" [w domyśle "gdzieś
> kiedyś"].

Auto na noc też pewnie zostawia z otwartymi na roścież dżwiami. W nocy 
często wieje, to mu sie zamkną.

> Po za tym, wspomniałeś wcześniej obłędach. Jak zamykasz pliki w Javie w
> sytuacjach awaryjnych? To samo masz w Javie problem z wyjkątkami i
> wykonaniem zamknięcia pliku. Musisz przeanalizować wszystkie możliwe
> ścieżki wykonanania. To w C i C++ jest naturalne, w Javie jest to extra
> umiejętność. W każdym razie mój testwy koder Java miał kłopoty z taką
> analizą. Może to moja wina, że skomplikowałem zadanie.

W C# do tego służy blok finally.

Pozdrawiam.

- Bastek - 

On 27 Lut, 19:26, "Adam Karpierz" <karpierz@_NOSPAM_python.pl> wrote:

> Do dzisiaj nie moge sie nadziwic jak mozna wprowadzac tak idiotyczne
> slowo jak const zamiast np in.

const nie jest "zamiast" - te dwie rzeczy rozwiązują różne problemy,
tylko częściowo się pokrywające.
Ale możesz się dziwić dalej.

> Natomiast wskazniki ?
> A _po co_ w ogole potrzebne wskazniki jako parametry, jesli sa
> rerefencje i (tfu) const referencje ?
> Chyba po to aby utrudniac zycie.

A może po to, żeby można było przekazać NULL?
Albo po to, żeby można było przekazać wskaźnik całkowicie oderwany od
typu (void)?
Albo może po to, żeby można było przekazać wskaźnik do czegoś, co nie
ma sensu jako wartość (np. wskaźnik do funkcji) i dlatego nie dałoby
się zrobić do tego referencji?

BTW - napisałeś tu niedawno, że Ada jest wzorem języków imperatywnych.
Wnioskuję, że nie słyszałeś o tym, że w Adzie wskaźniki mogą być
parametrami podprogramów. Sam sobie odpowiedz, po co.

> Po jaka cholere programiscie 'wiedza' gdzie jest umieszczana zmienna lokalna
> ?
> Jemu wystarczy wiedza ze jest dostepna jedynie w jej scope _i tyle_.

Przecież chodzi o to samo. Pojęcie stosu jest sztuczne, co sam nawet
(!) zauważyłeś:

> Poza tym wskaz mi _gdzie_ stos procesora wystepuje w standardzie C ?

No właśnie. Stos to pojęcie potoczne opisujące model życia obiektów.
Zagnieżdżanie zakresów jest modelowane przez wydłużający się "stos"
obiektów.
Jeżeli ktoś mówi "zmienna x jest na stosie" to w ten sposób opisuje
jedynie relację jaka zachodzi pomiędzy czasem życia tej zmiennej a
czasem życia innych zmiennych z innych zakresów.

> > Ich niedouczenie wynika wlasnie z tego faktu iz oni nie musza tego
> > wiedziec aby napisac program, bo robi to za nich automat.
>
> No wlasnie !
> I o to chodzi !

Powodzenia.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Użytkownik "Seweryn Habdank-Wojewódzki" <shw_mail@wp.pl> napisał:

> Po za tym, wspomniałeś wcześniej obłędach.
> Jak zamykasz pliki w Javie w sytuacjach awaryjnych?
> To samo masz w Javie problem z wyjkątkami i
> wykonaniem zamknięcia pliku. Musisz przeanalizować wszystkie możliwe
> ścieżki wykonanania.

A co to Pan Kolega finally nie uzywa ?
'Przyzwyczajenie' z C++ ?

AK 

Przywracasz wiare w programistow C++ ;)

AK 

Witam

Adam Karpierz wrote:

> Użytkownik "Seweryn Habdank-Wojewódzki" <shw_mail@wp.pl> napisał:
> 
>> Po za tym, wspomniałeś wcześniej obłędach.
>> Jak zamykasz pliki w Javie w sytuacjach awaryjnych?
>> To samo masz w Javie problem z wyjkątkami i
>> wykonaniem zamknięcia pliku. Musisz przeanalizować wszystkie możliwe
>> ścieżki wykonanania.
> 
> A co to Pan Kolega finally nie uzywa ?

A "finally" zwalnia z myślenia?
Finally samo się nie napisze!

Napisanie finally przecież kosztuje 2 linie kodu, zapomniał Pan o tym?

> 'Przyzwyczajenie' z C++ ?

W C++ RAII w pewnych sytuacjach pomaga i nie trzeba pisać "finally".
Smart_ptr sam zawoła destruktor kiedy potrzeba -- czysta oszczędność.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Witam

Marcin ?Qrczak? Kowalczyk wrote:

>> A on zapyta: Czemu zamykać, jeśli "sam się zamknie" [w domyśle "gdzieś
>> kiedyś"].
> 
> Odpowiesz: żeby nie marnować uchwytów pliku, których system operacyjny
> nie pozwala mieć naraz zbyt wiele.
> 
> Naprawdę nie widzę problemu.

Ja też nie. Ale są tacy co widzą :-). BTW używając wzorca
projektowego "język C" nie muszę gadać więcej niż powiedziałem.

Pozdrawiam. 

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Użytkownik "Seweryn Habdank-Wojewódzki" <shw_mail@wp.pl> napisał:

>> A co to Pan Kolega finally nie uzywa ?
>
> A "finally" zwalnia z myślenia?
> Finally samo się nie napisze!
>
> Napisanie finally przecież kosztuje 2 linie kodu, zapomniał Pan o tym?

Panie Wojewodzki, niech mnie Pan nie oslabia :)
Prosciej w/g Pana przeanalizowac wszytskie
sciezki wywolania (bo o tym Pan pisal) niz uzyc finally ?
O tempora o mores !

AK

Seweryn Habdank-Wojewódzki wrote:
>>> Co mu powiesz?
>> 
>> Powiem mu, że jak plik otworzył, to musi dopilnować jego zamknięcia. Cała
>> filozofia.
> 
> A on zapyta: Czemu zamykać, jeśli "sam się zamknie" [w domyśle "gdzieś
> kiedyś"].

A mu odpowiem: bo może otworzyć najwyżej N (N jest małe) plików. 


> Po za tym, wspomniałeś wcześniej obłędach. Jak zamykasz pliki w Javie w
> sytuacjach awaryjnych?

O finally słyszałeś?

> To samo masz w Javie problem z wyjkątkami i 
> wykonaniem zamknięcia pliku. Musisz przeanalizować wszystkie możliwe
> ścieżki wykonanania.

Ależ skąd.

> To w C i C++ jest naturalne, w Javie jest to extra 
> umiejętność.

Ależ skąd. 

BTW. przyjrzałem się bliżej tej naturalności z C++ i wyszło, że w 95% używam
jej do tego, by obejść brak standardowego GC albo brak konstrukcji typu
using / with / finally (odpowiednio C# / Python / Java & C# & Python).


> W każdym razie mój testwy koder Java miał kłopoty z taką 
> analizą. Może to moja wina, że skomplikowałem zadanie.
>  
>> Słaba to metryka. Co z tego, że coś ma miliard użytkowników, skoro żyje z
>> tego jeden człowiek (zostało napisane raz i już sobie jest). Dużo
>> ciekawsza jest metryka w czym większy procent ludzi pisze. A tu C++
>> jedzie w dół, coraz ostrzej.
> 
> Tak wiem, ta metryka jest bardzo dobra dla Pythona.

To nie ma znaczenia dla czego jest dobra. Znaczenie ma dla kogo jest dobra.
A jest dobra np. dla producentów rozmaitych narzędzi wokołojęzykowych,
bibliotek itd.

>> BTW. W 6 na 7 podanych przez ciebie przypadkach mowa jest o C a nie C++.
>> Z tego wynika jedno -- o ile C zostanie, bo zapotrzebowanie na "przenośny
>> assembler" jest i w przewidywalnej przyszłości będzie, to C++ nie ma
>> takiej "z góry upatrzonej pozycji na którą może się wycofać".
> 
> Nie ma to znaczenia. Ja i tak pozostanę Ajatollahem C++. A dyskusja
> dotyczy także C bo ten język RÓWNIEŻ nie ma GC.

To może dotyczy również assemblera, Fortha, Fortranu czy czego tam jeszcze,
bo one również nie mają standardowego GC? Nie naciągaj.

-- 
"Never underestimate the power of human stupidity" -- L. Lang

Sebastian Kaliszewski wrote:
> Destruktory z C++ są rozwiązaniem cienkim. Cienkim z jednego, prozaicznego,
> ale kluczowego(!), powodu. Z poziomu destruktora nie da się poinformować o
> błędzie 

Czy możesz podać jakiś spektakularny przykład, gdzie taka potrzeba 
występuje?

JD

Dnia Sun, 2 Mar 2008 13:50:55 +0100, the_foe skrobie:
> Dnia Wed, 27 Feb 2008 06:42:29 -0800 (PST), Maciej Sobczak napisał(a):

> > Bilu też kiedyś myślał, że 640kB każdemy wystarczy - a dzisiaj Visty
> > poniżej 2GB nie ma po co nawet uruchamiać.

> nie to ze jestem milosnikiem Billa, ale prawda jest ze nigdy takich rzeczy
> nie mowil, a sam zaprzecza ze nawet kiedykolwiek o tym pomyslal. 

Bo tego nie mówił Bill Gates, tylko Peter Norton.

Nb. ten facet słynie z jeszcze ciekawszych wypowiedzi, np. w dawniejszych
czasach powątpiewał w istnienie wirusów.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

Jedrzej Dudkiewicz wrote:
>> Destruktory z C++ są rozwiązaniem cienkim. Cienkim z jednego,
>> prozaicznego, ale kluczowego(!), powodu. Z poziomu destruktora nie da się
>> poinformować o błędzie
> 
> Czy możesz podać jakiś spektakularny przykład, gdzie taka potrzeba
> występuje?

Oczywiście:

Np. klasa obsługi (zapisywalnego) pliku z buforowaniem. Przy zamykaniu robi
się opróżnienie buforów, które oczywiście może się nie udać. Destruktor
jest tu rozwiązaniem cienkim.


Konstrukcja using (z C#) czy with: z Pythona jest zdecydowanie lepsza. Bo
Close() może rzucić wyjątek i ten wyjątek można normalnie obsłużyć.

pzdr
\SK
-- 
"Never underestimate the power of human stupidity" -- L. Lang

Dnia Tue, 04 Mar 2008 17:30:20 +0100, Sebastian Kaliszewski skrobie:
> Jedrzej Dudkiewicz wrote:
> >> Destruktory z C++ są rozwiązaniem cienkim. Cienkim z jednego,
> >> prozaicznego, ale kluczowego(!), powodu. Z poziomu destruktora nie da się
> >> poinformować o błędzie
> > 
> > Czy możesz podać jakiś spektakularny przykład, gdzie taka potrzeba
> > występuje?

> Oczywiście:

> Np. klasa obsługi (zapisywalnego) pliku z buforowaniem. Przy zamykaniu robi
> się opróżnienie buforów, które oczywiście może się nie udać. Destruktor
> jest tu rozwiązaniem cienkim.


> Konstrukcja using (z C#) czy with: z Pythona jest zdecydowanie lepsza. Bo
> Close() może rzucić wyjątek i ten wyjątek można normalnie obsłużyć.

Przecież destruktor również może rzucić wyjątkiem. Żadnego jawnego zakazu w
C++ na ten temat nie ma. Istnieje tylko jedna reguła: destruktor, który miałby
rzucić wyjątkiem, musi najpierw sprawdzić czy std::uncaught_exception(). Jeśli
tego nie zrobi, program dostanie terminate()m.

Konstrukcja using robi akurat dokładnie to samo.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

Sebastian Kaliszewski wrote:
> Jedrzej Dudkiewicz wrote:
>>> Destruktory z C++ są rozwiązaniem cienkim. Cienkim z jednego,
>>> prozaicznego, ale kluczowego(!), powodu. Z poziomu destruktora nie da się
>>> poinformować o błędzie
>> Czy możesz podać jakiś spektakularny przykład, gdzie taka potrzeba
>> występuje?
> 
> Oczywiście:
> 
> Np. klasa obsługi (zapisywalnego) pliku z buforowaniem. Przy zamykaniu robi
> się opróżnienie buforów, które oczywiście może się nie udać.
> Konstrukcja using (z C#) czy with: z Pythona jest zdecydowanie lepsza. Bo
> Close() może rzucić wyjątek i ten wyjątek można normalnie obsłużyć.

Obsługa takich błędów jest zwykle określona w jakimś firmowym 
standardzie kodowania czy wymaganych praktyk programistycznych. Równie 
dobrze można to zaimplementować w destruktorze. Jeżeli faktycznie 
interesuje nas, czy zapis się powiódł (czasem nie jest to istotne, np. 
kiedy leci akurat inny wyjątek), to wołamy Close() własnoręcznie.

JD

On 4 Mar, 20:02, Sektor van Skijlen
<ethou...@guess.if.gmail.com.is.valid.or.invalid> wrote:
> Przecież destruktor również może rzucić wyjątkiem. Żadnego jawnego zakazu w
> C++ na ten temat nie ma. Istnieje tylko jedna reguła: destruktor, który miałby
> rzucić wyjątkiem, musi najpierw sprawdzić czy std::uncaught_exception(). Jeśli
> tego nie zrobi, program dostanie terminate()m.

http://www.gotw.ca/gotw/047.htm

--
Khorne

Dnia Wed, 5 Mar 2008 02:42:37 -0800 (PST), Michał 'Khorne' Rzechonek skrobie:
> On 4 Mar, 20:02, Sektor van Skijlen
> <ethou...@guess.if.gmail.com.is.valid.or.invalid> wrote:
> > Przecież destruktor również może rzucić wyjątkiem. Żadnego jawnego zakazu w
> > C++ na ten temat nie ma. Istnieje tylko jedna reguła: destruktor, który miałby
> > rzucić wyjątkiem, musi najpierw sprawdzić czy std::uncaught_exception(). Jeśli
> > tego nie zrobi, program dostanie terminate()m.

> http://www.gotw.ca/gotw/047.htm

Oczywiście, on ma rację, ale ja mówię o zupełnie czym innym - o czym Herbuś
pewnie nie wie.

Chodzi o obiekty, dla których rzucanie wyjątku z destruktora jest istotą
działania. Na przykład:

{
	Initializer i( &v );

	i.add( x );
	i.add( y );
} // destruktor skleja i wpisuje do v

Nie wiem, czy to coś ma jakąś konkretną nazwę - nazwijmy to "pending state
object".

Tego typu obiekty mają następujące charakterystyki:

1. Najczęściej są używane jako obiekty tymczasowe (np. proxy dla operatora
przecinek, co kiedyś tu pokazywałem - dokładnie to pokazał ktoś inny, a ja
tylko inspirowałem :).

2. Destruktor ma za zadanie tylko i wyłącznie rzucić wyjątkiem w razie
niemożności skompletowania operacji.

W takiej sytuacji destruktor powinien mieć następującą definicję:
1. Spróbować wykonać operację dopełniającą
2. Jeśli podczas tej operacji wystąpił błąd:
   a. jeśli !uncaught_exception(), rzucić wyjątek
   b. jeśli nie, to po prostu nie rób nic

Ponieważ ten obiekt ma ściśle ograniczony zasięg działania, więc rzucenie
zwijanie tego obiektu podczas zwijania stosu na rzecz wyjątku i tak przerwie
całą operację, która go używa. Nie ma zatem żadnych powodów, aby ta operacja
informowała o jakimkolwiek błędzie, bo nawet jeśli wystąpił, i tak to już nie
ma żadnego znaczenia.

Herbuś mówi tutaj o zupełnie innych rzeczach - o "normalnych" obiektach, które
próbują sprzątać po sobie, a to sprzątanie może zakończyć się wyjątkiem. TU MA
RACJĘ. W takich obiektach destruktor powinien złapać ewentualny wyjątek z
operacji nieudanego cleanupu i go "zdusić". Ja mówię o zupełnie innych
obiektach - obiektach, w których destruktor jest dopełnieniem częściowych
operacji.

Najważniejszą sprawą w tym jest fakt, że obiekt taki ma NIE ROBIĆ ZUPEŁNIE NIC
w przypadku, gdy uncaught_exception(). Najlepiej, żeby miał zawsze na
początku:

if ( uncaught_exception() ) return;


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

Dnia 05-03-2008, Śr o godzinie 12:26 +0000, Sektor van Skijlen pisze:

> > http://www.gotw.ca/gotw/047.htm
> 
> Oczywiście, on ma rację, ale ja mówię o zupełnie czym innym

To jest to samo. Zastosowanie destruktora nie ma znaczenia. Chodzi o to,
że sprawdzenie uncaught_exception() w destruktorze nie jest równoważne
sprawdzeniu, czy wyjątek z tego destruktora spowoduje terminate(), choć
pomyłka jest w bezpieczną stronę. Może być tak, że uncaught_exception()
jest true, ale wyjątek z destruktora nie powoduje terminate. Przykład
pod linkiem powyżej.

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

Dnia Wed, 05 Mar 2008 15:13:22 +0100, Marcin ?Qrczak? Kowalczyk skrobie:
> Dnia 05-03-2008, Śr o godzinie 12:26 +0000, Sektor van Skijlen pisze:

> > > http://www.gotw.ca/gotw/047.htm
> > 
> > Oczywiście, on ma rację, ale ja mówię o zupełnie czym innym

> To jest to samo. Zastosowanie destruktora nie ma znaczenia. Chodzi o to,
> że sprawdzenie uncaught_exception() w destruktorze nie jest równoważne
> sprawdzeniu, czy wyjątek z tego destruktora spowoduje terminate(), choć
> pomyłka jest w bezpieczną stronę. Może być tak, że uncaught_exception()
> jest true, ale wyjątek z destruktora nie powoduje terminate. Przykład
> pod linkiem powyżej.

No dobrze. Zgodzę się jeszcze tylko do jednego - "pending state object"
również nie może być stosowany w destruktorze.

Ale to już naprawdę ostatni wyjątek :)


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"