• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    XCHAOSANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API
    XCHAOS
    XCHAOS --- ---
    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í...)
    REDGUY
    REDGUY --- ---
    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)
    XCHAOS
    XCHAOS --- ---
    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()
    XCHAOS
    XCHAOS --- ---
    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.
    REDGUY
    REDGUY --- ---
    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)
    XCHAOS
    XCHAOS --- ---
    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.
    REDGUY
    REDGUY --- ---
    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))
    REDGUY
    REDGUY --- ---
    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.
    XCHAOS
    XCHAOS --- ---
    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 :-)
    REDGUY
    REDGUY --- ---
    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.
    XCHAOS
    XCHAOS --- ---
    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.
    REDGUY
    REDGUY --- ---
    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.
    XCHAOS
    XCHAOS --- ---
    REDGUY: víceméně, pokud pro tebe nebude přínos žádný, tak se to dá i docela dobře pochopit.

    nešlo by to prostě dohodnout tak, že tento klub je obecně o C a o věcech volně souvisejících s C ? 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á ?
    REDGUY
    REDGUY --- ---
    XCHAOS: je to pak prostě už "trochu jiný jazyk", stejně jako ObjectiveC je jiné, stejně jako C++ je jiné - ano. Jenomze Jak ObjC tak C++ jsou _univerzalni_ jazyky ve kterych muzu psat projekty vsech velikosti. Zatimco o Cll1 jsi ty sam napsal, ze je urcene na "mikroprojekty". Takze plan je takovej, ze na male veci budu pouzivat Cll1, ktere je _skoro_ C, ale ne uplne a nektere konstrukce z C ho spolehlive a hlavne bez varovani rozbijou, zatimco kdyz budu delat neco vetsiho, pouziju C? To bude zabava, pri prechodu z velkeho projektu na malej bastl si vzpomenout, co vsechno je v Cll1 rozbite a naopak, pri prechodu zpatky si uvedomit, ze ty obezlicky, nutne aby Cll1 fungovalo, uz nejsou zapotrebi.
    REDGUY
    REDGUY --- ---
    XCHAOS: jednoduše udělám jako "manuál" velkou tabulku všech svých maker, u kterých bude zmíněná jejich "kompatibilita" s break, continue, goto a return - takze soucasti jednoducheho, rychleho nastroje pro mikroprojekty urceneho pro zacatecniky (chapu to spravne?) bude velka tabulka ad-hoc nekompatibilit s normalnim C, kterou bude potreba se ridit protoze jinak se to rozbije? To ti prijde jako zjednoduseni? Co presne je podle tebe prinosem?
    XCHAOS
    XCHAOS --- ---
    REDGUY: když "víš co děláš", ano... ale ty prostě vycházíš z toho, že lidé co žádný toolkit nepoužití, _vždycky_ "vědí co dělají" - zatímco lidé, co ho použijí, _nikdy_ nevědí, co dělají.

    to ovšem není tak docela pravda - stejně jako můžeš zdokumentovat, že u open() je chybový kód filedescriptor<0 , zatímco u fopen() je to FILE==NULL, a lidi se to musí naučit, tak stejně tak programátoři v C<<1 si budou muset v dokumentaci přečíst, že místo break můžou univerzálně používat makro escape (v případech nespecializovaných smyček to udělá prostě break a basta). ano... je to pak prostě už "trochu jiný jazyk", stejně jako ObjectiveC je jiné, stejně jako C++ je jiné...
    XCHAOS
    XCHAOS --- ---
    REDGUY: tak zrovna to for_each() se chová slušně korektně pro continue; ... horší je to s break.

    uznávám, že např. nezavřený soubor při break; je nedomyšlenost (i když podle mě nikoliv neřešitelná). (ne všechny moje iterátory ovšem otevírají nějaký soubor...). tady by asi bylo nutné nějaké "escape", které by dělalo "přesně tu správnou věc" pro každé iterační makro.

    jednoduše udělám jako "manuál" velkou tabulku všech svých maker, u kterých bude zmíněná jejich "kompatibilita" s break, continue, goto a return. Nekompatibilitu s break (a v jistém smyslu s goto/return) bude nutné řešit makrem "escape", které bude něco jako "korektní break".

    jako programátor v Céčku jsem strávil mládí řešením, jak správně přečíst a pak zase zapsat textovej soubor s přesně správným počtem prázdných řádků na konci (typicky jeden nebo žádný). sice to je zajímavé intelektuální cvičení pro začátečníky - ale dost nesouhlasím s tím, že by toto nutně museli všichni znova podstupovat od začátku, a že by na to nešlo napsat nějaké triviální univerzální řešení po vzoru vyšších jazyků... ano, dost velký opruz zůstane hlídání vyjímek, alokací paměti, apod. - už skrze to to nikdy nebude "vyšší" jazyk... samozřejmě.
    REDGUY
    REDGUY --- ---
    XCHAOS: takhle, snad jsme se shodli, že možnost nevhodného použití returnu lidmi, co nevědí co dělají, je obecně VLASTNOST všeho v čistém C - je to chyba koncepce toho jazyka, resp. já to už nijak výrazněji nezhoršuji proti stavu, který je i beze mě. - boha jeho, to je neuveritelny. Tak jeste jednou a pomalu: kdyz vim co delam, _muzu_ return pouziv v C uprostred funkce bez problemu. I kdyz vim co delam, v Cll1 ho tak pouzit _nemuzu_. To je vyrazne _zhorseni_ stavu, _prosim_, prestan uz s timhle blabolem ze "nic nezhorsujes".
    REDGUY
    REDGUY --- ---
    XCHAOS: for_each & spol jsou nejmensim problemem. I kdyz samozrejme predstava ze bych musel nekdy hledat je chyba v #define for_each(ONE_T,ONE,ALL_T,...) for(_init_##ONE_T##_##ALL_T(_head_##ONE_T##_##ALL_T(ONE,__VA_ARGS__));_test_##ONE_T##_##ALL_T(ONE,__VA_ARGS__) || _free_##ONE_T##_##ALL_T(ONE,__VA_ARGS__);_next_##ONE_T##_##ALL_T(ONE,__VA_ARGS__)) je fyzicky bolestiva.

    Kde to zoufale nefunguje je tvoje snaha vytvaret nove struktury v C, ktere proste nejde trivialne namapovat na nejaky for/while. Viz rozbitej return/goto/break/continue, to vsechno kvuli jen napul fungujicim "kontextum".
    XCHAOS
    XCHAOS --- ---
    JACHYMKO: takhle, snad jsme se shodli, že možnost nevhodného použití returnu lidmi, co nevědí co dělají, je obecně VLASTNOST všeho v čistém C - je to chyba koncepce toho jazyka, resp. já to už nijak výrazněji nezhoršuji proti stavu, který je i beze mě.

    ano, tak trochu mám pocit, že pokud by člověk psal opravdu čistě strukturovaný kód, s využitím systému odchytávání vyjímek, tak asi nebude mít až tolik případů, kdy by měl z jedné funkce více returnů:

    1) obecně, pokud je to void funkce a nevrací žádnou hodnotu, tak jí lze nejspíš rozdělit na více dílčích funkcí

    2) ad příklad s tou deinicializací - ona správná odpověď asi je, že toto by se napsalo "C-objektově" - tedy všechny ty lokální proměnné by byly ve struct, a ten de-inicializátor by byla funkce, které se předává pointer na struct a kterou lze zavolat z více míst...

    2) pokud funkce vrací nějaký výsledek, tak skutečně její vnitřní větvení, ukončené různými návratovými hodnotami - včetně nastavení hodnot indikujících chybu, apod. - by se mohla "sbíhat" před místem, kde se vrací ta návratová hodnota. opravdu jsem takto viděl jiné lidi programovat a nemyslím, že je to špatný přístup.
    Kliknutím sem můžete změnit nastavení reklam