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.
Byla vydána (𝕏) nová verze 2025.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
Dánské ministerstvo pro digitální záležitosti má v plánu přejít na Linux a LibreOffice [It's FOSS News].
V úterý Google vydal Android 16. Zdrojové kódy jsou k dispozici na AOSP (Android Open Source Project). Chybí (zatím?) ale zdrojové kódy specifické pro telefony Pixel od Googlu. Projekty jako CalyxOS a GrapheneOS řeší, jak tyto telefony nadále podporovat. Nejistá je podpora budoucích Pixelů. Souvisí to s hrozícím rozdělením Googlu (Google, Chrome, Android)?
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.101 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.101 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
V Brně na FIT VUT probíhá třídenní open source komunitní konference DevConf.CZ 2025. Vstup je zdarma, nutná je ale registrace. Na programu je celá řada zajímavých přednášek, lightning talků, meetupů a workshopů. Přednášky lze sledovat i online na YouTube kanálu konference. Aktuální dění lze sledovat na Matrixu, 𝕏 nebo Mastodonu.
Vyloučení technologií, které by mohly představovat bezpečnostní riziko pro stát, má umožnit zákon o kybernetické bezpečnosti, který včera Senát schválil spolu s novelami navazujících právních předpisů. Norma, kterou nyní dostane k podpisu prezident, počítá rovněž s prověřováním dodavatelů technologií pro stát. Normy mají nabýt účinnosti od třetího měsíce po jejich vyhlášení ve Sbírce zákonů.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.6.
Po Red Hat Enterprise Linuxu a AlmaLinuxu byl v nové stabilní verzi 10.0 vydán také Rocky Linux. Přehled novinek v poznámkách k vydání.
Bylo vydáno Eclipse IDE 2025-06 aneb Eclipse 4.36. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
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: