🚀 go-pugleaf

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

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

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

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

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

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

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

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

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

> A co z Mono ?
> Przeciez dziala.


Niby działa, ale nie jest jeszcze zgodny z .NET 2.0 a szybkość tego 
działaniam też pozostawia wiele do życzenia. Na domiar złego, narzędzia do 
niego są jakieś niedopracowane.

Pozdrawiam.

- Bastek - 

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

> Niby działa, ale nie jest jeszcze zgodny z .NET 2.0 a szybkość tego 
> działaniam też pozostawia wiele do życzenia. Na domiar złego, narzędzia do 
> niego są jakieś niedopracowane.

Te podstawowe sa (kompilatory, API, VM itp).
Zawsze jednak jest tak ze developing odbywa sie na jednej platformie
(zazwyczaj - tak prawie 100% - na Windows) a na innych sie jedynie
'kompiluje' i 'builduje') wiec dodatkowe narzedzia (typu IDE, itp)
sa malo istotne.

Co do nadazania z rozwojem samego .NET ?
Prawda, ale ten efekt jest _nieunikniony_
no bo .NET sie rozwija (np LINQ).
Mono tez sie jednak rozwija.
Srodowisko .NET jest jednak kompatybilne w dol
wiec to nie jest przeszkoda w pisaniu aplikacji 'przenosnej'.
Jak zwykle w takich sytuacjach trzeba wybrac przenosny
'podset'.
Smiem twierdzic (a mowie to na podstawie wieloletniej,
ale i obecjen praktyki), ze to i tak przyslowiowy pryszcz
w stosunku do zgromadzenia _naprawde_ przenosnego
srodowiska (mowie o API i bibliotekach) developerskiego
w C++.
To jeden z wiekszych mitow ze C++ jest przenosny .
IMHO o wiele lepiej tu sie spisuje .NET i Mono

AK

Witam

Adam Karpierz wrote:

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

Trzeba zdjąć okulary z filtrem Anti-C++.

HPC? 
Quantitative Finance?
ODB?
 
> Jakie to dziedziny ?

HCP?
Quantitative Finance?
ODB?
 
> Jakie to galezie ?

HPC?
Quantitative Finance?
ODB?

I ogólnie to tam, gdzie nie ma wymogu, aby aplikacja bezpośrednio świstała
po WWW i aby wyglądała jak Windows -- C# + .NET jest tańszy niż C++/CLR
+ .NET.

Pozdrawiam.

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

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

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

Tam jest tak, że jak mamy 10 razy więcej pamięci, to sobie wrzucimy
podczyt danych pomiarowych z różnymi oknami usredniania i z dużo
większą historią (historią danych można już załatwić temat, ale idźmy
dalej), logowaniem, diagnostyką, XMLami konfiguracyjnymi i middlewarem
z półki.
Schemat ten sam, tylko zabawki inne.

> Samego kodu nie da się mnożyć na dużą skalę w nieskończoność.

Wprowadźmy sobei generatory kodu. One mają cierpliwość.
Dodajmy agenty monitorujące oraz skomplikowaną kontrolę uprawnień
dostępu.

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

Właśnie nie podzielam tego przekonania.

> Sprzęt niewielkim kosztem można rozbudować, co jeszcze
> kilkanaście lat temu często nie było możliwe.

Nadal bywa niemożliwe, po prostu limity są gdzie indziej. Zapełnione
gniazda pamięci? Oops.

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

Bez obaw. Nowy standard najszybciej trafi właśnie na desktopy, bo tam
najszybciej można wprowadzać nowości.
Swoją drogą - nie upieram się, że C++ powinien królować na desktopach.

> > Druga płaszczyzna to biblioteki i narzędzia orbitujące

> Zgadza się, trzeba jednak wziąć pod uwagę, że możliwości bibliotek są
> ograniczane przez możliwości samego języka.

Pozwolę sobie się z tym nie zgodzić. :-)
Raczej nie widzę spowolnienia w produkcji innowacyjnych bibliotek.

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

Dlaczego myślisz, że będzie trzeba czekać kolejnych 10 lat?

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

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

> Trzeba zdjąć okulary z filtrem Anti-C++.

Nie mam ich.
Bez nich tez nie dostrzegam C++.

> HPC?

Sobie Pan nie zartuj
HPF ja juz !
Fortran sie klania !

> Quantitative Finance?

A co to ?
Tego sie nie da w C# albo nawet w... Clipperze ? ;0

> ODB?

To niby domena C++ ? :)

> I ogólnie to tam,

Czyli gdzie ?
Ogolnie brzmi mi jak nigdzie.
Na razie Pan daje ciala Panie Wojewodzki.

AK

On 27 Lut, 19:47, "Adam Karpierz" <karpierz@_NOSPAM_python.pl> wrote:
> Smiem twierdzic (a mowie to na podstawie wieloletniej,
> ale i obecjen praktyki), ze to i tak przyslowiowy pryszcz
> w stosunku do zgromadzenia _naprawde_ przenosnego
> srodowiska (mowie o API i bibliotekach) developerskiego
> w C++.

Mam nieodparte wrażenie, że piszesz o GUI :-]
Z resztą bibliotek (do czegokolwiek) problemów nie miałem,
nawet nie używając takich wynalazków jak Apache Portable
Runtime.

Z .NET i Mono bywa różnie, bo projekty są związane ze
sobą tylko w jedną stronę. Z Javą jest fatalnie, wiele
bibliotek/frameworków działa tylko na określonych wersjach
a po upgrade JVM sypią się tak że aż tyłek boli.

> To jeden z wiekszych mitow ze C++ jest przenosny .
> IMHO o wiele lepiej tu sie spisuje .NET i Mono

IMO największym mankamentem C++ jest brak
ustandaryzowanego środowiska uruchomieniowego -
każdy OS/kompilator realizuje linkowanie po swojemu
linkowanie i nawet jeśli zbudujemy aplikację to się
wywali na runtime z Bardzo Dziwnym Błędem.

--
Khorne

Użytkownik "Michał 'Khorne' Rzechonek" <khornik@gmail.com> napisał:

> Mam nieodparte wrażenie, że piszesz o GUI :-]

Mam nieodparte wrazenie ze nie.

PS: Akurat GUI jest w pelni przenosne (MFC).

> Z .NET i Mono bywa różnie, bo projekty są związane ze
> sobą tylko w jedną stronę.

No przeciez jest _jasne jak slonce_ ze Mono
nigdy nie nadazy a .NET - bo tak ma kazdy
port czegokolwiek co sie rozwija.
To jednak nie przeszkadza w portability.
(czasem nawet o dziwo pomaga - ogranicza szalenstwo
 rzucania sie na nowostki)

> Z Javą jest fatalnie, wiele bibliotek/frameworków działa tylko
> na określonych wersjach a po upgrade JVM sypią się tak że aż tyłek boli.

Nie no dajzesz chlopie spokoj :)
Siedzi kolo mnie cala banda Javowcow ktorym szczerze
zazdroszcze zerowych problemow z portability.

AK

Adam Karpierz wrote:
>> Z .NET i Mono bywa różnie, bo projekty są związane ze
>> sobą tylko w jedną stronę.

Nie sa w 100% kompatybilne na poziomie skladni jezyka.

> No przeciez jest _jasne jak slonce_ ze Mono
> nigdy nie nadazy a .NET - bo tak ma kazdy
> port czegokolwiek co sie rozwija.
> To jednak nie przeszkadza w portability.
> (czasem nawet o dziwo pomaga - ogranicza szalenstwo
>  rzucania sie na nowostki)

Tu smutna prawda ze autorzy Mono wcale nie darza do stabilizowania 
wersji zanim zaczna implementowac nowostki.

Efekt w mono jest taki ze ma elementy NET 3ki C# a nawet chyab 3.5 (nei 
dam sobie glowy uciac) a faza .NET1.1 nei jest skonczona w 100% a o 2.0 
lepiej sie nei wypowiadac bo nie da sie zadnej aplikacji gui stworzonej 
na VS2005 nawet bez tykania wodotryskow zbudowac z mono.

Na dokladke w mono autorzy nei staraja sie nawet zachowac z VS 
kompatybilnosci (przynajmiej tak bylo jak keidys stralem sie zbudowac na 
sile aplikacje zrobiona z VS)  prosty przyklad ktory boli gdy sie uzywa 
designera i form.

VS np generuje takie cos dla form

//implementacja usera
public partial class X {
};

//implementacja designera w pliku *.designer.cs
partial class X {
};

Z tego co pamietam mono sie sypal z krzykiem o inconsitent accesiblity 
co jest z jednej strony logiczne ale boli jak chce sie sportowac 
aplikacje VS.

Jakis miesiac temu sprawdzalem stan .NET 2.0 w mono i nadal podstawowej 
rzeczy nie ma -> klas ToolStripXXXXX
Nie da sie zbudowac nic co ma Menu i Toolbar zrobiony w 2.0 .NET

-- 

Artur

Czy w 1.1 nie da sie pisac ?
Czy w 1.1 nie da sie zrobic Menu u Toolbara ?

AK 

Adam Karpierz wrote:
> Czy w 1.1 nie da sie pisac ?

Czy w asemblerze nie da się pisac ?
Miedzy 1.1 a 2.0 jest przepaść , np brak wzorców.

To tak jakby programiscie C++ powiedziec ze ma przeniesc aplikacje z C++ 
z szablonami na C z uzyciem void* zamiast typename T, da się prawda ?

> Czy w 1.1 nie da sie zrobic Menu u Toolbara ?

Nie w VS2005 z uzyciem designera, recznie z pewnością tak.

-- 

Artur

"Artur Bać" <artur_nospam@ebasoft.com.pl> wrote:

> Adam Karpierz wrote:
>> Czy w 1.1 nie da sie pisac ?
>
> Czy w asemblerze nie da się pisac ?

Idiotyczne porownanie.

> Miedzy 1.1 a 2.0 jest przepaść , np brak wzorców.
>
> To tak jakby programiscie C++ powiedziec ze ma przeniesc aplikacje z C++ z 
> szablonami na C z uzyciem void* zamiast typename T, da się prawda ?

j/w.
Jelsi juz to mozna porownywac 'generyczne' podejscie
z podejsciem scisle obiektowym (dziedziczenie od obj).
Czy w javie < 1.6 nie da sie pisac ?

PS: Przeciez Mono obsluguje wzorce

AK

On 28 Lut, 12:32, "Adam Karpierz" <karpierz@_NOSPAM_python.pl> wrote:
> PS: Akurat GUI jest w pelni przenosne (MFC).
Znaczy... na co przenośne? Na Linuksa, Solarisa i OS X?

> Nie no dajzesz chlopie spokoj :)
> Siedzi kolo mnie cala banda Javowcow ktorym szczerze
> zazdroszcze zerowych problemow z portability.

A to ciekawe, bo ja się nasłuchałem z sąsiedniego
pokoju ciężkiego mięsa na temat upgradów JRE.

Z własnego doświadczenia nie wiem, bo w Javie nie
piszę.


--
Khorne

> Znaczy... na co przenośne? Na Linuksa, Solarisa i OS X?

Dokladnie.

> A to ciekawe, bo ja się nasłuchałem z sąsiedniego
> pokoju ciężkiego mięsa na temat upgradów JRE.

Jesli kilkudziesiecioosobowy zespol
bez wiekszych problemow przeszedl z Javy
'bezszablonowej' na 'szablonowa' to jakies problemy
z upgrades JRE w ramach tej samej wersji to mnie
smiechem napelniaja.

AK

On 28 Lut, 15:25, "Adam Karpierz" <karpierz@_NOSPAM_python.pl> wrote:
> > Znaczy... na co przenośne? Na Linuksa, Solarisa i OS X?
> Dokladnie.

MFC? Czy ja czegoś nie wiem?

--
Khorne

Użytkownik "Michał 'Khorne' Rzechonek" <khornik@gmail.com> napisał:

> MFC? Czy ja czegoś nie wiem?

Chyba tak.

Tak sie wlasnie tworza mity.
MFC _jest_ przenosne.
Nieprzenosny jest np boost.

AK

Dnia 28-02-2008, Cz o godzinie 18:18 +0100, Adam Karpierz pisze:

> MFC _jest_ przenosne.

MFC nie działa w GCC pod Linuxem.

> Nieprzenosny jest np boost.

Boost działa w GCC pod Linuxem.

Używasz jakiejś dziwnej definicji przenośności, w moim przypadku całkiem
nieprzydatnej.

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

Adam Karpierz wrote:
> Użytkownik "Michał 'Khorne' Rzechonek" <khornik@gmail.com> napisał:
> 
>> MFC? Czy ja czegoś nie wiem?
> 
> Chyba tak.
> 
> Tak sie wlasnie tworza mity.
> MFC _jest_ przenosne.

A na czym ona polega czy tylko na istnieniu MFC dla WinXP64 i WinCE ?

PS: Pytam sie calkiem pargmatycznie bo mnie to interesuje , bynajmiej 
nie złośliwie.

Witam

Adam Karpierz wrote:

> Użytkownik "Seweryn Habdank-Wojewódzki" <shw_mail@wp.pl> napisał:
> 
>> Trzeba zdjąć okulary z filtrem Anti-C++.
> 
> Nie mam ich.
> Bez nich tez nie dostrzegam C++.

To o co Pan tak wojuje? O coś czego Pan nie widzi?
 
>> HPC?
> 
> Sobie Pan nie zartuj
> HPF ja juz !
> Fortran sie klania !

Panie Karpierz nie słyszałem, o żadnym projekcie HPC pisanym ostatnio w
Fortranie (dla ustalenia uwagi -- High Performance Computing -- termin ten
jest niezależny od języka).

Rozumiem, że ma Pan jakieś wspomnienia z dzieciństwa.
 
>> Quantitative Finance?
> 
> A co to ?
> Tego sie nie da w C# albo nawet w... Clipperze ? ;0

Ale pisze się w C++. C# jest w na końcu, Java jest przed C# za C++, ale Java
pojawia się i tak dość rzadko. O Pythonie nie mówi się na poziomie szumu
ofertowego w sekcji (jak ktoś zna to dobrze).
 
>> ODB?
> 
> To niby domena C++ ? :)

A nie? Udowodnij Pan, że nie, a nie wypisuj bzdur. Jedna z najlepszych baz
danych z tej działki jest dziubnięta w C++.
 
>> I ogólnie to tam,
> 
> Czyli gdzie ?
> Ogolnie brzmi mi jak nigdzie.
> Na razie Pan daje ciala Panie Wojewodzki.

Panie Karpierz, ja już podałem działki, a Pan narazie nic nie podał
konkretnego. Dla mnie to jest żałosne, że Pan tak usilnie dezawuuje język,
dzięki któremu ma Pan pensję większą niż gdyby pisał Pan stronki w PHP.

Pozdrawiam.

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

Dnia Wed, 27 Feb 2008 16:59:38 +0100, Sebastian Nibisz skrobie:
> 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ść.

Co to znaczy?

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

Sprzęt w "systemie wbudowanym"? Ty masz chyba marne pojęcie o takim sprzęcie.

Czy ty w ogóle wiesz, o jakich systemach mowa? Mowa o systemach, które muszą
się w najlepszym razie zmieścić *w całości* na płycie wielkości 1/4 laptopa. W
całości, wraz ze wszystkimi podległymi sprzętami. I powtarzam - w *najlepszym*
razie, bo poza tym mamy jeszcze urządzenie wielkości telefonu komórkowego lub
zegarka, no w porywach jest to urządzenie POS (jak płaciłeś kiedyś kartą w
sklepie, to wiesz, jak wygląda).

Chcesz mi powiedzieć, że w takich urządzeniach można ten sprzęt "niewielkim
kosztem rozbudować"?



-- 
//  _    ___         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 Wed, 27 Feb 2008 06:42:29 -0800 (PST), Maciej Sobczak skrobie:
> 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.

Maćku, kilkakrotnie podnosisz ten argument, ale dla mnie on jest niestety dość
słaby.

Co z tego, że przemysł ledwo nadąża z kompilatorami za standardem w przypadku
C++, skoro Java zmienia się szybciej i tam akurat kompilatory nadążają za
standardem (oczywiście mówię o JDK, a nie gcj, bo ten ledwie zdążył się
dostosować do jdk 1.5, podczas gdy w użyciu jest już 1.6)?

Jeśli kompilatory nie nadążają za standardem to nie jest to dla mnie
absolutnie wyznacznik tego, że język zmienia się "szybko". Gdyby język
zmieniał się szybciej, to kompilatory nadążałyby za nim mniej więcej tak samo,
może co najwyżej przeskakiwanoby po kilka wersji na raz.

Jak już niejednokrotnie mówiłem, problemem C++ nie jest to, czy on się zmienia
za wolno czy za szybko - problemem jest to, że decyzje komitetu
standaryzacyjnego C++ nie są wspierane równocześnie feedbackiem z testów na
próbnej implementacji.

Może dzięki wysiłkom Douga Gregora to się zmieni, ale póki co nie
zaimplementowano tam jeszcze wielu WSTĘPNIE ZAAKCEPTOWANYCH propozycji.
Natomiast dawno już zaimplementowany ficzer Variadic Templates (który, że się
tak lubię chwalić, osobiście pomagałem testować :) jest w stanie (moim
zdaniem) "produkcyjnym", a komitet standaryzacyjny nie raczył nawet jeszcze
tego włączyć pod obrady.

Jedynym ficzerem, który jest zaimplementowany i zaakceptowany równocześnie to
rvalue-reference; ficzer, który budzi niestety u mnie mieszane uczucia (jestem
zdania, że nawet jeśli trochę pomoże, to też i wiele zaszkodzi C++).

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

Możliwe, ale potrzebna będzie zmiana standardu, żeby zaimplementować Lambdy.
To, co w tej chwili zaimplementowano jako boost::lambda nadaje się tylko do
zabawy.

Boost jest pełen tego typu rozwiązań.


-- 
//  _    ___         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 02-03-2008, N o godzinie 09:59 +0000, Sektor van Skijlen pisze:

> Jedynym ficzerem, który jest zaimplementowany i zaakceptowany
> równocześnie to rvalue-reference; ficzer, który budzi niestety u mnie
> mieszane uczucia (jestem zdania, że nawet jeśli trochę pomoże, to też
> i wiele zaszkodzi C++).

Rvalue references pozwalają rozwiązać problem, który w C++ jest bardzo
ważny: przenoszenie obiektów (move semantics).

Teraz jest tak, że jeśli mamy vector<vector<T> >, to realokacja
zewnętrznego wektora pociąga za sobą zrobienie kopii wszystkich
wewnętrznych wektorów razem ze wszystkimi obiektami typu T, a potem
usunięcie oryginałów. Z move semantics wystarczy przenosić obiekty
wielkości sizeof(vector<T>), bez ruszania obiektów typu T. Nie jest
nawet potrzebna dostępność konstruktora kopiującego T.

Rvalue references nie są jedyną możliwą drogą uzyskania move semantics,
ale są całkiem dobrą drogą. Z rvalue references przenoszenie wyraża się
konstruktorem o sygnaturze podobnej do konstruktora kopiującego, przy
czym konstruktor ten jest wołany tylko w sytuacji, w której obiekt,
z którego przenosimy, nie będzie już później wykorzystywany i zostanie
tylko zawołany jego destruktor.

Można sobie wyobrazić inny interfejs opisywania przenoszenia obiektów
danego typu, np. zawarcie destrukcji oryginału już w czasie przenoszenia,
ale to by mogło być trudniejsze w poprawnym oprogramowaniu, zwłaszcza
w obliczu wyjątków, i zdecydowano się na rvalue references.

W językach, w których wartościami są referencje, a nie kopie obiektów,
co prawda pewne konstrukcje są mniej efektywne (pojawia się więcej
osobno zaalokowanych obiektów), ale za to cała komplikacja z move
semantics jest niepotrzebna. Ba, niepotrzebne są już konstruktory
kopiujące (tzn. sporadycznie może się przydać tworzenie kopii obiektu
danego rodzaju, ale to jest operacja biblioteczna jak każda inna,
która nie bierze udziału w semantyce przekazywania argumentów funkcji
itp.).

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

>> 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ść.
>
> Co to znaczy?

To znaczy, że pamięci dostępnej z roku na rok jest coraz więcej i z 
pewnością oprogramowanie nie rozwija sie w takim tempie, aby samym kodem 
można było tę pamięć od ręki zagospodarować.

>> 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.
>
> Sprzęt w "systemie wbudowanym"? Ty masz chyba marne pojęcie o takim 
> sprzęcie.
>
> Czy ty w ogóle wiesz, o jakich systemach mowa? Mowa o systemach, które 
> muszą
> się w najlepszym razie zmieścić *w całości* na płycie wielkości 1/4 
> laptopa. W
> całości, wraz ze wszystkimi podległymi sprzętami. I powtarzam - w 
> *najlepszym*
> razie, bo poza tym mamy jeszcze urządzenie wielkości telefonu komórkowego 
> lub
> zegarka, no w porywach jest to urządzenie POS (jak płaciłeś kiedyś kartą w
> sklepie, to wiesz, jak wygląda).
>
> Chcesz mi powiedzieć, że w takich urządzeniach można ten sprzęt 
> "niewielkim
> kosztem rozbudować"?

Trochę się napisałem softu dla systemów wbudowanych, więc raczej mam pojęcie 
o czym piszę. Pisałem soft dla urządzeń pomiarowych wielkości pudełka 
zapałek a także dla dużych, wieloprocesorowych urządzeń przemysłowych. Wiem 
jak to jest, gdy trzeba szukać oszczędności rzędu kilkunastu bajtów, bo 
program nie ładuje się do mikrokontrolera posiadającego 4KB pamięci kodu. 
Dzisiaj mogę mieć mikrokontroler w takiej samej obudowie i 64KB pamięci 
wbudowanej. Z pewnością, zanim uda mi się zagospodarować tę pamięć, będę 
mógł mieć jej znów kilkukrotnie więcej.

Z pewnością wybór mam o wiele większy niż kiedyś. To co mogę obecnie 
zrealizować, jest w coraz mniejszym stopniu ograniczane przez możliwości 
sprzętu.

Pozdrawiam.

- Bastek - 

Witam

Sebastian Nibisz wrote:

> To znaczy, że pamięci dostępnej z roku na rok jest coraz więcej i z
> pewnością oprogramowanie nie rozwija sie w takim tempie, aby samym kodem
> można było tę pamięć od ręki zagospodarować.

[...]

> Z pewnością, zanim uda mi się
> zagospodarować tę pamięć, będę mógł mieć jej znów kilkukrotnie więcej.

No to pisałeś systemy luźno upakowane :-).

Pisałem program dla DSP, gdzie każda wykonywana na przemian funkcjonalność
musiała swapować swoje śmieci na zewnętrznego flasha -- było ciasno, bardzo
ciasno. Co więcej stuktury musiały być elegancko popakowane, aby swapowanie
machać jedną komendą (specjalna odmiana memmove), bo to trwało, a to z
kolei przeszkadzało w narzuconym reżimie czasu -- trzeba było za każdym
razem pobrać dane ze swapa i na końcu pracy wrzucić je tam z powrotem.

Pozdrawiam.

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

Dnia Sun, 2 Mar 2008 11:53:14 +0100, Sebastian Nibisz skrobie:
> Trochę się napisałem softu dla systemów wbudowanych, więc raczej mam pojęcie 
> o czym piszę. Pisałem soft dla urządzeń pomiarowych wielkości pudełka 
> zapałek a także dla dużych, wieloprocesorowych urządzeń przemysłowych. Wiem 
> jak to jest, gdy trzeba szukać oszczędności rzędu kilkunastu bajtów, bo 
> program nie ładuje się do mikrokontrolera posiadającego 4KB pamięci kodu. 
> Dzisiaj mogę mieć mikrokontroler w takiej samej obudowie i 64KB pamięci 
> wbudowanej. Z pewnością, zanim uda mi się zagospodarować tę pamięć, będę 
> mógł mieć jej znów kilkukrotnie więcej.

> Z pewnością wybór mam o wiele większy niż kiedyś. To co mogę obecnie 
> zrealizować, jest w coraz mniejszym stopniu ograniczane przez możliwości 
> sprzętu.

