OctaForge - OctaSTD update, libcubescript a OctaBuild

5.9.2015 16:35 | Přečteno: 1380× | octaforge | | poslední úprava: 5.9.2015 18:13

Od posledního zápisu proběhlo mnoho změn v OctaSTD a vznikly dva další projekty.

OctaSTD změny

Seznam změn je v podstatě chronologický, jen pospojovaný tak, aby to dávalo smysl. Přidal jsem několik nových věcí a dost změnil.

Změny v infrastruktuře

OctaSTD teď používá ostd místo octa jako svůj namespace (a stejně tak adresář s moduly se jmenuje ostd). Header soubory používají příponu .hh a zdrojové soubory .cc.

Kompletní hash table

Asociativní mapy jsou teď funkčně kompletní. Podporují rehash, load factor balancing a většinu hlavních API. Kromě toho prošly optimalizací - buckets se alokují v kusech (od 32 to 128 buckets) a respektují alignment. Kromě toho kontejner podporuje vlastní alokátory. Kromě asociativní mapy Map existují i Set, Multimap a Multiset, a také Keyset a Multikeyset. Všechny používají stejný základ (sdílejí většinu implementace). Keyset je momentálně experimentální - je to v podstatě hybrid mezi Set a Map - indexovatelný jako Map, ale klíče jsou součástí hodnoty samotné.

Nové Stream API

OctaSTD teď podporuje streamy jakožto obecnou Stream class v souboru stream.hh. Streams jsou samozřejmě range-based. StreamRange je InputRange, která umožňuje číst ze streamu jakéhokoliv typu (a také do něj zapisovat, protože podporuje interface OutputRange). Spousta věcí se dá implementovat jako stream, nicméně OctaSTD zatím podporuje základní I/O, jako součást io.hh. Tento modul implementuje FileStream a několik dalších funkcí. Ukázka pár z nich:

#include <ostd/algorithm.hh>
#include <ostd/string.hh>
#include <ostd/io.hh>

using namespace ostd;

int main() {
    writeln("Zapisuji soubor..."); // z io.hh

    FileStream wtest("test.txt", StreamMode::write);
    String test = "Testovaci obsah souboru";
    copy(test.iter(), wtest.iter()); // obecne algoritmy se StreamRange, z algorithm.hh
    wtest.close();

    FileStream rtest("test.txt", StreamMode::read);
    writeln("read file");

    String cely_soubor(rtest.iter()); // range-based konstruktor se StreamRange
    rtest.seek(0);
    String cast_souboru(take(rtest.iter(), 5)); // max 5 znaku, pomoci TakeRange

    writefln("Soubor: %s", cely_soubor); // formatovani, z io.hh, popisu pozdeji
}

Jak je vidět, streams se kompletně integrují se všemi obecnými algoritmy pro vstupní a výstupní ranges. StreamRange bohužel nepodporuje ForwardRange a vyšší, a bohužel nemůže, takže multi-pass algoritmy nebudou fungovat. I tak je ale možné spoustu algoritmů se streamy použít. Například:

#include <ostd/algorithm.hh>
#include <ostd/functional.hh>
#include <ostd/io.hh>
#include <ostd/platform.hh>

using namespace ostd;

int main() {
    FileStream wtest("test.bin", StreamMode::write);
    // zapis se specifickym typem
    copy(iter({ 0xABCD1214, 0xBADC3264, 0xDEADBEEF, 0xBEEFDEAD }), wtest.iter<Uint32>());
    wtest.close();

    FileStream rtest("test.bin", StreamMode::read);
    writefln("velikost streamu: %d", rtest.size());

    for (Uint32 x: map(rtest.iter<Uint32>(), FromBigEndian<Uint32>()))
        writeln("hodnota: ", x);
}

S tímto příkladem by stálo za zmínku, že všechny I/O streamy v OctaSTD jsou binární - tzn. StreamMode::read se chová jako rb a to samé pro ostatní typy. Osobně mám za to, že textové streamy jsou špatný design a mají více nevýhod, než výhod. Z poslední ukázky je také vidět, že je možné číst a zapisovat se specifickým typem. Tento typ musí být POD. Výchozím typem je char.

Typově nezávislé formátování

Každý si je vědom problémů s funkcemi typu printf a obecně C varargs. OctaSTD proto teď podporuje formátování podobné printf, ale type-safe pomocí C++11 varargs, a s extra funkcemi. Modul format.hh implementuje funkci format(), která formátuje do obecné výstupní range. Základní ukázka:

#include <ostd/format.hh>
#include <ostd/string.hh>
#include <ostd/range.hh>
#include <ostd/io.hh>

using namespace ostd;

int main() {
     auto app = appender<String>();
     format(app, "hello %s", "world");
     writeln(app.get());
}

Rozdíl od printf je v tom, že formátovací značka %s podporuje jakýkoliv typ. Ostatní značky existují pro další runtime ověření - např. %d vypíše jakýkoliv celočíselný typ, ale selže na ostatních. Díky tomu, že modul je type-safe, už nejsou potřeba další značky pro velikost typu - %d vypíše jak int, tak třeba long long. Kromě toho modul podporuje výpis kompletních ranges, takže se dá snadno vypsat obsah jakéhokoliv kontejneru. A aby toho nebylo málo, tak podporuje i formátování uživatelských typů BEZ extra alokací.

Pár ukázek použítí je zde. Modul toho podporuje ještě mnohem víc, bohužel dokumentace momentálně chybí - ještě jsem ji nestihl napsat.

Modul io.hh podporuje funkce write, writeln, writef a writefln. Ty první dvě jsou také typově obecné, tzn. podporují neomezené množství argumentů jakéhokoliv typu, ty poslední dvě fungují jak printf s tím, že používají format.hh. Koncovka ln znamená, že na konci řetězce bude nový řádek. Tyto čtyři metody jsou podporovány i jako metody na jakémkoliv Streamu.

Signals-slots

Nový modul event.hh přidává funkcionalitu pro signals-slots. Ukázka je zde. Tento systém není asynchronní - byl by potřeba event loop. Asynchronní funkcionalita bude potřebovat jinou implementaci. Stejně jako zbytek OctaSTD je tento systém typově bezpečný.

Zero-overhead string slicing a další změny práce s řetězci

Toto je asi nejvýraznější kus funkcionality, který odděluje OctaSTD od ostatních C++ knihoven. V C a C++, řetězce jsou obecně zakončené nulou. Slicing pak vyžaduje alokaci nového řetězce. OctaSTD se snaží tento systém změnit.

Už od začátku existuje systém ranges. Řetězce mají také svůj vlastní typ ranges, resp. dva - CharRange a ConstCharRange. Oba typy reprezentují vlastně dva pointery. Vtip je v tom, že ConstCharRange má takový set konstruktorů, že se dá vytvořit implicitně jak z C řetězců (char * a const char *), tak OctaSTD řetězců a CharRange. To znamená, že ConstCharRange je vlastně univerzálním read-only řetězcem bez vlastní paměti. Protože je to range s náhodným přístupem, podporuje slicing.

Všechna OctaSTD API, která pouze čtou řetězce, mají ConstCharRange jako argument. Díky tomu vědí o délce tohoto řetězce a nepotřebují nulové zakončení. Tím pádem je 100% bezpečné řetězce řezat pomocí ranges a potom je poskytnout jakémukoliv API.

#include <ostd/string.hh>
#include <ostd/io.hh>

using namespace ostd;

void print_test(ConstCharRange test) {
    writeln(test);
}

int main() {
    print_test("foo"); // C literal
    print_test((const char *)"foo");
    print_test(String("foo"));

    ConstCharRange stest = "hello world";
    print_test(stest.slice(0, 5)); // hello
}

ConstCharRange používá template metaprogramming tak, aby délky literálů byly známé už při kompilaci, tzn. první volání print_test ví, že délka je 3. U druhého volání máme pouze pointer, takže délka není známá - takže se použíje strlen. Toto sice znamená overhead, nicméně tato délka by stejně byla potřeba v jiném volání jinde - takže ve většině případů to není problém. Co se týče nulového zakončení - typ String vnitřně stále nulové zakončení používá, pro kompatibilitu s C. Takže datový pointer Stringu je bezpečné předat C funkci.

Filesystem modul

Nově jsem přidal modul filesystem.hh, který umožňuje iterovat adresáře a pracovat se soubory. Tento modul jsem přidal včera a bude ještě trvat, než se stabilizuje. Zatím ukázka:

#include <ostd/filesystem.hh>
#include <ostd/io.hh>

using namespace ostd;

int main(int, char **argv) {
    DirectoryStream ds(argv[1]);
    writeln("pocet souboru: ", ds.size());
    for (FileInfo i: ds.iter()) {
        writeln("cesta: ", i.path());
        writeln("soubor: ", i.filename());
        writeln("cas modifikace: ", i.mtime());
    }
}

Další změny

Funkcionální knihovna teď podporuje functory pro práci s endianess. Ranges podporují novou kategorii ContiguousRange, která přídává další záruky do FiniteRandomAccessRange - musí reprezentovat jednotnou sekvenci jako pár pointerů, podobně jako C++14 ContiguousIterator. Nový modul platform.hh umožňuje detekci platforem, endianess cílové architektury a kompilátoru (podporuje detekci GCC, Clang a MSVC). Spousta funkcí byla přejmenována nebo dále změněna. A přidal jsem spoustu nových algoritmů, functorů a další.

OctaBuild a libcubescript

Už nějakou dobu jsem měl v plánu pro OctaForge napsat build systém. Proto jsem vytvořil nový projekt, OctaBuild. OctaBuild je v základu inspirovaný klasickým Make, ale se spoustou změn a vylepšení.

Problémem byl skriptovací jazyk. "Velké" skriptovací jazyky se na toto nehodí, protože místo obecného skriptování je prioritou jednoduchá práce s řetězci a makry. Proto jsem se rozhodl použít jazyk Cubescript, který už OctaForge používá v enginu samotném - pochází z Cube 2: Sauerbraten. Cubescript je jednoduchý, dynamický jazyk založený na principu, že všechno je řetězec. Vleze se do přibližně 4000 řádků C++, nemá garbage collector, ale má automatickou správu paměti, používá dynamic scope, a má jednoduchou syntaxi podobnou Lispu.

Problém byl v tom, že Cubescript byl do enginu v podstatě zabudovaný. Proto jsem vytvořil ještě jeden nový projekt, libcubescript. To je samostatná distribuce Cubescriptu přepsaná tak, aby se dala jedndouše zabudovat do jiných projektů - nepoužívá globální proměnné a moderní high level API.

OctaBuild je dostupný zde a libcubescript zde. Momentálně dostupné featury jsou:

• V principu podobný Make s podobným systémem rules.
• V podstatě všechny featury ze základního Make.
• Podporuje paralelní sestavení, podobně jako Make -jN.
• "Plnotučný" skriptovací jazyk, což znamená podporu podmínek, cyklů apod. a dynamické tvorby rules.
• Glob matching.

Bohužel ještě spousta práce zbývá:

• Automatický tracking závislostí (Make toto nemá, OctaBuild to mít bude).
• Nezávislost na shellu pro volání kompilátoru apod.
• Větší standardní knihovna včetně funkcí pro správu externích knihoven a detekci věcí závislých na platformě.
• Podpora Windows.

Momentálně ukázka souboru build definicí:

rule all test

OBJ = (strreplace (glob "*.c") ".c" ".o")

rule test $OBJ [
    echo " LD" $target
    shell cc -o $target $sources
]

rule %.o %.c [
    echo " CC" $target
    shell cc -c -o $target $source
]

rule clean [] [
    echo " CLEAN" $OBJ test
    shell rm -f $OBJ test
]

// zavislosti

rule foo.o foo.h
rule bar.o bar.h
rule test.o [foo.h bar.h]

Cílem je také udělat z OctaBuildu knihovnu - tak, aby ji bylo možné použít uvnitř samotného enginu. To umožní dynamické sestavení herních modulů enginu přímo zevnitř enginu.

Závěr

To je zatím vše. Pro jakékoliv připomínky nebo otázky je tu sekce komentářů.

       

Komentáře

[Bedňa]

Tak konečne nebojuješ proti namespace

./client_linux_x64 
Using home directory: /home/mario/.octaforge/
<<< setting loglevel to WARNING >>>
[[INIT]] - sdl
[[INIT]] - net
[[INIT]] - game
[[INIT]] - lua
[[INIT]] - video
[[INIT]] - gl
Renderer: GeForce 7025 / nForce 630a/integrated/SSE2 (NVIDIA Corporation)
Driver: 2.1.2 NVIDIA 304.125
GLSL: 1.20 NVIDIA via Cg compiler
[[INIT]] - console
[[INIT]] - world
[[INIT]] - sound
[[INIT]] - cfg
OF defaults
[[INIT]] - render
[[INIT]] - mainloop
[[ERROR]] - variable hidechanges already exists
failed allocating radiance hints buffer!

Nejak to skapalo.

[q66]

na 7025 to nepojede, moc slabá karta.

minimum je tak intel HD3000 nebo nvidia 9600gt. Pak to už pojede, na nižší detaily.

[Václav "Darm" Novák]

Ah… Teď jsem přemýšlel že to opět zkusím, ale GMA X3100 asi smůla :/

[q66]

asi ne... chce to aspoň sandy bridge, ale nejlíp lepší.

[Václav "Darm" Novák]

Jo, no… Tohle byla poslední katastrofa od Intelu, pak už začali dělat slušné integrované grafiky.

[Václav "Darm" Novák]

terminated by signal SIGSEGV (Address boundary error)

[Bedňa]

Mám aj GeForce GTX 275, ale musel som ju vybrať, pretože mi zhorel zdroj a ten čo som tam dal má problém ju utiahnuť. Tak to testnem neskôr.

[q66]

jo, GTX 275 by to měla zvládnout.

[Bedňa]

Tá karta to dá ľavou zadnou na rozdiel od tých marketingových táto utiahne hravo hocijaký engine.

Memory Interface GDDR3
Memory Interface Width 448-bit
Memory Bandwidth (GB/sec) 127.0

[q66]

275 by měla být jen o trochu slabší, než gtx 460, takže to zvládne tak akorát...nicméně dnešní karty budou o dost výkonnější (třeba gtx 950, nebo i 750)

[Bystroushaak]

Respekt.

[KS]

Dobrá práce!

[dumblob]

Moc hezke, jen tak dal!

Mimochodem, mrknul jsem na libcubescript a protoze ten jazyk vypada na tech necelych 5000 SLOC docela obstojne, zajimalo by me, zdali se ti jiz nekdo ozval s pozadavkem prepsat libcubescript do C99, aby byla knihovna pouzitelna i z C. Podle hodne letmeho pohledu nebude uplna brnkacka prepsat libcubescript do C

[q66]

jo, to by bylo docela těžký... a vyžadovalo by to o dost rozdílný styl API.

[Jardík]

struct SignalTest {
    // ...
    Signal<const SignalTest, int, const char *> on_simple = this;
    Signal<      SignalTest, float            > on_param  = this;
    // ...
};

Mně se to vůbec nelíbí. Proč? Protože každý signál zabírá místo v každé instanci objektu. Tento signál pak zase obsahuje ukazatel zpět na objekt.

[q66]

nějaká data v tom objektu stejně být musí, pro uložení connected callbacks.