Byla vydána nová verze 1.12.0 dynamického programovacího jazyka Julia (Wikipedie) určeného zejména pro vědecké výpočty. Přehled novinek v příspěvku na blogu a v poznámkách k vydání. Aktualizována byla také dokumentace.
V Redisu byla nalezena a v upstreamu již opravena kritická zranitelnost CVE-2025-49844 s CVSS 10.0 (RCE, vzdálené spouštění kódu).
Ministr a vicepremiér pro digitalizaci Marian Jurečka dnes oznámil, že přijme rezignaci ředitele Digitální a informační agentury Martina Mesršmída, a to k 23. říjnu 2025. Mesršmíd nabídl svou funkci během minulého víkendu, kdy se DIA potýkala s problémy eDokladů, které některým občanům znepříjemnily využití možnosti prokázat se digitální občankou u volebních komisí při volbách do Poslanecké sněmovny.
Společnost Meta představila OpenZL. Jedná se o open source framework pro kompresi dat s ohledem na jejich formát. Zdrojové kódy jsou k dispozici na GitHubu.
Google postupně zpřístupňuje českým uživatelům Režim AI (AI Mode), tj. nový režim vyhledávání založený na umělé inteligenci. Režim AI nabízí pokročilé uvažování, multimodalitu a možnost prozkoumat jakékoliv téma do hloubky pomocí dodatečných dotazů a užitečných odkazů na weby.
Programovací jazyk Python byl vydán v nové major verzi 3.14.0. Podrobný přehled novinek v aktualizované dokumentaci.
Bylo oznámeno, že Qualcomm kupuje Arduino. Současně byla představena nová deska Arduino UNO Q se dvěma čipy: MPU Qualcomm Dragonwing QRB2210, na kterém může běžet Linux, a MCU STM32U585 a vývojové prostředí Arduino App Lab.
Multiplatformní open source voxelový herní engine Luanti byl vydán ve verzi 5.14.0. Podrobný přehled novinek v changelogu. Původně se jedná o Minecraftem inspirovaný Minetest v říjnu loňského roku přejmenovaný na Luanti.
Byla vydána nová stabilní verze 6.10 (YouTube) multiplatformního frameworku a GUI toolkitu Qt. Podrobný přehled novinek v poznámkách k vydání.
Občas není od věci vyslovit něco, za co se upaluje nebo ukamenovává. Nic není totiž tak jednoduché, aby byla pravda vždy jediná a na první pohled zřejmá.
Jednou z poměrně málo pochopitelných věcí je odpor k STL u programátorů v C++. Někteří pro něj mají pádné důvody, ale u těch ostatních většinou nevím o jediném rozumném argumentu, proč STL nepoužívat.
Prakticky každý program vyžaduje nějaký mechanismus ukládání dat v paměti. Velice záleží na tom, jaká data ukládáme a jak s nimi potřebujeme pracovat. Nelze zapomenout ani na časté dilema "operační versus paměťová složitost". Proto je dobré mít možnost s daty pracovat efektivním, univerzálním a přenositelným způsobem, s výběrem metody, jak se budou data ukládat.
V jazyce C++ máme standardně k dispozici velice silné prostředky k realizaci tohoto cíle. Skrývají se pod zkratkou STL (Standard Template Library, standardní knihovna šablon). STL je běžně součásní standardní knihovny C++ (např. libstdc++
), kromě toho existují i další implementace, např. STLPort. V knihovně jsou obsaženy šablony pro kontejnery a celá řada dalších zajímavých věcí, včetně efektivní implementace řetězců.
Když jsem začínal programovat v C++, právě STL byla věc, která mě naprosto uchvátila. Již předtím jsem znal Java Collections Framework, kde je filosofie trochu podobná, nicméně i vzhledem k různému charakteru jazyků se řada věcí liší. V každém případě jsem se ale do používání STL vrhl po hlavě a postupně přicházel na výhody i nevýhody. Pravda, nevýhod moc není - i když samozřejmě nějaké také jsou.
Vzhledem k výtečným vlastnostem STL by jeho použití mělo být metodou první volby ve všech případech, kdy tomu nebrání závažné důvody. Už pro tu přenositelnost a spolehlivost to stojí za to. Je tu pochopitelně pár situací, kdy STL raději nepoužívat - zde jsou ty hlavní z nich:
Když vynecháme uvedené důvody (a výjimečně ještě nějaké další), obecně není důvod se používání STL bránit. Přesto se všeobecně setkávám s tím, že programátoři toto řešení zavrhují a raději tráví spoustu hodin návrhem, implementací a laděním vlastních kontejnerů. Jiní se zase moří se složitými operacemi na řetězci typu char*
, i když pomocí std::string
by to měli hotové za pár minut.
Doporučuji proto, ať se každý, kdo programuje v C++ a nepoužívá STL, trochu zamyslí nad tím, jaký je hlavní důvod. Případně ať se podívá, co mu tato výtečná knihovna skýtá a jak se používá. Možná přijde na to, že to celé bylo zbytečné a že jediným důvodem nepoužívání byly obavy z neznámého.
Tiskni
Sdílej:
while (*s++ = *t++);
' nebo 'int f(int n) { return n ? n*f(n-1) : 1; }
' a musel jsem z toho vystřízlivět. Když jsem začínal s C++ byl jsem podobně opojen jeho vymoženostmi a byl jsem přesvědčen, že musím za každou cenu overloadovat operátory, používat šablony atd. Z toho prostě člověk musí vyrůst…
potvoro->hejbni_se();tak musím prolézt celkem dost kódu a zkoumat co kde je. Kdežto v C mi to grep poví prakticky rovnou a ctags fungují bezchybně. Další lahůdka je, když se v php předá nějaký objekt coby parametr funkce a chci zjistit co se vlastně předalo. To zas není problém v C++, protože tam je uveden typ. Zase nadruhou stranu, v C++ lze schovat spoustu kódu, který by jinak překážel a znepřehledňoval. Například přetížením operátorů. Ale to není u slušně napsaného kódu v C problém.
To taky, ale spíš jsem měl na mysli třeba to, že se děděním vytvoří nějaká hiearchie tříd. Metody se různě dědí či nedědí, některé jsou virtuální, některé ne... no a pak když chci vědět co se myslí řádkemTo je spise vysledek chaotickeho navrhu knihovny a pouzivani neintuitivnich jmen. A nebo dusledek vaseho podvedomeho odporu k OO programovani obecne.
int pole[] = {4, 4, 4,4 ,4}; std::sort(pole, pole+3); //seradi brambory nebo 4ky nebo streamy:)