Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
A i korutiny jdou řešit lépe a v existujících jazycích (OpenMP, Boost Thread, ThreadWeaver, Scheduler/Linux Activations)imho gorutiny maji byt neco jineho nez vlakna a v kombinaci s kanaly to muze byt docela mocne. i kdyz osobne by se mi libilo spis, kdyby zpravy zaslane kanalem definitivne neslo precist, jak to ma udelane treba sing#
Go je typově a paměťově bezpečný jazyk a to se s aritmetikou ukazatelů nedá snadno, tedy spíše v podstatě asi vůbec nijak, skloubit dohromady.Přijatelný kompromis je systém vlastních alokátorů, jak ho např. má C++ nebo Ada.
Go je typově a paměťově bezpečný jazyk a to se s aritmetikou ukazatelů nedá snadno, tedy spíše v podstatě asi vůbec nijak, skloubit dohromady.Jazyky se silnějším typovým systémem by s tím neměly mít problém. Viz třeba ATS.
Třeba tohle? http://yosefk.com/c++fqa/defective.html#defect-7
a to vznikne jednoduchým std::map<std::string, std::string> STL je hodně blbě navržená knihovna a kdykoliv musím s C++ dělat, tak se jí obloukem vyhýbám a využívám raději přímo Clib. (cstdlib, cstdio, c*)
nikoliv - třeba místo komplexních templates mohli naprogramovat opravdový dynamický arrays s měnitelnou délkou a tak mohly být dělaný i stringy - např. jako to dělá jazyk D. Btw, Dčkový string jako array je v benchmarku asi 3x rychlejší než std::string, daleko lépe navržený a mnohem elegantnější co se týče úprav, vyhledávání apod. (např: slicing: string a = "hello world"; string b = a[6 .. $]; /* b je "world" */)
co se týče std::map, D má asociativní arrays: int[string] x = [ "foo":5, "bar":10 ]; x["y"] = 143; který jsou opět efektivnější než std::map a mnohem lépe se s nimi pracuje.
Špatně, std::map není hashtable, ale binary search tree; hashtable v C++ je std::unordered_map, který je ale až součástí TR1.
Co se týče asociativní array v D, tak je to ve skutečnosti opravdu hashtable.
To s map není špatný návrh, to je naopak hodně propracovaný návrh.No, to se přece nevylučuje. A jestli je skutečný typ té StringToStringMapy opravdu takový, jak se v odkazovaném dokumentu píše (což nemám nejmenší chuť zjišťovat), pak je to skvělý příklad toho, jak mizerný může být takový propracovaný návrh.
Nemám nic proti templates ani metaprogrammingu, ale STL a Boost mi přijdou dost "overengineered" a rozvrstvené; asi je to tím, že pracuju hlavně s Cčkem, kde nic takového neexistuje - ale jako správně udělanou mid/high-level standardní knihovnu si představuju něco jako Phobos2 z jazyka D https://github.com/D-Programming-Language/phobos/tree/master/std - umí toho dost (včetně algorithm knihovny pro různý filtrování polí a takové věci) a přitom je srozumitelně a jednodušše naprogramovaná; Co se týče kontejnerů jako vector, map atd, nic takového není třeba, protože jsou podporovány dynamic arrays / hashtables na kterých je možno provádět bez problému slicing, vyhledávání apod a pro filtrování (např. odstraňování elementů, nebo nalezení největšího čísla v array apod) je možné využít algorithm knihovnu (např. template "reduce")
template<typename T> class Something { static void func(void) { T::tady bude asi problém } };
C++ je dobrý jazyk, ale vyžaduje praxi, protože půlka jeho vlastností je určena pro méně než jedno procento dobře navrženého kódu (např. pointerová aritmetika nebo private členové).Nebylo by pak lepsi rozdelit jej na 2 dobre spolupracujici jazyky, a tu pulku umistit do toho nizkourovnoveho? Ale ja to chapu. Podle me C++ melo sve misto v historii jako urcity meziclanek - jazyk na psani komplikovanych aplikaci v dobe, kdy kompilatory byly jeste v plenkach. Mista, kde se opravdu hodi nasadit C++ - slozity program, ktery musi byt zaroven rozumne rychly - dost ubyvaji, namatkou jeste treba herni enginy. (Na druhou stranu, Common Lisp tyto problemy resil taky. I kdyz ta nizka uroven mohla byt v nem trochu lepsi.)
GC v Go přináší stejné výhody, ale i pochopitelně i shodné nevýhody jako v cca každém jiném GC jazyku. Pocit, že na uvolňování paměti lze z hlediska programátora zapomenout, je oprávněný jen z velmi malé části.Ze statistik o tvorbě programů vyplývá něco jiného. GC se zavádí právě kvůli problémům programátorů s uvolňováním paměti.
Nedobře napsaný kód v libovolném GC jazyce generuje pro GC zbytečně mnoho práce (třeba alokace v cyklu, kterou ale přitom lze vytknout před něj). Za to se platí zpomalením/zpomalováním/přerušováním běhu aplikace a zvýšenými nároky na zdroje systému. Dva funkčně shodné programy v GC jazyce se mohou lišit až příliš snadno na škále od perfektně vyhovující aplikace až po program, který pro soustavný trashing není použitelný vůbec k ničemu, tedy pokud nepočítáme účinnou „výrobu“ frustrace jeho nešťastného uživatele.Tohle není věc specifická pro jazyky s GC. Tuhle chybu může udělat i vývojář v jazyku bez GC.
Tiskni Sdílej: