Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
std::function<void (EraseResult)> OnEraseDone; std::thread eraseDisc(bool quick, OnEraseDone callback) { std::thread th(std::bind(&Device::_eraseThread, this, callback)); return std::move(th); } void _eraseThread(OnEraseDone callback) { // blabla }Callbacky mi tak hezky fungovaly, ale jen do té doby, než jsem místo obyčejné funkce jako callback chtěl použít pointer na metodu:
// v metodě objektu typu Test std::thread th = eraseDisc(true, OnEraseDone(&Test::eraseDone, this));Kompilátor nahlásí slušnou 100 řádkovou chybu, ze které se zdá, že takový konstruktor std::function nemá a std::bind mi taky nepomůže. Otázkou tedy je, co použít místo std::function (GCC 4.4 ještě neumí lambda funkce, tak ty taky ne, boost knihovnu taky nee), nebo poradit, co dělám špatně.
Řešení dotazu:
std::mem_fn
, Jardiku!
bind
(nějak takhle):
eraseDisc(true, boost::bind(&Objekt::metoda, this));
Skoro jistě (nechce se mi to zjišťovat) je to v C++0x taky (asi se to bude jmenovat std::bind
), najdi si to.
Nebo můžeš bejt frikulín, a jít do lambdy (bez záruky jak na syntax, tak na funkčnost v nějakým kompilátoru):
eraseDisc(true, []{ this->metoda(); } );
Na std::function
je konvertovatelný buď func-pointer, nebo funktor.
Tahleta dnesni mladez ...
std::bind(std::mem_fn(&Test::eraseDone), this)
std::function<void (EraseResult)>
Jo aha, vy tam mate jeste jeden volnej parametr... s vama je teda prace!
#include <functional> #include <string> #include <iostream> struct test { void run(const std::string& message) { std::cout << message << "\n"; } }; int main(int argc, char** argv) { using namespace std::placeholders; test t; std::function<void (const std::string&)> f = std::bind(&test::run, &t, _1); f("Hola hola"); }
(Mate recht, jde to i bez std::mem_fn
, musim se podivat, proc mne to bez nej kdysi neslo...)
std::bind(&Test::eraseDone, this, std::placeholders::_1)
Kompilator musi pripravit kod, kterej za behu rozhodne jestli je metoda virtualni nebo ne, jestli nahodou neni zdedena od virtualniho predka a pod.Nikoliv, kompilátor nic takového dělat nemusí. Ani nemůže, protože za běhu v programu taková informace prostě není (ledaže by si ji tam ten implementátor speciálně kvůli tomuhle přidal, ale v takovém případě je pochybné mluvit o tom jako o opruzu - implementátor si za ten opruz může sám, a to i v případě, kdy chce dodržet nějaké ABI). Pokud jde o ukazatele na metodu, je situace celkem jednoduchá - asi nejjednodušší implementace je dvojice
(pointer na funkci, offset pro this)
s tím, že pro volání virtuální funkce ap. kompilátor vygeneruje kód
Ret synthesized_thunk(T* that, Args... args) { that->real_function(args); }a tuhle funkci použije do toho PMF.
zabira member pointer 6-12B na 32bit platformachTo není vůbec k divení, takových věcí je víc.
Je to jedna z nejtezsich veci pro impementatory C++ kompilatoruImplementoval ten váš expert RTTI? Výjimky? Linker? To jsou všechno věci těžší, anebo pracnější, a zcela určitě jejich datové struktury zabírají víc, než pouhých 12 B.
Ja jsem si z toho vzal ponauceni ze nikdy member pointer pouzivat nebuduUniká mi logika tohohle kroku. I když to nebudete používat, implementovat se to bude pořád stejně (těžce nebo lehce, to je jedno).
ze mi staci trida command s metorou run.... čímž se ochudíte o jakýkoli generický kód, který spolupracuje s funktory. Disclaimer: Tento příspěvek rozhodně nemá vyvolat dojem, že PMF by se měly používat nějak masově. IMHO jsou PMF v C++ jedním z reliktů C (v tomto případě ukazatelů na funkce) a jejich použití přináší např. výkonnostní problémy, na druhou stranu není jednoduché a nepodporuje znovupoužitelnost kódu.
Tiskni
Sdílej: