Open-source trackball Ploopy Adept má novou verzi nazvanou A+. Stále jde o symetrický desktopový trackball s šasi z 3D tiskárny a firmwarem QMK. Novinkami jsou dvojice tlačítek, jimiž půjde také otáčet, a volitelná opěrka ruky. Funkcionalita firmwaru je rozšířena o gesta, vrstvy a možnost konfigurace za běhu. Schémata a kód jsou jako obvykle na GitHubu. A+ půjde předobjednat za 99 CAD (bez dopravy a cla/DPH).
Prusa Research představil nové modely svých 3D tiskáren: Prusa XL+, CORE One+ (Gen 2) a CORE One L+.
Crown je multiplatformní open source herní engine. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT a GPLv3+. Byla vydána nová verze 0.64. Vyzkoušet lze online demo.
NVIDIA na konci ledna vydala v beta verzi nativního linuxového klienta své cloudové herní služby GeForce NOW. Včera oznámila ukončení beta verze a oficiální podporu Linuxu.
Byla vydána nová verze 3.5.0 nástroje pro inkrementální kopírování souborů rsync (Wikipedie). Přehled oprav a vylepšení v souboru NEWS. Řešeno je 33 zranitelností.
Organizace Apache Software Foundation (ASF) vydala verzi 31 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Firma IBM uvedla svůj první mikropočítač Personal Computer před 45 lety, v srpnu 1981. Základní konfigurace modelu 5150 za 1 565 tehdejších dolarů obsahovala desktop s Intel 8088 a 16KB RAM, Color Graphics Adapter a klávesnici. Právě klávesnice Model F/XT vybavené kapacitními spínači, vlivné a s převodníkem dodnes použitelné, připomíná sběratelský web Admiral Shark's Keyboards.
Slovensko odhalilo ruské součástky ve dvou testovaných zařízeních na zjišťování přestupků v silničním provozu a označilo je za bezpečnostní riziko. S odvoláním na vyjádření slovenského Národního bezpečnostního úřadu (NBÚ) to včera oznámil ministr vnitra Matúš Šutaj Eštok. Zároveň ohlásil ukončení spolupráce svého úřadu s dodavatelem části uvedeného systému, slovenskou společností Soitron. Opozice, která na problematické kamery upozornila už dříve, vyzvala k odvolání ministra vnitra.
Dle plánu dnes ve 13:00 proběhne veřejný test eDokladů. Jeho cílem je ověřit připravenost aplikace a související infrastruktury na vysokou souběžnou zátěž před podzimními komunálními volbami.
Byla vydána nová verze 3.47 frameworku Flutter (Wikipedie) pro vývoj mobilních, webových i desktopových aplikací a nová verze 3.13 souvisejícího programovacího jazyka Dart (Wikipedie).
Zdravím,
Měl jsem interface:
class Interface{
public:
virtual int cosi()=0;
...
}
a pak několik implementací:
class A: public Interface{
public:
int cosi();
...
}
class B: public Interface{
public:
B();
~B();
int cosi();
...
}
A dále factory, která mi podle předaných parametrů várátila instanci nějakého konkrétní implementace.
Interface test = factory->choose(parametry);
Takže jsem nevěděl, která konkrétní implementace je použita.
Problém nastal při volání destruktoru.
delete test
způsobil varování na undefined behavior, protože se volal destruktor Interface a ne konkrétní implementace A nebo B a tudíž v případě B to způsobovalo memoryleak.
Jak to vyřešit?
Když přidám protected destructor do Interface:
protected:
virtual ~Interface()=0;
...
inline ReadWrite::~ReadWrite() { }
a destruktory do každé implementace, tak to pořád neřeší problém.
Musím volat destruktor pro konkrétní implementaci a nějak si tudíž musím pamatovat jaká konkrétní implementace je použita, což mi připadá principiálně špatně. Jediná možnost, která mě napadá, je zavolat opět factory se stejnými parametry, aby mi řekla, jaká iplementace byla použita, což se mi taky moc nelíbí. Jak se tohle řeší?
Řešení dotazu:
Když bude public, tak se ale bude volat destruktor ~Interface(), což nechci, protože potřebuju zavolat destruktor konkrétní implemtace - ~B(); v B() něco alokuju, takže to musim uvolnit v ~B() ne v ~Interface(), kterej neví o tom, co se v B() alokovalo.
V tomhle konkrétním případě to můžu udělat tak, že v B() nebudu nic alokoavat a nemusí mít konstruktor ani destruktor - bude jeden prázdnej public destruktor v Interface. Zajímalo by mě to spíš teoreticky...
/** * @class Interface * @brief Interface class.Ne-virtuální destruktor základní třídy při „dědění“ je dost specifická a obvykle nežádoucí věc.
* This class is designed for inheritance. */ class Interface{ public: /** * Virtual empty destructor */ virtual ~Interface(){} /** * cosi do cosi */ virtual int cosi()=0; };
protected:
virtual ~Interface()=0;
...
inline Interface::~Interface() { }
Neopravil jsem to při kopírování z opravdového kódu.
protected:
virtual ~Interface(){};
U tříd, které budou mít destruktor vlastní, se bude volat ten vlastní, u ostatních ten z Interface, nevidím v tom problém.
Mě de o to, že mam Interface* test = new B(); a pak delete test;, jenže to se zavolá ~Interface místo ~B();
Řešim teda jak nějak elegantně volat konkrétní destruktor ~A() nebo ~B() nad Interface* test;
Instacne Interface se vytváří podle paramatrů sama a já nevím jaká. Řešení mě napadaj dvě - při vytváření si do proměnné uložit co to je konkrétně za třídu (A nebo B) a pak zavolat konkrétní destruktor, což mi připadá špatně - k čemu mi pak je ten interface...
Druhá, lepší, je před voláním destruktoru zjistit z facotry, jakej to je typ, ale právě se ptám, jak se tohle běžně řeší, protože mi to připadá jako docela běžný problém, ale nikde jsem to řešené nenašel.
.
komplexnejsie riesenie je v C++ neuvazovat o typu interface, pretoze ich C++ defakto nema- no nemá, ale je jedno jak se tomu říká, jestli jestli čistě abstraktní třída nebo intreface - princip je stejný.
ak sa o triede uvazuje tak, ze sa z nej bude dedit, t.j. prakticky vzdy.Dědičnost je hezká věc, ale jen opravdu tam kde má význam, jinak je lepší se jí raději vyhnout. A myslím si, že je dobré, o každé třídě uvažovat jako by pro dědění nebyla připravena, není-li explicitně uvedeno jinak. Zbytečně zatěžovat kód virtuálními destrukory mi také nepřijde jako nejlepší řešení.
Tiskni
Sdílej: