fk0, легенда (28.10.2011 14:13, просмотров: 265) ответил MegaJohn на да, fast тоже приучаюсь юзать. Надо не L"text" а так _T("text") ! Это исходник написан был для AVR, портирую на x86+MSVC+Win. Вот как раз на знаковости и попался я, в этом и есть ошибка- тады индекс улетает за пределы массива
L"text" -- это стандарт ISO. _T("text") это макрос придуманный микрософтом. Он либо в L"text" превращает, либо просто в "text", в зависимости от юникодности. Но это не "язык C" уже. Я тоже такой макрос изобрёл, для embedded. Смысл следующий: при компиляции программы на PC (у меня, правда, под linux) юникодность полноценная и получается L"text". При компиляции под пик-контроллеры (типа AT91SAM7X512 в т.ч.) получается не просто "text" (потому, что исходники всё равно в UTF-8, и не только по-этому), а __wstr("text"), где __wstr -- функция, динамически на-лету преобразующая "text" из UTF-8 в ISO-8859-5 и возвращающая указатель на строку (в ГОСТ-кодировке, выделенную в куче). Зачем ГОСТ. Поясняю. Для PIC-контроллеров делается typedef char wchar_t. ГОСТ позволяет русские и латинские буквы для основных советских республик. И все wsprintf, wcschr и т.п. функции -- просто #define wcschr(x) strchr(x). Вроде есть юникод и вроде работает. Ну а mbstowcs и т.п. пришлось таки написать. Почему ГОСТ, а не windows-cp1251. Потому, что не нужны аж две таблицы перекодировки (из win и в win). Из ГОСТ (он же ISO8859-5) получается UCS2 просто путём прибавления 0x360 и наоборот. Ну а исходники вовсе в UTF-8. И это правильно, потому, что на нормальных платформах тип char * и должен быть закодирован в UTF-8. О переносимости. В таком виде переносимость и на win тоже есть, в cygwin, например. Но win вообще -- это не "кросс-плаформенность". Микрософт всегда клал на все стандарты и делал свой кривой велосипед. В теории у них есть и utf8 и всё такое, да и на практике даже всё работает, но этим никто не пользуется и они специально делают так, чтоб привязать к исходники только к win. Хуже наркотиков и алкоголизма.
[ZX]