The Most Dangerous Programming Mistakes - Slashdot
http://developers.slashdot.org/story/11/07/01/1258227/The-Most-Dangerous-Programming-Mistakes

XCHAOS: Shell tim neco (nevyjimkovyho) handluje, napriklad. Ale co ja vim, ja sem windowsak :-)

heleďte jedu na dovolenou, asi ode mě budete mít chvíli klid. čau.

ISTEVE: tedy, to moje try { } je implementované právě pomocí setjmp/longjmp - takže těžko říct. na co se to používá jiného kromě odchytávání chyb hlouběji ve funkcích, to fakt nevím.

XCHAOS: Dovol mi vypichnot jeden bod: "goto a setjmp/longjmp is right out. | Místo toho je k dispozici struktur try { fail() } except() { } vzdáleně podobná C++, Javě nebo Pythonu, která jejich funkčnost plně nahrazuje,"

Opravdu si myslis, ze v C plne nahradis setjmp/longjmp pomoci try/fail/except ala exception handling v C++?

XCHAOS: Hele, koukals na ten link na pure C implementaci toho auto-release poolu? Podle mne to resi vesmes vsechno co se snazis vyresit ty, akorat to neni tak leaky abstraction.

XCHAOS: napíšeš kód, který to vůbec neřeší - a když pak potřebuješ ten kód z nějakého důvodu zasmyčkovat (např. z CGI skriptu uděláš FastCGI skript, u webové aplikace) - tak tu smyčku celou dáš do jednoho velkého forget - Normalni clovek by si v takovehle situaci (kdyz uz by to chtel resit hnusnym hackem a ne spravne) napsal jednoduchej wrapper nad malloc, kterej by kazdej alokovanej blok pridal do nejakyho spojovyho seznamu a funkci, ktera by pak na konci te smycky vsechno v tom seznamu uvolnila. Jak to resi XChaos? Napise necitelny makra(*), ktery zmrzacej C a prinutej ho ridit se spoustou omezeni a vyjimek. Takhle vypada ta "inovace" ktere se tolik branim? 8)))

(*) samozrejme, ne "napise", ale "vysni si", protoze skutecna implementace neexistuje a dlouho existovat nebude. Kolik dalsich problemu se objevi az/pokud to napise, to je uplne jina kapitola. Ostatne, je to legracni kolik problemu jsem ti nasel v kodu, ktery jeste neexistuje 8))

REDGUY: éééééé... ty jo, asi takhle: napíšeš kód, který to vůbec neřeší - a když pak potřebuješ ten kód z nějakého důvodu zasmyčkovat (např. z CGI skriptu uděláš FastCGI skript, u webové aplikace) - tak tu smyčku celou dáš do jednoho velkého forget { } (a předtím inicializace proměnných té aplikace bude pochopitelně před tím forget { } ).

víceméně kdybys viděl desing-patterns pro které je to určené, tak by ti vše bylo jasnější (doufám). a neříkám, že nemáš svůj díl pravdy ! (představ si typicky načítání ze souboru - potřebuješ typicky většinu věcí zahodit, ale to co hledáš, ponechat v paměti, a neztrácet čas kopírováním.. já uvažuju o nějakém recycle(), které by dokázalo uvolnit paměť z kontextu ... jako že plošná dealokace by byla rychlá, ale existovala by možnost vyhodit i dílčí flák paměti, byť ne vždy by to bylo efektivní...)

XCHAOS: jednoduše se paměť uvolní na konci programu ROFL. Cili tvoje oblibene leaky. Na co v tom pripade potrebujes vlastni knihovnu kdyz presne to same umi malloc sam ale fakt nechapu.

Prosim, neutikej od otazky: proc by kdokoliv krome tebe mel pouzivat alokaci pameti pres tve kontexty? Jak bys to propagoval? Je to slozitejsi, omezuje to, mrzaci to C, kde je vyhoda? (krome velmi osobniho "nemuzu pred Redguyem priznat ze to je na nic", samozrejme)

BTW precedentem pro "registraci něčeho, co se má udělat nakonec", je funkce atexit() které se předávají handlery na funkce které se mají zavolat při exit() .. v C prakticky každou slepou uličku už někdo prošlapal.

pokud udělám obecné queue() na zařazení čeho si do fronty, tak to bude velké dobro, protože pak by se to vykonalo při každém escape() z jakéhokoliv scope - v podstatě v céčku chybí nějaké "atbreak" a "atreturn", které by bylo ekvivalentní tomu atexit()

REDGUY: jednoduše se paměť uvolní na konci programu - asi jako když použiješ malloc() bez free() :-) (jak myslíš, že teď kompiluju ty svoje testovací progámky, když kontexty ještě nemám hotové ? :-)

takhle, jestli mi to přijde jednodušší... kdysi dávno mě C okouzlilo právě tím malým množstvím základních stavebních kamenů. teď mi ale přijde, že některé stavební kameny tam poněkud chybí... samozřejmě jsou lidi, co si radši všechno DIY stylem poslepují sami z deseti instrukcí a dvaceti kanonických knihovních funkcí, a jsou lidé, kteří nemají problém naučit se nějakých 200-300 příkazů a předdefinovaných funkcí v nějakém vyšším jazyce, s tím že ty knihovny pak "všechno dělají za ně" - a oni se mohou tvářit, že všechno dělají sami.

někdo vozí auto do servisu, někdo si je schopen většinu základních závad opravit sám - co víc k tomu chceš slyšet ? není důvod, proč by to v případě psaní kódu mělo být jinak: někdo to poslepuje z prefabrikovaných kompenent, a je spokojen, jak to vyřešil, někdo jiný zase chce rozumět úplně všemu a do detailů vše řešit sám.

já nikoho nesoudím, pouze cílím na "šedou zónu" mezi těmito dvěma extrémy.

XCHAOS: Pred tim nez pouzijes some(typ, parametry) můžeš clenit kod na forget/remember bloky, aby si označil, které kontexty mají a které nemají být uvolněny. - co to? Pokud nepouziju cleneni na forget/remember bloky, jak bude fungovat uvolneni nepotrebne pameti alokovane pres some?

Nicmene, to podstatne jsi nezodpovedel - prijde ti to jednodussi nez dve pravidla a nezmrzacene C pri pouziti normalniho malloc/free? Kde presne je vyhoda, ziskana tema plus minus ctyrma pravidlama navic? (uplne nechavam stranou drobnost, ze escape je zatim jen jiskrou v tvem oku bez naznaku implementace, stejne jako try/fail/except, jejichz soucasna implementace je rozbita uplne stejne jako setjmp/longjmp)

REDGUY: ok

Co se musi naucit zacatecnik pouzivajici můj alokator?

* V nekterych pripadech se pamet alokuje pomoci some(typ, parametry) , v ostatnich pripadech pomoci the(typ, parametry). Pravidlo pro rozliseni techto pripadu je jednoduché a stručné a je podobné pravidlům pro použití určitého a neurčitého členu v angličtině. some(typ, parametry) alokuje paměť pouze v aktuálním kontextu, the() jí alokuje zcela nezávisle na čemkoliv.
* Pamet alokovana pomoci the(typ, parametry) se musi uvolnit pomoci free().
* Pamet alokovana pomoci some(typ, parametry) se uvolnovat nemusi.
* Pred tim nez pouzijes some(typ, parametry) můžeš clenit kod na forget/remember bloky, aby si označil, které kontexty mají a které nemají být uvolněny.
* Pokud použiješ upřesňující forget/remember, tak zapomen na prikaz return zevnitř jejich scope.
* Pokud jsi cetl nejakou knihu o normalnim C, nezapomen ze break/continue se v nekterych pripadech chovaji jinak nez bys cekal. Toto lze řešit tím, že se místo break napíše escape
* goto a setjmp/longjmp is right out.Místo toho je k dispozici struktur try { fail() } except() { } vzdáleně podobná C++, Javě nebo Pythonu, která jejich funkčnost plně nahrazuje, a fail() řeší uvolnění zdrojů scope podobně, jako escape.

XCHAOS: ano, je to strawan fallacy, čekal jsem, že to řekneš. - co je horsi? Clovek ktery pise nesmyslne argumenty protoze si neuvedomuje jejich nesmyslnost, nebo trouba ktery si to uvedomuje a _presto_ je pise?

samozřejmě - tohle není strawman fallacy - to je prostě můj soukromý odhad - jisteze neni. To je ad hominem.

nezlob se, ale tvoje příspěvky tak trochu vyznívají - že "postaru" je to vždycky dobře, a "novátorství" je k ničemu dobré. - jasne. To ze jsem ti napsal hned nekolik zpusobu jak napsat Cll1 tak aby fungovalo je "odpor k novatorstvi" 8))

XCHAOS: dyž použiješ jakoukoliv externí knihovnu ve svém C projektu, tak by sis asi měl přečíst dokumentaci - nevim o zadne knihovne pro C, ktera by v dokumentaci rikala "A mimochodem, kdyz pouzijes tuhle knihovnu, _nesmis_ pouzivat return uprostred funkce a break/continue se zacne chovat jinak nez jsi zvykly". Knihovny _rozsiruji_ jazyk, ne ho meni, lepe receno v tvem pripade spis mrzaci.

REDGUY: ano, je to strawan fallacy, čekal jsem, že to řekneš.

nezlob se, ale tvoje příspěvky tak trochu vyznívají - že "postaru" je to vždycky dobře, a "novátorství" je k ničemu dobré. počítám, že v 70tých letech by si asi nebyl v té vlasaté partičce, co vymýšlela Unix a C - a místo toho by si byl vášnivý obhájce Fortranu nebo Cobolu... (samozřejmě - tohle není strawman fallacy - to je prostě můj soukromý odhad :-)

XCHAOS: Neptam se co je prinosem pro me, ale pro uzivatele na ktere miris. A opravdu bych rad abys v tehle souvislosti odpovedel na [ REDGUY @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] , v tehle souvislosti je to velmi dulezita otazka.

REDGUY: no tak co začne jako nástroj pro mikroprojekty, to se může v budoucnu rozvinout... vezmi si takové PHP :-)

podívej, když použiješ jakoukoliv externí knihovnu ve svém C projektu, tak by sis asi měl přečíst dokumentaci: jak to incializovat, jak deinicalizovat, jaké jsou chybové stavy, jak je ošetřit, a v neposlední řadě - jak to používat. a typicky okopíruješ fragement nějakého ukázkového kódu. viz např.: http://www.metalshell.com/source_code/18/Mysql_Select.html

a teď mi řekni, proč by si někdo, kdo použije makro for_each() neměl nejdřív přečíst dokumentaci - stejně, jako si jí musí přečíst, když použije nějakou jakoukoliv jinou knihovní funkci, kterou napsal někdo jiný. dílem budou lidé asi více používat méně známé či frekventované instrukce, jako třeba "continue", dílem budou používat "escape" místo profláklého "break". to bude zdokumentované. stejně, jako zdokumentované, jak přistupovat z C k MySQL databázi.

souhlasím, že nezdokumentované chování je velká chyba a musí být vymýceno. pokud ale všechny ty "nedomyšlenosti" (na které hodně předem a dost vášnivě upozorňuješ, ale často i máš pravdu). myslím, že pokud tě můj projekt tak moc zaujal (jak tě evidentně zaujal), tak budeš mít určitě příležitost porovnávat zdoukumentované a skutečné chování, a jistě najdeš spoustu "špeků", se kterými jsem ve své idealistické naivitě nepočítal.

XCHAOS: proč se jeho hlavní náplní stalo dokazování, že snaha o rozvoj C jiným směrem, než k Objektive C/C++ je URČITĚ (a za všech okolností a pro všechny) špatná ? - lekce zdarma - _TOHLE_ je strawman fallacy. Nikdy nikdo tady nerikal, ze rozvoj C jinym smerem nez OC/C++ je urcite spatne a myslim ze to moc dobre vis. Jen o par zprav dozadu jsem ti ukazoval jake nastroje k rozvijeni C tim jinym smerem muzes pouzit misto zoufale nevhodneho Ceckoveho preprocesoru.