Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+152
typedef signed int s32;
//...
void SomeStruct::SomeFunc(const char* ipImageName /*, ... */ )
{
// ...
s32 imageNameSize = strlen(ipImageName) * sizeof(char) + 1;
this->mpImageName = new char[imageNameSize];
strcpy(this->mpImageName, ipImageName);
// ...
}А теперь представим, что вместо char будет wchar_t... ...автор - лид-программист...
Запостил: 
Kirinyale,
13 Июня 2010
Follow us!
на счет wchar_t .... хез. я как правило на utf-8 сижу и вайд чарами принципиально не пользуюсь. и даже на виндах... ежели дежурный не-юникод+рашн+дельфи быдлокод, то там даже wchar_t не поможет.
почему? потому что их любит гадкий майкрософт? ох уже фанатики... или потому что он места "многго" занимает? ох уже эти не вышедшие из анабиоза, рам у них 3 килоайбата до сих пор гыгы
ну и как бы из контекста: игра казуальная, имена всех ресурсов известны заранее и могут быть набраны латиницей, смысла от использования вайд чара - нет...
но с другой стороны, опять исходя из условия что игра казуальная и все ресурсы известны заранее, все файлы пакуются (идеальный случай для издателя это 1 экзешник, с всем внутри) и номеруются, смысла использовать имена файлов - нет...
чем это он переносимее? абсолютно такая же портабельность. разве что есть встроенная поддержка легаси-АПИ типа libc... для использования вне libc utf8 не имеет абсолютно никаких преимуществ
ВСЕ символы 1 байтом не представить! Только ASCII подмножество, т.е. ты мудак предлагаешь транслитом писать?
Но, в принципе, на прошлом аналогичном проекте вполне нормально обошлись утф8, так что обойдёмся и здесь. Как минимум, он удобнее тем, что если некоторые данные вдруг оказались в ASCII, их не приходится постоянно конвертить туда-обратно, плюс халявные сторонние библиотеки далеко не всегда работают с wchar_t.
сплешскрины - это отдельный пак, локализация тоже...
то есть имеем 3 пака ( данные, сплешскрины, локализация), экзешник, 1-2 DLLки... это издателю понравится больше чем 100500 мелких файлов...
для запаковки локализаций и сплешей дайте издателю тулзу и небольшой комент как с ней работать... они не тупые, разберутся...
ну и если быть уж совсем крутым, то все паки можно положить в ресурсы экзешника и если нет доп библиотек, то будет 1 экзешник (мы так не делали, но видели игры в которых такое есть)...
и даже не тупые временами тупят... в последний раз они почему-то не сумели нормально обернуть в свой инсталлер тулзу, перепаковывающие ресурсы из сжатого в несжатый пак... пришлось игре перепаковывать их самой на первом запуске, что естественно вылилось в проблемы при дефолтной установке в Program Files и запуске не под админом... вместо нормального решения проблемы потребовали распаковывать все полгектара прямо в All Users под виндовыми документами, итог - хозяин барин, юзеры (те, которые нашли "гостинец") недовольны, разработчикам стыдно, а шо делать)))
мы использовали PopCap и его PopPak. в паке ресурсы не жали, но пользовались всякими трюками для уменьшения размеров png картинок, типа квантизации...
ресурсы жались только для финала (при отладке использовались как есть, т.е. те самые 100500 файлов, зато с возможностью подменять/исправлять на лету)
сжимали банальным разделением PNG или TGA (в основном исходники держали в TGA - грузилось быстрее) на два JPG (картинка+маска), после чего паковали в несжатый зип
printf("%d\n", strlen("привет"));
результат: 12
printf("%d\n", wcslen(L"привет"));
результат: 6
Это несомненный плюс...
одинаково хорошо если рассматривать строку просто как кусок памяти.
а если как некий набор буков, то wchar_t для некитайцев просто прекрасен.
Или вот хочу иметь логический чар 'Ж'. В утф8 не могу такого сделать. А в вайдчарах будет L'Ж'.
а на счет азиатов ты зря... если судить по играм, рыное японии второй по величине после сша, причем рынок сша постоянно сокращается, а китая растет...
Они это тебе припомнят, когда станут хозяивами мира.
по своему опыту скажу, везде где в данный момент нужен 1 символ (особенно с кодом больше 127) через месяц будет нужна строка...
ну и как бы локализация намекает на полное отсутствие строк в нац алфавитах в коде, поэтому в 99% случаев монопенисуально сколько байт занимает 1 символ (1% это функция DrawString)
потому что опыт у тебя с убогим утф8
под виндой это лучшее средство по крайней мере
дотнет а следовательно моно - тоже...
qt вроде тоже не утф8
нутри себя строки в яве и дотнете могут быть чем угодно, никто никогда не узнает как они устроены, так как язык это обернет в свои абстракции...
даже для С++ есть классы которые позволяют работать с utf8 строками, как с utf16/utf32.
c QT не работал, незнаю, спорить не буду...
В дотнете чётко прописано, что строка должна быть в utf16 (http://msdn.microsoft.com/en-us/library/system.string.aspx):
"Each Unicode character in a string is defined by a Unicode scalar value, also called a Unicode code point or the ordinal (numeric) value of the Unicode character. Each code point is encoded using UTF-16 encoding, and the numeric value of each element of the encoding is represented by a Char object. "
насчёт явы не знаю, но большинство реализаций, которые я знаю, используют внутренне utf16.
вот нашёл (http://java.sun.com/javase/technologies/core/basic/intl/faq.jsp):
"The Java programming language is based on the Unicode character set, and several libraries implement the Unicode standard. The primitive data type char in the Java programming language is an unsigned 16-bit integer that can represent a Unicode code point in the range U+0000 to U+FFFF, or the code units of UTF-16. The various types and classes in the Java platform that represent character sequences - char[], implementations of java.lang.CharSequence (such as the String class), and implementations of java.text.CharacterIterator - are UTF-16 sequences."
В дотнете это особеннно важно, потому что можно сделать строку pinned и передать в нативный код сразу указатель на чары без маршаллинга:
fixed(char* cs = &str) { }
без значния внутренней кодировки мы бы так делать не могли
Ыыы. Кстати, это вообще прикол, да. :)
да нифига, если юзать combination marks, то на одну букву может быть и два 32битных вчара... везде одни и те же траблы
если в GCC указать -fshort-wchar, то вайдчары и под линуксом будут 2 байта. правда, стандартные функции типа wcslen/wcscpy не будут работать...
с быдлос++ ни в чём нельзя быть уверенным
в некоторых случаях в реализации строк на С++ не включают шаблонные варианты функций работы со строками, а используют str* (mb_str*) и wcs* функции для char и wchar_t, соответственно... если мы делаем wchar_t 2 байтным, то все функции wcs* отваливаются... об этой проблеме уже писали (хотя для этого случая есть воркараунды)... по моему этой непонятки должно хватить с головой чтоб перестать пользоваться wchar_t...
> по моему этой непонятки должно хватить с головой чтоб перестать пользоваться wchar_t...
это не понятка не вчара, а конкретно gcc
тут вопрос стоит зачем нужен wchar_t? если есть причины по которым он нужен, то использовать std::wstring или нет - дело автора (причина выбора такие же как и при выборе std::string).
А профит в том, что работа со строками становится намного проще, уже не нужно думать о всяких str*, mb_str*, wcs* об утечках памяти, о буферах достаточной длинны и тд, то есть все что ненавидят в С++ шарписты, явисты, пехапешники, и др... да, за удобство придется расплачиваться производительностью, поэтому если она нужна придется велосипедировать, благо С++ никого не принуждает, за что его и любят...
Лол) Если на него(на С++) кто-то садится, то тот его изнасилует пополной.
это да, только что делать, если я не пишу на с++
VB в твоём распоряжении обезьянка.
> спасибо, я не осилил С++
на этом сайте людей осиливших С++ не больше десятка... то что уэбкилл коментит темы по С++ не значит, что он его осилил...
В 1994г выпустили книгу по VB. Там было сказано, что раньше писать под windows было просто нереально сложно, потому что надо было писать тысячи строк кода на сях, и вообще не понятно как люди умудрялись писать программы.
В 2004м вышла книга про C#, где было сказано что без автоматической сборки мусора писать физически нереально, и до появления .NETа писать программы могли только доктора пяти наук
>> спасибо, я не осилил С++
Нет, это звучит так: "шутку понял, но всё равно не смешно".
Подрочить.
Да ничего. Продолжай делать говносайты за $ 15 на PHP, макак ты несчастный
Соси!
Мой полы.
Например, если приложение на MSVC использует один рантайм, подключает библиотеку которая использует другой рантайм, могут возникнуть проблемы из-за разных реализаций. И обычно, stl'ские классы убирают из интерфейсных частей, заменяя их char'ами и т.п..
Данный говнокод выдран из контекста, и сказать плохо то что нет std::string, или хорошо, однозначно нельзя.
возможно ваш лид сталкивался с платформами на которых char больше 1 байта...
Наверное имелось ввиду, больше 8ми бит?
RTFM, в данном случае стандарт C++.
страница, строка?
"The sizeof operator yields the number of bytes in the object representation of its operand."
...
"sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1."
для общего развития, стр 5:
"The fundamental storage unit in the C++ memory model is the byte. A byte is at least large enough to contain any
member of the basic execution character set and is composed of a contiguous sequence of bits, the number of which
is implementation-defined."
Objects declared as characters (char) shall be large enough to store any member of the implementation’s basic character
set.
Впрочем, меньшим говнокодом сабж от всего этого не становится.
слово basic, имхо убирает всю обтекаемость.
"Впрочем, меньшим говнокодом сабж от всего этого не становится."
Я вообще-то ещё не говорил о своей оценке сабажакода. Я указал на ваше говновысказывание, которое может подтолкнуть к высеранию говнокода вами, и тех кто прочёл это ваше высказывание.
Перефразирую: "вернёмся к примеру с wchar_t и заменим для компилируемости strlen/strcpy на соответствующие аналоги".
Человек который будет менять на wchar_t, возьмётся и за strlen, и скорей всего заметит каку.
А вообще wchar_t планируется?
wchar_t пока что вроде не планируется.
байт это семантически единица.
байт может реализовываться любым количеством битов.
в байте может быть 16 бит, но это всё равно будет ОДИН байт.
и код в этом смысле совсем не говнокод, ибо выделяется память на любой платформе будет под нужное количество бит, ибо реализацтия - сколько битов - скрыта...
вообще судя по всему, учитывая что он рядом пишет sizeof(char) и 1, это похоже на ошибку по невнимательности