Příspěvky

16

Vývoj / Re:Použití příkazu GOTO v jazyku C

« kdy: 21. 08. 2019, 09:49:43 »

Nejznámější variantou goto je switch-case. Jinak v C++ je to složitější když v rámci skoku preskakuju inicializaci objektů - není to fakt dobrý nápad a týká se to i switch case. Naštěstí překladač to oznámí. Takže je fakt dobré sahat na goto až je to opravdu nutné

Pokud při skoku opouštím blok kde končí platnost některých proměnných, zavolají se destruktory - takže obyčejný JMP to není.

(Právě kvůli finalizaci mám rád koncept RAII - pak goto nepotřebuju)

17

Desktop / Tip na primitivní windows manager

« kdy: 05. 07. 2019, 22:31:53 »

Zdravím.

Sháním nějaký dobrý tip na velice jednoduchého window managera který bych nasazoval na vncserver. Kdysi jsem používal metacity, ale jeho integrace do unity je už tak velká, že mi občas nefunguje, nebo se chová divně, vypisuje tuny chybových hlášek o nepřístupnosti DBUS a tak dále, prostě to vypadá, na samostatné použití není. Navíc přepínání oken ALT+TAB moc na VNC nefunguje, protože to viewer neodchytí a přepínám okna na lokálním stroji.

Zkoušel jsem evilwm, ale na některých strojích dostávám hlášku o tom, že mu chybí nějaký font a nespustí se.

Nejspolehlivěji funguje twm, akorát ho považuju za vykopávku z dob, kdy jsem unix poprvé viděl někdy kolem roku 2000 na solarisech. Na twm oceňuji prostřední tlačítko myši, které přesune okno do pozadí (takže žádné ALT+TAB)

Takže něco takového, co ideálně stáhnu přes apt, a pak spustím ve stylu DISPLAY=:1 XXXwm &  a získám prostě nějakou kontrolu nad těmi okny.

Dík

18

Vývoj / Re:C++ konverze na const reference

« kdy: 12. 10. 2018, 17:47:35 »

Nepřijde mi, že dělám něco špatně. Zaprvé řeším nějaký problém. A samozřejmě, že bych to mohl napsat zdlouhavě a řešit to třeba v runtime, ale proč? Třeba jsem řešil to, jak používat lambda funkce a benefitovat z toho, že lambda funkce mají vnitřní stav. Ona s tím totiž standardní knihovna moc nepočítá, třeba při práci se std::function mi každá kopie vytváří i kopii vnitřního stavu. Ale s vnitřním stavem se počítá, protože máme přece klíčové slovo mutable.

 Nebo třeba že lambda funkce je vlastně objekt, ale nemá this.

Protože hodně používám různé callbacky a asynchroní volání, které je realizované lambdo, někdy kvůli vnitřnímu stavu musím místo lambdy napsat třídu, a to je zdlouhavé, kód se stěhuje na jiné místo a nepřehledné, není jasné, kudy kód pokračuje v asynchroním zpracování. Je to víc nepřehledné, než pochopit vnitřní stav. Snažil jsem se nějak řešit tento problém. A to proto, že jakkoliv se zeptam na stack overflow, končím pouze u začátečnických dotazů.


Za druhé, ano, neznám všechny zákoutí práce s param packy, protože třeba vím, že konverze lze napsat do kódu pokud funkci volám, ale nevěděl jsem, že to funguje i pokud definuju parametry funkce. Holt se musím učit.

Takže díky za tu diskuzi.

19

Vývoj / Re:C++ konverze na const reference

« kdy: 12. 10. 2018, 14:12:33 »

No já jsem si uvědomil, že je docela problém provést konverzi parameter packu. On ten parameter pack je docela oříšek. Trochu sem si s tím začal hrát tady

http://cpp.sh/26g5x

Příklad skončí kompilační chybou, to je záměr, protože součástí chyby je výsledek. Výsledkem je vygenerování funkce, kde jsou všechny typy vyžadovány s const T &, ačkoliv původní parameter pack to neměl. Je to primitivnější verze. Problém je totiž vlastní konverze a pak použití konvertovaného param paku na vygenerování prototypu funkce. V příkladu se to řeší tak, že se vygeneruje třída, která obdrží konvertovaný parameter pack a v ní je definovaná ta funkce, která se instanciuje v daném prototypu.

Ale že bych tohle někde viděl ve standardní knihovně? Vůbec hledal jsem co všechno se dá dělat s param.pakem a ... nic moc, všichni z toho hned dělají tuple. Jenže nenašel jsem, jak z tuple vyrobit prototyp funkce.

20

Vývoj / Re:C++ konverze na const reference

« kdy: 12. 10. 2018, 11:16:00 »

Šablona s param pakem není řešení. Uvědomuji si že jsem zapomněl zmínit že ta funkce bude nejspíš virtuální (typy argumentů obdrží trida, ve které bude definována)

Ale máš pravdu, mohu se na to vykašlat a nechat to na userovi, když to nedá jako referenci ať se mu to tam kopíruje (ale přijde mi to nefér vůči němu)

21

Vývoj / Re:C++ konverze na const reference

« kdy: 12. 10. 2018, 11:05:04 »

Decay je přesný opak

Dám jiný priklad

Kód: [Vybrat]

template<typename T>
void call(T &&fn)

...
call([=]{...})

Ačkoliv vse je podle učebnic a nejefektivnější perfekt forwarding, přesto dost často vidím funkci call specializovanou tak že se T předává hodnotou, což poznám na dvojnasobnem volání konstruktorů capturovanych hodnot.

Ale možná to je Bug v Gcc. Nemám po ruce reprezentativní priklad momentálně

22

Vývoj / Re:C++ konverze na const reference

« kdy: 12. 10. 2018, 10:46:16 »

Tak jistě, ta funkce ty argumenty bude někam forwardovat a aniž bych chtěl zabihat do podrobnosti, je určena k volání nějakých uživatelských lambda funkci. Už jen to kdy by to forwardovalo argumenty do std::function, kam málokdy člověk napíše const Gadget & jako argument, přestože tam pak lze bindnout funkci která to const v argumentaci ma.

Dalším zadrhelem je, že to chci použít v param packu, takže overload použít nejde. Forward taky použít nejde protože typy je třeba znát dopředu a příklad s funkcí je jen pro zjednodušení, nejspíš to bude třída, která bude mít takovou funkci.

Uživatel může použít T, T&, const T &, T && a mělo by se to předat správně s tím, že T chci během zpracování tahat jako referenci. Nevím jestli funguje const T && &, ale mám pocit že ne, proto ta specializace

23

Vývoj / C++ konverze na const reference

« kdy: 12. 10. 2018, 09:50:17 »

Zdravím.

Stává se mi, že když napíšu něco na blog o programování, odněkud se vyrojí spoustu znalců normy, kteří ji znají zpamětí i po zpátku a hned vědí, co jsem udělal špatně, co řeší lépe std knihovna, se skrytým odkazem "nauč se pořádně normu a standardní knihovnu, než sem něco napíšeš". Upřímě tyto znalce obdivuju, protože mají čas ty stohy dokumentace studovat. A proto je teď moc prosím o pomoc.

Potřebuji toto:

Mám šablonu klasicku

Kód: [Vybrat]

template<typename T> void foo(...). Předpokládá se, že uživatel šablony T explicitně určí, například

Kód: [Vybrat]

foo<int>(...) nebo

Kód: [Vybrat]

foo<int &&>(...)
A nyní hledám v std něco, co mi z T udělá typ vhodný pro předání argumentu. Dle nějakých směrnic se doporučuje aby

• Pouze jednoduché typy předávat hodnotou
• Složite typy lépe předávat const referenci
• Samotné refernece předávat tak jak jsou
• Pointery jakbysmet

Takže bych to viděl že.

Kód: [Vybrat]


T -> const T &
const T & -> const T &
T & -> T &
T && -> T &&
T * -> T *
scalar<T> -> T
Já si tohle dokážu samozřejmě napsat pomocí částečných specializací. Ale nechce se mi věřit, že ve standardní knihovně nic takového není. Ať hledám jak hledám, nic nemůžu najít. Pomůžete mi? Zase nechci vypadat jako někdo, kdo nemá nastudováno.

PS: Forward to není. Forward je funkce, já potřebuju typ.

Dík.

24

Sítě / Re:Implementácia a náročnosť SW bridge

« kdy: 16. 09. 2018, 20:46:41 »

Na 99% se vsadím, že sw bridge funguje přes RAM a je řízena CPU. Už proto, že je tam nějaká logika, například, že některé pakety mohou být určeny tomu SW bridge a není možné je jen hloupě přeposlat

25

Vývoj / Re:Přehlednost syntaxe C++

« kdy: 10. 03. 2018, 17:01:40 »

V C++ se dá psát i přehledně. Zejména pokud člověk vyvíjí knihovny o kterých se předpokládá, že je budou používat jiní, se snažím navrhovat zejména interface tak, aby to bylo vše čitelné. Ale je to jako s UI, čili je to věc názoru, to co jednomu přijde jako přehledné, druhý se v tom nevyzná.

Já mám radši ukecanejší kód, hlavně když je hned vidět, co to dělá.

Knihovna od matematika bude napsaná tak, aby jí rozuměli matematici a nematematik zřejmě bude tápat. Nelze z toho vinit C++. Tenhle jazyk má dost širokou paletu vyjadřovacích nástrojů.

26

Vývoj / Re:C-čko a zápis mimo proměnnou

« kdy: 01. 11. 2017, 15:26:31 »

ve vašem příkladu mutable counteru z jiné diskuze jste musel používat zámky. Kdybyste v tom udělal chybu, tak to překladač narozdíl od Rustu přeloží.

No ono se to jinak implementovat nedá! V žádném jazyce.

(ach ta slepá víra ve své božstvo)

A právě z jiné diskuze se ukázalo, že na jednom místě všichni hlásili chybějící zámek, ale po promyšlení se ukázalo, že tam chybí správně (že je zbytečný). Rust by asi řval (zbytečně)

27

Vývoj / Re:C-čko a zápis mimo proměnnou

« kdy: 01. 11. 2017, 15:21:59 »

Unsafe je v C++ prakticky všechno např.:

Kód: [Vybrat]

*pointer;
pointer += neco; *pointer;
pole[index];
*iterator;
iterator += neco; *iterator;
if (pointer) *pointer; // pointer neni null, ale objekt uz neexistuje
objekt->metoda();


Krása, ale chtěl jsem C++. Ne C.

Aha, takže v C++ se nepřistupuje do pole nebo se nevolají metody objektu? To už je opravdu velká demagogie. Znovu opakuji, v C++ není safe prakticky nic, protože C++ neřeší životnost objektů.

V C++ nejsou pole! V C++ máte std::vector<>! Že můžete v C++ udělat pole je proto, že C++ sebou taha C. Ale při code review pokud někdo někde vytváří pole, tak kód letí na přepsání, pokud to nemá nějaký závažný výkonostní důvod. To se pozná na první pohled

Jak C++ neřeší životnost objektu? C++ má RAII!!! A opět, pokud míníte pointery, tak zase už nejste v C++. C++ má přece std::shared_ptr nebo std::unique_ptr!

Mám ještě demonstrovat že o C++ nevíte vůbec nic?
[/quote]

Garance v Rustu jsou založené na tom, že může být buď libobolný počet imutabilních objektů, nebo pouze jeden objekt mutabilní.

Vím jak fungují imutabilní objekty. Mám na tomhle principu postavenou celou knihovnu.

https://github.com/ondra-novak/imtjson

. Rust nemá žádný runtime overhead navíc a přitom garantuje, že v programu není data race. Zjistí to už během kompilace.

No jasně, stačí jen ověřit imutabilitu. Najít race v systémech, kde se sdílí stav, třeba taková sdílená mapa s nutností do ní zapisovat, to už taková sranda není. A není to věc jazyka.

Jste naivní a zaslepený svou vírou.

28

Vývoj / Re:C-čko a zápis mimo proměnnou

« kdy: 01. 11. 2017, 14:49:14 »

Unsafe je v C++ prakticky všechno např.:

Kód: [Vybrat]

*pointer;
pointer += neco; *pointer;
pole[index];
*iterator;
iterator += neco; *iterator;
if (pointer) *pointer; // pointer neni null, ale objekt uz neexistuje
objekt->metoda();


Krása, ale chtěl jsem C++. Ne C.

Rust navíc dává garanci, že v programu není žádný data race, tohle v C++ zaručit nelze.

Rust si hlavně pomáhá tím, že má všechno imutabilní. Já taky v programech mám většinu věcí imutabulní právě proto, abych co nejméně řešil data races. C++ vám nebrání mít imutabilní objekty. To není vlastnost jazyka. A pokud v runtime automaticky zamyká přístup k neimutabilním objektům, ... tak pak je to o tom výkonu ... rozhodně to nebude žádný modrý přízrak.

29

Vývoj / Re:C-čko a zápis mimo proměnnou

« kdy: 01. 11. 2017, 14:00:32 »

Lámání chleba je co? Nějaká hardcore optimalizace něčeho? To se dělá obvykle v assembleru, nebo pokud bych fakt chtěl, tak je v Rustu unsafe, ale nikdy jsem ale neměl potřebu unsafe přímo použít. C++ je oproti tomu unsafe by default, nelze si vybrat, že teď to chci safe. C++ safe režim jaksi neumí...

Která konkrétní část C++ je unsafe? To že můžete použít věci z C? Že to nemusím uvozovat nějakým klíčovým slovem? Je to problém? Analyzátory C++ kódu existují a umí docela dobře upozornit na unsafe techniky v C++ kódu. To že si něco vynucuje syntaxe je jen syntax sugar.

Co se runtime týče, jakákoliv bezpečí hlídající technika jde proti výkonu. V tomto místě chci mít svobodu, jestli zajištění bezpečnosti nebo výkon.

30

Vývoj / Re:C-čko a zápis mimo proměnnou

« kdy: 01. 11. 2017, 12:50:41 »

Ale mohou se objevit a objevují se. C++ nabízí vyšší míru abstrakce a odstiňuje od low level správy paměti, ale negarantuje navíc vůbec nic. V C++ se dá střelit do nohy stejně snadno jako v C (dokonce k tomu je více příležitostí). C++ nehlídá žádné chyby přístupu do paměti, všechno musí programátor pohlídat ručně. No a lidi dělají chyby. Pokud něco lze zkontrolovat strojově, je to lepší nechat zkontrolovat stojově. Překladač Rustu chybu neudělá, neunaví se, protože dělá na projektu, který je ve skluzu už 10 hodin v kuse a všichni se ho ptají, jakto že to ještě nemá hotové.

No protože to nejsou C++ programátoři. Protože současná generace programátorů umí z C základy a používá k tomu C++ syntaxi a nazývají se C++ programátoři. Spoléhat se, že nějaký stroj udělá code review nejde. Vždycky to bude něco za něco. Jazyky s GC za programátora řeší správu paměti, jejich nevýhodou je, že správu paměti už nemůže dělat programátor a navíc ta správa paměti není 100%. Totéž v Rustu. Něco za Vás Rust hlída, ale zároveň omezuje. A když dojde na lámání chleba, začnu Rust obcházet a vymýšlet prasárny.