Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
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:)