Byla vydána (𝕏) nová verze 24.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 24.7 je Thriving Tiger. Přehled novinek v příspěvku na fóru.
Binarly REsearch upozorňuje na bezpečnostní problém PKFail (YouTube) v ekosystému UEFI. Stovky modelů zařízení používají pro Secure Boot testovací Platform Key vygenerovaný American Megatrends International (AMI) a jeho privátní část byla při úniku dat prozrazena. Do milionů zařízení (seznam v pdf) po celém světě tak útočníci mohou do Secure Bootu vložit podepsaný malware. Otestovat firmware si lze na stránce pk.fail. Ukázka PoC na Linuxu na Windows na YouTube.
Mobilní operační systém /e/OS (Wikipedie) založený na Androidu / LineageOS, ale bez aplikací a služeb od Googlu, byl vydán ve verzi 2.2 (Mastodon, 𝕏). Přehled novinek na GitLabu. Vypíchnuta je rodičovská kontrola.
Společnost OpenAI představila vyhledávač SearchGPT propojující OpenAI modely umělé inteligence a informace z webů v reálném čase. Zatím jako prototyp pro vybrané uživatele. Zapsat se lze do pořadníku čekatelů.
Distribuce Linux Mint 22 „Wilma“ byla vydána. Je založená na Ubuntu 24.04 LTS, ale s desktopovým prostředím Cinnamon (aktuálně verze 6.2), příp. MATE nebo Xfce, balíkem aplikací XApp, integrací balíčků Flatpak a dalšími změnami. Více v přehledu novinek a poznámkách k vydání.
Příspěvek na blogu Truffle Security: Kdokoli může přistupovat ke smazaným a privátním repozitářům na GitHubu.
Byla vydána nová verze 14 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v cgitu. Vypíchnout lze podporu rozšíření v Lua.
Byla vydána verze 1.80.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Apple oznámil, že v beta verzi spustil své Apple Maps na webu. Podporován je také webový prohlížeč Chrome. Ne však na Linuxu.
Portál Stack Overflow po roce opět vyzpovídal své uživatele, jedná se především o vývojáře softwaru, a zveřejnil detailní výsledky průzkumu. Průzkumu se letos zúčastnilo více než 65 tisíc vývojářů. Z Česka jich bylo 710. Ze Slovenska 246.
když mám v objektu string uložen řtězec např. "4587" jak ho mám převést na číslo int
myslím tim nějakou metodou třídy string ( i = retezec.prevednacislo();
i = atoi(retezec.c_str());
strtol
.
#include <sstream> #include <iostream> #include <string> using namespace std; int main() { string s = "1234"; istringstream is(s); int num; is >> num; cout << "Číslo je " << num << endl; return 0; }
>>
. Takže kdykoli si zavedu novou třídu X
, ať už je to komplexní číslo, matice nebo cokoli jiného, stačí zadefinovat std::istream& operator >>(std::istream&, X&)
a nemusím extra definovat funkci pro konverzi ze stringu. No a kdo chce funkci, může si zadefinovat template void string_to_anything<class X>(const std::string&, X&)
nebo X* anything_from_string<class X>(const std::string&)
.
istringstream
, ale řekl bych, že tyhle vlastnosti by se daly zahrnout klidně do třídy string
, vypadalo by to líp. A nebyl by potřeba konstruktor navíc.
i = int("1234")nebo spíš
int i("1234");abyste to měli se syntaxí C++, kde to ale takhle nejde. A celá ta konstrukce se streamy je jen složitý workaround.
Ja som asi strasny barbar, ked pouzivam:
if(sscanf(a.c_str(),"%d",&x)!=1) printf("neda sa\n");
Stary C-ckar sa vo mne nezaprie :)
Už jsem to napsal dříve/výše. V C++ metoda pro konverzi ze stringu na typ int ve třídě std::string nebo konstruktor pro int(basic_string<char>) neexistují:
int mujInt = mujString.prevedNaInt(); //nenajdem i int("1234"); //taky ne
Proc neexistuje? Vzdyt je to častý způsob konverze! Pokud se na to podíváme z pohledu návrhu, tak IMHO myslim, ze to je velmi konzistetní a obecné řešení - nevkládat konverzní metody. S takovým přístupem bychom mohli rovnou zaimplemetovat např. do std::string i metody pro např. formátování. A to se mi na C++ libí, oddělení odlišných úloh tak, abych mohl v budoucnu použít opravdu jen to, co chci, nechci stavět na něčem, co nepotřebuji. Nepotřebuji konverzní funkce jako
TypRimskaCisla mojeRimskeCislo = mujString.prevedNaRimskeCislo();a nezastavíme se mohli bychom generovat další konverze. Když budu mít následující problém
TypVelkaBrambora mojeVelkaBrambora = mojeBrambora.prevedNaVelkouBramboru();
To jak interpretuju velikost brambory přeci nezáleží na bramboře, ale na mě, to jak interpetuju cigarety, jestli jsou proclené nebo ne, nezáleží na cigaretách, ale na celníkovi nebo na mě, to jak interpretuju pasažera v tramvaji, jestli jede načerno nebo ne, nezáleží na něm, ale na tom, jestli se za přepravu zrovna platí, to jak interpretuju čísla, nezáleží na typu std::string nebo typu int, ale na tom, jak je interpretuje istringstream, a právě istringstream definuje formátování, interpretuje informaci např. jako int pro třídu std::string. Istringstream jen čte řetězce a interpretuje je s použitím formátovacích flagů, manipulátorů, nic víc po ní nechci.
Naopak funkcemi z istringstream bych nechtěl zanášet std::string nebo int.Co chybí v <sstream> je obecná konverzní funkce, něco jako:
template<typename T> inline T prevedDo(const string& st) { T t; istringstream(st)>>t; return t; }Pro typy, pro které jsou přetížené operátory << a >> ve třídě istringstream pak můžu napsat:
int myInt = prevedDo<int>("12345"); double myDouble = prevedDo<double>("13245"); float myFloat = prevedDo<float>("13245");
Jedna z dobrých vlastností v C++ je modularita (tím nějak nechci komentovat jiné jazyky), která se bude ješte prohlubovat. Bohužel díky pozdnímu standardu existuje dosud mnoho FUDu.
Už jsem to napsal dříve/výše. V C++ metoda pro konverzi ze stringu na typ int ve třídě std::string nebo konstruktor pro int(basic_string<char>) neexistují:Samozřejmě, pokud to vezmeme obecně: tyto metody nepatří do třídy string (tedy zdroje, nositele dat bez informace o struktuře), ale do třídy cílové, která umí data zakódovat (a nejen do řetězce). Tedy do třídy int ...
Jedna z dobrých vlastností v C++ je modularita (tím nějak nechci komentovat jiné jazyky), která se bude ješte prohlubovat. Bohužel díky pozdnímu standardu existuje dosud mnoho FUDu.Tento trik s isstringstream je prostě hack. To samozřejmě mnoho lidí obdivuje, některé jazyky na tom stojí. Ale mnoho lidí zase stojí v úžasu nad takovým overheadem u jedné z nejběžnějších operací vůbec. Navíc, i jako obecný princip to není moc užitečné. Protože to předpokládá, že nějaké obecné objekty budou mít jednoznačnou znakovou reprezentaci - a to mít nebudou. Ani u těch čísel to není zcela jednoznačné, můžu chtít ta čísla hexadecimálně, nebo v různé soustavě podle C notace...
Ten overhead ve skutečnosti není zdaleka tak velký, jak to opticky vypadá.
Navíc, i jako obecný princip to není moc užitečné. Protože to předpokládá, že nějaké obecné objekty budou mít jednoznačnou znakovou reprezentaci
On to také obecný princip není. Jde jen o to, že má-li objekt svou textovou reprezentaci (jako třeba int
), je obvykle operace jeho přečtení ze stringu přesně totéž jako jeho přečtení z jiného streamu (soubor, socket, …). A byl by tedy nesmysl implementovat ji dvakrát.
A to je přesně to, co vyřešíte jedním jednoduchým templatem. Pouze se (v rozporu s tradicí) za primární interface považuje ten streamový, protože je obecnější.
do souboru se například bude ukládat binárně
Což je přesně to, co se v dokumentaci k libstdc++ velmi důrazně nedoporučuje, protože to téměř garantuje nepřenositelnost toho datového formátu. Ne že by to nešlo udělat i přenositelně, ale dalo by to podstatně víc práce.
stačí ji mít přístupnou přes dvě rozhraníNevyřeším. Ta šablona totiž obsahuje i implementaci, která nebude optimální. A tím nemyslím jenom to, že se vyrábí wrapper stream. U složitějšího parsování je i rozdíl ve zpracování a rozhodně nebude výjimkou, že se data z toho streamu načtou do řetězce a pak se parsují. Ony ty tradice nemusí být nemyslyA to je přesně to, co vyřešíte jedním jednoduchým templatem. Pouze se (v rozporu s tradicí) za primární interface považuje ten streamový, protože je obecnější.
No, už se trochu dostáváme mimo.
Celá tato diskuse pro mě velmi překvapivá. Jsem ze strany zastánců C++ zvyklý na argumenty vyzdvihující efektivitu výsledného kódu a šetření cyklů procesoru. Že to někdo bere zcela naopak a pojímá C++ spíše jako typovaný LISP, to bych ani ve snu nečekal. Holt - pokrok
Tiskni
Sdílej: