Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 209. brněnský sraz, který proběhne tento pátek 16. května od 18:00 ve studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Jelikož se Brno stalo jedním z hlavních míst, kde se vyvíjí open source knihovna OpenSSL, tentokrát se OpenAlt komunita potká s komunitou OpenSSL. V rámci srazu Anton Arapov z OpenSSL
… více »GNOME Foundation má nového výkonného ředitele. Po deseti měsících skončil dočasný výkonný ředitel Richard Littauer. Vedení nadace převzal Steven Deobald.
Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 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.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
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:
