Parametry příkazu, roury, Java a jiné jazyky

11.9.2016 02:07 | Přečteno: 1621× | Softwarové inženýrství | poslední úprava: 11.9.2016 02:16

Při psaní složitějších skriptů a příkazů pospojovaných rourami někdy člověk narazí na záhadné chyby. Ty jsou někdy způsobeny tím, že např. název souboru obsahuje mezery nebo jiné „nečekané“ znaky.

Někteří proto zastávají názor, že by se mezery (a diakritika atd.) neměly v názvech souborů používat. Já si spíš myslím, že program by se s tím měl vypořádat a měl by pracovat správně, i když tam takové znaky jsou (jestli je praktické tak soubory pojmenovávat, to už je na uživateli, nicméně program by to zvládat měl).

Programům předáváme parametry (argumenty), např. zadáme příkaz:

echo ahoj, jak se máš

Což nám vypíše text ahoj, jak se máš a znak konce řádku. Mohlo by se zdát, že příkaz dostal jeden parametr (celou větu). Ale není tomu tak. Snadno se o tom přesvědčíme např. u příkazu pro vytváření adresářů:

mkdir ahoj, jak se máš

který nám vytvoří čtyři adresáře (po jednotlivých slovech).

Spouštění procesů je docela hezké API – příkaz má parametry a ty jsou polem textových řetězců. Jednoduché a univerzální. Na úrovni tohoto API neexistuje nic jako přepínače (např. ls -la nebo ls -l -a), ty jsou interpretované až uvnitř toho kterého programu – který při spuštění dostal vždy jen to pole textových řetězců.

Příkaz echo ve skutečnosti taky dostal čtyři parametry, ale zase si je pospojoval mezerami, což je jeho vnitřní logika, a proto se chová jinak než příkaz mkdir.

Pokud budete spouštět systémový příkaz z nějakého programovacího jazyka (Java, C, C++, Perl, Python…) budete konstruovat toto pole textových řetězců a chybu v tom neuděláte – máte jasné hranice, kde jeden parametr končí a druhý začíná.

Pokud ale příkaz pouštíme z shellu (Bash atd.), konstruuje za nás toto pole shell a dělá to typicky tak, že rozdělí text podle mezer. Pokud chceme více slov jako jeden parametr, musíme je dát do uvozovek. U některých příkazů je výsledek stejný (echo) u jiných ne (mkdir a většina ostatních).

Další zajímavá věc je, že některé příkazy, které pracují se soubory, umí zpracovat víc souborů v rámci jednoho běhu procesu – stačí do pole textových řetězců dát víc prvků. A výsledek je pak stejný (akorát to trvá trošku déle), jako kdybychom tentýž příkaz pustili několikrát.

Tudíž toto:

touch a b c

dá stejný výsledek jako toto:

touch a
touch b
touch c

a jako toto:

echo -e 'a\nb\nc' | xargs touch

a toto:

echo -e 'a\nb\nc' | xargs -n1 touch

(volba -n1 způsobí, že xargs předá danému příkazu maximálně jeden parametr a pro další pustí další proces)

Zatímco následující dva příkazy dávají jiný výsledek:

$ echo -e 'a\nb\nc' | xargs echo
a b c

$ echo -e 'a\nb\nc' | xargs -n1 echo
a
b
c

Zde už se po poněkud zdlouhavém důvodu dostáváme k jádru zápisku – při použití xargs můžou vznikat ty zmatky, kdy skript často funguje správně a někdy „záhadně“ chybně. Většinou je to o mezerách a uvozovkách… Na podobné problémy můžete někdy narazit i při spouštění příkazů přes su -c, sh -c, find -exec a podobně.

BTW: v souborovém systému /proc, který mj. zpřístupňuje informace o parametrech procesů jsou tyto parametry oddělené nulovým bajtem, takže hranice mezi parametry jsou jasně patrné (viz cat /proc/self/cmdline | less)

Program parameter-lister

Proto jsem si řekl, že by pro ladění různých skriptů bylo dobré mít program, který vypíše svoje parametry a bude z toho jasné, zda to byly dva parametry nebo jeden obsahující mezeru, případně zda tam byly mezery na konci nebo na začátku, zda parametry obsahovaly znak konce řádku atd. Když něco nebude fungovat podle našich představ, jednoduše program vložíme na určité místo ve skriptu/rouře a necháme si vypsat, jaké parametry tam dorazily.

Tento program jsem si napsal. Jedná se zároveň o programátorské cvičení (viz níže).

Očekávané vlastnosti programu:

• nemůže mít sám přepínače/parametry, protože všechny parametry má vypsat, takže pokud mu chceme předat nějakou informaci, uděláme to přes proměnné prostředí
• měl by podporovat více výstupních formátů – např. co jeden parametr, to řádek. Ale co když bude parametr obsahovat znak konce řádku? Můžeme přidat číslování, odsazení, obarvit v terminálu pomocí escapovacích sekvencí nebo (ať nevymýšlíme kolo) vypsat v nějakém existujícím formátu (jako je XML), u kterého bude jasné, kde jsou hranice mezi jednotlivými parametry, kde byly konce řádku, jestli byly na konci mezery atd. a výstup nepůjde nabořit tím, že by parametr obsahoval stejné formátování jako používá náš výstupní formátovač
• měl by být modulární tzn. aby bylo možné dopisovat další výstupní moduly – mělo by tam být nějaké rozhraní, aby ten, kdo chce napsat nový výstupní modul, věděl, co má implementovat (jaké metody, s jakými parametry, co má vracet)
• ideálně by měl být modulární i v době běhu, ne jen v době kompilace – tzn. aby šlo přihodit do nějaké cesty nezávisle zkompilovaný modul, program si ho při spuštění načetl a umožnil jeho použití (moduly jsou pojmenované a uživatel vybírá, který modul chce, nastavením proměnné prostředí)

Jedná se o triviální program. Pro ověření tohoto konceptu jsem napsal implementaci v Javě. Nicméně Java se pro systémové příkazy moc nehodí, protože musí nastartovat JVM a vykonání příkazu pak trvá nějakých 150 ms. Je to sice použitelná odezva, ale radši bych to měl napsané v jiném jazyce.

Pokusil jsem se o vytvoření implementace v C++. Provedení příkazu trvá na stejném HW jen 6 ms (nestartuje JVM, program se začne provádět prakticky hned). Ale kód je dost hrozný – nepřehledný, ukecaný. Z velké míry to bude dané tím, že C++ neumím. A v programu asi budou i chyby (i když nějak to funguje a vypisuje to celkem to, co jsem chtěl – jen mi to přijde ošklivě napsané).

Proto bych chtěl požádat zkušenější programátory o vytvoření implementace v C++ s použitím dobrých praktik a moderních možností tohoto jazyka. Případně o přepis v jiném vhodném jazyce (viz očekávané vlastnosti programu výše).

Co mi na C++ přišlo nešikovné:

• třídy, abstraktní třídy a rozhraní
• textové řetězce
• kolekce, seznamy, mapy
• bezpečnost při práci s pamětí (pravděpodobně tam mám nějaké chyby)
• ukazatele, chytré ukazatele – jakkoli je RAII dobrý princip, oproti Javě jsem v C++ musel napsat mnohem víc řádků a bylo to méně přehledné
• nutnost používat další knihovny (v Javě jsem si vystačil s tou standardní, program tedy nemá jinou závislost než Javu)

Moje implementace v Javě a C++ nejsou funkčně 1:1, protože jsem si tam trochu hrál a už jsem to pak nedopisoval, ale jde o ten princip a návrh programu (více výstupních modulů).

Ukázka běhu programu v Javě:

$ cat start.sh 
#!/bin/sh

# syntax highlight:
# ./start.sh | pygmentize -l xml

p1="aaa";
p2="first line
second line
third line";
p3="a & b >> OMG <<";

export PARAMETER_LISTER_OUTPUT="xml";

java -jar dist/parameter-lister.jar "$p1" "$p2" "$p3";


$ ./start.sh 
<parameters>
        <parameter>aaa</parameter>
        <parameter>first line
second line
third line</parameter>
        <parameter>a &amp; b &gt;&gt; OMG &lt;&lt;</parameter>
</parameters>

Ukázka běhu programu v C++:

$ cat start.sh 
#!/bin/sh

# syntax highlight:
# ./start.sh | pygmentize -l xml

p1="aaa";
p2="first line
second line
third line";
p3="a & b >> OMG <<";

export PARAMETER_LISTER_OUTPUT="terminal";

dist/Debug/GNU-Linux/parameter-lister "$p1" "$p2" "$p3";


$ ./start.sh 
terminalOutputModule >>>
dist/Debug/GNU-Linux/parameter-lister: aaa
dist/Debug/GNU-Linux/parameter-lister: first line
second line
third line
dist/Debug/GNU-Linux/parameter-lister: a & b >> OMG <<
<<< terminalOutputModule

(výstup je v terminálu obarvený)

Zdrojové kódy jsou zde:

hg clone https://hg.frantovo.cz/parameter-lister/

P.S. Program a celá tahle myšlenka je staršího data – impulzem ke zveřejnění byla diskuse pod zápiskem Prokleté programování.

       

Komentáře

[wamba]

na to jsem používal Perl one-liners

perl6  -e '@*ARGS.pairs>>.say' "$p1" "$p2" "$p3"

0 => aaa
1 => first line
second line
third line
2 => a & b >> OMG <<

perl6  -e '@*ARGS.perl.say' "$p1" "$p2" "$p3"

["aaa", "first line\nsecond line\nthird line", "a \& b >> OMG <<"]

popř.

perl6 -MJSON::Tiny -e '@*ARGS.&to-json.say' "$p1" "$p2" "$p3"

[ "aaa", "first line\nsecond line\nthird line", "a & b >> OMG <<" ]

atd. Podobně varianty pro Perl 5

perl -MData::Dumper -E 'say Dumper @ARGV' "$p1" "$p2" "$p3"

$VAR1 = 'aaa';
$VAR2 = 'first line
second line
third line';
$VAR3 = 'a & b >> OMG <<';

A spousta dalších možností.

[xkucf03]

Na samotné vypsání parametrů je tohle asi ideální řešení.

Ale mělo to být zároveň programátorské cvičení s cílem naučit se postupy použitelné pro vývoj větších aplikací – definovat si rozhraní, mít několik jeho implementací, umožnit mezi nimi vybírat a předávat data z jedné části programu do jiné.

Např. si představ, že máš editor, ten má nějakou interní reprezentaci dokumentu a pak moduly pro ukládání v různých formátech, které implementují stejné rozhraní. Nebo databázové ovladače pro různé DBMS nebo ovladače pro verzovací systémy (hg, git, svn, bzr, mtn…) a rozhraní, které nad nimi staví jednotnou abstrakci.

[hypvofxy]

Ale mělo to být zároveň programátorské cvičení s cílem naučit se postupy použitelné pro vývoj větších aplikací – definovat si rozhraní, mít několik jeho implementací, umožnit mezi nimi vybírat a předávat data z jedné části programu do jiné.

Ja ti nevim, jestli je na tom vlastne co cvicit (pokud to neni zrovna pri uceni se Javy).

Např. si představ, že máš editor, ten má nějakou interní reprezentaci dokumentu a pak moduly pro ukládání v různých formátech, které implementují stejné rozhraní. Nebo databázové ovladače pro různé DBMS nebo ovladače pro verzovací systémy (hg, git, svn, bzr, mtn…) a rozhraní, které nad nimi staví jednotnou abstrakci.

Plati pravidlo, ze jednotna abstrakce a zobecnovani je zlo. Zrovna uvedene verzovaci systemy se lisi natolik, ze s nimi jinak jednoduse pracovat jednotne. Kdybys potreboval ovladac na jednoduche provedeni commitu, tak by to treba davalo smysl, ale tim to asi konci.

Podobne absurdne by si nekdo mohl rict, ze napise abstraktni ovladatko pro vsechny operacni systemy, nad kterym bude stacit volat metody a takto ovladat jakykoliv pocitac jednotnym zpusobem. Jenze ve vysledku se stejne stane, ze neco bude dostupne jen na jednom OS, takze dalsi implementace se bud budou snazit to (potencialne extremne slozite) reimplementovat, nebo proste zacnou vyhazovat UnsupportedOperationException, cimz vlastne k rozbiti spolecneho rozhrani uplne doslo. (A nebo to v abstraktnim predkovi vubec nebude, ale pretypujes si na konkretni implementaci, ktera to v sobe bude mit schovane, cimz k rozbiti spolecneho rozhrani opet doslo.)

Tu snahu o zobecnovani jsem videl vickrat a vcelku plati, ze to 1) vzdycky vypada uzasne na zacatku, 2) zacne se borit v prubehu, 3) skonci odporne na konci. Nez treba zobecnovat praci se zcela rozdilnymi databazemi (Mongo, MSSQL), tak je lepsi udelat si dve implementace DB klientu (prijde mi jako docela dobre mit jednoho klienta pro kazdou tabulku / kolekci).

[xkucf03]

Plati pravidlo, ze jednotna abstrakce a zobecnovani je zlo.

Odkdy?

Jak jinak bys chtěl řešit požadavek: máme jádro programu + moduly; jádro obstará data; modul tato data převezme, naformátuje a pošle na zadaný výstup; modul může napsat kdokoli, typicky i někdo jiný než autor jádra; modul se dá zapojit do programu i dodatečně (nemusí se kompilovat společně s jádrem) ?

Chceš psát implementace nástrojů jako ls, find, mkdir pro jednotlivé souborové systémy? Nebo radši mít společnou abstrakci a moci používat tentýž program s Ext4, XFS, Btrfs a jakýmkoli jiným FS?

U databází máš JDBC v Javě, ODBC v unixu, PDO v PHP – díky nim můžeš psát kód, který bude pracovat jak s MySQL, tak s PostgreSQL nebo jinou relační databází. Používat proprietární API jednotlivých DBMS by byl krok zpět, znemožnilo by to přenositelnost aplikace. A úplně zbytečně – protože je to všude to samé – odeslat SQL + parametry a zpátky dostat výsledkovou sadu (sady), případně počet změněných záznamů. Díky JDBC jsem např. napsal řádkového databázového klienta SQL-DK, pomocí kterého můžeš jednotným způsobem pracovat s libovolnou relační databází (někdy i nerelační, ve vývoji je LDAP). Nemusíš se učit příkazy a přepínače jednotlivých proprietárních DB klientů, nemusíš si konfigurovat DB spojení na deseti různých místech, můžeš si napsat skripty a nástroje, které abstrahují od použitého DBMS a fungují se všemi.

Společná abstrakce je třeba i HTTP – může ti být jedno, zda je na serveru Apache, Nginx nebo jakýkoli jiný HTTP server – stejně tak serveru je jedno, jestli používáš Firefox, Chromium nebo wget nebo to stahuješ telnetem a píšeš příkazy ručně. Díky společné abstrakci/rozhraní to funguje.

Zrovna uvedene verzovaci systemy se lisi natolik, ze s nimi jinak jednoduse pracovat jednotne. Kdybys potreboval ovladac na jednoduche provedeni commitu, tak by to treba davalo smysl, ale tim to asi konci.

Představ si editor, který ti podbarví řádky, které jsi změnil oproti předchozí verzi. Tohle umí např. Netbeans. A umí to pro SVN, Hg, Git a šla by tam dopsat podpora pro jiné verzovací systémy.

Distribuované VCS jsou dost na jedno brdo. Lidé píší různé GUI nástroje nebo nadstavby pro konkrétní VCS, ale je to často nedokonalé, nedotažené, plýtvá se energií a duplikuje se práce – přitom je to dokola to samé: zobrazit historii, vyhledávat v ní, zobrazit změny oproti poslední verzi, vrátit změny, porovnat dvě verze, přepnout se do větve, označit štítkem, postoupit verzi, odeslat změny do vzdáleného úložiště… A i ty centralizované systémy jako SVN nebo CVS by na to šly napasovat, jen by nepodporovaly všechny funkce, nešlo by např. odeslat změny do vzdáleného úložiště, protože se to udělalo už automaticky při postoupení verze (commit). GUI nástroj v takovém případě jen zobrazí hlášku, že data na serveru už jsou a není co odesílat.

tak je lepsi udelat si dve implementace DB klientu

Čímž vytvoříš tu jednotnou abstrakci – jen sis ji musel napsat sám, je součástí tvé aplikace, musíš ji udržovat a nesdílíš ji s nikým jiným, nemůžeš čerpat z práce ostatních. Těžko ti někdo napíše klienta pro svoji DB, protože ho tvoje aplikace nezajímá → ty si ho budeš muset napsat sám. Jenže když použiješ obecně používanou abstrakci místo své proprietární, tak je dost možné (a např. u JDBC prakticky jisté), že klienta/ovladač už někdo napsal a tobě ušetřil práci.

[hypvofxy]

Aha, to si nerozumime. Tyhle tvoje priklady jsou samozrejme OK. Mel jsem na mysli nasilne snahy o zobecneni. Konkretne treba Elasticsearch umi fulltextove vyhledavani, ale Mongo ne. Nedava smysl snazit se s obojim pracovat stejne, protoze realne se proste nelze rozhodnout, ze zahodis Elasticsearch a prejdes na Mongo. Implementace konkretni DB vrstvy nad Mongem by se mohla snazit chybejici funkcionalitu nejak doplnit rucne, ale za cenu obrovskeho propadu ve vykonu. To je neco, s cim jsem se konkretne setkal, a v kodu to jen komplikovalo dalsi vyvoj (a pritom se to nikdy nepouzilo). Jak by to bylo u JDBC nevim, tady to bylo resene rucne a jsem rad, ze uz se to odstranilo.

[Matlák]

JDBC je pěkná abstrakce. Ale nezapomeň že jsou tu taky ORM vrstvy, které dělají přesně to špatné co říká hypvofxy. Skvěle zobecňují základní CRUD operace s řádky, ale udělat v nich složitější dotaz se subselecty, WITH klauzulemi nebo jinými "nestandardními" vyjadřovacími prostředky SQL je fakt hrůza. A to to vypadalo tak pěkně na začátku...

[BFU]

http://www.dwheeler.com/essays/filenames-in-shell.html

[kozzi]

Tak treba v D to dle me jde napsat velmi slusne a to jsem to jen tak bastlil chvili:

https://github.com/Kozzi11/parameter-listerd/blob/master/source/app.d

[kozzi]

kruci vedle :)

[Dejv]

U některých příkazů je výsledek stejný (echo)

To neni tak docela pravda.

## echo zpracuje 4 parametry, vypise je oddelene mezerami:
$ echo ahoj,    jak    se    máš
ahoj, jak se máš

## 1 parametr
$ echo "ahoj,    jak    se    máš"
ahoj,    jak    se    máš

## Totez, s pouzitim promenne
$ t="ahoj,    jak    se    máš"; echo ${t}
ahoj, jak se máš

$ t="ahoj,    jak    se    máš"; echo "${t}"
ahoj,    jak    se    máš

Podle me tedy parametr, ktery muze obsahovat mezery, patri do uvozovek (nebo apostrofu).

[xkucf03]

Pravda, ani u toho echa to neplatí vždycky – echo neví, kolik mezer tam bylo původně a vloží vždy jednu.

[kralyk z abclinuxu]

Příloha:

• rust.tgz (1403 bytů)

C++ programátorů tady určitě bude víc, tak dávám implementaci v Rustu (navíc to mě víc baví teď ) Napsal jsem to hodně v rychlosti (dnešek mam docela nabitej), takže to ber s rezervou, runtime loadování modulů jsem neimplementoval - v Rustu je zatím pouze low-level/unsafe implementace. V tomhle případě by to šlo celkem snadno (protože to je jednoduchý příklad), ale nemám aktuálně čas to psát... Jinak by to snad mělo fungovat...

K tvé implementaci: V Javě neřešíš error handling u PrintWriteru, což je ale jen taková hnida, je to zrovna záludný případ, kdy tě javovská stdknihovna nenutí řešit chyby...

V C++ je vidět silný javismus IMHO nemá cenu snažit se dát C++ projektu javovskou strukturu, to tam pak máš ty šílený zanořený namespaces apod. To doménové jméno je tam v zásadě k ničemu. Jnak jenom v rychlosti: Ten boost optional vypadá jako zbytečná dependence. Pointery porovnáváme s nullptr pro větší typovou hyperkoretnost V lambdách nemusíš vypisovat všechny použité proměnné, případně můžeš použít for (foo: bar) { ... }. Může také použít using std::vector; pro snažší práci s vectorem et al.

Později se na to podívám podrobněji...

[xkucf03]

tak dávám implementaci v Rustu

Díky, pěkné. Můžu to přidat do https://hg.frantovo.cz/parameter-lister/? (uvedu tě jako autora)

Mohla by to být zajímavý sbírka implementací v různých jazycích.

runtime loadování modulů jsem neimplementoval

Díky tomu odpadly ty továrny + tam nejsou výjimky, takže to má méně řádků, ale je to dobré. Hodně se to blíží té Javě, nejsou tam ty hrůzy jako v C++, ale rychlost je srovnatelná. Trochu rušivé a navíc oproti Javě mi tam přijdou ty &', Box, &*, ale na to se asi dá zvyknout Co se mi líbí je ten trait XMLEscape

V C++ je vidět silný javismus IMHO nemá cenu snažit se dát C++ projektu javovskou strukturu, to tam pak máš ty šílený zanořený namespaces apod.

Vím o tom Tady jsem spíš zkoušel, jestli to jde. Ale obecně mi přijde užitečné, aby každá třída měla globálně jedinečný název.

Ještě by to chtělo pořešit verzování – dneska můžeš použít třeba OSGi, ale tam nedosáhneš toho, aby jeden kód mohl používat více verzí téže třídy, případně si musíš vytvořit vlastní jmennou konvenci (např. MojeTřída1, MojeTřída2 atd.). Bylo by fajn mít tohle podchycené na úrovni jazyka nějak systémově. Pak by nová verze programu mohla snadno podporovat nové i staré API nebo třeba protokol/formát.

Ten boost optional vypadá jako zbytečná dependence.

Co by tedy měla vracet tahle funkce?

boost::optional<string> getenv(const string name) {
	const char * value = ::getenv(name.c_str());
	if (value == 0) {
		return boost::optional<string>();
	} else {
		return boost::optional<string>(value);
	}
}

Chtěl jsem, aby to bylo bezpečné a aby se o správu paměti staraly chytré ukazatele a RAII. Jenže výsledkem byl dost ošklivý kód, mnohem složitější než v Javě.

Může také použít using std::vector; pro snažší práci s vectorem et al.

Vektor tam je (viz vector<string> args). Kam ještě bych ho měl dát?

Pak jsem tam chtěl použít mapu (// TODO: use a map instead of sequence of IFs), ale nakonec jsem se na to vykašlal, přišlo mi to strašně složité (už přesně nevím, přeci jen je to víc než rok, co jsem to psal).

A pak mi tam chybí rozhraní – s tím jsem si nějak nevěděl rady, takže OutputModule není jen rozhraní, ale obsahuje i nějakou základní implementaci.

Co se týče C++ nechci úplně házet flintu do žita, ale musím uznat, že ten Rust vypadá mnohem mnohem líp. Až se vkrádá otázka: „a v čem je háček?“

[wamba]

v Perlu 6 parameter-lister.p6:

use v6;
use lib <.>;
require ::(%*ENV<PARAMETER_LISTER_OUTPUT>) <&output>;

@*ARGS.&output;

jednotlivé moduly (ve stejném adresáři) potom pairs-output.pm6:

use v6;
unit module pairs-output;
sub output is export { @^a.pairs>>.say }

Perl-output.pm6:

use v6;
unit module Perl-output;
sub output is export { @^a.perl.say };

JSON-output.pm6

use v6;
unit module JSON-output;
use JSON::Tiny;

our &output is export = *.&to-json.say;

Výstup následujícího je pak stejný jak v mém komentáři výše

env PARAMETER_LISTER_OUTPUT=pairs-output perl6 parameter-lister.p6  "$p1" "$p2" "$p3"
env PARAMETER_LISTER_OUTPUT=Perl-output  perl6 parameter-lister.p6  "$p1" "$p2" "$p3"
env PARAMETER_LISTER_OUTPUT=JSON-output  perl6 parameter-lister.p6  "$p1" "$p2" "$p3"

[xkucf03]

Díky.

Jako skript, který si člověk napíše sám pro sebe je to dobré, ale jako normální program, který jeden napíše a někdo jiný pouští a ještě do toho cpe vstup z nedůvěryhodných zdrojů, je to dost nebezpečné. Přes proměnnou prostředí tam můžu podvrhnout i něco špatného. Pro tenhle konkrétní účel je to OK, ale mým cílem bylo najít postup, jak psát větší a robustní programy – tímhle stylem bych nemohl psát nic, co běží třeba na serveru a do čeho se posílá vstup třeba z webu.

[kralyk z abclinuxu]

Díky, pěkné. Můžu to přidat do https://hg.frantovo.cz/parameter-lister/? (uvedu tě jako autora)

Jj, klidně.

Díky tomu odpadly ty továrny + tam nejsou výjimky, takže to má méně řádků, ale je to dobré.

No, pro to dynamické loadování mají ty moduly tu statickou proměnnou MOD_NAME, ze které by se vyčetlo jméno, a pak by musela přibýt funkce (v podstatě factory), která by vytvářela boxovanou instanci modulu. Musela by se prohnat přes unsafe rozhraní / raw pointer, ale to je detail, mě se spíš hlavně nechtělo psát funkci pro prohledávání adresáře a matchování nějakých souborů, což by taky bylo potřeba...

Trochu rušivé a navíc oproti Javě mi tam přijdou ty &', Box, &*, ale na to se asi dá zvyknout Co se mi líbí je ten trait XMLEscape

Jo, to jsou lifetimes (což je pro nově přichozí typicky problém v Rustu a já se nedivím) a &* je konverze Stringu na &str, šlo by místo toho použít module_name.as_ref(), což je asi i čitelnější, ale byl jsem línej...

Co by tedy měla vracet tahle funkce?

Takhle, obecně je ten optional (nebo jeho ekvivalenty) fajn věc, spíš mi to přišlo zbytečné v tomhle případě, v tý funkci chooseOutputModule() můžeš IMHO klidně použít céčkovou getenv(), nebude to o nic nebezpečnější...

Jinak taky takhle jak to je by stačilo z té funkce vracet unique_ptr. V případě, že by tam byla hashmapa, by se buď použily shared_ptr, nebo by mapa vlastnila moduly a použily by se jen reference.

Vektor tam je (viz vector<string> args). Kam ještě bych ho měl dát?

Měl jsem na mysli TerminalOutputModule.cpp, kde by se std::vector daly zkrátit na vector, ale to je dost detail...

A pak mi tam chybí rozhraní – s tím jsem si nějak nevěděl rady, takže OutputModule není jen rozhraní, ale obsahuje i nějakou základní implementaci.

Ekvivalentem rozhraní by bylo

class OutputModule {
public:
	virtual int process(ostream &output, string &command, vector<string> &args) = 0;
	// ...
}

Tj. virtuální metoda bez implementace. Od téhle třídy nejde vytvořit instance. Soubor .cpp by odpadl.

Co se týče C++ nechci úplně házet flintu do žita, ale musím uznat, že ten Rust vypadá mnohem mnohem líp. Až se vkrádá otázka: „a v čem je háček?“

Tak Rust má taky svoje problémy. Jazyk je to poměrně složitý. Borrow-checker a lifetimes jsou problém, hlavně pro začátečníka, člověk musí mít rozmyšleno co kam patří. Nemá tradiční OOP model, což může být taky pro někoho problém. FFI není úplně snadné (ale asi snažší než JNI). Výkon taky není vždy ekvivalentní C/C++, v některých případech může pokulhávat. Taky je v ekosystému zvykem dělat staticky linkované binárky (ie. dost velké). (Malé dynamické binárky jsou možné, jen je potřeba si to zařídit tak trochu na vlastní pěst.) Kompilátor je notoricky pomalý a inkrementální kompilace donedávna chyběla, teď je nově v alpha verzi. Časem by měla být dostupná. Podpora v IDE nic moc. A nějaké další mouchy, to jen tak aby nebylo všechno růžové

[xkucf03]

Jj, klidně.

začleněno

Tak Rust má taky svoje problémy. … Taky je v ekosystému zvykem dělat staticky linkované binárky (ie. dost velké)

Vypadla z toho dynamicky liknovaná binárka, ale ta velikost mne trochu zarazila:

$ du target/debug/parameter-lister-rust 
1,1M    target/debug/parameter-lister-rust

$ ldd target/debug/parameter-lister-rust 
        linux-vdso.so.1 =>  (0x00007ffe1f7b8000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffa4d64e000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffa4d42e000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffa4d216000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffa4ce46000)
        /lib64/ld-linux-x86-64.so.2 (0x000055b108814000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffa4cb36000)

$ file target/debug/parameter-lister-rust 
target/debug/parameter-lister-rust: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=67e01212651d60c4017df4fbd4249ced130f366a, not stripped

Oproti tomu ta C++ verze:

$ du c++/parameter-lister/dist/Debug/GNU-Linux/parameter-lister 
240K    c++/parameter-lister/dist/Debug/GNU-Linux/parameter-lister

$ ldd c++/parameter-lister/dist/Debug/GNU-Linux/parameter-lister 
        linux-vdso.so.1 =>  (0x00007ffe8bde0000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f658041e000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6580206000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f657fe36000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f657fb26000)
        /lib64/ld-linux-x86-64.so.2 (0x000056343dfe0000)

$ file c++/parameter-lister/dist/Debug/GNU-Linux/parameter-lister 
c++/parameter-lister/dist/Debug/GNU-Linux/parameter-lister: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=9dabb0d61042100762bf8054286c04fb3be29433, not stripped

A Java (ale to se nedá srovnávat, protože vyžaduje JRE):

$ du java/parameter-lister/dist/parameter-lister.jar 
20K     java/parameter-lister/dist/parameter-lister.jar

BTW: nechce se někomu napsat/upravit tu C++ verzi tak, aby to bylo správně a moderně?

[petr_p]

Na mém systému má libstdc++.so.6 kolem megabajtu. To je právě ten rozdíl mezi rustem a C++. Jinak to, že je binárka dynamická, neznamená, že neobsahuje statické knihovny. Úplně stejně si můžete přilinkovat libstdc++.a do C++ binárky a pak bude situace podobná rustu.

[kralyk z abclinuxu]

Co se týče té velikosti, zhruba polovina je způsobená tím, že to je debug build. S release buildem se dostaneš na nějakých ~600k, což je samozřejmě stále dost. Dynamická binárka to sice je, ale je do ní staticky nalikovaná standardní knihovna Rustu spolu s libjemalloc, libbacktrace a možná dalšíma kravinkama. Tyhle věci se dají povyhazovat, pokud člověk potřebuje, taky se dá použít LTO.

Na C++ mrknu, bude-li čas...

[Grunt]

Jedna technická. Na zápise:

#include <stdio.h>

main (int argc, char *argv[])
{
  int a;

  for (a=0; a < argc; a++)
    printf ("#%d: \"%s\"\n", a, argv[a]);

return 0;
}

je nekorektního co?

[Radovan]

Byl jsi rychlejší, já jsem měl int i;

Odpověď na otázku možná najdeš zde: http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html

[Grunt]

Vim že některé kodeky měly implementaci v Javě, ale nikdy jsem si na to netroufl kliknout. Z prdele se na některou zkusím podívat.

[
  uuid(2573F8F4-CFEE-101A-9A9F-00AA00342820)
  ]
  library LHello
  {
      // bring in the master library
      importlib("actimp.tlb");
      importlib("actexp.tlb");
 
      // bring in my interfaces
      #include "pshlo.idl"
 
      [
      uuid(2573F8F5-CFEE-101A-9A9F-00AA00342820)
      ]
      cotype THello
   {
   interface IHello;
   interface IPersistFile;
   };
  };
 
  [
  exe,
  uuid(2573F890-CFEE-101A-9A9F-00AA00342820)
  ]
  module CHelloLib
  {
 
      // some code related header files
      importheader(<windows.h>);
      importheader(<ole2.h>);
      importheader(<except.hxx>);
      importheader("pshlo.h");
      importheader("shlo.hxx");
      importheader("mycls.hxx");
 
      // needed typelibs
      importlib("actimp.tlb");
      importlib("actexp.tlb");
      importlib("thlo.tlb");
 
      [
      uuid(2573F891-CFEE-101A-9A9F-00AA00342820),
      aggregatable
      ]
      coclass CHello
   {
   cotype THello;
   };
  };
 
 
  #include "ipfix.hxx"
 
  extern HANDLE hEvent;
 
  class CHello : public CHelloBase
  {
  public:
      IPFIX(CLSID_CHello);
 
      CHello(IUnknown *pUnk);
      ~CHello();
 
      HRESULT  __stdcall PrintSz(LPWSTR pwszString);
 
  private:
      static int cObjRef;
  };
 
 
  #include <windows.h>
  #include <ole2.h>
  #include <stdio.h>
  #include <stdlib.h>
  #include "thlo.h"
  #include "pshlo.h"
  #include "shlo.hxx"
  #include "mycls.hxx"
 
  int CHello::cObjRef = 0;
 
  CHello::CHello(IUnknown *pUnk) : CHelloBase(pUnk)
  {
      cObjRef++;
      return;
  }
 
  HRESULT  __stdcall  CHello::PrintSz(LPWSTR pwszString)
  {
      printf("%ws
", pwszString);
      return(ResultFromScode(S_OK));
  }
 
 
  CHello::~CHello(void)
  {
 
  // when the object count goes to zero, stop the server
  cObjRef--;
  if( cObjRef == 0 )
      PulseEvent(hEvent);
 
  return;
  }
 
  #include <windows.h>
  #include <ole2.h>
  #include "pshlo.h"
  #include "shlo.hxx"
  #include "mycls.hxx"
 
  HANDLE hEvent;
 
   int _cdecl main(
  int argc,
  char * argv[]
  ) {
  ULONG ulRef;
  DWORD dwRegistration;
  CHelloCF *pCF = new CHelloCF();
 
  hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
 
  // Initialize the OLE libraries
  CoInitializeEx(NULL, COINIT_MULTITHREADED);
 
  CoRegisterClassObject(CLSID_CHello, pCF, CLSCTX_LOCAL_SERVER,
      REGCLS_MULTIPLEUSE, &dwRegistration);
 
  // wait on an event to stop
  WaitForSingleObject(hEvent, INFINITE);
 
  // revoke and release the class object
  CoRevokeClassObject(dwRegistration);
  ulRef = pCF->Release();
 
  // Tell OLE we are going away.
  CoUninitialize();
 
  return(0); }
 
  extern CLSID CLSID_CHello;
  extern UUID LIBID_CHelloLib;
 
  CLSID CLSID_CHello = { /* 2573F891-CFEE-101A-9A9F-00AA00342820 */
      0x2573F891,
      0xCFEE,
      0x101A,
      { 0x9A, 0x9F, 0x00, 0xAA, 0x00, 0x34, 0x28, 0x20 }
  };
 
  UUID LIBID_CHelloLib = { /* 2573F890-CFEE-101A-9A9F-00AA00342820 */
      0x2573F890,
      0xCFEE,
      0x101A,
      { 0x9A, 0x9F, 0x00, 0xAA, 0x00, 0x34, 0x28, 0x20 }
  };
 
  #include <windows.h>
  #include <ole2.h>
  #include <stdlib.h>
  #include <string.h>
  #include <stdio.h>
  #include "pshlo.h"
  #include "shlo.hxx"
  #include "clsid.h"
 
  int _cdecl main(
  int argc,
  char * argv[]
  ) {
  HRESULT  hRslt;
  IHello        *pHello;
  ULONG  ulCnt;
  IMoniker * pmk;
  WCHAR  wcsT[_MAX_PATH];
  WCHAR  wcsPath[2 * _MAX_PATH];
 
  // get object path
  wcsPath[0] = '\0';
  wcsT[0] = '\0';
  if( argc > 1) {
      mbstowcs(wcsPath, argv[1], strlen(argv[1]) + 1);
      wcsupr(wcsPath);
      }
  else {
      fprintf(stderr, "Object path must be specified\n");
      return(1);
      }
 
  // get print string
  if(argc > 2)
      mbstowcs(wcsT, argv[2], strlen(argv[2]) + 1);
  else
      wcscpy(wcsT, L"Hello World");
 
  printf("Linking to object %ws\n", wcsPath);
  printf("Text String %ws\n", wcsT);
 
  // Initialize the OLE libraries
  hRslt = CoInitializeEx(NULL, COINIT_MULTITHREADED);
 
  if(SUCCEEDED(hRslt)) {
 
 
      hRslt = CreateFileMoniker(wcsPath, &pmk);
      if(SUCCEEDED(hRslt))
   hRslt = BindMoniker(pmk, 0, IID_IHello, (void **)&pHello);
 
      if(SUCCEEDED(hRslt)) {
 
   // print a string out
   pHello->PrintSz(wcsT);
 
   Sleep(2000);
   ulCnt = pHello->Release();
   }
      else
   printf("Failure to connect, status: %lx", hRslt);
 
      // Tell OLE we are going away.
      CoUninitialize();
      }
 
  return(0);
  }

To je bohajeho co? To snad ani nemůže být validní syntaxe a není to nikde na Linuxu. Že sleep(2000); – čistě pro jistotu

[Radovan]

Řekl bych že to je validní syntaxe pro Visual Studio, přesně podle MSDN

  #include <windows.h>
  #include <ole2.h>

Ten sleep je v milisekundách (kompatibilita podle M$), akorát že timer v PC tiká 18.2krát za sekundu, takže to skáče o různá hausnumera a výsledek je velmi přibližný.

[xkucf03]

Viz zápisek – tenhle program je triviální, ale cílem bylo i cvičení – vyzkoušet si postup použitelný pro větší programy, kde ta modulárnost dává smysl nebo je spíš nutností.

Tzn. to, co umím v Javě (napsat jádro programu, definovat rozhraní modulů, napsat jednu dvě implementace modulu, nechat ostatní napsat svoje implementace a připojit je k hotovému jádru) bych rád uměl i v jiných jazycích.

[Grunt]

Javu jsem měl otevřenou několikrát a právě tohle to zaručeně zabilo a vždycky jsem to zavřel (NetBeans mi tu trčí dodnes) – je to šíleně nudné. Jsem zvědav zda-li tohle stádium někdy překonám a taky se neučím psát objektově a modulárně a pro víc lidí než jsem jenom já

bych rád uměl i v jiných jazycích.

Tak ono je i dobré naučit se psát kód odpovídající situaci. Věta „to, co umím v Javě bych rád uměl i v jiných jazycích“ je vyloženě pohrdání krásou ostatních jazyků která předpokládá že všechny jazyky jsou korporátní krámy pouze s jinou syntaxí. Za to by tě ve středověku normálně kamenovali.

[hypvofxy]

V jinych jazycich se jako neda psat modularne, nebo co zas?

[Grunt]

Jak se píše modulárně v Céčku?

[hypvofxy]

Lua? Nacteni nejake binarky a skok na nejakou adresu? A co je DLL injection? A kdo vubec rika, ze to musi byt modularni runtime, ne compile-time?

[Josef Kufner]

V čistém C lze psát modulárně a dokonce i objektově docela snadno. Nemá sice moc dobrou podporu pro polymorfismus (jen union a void*). Příkladem budiž stdio.h, kde fopen() a související funkce mají jako parametr pointer na FILE, což v OOP jazycích není nic jiného než this. A tento přístup se docela běžně v C používá.

[hypvofxy]

O OOP rec nebyla - a zase se nam to tu zvrtne, jako u posledni diskuze... :) - ale jinak +1.

[xkucf03]

Jádro? (Linux, Hurd)

[Kvakor]

V C není modularita problém, sice se to poněkud komplikuje tím, že existuje jen lokální a globální jmenný prostor (tj. proměnná nebo funkce je viditelná buď globálněm, nebo jen ve svém souboru souboru), ale v praxi to většinou zas tak moc nevadí, protože soucasné překladače (C99+) už nemají osmiznakové omezení identifikátoru a stačí rozumně použít unikátní prefixy.

Funkcím, co se mají exportovat, se dají do hlavičových souborů deklarace jako extern, pokud jsou třeba globální proměnné, tak se jednou definují v jednom souboru normálně a v ostatním se také dají extern, zbytek funkcí a globální proměnné viditelné jen v rámci souboru se dají jako static (ale pozor, static u lokální proměnné znamená něco úplně jiného než u globální). Pokud jsou funkce jednoho souboru potřeba v jiném, přidá se příslušný hlavičkový soubor.

Osobně si myslím, že mnohem větší magie je udělat Makefile tak, aby se projekt sestávající z desítek a více souborů správně přeložil včetně závislostí (tj. aby přeložilo se jen to, co je změněné a to, co na změněných částech závisí), tedy pokud se na to nepoužává nějaké IDE nebo automatický udělátor. Nicméně, minimálně s gcc jde generovat závislosti automaticky (jako např. při překladu linuxového jádra), takže stačí jen několik pravidel na libovolné množství souborů.

No a pokud chce někdo plnou dynamickou modularitu, tedy i za chodu programu, tak jsou tu dynamické knihovny (v Linuxu ty s příponou .so) zaváděné přes dlopen(), kterýmj jde například vybrat výkonově náročné rutiny podle aktuálně detekovaného procesoru (stejný zdojový kód, ale přeložený pro různé procesory) nebo třeba implementace systému pluginů, včetně jejich zavádění a uvolňování podle potřeby.

[xkucf03]

Tak ono je i dobré naučit se psát kód odpovídající situaci.

Situace je celkem jednoduchá: Chceme vytvořit systém, který se bude skládat z několika částí. Ty mezi sebou budou komunikovat → je tedy potřeba nějak domluvit rozhraní mezi nimi. A chceme, aby každou část mohl psát jiný programátor nebo i nezávislý tým. Je jedno, v jakém to bude jazyce, dokonce to ani nemusí být v objektovém paradigmatu, stačí, když budou splněny předchozí požadavky.

Dá se to udělat i jako hromada procesů, které spolu komunikují přes sokety nějakým protokolem nebo přes jiné IPC, nicméně tam už na programovacím jazyce nezáleží a každá část může být klidně v jiném (což není vůbec špatný přístup). Ale tady jsem se bavil o trochu jednodušším případě, kdy používáme jeden jazyk, poběží to v jednom procesu a nemusíme specifikovat síťový protokol, ale stačí nám si specifikovat třeba ty abstraktní třídy nebo rozhraní.

[Grunt]

Na druhou stranu je fakt že Microsoftu se podařilo na BASIC naroubovat OLE, COM a udělat z něj multiparadigmatický programovací jazyk, takže bůh ví co všechno jde ještě zmršit.

[kozzi]

Jo jenze ja kolikrat freferuji unix prsitup, proste jeden program dela jednotnej jeden vystup, a jednotlive ostatni vystupy jso samostatne aplikace co tento vystup papkaji a generuji to co je potreba, vyhoda je ze oproti modulum je to mnohem univerzalnejsi a da se to snadneji kombinovat a je to nezavisle na jazyku ;).

[hypvofxy]

To lze v podstate take povazovat za modularitu, jen resenou na trochu jine urovni (v podstate na urovni shellu, kde to nejak spojis rourama).

[xkucf03]

Viz #25 – ale znamená to, že si musíš domluvit nějaký protokol/formát, kterým spolu ty procesy (tzn. vlastně moduly) budou komunikovat. Což bývá (když se to má udělat dobře) pracnější než nadefinovat rozhraní třeba v Javě a napsat několik jeho implementací. Přeci jen musíš parsovat vstup z nějakého proudu bajtů, místo abys dostal několik parametrů/objektů na zlatém podnose při volání metody a následně serializovat výstup do toho formátu a poslat jako bajty dál.

[Kvakor]

Na druhou stranu, když umře plugin-proces, tak jeho rodič, pokud je dobře napsaný, jede vesele dál, ale když umře (nebo se zblázní) plugin, který je součástí "rodiče", tak ho může vzít s sebou. A proti blbému algoritmu nechrání ani inteligentní jazyk (už z principu), takže když se plugin zblázní a začne alokovat kvanta paměti, tak ho v Linuxu nejspíš odpraví OOM killer včetně "rodičovkého" procesu.

[xkucf03]

Souhlas, osobně si myslím, že tohle je celkem dobrá cesta a měla by se používat častěji. Jen si prostě nelze představovat, že to bude jednodušší/rychlejší na vývoj (aspoň ze začátku, než si připravíš nástroje, různé generátory a nacvičíš tenhle způsob práce).

Aplikace (nebo třeba DE) by mohla být složená z několika kooperujících procesů, spojených ať už přes sokety nebo STDIO, které se můžou za chodu dynamicky pouštět a ukončovat, takže aplikace může třeba i uvolnit většinu zdrojů a „uspat se“ – zachovat jen základní funkce.

Takovým příkladem, byť rozděleným jen na dvě části, je XMMS2 (démon + GUI/CLI).

[podlesh]

Souhlas, osobně si myslím, že tohle je celkem dobrá cesta a měla by se používat častěji.

Momentálně je to velmi žhavá móda (klíčové slovo: microservices).

[xkucf03]

Nechtěl jsem sem zatahovat ten módní buzzword. Já v tom vidím pořád ten UNIX, roury, GNU Hurd, démony, sunovské „síť je počítač“…

[johniez]

Zbezne jsem nahlidnul do cpp zdrojaku. Par poznamek:

• using namespace v headeru je lepsi nedelat.
• misto parametru (string value) lepe (const string &value)
• tem referencim, kde se neocekava zmena, je lepsi dat take const. Je pak z hlavicky videt, zda se parametr ve funkci muze zmenit, ci ne. Treba v process() ten vector argumentu se asi nemeni - const &.
• misto shared_ptr<>(new) mozno make_shared(), ac asi az v c++11 teda.
• main obsahuje spoustu nadbytecnych include (jen par se skutecne pouziva).
• colorize() v terminal outputu by sla cela sypat do toho ostreamu, nez pak ty stringy scitat.

[kozzi]

Tak treba v D to dle me jde napsat velmi slusne a to jsem to jen tak bastlil chvili:

https://github.com/Kozzi11/parameter-listerd/blob/master/source/app.d

[jolanda]

pane bože, kdy už si konečně Javisti o C++ něco do prkvančic zjistí, než ho začnou kritizovat?

[xkucf03]

Neber to jako kritiku, spíš jako žádost o pomoc – uvítal bych, kdyby sem někdo napsal, jak to v C++ napsat správně a moderně.

Ano, vícenásobná dědičnost a abstraktní třídy nahrazují rozhraní, takže mít jazykový konstrukt pro rozhraní je zbytečné, ale to nic nemění na tom, že když jsem tyhle třídy psal, přišlo mi to oproti Javě strašně neohrabané a složité.

[xkucf03]

Toto je odpověď na #669 z jiné diskuse, kde je to mimo téma.

---

Jestli máš čas, tak koukni na ten můj zdroják v C++.

Ano, namespaces + adresářová struktura. Je to kravina, to souhlasim, ale nemůžeš se úplně divit, že se nad tim někdo pozastaví, protože to na první pohled každého praští do očí... Navíc v C++ to ani nemá takové opodstatnění jako v Javě (v C++ nemáš, bohužel, moduly/pacakges).

Já se tohle sice naučil v rámci Javy, ale myslím si, že je to dobrý zvyk obecně, v jakémkoli jazyce. Dost trpím, když vidím třeba moduly v NodeJS nebo Pythonu či Perlu, kde se používají jednoslovné názvy, často dost obecná slova… přijde mi to jako hrozný chaos. Oproti tomu v Javě resp. Mavenu je krásný pořádek – groupId odvozené z doménového jména¹ a týmu/projektu, artifactId jako název modulu v rámci daného týmu/projektu a k tomu číslo verze. Dohromady to dává globálně unikátní název identifikující daný kus kódu/binárky. OSGi jde pak ještě o kus dál a donutí tě to provázat na názvy javovských balíčků (package) a nedovolí ti křížit balíčky napříč moduly².

Moderní C++ je relativně ukecané co se memory managementu týče

Taky mi to přijde. A nevím, jestli to, co jsem napsal, je bezpečné³, nebo by to naopak šlo napsat nějak stručněji elegantněji (ale bez surových ukazatelů).

Co jsi měl za problém s mapama?

Už si přesně nepamatuji, ale snažil jsem se tam udělat mapu těch modulů (instance třídy OutputModule), ze které by se vybíralo na základě názvu modulu, ale ten kód mi přišel tak hrozný, že jsem to zatím přepsal jako posloupnost IFů.

Ideálně bych tam chtěl mít něco aspoň na úrovni ServiceLoaderu, kde se moduly dynamicky najdou při startu programu. Tzn. aby pak v praxi stačilo do nějakého adresáře nasypat .so moduly a ty byly po startu programu vidět přes nějaké pěkné API.

_{[1] občas se najde někdo, kdo tuhle konvenci ignoruje, ale to jsou naštěstí spíš jen historické pozůstatky
[2] to jsem nejdřív bral jako nesmyslné omezení, ale pak jsem pochopil, že je dobré to dodržovat i ve standardní (ne-OSGi) Javě, která tě k tomu přímo nenutí
[3] to se na tomhle příkladu moc nepozná, protože program má velice krátký běh, hned skončí a dělá, co má}

[kralyk z abclinuxu]

(fyi: koukám na to, jen jsem ještě nesepsal celý komentář...)

[kralyk z abclinuxu]

Příloha:

• codereview.md (4247 bytů)

Jestli máš čas, tak koukni na ten můj zdroják v C++.

Vzal jsem to jako codereview, přikládam do přílohy

Já se tohle sice naučil v rámci Javy, ale myslím si, že je to dobrý zvyk obecně, v jakémkoli jazyce.

Teoreticky ano, ale prakticky 1) mimo Javu (a jazyky, které mají stejné schéma) budeš nejspíše jediný, kdo to dělá, což taknějak pozbývá smyslu. Navíc bude prostě tvůj kód pro ostatní "divný". IMHO to za to nestojí. 2) ten benefit je IMHO opravdu spíše teoretický. Nevzpomínám se, kdy jsem naposledy, jestli vůbec někdy, narazil na to, že bych chtěl použít v jednom projektu dvě různé knihovny se stejným jménem. A když už by se to stalo, dalo by se to řešit.

Dost trpím, když vidím třeba moduly v NodeJS nebo Pythonu či Perlu, kde se používají jednoslovné názvy, často dost obecná slova… přijde mi to jako hrozný chaos.

To zní spíše jako prostý nezvyk. Opravdu s tím v praxi problémy nejsou. Mně vyhovuje ta stručnost, ale nemám problém ani s tím schématem v Javě / JVM jazycích. Doporučuju prostě neřešit problém, který je stejně nejspíše neexsitující, a prostě použít to, co je v daném jazyku běžné.

Už si přesně nepamatuji, ale snažil jsem se tam udělat mapu těch modulů (instance třídy OutputModule), ze které by se vybíralo na základě názvu modulu, ale ten kód mi přišel tak hrozný, že jsem to zatím přepsal jako posloupnost IFů.

Tady je příklad, jak něco takového provést.

NB: tu mapu tam inicializuju lambdou. Není to jediné možné řešení, dá se nainicializovat přímo v mainu prostě imperativně, případně by šlo tu mapu podědit a napsat si konstruktor, který by dělal všechno potřebné. Výhoda té lambdy je, že je to relativně stručné, ale zároveň to lze použít i pro deklarace mimo funkci. (Což s tou poděděnou třídou jde taky, akorát je potřeba ten podtyp vytvořit.)

Ideálně bych tam chtěl mít něco aspoň na úrovni ServiceLoaderu, kde se moduly dynamicky najdou při startu programu. Tzn. aby pak v praxi stačilo do nějakého adresáře nasypat .so moduly a ty byly po startu programu vidět přes nějaké pěkné API.

Tak v Javě/JVM je tohle jednoduché, protože tam máš bohatý runtime + s sebou vlastní platformu. V C/C++ to je o dost složitější, protože potřebuješ abstrahovat různorodé platformy, navíc téměř jistě existují platformy podporované C/C++, kde tohle třeba ani nejde nebo špatně.

Nicméně pokud cílíš na nějakou konkrétní platformu nebo množinu, dá se něco takového realizovat, akorát si to musíš napsat sám. V POSIXu se typicky používá dlfcn, něco velmi podobného nám funguje na projektu v práci, včetně toho, že to umí moduly reloadovat, když se změní ve filesystému. Qt taky má něco takového. V případě dlfcn je potřeba počítat s tím, že typicky se dají dynamicky načítat pouze extern "C" funkce (protože mangling et al.), takže typicky se to řeší tak, že ten modul exponuje jen jednu nebo několik málo extern "C" funkcí, které vracejí něco, co už se dá použít v C++, případně jim jako argument podstrčíš skrz C API něco, do čeho můžou nějak zaregistrovat libovolný počet typů, funkcí atd.

Takže ano, jde to, ale neexistuje jedno správné předpřipravené řešení.

Jinak ještě k tomu javismu: Kromě těch namespaces se to projevuje IMHO i na použití shared_ptr coby "univerzální" reference a neřešení (im)mutability / const-correctness. Tím tě nechci nějak plísnit, je to dost pochopitelné při přechodu z Javy. Akorát je blbý, že bez nějakého review asi moc nepoznáš, jestli to děláš dobře. Skoro bych možná javistům doporučil to do C++ brát přes Rust, protože tam tě za neřešení vlastnictví a (im)mutability obvykle seřve kompilátor (lidi tomu říkají "fáze boje s borrow-checkerem"). Ale zas je to samozřejmě trochu oklika, zejména pokud tě vyloženě zajímá C++, navíc taky v C++ a Rustu se řada věcí dělá jinak.

[xkucf03]

Dík. V klidu si to projdu, zapracuji a dám vědět…