Zgoda - możesz tam zmieścić *więcej* pamięci, niż niegdyś - problem polega
tylko na tym, że jak raz zaprojektujesz sprzęt, to dajmy mu nawet że zmieścisz
mu jakimś cudem 1GB pamięci, kiedykolwiek byś pisał jakieś oprogramowanie do
tego sprzętu (a aktualizacja firmware'u jest ostatnio bardzo modna), musisz
się w tym kawałku pamięci zmieścić. To nie jest komputer, do którego włożysz
sobie nową kostkę pamięci.


-- 
//  _    ___         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"

Sektor van Skijlen wrote:

> Natomiast dawno już zaimplementowany ficzer Variadic Templates (który, że
> się tak lubię chwalić, osobiście pomagałem testować :) jest w stanie (moim
> zdaniem) "produkcyjnym", a komitet standaryzacyjny nie raczył nawet
> jeszcze tego włączyć pod obrady.

W ostatnich draft-standardach już są variadic templates.

>> Z pewnością wybór mam o wiele większy niż kiedyś. To co mogę obecnie
>> zrealizować, jest w coraz mniejszym stopniu ograniczane przez możliwości
>> sprzętu.
>
> Zgoda - możesz tam zmieścić *więcej* pamięci, niż niegdyś - problem polega
> tylko na tym, że jak raz zaprojektujesz sprzęt, to dajmy mu nawet że 
> zmieścisz
> mu jakimś cudem 1GB pamięci, kiedykolwiek byś pisał jakieś oprogramowanie 
> do
> tego sprzętu (a aktualizacja firmware'u jest ostatnio bardzo modna), 
> musisz
> się w tym kawałku pamięci zmieścić. To nie jest komputer, do którego 
> włożysz
> sobie nową kostkę pamięci.

I tak i nie, wszystko zależy od specyfiki danego sprzętu. W większych, 
dobrze zaprojektowanych, systemach wbudowanych problem nie jest aż taki 
duży, bo jednostkę logiczną moża, niewielkim kosztem, wymienić razem z 
softem.

Pozdrawiam.

- Bastek - 

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. 

On 2 Mar, 11:53, "Sebastian Nibisz" <EB...@poczta.onet.pl> wrote:

> To znaczy, że pamięci dostępnej z roku na rok jest coraz więcej i z
> pewnością oprogramowanie nie rozwija sie w takim tempie, aby samym kodem
> można było tę pamięć od ręki zagospodarować.

"Software is getting slower faster than hardware is getting
faster." :-)

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

> "Software is getting slower faster than hardware is getting
> faster." :-)

Ano, trzeba jakoś motywować do rozwoju technologii :-)

Pozdrawiam.

- Bastek -

Dnia Sun, 2 Mar 2008 13:23:46 +0100, Sebastian Nibisz skrobie:
> >> Z pewnością wybór mam o wiele większy niż kiedyś. To co mogę obecnie
> >> zrealizować, jest w coraz mniejszym stopniu ograniczane przez możliwości
> >> sprzętu.
> >
> > Zgoda - możesz tam zmieścić *więcej* pamięci, niż niegdyś - problem polega
> > tylko na tym, że jak raz zaprojektujesz sprzęt, to dajmy mu nawet że 
> > zmieścisz
> > mu jakimś cudem 1GB pamięci, kiedykolwiek byś pisał jakieś oprogramowanie 
> > do
> > tego sprzętu (a aktualizacja firmware'u jest ostatnio bardzo modna), 
> > musisz
> > się w tym kawałku pamięci zmieścić. To nie jest komputer, do którego 
> > włożysz
> > sobie nową kostkę pamięci.

> I tak i nie, wszystko zależy od specyfiki danego sprzętu. W większych, 
> dobrze zaprojektowanych, systemach wbudowanych problem nie jest aż taki 
> duży, bo jednostkę logiczną moża, niewielkim kosztem, wymienić razem z 
> softem.

Tylko w przypadku, gdy ta "jednostka logiczna" jest względnie tania. Tak
niestety nie jest i jeszcze długo nie będzie.


-- 
//  _    ___         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"