Byla vydána nová verze 2.45.0 distribuovaného systému správy verzí Git. Přispělo 96 vývojářů, z toho 38 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání. Vypíchnout lze počáteční podporu repozitářů, ve kterých lze používat SHA-1 i SHA-256.
Před 25 lety, ve čtvrtek 29. dubna 1999, byla spuštěna služba "Úschovna".
Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
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 - pokrokTiskni Sdílej: