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

[ciach]

Kiedys by³a mowa o jakims pdf-ie który opisuje zastosowane przez Ciebie
algorytm, ale jakos teraz go nie moge znale¿æ, czy jestes w stanie go
udostepniæ?

--
Wys³ano z serwisu OnetNiusy: http://niusy.onet.pl

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
 \/\/

> Kiedys by�a mowa o jakims pdf-ie kt�ry opisuje zastosowane przez Ciebie
> algorytm, ale jakos teraz go nie moge znale��, czy jestes w stanie go
> udostepni�?

Bior�c pod uwag� zmiany w bibliotece, jakie zosta�y poczynione od wersji
0.8.1, dokument ten ma wiele rozbie�no�ci i musia�bym go poprawic.
Z drugiej strony, nie widz� sensu tracenia czasu na poprawianiu dokumentu,
kt�rego i tak prawie nikt nie b�dzie czyta�.

Pozdrawiam.

- Bastek -

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

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

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

Panie Wojewodzki ! Prosze nie stulac nastepnych glupot.
Simula67 maila sobie gc (jako czesc jezyka a nie zewnetrzna lib czy tool)
i dzialala sobie na OSsie z calkowita pamiecia
32kW (slow 24 bitowych) wiec prosze dac juz spokoj z ta
idiotyczna 'krytyka' gc.

Na reszte Pana wypocin szkoda zwyczajnie klawiatury !

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

I badzo dobrze ze trzeba sie nahakowac
Hakowanie zniecheca (i o to chodzi).

AK

Brawo !

AK

Seweryn Habdank-Wojew�dzki wrote:
> 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.

Np w C# mordowac jak ja z starym dobrym malloc /heapalloc
Btw kod na tak przydzielonej pameici jest lekko 2x szybszy od tego co
intensywnie kozysta z NET owego GC
Nie mowiac juz o problemach z fragmentacja ramu gdy uzywa sie GC  i
duzej ilosci (setki tysiecy/ mln) alokacji i zwalnainia malych class.

Wtedy sie przydaje znajmosc C /algorytmow i mozna jechac z C# tak jakby
byl to C z mozliwoscia deklarowania metod. (uzywam wtedy tylko struct
ktory jest value type w C#)


//wycinek
public static unsafe class Heap
{
	public enum HEAP_INFORMATION_CLASS {
		HeapCompatibilityInformation
	};

#if USE_KERNEL32
static HANDLE*			ph = InitializeLFH();
static HANDLE*			InitializeLFH()
{
	uint  HeapFragValue = 2;
	HANDLE* heap = HeapCreate( (uint)dwFlags.CREATE_ENABLE_EXECUTE |
(uint)dwFlags.HEAP_GENERATE_EXCEPTIONS, 4 * 1024 * 1024, 0);

if(!HeapSetInformation(heap,HEAP_INFORMATION_CLASS.HeapCompatibilityInformation,
&HeapFragValue, sizeof(uint)))
		throw new InvalidProgramException("Setting LowFragmentationHeap failed");
	return heap;
}
#endif


public static void*		Malloc(int type_size, int element_count)
#if USE_KERNEL32
	void* result = HeapAlloc(ph, (int)dwFlags.HEAP_ZERO_MEMORY, type_size *
element_count);
#else
	void* result = malloc(type_size * element_count);
#endif

	return result;
}

[DllImport(KERNEL32)]
static extern void* HeapAlloc(HANDLE* hHeap, int flags, int size);

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
 \/\/

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

Tych system�w z ograniczonymi zasobami pami�ciowymi jest chyba znacznie
wi�cej ni� tych z "nieograniczonymi" (gdzie "nieograniczone to, za��my,
2GB).

JD

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

> Tych system�w z ograniczonymi zasobami pami�ciowymi jest chyba znacznie
> wi�cej ni� tych z "nieograniczonymi" (gdzie "nieograniczone to, za��my,
> 2GB).

Wszystko zale�y od wymaga� samej aplikacji. Dla niekt�rych, "nieograniczonym
zasobem", mo�e by� ju� 64MB pami�ci.

Pozdrawiam.

- Bastek -

Sebastian Nibisz wrote:
>> Tych system�w z ograniczonymi zasobami pami�ciowymi jest chyba
>> znacznie wi�cej ni� tych z "nieograniczonymi" (gdzie "nieograniczone
>> to, za��my, 2GB).
>
> Wszystko zale�y od wymaga� samej aplikacji. Dla niekt�rych,
> "nieograniczonym zasobem", mo�e by� ju� 64MB pami�ci.

Wydaje mi si�, �e na maszynach, gdzie pami�ci jest w okolicach ma�ych GB
(czyli np. domowe pecety albo jakie� Pomniejsze Serwery (tm)), to tych
aplikacji jest znacz�co wi�cej ni� jedna. To wszystko si� na siebie
nak�ada. Pewnie, �e jak otwierasz Eclipse i masz 2GB to to jest jak
splun��, tylko �e ma�o kto ma otwarte samo Eclipse.

JD

>>> Tych system�w z ograniczonymi zasobami pami�ciowymi jest chyba znacznie
>>> wi�cej ni� tych z "nieograniczonymi" (gdzie "nieograniczone to, za��my,
>>> 2GB).
>>
>> Wszystko zale�y od wymaga� samej aplikacji. Dla niekt�rych,
>> "nieograniczonym zasobem", mo�e by� ju� 64MB pami�ci.
>
> Wydaje mi si�, �e na maszynach, gdzie pami�ci jest w okolicach ma�ych GB
> (czyli np. domowe pecety albo jakie� Pomniejsze Serwery (tm)), to tych
> aplikacji jest znacz�co wi�cej ni� jedna. To wszystko si� na siebie
> nak�ada. Pewnie, �e jak otwierasz Eclipse i masz 2GB to to jest jak
> splun��, tylko �e ma�o kto ma otwarte samo Eclipse.

Zgadza si�, ale to przecie� nie jest tak, �e jak mam aplikacj� w kt�rej
zasoby s� zwalniane r�cznie, to mi wystarczy 10MB pami�ci systemowej a jak
korzystam z systemu GC, to tej pami�ci musz� mie� 10 razy wiecej. Wszystko
zale�y od specyfiki danej aplikacji i od sposobu zarz�dzania pami�ci� przez
system GC.

Nie potrzeba mi aplikacji wykorzystuj�cych GC, aby zadusi� system
wyg�rowanymi rz�daniami.

Pozdrawiam.

- Bastek -

Sebastian Nibisz wrote:
>>>> Tych system�w z ograniczonymi zasobami pami�ciowymi jest chyba
>>>> znacznie wi�cej ni� tych z "nieograniczonymi" (gdzie "nieograniczone
>>>> to, za��my, 2GB).
>>>
>>> Wszystko zale�y od wymaga� samej aplikacji. Dla niekt�rych,
>>> "nieograniczonym zasobem", mo�e by� ju� 64MB pami�ci.
>>
>> Wydaje mi si�, �e na maszynach, gdzie pami�ci jest w okolicach ma�ych
>> GB (czyli np. domowe pecety albo jakie� Pomniejsze Serwery (tm)), to
>> tych aplikacji jest znacz�co wi�cej ni� jedna. To wszystko si� na
>> siebie nak�ada. Pewnie, �e jak otwierasz Eclipse i masz 2GB to to jest
>> jak splun��, tylko �e ma�o kto ma otwarte samo Eclipse.
>
> Zgadza si�, ale to przecie� nie jest tak, �e jak mam aplikacj� w kt�rej
> zasoby s� zwalniane r�cznie, to mi wystarczy 10MB pami�ci systemowej a
> jak korzystam z systemu GC, to tej pami�ci musz� mie� 10 razy wiecej.

Jasne. Kto� tutaj jednak podawa� statystyki kiedy� i wychodzi�o, �e
�rednio aplikacja z GC �re wi�cej - co jest w zasadzie oczywiste. Wi�c,
by�o nie by�o, �atwiej.

> Wszystko zale�y od specyfiki danej aplikacji i od sposobu zarz�dzania
> pami�ci� przez system GC.
 > Nie potrzeba mi aplikacji wykorzystuj�cych GC, aby zadusi� system
 > wyg�rowanymi rz�daniami.

Zdecydowanie.

Tak w og�le, to mi si� idea GC bardziej ni� bardzo podoba, zje�y�em si�
tylko z tego powodu, �e z Twojej wypowiedzi mo�na by�o wnioskowa�, �e o
pami�� nie warto dba�, bo ma si� jej ile si� chce.

Przy czym rozumiem, �e chodzi�o o to, �e nale�y zasoby �ci�le podzieli�
na te, kt�rych przydzia�em trzeba si� bardzo przejmowa� i takie, kt�rych
przydzia�em mo�na zajmowa� si� mniej i �e w wi�kszo�ci przypadk�w pami��
nale�y do tej drugiej grupy.

JD

>> Zgadza si�, ale to przecie� nie jest tak, �e jak mam aplikacj� w kt�rej
>> zasoby s� zwalniane r�cznie, to mi wystarczy 10MB pami�ci systemowej a
>> jak korzystam z systemu GC, to tej pami�ci musz� mie� 10 razy wiecej.
>
> Jasne. Kto� tutaj jednak podawa� statystyki kiedy� i wychodzi�o, �e
> �rednio aplikacja z GC �re wi�cej - co jest w zasadzie oczywiste. Wi�c,
> by�o nie by�o, �atwiej.

Aplikacja korzystaj�ca z GC zawsze b�dzie bardziej pami�cio�erna, ale to jak
bardzo, zale�y ju� od samego systemu GC.
Typowy system GC zwalnia pami�� w sytuacji, kiedy zaczyna jej brakowa�.
Nietrudno sobie wyobrazi�, co si� stanie w sytuacji, gdy odpalimy dwie
pami�cio�erne aplikacje, korzystaj�ce z niezale�nych od siebie system�w GC.

>> Wszystko zale�y od specyfiki danej aplikacji i od sposobu zarz�dzania
>> pami�ci� przez system GC.
> > Nie potrzeba mi aplikacji wykorzystuj�cych GC, aby zadusi� system
> > wyg�rowanymi rz�daniami.
>
> Zdecydowanie.
>
> Tak w og�le, to mi si� idea GC bardziej ni� bardzo podoba, zje�y�em si�
> tylko z tego powodu, �e z Twojej wypowiedzi mo�na by�o wnioskowa�, �e o
> pami�� nie warto dba�, bo ma si� jej ile si� chce.
>
> Przy czym rozumiem, �e chodzi�o o to, �e nale�y zasoby �ci�le podzieli� na
> te, kt�rych przydzia�em trzeba si� bardzo przejmowa� i takie, kt�rych
> przydzia�em mo�na zajmowa� si� mniej i �e w wi�kszo�ci przypadk�w pami��
> nale�y do tej drugiej grupy.

To, �e pami�� jest tania, nie znaczy, �e jest za darmo i mo�na j�
marnotrawi�.
GC z biblioteki SGCL zosta� tak zaprojektowany, �e na bie��co analizauje
stan osi�galnej pami�ci w aplikacji. Pami�� zwalniana jest "na bie��co",
niezale�nie od tego czy aplikacja ��da przydzielania nowej.

Pozdrawiam.

- Bastek -

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"

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
 \/\/

Sebastian Nibisz wrote:

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

Niezaprzeczalnie.

> 2. Operacje na wska�nikach s� kosztowne (wymaga operacji atomowych).

I tu -- niespodzianka -- nie wymagaj�. Sam si� zdziwi�em, gdy
wpad�em na pomys� rozwi�zania, ale ono by�o z�udnie proste.
Zaimplementowa�em pierwotny pomys� w 2 dni, a potem... przez
7 debugowa�em, zanim zrozumia�em, �e to nie w kodzie jest
problem i poprawi�em algorytm. Przedstawi�em tu kiedy� szkic
pomys�u. Ale on jest b��dny (cho� wtedy jeszcze tego nie
wiedzia�em); ot, super rzecz dla szpieg�w przemys�owych
-- co�, co wygl�da na poprawne, ale wybuchnie w r�kach... :-)

Dlatego ostatnimi czasy wr�ci�em do rozwi�za� ze zliczaniem
referencji (intruzywnym), po tuningu s� niewiele wolniejsze ni�
zwyk�y wska�nik.

> 3. Zwalnianie wi�kszych struktur, mo�e doprowadzi� do przepe�nienia ramki
> stosu.

To si� da rozwi�za�, cho� nie zawsze jest to konieczne. Naiwna
implementacja mark&sweep cierpi na dok�adnie ten sam problem.

> 4.  Zwalnianie wi�kszych struktur, mo�e na d�u�szy okres wstrzyma�
> dzia�anie aplikacji (wymaga operacji atomowych).

Ja deterministyczny punkt destrukcji uznaj� za zalet�.

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

Pogratulowa�. :-)

    Pozdrawiam
    Piotr Wyderski

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

On 27 Lut, 13:09, "Piotr Wyderski" <wyder...@REMOVEii.uni.wroc.pl>
wrote:
> S± potrzebne tylko wtedy, gdy w±tek pierwszy raz spotyka siê z danym
> obiektem.
> Wówczas atomowo podnosi licznik referencji (i od tego momentu ma pewno¶æ, ¿e
> nikt mu tego obiektu nie zabije) i mo¿e sobie zacz±æ lokalne zliczanie
> swoich referencji.

Ach, tak proste, ¿e a¿ genialne. Bardzo fajne rozwi±zanie, zapamiêtam,
dziêkujê :)

--
Micha³ 'Khorne' Rzechonek

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"

>> 2. Operacje na wska�nikach s� kosztowne (wymaga operacji atomowych).
>
> I tu -- niespodzianka -- nie wymagaj�. Sam si� zdziwi�em, gdy
> wpad�em na pomys� rozwi�zania, ale ono by�o z�udnie proste.
> Zaimplementowa�em pierwotny pomys� w 2 dni, a potem... przez
> 7 debugowa�em, zanim zrozumia�em, �e to nie w kodzie jest
> problem i poprawi�em algorytm. Przedstawi�em tu kiedy� szkic
> pomys�u. Ale on jest b��dny (cho� wtedy jeszcze tego nie
> wiedzia�em); ot, super rzecz dla szpieg�w przemys�owych
> -- co�, co wygl�da na poprawne, ale wybuchnie w r�kach... :-)
>
> Dlatego ostatnimi czasy wr�ci�em do rozwi�za� ze zliczaniem
> referencji (intruzywnym), po tuningu s� niewiele wolniejsze ni�
> zwyk�y wska�nik.

Operacje atomowe na liczniku nie sa wymagane tylko w przypadku, gdy ma sie
pewno��, �e manipulacja wska�nikiem odbywa si� w jednym w�tku aplikacji.

>> 3. Zwalnianie wi�kszych struktur, mo�e doprowadzi� do przepe�nienia ramki
>> stosu.
>
> To si� da rozwi�za�, cho� nie zawsze jest to konieczne. Naiwna
> implementacja mark&sweep cierpi na dok�adnie ten sam problem.

Zawsze mo�na to jako� rozwi�za�. Mo�na si� jednak nie�le �dziwi�, gdy niby
prawid�owy fragment kodu wysypuje nam aplikacj�.

>> 4.  Zwalnianie wi�kszych struktur, mo�e na d�u�szy okres wstrzyma�
>> dzia�anie aplikacji (wymaga operacji atomowych).
>
> Ja deterministyczny punkt destrukcji uznaj� za zalet�.

Trudno uzna� za zalet� stuacj� w kt�rej aplikacja zatrzymuje si� na dwie
sekundy tylko po to, aby zwolni� zajmowana przez siebie pami��.

>> Prawde powiedziawszy, na chwil� obecn�, nie spotka�em jeszcze takiej
>> implementacji systemu GC w jakimkolwiek j�zyku czy �rodowisku.
>
> Pogratulowa�. :-)

Dzi�ki, cho� niestety rozwi�zanie nie jest pozbawione wad.

Pozdrawiam.

- Bastek -

Dnia 27-02-2008, ¦r o godzinie 12:02 +0100, Sebastian Nibisz pisze:

> Operacje atomowe na liczniku nie sa wymagane tylko w przypadku, gdy ma sie 
> pewno¶æ, ¿e manipulacja wska¼nikiem odbywa siê w jednym w±tku aplikacji.

Pewnie mo¿na w ka¿dym obiekcie pamiêtaæ, który w±tek ostatnio dotyka³
jego licznika odwo³añ. Operacje atomowe bêd± potrzebne tylko kiedy
obiekt jest przekazywany miêdzy w±tkami, co powinno byæ rzadkie.

Wystarczy, je¶li operacji atomowych unika siê w typowym przypadku.
Nie trzeba unikaæ ich bezwzglêdnie.

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

Sebastian Nibisz wrote:

> Operacje atomowe na liczniku nie sa wymagane tylko w przypadku, gdy ma sie
> pewno��, �e manipulacja wska�nikiem odbywa si� w jednym w�tku aplikacji.

Ano w�a�nie nie... :-)
S� potrzebne tylko wtedy, gdy w�tek pierwszy raz spotyka si� z danym
obiektem.
W�wczas atomowo podnosi licznik referencji (i od tego momentu ma pewno��, �e
nikt mu tego obiektu nie zabije) i mo�e sobie zacz�� lokalne zliczanie
swoich referencji.

>>> 3. Zwalnianie wi�kszych struktur, mo�e doprowadzi� do przepe�nienia
>>> ramki stosu.
>>
>> To si� da rozwi�za�, cho� nie zawsze jest to konieczne. Naiwna
>> implementacja mark&sweep cierpi na dok�adnie ten sam problem.
>
> Zawsze mo�na to jako� rozwi�za�. Mo�na si� jednak nie�le �dziwi�, gdy niby
> prawid�owy fragment kodu wysypuje nam aplikacj�.

No tak, tylko Ty to podawa�e� jako wad� RC, cho� dotyczy to te� M&S
z dok�adnie tego samego powodu. I w ten sam spos�b si� to rozwi�zuje.

> Trudno uzna� za zalet� stuacj� w kt�rej aplikacja zatrzymuje si� na dwie
> sekundy tylko po to, aby zwolni� zajmowana przez siebie pami��.

Przesadzasz... poza tym na to te� s� sposoby... RC jest bardzo cz�sto
wykorzystywany w systemach czasu rzeczywistego, wi�c chyba nie ma
lepszego dowodu na istnienie rozwi�zania.

    Pozdrawiam
    Piotr Wyderski

Marcin 'Qrczak' Kowalczyk wrote:

> Pewnie mo�na w ka�dym obiekcie pami�ta�, kt�ry w�tek ostatnio dotyka�
> jego licznika odwo�a�. Operacje atomowe b�d� potrzebne tylko kiedy
> obiekt jest przekazywany mi�dzy w�tkami, co powinno by� rzadkie.

Owszem, to jedno z mo�liwych rozwi�za�, cho� da si� znacznie lepiej.

> Wystarczy, je�li operacji atomowych unika si� w typowym przypadku.
> Nie trzeba unika� ich bezwzgl�dnie.

W�asnie tak. :-) To dok�adnie to samo, co z pami�ci� cache. Mo�na
�atwo pokazac przypadek, �e �adne cache nie pomo�e, a jednak... jako�
si� producenci procesor�w prze�cigaj� w zwi�kszaniu jego rozmiaru.
Lokalno�� referencji to znacznie og�lniejsze zjawisko...

    Pozdrawiam
    Piotr Wyderski

>> Operacje atomowe na liczniku nie sa wymagane tylko w przypadku, gdy ma
>> sie
>> pewno��, �e manipulacja wska�nikiem odbywa si� w jednym w�tku aplikacji.
>
>Pewnie mo�na w ka�dym obiekcie pami�ta�, kt�ry w�tek ostatnio dotyka�
>jego licznika odwo�a�. Operacje atomowe b�d� potrzebne tylko kiedy
>obiekt jest przekazywany mi�dzy w�tkami, co powinno by� rzadkie.

Niby tak, ale wyjdzie na to, �e zapis i odczyt pola przechowuj�cego
identyfikator w�tku i tak w jaki� spos�b musia�by by� synchronizowany.
Zastanawia�em si� kiedy� nad podobnym rozwi�zaniem i doszed�em do wniosku,
�e raczej nie da sie tego w �aden sensowny spos�b zaimplementowa�.

>Wystarczy, je�li operacji atomowych unika si� w typowym przypadku.
>Nie trzeba unika� ich bezwzgl�dnie.

Zgadza si�, potrzeba stosowania synchronizacji, nie jest nagminna. Mo�na
sobie wyobrazi� taki shared_ptr dost�pny w dw�ch wersjach, synchronizowanej
oraz niesynchronizowanej i stosowa� odpowiedni� wersj� w ramach potrzeb.
Takie podej�cie mo�e jednak rodzi� problemy w p�niejszym utrzymywaniu kodu.

Pozdrawiam.

- Bastek -

 > Na reszte Pana wypocin szkoda zwyczajnie klawiatury !

Niezale¿nie od tego kto ma s³uszno¶æ, daruj, proszê sobie tego typu
wstawki. Nie po to cz³owiek wchodzi do sieci ¿eby mieæ powtórkê dyskusji
polityków z TVN24.

To jest grupa dyskusyjna, ¶cieraj± siê tu ró¿ne opinie (w tym b³êdne).
Je¶li kto¶ z nas ma wyrobiæ sobie *prawid³owe* zdanie na podstawie
dyskusji to musi siê oprzeæ na argumentach obu stron. Pisanie o
wypocinach argumentem nie jest. Jest to tak oczywiste, ¿e wstyd i¿
trzeba o tym przypominaæ.


-- 
Pozdrawiam
Johnny

"Zauwa¿y³em ¿e ci wszyscy, którzy opowiadaj± siê za aborcj±, zd±¿yli siê
urodziæ". R. Reagan

>> Operacje atomowe na liczniku nie sa wymagane tylko w przypadku, gdy ma
>> sie pewno��, �e manipulacja wska�nikiem odbywa si� w jednym w�tku
>> aplikacji.
>
> Ano w�a�nie nie... :-)
> S� potrzebne tylko wtedy, gdy w�tek pierwszy raz spotyka si� z danym
> obiektem.
> W�wczas atomowo podnosi licznik referencji (i od tego momentu ma pewno��,
> �e
> nikt mu tego obiektu nie zabije) i mo�e sobie zacz�� lokalne zliczanie
> swoich referencji.

A w jaki spos�b w�tek sprawdza, czy pierwszy raz spotka� sie z danym
obiektem, aby ewentualnie atomowo podnie�� licznik referencji?

>>>> 3. Zwalnianie wi�kszych struktur, mo�e doprowadzi� do przepe�nienia
>>>> ramki stosu.
>>>
>>> To si� da rozwi�za�, cho� nie zawsze jest to konieczne. Naiwna
>>> implementacja mark&sweep cierpi na dok�adnie ten sam problem.
>>
>> Zawsze mo�na to jako� rozwi�za�. Mo�na si� jednak nie�le �dziwi�, gdy
>> niby prawid�owy fragment kodu wysypuje nam aplikacj�.
>
> No tak, tylko Ty to podawa�e� jako wad� RC, cho� dotyczy to te� M&S
> z dok�adnie tego samego powodu. I w ten sam spos�b si� to rozwi�zuje.

Nie mo�na stawia� tych dw�ch przypadk�w na jednym poziomie, gdy� shared_ptr
wymaga rozwi�zania problemu na poziomie aplikacji a algorytm "mark & sweep"
na poziomienie implementacji systemu GC.

>> Trudno uzna� za zalet� stuacj� w kt�rej aplikacja zatrzymuje si� na dwie
>> sekundy tylko po to, aby zwolni� zajmowana przez siebie pami��.
>
> Przesadzasz... poza tym na to te� s� sposoby... RC jest bardzo cz�sto
> wykorzystywany w systemach czasu rzeczywistego, wi�c chyba nie ma
> lepszego dowodu na istnienie rozwi�zania.

RC nie jest jedyna technik� od�miecania stosowan� w systemach czasu
rzeczywistygo, co dobitnie �wiadczy o tym, �e jego wady mog� przeszkadza�.

Pozdrawiam.

- Bastek -

Sebastian Nibisz wrote:

> A w jaki spos�b w�tek sprawdza, czy pierwszy raz spotka� sie z danym
> obiektem, aby ewentualnie atomowo podnie�� licznik referencji?

Zapami�tuje sobie w TLSie N ostatnio u�ywanych obiekt�w.
Potem tylko proste hashowanie i masz, co potrzeba.

> Nie mo�na stawia� tych dw�ch przypadk�w na jednym poziomie, gdy�
> shared_ptr wymaga rozwi�zania problemu na poziomie aplikacji a algorytm
> "mark & sweep" na poziomienie implementacji systemu GC.

To si� da rozwi�za� poprzez modyfikacj� implementacji shared_ptr. Jest taka,
jaka jest, wi�c i problem w naturalny spos�b wyst�puje, ale nie musi taka
by�.

> RC nie jest jedyna technik� od�miecania stosowan� w systemach czasu
> rzeczywistygo, co dobitnie �wiadczy o tym, �e jego wady mog� przeszkadza�.

Oczywi�cie, �e ta metoda ma wiele wad. Ale w RT chyba dominuje i wcale
mnie to nie dziwi. Lubi� deterministyczne programy... :-)

    Pozdrawiam
    Piotr Wyderski

> 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

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

