Cont - container generator

13.6.2015 22:02 | Přečteno: 893× | Vývoj software | | poslední úprava: 13.6.2015 22:02

Rád by jsem vám představil další projekt, na kterém jsem začal pracovat přibližně před šesti lety a od té doby jsem jej několikrát využil při implementaci řešení některých úloh se kterými jsem se setkal. Program se jmenuje cont (od slova container) a reprezentuje preprocesor rozšířeného jazyka C/C++, který nahrazuje značky umístěné ve zdrojovém kódu, kódem implementujícím abstraktní datové typy popsané těmito značkami.

Při vývoji software jsem si všiml, že významnou část času strávím zapisováním kódu pro manipulaci s objekty, který se příliš netýká implementovaných algoritmů. Mám na mysli inicializaci datových struktur, jejich uvolňování, kopírování objektů a podobně. Často se v rámci takového kódu mění pouze datové typy se kterými pracuje, zatímco jejich základní struktura zůstává zachována. Na základě výše uvedeného jsem se rozhodl implementovat program, který by mi umožnil psát pouze kód, nad kterým je nutné přemýšlet.

Základní funkce

Zdrojové soubory programu zapsaného v jazyce C/C++ obsahují značky určené pro zpracování generátorem kontejnerů. Každý zdrojový .cc soubor je zpracován programem cont, který ve zdrojovém souboru rozpozná jemu určené značky, a na základě informací získaných z těchto značek generuje výsledný zdrojový soubor. Vygenerovaný zdrojový soubor je připraven pro zkompilování kompilátorem jazyka C/C++.

Použití programu

Program cont požaduje minimálně jeden argument příkazové řádky, který se odkazuje na zdrojový .cc soubor. Následující argumenty programu identifikují adresáře, ve kterých budou hledány hlavičkové soubory použité pro generování výsledného souboru. Výsledný zdrojový soubor je zapisován na standardní výstup programu cont.

cont <source-file> <inc-dir> <inc-dir> ... > <target-file>

Je vhodné umístit zpracování zdrojových souborů programem cont do souboru Makefile, který se stará o překlad projektu.

Základní princip

Program cont v jednom běhu zpracovává vždy jeden zdrojový .cc soubor, včetně všech do něj vkládaných hlavičkových souborů. Po celou dobu běhu si v paměti udržuje informace o všech definovaných a vytvořených datových typech, které používá za účelem generování dalších datových typů prostřednictvím šablon.

Datové typy a jejich vlastnosti

Sledované datové typy jsou popsány jejich jménem, skutečným jménem, množinou zkratek, a jejich vlastnostmi.

Jméno datového typu

Základní jméno datového typu, které je použito jako jméno struktury reprezentující vygenerovaný datový typ. Jméno datového typu může být popsáno formátem splňujícím vlastnosti standardního identifikátoru v jazyce C/C++.

Skutečné jméno

Skutečné jméno datového typu slouží k jednoznačné identifikaci typu za účelem hledání duplicitních datových typů co se obsahu týká. Skutečné jméno datového typu je generováno automaticky na základě typu šablony a datovém typu pro který se tato šablona generuje. Skutečná jména některých datových typů mohou vypadat následovně:

• bi_a - pole celých čísel.
• bi_a_q - řada polí celých čísel.
• bd_l - seznam (list) 64 bitových reálných čísel.

Množina zkratek

Množina zkratek přiřazená k datovému typu obsahuje jména, která se používají pro identifikaci datového typu v rámci zdrojových souborů. První zkratka je nastavena podle jména datového typu. Zbytek zkratek je definován prostřednictvím klíčového slova typedef.

Vlastnosti datového typu

Datový typ vždy patří do jedné z následujících základních kategorií:

• basic - základní datový typ. Do této kategorie patří například datové typy: char, int a double.
• static - datový typ popsaný statickou strukturou, která nepoužívá dynamicky alokovanou paměť.
• dynamic - datový typ popsaný dynamickou strukturou, která používá dynamicky alokovanou paměť.

Z příslušnosti k jedné z výše uvedených kategorií vyplývají základní vlastnosti datového typu, definující množinu operací, které je možné nad daným datovým typem používat. Tyto informace jsou zohledňovány při generování kontejnerů operujících nad konkrétním datovým typem.

Například pří kopírování pole prostřednictvím metody operator= je možné pro datové typy z kategorií basic a static použít funkci memcpy, zatímco datové typy dynamic je nutné kopírovat prostřednictvím jejich operátoru operator=.

V rámci popisu datového typu může být nastaven příznak flushable, který indikuje, že je možné zavolat metodu flush tohoto objektu, za účelem uvolnění přebytečně alokované dynamické paměti.

Rozhraní pro přístup k objektům

Datové typy, které jsou určeny pro zpracování jako objekty z kategorií static a dynamic musí implementovat následující rozhraní:

• init - Inicializace objektu. Po zavolání této metody se objekt nachází v definovaném stavu a neodkazuje se na žádnou dynamicky přidělenou paměť. Tato metoda se volá nad objekty, které se nachází v nedefinovaném stavu.
• clear - Uvolní dynamicky alokovanou paměť používanou objektem a uvede objekt do definovaného stavu. Výsledný stav objektu je stejný jako stav ve kterém se objekt nachází po zavolání metody init.
• flush_all - Omezí velikost dynamicky alokované paměti používané objektem na velikost nezbytně nutnou pro uložení aktuálního obsahu.
• swap - Prohodí data přiřazená objektu s daty objektu předaného parametrem metody.
• operator= - Zkopíruje do objektu data objektu předaného parametrem operátoru. Původní data objektu jsou uvolněna.
• operator== - Porovná objekt s objektem předaným parametrem operátoru a vrátí true pokud je obsah objektů shodný.

Datové typy, které jsou generovány šablonami, implementují výše uvedené rozhraní tak, aby bylo možné tyto datové typy použít pro další generování prostřednictvím šablon.

Syntaxe zápisu značek

Původní implementace programu cont byla napsána v jazyce perl, a z množiny vstupních zdrojových souborů generovala jeden výstupní soubor, obsahující veškerý kód překládaného programu. Kvůli rozšiřování funkčnosti programu cont, změně způsobu práce se vstupními soubory a tomu, že nejsem žádný perl hacker byl program cont přepsán do jazyka C/C++. Aktuální syntaxe popisu značek se vyvinula z původní perlem zpracovávané syntaxe, a je možné, že to na ní zanechalo nějaké stopy.

Značky generátoru

Značky generátoru jsou ve zdrojovém souboru uzavřeny mezi klíčovými slovy @begin a @end.

@begin
  <operation>
  <operation>
  ...
@end

Mezi těmito klíčovými slovy mohou být zapsány značky, provádějící jednu z následujících operaci:

• Vložení hlavičkového souboru.
• Definování existujícího datového typu.
• Vygenerování nového datového typu na základě šablony.
  • Vygenerování inline metod datového typu.
  • Vygenerování metod datového typu.

Soubor popisující rozklad výše uvedeného zápisu je k nahlédnutí zde.

Vložení hlavičkového souboru

Program cont pracuje s hlavičkovými soubory, protože musí mít přehled o datových typech, které byly v těchto souborech definovány nebo vygenerovány. Hlavičkové soubory jsou zpracovávány rekurzivně, což znamená, že soubor vygenerovaný programem cont obsahuje všechny informace, které vstupují do překladu. To neplatí pro standardní direktivy #include, které se pouze zkopírují do generovaného výstupu, a tyto zpracuje preprocesor jazyka C/C++.

@begin
  include "basic.h"
@end

Definování existujícího datového typu

Značka registruje existující datový typ pro použití v rámci generátoru kontejnerů. Tato funkce slouží k propagaci informace o existenci daného datového typu a jeho základních vlastnostech do runtime programu cont.

define <type-id> <modifier> <modifier> ...

Modifikátory ve výše uvedeném řetězci mohou nabývat následujících hodnot: basic, static, dynamic a flushable.

typedef void * pointer;
@begin
  define pointer basic
@end

Vygenerování nového datového typu na základě šablony

Tato operace generuje nový datový typ na základě šablony popsané v rámci implementace programu cont. Kód generující požadovaný datový typ se ve zdrojových souborech programu zapisuje na třech místech v následujících třech krocích:

1. Vygenerování nového datového typu.
2. Vygenerování inline metod datového typu.
3. Vygenerování metod datového typu.

Vygenerování nového datového typu

Značka pro generování nového datového typu obsahuje identifikaci typu kontejneru, identifikaci datového typu (případně několika datových typů) nad kterým bude kontejner vygenerován a jméno nového datového typu. Jméno datového typu nad kterým bude kontejner vygenerován musí existovat a jeho vlastnosti musí být programu cont známy. Níže uvedený formát značky pro vytvoření nového datového typu reprezentuje jen základní možností, rozšířený popis bude uveden níže.

@begin
  <cont-id><<type-id>> <new-type-id>;
@end

Ve výše uvedeném zápisu <cont-id> identifikuje typ kontejneru, <type-id> identifikuje datový typ, nad kterým bude kontejner vygenerován, a <new-type-id> identifikuje jméno nově vytvořeného datového typu. Ve zdrojových souborech, kde se nachází tato značka, bude vygenerována struktura popisující nový datový typ reprezentující požadovaný kontejner. Od tohoto bodu dále je možné používat jméno nového datového typu při generování dalších kontejnerů, nebo jako datový typ C/C++ reprezentovaný strukturou.

// -- ui_array_s --
@begin
  array<unsigned> ui_array_s;
@end

Vygenerování inline metod datového typu

Ve zdrojových souborech, kde se nachází níže uvedená značka, budou vygenerovány inline metody zvoleného datového typu.

@begin
  inlines <type-id>
@end

Ve výše uvedeném zápisu <type-id> identifikuje vygenerovaný datový typ. Tuto značku je možné použít kdekoli ve zdrojových souborech, ale ve většině případů se používá ve stejném hlavičkovém souboru, ve kterém byl daný datový typ vygenerován. To proto, aby překladač C/C++ měl přístup k implementaci inline metod při kompilaci všech .o objektů ve kterých je datový typ nadefinován.

// -- ui_array_s --
@begin
  inlines ui_array_s
@end

Vygenerování metod datového typu

Ve zdrojových souborech, kde se nachází níže uvedená značka, budou vygenerovány metody kontejneru.

@begin
  methods <type-id>
@end

Ve výše uvedeném zápisu <type-id> identifikuje vygenerovaný datový typ. Tato značka se použije ve zdrojovém .cc souboru, který bude obsahovat implementaci funkce generovaného kontejneru.

// -- ui_array_s --
@begin
  methods ui_array_s
@end

Rozšířený formát generující značky

Značka určená pro popis datového typu generovaného na základě šablony může mít komplikovanější formát, než ten který byl uveden v předcházejícím textu. Tato značka musí umožňovat:

• Pojmenovat členské proměnné kontejneru reprezentujícího strukturu.
• Identifikovat metody, které nechceme, aby program cont pro konkrétní datový typ generoval.
• Konfigurovat datový typ prostřednictvím dalších voleb.
• Přidávat vlastní členské proměnné nebo metody do generované struktury.
• Přiřazování více jmen (výše zmiňovaných zkratek) generované struktuře.

@begin
  <cont-id>
  <
    <type-id>:<var-name>
    ...
  >
  not_generate: <method-id> ...
  options: <option> ...
  additions
  {
    <addition-code>
    ...
  }
  <new-type-id>
  ...
  ;
@end

V uvedeném zápisu mají jednotlivé zástupné hodnoty následující význam:

• <cont-id> - Identifikuje typ generovaného kontejneru.
• <type-id> - Datový typ nad kterým bude kontejner generován.
• <var-name> - Zastupuje jméno členské proměnné, přiřazené k datovému typu.
• <method-id> - Identifikace metody, která bude vynechána při generování obsahu struktury. Tato identifikace může nabývat hodnot: init, clear, swap, operator=.
• <option> - Rozšiřující volba, která může nabývat hodnoty strict_dynamic.
• <addition-code> - Rozšiřující kód, který umožňuje přidat členské proměnné a metody do deklarace generované struktury. Kód uzavřený ve složených závorkách je zkopírován do generovaného C/C++ souboru beze změny.
• <new-type-id> - Jméno identifikující nově generovaný datový typ. První jméno je použito jako jméno generované struktury. Zbytek jmen je nadefinován pomocí klíčového slova typedef.

Typy generovatelných šablon

V této části textu uvedu stručný popis jednotlivých typů šablon, na základě kterých je možné generovat nové datové typy.

Šablona struct - struktura shlukující několik prvků

Tato šablona slouží za účelem kombinování jednodušších datových typů do složitějšího celků. Její význam je stejný jako význam struktury (struct) v jazyce C. Příklad použití šablony generující strukturu je uveden zde.

// -- record_s --
@begin
struct
<
  unsigned:index
  unsigned:value
>
record_s;

Šablona array - dynamické pole prvků

Tato šablona generuje abstraktní datový typ reprezentující dynamické pole s možností vkládat nové prvky na jeho konec. Dynamické pole je vhodné pro implementování abstraktního datového typu zásobník (LIFO). Příklad použití šablony generující dynamické pole je uveden zde.

// -- rec_array_s --
@begin
  array<record_s> rec_array_s;
@end

Šablona queue - dynamická řada prvků

Tato šablona generuje abstraktní datový typ reprezentující jedno-směrnou řadu. To znamená, že prvky jsou vkládány na konec řady a je možné je vyzvedávat ze začátku řady (FIFO). Příklad použití šablony generující dynamickou řadu prvků je uveden zde.

// -- rec_queue_s --
@begin
  queue<record_s> rec_queue_s;
@end

Šablona list - obousměrný seznam prvků

Tato šablona generuje abstraktní datový typ reprezentující obousměrný seznam. Jednotlivé prvky je možné do tohoto seznamu vkládat na libovolnou pozici, a z libovolné pozice je odstraňovat. Prvky jsou v obousměrném seznamu identifikovány celým bez-znaménkovým číslem. Příklad použití šablony generující obousměrný seznam prvků je uveden zde.

// -- rec_list_s --
@begin
  list<record_s> rec_list_s;
@end

Šablona rb_tree - Automaticky vyvažovaný binární strom

Tato šablona generuje abstraktní datový typ reprezentující automaticky vyvažovaný binární strom, jehož nejdelší větev je maximálně dvakrát tak dlouhá jako jeho nejkratší větev. Prvky jsou do stromu vkládány s logaritmickou složitostí, a se stejnou složitostí jsou v tomto stromě vyhledávány. Prvky jsou ve stromě identifikovány celým bez-znaménkovým číslem. Příklad použití šablony generující automaticky vyvažovaný binární strom je uveden zde.

Metoda get_idxs objektů generovaných touto šablonou používá datový typ ui_array_s popisující dynamické pole celých bez-znaménkových čísel. Proto je nutné tento datový typ vygenerovat před generováním ze šablony rb_tree.

V rámci objektu generovaných že šablony rb_tree je nutné implementovat jejich metodu __compare_value (příklad zde), která je používána pro porovnání dvou prvků tohoto kontejneru.

// -- rec_rb_tree_s --
@begin
  rb_tree<record_s> rec_rb_tree_s;
@end

Další vlastnosti generovaných typů

Pro potřeby následujícího popisu vlastností generovaných kontejnerů předpokládejme, že existuje datový typ string_s, který má dvě členské proměnné length (celé číslo) a data (ukazatel na znaky). Dále předpokládejme, že na základě tohoto typu byly vygenerované datové typy string_array_s a string_list_s.

Umístění objektů v jednom bloku paměti

Statická data struktur datových typů obsažených v kontejneru jsou umístěna v jednom bloku paměti, který je možné při dynamické změně velikosti zkopírovat funkcí memcpy. V našem případě v rámci implementace datového typu string_array_s vznikne následující struktura:

struct string_array_s
{
  unsigned size;
  unsigned used;
  string_s *data;
}

V objektu typu string_array_s je alokován blok paměti obsahující data struktury string_s. V případě realokace pole je alokován větší blok paměti, na jehož začátek je zkopírován obsah starého bloku, a starý blok je následně uvolněn. S dynamickými daty objektů typu string_s se při realokaci manipulovat nemusí, protože ukazatele na ně se zkopírují do nového aktivního bloku. Jednotlivé řetězce je možné indexovat celým číslem identifikujícím jejich pozici v bloku paměti.

Výše uvedené je více méně samozřejmostí pro datový typ reprezentující dynamické pole, podstatné je, že tyto vlastnosti jsou vlastní všem datovým typům generovaným šablonami programu cont, včetně obousměrného seznamu a red-black stromu.

Demonstraci použitého principu předvedu na objektu generovaného na základě šablony list. V rámci implementace datového typu string_list_s vzniknou následující struktury:

struct string_list_s_element
{
  string_s object;
  unsigned next_idx;
  unsigned prev_idx;
};

struct string_list_s
{
  unsigned size;
  unsigned used;
  string_list_s_element *data;
  unsigned free_idx;
  unsigned first_idx;
  unsigned last_idx;
}

Výše uvedená struktura string_list_s_element je použita jako základní prvek bloku paměti přiřazeného kontejneru string_list_s. Díky tomu je možné obdobně jako u pole identifikovat prvek vložený do seznamu pomocí celého čísla, udávajícího offset od začátku bloku paměti. Tuto vlastnost využívají indexy výše uvedených struktur, identifikující jeden konkrétní prvek seznamu.

Prvky odstraněné ze seznamu se recyklují při vkládání nového prvku, a v případě, že není žádný volný prvek k dispozici, realokuje se nosný blok paměti stejným způsobem jaký byl popsán u objektu typu string_array_s.

Indexace kontejnerů pomocí celého čísla

Z výše uvedeného způsobu implementace kontejnerů vyplývá, že celočíselný index přiřazený prvku vloženému do kontejneru je neměnný po celou dobu jeho života v tomto kontejneru. Jinými slovy: celočíselný index pozbývá platnosti pouze odstraněním tohoto prvku z daného kontejneru.

Tato vlastnost usnadňuje vytváření pohledů, funkcí a různých mapování mezi kontejnery. Kvůli této vlastnosti byly kontejnery a jejich generátor navržen a implementován, a tato byla využita při implementaci algoritmů pro vyhledávání množiny isomorfních grafů v ohodnoceném hostitelském grafu.

Safe varianty šablon list a rb_tree

Šablony safe_list a safe_rb_tree generují "bezpečné" varianty odpovídajících datových typů. Tyto navíc (oproti standardním implementacím) udržují počítadlo aktuálního počtu prvků v kontejneru, a u každého prvku udržují příznak indikující, zda je tento aktivním prvkem kontejneru. Tato vlastnost je užitečná v případě, že celočíselné indexy identifikující prvek pochází z vnějšího zdroje, a je potřeba otestovat, zda takový index odkazuje na validní prvek kontejneru.

Generování vlastního kódu

Program cont generuje svůj vlastní zdrojový kód. Generátor je implementován s využitím značek, k jejichž generování je určen. V repositáři obsahujícím zdrojový kód programu cont jsou uloženy i vygenerované soubory určené k jeho první kompilaci.

       

Komentáře

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