Společnost Hugging Face ve spolupráci se společností Pollen Robotics představila open source robota Reachy Mini (YouTube). Předobjednat lze lite verzi za 299 dolarů a wireless verzi s Raspberry Pi 5 za 449 dolarů.
Dnes v 17:30 bude oficiálně vydána open source počítačová hra DOGWALK vytvořena v 3D softwaru Blender a herním enginu Godot. Release party proběhne na YouTube od 17:00.
McDonald's se spojil se společností Paradox a pracovníky nabírá také pomocí AI řešení s virtuální asistentkou Olivii běžící na webu McHire. Ian Carroll a Sam Curry se na toto AI řešení blíže podívali a opravdu je překvapilo, že se mohli přihlásit pomocí jména 123456 a hesla 123456 a získat přístup k údajům o 64 milionech uchazečů o práci.
Byla vydána (𝕏) červnová aktualizace aneb nová verze 1.102 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.102 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána nová verze 2.4.64 svobodného multiplatformního webového serveru Apache (httpd). Řešeno je mimo jiné 8 bezpečnostních chyb.
Společnost xAI na síti 𝕏 představila Grok 4, tj. novou verzi svého AI LLM modelu Grok.
Ministerstvo vnitra odhalilo závažný kyberincident v IT systému resortu. Systém, do kterého se dostal útočník bez oprávnění, byl odpojen a nedošlo k odcizení dat [𝕏].
Před rokem byla streamovací služba HBO Max přejmenována na Max. Dle managementu slovo HBO v názvu nebylo důležité. Včera byl Max přejmenován zpět na HBO Max. Kolik milionů dolarů to stálo? 😂
Byla vydána nová major verze 8.0.0 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata (Wikipedie). Přehled novinek v oficiálním oznámení a v aktualizované dokumentaci.
Mastodon (Wikipedie) - sociální síť, která není na prodej - byl vydán ve verzi 4.4. Přehled novinek s náhledy a videi v oznámení na blogu.
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: