Svobodný CAD – jak na modulární architekturu v C++? (diskuse)

[Abraxis]

Zalezi na granularite API...

Pokud je to dost coarse-grain, tak bych sel do nejakeho MQ - napriklad mam vyborne zkuenosti s ActiveMQ, umozni ti to (napriklad!) napsat front-end v Jave a back-end v C++ (ktery muze treba bezet na naslapenem serveru...).

Nicmene ty asi mit hodne fine-grained API, provazane hodne s UI. Proto bych nevymyslel kolo a sel do Qt (multi-platform oob, signal/slots koncept je bozi, resi i spoooustu veci, na ktere narazis - scripting, XML, multi-threading, GUI, canvas atd. atd.).

[xkucf03]

jj, na Qt to vypadá (i když nemám rád tohle předbíhání, pravděpodobně to Qt bude) a signály/sloty se zdají být dobře použitelné.

Ale ty signály/sloty si předávají nějaké hodnoty/objekty a otázka právě je, co by to mělo být za objekty – instance jakých tříd/rozhraní, kde by měly být definované.

[Abraxis]

No co jineho, nez C++ Object? Snad proboha pres to nechces honit XMLko ve stringu...

Chlape, psal si neco nekdy ne-trivialniho v C++???

[xkucf03]

Modul je část programu, která jde přeložit samostatně – může si ho někdo zkompilovat bokem a dodatečně nainstalovat. Kdyby šlo jen o uspořádání tříd v rámci jednoho monolitického programu, tak tuhle otázku ani nepokládám (a neříkám tomu moduly).

Závislosti se dají řešit pomocí balíčkovacího systému – co modul (nebo skupina souvisejících modulů), to balíček. Ten bude závislý na balíčku jádra případně jiných modulů. To jsou závislosti v době instalace – ale co závislosti v době kompilace? Jaký bys doporučoval nástroj pro „build“, aby ušetřil co nejvíc práce a aby stačilo na jednom místě deklarovat, co na čem závisí? A ideálně aby z toho vypadly i .deb a .rpm balíčky (aniž by bylo potřeba vynakládat zbytečné úsilí a duplikovat kód/konfiguraci). A třetí věc jsou závislosti v době běhu – aby se načetlo jen to, co je potřeba, aby šlo moduly zapínat/vypínat za chodu. Jde tohle v C++ udělat?

Příklady ze světa Javy: plug-iny v jEditu, moduly v Netbeans, OSGi…

Jde mi o to, jaké jsou nejlepší praktiky, jak tohle řešit. Jaký svobodný software má tohle dobře udělané a mohl by sloužit jako vzor?

No co jineho, nez C++ Object?

Taky si myslím, že by to měl být C++ objekt, ale viděl jsem i systémy, kde je to řešení obecněji (různá pole, mapy) a někteří to tak radí dělat, což se mi ale nelíbí.

[petr_p]

Přijdme mi, že jsi nikdy neviděl dlopen() nebo slabě linkované symboly. Podívej se na perl nebo mediastreamer.

Otázka, jak volné mít API, je těžká. Můžeš začít se statickými datovými typy a skončit u X11 nebo obecným předáváním zpráv jako u mikrojádra. To samozřejmě nevylučuje efektivní přenosy dat formou sdílené paměti.

[Kvakor]

Třeba právě ten dlopen(), dlsym() a dlclose() z dlfcn.h fungují tak, že se běžná dynamická knihovna (.so) načte do paměti a je možné získat adresy vstupních bodů jednotlivých symbolů, jak dat, tak ḱódu, jako ukazatele na void.

To je největší sílá a slabost zároveň - jde sice načíst naprosto cokoliv a dělat s tím cokoliv chcete, ale neexistuje nic, co by pak zabránilo dělat chyby - není obecný způsob, jak se z knihovny dozvědět, jestli je symbol proměnná nebo funkce, jaké má parmetry a co vrací.

Pro praktické použití se nad to musí napsat nějaké wrappery, už třeba jen kvůli tomu, že ve Windows se příslušné funkce jmenují jinak (ale fungují víceméně stejně).

[Grunt]

jestli je symbol proměnná nebo funkce,

No GDB to tahá z debugovacích symbolů (zrovna datové typy symbolů se tam myslím kódují i když není knihovna přeložena s parametrem -g). Ale naostro to tak dělat a spoléhat na to je samozřejmě kravina. Hlavičky, hlavičky, hlavičky. Dynamický modul se ještě nemusí automaticky rovnat jednomu binárnímu souboru.

[Grunt]

Dynamický modul se ještě nemusí automaticky rovnat jednomu binárnímu souboru.

I takový kernel si myslím tyto věci exportuje bokem do texťáku, takže automaticky nemusí platit, že stačí modprobnout libovolné *.ko které kde seženu a že to automaticky musí fungovat.

[petr_p]

není obecný způsob, jak se z knihovny dozvědět, jestli je symbol proměnná nebo funkce, jaké má parmetry a co vrací.

A proč bych to dělal? Od toho máme hlavičkové soubory.

Ale možná jenom hledáte gobjectový introspection.

[Josef Kufner]

Qt Meta-Object System

[Grunt]

Modul je část programu, která jde přeložit samostatně – může si ho někdo zkompilovat bokem a dodatečně nainstalovat.

A co by si takhle chtěl dělat prosimtě v CADu? Obdobu skinů pro Winamp či Firefox extensions?

[Grunt]

Ale když to tak čtu tak si myslím, že jsem dítě štěstěny, že jsem se nikdy Javu nenaučil a C++ záměrně nepochopil.

[Luk]

Předávání dat ve formátu XML v rámci téhož programu (byť mezi různými moduly) je něco, za co by se mělo věšet za pytel do průvanu. Je to zaručená cesta, jak udělat program pomalý a žravý.

[Pnaky]

A snadno přenositelný mezi architekturami, hamba.

[pavlix]

A snadno přenositelný mezi architekturami

Stejně jako s jakýmkoli jiným textovým formátem nebo i dobře specifikovaným binárním formátem.

[xkucf03]

Ale tady se bavíme o interním API jednoho programu – jednoho procesu běžícího na jednom počítači. Tam bych to XML necpal, ač ho mám jinak rád. XML se hodí na komunikaci s okolím, třeba jako formát souborů nebo na něm postavit komunikační protokol pro spojení více programů po síti.

XML se v rámci jednoho běžícího procesu dá taky smysluplně použít. Ono totiž XML není jen text s ostrými závorkami, který se musí vždy parsovat/serializovat, ale v první řadě je to objektový model. Předávat si DOM není o moc náročnější než si předávat hashmapu (ostatně do ní to klidně může interně ukládat). Problém vidím v tom, že je to příliš volná, slabě typovaná struktura. Abychom v tom udělali pořádek, je potřeba na obou stranách použít (stejné) XML schéma. A teď se k tomu dostáváme – toto schéma by bylo potřeba nějak sdílet mezi moduly a zajistit, aby měly stejnou verzi. A to už rovnou můžeme sdílet ty hlavičkové soubory a posílat si C++ objekty.

[Dadam]

Na to, abych radil že ho máte použít (a proč), s ním mám moc málo zkušeností. Tak se aspoň zeptám: uvažovali jste Boost? Signály a sloty má, správu pluginů zdá se taky (nějaký Boost Extension), narozdíl od Qt je to čisté C++. Navíc se mi tak nějak zdá, že kdykoliv se snažím najít na něco knihovnu, dřív či později se doklikám právě k němu.

Co se těch pluginů týče, tak pracuju na větším projektu, který je založený právě na pluginech. Máme jádro, které obsahuje rozhraní každého pluginu coby hlavičku. Plugin obsahuje továrnu (tu implementuje knihovna, v našem případě Poco) se standardním rozhraním. Ta pak vytváří vlastní objekty toho pluginu.

Závislosti mezi pluginy bych nedělal. Aspoň ne přímo. Pokud by plugin A závisel na pluginu B, nechal bych A požádat jádro o objekt B. Aby jádro řešilo věci okolo pluginů, a pluginy samotné nenačítaly nic.

[xkucf03]

Co se těch pluginů týče, tak pracuju na větším projektu, který je založený právě na pluginech.

Dík za relevantní komentář.

Máme jádro, které obsahuje rozhraní každého pluginu coby hlavičku.

Ale co když bude někdo chtít přidat svůj modul, aniž by zasahoval do toho jádra? To by ještě šlo, ale co když na něm bude záviset jiný modul? To v tom CADu může nastat, protože ho bude tvořit víc nezávislých autorů a nemusí být všechno centralizované na jednom místě.

[Dadam]

Máme to tak, že jádro obsahuje hlavičky s definicemi rozhraní (osobně bych ty hlavičky izoloval mimo jádro, ale to už na mě nezáleží). Když chceš přidat plugin, musíš použít některé z nich. Vypadá to jako dost low level záležitost, ale záleží to jen na tom, jak definujete rozhraní.

Můžete mít modul pro uložení a modifikaci modelu. Ten má dost specifické rozhraní, v podstatě se jedná jen o různé implementace té samé funkcionality.

Pak ale máte modul pro GUI. Ten jen dostane widget, do kterého má kreslit, vyžádá si výš zmíněné rozhraní pro práci s modelem a co s ním udělá, je jen na něm.

Je to trochu stupidní a zjednodušený příklad, předpokládám ale že si dokážeš představit jak to myslím. Výhodou podle mě je to, že můžete mít jak rychlé low level pluginy, tak pluginy které třeba přijmou jakoukoliv zprávu v XML (osobně bych radši zvolil JSON, pokud bych si to měl psát sám).

[mirec]

Kedysi dávnejšie som sa nad touto otázkou zamýšľal. Veľmi pekne má systém pluginov vyriešený Qt Creator. Odporúčam si prehrabať zdrojáky, veľmi inšpiratívne čítanie.

[xkucf03]

Dík, kouknu na to.

[mirec]

Na toto PDF som chcel ešte poslať link, je to síce staršie, ale celkom dobre spracované. Qt má celkom fajn systém signálov a slotov (teoreticky by šlo použiť aj na update pluginov bez reštartu pri ukladaní signálov do fronty kým sa plugin nereštartuje). Tiež systém rozhraní je veľmi slušný. Qt Creator nad to ešte používa dependency.

[kralyk z abclinuxu]

Rozhodně nesdílet hlavičkové soubory mezi moduly. To by pak nebyly moduly.

Vzhledem k tomu, že jde o C++, rozdělil bych to na low-level a high-level API.

Úloha low-level API by byly základní operace jako načtení modulu (ať už loadtime nebo runtime přes nějakej ten dlopen a spol.) a dále základní enumerace, tzn. jméno modulu, verze API, verze modulu, závislosti (tzn. jména modulů, které musí být předtím načteny) a podobně. Měl by být taky nechán nějaký porstor pro kompatibilní budoucí rozšíření.

Toto low-level API by definovalo jádro programu, a to poměrně striktně, tzn. s dopřednou komtaibilitou vč. kompatibility ABI. V C++ je potřeba na to dát pozor, ale dá se to...

No a high-level API by pak bylo runtime API, padla tady zmínka o Qt signals, například, takže něco takového, případně jsou i jiné možnosti... Toto API by si pak definoval modul sám a v rámci něj by se poskytovaly všechny relevantní funkce modulu i vazby mezi moduly.

[xkucf03]

Rozhodně nesdílet hlavičkové soubory mezi moduly. To by pak nebyly moduly.

Jak by potom byl implementovaný ten příklad ze zápisku?

modul pro výpočet spotřeby materiálů (a tisk nějaké pěkné tabulky) potřebuje od jiného modulu zjistit, jaké objekty v modelu máme a z jakých materiálů jsou složené.

V jaké formě by si ty dva moduly vyměňovaly data, jakou by měly strukturu?

[kralyk z abclinuxu]

Jak by potom byl implementovaný ten příklad ze zápisku?

To záleží na tom, jestli ty struktury těch modelů a materiálů definuje jádro. Pokud ano, tak je to celkem jednoduché (předají se instance,...), pokud ne, je to složitější a byla by pak otázka, jestli je takový návrh vůbec dobrý...

V jaké formě by si ty dva moduly vyměňovaly data, jakou by měly strukturu?

To záleží na konkrétních požadavcích, ale souhlasil bych s Lukem, že XML (apod.) radši ne (pokud by to nebyl nějaký specifický případ).

Nemohl bys ty moduly nějak konkrétněji definovat? Přijde mi, že se snažíš najít v C++ javovské packages, což tak úplně nejde (resp. ne obecně)...

[xkucf03]

To záleží na tom, jestli ty struktury těch modelů a materiálů definuje jádro. Pokud ano, tak je to celkem jednoduché (předají se instance,...), pokud ne, je to složitější a byla by pak otázka, jestli je takový návrh vůbec dobrý...

A podaří se nám v jádře udělat rozhraní pro všechno, co si mezi sebou moduly potřebují vyměňovat? Některá rozhraní můžou (a měla by být) jednotná – např. pro importní a exportní moduly. Ale u všech to IMHO nejde, resp. není to správné. Pokud je to technicky proveditelné (snad by mělo být) a není to nijak šíleně pracné, tak si myslím, že bychom měli mít i možnost závislosti modulů mezi sebou a do modulu jménem „jádro“ dát jen ta společná rozhraní. Přijde mi to jako pružnější a univerzálnější návrh. Paralela jsou balíčky a knihovny v distribucích – různé programy používají různé knihovny a závisí na sobě – není jedno rozhraní, za kterým by byly schované všechny knihovny.

Např. někdo udělá modul pro sazbu tabulek a textových výstupů. Více jiných modulů ho bude chtít využít a sázet pomocí něj své výstupy. Tak mi přijde rozumnější, když budou záviset na tom modulu – ne že se rozhraní nacpe do jádra. Jednak by byl v jádře časem bordel a ztrácel by se přehled, co je čím používáno a jestli není nějaký kód zastaralý/zbytečný. A jednak by to představovalo velké nároky na centrální autoritu – správce projektu – kteří by museli rozhodovat, co do jádra dát a co ne – musela by se dělat řada administrativních rozhodnutí. Ale když budou moci moduly záviset na jiných modulech, může být vývoj živelnější – dá se tomu nechat volný průběh, každý si může dopsat libovolný modul a praxe ukáže, co uživatelé používají a chtějí (a to se pak dá zahrnout do projektu mezi ostatní zdrojáky hned vedle jádra). Správci projektu to pak můžou jen trochu usměrňovat a pomáhat, aby podobné moduly implementovali jedno rozhraní.

Přijde mi, že se snažíš najít v C++ javovské packages, což tak úplně nejde (resp. ne obecně)...

Javovské balíčky ani ne, spíš JARy nebo lépe OSGi moduly (což je JAR + metadata). Moje představa je zatím takováhle:

1. Distribuční balíček (.deb,.rpm…) libcadus-něco obsahující
2. jednu nebo více dynamických knihoven + jejich metadata a v těch knihovnách pak
3. jedna nebo více tříd implementujících určitá rozhraní (ať už společná nebo nějaké svoje speciální)

Modul byl ta jedna dynamická knihovna. A víc modulů by šlo dát do jednoho balíčku. Každý balíček by měl ještě -dev verzi, kde by byly hlavičkové soubory – rozhraní. Pro naprogramování nového modulu bych si pak nainstaloval -dev balíčky jádra a modulů, na kterých bude ten můj závislý.

Mám tři dotazy:

• Je to technicky proveditelné?
• Jak dlouho by trvalo zkušenému C++ programátorovi vytvořit tento framework? (žádná funkcionalita, jen framework, buildovací a balíčkovací skripty… viditelný výsledek: prázdné hlavní okno aplikace + možnost zapínat a vypínat moduly + jeden „Hello World“ modul)
• Je to pro projekt tohoto rozsahu overengineering nebo ne?

[pavlix]

Je to technicky proveditelné?

Rozhodně ano.

Jak dlouho by trvalo zkušenému C++ programátorovi vytvořit tento framework? (žádná funkcionalita, jen framework, buildovací a balíčkovací skripty… viditelný výsledek: prázdné hlavní okno aplikace + možnost zapínat a vypínat moduly + jeden „Hello World“ modul)

Podle mě k tomu nemusíš nic programovat, kromě seznamu modulů UI na vypínání/zapínání modulů. Možnost dynamických modulů je standardní vlastnostní dynamického linkeru. Případně můžeš použít nějakou lehkou nadstavbu z aplikačního frameworku.

Je to pro projekt tohoto rozsahu overengineering nebo ne?

Ani ne.

[kralyk z abclinuxu]

Jasný, tak pokud nevadí, že jeden modul linkuješ proti jiným modulům, tak je to asi v pohodě. To bych to skoro okopíroval z toho Qt Creatoru, zmíněného výše Ty požadavky vypadaj hodně podobný...

(Teda ne nutně s Qt specifikama, nevim, jestli budete Qt používat...)

[Rezza]

Jak uz tady nekdo psal - jdes podle me z opacne strany k veci. Ano, rozsiritelnost a modularnost je dulezita, ale nejdriv potrebujes to zakladni vec CADu

[Ivan]

Neco podobnyho jsem resil v nasem projektu a nakonec jsem pouzil tohle. Je to abstraktni tovarna na objekty pro knihovnu Loki.

Hlavni aplikace obsahuje pouze header pro rozhrani(abstraktni trida). Headery implementaci nikdo neincluduje. Dokonce mam implemetace ve zvlastnich knihovnach.

Staci kdyz se trida s implemetaci "zaregistruje v tovarne":

#include "ABaseClass.h"
class SubClass1 : public ABase
{
public:
        SubClass1(unsigned int i) : ABase(i) {};
        
        virtual void doWork(void) const {...}
};
Util::RegisterInFactory<SubClass1, ABaseFactory> regSubClass1("SubClass1");

hlavni program potom pouzije tovarnu pro vytvoreni kontretni tridy:

int main( int argc, const char* argv[] )
{
        void *handle = dlopen("./libSubClass1.so", RTLD_NOW | RTLD_GLOBAL);
        if( !handle)
        {
                std::cout << dlerror() << std::endl;
                return 1;
        }
        
        ABase *one = ABaseFactory::Instance().createPtr("SubClass1", 0);
        if( !one)
                return 2;
        
        one->doWork();

        return 0;       
}

Pouzivame to v projektu Tora. Tim modulem je "connection provider" - knihovna ktera je wrapperem nad nativni knihovnou pro pripojeni do databaze(libpg.so, libclntsh.so, ...). Pokud hlavni program najde instalaci DB klienta(Oracle,PgSQL, MySQL), tak si nacte plugin(knihovnu) a rovnou muze vytvaret instance trid z te knihovny. Samotna hlavni aplikace vubec nezavisi na zadnem DB klientovi. Zatim mi to funguje jen na Linuxu a Woknach - na MAC se mi to zatim nepodarilo portovat - nemam MAC.

[Ivan]

PS: QT ma vlastni "framework" pro pluginy. To jsem ale jeste nezkouzel.

[Rezza]

Ano a pokud to bude Qt - tak rovnou jit do tohohle. Idealni studijni material jsou zdrojaky KDE. To je jen kupa pluginu poslepovanych dohromady a hlavne bych se mrkl na KParts atd.

[Dadam]

Na knihovnu Loki bacha. Krásná je, o tom žádná, ale zkus předat funktor s nabindovanými hodnotami do jiného vlákna. Je to jen jedna "malá" chyba, ale mně to něco vypovídá o tom, jak moc to bylo testované...

[User682]

zdravim,

osobne bych sel cestou, ze kazdy modul umi prijmout libovolnou zpravu. Umi rici, zda ji vubec zpracoval a kdyz ano, tak jak(boolean/XML data). Da se to udelat i tak, ze odpovedi modulu bude zprava. Bud, ze je to OK/KO, anebo zprava/y pro dalsi moduly.

Pro inspiraci se podivejte na definice a specifikace XML struktur insolvencniho rejstriku (ISIR) a zamerte se na zakladni obalku zpravy a typy poznamek. Konkretni data ve zprave uz nahradite konkretni implementaci podle Vasich potreb.

gf

[xkucf03]

XML mám rád, ale přijde mi vhodné ho použít jen na externí rozhraní, ne na interní API – viz #24.

[deda.jabko]

Osobne bych k tomu pristupoval jinak. Jako prvni vec bych resil hlavni cast -- modul pro CSG. Pozadavky na struktury, ktere to bude pouzivat, vyrazne ovlivni, jak bude vypadat pozadovane rozhrani. Jste schopni uz ted rict, jak ty struktury budou vypadat?

Dal tu nekdo navrhl pouzit nejaky vyssi jazyk jako lepidlo, to neni spatne reseni. Tu se nabizi vybrat konkretni hotove reseni, ktere ma solidni FFI, zbytek uz z toho vyplyne sam.

[Radek Miček]

Pozadavky na struktury, ktere to bude pouzivat, vyrazne ovlivni, jak bude vypadat pozadovane rozhrani. Jste schopni uz ted rict, jak ty struktury budou vypadat?

+1

Osobně bych napřed napsal nějaký kód a teprve poté řešil, jak a zda to případně rozdělit.

[kralyk z abclinuxu]

Osobne bych k tomu pristupoval jinak. Jako prvni vec bych resil hlavni cast -- modul pro CSG. Pozadavky na struktury, ktere to bude pouzivat, vyrazne ovlivni, jak bude vypadat pozadovane rozhrani.

+1

Dal tu nekdo navrhl pouzit nejaky vyssi jazyk jako lepidlo, to neni spatne reseni.

Tady by bylo záhodno připomenout, že třeba Python se s C++ lepí relativně velmi dobře. Viz třeba sublime apod.

[Martin Beránek]

Když už tu byly ty příklady z Javy, docela se mi líbí systém Extension/ExtensionPoint z Eclipse RCP.

[Miloslav Ponkrác]

Mně se hrozně líbí, jak ještě se neví, co se bude dělat, jaká data tam budou lítat, ale už se ví, jaká technologie se použije.

Neznáte data, neznáte struktury do detailů.

Osobně bych jádro malé nedělal. Není proč. Modul by měl dělat jenom něco volitelného, co nemusí být trvalou součástí.

Ono to modulové API, komunikace a další něco stojí. Ono to také stojí víc práce, více lidí, více času, více ladění a více problémů.

Věmoval bych více času dobře navrženému objektovému modelu a datovým strukturám. Datové struktury jsou základ každého programu.

Až budete mít excelentní objektový model a datové struktury (a to klidně na papíře, není třeba nic implementovat za každou cenu), pak zjistíte, že modul se snadno udělá tím, že vystrčíte nějaké objekty pár základních tříd ven přes rozhraní Factory či podobně.

Pokud C++ program rozdělíte do nezávislých modulů, ztrácíte sílu C++. Na to C++ není příliš dělané, jeho síla je v rozdělení programu do nezávislých namespaců a tříd, které se sice kompilují jako celek, ale mají velmi dobré vlastnosti typu oddělenost, zapouzdřenost, ochranu proti jiným komponentám, atd.