Dnes startuje prodej headsetu Steam Frame. Počínaje dneškem se tedy můžete zapsat na seznam pro jeden z následujících modelů: Steam Frame 256 GB za 1 049 EUR a Steam Frame 1 TB za 1 279 EUR.
Vládní CERT upozorňuje na kritickou zranitelnost v GitLab Community Edition (CE) a Enterprise Edition (EE). Zranitelnost CVE-2026-85706 typu path traversal v Repository Commits API dosahuje skóre CVSS 10.0. Kvůli nedostatečnému omezení cest a chybějícímu vynucení autentizace může za určitých podmínek neautentizovaný útočník číst libovolné soubory ze serveru GitLab, a získat tak přístup k citlivým datům a konfiguraci instance.
Linux může běžet nativně na ESP32-S3 – bez emulace a rovnou s 9,7″ e-paperem.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 7.0.0. Pro sandboxing se na Linuxu nově používá Landlock místo Bubblewrap. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Správce fotografií Shotwell byl vydán ve verzi 33.0 (GitLab). Hlavní novinkou v tomto vydání po dvou letech je přechod na GTK4.
Na YouTube byly publikovány videozáznamy přednášek a na Flickru fotografie z konference EuroPython 2026.
Byl vydán Debian 13.7, tj. sedmá opravná verze Debianu 13 s kódovým názvem Trixie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Jiří Eischmann se v příspěvku Fiasko jménem W Social na svém blogu věnuje evropské sociální síti W: "W Social je příkladem toho, že se problémy sociální sítí nedají řešit od exekutivního stolu. Když na začátku tohoto roku v Davosu oznámili vznik nové sociální sítě W Social, politici se mohli přetrhnout ve chvalozpěvech. Konečně evropská sociální síť a ještě s ověřením identity. … Jak se ukázalo, když v Davosu W Social oznamovali, neměli kromě
… více »Výrobce hardwarových kryptoměnových peněženek Trezor upozorňuje na bezpečnostní incident u společnosti Brevo, kterou využívá k odesílání newsletterů. Útočník na e-mailové adresy odeslal phishingový e-mail.
Clement "Clem" Lefebvre publikoval souhrn dění v Linux Mintu za srpen 2026. Aplikace XApp mají vlastní webovou stránku xapp-project.org. Představena byl čtečka EPUB s názvem Xepub a kalendář Clockenstein.
C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/cwchar:161: error: `::swprintf' has not been declared C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/cwchar:168: error: `::vswprintf' has not been declared mingw32-make: *** [main.o] Error 1Co se programu týče, háže to na řádku, kde includuju knihovnu iostream. Ví někdo, co to znamená a jak to vyřešit? Budu vděčný za každou pomoc.
Ve windows verzi gcc neni podpora pro siroke znaky, neni to naimplementovane, stalo se me totez, kdyz jsem pouzival prepinac -std=c++98. Kdyz sem ho nahradil -std=gnu++98, tak preklad prosel.
Podpora pro typ wchar_t viz http://www.mingw.org/category/wiki/wchar_t
V rozporu s jakym standardem? Nic neni potreba reimplementovat.
MSVC byl a je prinejmensim slusny kompilator.
Ac linuxak, tak na vareni z vody moc nejsem.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
wchar_t bude šestnáctibitový, tak to je samozřejmě problém.
wchar_t je pod Windows 16bit s kodovanim UTF-16 (WinXP a novejsi)Tak za něco takového by autoři opravdu zasloužili pár facek.
Pod Linuxem je wchar_t 32bit s kodovanim UTF-32.
Spíš bych řekl UCS-4, i když z praktického hlediska to vyjde nastejno.
wchar_t nikdy nebyl zamýšlen jako přenositelný typ, ale zásadně jako typ pro interní práci s textem. Chtějí se od něj v podstatě jen dvě základní vlastnosti: aby umožnil reprezentovat všechny potřebné znaky a aby umožnil kódování s pevnou délkou znaku a tím i jednodušší (interní) zpracování textu. "Unixový" 32-bitový wchar_t obě tyto vlastnosti splňuje velmi dobře, při použití 16-bitového ale už z principu musíte jednu obětovat (to odpovídá výše zmíněné volbě mezi UCS-2 a UTF-16).
Já jsem myslel, že je tu diskuze o programování, takže onou přenositelností jsem myslel psaní přenositelných aplikací, které budou využívat wchar. A to podle mě nejde, protože pod Windows nemáte právě tu jistotu, o které mluvíte.
Pokud nepřenositelností rozumíte to, že to nebude fungovat na překladačích (s knihovnami), které sice implementují funkce definované standardem ISO C99, ale implementují je v rozporu s tímto standardem, pak máte pravdu. Ale to není speciální vlastnost widechar stringů, to potom platí pro jakýkoli prvek jazyka.
V čem je tedy UTF-8 lepší?
Je přímým rozšířením sedmibitové ASCII (může se to hodit např. u webů, jejichž autoři z nějakých důvodů pro informaci o kódování místo hlavičky odpovědi používají berličku v podobě http-equiv meta elementu). Odpadá u něj problém s endianitou, takže není potřeba prznit textové soubory BOM nebo rozlišovat dvě varianty kódování. Je úspornější. Naopak nepřináší oproti UTF-16 žádné nevýhody: zpracováváte-li text v UTF-16, stejně musíte počítat s proměnnou délkou znaku se všemi důsledky (pokud to neděláte jako ta část windowsových programátorů, kteří používají UCS-2 a říkají mu UTF-16).
Pokud mluvíme o ukládání textu ve smyslu uložení na HDD, je i UTF-8 můj favorit, ale já jsem mluvil v kontextu uložení textu v paměti aplikace (RAM) a s takovým textem obvykle pracujeme, ne?
Co se týká zpracování, pak pro jednodušší operace to lze nechat v UTF-8 (převodem do UTF-16 nic nezískáte), pro složitější preferuji typ wchar_t a funkce pro práci s ním tak, jak je definuje ISO C99. Což v podstatě znamená UCS-4 (případně máme-li jistotu, že to bude stačit, lze uvažovat i o UCS-2).
Podstatou celé debaty je ale skutečnost, že pokud autoři MSVC dnes, v roce 2009, pořád ještě nejsou schopni (nebo ochotni) korektně implementovat práci s widechar stringy podle ISO C99, je to trestuhodné. Bohužel v případě MS je takový přístup spíš pravidlem než výjimkou.
Standard vyzaduje platnost: jeden wchar_t = jeden znak
Ktery standard? V C99 to zhruba takhle je, ale takhle to tam nestoji. Necham se presvecit konkretnim prikladem se zduvodnenim.
Veskere funkce z GCC tohle celkem logicky predpokladaji.
GCC je to povetsinou jedno a tam kde neni, tam by se mel drzet v mantinelech standardu. V tom neni problem (jak se to vezme, k tomu nejspis dojdeme).
Co třeba sekce 7.17?
which is an integer type whose range of values can represent distinct codes for all members of the largest extended character set specified among the supported locales; the null character shall have the code value zero.wchar_t
Nebo 7.1.1:
1 … The term multibyte string is sometimes used instead to emphasize special processing given to multibyte characters contained in the string or to avoid confusion with a wide string. …
…
A wide string is a contiguous sequence of wide characters terminated by and including the first null wide character. A pointer to a wide string is a pointer to its initial (lowest addressed) wide character. The length of a wide string is the number of wide characters preceding the null wide character and the value of a wide string is the sequence of code values of the contained wide characters, in order.
wchar_t třeba jako 64-bitový. Ale teorie a praxe se často dost liší… Holt si asi musíme zvyknout, že programátoři na Windows teprve teď se zpožděním nějakých čtyř let prožívají rozšiřování obzorů související s přechodem na 64-bitovou platformu. Snad se jim časem rozšíří natolik, že budou schopni vstřebat i širší široké znaky. :-)
GCC je to povetsinou jedno a tam kde neni, tam by se mel drzet v mantinelech standardu. V tom neni problem (jak se to vezme, k tomu nejspis dojdeme).Coze? Jak ti proboha muze byt u wide retezcu jedno jestli pouzivaji variabilni nebo fixni kodovani?
A wide string is a contiguous sequence of wide characters terminated by and including the first null wide character. A pointer to a wide string is a pointer to its initial (lowest addressed) wide character. The length of a wide string is the number of wide characters preceding the null wide character and the value of a wide string is the sequence of code values of the contained wide characters, in order.Je jedno kterym smerem se na to divas. Budto neplati ze string je sekvence wide characters, nebo neplati to ze delka je jejich pocet. Take porusuje pozadavek na to ze wchar_t ma byt schopen pojmout vsechny znaky vsech locale dostupnych na danem systemu.
wide character
bit representation that fits in an object of type wchar_t, capable of representing any character in the current locale
MSVC je sice hrozny kompilator, ale pokud mas standardni kod, tak to vetsinou sezere.To preto mám v projekte:
#if defined(WIN32)
#define recv(s,b,l,f) recv(s,(char *)b,l,f)
#define setsockopt(s,l,o,v,n) setsockopt(s, l, o,(char *)v, n)
#define getsockopt(s,l,o,v,n) getsockopt(s, l, o,(char *)v, n)
#define strcasecmp _stricmp
#define strncasecmp _strnicmp
#define vsnprintf _vsnprintf
#define snprintf _snprintf
#define assert(b) _ASSERT(b)
#define u_int32_t DWORD
#define u_int16_t WORD
#define u_int64_t unsigned __int64
#define inline __inline
#endif
Ale ano, podpora pro Cecko je na hrozne urovni.
C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../libmingw32.a(main.o):main.c:(.tex t+0x104): undefined reference to `WinMain@16'Ano, mám tam funkci main, a to ve formátu
int main(int argc, char * argv[])Zkoušel jsem i -mwindows přepínač při linkování i překladu (někde jsem to vygooglil) a nic.
Moment on je to ceckovy program nebo c++ zkusil bych mozna prejmenovat main.c na main.cpp ikdyz mozna je to blbost jak od teho vypada makefile?
Toto uz je mimo ale mozna bys upotrebil novejsi verze gcc http://tdragon.net/recentgcc/ Ale zmineny problem to neresi.
Tiskni
Sdílej:
