[SGCL] Odśmiecania współbieżnego ciąg dalszy
Sebastian Nibisz
Nadarzyła się okazja, aby zweryfikować działanie biblioteki SGCL na
platformie z procesorem wielordzeniowym.
Już po pierwszych testach okazało się, że biblioteka nie radzi sobie zbytnio
na takiej konfiguracji. Postanowiłem zweryfikować swoje założenia odnośnie
koncepcji współbieżnego działania systemu GC w bibliotece i w miarę
możliwości spróbować ją poprawić.
Po głębszej analizie algorytmu doszedłem do wniosku, że ogólne założenia
współbieżnej pracy systemu GC były prawidłowe. Biblioteka posiadała szereg
błędów w implementacji, które w szczególności ujawniały sie na platformie
wieloprocesorowej.
Biblioteka została gruntownie przebudowana. Pierwotne założenie, braku
potrzeby synchronizacji wątków aplikacji z wątkiem systemu GC, zostało
zachowane. Dodałem wsparcie dla systemów 64-bitowych, poprzez zniesienie
ograniczenia wielkości mapowanej pamięci (4GB).
Ze względu na wykorzystanie w bibliotece funkcji systemowych Windows,
biblioteka nadal przeznaczona jest jedynie na tę platformę systemową. Na
chwilę obecną, starałem się skupić na systemie, który znam najlepiej.
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.
SGCL nie wykorzystuje już biblioteki boost.
Zainteresowanych zachęcam do pobrania najnowszych plików projektu:
http://sourceforge.net/projects/sgcl/
Pozdrawiam.
- Bastek -
Paweł
> 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
Adam Karpierz
> 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
Sebastian Nibisz
> 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 -
Adam Karpierz
Jeszcze jedno pytanie z gatunku naiwnych:
Czym sie rozni/codaje wiecej ta biblioteka
w stosunku od boostowego/MSowego
shared_pointer-a ?
AK
Sebastian Nibisz
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 -
Artur Bać
> 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
Sebastian Nibisz
>> 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 -
Adam Karpierz
> 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
Artur Bać
Nie cieprie GC :) to sie wogole nie sprawdza przy przetwarzaniu duzej
ilosci danych , duze chwilowe alokacje, przynajmiej ten z NET.
Seweryn Habdank-Wojewódzki
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
\/\/
Sebastian Nibisz
> 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 -
Sebastian Nibisz
>>> 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 -
sop3k
A jesli masz go pod ręką mógłbys przesłąć na sop3k at 02 dot pl? bede wdzieczny
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Sebastian Nibisz
> wdzieczny
Wysłałem.
Pozdrawiam.
- Bastek -
Adam Karpierz
> 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
Adam Karpierz
AK
Artur Bać
> 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);
Seweryn Habdank-Wojewódzki
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).
Jedrzej Dudkiewicz
>>>> 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
Sebastian Nibisz
>> 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 -
Sebastian Nibisz
> 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 -
Jedrzej Dudkiewicz
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
Sebastian Nibisz
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 -
Jedrzej Dudkiewicz
>>>> 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
Sebastian Nibisz
>> 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 -
Seweryn Habdank-Wojewódzki
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.
Sektor van Skijlen
> >> 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"
Piotr Wyderski
> 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
Sebastian Nibisz
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 -
Sebastian Nibisz
>
> 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 -
Sektor van Skijlen
> 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.
Marcin ‘Qrczak’ Kowalczyk
> 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
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
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.
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
Piotr Wyderski
> 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
Sebastian Nibisz
>> 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 -
Johnny
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
Sebastian Nibisz
>> 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 -
Piotr Wyderski
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
Sebastian Nibisz
> 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 -
Sebastian Nibisz
>> 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 -
Artur Bać
>> 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
Maciej Sobczak
> >> 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
Sebastian Nibisz
>> 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 -
Michał 'Khorne' Rzechonek
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
Sebastian Kaliszewski
>>>> 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 Kaliszewski
>>> 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) :).
Piotr Wyderski
> 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
Adam Karpierz
<etho...@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
Adam Karpierz
<etho...@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
Adam Karpierz
> 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
Adam Karpierz
>> Ale to świadczy jedynie o tym, że koder jest niedouczony. Nawet ucząc się
>> tylko języka z GC, koder powinien sie dowiedzieć co to jest GC i do czego
>> tego wykorzystywać nie można.
>
> Ile % koderów piszacych wylacznie w PHP, C#, Java ma o tym pojecie ?
> Sadze ze mniej niz 1%.
Dla mnie pierwszy lepszy Ayatollah C++ jest tym czym ten
wysmiewany(?) przez Ciebie koder Javy czy C#.
Dlaczego ? Ano dlatego ze Ayatollah nawet nie slyszal co to jest np:
cal by name czy call by need
Jest wiec zwyczajnie niedouczonym koderem.
> Ostatnio prowadzilem dyskuje tj tlumaczylem koledze ktory od lat pisze
> apliakcje webowe w PHP i jest dobry w tym co robi, na czym polegaja
> roznice przekazania paramteru przez referencje const referencje wskaznik
> przez wartosc.
Bo to glupie.
Do dzisiaj nie moge sie nadziwic jak mozna wprowadzac tak idiotyczne
slowo jak const zamiast np in.
Natomiast wskazniki ?
A _po co_ w ogole potrzebne wskazniki jako parametry, jesli sa
rerefencje i (tfu) const referencje ?
Chyba po to aby utrudniac zycie.
> Sedno w tym ze wiekszosc nie ma o tym pojecia a takie slowa jak stos czy
> sterta to szyszeli ze sa.
I bardzo dobrze !
Po jaka cholere programiscie 'wiedza' gdzie jest umieszczana zmienna lokalna
?
Jemu wystarczy wiedza ze jest dostepna jedynie w jej scope _i tyle_.
Poza tym wskaz mi _gdzie_ stos procesora wystepuje w standardzie C ?
> Ich niedouczenie wynika wlasnie z tego faktu iz oni nie musza tego
> wiedziec aby napisac program, bo robi to za nich automat.
No wlasnie !
I o to chodzi !
AK
Sebastian Nibisz
> 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 -
Adam Karpierz
> 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
Artur Bać
>> Teraz postaw się w sytuacji (która mnie dotknęła) wytłumacz to
>> przeciętnemu koderowi języka z GC (i tylko jednego języka, bo tacy
>> jednojęzykowcy są tanii).
>>
>> Co mu powiesz?
>
> Powiem mu, że jak plik otworzył, to musi dopilnować jego zamknięcia. Cała
> filozofia.
Przyklad z niby bardziej odpornego C# od javy, pokazujacy jak bardzo nie
swiadomosc detali lub poleganie na automacie krzywdzi i jak latwo mozna
pasc ofiara automatow i GC.
Sam w to wpadlem swego czasu i niestety zabolalo, aplikacja byla juz
wersja produkcyjna i zawiodla w momncie gdy bylo ztroche a pozno na
zabawe z kodem.
void Cos() {
FileStream x = new ....
using( BinaryWriter br = new BinaryReader (x) ) {
//blabla
}
}
Pytanie 1:
Kiedy fs zwolni zasoby 'handle' do plikow.
a) po zakonczeniu scope using
b) po zakonczeniu scope Cos
c) po zakonczeniu programu lub gdy gc sie zlituje tj niewiadomo kiedy.
odpowiedz prawidlowa
c) br oleje fs, a destruktor fs niewiadomo kiedy bedzie wykonany.
dokladnie dzieje sie tak chyba z tego co rozumie iz dopuki ostatnia
referencja nie zginie doputy wszelkie wywolania Dispose() zostana
zignorowane a tu mamy az 2 kopie jedna posiada BianryWriter a druga jest
zadeklarowana w obrebie metody.
Tak wiec zycze powodzenia z wolaniem metody Close na BianryWriter.
FaileStream z NET ma implementacje:
public virtual void Close()
{
this.Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (disposing && (this._asyncActiveEvent != null))
{
this._CloseAsyncActiveEvent(Interlocked.Decrement(ref
this._asyncActiveCount));
}
}
private void _CloseAsyncActiveEvent(int asyncActiveCount)
{
if ((this._asyncActiveEvent != null) && (asyncActiveCount == 0))
{
this._asyncActiveEvent.Close();
this._asyncActiveEvent = null;
}
}
Pytanie 2:
Kiedy progrmaista sie o tym zorientuje
a) mozliwe ze nigdy
b) gdy aplikacja sypnie sie u klienta
c) w trakcie testow
d) ciezko powiedziec, wszystkie mozliwosci sa relane
najblizsza prawdy
d) a jak sie sypnie to komunikat exception wyzuci sie z bardzo
idiotycznym problemem kernela32.
W tak prostych przypadkach siadmosc kiedy zasoby sa zwalniane jest
przydatna bo pozwala zrozumiec istote problemu.
Marcin ‘Qrczak’ Kowalczyk
> c) po zakonczeniu programu lub gdy gc sie zlituje tj niewiadomo kiedy.
>
> odpowiedz prawidlowa
> c) br oleje fs, a destruktor fs niewiadomo kiedy bedzie wykonany.
Nieprawda.
Nie mam pod ręką dokumentacji do .NET, ale ze źródeł Mono
mono-1.2.6/mcs/class/corlib/System.IO/BinaryWriter.cs:
public virtual void Close() {
Dispose (true);
}
void IDisposable.Dispose() {
Dispose (true);
}
protected virtual void Dispose (bool disposing)
{
if (disposing && OutStream != null)
OutStream.Close();
buffer = null;
m_encoding = null;
disposed = true;
}
> dokladnie dzieje sie tak chyba z tego co rozumie iz dopuki ostatnia
> referencja nie zginie doputy wszelkie wywolania Dispose() zostana
> zignorowane
Nic podobnego. Dispose jest zwykłą metodą, a using woła Dispose.
Nie ma żadnego liczenia referencji.
Artur Bać
> Dnia 27-02-2008, Śr o godzinie 20:13 +0100, Artur Bać pisze:
>
>> c) po zakonczeniu programu lub gdy gc sie zlituje tj niewiadomo kiedy.
>>
>> odpowiedz prawidlowa
>> c) br oleje fs, a destruktor fs niewiadomo kiedy bedzie wykonany.
>
> Nieprawda.
> Nic podobnego. Dispose jest zwykłą metodą, a using woła Dispose.
> Nie ma żadnego liczenia referencji.
>
BinryWriter wola swoje Dispose ktore wola Dispose FaileStream
Nie bede polemizowal z kodem mono , wkleilem kod filestream z NET
uzyskany NET reflektorem i widac tam liczenie referencji i igonorowanie
Close() samego FileStream. W tym wypdaku wolanie Close BinaryWriter nic
nie zmienia.
A pozatym szukalem powodu exception przez pare godzin mowiacego o
przekroczeniu ilosci handle do plikow rzucenego przez kernel ...
Seweryn Habdank-Wojewódzki
Sebastian Kaliszewski wrote:
>> Co mu powiesz?
>
> Powiem mu, że jak plik otworzył, to musi dopilnować jego zamknięcia. Cała
> filozofia.
A on zapyta: Czemu zamykać, jeśli "sam się zamknie" [w domyśle "gdzieś
kiedyś"].
Po za tym, wspomniałeś wcześniej obłędach. Jak zamykasz pliki w Javie w
sytuacjach awaryjnych? To samo masz w Javie problem z wyjkątkami i
wykonaniem zamknięcia pliku. Musisz przeanalizować wszystkie możliwe
ścieżki wykonanania. To w C i C++ jest naturalne, w Javie jest to extra
umiejętność. W każdym razie mój testwy koder Java miał kłopoty z taką
analizą. Może to moja wina, że skomplikowałem zadanie.
> Słaba to metryka. Co z tego, że coś ma miliard użytkowników, skoro żyje z
> tego jeden człowiek (zostało napisane raz i już sobie jest). Dużo
> ciekawsza jest metryka w czym większy procent ludzi pisze. A tu C++ jedzie
> w dół, coraz ostrzej.
Tak wiem, ta metryka jest bardzo dobra dla Pythona.
> BTW. W 6 na 7 podanych przez ciebie przypadkach mowa jest o C a nie C++.
> Z tego wynika jedno -- o ile C zostanie, bo zapotrzebowanie na "przenośny
> assembler" jest i w przewidywalnej przyszłości będzie, to C++ nie ma
> takiej "z góry upatrzonej pozycji na którą może się wycofać".
Nie ma to znaczenia. Ja i tak pozostanę Ajatollahem C++. A dyskusja dotyczy
także C bo ten język RÓWNIEŻ nie ma GC.
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
Sebastian Nibisz
> FileStream x = new ....
> using( BinaryWriter br = new BinaryReader (x) ) {
> //blabla
> }
> }
>
> Pytanie 1:
> Kiedy fs zwolni zasoby 'handle' do plikow.
Kiedy GC przyjdzie na to ochota. Nie zawołałes Dispose dla obiektu
FileStream, tak więc skazałeś się na łaskę systemu GC.
Powinno byc tak:
using (FileStream fs = new FileStream(...))
{
using (BinaryWriter br = new BinaryWriter(fs))
{
// blabla
}
}
Pozdrawiam.
- Bastek -
Artur Bać
> Kiedy GC przyjdzie na to ochota. Nie zawołałes Dispose dla obiektu
> FileStream, tak więc skazałeś się na łaskę systemu GC.
>
> Powinno byc tak:
>
To akurat wiem.
Ale irytujace w tym jest to ze wszystkie referencje musza zawolac
Close/Dispose inaczej zasoby -> handle do plikow nei sa zwalniane.
I obawiam sie ze nie jeden juz sie nacial na to.
Marcin ‘Qrczak’ Kowalczyk
> wkleilem kod filestream z NET
> uzyskany NET reflektorem i widac tam liczenie referencji i igonorowanie
> Close() samego FileStream.
http://msdn2.microsoft.com/en-us/library/system.io.filestream.dispose.aspx
"Dispose() - Infrastructure. Releases all resources used by the Stream.
(Inherited from Stream.)"
Nie ma mowy o jakimś zliczaniu referencji.
Implementacja w Mono:
~FileStream ()
{
Dispose (false);
}
#if NET_2_0
protected override void Dispose (bool disposing)
#else
protected virtual void Dispose (bool disposing)
#endif
{
if (handle != MonoIO.InvalidHandle) {
FlushBuffer ();
if (owner) {
MonoIOError error;
MonoIO.Close (handle, out error);
if (error != MonoIOError.ERROR_SUCCESS) {
// don't leak the path information for isolated storage
string fname = (anonymous) ? Path.GetFileName (name) : name;
throw MonoIO.GetException (fname, error);
}
handle = MonoIO.InvalidHandle;
}
}
canseek = false;
access = 0;
if (disposing) {
buf = null;
}
}
Jak widać, nie ma żadnego zliczania referencji (pole "owner" z reguły
jest true, jest false chyba tylko dla stdin/stdout/stderr).
Artur Bać
> A on zapyta: Czemu zamykać, jeśli "sam się zamknie" [w domyśle "gdzieś
> kiedyś"].
Dobre , usmialem sie ale masz w tym duzo racji.
Typowe myslenie przecierz ja juz nie korzystam z tego, 'wali mnie to'.
Marcin ‘Qrczak’ Kowalczyk
pisze:
> > Powiem mu, że jak plik otworzył, to musi dopilnować jego zamknięcia. Cała
> > filozofia.
>
> A on zapyta: Czemu zamykać, jeśli "sam się zamknie" [w domyśle "gdzieś
> kiedyś"].
Odpowiesz: żeby nie marnować uchwytów pliku, których system operacyjny
nie pozwala mieć naraz zbyt wiele.
Naprawdę nie widzę problemu.
Seweryn Habdank-Wojewódzki
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.
Sebastian Nibisz
>> filozofia.
>
> A on zapyta: Czemu zamykać, jeśli "sam się zamknie" [w domyśle "gdzieś
> kiedyś"].
Auto na noc też pewnie zostawia z otwartymi na roścież dżwiami. W nocy
często wieje, to mu sie zamkną.
> Po za tym, wspomniałeś wcześniej obłędach. Jak zamykasz pliki w Javie w
> sytuacjach awaryjnych? To samo masz w Javie problem z wyjkątkami i
> wykonaniem zamknięcia pliku. Musisz przeanalizować wszystkie możliwe
> ścieżki wykonanania. To w C i C++ jest naturalne, w Javie jest to extra
> umiejętność. W każdym razie mój testwy koder Java miał kłopoty z taką
> analizą. Może to moja wina, że skomplikowałem zadanie.
W C# do tego służy blok finally.
Pozdrawiam.
- Bastek -
Maciej Sobczak
> Do dzisiaj nie moge sie nadziwic jak mozna wprowadzac tak idiotyczne
> slowo jak const zamiast np in.
const nie jest "zamiast" - te dwie rzeczy rozwiązują różne problemy,
tylko częściowo się pokrywające.
Ale możesz się dziwić dalej.
> Natomiast wskazniki ?
> A _po co_ w ogole potrzebne wskazniki jako parametry, jesli sa
> rerefencje i (tfu) const referencje ?
> Chyba po to aby utrudniac zycie.
A może po to, żeby można było przekazać NULL?
Albo po to, żeby można było przekazać wskaźnik całkowicie oderwany od
typu (void)?
Albo może po to, żeby można było przekazać wskaźnik do czegoś, co nie
ma sensu jako wartość (np. wskaźnik do funkcji) i dlatego nie dałoby
się zrobić do tego referencji?
BTW - napisałeś tu niedawno, że Ada jest wzorem języków imperatywnych.
Wnioskuję, że nie słyszałeś o tym, że w Adzie wskaźniki mogą być
parametrami podprogramów. Sam sobie odpowiedz, po co.
> Po jaka cholere programiscie 'wiedza' gdzie jest umieszczana zmienna lokalna
> ?
> Jemu wystarczy wiedza ze jest dostepna jedynie w jej scope _i tyle_.
Przecież chodzi o to samo. Pojęcie stosu jest sztuczne, co sam nawet
(!) zauważyłeś:
> Poza tym wskaz mi _gdzie_ stos procesora wystepuje w standardzie C ?
No właśnie. Stos to pojęcie potoczne opisujące model życia obiektów.
Zagnieżdżanie zakresów jest modelowane przez wydłużający się "stos"
obiektów.
Jeżeli ktoś mówi "zmienna x jest na stosie" to w ten sposób opisuje
jedynie relację jaka zachodzi pomiędzy czasem życia tej zmiennej a
czasem życia innych zmiennych z innych zakresów.
> > Ich niedouczenie wynika wlasnie z tego faktu iz oni nie musza tego
> > wiedziec aby napisac program, bo robi to za nich automat.
>
> No wlasnie !
> I o to chodzi !
Powodzenia.
Maciej Sobczak
> 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?
Adam Karpierz
> Po za tym, wspomniałeś wcześniej obłędach.
> Jak zamykasz pliki w Javie w sytuacjach awaryjnych?
> To samo masz w Javie problem z wyjkątkami i
> wykonaniem zamknięcia pliku. Musisz przeanalizować wszystkie możliwe
> ścieżki wykonanania.
A co to Pan Kolega finally nie uzywa ?
'Przyzwyczajenie' z C++ ?
AK
Adam Karpierz
AK
Adam Karpierz
> 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
Seweryn Habdank-Wojewódzki
Adam Karpierz wrote:
A "finally" zwalnia z myślenia?
Finally samo się nie napisze!
Napisanie finally przecież kosztuje 2 linie kodu, zapomniał Pan o tym?
> 'Przyzwyczajenie' z C++ ?
W C++ RAII w pewnych sytuacjach pomaga i nie trzeba pisać "finally".
Smart_ptr sam zawoła destruktor kiedy potrzeba -- czysta oszczędność.
Seweryn Habdank-Wojewódzki
Marcin ?Qrczak? Kowalczyk wrote:
>> A on zapyta: Czemu zamykać, jeśli "sam się zamknie" [w domyśle "gdzieś
>> kiedyś"].
>
> Odpowiesz: żeby nie marnować uchwytów pliku, których system operacyjny
> nie pozwala mieć naraz zbyt wiele.
>
> Naprawdę nie widzę problemu.
Ja też nie. Ale są tacy co widzą :-). BTW używając wzorca
projektowego "język C" nie muszę gadać więcej niż powiedziałem.
Michał 'Khorne' Rzechonek
> 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
Adam Karpierz
>> A co to Pan Kolega finally nie uzywa ?
>
> A "finally" zwalnia z myślenia?
> Finally samo się nie napisze!
>
> Napisanie finally przecież kosztuje 2 linie kodu, zapomniał Pan o tym?
Panie Wojewodzki, niech mnie Pan nie oslabia :)
Prosciej w/g Pana przeanalizowac wszytskie
sciezki wywolania (bo o tym Pan pisal) niz uzyc finally ?
O tempora o mores !
AK
Adam Karpierz
> 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
Sebastian Kaliszewski
>>> Co mu powiesz?
>>
>> Powiem mu, że jak plik otworzył, to musi dopilnować jego zamknięcia. Cała
>> filozofia.
>
> A on zapyta: Czemu zamykać, jeśli "sam się zamknie" [w domyśle "gdzieś
> kiedyś"].
A mu odpowiem: bo może otworzyć najwyżej N (N jest małe) plików.
> Po za tym, wspomniałeś wcześniej obłędach. Jak zamykasz pliki w Javie w
> sytuacjach awaryjnych?
O finally słyszałeś?
> To samo masz w Javie problem z wyjkątkami i
> wykonaniem zamknięcia pliku. Musisz przeanalizować wszystkie możliwe
> ścieżki wykonanania.
Ależ skąd.
> To w C i C++ jest naturalne, w Javie jest to extra
> umiejętność.
Ależ skąd.
BTW. przyjrzałem się bliżej tej naturalności z C++ i wyszło, że w 95% używam
jej do tego, by obejść brak standardowego GC albo brak konstrukcji typu
using / with / finally (odpowiednio C# / Python / Java & C# & Python).
> W każdym razie mój testwy koder Java miał kłopoty z taką
> analizą. Może to moja wina, że skomplikowałem zadanie.
>
>> Słaba to metryka. Co z tego, że coś ma miliard użytkowników, skoro żyje z
>> tego jeden człowiek (zostało napisane raz i już sobie jest). Dużo
>> ciekawsza jest metryka w czym większy procent ludzi pisze. A tu C++
>> jedzie w dół, coraz ostrzej.
>
> Tak wiem, ta metryka jest bardzo dobra dla Pythona.
To nie ma znaczenia dla czego jest dobra. Znaczenie ma dla kogo jest dobra.
A jest dobra np. dla producentów rozmaitych narzędzi wokołojęzykowych,
bibliotek itd.
>> BTW. W 6 na 7 podanych przez ciebie przypadkach mowa jest o C a nie C++.
>> Z tego wynika jedno -- o ile C zostanie, bo zapotrzebowanie na "przenośny
>> assembler" jest i w przewidywalnej przyszłości będzie, to C++ nie ma
>> takiej "z góry upatrzonej pozycji na którą może się wycofać".
>
> Nie ma to znaczenia. Ja i tak pozostanę Ajatollahem C++. A dyskusja
> dotyczy także C bo ten język RÓWNIEŻ nie ma GC.
To może dotyczy również assemblera, Fortha, Fortranu czy czego tam jeszcze,
bo one również nie mają standardowego GC? Nie naciągaj.
--
"Never underestimate the power of human stupidity" -- L. Lang
Artur Bać
>> 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
Adam Karpierz
Czy w 1.1 nie da sie zrobic Menu u Toolbara ?
AK
Jedrzej Dudkiewicz
> Destruktory z C++ są rozwiązaniem cienkim. Cienkim z jednego, prozaicznego,
> ale kluczowego(!), powodu. Z poziomu destruktora nie da się poinformować o
> błędzie
Czy możesz podać jakiś spektakularny przykład, gdzie taka potrzeba
występuje?
JD
Artur Bać
> 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
Adam Karpierz
> 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
Michał 'Khorne' Rzechonek
> PS: Akurat GUI jest w pelni przenosne (MFC).
> 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
Adam Karpierz
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
Michał 'Khorne' Rzechonek
> > Znaczy... na co przenośne? Na Linuksa, Solarisa i OS X?
> Dokladnie.
MFC? Czy ja czegoś nie wiem?
--
Khorne
Adam Karpierz
> MFC? Czy ja czegoś nie wiem?
Chyba tak.
Tak sie wlasnie tworza mity.
MFC _jest_ przenosne.
Nieprzenosny jest np boost.
AK
Marcin ‘Qrczak’ Kowalczyk
> 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.
Artur Bać
> Użytkownik "Michał 'Khorne' Rzechonek" <kho...@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.
Seweryn Habdank-Wojewódzki
Adam Karpierz wrote:
> Użytkownik "Seweryn Habdank-Wojewódzki" <shw_...@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.
Sektor van Skijlen
> 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"
Sektor van Skijlen
> 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ń.
Marcin ‘Qrczak’ Kowalczyk
> 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.).
Sebastian Nibisz
>> 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 -
Seweryn Habdank-Wojewódzki
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.
Sektor van Skijlen
> 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.
Wojciech Jaczewski
> 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.
Sebastian Nibisz
>> 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 -
the_foe
> 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.
Maciej Sobczak
> 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
Sebastian Nibisz
> faster." :-)
Ano, trzeba jakoś motywować do rozwoju technologii :-)
Pozdrawiam.
- Bastek -
Sektor van Skijlen
Tylko w przypadku, gdy ta "jednostka logiczna" jest względnie tania. Tak
niestety nie jest i jeszcze długo nie będzie.