Cont - container generator (diskuse)

[Odin1918]

Pekne, ale obavam se, ze Jardik z toho chytne psotnik.

[pavelk]

Díky, pozvedáváš úroveň abclinuxu. Znáš boost::multi_index_container?

[zuzanak]

Bohužel boost obecně moc neznám, a považuji to za zásadní nedostatek, který musím dříve či později napravit.

[Marvin]

Program mozna dobrej, ale zapis v blogu strasnej. Precetl jsem prvni 2 odstavce a na rychlo proletel zbytek a nemam tuseni co to vlastne dela...

[Ivorne]

Heh, já přečetl většinu zápisku a taky nemám tušení, co to vlastně dělá . A to se považuju za pokročilýho v c++.

[zuzanak]

Dobrá tedy, tak na té nesrozumitelnosti asi něco bude.

Co to dělá: Zdrojové soubory kompilovaného projektu obsahují značky, které popisují datové typy, které se mají generovat na základě podporované množiny šablon.

Program o kterém píši, prochází zdrojové soubory kompilovaného projektu, hledá v něm tyto značky, a generuje kód implementující datové typy popsané těmito značkami. Vygenerovaný výsledný soubor je určen ke kompilaci kompilátorem C/C++.

Pokud znáte STL a kontejnery (vector, list, atd.), tak to v podstatě dělá to samé, jen jsou tyto značky zpracované externím preprocesorem (programem cont).

[Marvin]

Takze tomu treba reknu ze chcu mapu 'int -> string' a ono me to vygeneruje tridu ktera tu mapu implementuje?

[zuzanak]

Ano je to víceméně tak jak píšeš. Jen mapy nejsou implementovaný jako samostatný typ kontejneru, a je potřeba tyto vytvořit jako kombinaci struktury obsahující integer index a string value, nad kterou se vygeneruje rb_tree.

Příklad generování mapy int na string výše uvedeným způsobem je uveden zde.

Struktura int_string_s je generována nad nějakým mým obskurním řetězcem, protože struktury použité v kontejnerech musí implementovat rozhraní, které jsem zmiňoval v zápisku.

Značky generující kontejnery jsou ve zdrojových souborech umístěny zde.

[Ivorne]

No jasně, že je to nějaký preprocesor jsem pochopil. Ale jaký konkrétně typ kontejnerů či datových typů to generuje? C++ pro podobné věci typicky používá template system nebo C preprocesor. V čem je tohle lepší? Nebo v čem se liší zaměření toho tvého preprocesoru?

[zuzanak]

Nesnažím se tvrdit, že je to lepší než STL šablonové kontejnery, případně jiná implementace kontejnerů, to by jsem si ani tvrdit netroufal.

Typy kontejnerů, které to je schopné generovat jsem se snažil popsat v zápisku. Výhody oproti STL jsou pro mě následující:

• Překladač nemusí implementovat STL.
• Celočíselné indexy do kontejnerů namísto iterátorů, u všech typů kontejnerů.
• Public přístup ke všem členům generovaných struktur.

Hlavním důvodem proč jsem jsem se tu o tom upsal bylo, že to používám ve větší věci, kterou tu chci zmínit, a byl by jsem rád, kdyby někdo kdo se případně podívá na zdrojové kódy a viděl tam tyto značky, tak aby tušil která bije.

[Ivorne]

No ale nechápu, proč jsi použil vlastní preprocesor, když by to zřejmě šlo udělat i pomocí šablon. Když říkám template system, tak tím myslím něco jiného než jen STL. Celkově bude dost pakárna do různých build systémů zakomponovávat vlastní preprocesor.

[Josef Kufner]

Proč nestačilo použít běžné šablony, které v C++ už jsou?

[zuzanak]

Když jsem implementoval grafové gramatiky reprezentoval jsem množiny vrcholů a hran grafu rb-stromy, kde:

• každá hrana se odkazovala na zdrojový a cílový uzel.
• každý vrchol obsahoval pole hran, se kterými je incidentní.

Tyto "odkazy" na hrany a uzly byly realizované pomocí celých čísel (unsigned), tak jak o nich píši v zápisku (viz "Umístění objektů v jednom bloku paměti"). Takto popsaný graf bylo snadné exportovat do binárního souboru, a z tohoto jej importovat, jednoduchým zkopírováním bloků paměti generovaných kontejnerů (offset zůstal zachován).

Některé z důvodů proč jsem v té době nepoužil STL:

• Nebyl jsem si jistý zda multiset z STL nepoužívá v rámci iterátoru ukazatele na umístění prvků v paměti, nebo ukazatel na objekt reprezentující kontejner, což by mi zkomplikovalo výše uvedené exporty/importy.
• Alokace paměti pro každý samostatný prvek v multiset, pro mě před šesti lety byla velkým strašákem. Dnes už se mi to tak strašné nejeví.
• Zvědavost a potřeba si takový složitější kontejner implementovat byla veliká.

[Josef Kufner]

O STL vůbec nemluvím. Mluvím o šablonách jako takových.

[zuzanak]

Před tím, než jsem vytvořil tento preprocesor, jsem zkoušel za účelem generování kódu používat makra preprocesoru, a později i C++ šablony. Ale vždy jsem narazil na nějaké omezení, které se mi nelíbilo.

Já jsem takový úchyl, kterému by se líbilo, kdyby jazyk C preprocesoru byl úplný programovací jazyk, který by generoval zdrojový soubor pro překladač.

Šablony jsou určitě nástroj, který by člověk myslící to s C++ vážně neměl ignorovat. Před 6 lety, kdy jsem vytvářel preprocesor, se mi šablonování zdálo docela divoké, ale v poslední době, když se setkám s novými věcmi z C++11, tak bývám často překvapen, v dobrém slova smyslu.

Problémy (které si myslím že mám) s C++ šablonami:

• Neumím generovat zdrojový kód v závislosti na typu datového typu. Tj. nevím jak je rozdělit a otestovat na kategorie basic,static a dynamic, jak jsem je popsal v zápisku.
• Na základě tohoto typu chci generovat odlišný kód, aniž by jsem znal přesné jméno toho či onoho datového typu. A vyhovovalo by mi, kdyby jsem mohl diverzifikovat jen část kódu funkce.
• Potřebuji mít přístup k vygenerovanému kódu, který si můžu například krokovat v debugeru, nebo zkopírovat a použít jako čitelnou část zdrojového kódu.

[pavlix]

Já jsem takový úchyl, kterému by se líbilo, kdyby jazyk C preprocesoru byl úplný programovací jazyk, který by generoval zdrojový soubor pro překladač.

Taky bych bral nějaký hybrid mezi céčkem a tím, co jsem slyšel o lispu.

[Miriam]

Já slyšela o lispu, že je to úplná sračka, která je zastaralá jako prase a protože za nic nestála, tak se přestala používat a přitom na ní všichni nostalgicky vzpomínají. Zdar Max

[Ivorne]

Já ovládám několik odnoží lispu a rozhodně bych netvrdil, že je to zastaralé.

Pokud člověk touží po pokročilém metaprogramování / generickém programování / rozsáhlém preprocessoru, tak je lisp ta pravá volba. Pokud se člověk snaží o nějaký pokročilejší bottom-up vývoj, tak u většiny programovacích jazyků má k dispozici většinou dvě úrovně - úroveň pro metaprogramování (template system, generics, c-preprocessor) a pak úroveň pro normální programování. V LISPu se používá v podstatě ten samý přístup pro metaprogramování i normální programování, takže těchhle vrstev si člověk může udělat kolik chce. Interpretované dynamicky typované jazyky tuhle funkčnost částečně řeší právě tak, že všechno probíhá v runtimu, ale zdaleka to není dokonalé (třeba ruby taky používá různá makra pro metaprogramování).

Sám mám radši přístup C++ (statické typování, co jde se dělá už v compile-time) než LISP. Ale LISP není zastaralý už z toho důvodu, že většina věcí co se posledních několik let přidávalo do všech programovacích jazyků (a ještě pár let přidávat bude) pochází z LISPu a obecně z funkcionálního programování.

[Bystroushaak]

Já jsem takový úchyl, kterému by se líbilo, kdyby jazyk C preprocesoru byl úplný programovací jazyk, který by generoval zdrojový soubor pro překladač.

Zkus D. Tam přesně takhle fungují template mixiny.

[Miloslav Ponkrác]

Jsou 2 cesty, jak toho snadno dosáhnout:

1) To kouzlo, které to v C++ umožňuje se jmenuje specializace šablon.

2) Kromě toho, šablony mohou mít extrémní variabilitu také tak, že parametrem šablon může být i jiná šablona dodávající částečnou funkcionalitu a určité kusy kódů a funkcí. Tato technika je v STL sem tam použita a C++ standard ji nazývá traits.

Věděl bych o miliardě možností, kdy je lépe v C++ generovat něco preprocesorem, ale zrovna datové kontejnery v té relativně malé a málo rozměrné podobě, kterou jsem pochopil v blogu, na to C++ preprocesor opravdu netřeba. To zvládne velice dobře C++ standardními prostředky. A samozřejmě to zvládne i debugovat či použít jako čitelnou část zdrojového kódu.

Nicméně nehaním vaši práci. Jen jsem chtěl podat ruku k pomoci, že to opravdu pomocí C++ šablon jde, a velice snadno.

Miloslav Ponkrác

[zuzanak]

Problém je v tom, že programuji spíše v jazyce C, než v C++. Z C++ si beru jen syntaktický cukr týkající se metod a referencí. Potvrzením tohoto budiž fakt, že bylo poměrně snadné upravit generátor kódu tak, aby jeho výstup bylo možné zkompilovat kompilátorem jazyka C (branch cont_c).

Na šablony, jsem zanevřel před šesti lety, předtím, než jsem generátor začal používat. V okamžiku, kdy použiji šablony jsem odsouzen programovat v C++ naplno (konstruktory/destruktory, new/delete, instanciace šablonových funkcí, ...), ale to já nepotřebuji, proč by jsem musel? Namísto zjednodušení mi výše uvedené do problémů zanáší další úroveň složitosti.

S příchodem C++11 (nebo spíše s přibývající podporou v kompilátorech) to začíná být znovu zajímavé. Vypadá to, že už se upustilo od čisté teorie a někdo se to (šablony) pokusil použít v praxi a získanou zkušenosti promítl do C++11. To nic nemění na tom, že například Texas Instruments nepodporují v některých svých kompilátorech tyto "kouzla" (C++11 traits), na rozdíl od C++ jak jej používám já, a které bude vždy a všude přístupné. Ale i v budoucnu, kdy bude podpora "kouzel" už dostatečná by jsem musel odmítnout názor tvrdící, že když jazyk podporuje generické programování, tak dělat to jiným způsobem je rouhání (neříkám, že to tvrdíte).

Na C a C++ s objekty mi vyhovuje minimální množství axiomů, které programátor musí znát, aby mohl naprogramovat cokoli. Pokud má někdo problém s dynamickou pamětí a inicializací proměnných (konstruktory, destruktory), ukazateli (iterátory, smart ukazatele), vstupem/výstupem (streamy), dobrá ať si to zjednoduší, za cenu toho, že se připraví o určitou svobodu, ale nemusí takový přístup vyžadovat i od ostatních (pokud ovšem není projektový manager, rozhodující o používaných nástrojích).

[Miloslav Ponkrác]

I já jsem byl odsouzen programovat v C++ naplno a mnoho let. Se šablonami jsem vážnější problém neměl. Daleko více mám problémy s C a zbytky po C.

Například dodnes jsem nepochopil, proč pro výběr členu struktury/unie/třídy/whatever přes pointer jsou v C dvě různé syntaxe, v C++ dokonce tři.

Kompilátor C i C++ bezpečně ví, co je pointer a co přímá proměnná. Kdyby se vše vybíralo pomocí tečky, nevznikl by žádný problém, následně by Stroustrup nemusel zavádět reference, a celé by to bylo konzistentnější. Existenci operátoru -> považuji za blbost tvůrců jazyka C.

Šablony jsem využíval a mám pár hezkých knihoven. Třeba na typy. Takže mám typy třeba uint<2> pro dvoubajtový unsigned integer. Minimální a maximální hodnotu zjistím snadno, třeba pro size_t či libovolný číselný typ: int_traits<size_t>::min_value, int_traits*<size_t>::max_value.

C++11 neudělalo nic jiného, než převzato některé šablonové knihovny z projektu boost a učinilo je standardem. Bohužel C++ 11 mě přesvědčilo, že C++ jde špatným směrem, a tak se obracím jinam. Ačkoli řada věcí je dobrá, pochopil jsem, že ta největší a nejšpatnější část C++ je to, co bylo převzato z C, a to už nikdo nenapraví.

Přístup k minimalizaci jazyka není nic, co bych nerespektoval. C++ má velmi špatnou standardní knihovnu, to je asi největší slabina C++. A kvalita knihovny má spíše klesající tendenci s dalšími a dalšími normami. Tudíž asi každý rozumný člověk si musí napsat své části, ne-li prakticky celou. STL, která podle normy zaručuje, že stačí posunout iterátor o jeden prvek dále a výsledkem je podle standardu „nedefinované chování“ není asi nic, po čem by člověk toužil. Stejně tak streamy, které nejsou rozumně přetěžovat a rozšiřovat, protože v rámci ušetření pár bajtíků mají skoro všechny metody nevirtuální mi nápadně připomínají Y2K. A to ještě trvalo řadu let, než někdo standardizátory přemluvil, aby alespoň bylo možné bezpečně vyhazovat v STL kontejnerech výjimky, i to chtěli zakázat.

Nicméně bych uvítal, aby každý ke svému projektu na začátku napsal „rationale“ jak je zvykem včetně svého přístupu a vztahu k tomu či onomu. Když jsem v manuálu PostgreSQL našel před léty „Nenávidíme Windows a proto na to kašlem“, byl jsem rád, a PostgreSQL jsem opustil, protože nesplňuje to, co čekám. Dnes v politicky korektní době už to v manuálu PostgreSQL není, ale výsledek je stejný, jen si nováček na to, že nenávist autorů PostgreSQL se projevuje i na jejich vlastnostech na této platformě musí přijít sám a ztratí sposuty času.

Proto bych docela uvítal, aby každý, kdo nemá rád C++ a dělá projekt pro C++ na začátku napsal „nemám rád C++“ nebo „nemám rád většinu C++“ a já jsem nemusel třeba psát sem řádné příspěvky. Tak jak to poctivě píše Qt projekt, že nenávidí C++, ale milují ObjectiveC, ale pragmaticky pochopili, že pokud chtějí prachy, tak v ObjectiveC je nenajdou, tak zprznili C++, trochu zbytečně zapojili moc, aby měli pocit, že C++ trochu nakopali do zadnice a přiblížili se Objective C a je jasno. Je pak zřejmé, že absence výjimek, nebo zamlčování chyb u akcí s potenciálem selhat a návratovou hodnotou void je prostě způsob protestu proti C++, a já se Qt zcela vyhnul a spokojenost na všech stranách.

Dá se totiž diskutovat s technickými problémy, nedostatky, řešeními. Ale nedá se diskutovat s emocemi, nenávistí, ideologií, politikou, islámem, atd. A ani bych se o to nepokoušel, když bych v rationale hned viděl „C++ mi vadí“.

[vlastikroot]

Tohle vypada mnohem vic jako C nez jako C++. V C bych to pochopil, ale v C++ jsou templaty uz v jazyce, tam je to asi zbytecny.

[zuzanak]

Je to tak jak říkáš. Proto pořád píši C/C++ namísto C++, čímž mám na mysli C rozšířené o metody ve strukturách, reference, datový typ bool, výčtový typ, a možná některé další funkce.

Původně to (v experimentální fázi) generovalo C kód, a generované funkce vypadaly tak jak je vidět v některých C knihovnách: rb_tree_init, rb_tree_push, apod. Od toho jsem ale upustil, protože pohodlnost použití vygenerovaných "objektů" byla ještě horší.

[vlastikroot]

Takze ten generovany kod nejde prelozit C prekladacem?

[zuzanak]

Aktuálně generovaný kód překladačem C přeložit nejde, ale je jednoduché to upravit tak, aby takový kód byl generován.

Problém je jen v tom, že C nezná metody ve strukturách, reference a typ bool. Kód generátoru je možné upravit tak, aby místo metod generoval funkce s prefixovou notací (<class>_<method>), a reference nahradil ukazateli. Algoritmy zůstávají stejné.

Včera jsem vykoušel jeden generátor takto upravit, a funguje to.

[Bedňa]

Včera jsem vykoušel jeden generátor takto upravit, a funguje to.

Však keby si do blogov napísal konkrétne prípady použia, tak by to viac povedalo ako stovky riadkov teórie

[zuzanak]

Inu chtěl jsem aby to bylo kompletně popsané :). Jinak jsem tam uvedl nějaké odkazy na příklady pro každý popsaný kontejner. Nebo případem použití máš na mysli nějaký konkrétní program, ve kterém jsem to použil? Třeba parser generátor yapgen je na tom kompletně založený.

[Bedňa]

Tak, tak kompletne s nápovedou na použitie a konkrétne použitie. Vždy sa učím z príkladov a dalo mi to viac ako dokumentácia.

[vlastikroot]

V tom pripade bych se byt tebou drzel prave toho C, kde tohle muze byt silny nastroj k zprehledneni kodu. Michat do toho C++ mi prijde spis naskodu, tam uz vsechno je - nemusi to byt zrovna STL (viz treba OctaSTD), taky se daji naprogramovat uplne vlastni containery. Programovat v C/C++ (tak jak to myslis) mi neprijde jako dobry napad.

[zuzanak]

Transformace do C výstupu už je v pokročilé fázi, jsem zvědavý na porovnání výsledku překladu C vs C++ co se rychlostí výsledného kódu týká (i když tuším, že se to nijak lišit nebude).

Jinak ty generované kontejnery v C/C++ používám docela často ve věcech na kterých dělám, a dost jsem si na to zvykl. Šablony v C++ mě zatím nějak míjí.

[vlastikroot]

IMHO by se dala udelat implementace v cistem C++, ktera by se chovala naprosto stejne jako C++ vystup z cont. Sablony nejsou zas takova veda, pokud jde o containery. Urcite by i slo vyuzit ty algoritmy.

[Miloslav Ponkrác]

Ono se dá říci, že šablony byly do C++ přidány především přesně ze stejného důvodu, jako jsi vytvořil svůj preprocesor. Jen ty šablony jsou značně univerzálnější.

[Bedňa]

Pokiaľ ťa zaujímajú kontajnery v C++, pozri na toto.

[Miloslav Ponkrác]

Programuji v C++ od samého začátku, co C++ existuje, tedy už velmi dlouho. Pokud se objeví něco zajímavého, tak jsem to skoukl.

Ultimate C++ považuji za prasečinu non plus ultra, jaké není rovno. Když jsem projížděl zdrojáky, tak je v tom pár docela dobrých nápadů, ale jinak hnůj, hnůj, hnůj.

Doporučuji vám prohlédnout si zdrojáky, a snažit se v nich vyznat.

Ultimate C++ je takový řízený chaos. Mnoho jejich kódu dělá neoprávněné předpoklady, které jsou většinou, ale nikoli zaručeně, splněny. Zrovna jejich kontejnety jsou přesně tímto infikovány. Tichý předpoklad u většiny kontejnerů, totiž že jejich obsah lze přesouvat na různé adresy v paměti přímo pomocí funkcí memcpy, a nikoli pomocí operatoru přiřazení – sice drasticky leccos zrychluje, ale je to velmi chatrná stavba.

Není nic příjemnějšího, než si poničit paměť náhodnými změnami objektů v kontejneru a pak to hledat.

V zásadě tak nějak jsem pochopil, že autoři považují správná řešení za prasečiny, jako jsou třeba sdílené hodnoty, které se nijak nevylučují s alokačními rámci. A propagují bambión prasečin, jako jsou třeba memcpy přesuny objektů po adresách, což nikdy není zaručeno, že projde správně a kompilátor C++ nijak toto nezaručuje že to je ok. Nebo zdrojáky, které mají identifikátory komplet v globálním prostoru bez použití namespace a přitom jejich identifikátory jsou natolik běžné, že snadno dojde ke konfliktu s jinou knihovnou/kódem/čímkoli. A mnoho a mnoho dalšího.

Na Ultimate++ se mi líbí dotažení do konce. Ale základ je velice shnilý. Je to inspirativní projekt některými nápady, nicméně implementace je zhruba na úrovni nejhoršího možného prasectví.

Za mě palec dolů. Používat Ultimate++ v praxi bych každému vymlouval jako čirou pitomost.

Miloslav Ponkrác

[adadg]

Co na cechoch strasne obdivujem je to, ze su patrioti a prekladaju vsetko lebo sa im to tak paci. Co na cechoch strasne nenavidim je to, ze vsetko prekladaju a ja potom neviem co je co resp. trva mi to dlhsiu dobu to pochopit :D

[Miriam]

Sorry, ale tohle je neuvěřitelná prasárna.

[Bluebear]

Co o tom ví nezaměstnaná transka, která neumí ani hello world ve skriptovacím jazyce?