W systemach wbudowanych nie wykorzystuje sie pami�ci tak ja na komputerach
domowych. Tam nie ma tak, �e jak mamy 10 razy wi�cej pami�ci, to sobie
wrzucimy wiecej obrazk�w, dodamy muzyczk�, jakie� dynamiczne menu i pami�ci
zn�w mamy ma�o.

Samego kodu nie da si� mno�y� na du�� skal� w niesko�czono��. Z pewno�ci�
jest coraz mniej sytuacji w kt�rej ze wzgl�du na ma�� ilo�� dost�pnej
pami�ci, nie mo�na zaimplementowa� jakie� funkcjonalno�ci w systemie
wbudowanym. Sprz�t niewielkim kosztem mo�na rozbudowa�, co jeszcze
kilkana�cie lat temu cz�sto nie by�o mo�liwe.

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

Przy za�o�eniu, �e j�zyk C++ jest dedykowany jedynie dla przemys�u, to mo�na
sie zgodzi� z tym, �e tempo jego rozoju jest zadowalaj�ce.
Niestety takiego za�o�enia przyj�� nie mo�na i mog� rodzi� sie s�uszne obawy
o to, �e zanim nowy standard zostanie "zaklepany" no i oczywi�cie wdro�ony,
j�zyka C++ na desktopach ma�o kto ju� b�dzie u�ywa�.

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

Zgadza si�, trzeba jednak wzi�� pod uwag�, �e mo�liwo�ci bibliotek s�
ograniczane przez mo�liwo�ci samego j�zyka.

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

W swojej kategorii, j�zyk C++ wiedzie prym lidera.

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

Jak najbardziej sie zgadzam. Nie wyobra�am sobie j�zyka C++ z innym, ni�
jedynie opcjonalnym system GC.

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

Nikt nie og�asza zgonu j�zyka C++, ale te� nikomu nie chce sie czeka�
kolejnych 10 lat na jego nowsz� wersj�.

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

Po�yjemy, zobaczymy.

Pozdrawiam.

- Bastek -

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

Sebastian Nibisz wrote:

>>> Operacje atomowe na liczniku nie sa wymagane tylko w przypadku, gdy ma
>>> sie
>>> pewno��, �e manipulacja wska�nikiem odbywa si� w jednym w�tku aplikacji.
>>
>>Pewnie mo�na w ka�dym obiekcie pami�ta�, kt�ry w�tek ostatnio dotyka�
>>jego licznika odwo�a�. Operacje atomowe b�d� potrzebne tylko kiedy
>>obiekt jest przekazywany mi�dzy w�tkami, co powinno by� rzadkie.
>
> Niby tak, ale wyjdzie na to, �e zapis i odczyt pola przechowuj�cego
> identyfikator w�tku i tak w jaki� spos�b musia�by by� synchronizowany.
> Zastanawia�em si� kiedy� nad podobnym rozwi�zaniem i doszed�em do wniosku,
> �e raczej nie da sie tego w �aden sensowny spos�b zaimplementowa�.

Hehe, zauwa�, �e takie "pole" bardzo cz�sto masz ju� za darmo, na i396 i
x86-64 le�y sobie ono w procesorze i dost�pne jesyt poprzez FS albo GS
(zale�nie od ABI) :).


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

Micha� 'Khorne' Rzechonek wrote:

> Ach, tak proste, �e a� genialne. Bardzo fajne rozwi�zanie, zapami�tam,
> dzi�kuj� :)

Dzieki za mi�e s�owo, ale prostota tego rozwi�zania jest z�udna. :-)

    Pozdrawiam
    Piotr Wyderski

U�ytkownik "Sektor van Skijlen"
<ethouris@guess.if.gmail.com.is.valid.or.invalid> napisa�:

> To prawda, ale dotyczy to tylko cz�ci rynku oprogramowania.

Prawda !
Ta czesc to 99.5%

AK

U�ytkownik "Sektor van Skijlen"
<ethouris@guess.if.gmail.com.is.valid.or.invalid> napisa�:

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

Konkrety Panowie.
_Jakie to sa obszary_  w ktorych C++ zradzi bo ja nie widze ?

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

j/w
Jakie to dziedziny ?

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

j.w
Jakie to galezie ?

AK

U�ytkownik "Sebastian Nibisz" <EBA_K@poczta.onet.pl> napisa�:

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

A co z Mono ?
Przeciez dziala.

AK

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