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.

XCHAOS: A stale se nemuzu ubranit argumentaci lidskou masou -- programovaci jazyky jsou pro konzumaci programatory, mas jedinyho kterej by tohle povazoval za dobrej napad? Ja vidim spoustu lidi, co to za dobrej napad nepovazuje, a i kdyz budes reagovat ze se jen hadaj, tak ti to furt lidi co souhlasej nenajde...

XCHAOS: S tvoji vymyslenosti jsou dve varianty:
a) Nemuzu udelat manualni release pameti, a tudiz nemuzu pouzit return v polovine funkce.
b) Muzu udelat manualni release pameti, a tudiz je mi tvoje vymyslenost na hovno.

DAVIDOWITCH: ano

1) u matematickych funkci nad maticemi to asi pujde dobre rozdelit do funkci s nejvyse tremi/ctyrmi parametry, casto casem zjistis ze potrebujes delat i nejake dilci operace, takze funkce/makro volajici/pouzivajici dalsi funkci/makro je imho ok, alespon ja to tak mam rad :)

2) obvykle resim zkracovanim vseho do jedineho vyrazu/prirazeni, doufaje ze tim nejak usnadnim kompilatoru praci, ale asi je to v dnesni dobe vyspelejsich kompilatoru uz zbytecne. const nepouzivam, kdyz je potreba, prepisu kriticky kod do asm (vim, jebacka s portabilitou :)

_BENNY: tj ten mul(sub(a,b),c); zpusob?
A 2 followup questions:
1) asi je lepsi udelat tu fci delsi a mit min vnoreni, nez kratkou a nacpat vsechno do 2 radek?
2) ma nejakej realnej vliv deklarovat mezivysledky jako const, nebo je to tomu prekladaci burta? (tj. const tmp1 = mul(a,b); return sub(tmp1, d);)

DAVIDOWITCH: osobne preferuju prefix funkce/makra. jsem trochu staromodni :)

Ja mam vlastni problem na kterej bych znal nazor (neni sice uplne primo vztazenej k Ccku jako takovymu, ale je to problem kterej by se stejne vyskytl v Ccku jako v ty Jave kde mne zajima).

Delam grafiku, to znamena spoustu prace s maticema a vektorama. Typickej priklad, Vec3f, vector 3 floatu (neplest s vectorem jako natahovacim polem, tohle je matematickej vektor).
A ted, kdyz mam C++, pretizim si operator (a pokud sem prase jako muj kolega tak z ~ udelam normalizaci a z ^ udelam cross product a z % udelam dot product). A vesele pocitam. Ccko neumi pretezovat operatory. Jak to co nejcitelneji poresit?

Kluk z Cornellu kterymu sem koukal do Java kodu to ma poreseny tak, ze proste na 3 po sobe jdoucich radkach pouzije normalni float operatory na slozky x, y, a z, tj.:
a.x = (b.x-c.x)*d.x;
a.y = (b.y-c.y)*d.y;
a.z = (b.z-c.z)*d.z;
Dalsi moznost je mit prefixovy funkce tj. a = mul(sub(b, c), d);
a dalsi moznost (a tady to prave odbocuje od toho co nabizi Ccko) je mit infixovy fce:
a = (c.sub(d)).mul(d); Coz je sice infixovy jako obyc operatory, ale nevim nevim jestli je to citelnejsi.

Nejaky nazory?

ISTEVE: no ve vyšších programovacích jazycích asi skutečně máš ten luxus, že soubory se ti pozavírají, když zmizí reference na objekty, které je otevřely, apod. budiž.

ale v C to fakt nejsou jenom moje vymyšlenosti, kvůli kterým nemůžeš kdekoliv svévolně vyskočit z funkce. fakt na některém místě můžeš a na jiném ne, a stejně o tom musíš přemýšlet (a to zvlášť když to je funkce volaná z nějaké smyčky, kde neuvolnění zdrojů fakt způsobí průser...)

DAVIDOWITCH: ne, ale pracuje u nás týpek, co napsal http://wiki.kyberia.cz/doku.php/skripta/jazyk_c/start "učebnici C pro SSPŠ" :-)) což mi přijde zábavné.

skutečně nevím, z jakého konce bych to vzal, kdybych někoho učil céčko, netuším. a ani mě ho tedy nikdo nějak podrobněji neučil.

"a (složitější) funkce by opravdu mohly mít jeden validní return - a ostatní případy by měly být spíš (odchytitelné) exceptions" .. nemam tuhle zkusenost. Zminujes, ze "je to opravdu trend" -- citace / statistiky / ...?

DAVIDOWITCH: spíš se na to podívej jinak - jak bych já napsáním nějakým maker navíc mohl něco zakázat ? :-)

opravdu - v C není možné jednoduše udělat return zprostředka, pokud rozehraješ nějakou složitější hru: a složitější hra je všechno, než odkládání nějakých čísílek na stack. REDGUY v tomto opravdu "objevil Ameriku", ale co se dá dělat.

XCHAOS: Pro zajimavost, ucils nekdy nekoho Ccko?

REDGUY: 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, a že jen já jsem tak zlý, že navrhuju správu paměti, která to zkomplikuje. ale ZNOVU:

{
char *ptr=malloc(LEN)
FILE *f=fopen(...)
/* spousta řádků kódu */
if(redguy)
return -1;
/* spousta řádků kódu */
free(ptr);
fclose(f);
return vysledek;
}

a další problém je, že se NESMÍ vracet pointery na lokální proměnné - ale některé libc funkce přímo vyzývají, aby se jim předaly pointery na menší struktury (např. různé časové funkce) , takže pokud si někdo dá generování timestamp do funkce a přitom opíše ukázkový kód kdy ta struktura je lokální na stacku, a zkusí třeba vrátit pointer - tak taky nazdar. je to prostě už teď plné zádrhelů a rituálních zyvklostí co se smí a nesmí...

a (složitější) funkce by opravdu mohly mít jeden validní return - a ostatní případy by měly být spíš (odchytitelné) exceptions. je to opravdu trend, který vidíš všude kolem sebe - jenže ne, když to říkám já, tak je to špatně.

(a v jednodušší funkci která jen počítá něco s nějakými čísli či něco takového zase asi nebudeš alokovat paměť - takže celá zásada "jediného návratu z funkce" se vlastně točí kolem toho, jestli ta funkce nějak interaguje nebo neinteraguje se svým okolím, což je PODSTATNÝ detail - ale to prostě někomu nejde od palice, tak se radši povede flejmwar až do zblbnutí)