Společnost Epic Games vydala verzi 5.7 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Intel vydal 30 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20251111 mikrokódů pro své procesory.
Byla vydána říjnová aktualizace aneb nová verze 1.106 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.106 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Canonical pro své zákazníky, předplatitele Ubuntu Pro, prodloužil podporu Ubuntu LTS z 12 let na 15 let (Legacy add-on). Týká se verzí od 14.04 (Trusty Tahr).
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 5.0.0. Nově je oficiálně podporován Linux ARM64/AArch64. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byla vydána verze 10 dnes již multiplatformního open source frameworku .NET (Wikipedie). Přehled novinek v příspěvku na blogu Microsoftu. Další informace v poznámkách k vydání na GitHubu nebo v přednáškách na právě probíhající konferenci .NET Conf 2025.
Rodina hardwaru služby Steam se začátkem roku 2026 rozroste. Steam Deck doplní nový Steam Controller, herní PC Steam Machine se SteamOS s KDE Plasmou a bezdrátový VR headset s vlastními ovladači Steam Frame.
Amazon Web Services (AWS) oznámil (en) výstavbu Fastnetu – strategického transatlantického optického kabelu, který propojí americký stát Maryland s irským hrabstvím Cork a zajistí rychlý a spolehlivý přenos cloudových služeb a AI přes Atlantik. Fastnet je odpovědí na rostoucí poptávku po rychlém a spolehlivém přenosu dat mezi kontinenty. Systém byl navržen s ohledem na rostoucí provoz související s rozvojem umělé inteligence a
… více »Evropská komise zkoumá možnosti, jak přinutit členské státy Evropské unie, aby ze svých telekomunikačních sítí postupně vyloučily čínské dodavatele Huawei a ZTE. Místopředsedkyně EK Henna Virkkunenová chce změnit doporučení nepoužívat rizikové dodavatele při budování mobilních sítí z roku 2020 v právně závazný požadavek.
sudo-rs, tj. sudo a su přepsané do programovacího jazyka Rust, již obsaženo v Ubuntu 25.10, bylo vydáno ve verzi 0.2.10. Opraveny jsou 2 bezpečnostní chyby.
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: