|
|
Prosba čtenářům o zpětnou vazbu
|
15.11.2005 11:04
Jan Němec
|
Jeden čtenář vyjádřil touhu po zadáních k samostatnému procvičení k jednotlivým dílům. Třeba k tomuhle dílu bych čtenářům doporučil napsat pomocí qsort třeba třídění řetězců, porovnání časů různých třídění, zamyšlení nad algoritmem quicksort a podobně. Myslíte si, že a) pod další díly o C++ mám na konec dílů pár podobných úkolů zadávat, b) k již napsaným dílům o C to dopsat zpětně do samostatných článků? (b) bych asi musel probrat s redakcí) Pokud na to máte nějaký názor, tak se vyjádřete. |
|
|
malloc
|
15.11.2005 12:33
Lukáš Jelínek
|
"Ve skutečných programech takhle opatrný nejsem..." Zrovna u malloc je opatrnost na místě. Běžně se sice nestává, aby se vyčerpala paměť, ale nastat to může. Pokud má program dělat nějakou vážnější činnost, měl by být napsán tak, aby to ustál (a případně se pak hned čistě ukončil). |
|
|
Re: malloc
|
15.11.2005 12:45
Jan Němec
|
Čekal jsem, že to od někoho schytám. malloc(sizeof(Zamestnanec)) je něco jiného než malloc(10000000), když neprojde to první, tak je to už dost vážné a o moc víc než čisté ukončení už udělat nepůjde, nejspíš neprojde ani log do souboru, volání řady knihovních funkcí a podobně. V tom druhém případě se obvykle naopak dá zachránit ledacos. Ale samozřejmě uznávám, že správný program se má snažit korektně reagovat i na malloc(1) == NULL. |
|
|
Re: malloc
|
15.11.2005 13:17
Aleš Hakl
|
No ono je na Unixu ve vetsine pripadu celkem redundantni overovat, jestli malloc nahodou nevratil NULL. Protoze on dost casto uspeje i tehdy, kdyz uz zadna volna pamet neni a program pak nekdy spadne na SIGSEGV.
Pokud jde o to, ze program dela neco kritickeho a mel by ustat takovehle extremni situace tak je asi nejrozumnejsi odchytavat vsechny podstatne signaly a zaridit se podle nich. |
|
|
Re: malloc & overcommit memory
|
3.12.2005 18:55
Tomáš "Atom" Klas
|
Ehm, tohle nastane pouze na systémech, které mohou přidělit víc paměti, než mají k dispozici (v Linuxu tzv. overcommit memory). Používá se to pro ošálení programů, které si alokují víc paměti, než ve skutečnosti potřebují. Pro kritické aplikace je velmi vhodné toto vypnout a raději přikoupit kus paměti navíc. Netestovat chybové stavy v "programech, které dělají něco kritického", je vyslovený hazard. Chyba se totiž dost často neprojeví hned, ale až v nějaké navazující části. Jediné správné místo na ošetření chyb je tam, kde vznikají - jen tam totiž víte, proč ta konkrétní chyba vznikla a jak na ni správně reagovat. V opačném případě si koledujete o dost nepředvídatelné chování celého programu. |
|
|
|
|
KOMENTARZE
|
Tylko zarejestrowani użytkownicy mogą dopisywać komentarze.
|
|
Szukanie oprogramowania
|
©Pavel Kysilka - 2003-2024 |
maillinuxsoft.cz | Design:
www.megadesign.cz
|