Vývojáři KDE ve spolupráci se společností Slimbook oznámili 16palcový notebook KDE Slimbook VI s předinstalovaným KDE Neon s Plasmou 6. Uvnitř se nachází procesor AMD Ryzen 7 8845HS s integrovanou grafickou kartou Radeon 780M.
Ve Würzburgu dnes začala konference vývojářů a uživatelů desktopového prostředí KDE Akademy 2024. Sledovat lze také online (YouTube, Mastodon, 𝕏, …)
Byla vydána nová major verze 14 svobodného systému pro řízení přístupu k síti (NAC) PacketFence (Wikipedie). Přehled novinek v oznámení o vydání. Pro uživatele předchozích verzí jsou k dispozici poznámky k aktualizaci.
Jak nahrávat zvuk z webového prohlížeče na Linuxu s PipeWire pomocí Nahrávání zvuku (Sound Recorder) a Helvum případně qpwgraph, článek na webu Libre Arts.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.9.
České bezpečnostní instituce, jmenovitě Vojenské zpravodajství (VZ) a Bezpečnostní informační služba (BIS), ve spolupráci s americkou Agenturou pro kybernetickou a infrastrukturní bezpečnost (CISA), Federálním úřadem pro vyšetřování (FBI), Národní bezpečností agenturou (NSA) a dalšími mezinárodními partnery ze Spojeného království, Austrálie, Kanady, Německa, Nizozemska, Estonska, Ukrajiny a Lotyšska vydaly upozornění (
… více »Byla vydána (𝕏) srpnová aktualizace aneb nová verze 1.93 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.93 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Společnost Laravel stojící za stejnojmenným open source PHP frameworkem získala investici 57 milionů dolarů od společnosti Accel. Především na Laravel Cloud.
Byla vydána verze 1.81.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Řešena je také zranitelnost CVE-2024-43402. Vyzkoušet Rust lze například na stránce Rust by Example.
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:
