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.

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

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

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

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

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

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.

REDGUY: no, v době mých prvních pokusů jsem je skutečně používal špatně - resp. vygeneroval jsem hrozné množství maker, a chtěl jsem dělat jejich speciální verzi pro každý myslitelný datový typ, apod. ... skutečně jsem i sám sebe poměrně rychle přesvědčil, že směřuju do slepé uličky.

vezmi si ale, že třeba standardizované operace va_start(), va_arg() a va_end() jsou taky většinou (plaform-dependend) implementované jako makra, která jsou VELICE podobná přístupu, který razím já.

a teď si představ, že bych udělal for_each(int, .., args, ...) {}, for_each(str, ..., args ...) {} ... které by šlo použít u funkcí s proměnným počtem argumentů - ale bylo by to celé daleko čistší ?

a pokud to moje 4+ argumentové for_each() bude skutečně univerzální pro celou řadu iterací, které jsou v C tak nějak "nakousnuté", ale vlastně se pokaždé dělají jinak ?

Hele, XChaosi, fakt bych moc rad abys mi odpovedel na tohle, pro jistotu to prikopiruju sem:

začátečník, kterého budeš učit céčko ty, každopádně nabude dojmu, že z C funkce je možné kdykoliv bez rozmyšlení utéct - nikolvek. Zacatecnik, ktereho budu ucit programovat, se nauci tohle:

* Pamet se alokuje pomoci malloc
* Kazdou alokovanou pamet musis uvolnit pomoci free

Co se musi naucit zacatecnik pouzivajici tvuj alokator?

* V nekterych pripadech se pamet alokuje pomoci xchaos_alloc, v ostatnich pripadech pomoci malloc. Pravidlo pro rozliseni techto pripadu je "..." (zhruba odstavec textu).
* Pamet alokovana pomoci malloc se musi uvolnit pomoci free.
* Pamet alokovana pomoci xchaos_alloc se uvolnovat nemusi.
* Pred tim nez pouzijes xchaos_alloc musis spravne clenit kod na forget/remember bloky
* Pokud jsi cetl nejakou knihu o C, tak zapomen na prikaz return jinde nez na konci funkce.
* Pokud jsi cetl nejakou knihu o normalnim C, nezapomen ze break/continue se v nekterych pripadech chovaji jinak nez bys cekal.
* goto a setjmp/longjmp is right out.

Zapomel jsem na neco? Co ti prijde jednodussi?

JACHYMKO: asi taková, jako že tebe "donutím" začít vyvíjet céčkové aplikace pro Linux, místo pro mikrosoftí platformy ?

XCHAOS: vidím, že si konečně vzal na milost makra Ach jo. Psal jsem nekdy ze obecne pouzivat makra je spatne? Nepsal. Psal jsem, ze spatne je zpusob jakym je pouzivas ty.

že si uvědomuješ závažnost problému s random-return z plain-C funkce - dtto. Ano, je potreba uvolnovat zabrane zdroje. V C to jde (kdyz na to clovek mysli) i pri pouzit returnu uprostred funkce, v tvem bastlu return uprosted pouzit nemuzes vubec.

velká spousta programátorů tento problém řeší tím, že k úniku z funkce používá místo tebou navrhovaných maker např.nějaké goto na deinicializační blok.... fakt jsem to takto viděl už mnohokrát. - LOL. Jeste nedavno jsi psal, ze, cituji "v C [se] doporučuje použít goto max. jen na ošetření chyb (s následným rychlým ukončením programu, pokud možno)". Tak jak to je? Prosim, pokud uz si s prstu cucas ucelove argumenty podle toho co zrovna potrebujes, _prosim_, aspon si je pamatuj a bud konzistetni. A btw, samozrejme ze pouziti goto tak jak ho tady popisujes problem tvych "kontextu" neresi, protoze je rozbije uplne stejne jako return.

Nicmene, psal jsi neco o milionu zpusoby kdy i v normalnim C nelze pouzit return uprostred funkce. U jednoho jsem ti ukazal jak na to, takze bych prosil nejaky dalsi z tech zbylych 999 999?

REDGUY: ad "lepší C" - uvažoval jsem jít na to inkrementálně:

C<<1 by byla sada maker a funkcí, kterou vyvíjím teď
C<<2 by byl pre-compiler, který by konvertoval nějakou elegantní obejktovou syntaxi na volání metod z interfaců přiřazených strukturám, případně by hlídal dědění, správu paměti, volání destruktorů nakonci scope, apod. (něco jako Objektive C).

výhoda by bylo, že oboje dvoje by byla jen nadstavba využívající existující compilery a knihovny: jsem popravdě líný, a tu "skutečnou" práci spojenou s vývojem nějakého kompileru se mi dělat nechce...

REDGUY: ano, děkuji, že si konečně pochopil, že je to koníček. a že nemusíš na každý můj příspěvek nutně reagovat :-)

kromě toho si všimni, že já jsem opustil myšlenku toho mít to postavené čistě jen nad preprocesorem už dost dávno: nyní můj header obsahuje cosi jako mikro-knihovnu (tedy makro "program" implementuje potřebné funkce".

je to určené vysloveně pro mikro-projekty, a víceméně se ani nepředpokládá použití spolu s Makefily - používá se nějaký "quick and dirty" přístup k vývoji prográmků a použití mého jednoduchého kompilačního skriptu "bake". je to prostě hračka pro lidi, co mají pocit, že "méně je někdy více" - něco jako elektrokolo, moped, ultralehké letadlo, motorový paraglide... (výrobci dopravních letadel a autobusů můžou být v klidu :-)

JACHYMKO: kdybych tyto problémy neřešil v C, tak nejspíš nikdy nepochopím, který typ problémů vlastně C++ řeší za mě. (a kromě toho - C++ je neřeší zdaleka tak automaticky, jako skutečné vyšší programovací jazyky...)

REDGUY: zajímavé... vidím, že si konečně vzal na milost makra :-) a že si uvědomuješ závažnost problému s random-return z plain-C funkce :-)

každopádně, to co navrhuješ je sice pěkné - ale opravdu, velká spousta programátorů tento problém řeší tím, že k úniku z funkce používá místo tebou navrhovaných maker např.nějaké goto na deinicializační blok.... fakt jsem to takto viděl už mnohokrát.

ISTEVE: ve skutečnosti: to samé, co budu volat "zevnitř" makra
forget { }, můžu samozřejmě volat i z nějakého makra dejme tomu "escape" - to provede něco jako { forget_close(); return; }.

ve skutečnosti - pro různá svoje makra můžu udělat nějaký speciální indikátor, jaký typ destruktoru má volat makro "escape" - např. for_each() flow control makro by nařídilo, aby escape uzavřelo soubory - a asi by to šlo i vnořovat: tedy, pro všechna moje flow control makra která na začátku něco inicalizují a na konci deincializují, by escape mohlo být "bezpečnou" verzí returnu (a pokud bys použil escape mimo scope, tak by prostě udělal return)

nicméně je to překombinované, a já radši ve svém dialektu udělám méně maker a lépe zdokumentuji, co přesně dělají... než abych vymýšlel další takovéhle berličky.

JACHYMKO: Coz o to, ja chapu proc se o to snazi, i kdyz ze vsech praktickejch hledisek je to, v dobe existence C++, Javy, ObjC, Scaly a ja nevim ceho jeste, zcela zbytecne. Proste je to konicek, hobby projekt kterej si clovek vymysli a dotahne od zacatku do konce. To naprosto chapu, preju mu to a obdivuju ho za vytrvalost jakou se ho drzi.

Co ale nechapu je, ze po vsech tech letech co mu tady rikame ze C preprocesor fakt neni vhodnej nastroj na tenhle projekt tak se ho porad drzi. (A nejen ze mu to rikame, ale i prakticky ukazujeme na ruznych zpusobech, jakym je to konkretne rozbite). To neni obdivuhodna vytrvalost ale neco, co radsi nebudu pojmenovat aby tenhle prispevek pusobil aspon trochu konstruktivne 8)


XChaosi, C preprocesor slepa ulicka. Krome myriad postranich problemu ma hlavni problem v tom, ze nevi a nemuze vedet nic o strukture C programu. Jak v obecne rovine, kdy proste nema prostredky popsat syntaxi C, tak konkretne, ze nevi v jake casti kodu se to ktere makro zrovna expanduje. A kdyz nic nevi o strukture, nemuze ji ani efektivne modifikovat.

Jestli chces opravdu udelat "Lepsi C", pouzij na to spravny nastroj. Jestli chces hardcore klasiku, lex/yacc (resp. flex/bison), z modernejsich treba Antlr. Pro oboje existuji C gramatiky, ktere muzes vzit jako zaklad a nad nima postavit poradny preprocesor ktery Cll1 prelozi do C. Drzet se za kazdou cenu nastroje, ktery je tak extremne nevhodny jako CPP, je jen a jen plytvani casem ktere nikam nepovede.

Ja mam hrozne bolestnej pocit, ze xchaose by uspokojilo kdyz by mel scoped objekty (s moznosti definice destruktoru) v C, a toho cile se snazi dosahnout preprocessor makrama.