Здравствуйте, Codealot, Вы писали:
C> Данные, которые ты получаешь для парсинга — от пользователя. Никаких гарантий по их корректности никакой другой программист за тебя не обеспечит.
Или не от пользователя, а были сериализованы в другом месте самим собой же и их гарантированно никто не портил
Здравствуйте, Codealot, Вы писали:
R>>То есть, любой неудобный вопрос — это обвинение.
C>Только если он высосанный из пальца и хамский.
Как вопрос может быть высосанным из пальца? Это просто вопрос! То, что у тебя подгорело — это только твои проблемы. Вопрос от этого хамским не становится.
C>А, ну-ну. Не забывай про анекдот.
Ага, для прямой угрозы кишка тонковата, походу. Вот только на банальные анекдоты пороху и хватает.
Здравствуйте, Codealot, Вы писали:
C>Уже лучше, что мешало сразу так сделать?
Мне и без этого было хорошо. Это исключиельно по просьбам читателей. Лично мне и без этого все было ясно.
C>Напомню вопрос, который уже тут задавался — как так можно писать на C++, что получается в разы медленнее чем на C#?
Косоруких везде хватает. У тебя вон вообще в 5 раз было медленнее.
--
Re[25]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, Codealot, Вы писали:
R>>Ты путаешь теплое с мягким.
C>memcpy и парсинг — это как раз теплое с мягким.
А кто тебе обещал, что парсиг выполянется только для "внешних" данных? И почему memcpy не может применяться для них же. Да-да, ты именно путаешь теплое с мягким. Очевидно, недостаток базовых знаний (с)
--
Re[28]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rg45, Вы писали:
R>Косоруких везде хватает.
Я-то думал, что плюсовики все охренительно умные, а разработчики стандартных либ — так и вовсе сверхчеловеки
R>У тебя вон вообще в 5 раз было медленнее.
К разработке компилятора C++/CLI я не имею никакого отношения, так что не высасывай из пальца.
Ад пуст, все бесы здесь.
Re[26]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, Codealot, Вы писали:
M>>Или не от пользователя, а были сериализованы в другом месте самим собой же и их гарантированно никто не портил
C>Если производительность имеет значение, то это ярко выраженный говнокод.
Ну если у тебя есть разумная версия, зачем тебе понадобилось переводить числа в строки, а потом обратно, причем не для того, чтобы люди могли их редактировать — рассказывай.
Ад пуст, все бесы здесь.
Re[27]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, Codealot, Вы писали:
M>>Как скажешь
C>Ну если у тебя есть разумная версия, зачем тебе понадобилось переводить числа в строки, а потом обратно, причем не для того, чтобы люди могли их редактировать — рассказывай.
Здравствуйте, rudzuk, Вы писали:
R>Итеририровать кодпоинты. В utf-8 четыре проверки, в utf-16 — одна. Вопрос нормализации выносим за скобки т.к. он существует вне зависимости от кодировки.
R>Я вроде согласился, что как кодировка для сериализации utf-8 удобна, но мы говорим о хранении и обработке строк. При хранении той же кириллицы от utf-8 профита никакого, при хранении китайских иероглифов utf-8 еще и более требовательна к памяти. Единственный выигрыш это латиница.
Вот две одинаковые буквы 'Ё', только одна занимает один кодпоинт, а другая два, какие иероглифы??? Вторая Ё занимает и в UTF-8, и в UTF-16 по 4-ре байта. Символ — не равно кодпоинт.
Ё — 0х0401
Ё — 0х0415 0х0308
Короче моё утверждение: Невозможно ни в какой кодировке работать с Юникод оперируя индексами кодпоинтов как символами. Уже даже в рамках европейских языков существую комбинируемые диакритические знак, префиксы, индексы, зачеркивание и т.д. Так зачем плодить кодировки, если UTF-8 на практике компактнее, да еще и удобнее для передачи и хранения ?!
R>Я о том, что кодпоинты вне BMP это эмоджи и прочее.
Т.е. эможджи нафиг, так ?! Ну так нафига тогда говорить за весь Юникод. Пиши что ты имеешь в виду свою, выдуманную кодировку, где половина информации из любого современного мессенджера будет похерено, не говоря уже о сайтах и текстовых редакторах.
Re[30]: [performance] чего-то я не понимаю в этой жизни
