Byla vydána Java 27 / JDK 27. Nových vlastností (JEP - JDK Enhancement Proposal) je 9.
Byl vydán Mozilla Firefox 156.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Vestavěný prohlížeč PDF se nyní spouští o 45 % rychleji. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 156 bude brzy k dispozici také na Flathubu a Snapcraftu.
Článek na Raspberry Pi představuje nový vzhled desktopu operačního systému Raspberry Pi OS v aktuálním vydání 2026-09-15.
Nové verze Roundcube Webmailu 1.6.19 a 1.7.4 řeší několik zranitelností.
Na Kickstarteru běží kampaň na podporu hloupého (jenom volání a SMS) tlačítkového DIY telefonu MAKERphone 2.0 od společnosti CircuitMess postaveného na ESP32-S3 a volitelně také s hodinkami MAKERband. S možností psaní vlastních aplikací. S volitelnými HW rozšiřujícími moduly.
Byla vydána nová verze 10.7 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyly balíčky HomeBox a Scrypted.
OpenRGB (GitLab) dospěl do verze 1.0 (YouTube). OpenRGB (dříve OpenAuraSDK) je svobodný multiplatformní software umožňující nastavení podsvícení celé řady různých „herních“ komponent a periferií.
Dnes startuje prodej headsetu Steam Frame. Počínaje dneškem se tedy můžete zapsat na seznam pro jeden z následujících modelů: Steam Frame 256 GB za 1 049 EUR a Steam Frame 1 TB za 1 279 EUR.
Vládní CERT upozorňuje na kritickou zranitelnost v GitLab Community Edition (CE) a Enterprise Edition (EE). Zranitelnost CVE-2026-85706 typu path traversal v Repository Commits API dosahuje skóre CVSS 10.0. Kvůli nedostatečnému omezení cest a chybějícímu vynucení autentizace může za určitých podmínek neautentizovaný útočník číst libovolné soubory ze serveru GitLab, a získat tak přístup k citlivým datům a konfiguraci instance.
Linux může běžet nativně na ESP32-S3 – bez emulace a rovnou s 9,7″ e-paperem.
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)
Děkuju.
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: