Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 169
тема интересная, спасибо за перевод.
Но я бы посоветовал в дальнейшем читать предложение целиком, а затем по памяти записывать на русском. А то в этом переводе стиль не русский какой-то, что ли. Порядок слов и частей в сложных предложениях более характерен для английского, чем для русского.
Но я бы посоветовал в дальнейшем читать предложение целиком, а затем по памяти записывать на русском. А то в этом переводе стиль не русский какой-то, что ли. Порядок слов и частей в сложных предложениях более характерен для английского, чем для русского.
Это очень мягко сказано. Статья интересная, спасибо, но вот перевод вырвиглазный, прошу прощения. Английский текст надо адаптировать, а не просто переводить, тогда не будет появляться предложений вроде: «Sony (вероятно) не хотели выяснять, какой же беспорядок случится, если уделять безопасности мало внимания, поэтому этот и другие примеры ложной экономии не проходят отбор.».
Другим бы кандидатом мог быть выбор IBM Билла Гейтса, а не Гари Килдалла [Gary Kildall], в качестве поставщика операционной системы для их персонального компьютера. Ущерб от этого решения по-прежнему накапливается с головокружительной скоростью
Одним из элементов этого ущерба сейчас является компьютер в каждом доме :) Зато «идеальный» unix world породил такие брёвна в глазу как NUL-strings, UTF8 и XML.
Одним из элементов этого ущерба сейчас является компьютер в каждом доме :) Зато «идеальный» unix world породил такие брёвна в глазу как NUL-strings, UTF8 и XML.
Вам рассказать про такие чудесные вещи как IE, ActiveX, WinAPI, и т.п. или вы сами догадаетесь?
WinAPI, кстати, очень грамотная штука :) намного грамотнее и современней, чем POSIX. Особенно когда дело касается потоков и синхронизации. Про IE и ActiveX не знаю — ни разу не пришлось ими пользоваться. Наверно потому что хорошо владею API ;)
Интересно, что же тогда в wine/reactos так долго делают реализацию WinAPI, и до сих пор нормально не сделали, если это такая грамотная штука? Тогда как различных слабо связанных с собой клонов Юникса около десятка, плюс несчётное множество библиотек, реализующих какое-то подмножество POSIX.
Интересно, что же тогда в wine/reactos так долго делают реализацию WinAPI, и до сих пор нормально не сделали, если это такая грамотная штука?
По-моему они упёрлись в реализацию недокументированных возможностей WinAPI для полной совместисмости, включая поддержку быдлокода. Либо в DDK закопались. Либо пока делали не смогли сделать быстрее чем MS :) а релизить то же самое, но медленное смысла нет.
Тогда как различных слабо связанных с собой клонов Юникса около десятка, плюс несчётное множество библиотек, реализующих какое-то подмножество POSIX.
Слабо связанных клонов юникса не бывает. Начиная от bash'ей с /usr/bin'ам и заканчивая устройством ядра с одним и тем же набором файловых систем. Весь зоопарк юниксов — это разновидность обвеса +-трёх различных ядер. И даже при всём при этом без тысячи #ifdef'ов со стокилобайтными ./configre тру кроссплатформенности не добьёшься.
По-моему они упёрлись в реализацию недокументированных возможностей WinAPI для полной совместисмости, включая поддержку быдлокода. Либо в DDK закопались. Либо пока делали не смогли сделать быстрее чем MS :) а релизить то же самое, но медленное смысла нет.
Тогда как различных слабо связанных с собой клонов Юникса около десятка, плюс несчётное множество библиотек, реализующих какое-то подмножество POSIX.
Слабо связанных клонов юникса не бывает. Начиная от bash'ей с /usr/bin'ам и заканчивая устройством ядра с одним и тем же набором файловых систем. Весь зоопарк юниксов — это разновидность обвеса +-трёх различных ядер. И даже при всём при этом без тысячи #ifdef'ов со стокилобайтными ./configre тру кроссплатформенности не добьёшься.
Если грамотность измерять количеством передаваемых функциям параметров.
То получится POSIX, где нет ни CreateWindow, ни BitBlt.
Если же грамотность измерять фундаментальной функциональностью, то получится WinAPI, где можно в один WaitForMultipleObjects засунуть логический event с сокетным.
То получится POSIX, где нет ни CreateWindow, ни BitBlt.
Если же грамотность измерять фундаментальной функциональностью, то получится WinAPI, где можно в один WaitForMultipleObjects засунуть логический event с сокетным.
Я в курсе про графический интерфейс. Поэтому и упомянул с иронией о кол-ве аргументов в CreateWindow/BitBlt, т.к. среди базовых файловых/потоковых функций такого кол-ва параметров не наблюдается.
И меня в первую очередь инетерсует не количество функций и аргументов, а что API в принципе может делать.
Серьёзнейшие минусы POSIX'а касаемо потоков:
1. нельзя одновременно ждать condition_variable и события на сокете (приём/отправка), приходится применять polling.
2. нельзя проверить, завершился ли поток или ождать это событие лишь какое-то время. pthread_join работает как Wait(INFINITE). Опять же приходится изворачиваться на condvar'ах, выставляемых в конце функции потока.
3. самое главное — condvar'ы провоцируют проверку условия в user mode, что вызывает кучу spurious wakeups — проснулись, проверили что еще не время бежать дальше, заснули дальше. Особенно этот overhead доставляет с broadcast'ом.
4. нет толковой межпроцессной синхронизации, только flock()
И меня в первую очередь инетерсует не количество функций и аргументов, а что API в принципе может делать.
Серьёзнейшие минусы POSIX'а касаемо потоков:
1. нельзя одновременно ждать condition_variable и события на сокете (приём/отправка), приходится применять polling.
2. нельзя проверить, завершился ли поток или ождать это событие лишь какое-то время. pthread_join работает как Wait(INFINITE). Опять же приходится изворачиваться на condvar'ах, выставляемых в конце функции потока.
3. самое главное — condvar'ы провоцируют проверку условия в user mode, что вызывает кучу spurious wakeups — проснулись, проверили что еще не время бежать дальше, заснули дальше. Особенно этот overhead доставляет с broadcast'ом.
4. нет толковой межпроцессной синхронизации, только flock()
В MS есть разные отделения. Те, кто делают интернеты с офисам и DCOM'ами — согласен, стрёмные ребята. В отличие от тех, кто делают ядро операционки, компилятор и WinAPI.
А «„идеальный“ unix world», значит, состоит из одной команды, да?
А я и не сравниваю весь MS со всем unix. Речь про WinAPI vs. POSIX, про UTF8 vs. UCS2 и про length+chars vs. NUL-terminated. Хотя можно и MS Office с OpenOffice/LibreOffice сравить на больших документах :) единственное где юниксы оторвались — это opensource браузеры. И опять же благодаря тому, что начали их под винду делать.
офис тоже ниче так. свои задачи решает
COM, DCOM, COM+ — очень неплохие решения, кстати, учитывая требования к ним. Большего удалось достичь, только создав .NET.
Microsoft purchased all rights to 86-DOS in July 1981, and «IBM Personal Computer DOS 1.0» was ready for the introduction of the IBM PC in October 1981.
IBM subjected the operating system to an extensive quality-assurance program, reportedly found well over 300 bugs, and decided to rewrite the programs.
This is why PC-DOS is copyrighted by both IBM and Microsoft.
IBM subjected the operating system to an extensive quality-assurance program, reportedly found well over 300 bugs, and decided to rewrite the programs.
This is why PC-DOS is copyrighted by both IBM and Microsoft.
Бля, опять холивары! Гейтс — бог, минусуйте, черти! )
Переменной длиной символа в байтах. А предпочли его UCS2/UCS4 по причине всё тех же NUL-strings.
Стандартом UTF8 оказался, т.к. это было решение меньшей крови чтобы древний софт с PDP терминалов смог и дальше показывать английский язык без изменений и не ломать зубы о NUL chars. В мире unix'ов совместимость с ламповыми коамьютерами — священный грааль. В частности, именно поэтому мы до сих пор гоняем email в base64 дабы в 7 бит уложиться.
XML слишком избыточен, как минимум из-за закрывающих тегов. Это уже в сравнении с JSON видно. И не даёт возможности O(log(N)) поиска, т.к. неизвестно заранее где заканчивается ветка. XML надо парзить. В отличие от аналогичных бинарных структур.
XML слишком избыточен, как минимум из-за закрывающих тегов. Это уже в сравнении с JSON видно. И не даёт возможности O(log(N)) поиска, т.к. неизвестно заранее где заканчивается ветка. XML надо парзить. В отличие от аналогичных бинарных структур.
Любой человекочитаемый язык разметки надо парсить. Но мне лично ближе YAML, чем XML.
Про существование xsd вы видимо не в курсе. Как и про binary xml.
А еще мне интересно как бы вы поправили руками бинарник.
А еще мне интересно как бы вы поправили руками бинарник.
Дык с binary xml и надо было начинать, не выпуская просто xml за рамки текстовых редакторов. (Де)компиляция это называется.
> А еще мне интересно как бы вы поправили руками бинарник.
А зачем его руками править? JPEG'и вроде не руками правят.
> А еще мне интересно как бы вы поправили руками бинарник.
А зачем его руками править? JPEG'и вроде не руками правят.
Потому что xml`ем удобно описывать конфиги и вообще всякие данные и их схемы. Отсюда — необходимость читать глазами и править руками.
И, да, отвечу в этом же комменте — xml значительно активней используется в винде и в разработке под нее. Под юниксами его почти нет, там ворох разных форматов.
И, да, отвечу в этом же комменте — xml значительно активней используется в винде и в разработке под нее. Под юниксами его почти нет, там ворох разных форматов.
Для конфигов XML приемлем, хоть и не очень удобен. Я говорил про межпроцессное и сетевое взаимодействие, куда человек если и лезет, то только в целях отладки.
xml пришёл из html. по крайней мере его неприятная текстовая сторона.
xml пришёл из html. по крайней мере его неприятная текстовая сторона.
А xml изначально и не предназначался для межпроцессного и сетевого взаимодействия. Он в первую очередь язык разметки.
На майкрософтовской платформе сейчас гоняется mtom, binary xml и так далее.
На майкрософтовской платформе сейчас гоняется mtom, binary xml и так далее.
Наоборот, HTML «пришёл» из XML, так как является его диалектом.
За конфиги в XML-е надо выгонять из профессии.
«А давайте приделаем программе тормозов просто так».
«А давайте приделаем программе тормозов просто так».
Вы сейчас радостно опустили весь энтерпрайз и огромное количество профессиональных энтерпрайзных решений ;)
«За конфиги в XML-е надо выгонять из профессии.»
Угу. MS, Oracle, hibernate и далее по тексту.
Угу. MS, Oracle, hibernate и далее по тексту.
А чем вам это мешает?
Невозможностью найти 1005й или средний символ (по длине в символах, а не по длине в байтах) за O(1). И потребностью вешать логику с битовыми масками для перехода к следующему символу, который может занимать от 1 до 4 байт в зависимости от значения первого байта символа.
Про UTF16 и UTF32 вы тоже не в курсе?
В курсе, но я говорил про UTF8, а не про весь utf8. К тому же, UTF32 = UCS4 — я за них. UTF16 страдает той же разнобайтовостью, что и UTF8 (только там это суррогатными парами называется). А UCS2 — это UTF16, но без суррогатных пар, т.е. с неполной кодовой таблицей, всего 65536 позиций. Хотя если бы проектировщики unicode подошли к иероглифам с правильной стороны, считая иероглиф не символов, а словом, состоящим из чёрточек-символов, то 65536 позиций вполне бы хватило.
Операция нахождения 1005-ого символа или среднего именно для строк не характерна. Может давайте тогда по килобайту сразу закладывать на каждый символ — вдруг захочется long число туда засунуть. Или как в лиспе — держать указатель на каждый символ: там как раз от этого во внутреннем представлении стали отходить — а вы тут их р-р-раз, и перегоните.
Скорее в UCS2, а не в UTF32(UCS4). Проблема в том, что utf8 так же часто назвязывается как средство обработки.
От ситуации зависит. Если будет нужен весь набор символов, хранение будет в utf8(.gz), обработка в utf32. Если достаточно UCS2, то и хранение, и обработка будет в нём. По поводу востребованности UCS4 и почему не хватило UCS2 я свои доводы приводил здесь: habrahabr.ru/blogs/programming/126566/?reply_to=4177062#comment_4171396
Зачем в 2 раза увеличивать объем файла и ломать обратную совместимость, если этого можно не делать без какого-либо ущерба — непонятно.
Ущерб есть в необходимости обработки процессором каждого байта. Когда файловое содержимое соответствует рабочему представлению в памяти, работают DMA каналы и file mapping'и. Когда требуется битовая логика c if/else — они не работают. Согласен, что для строк не особо критично, но примыленный к скорости глаз это корёжит :)
Зачем доказывать, что в интернете кто-то неправ :)?
А забавно бывает позырить на реакцию :) особенно на контр-доводы, которые обычно взывают не к практическому удобству бывалого системного программиста, а к теоретической идейности и обобщённым сферическим понятиям, к которым человек еще и не сам пришёл, а где-то прочитал/услышал.
Ущерб есть в необходимости обработки процессором каждого байта. Когда файловое содержимое соответствует рабочему представлению в памяти, работают DMA каналы и file mapping'и. Когда требуется битовая логика c if/else — они не работают. Согласен, что для строк не особо критично, но примыленный к скорости глаз это корёжит :)
Зачем доказывать, что в интернете кто-то неправ :)?
А забавно бывает позырить на реакцию :) особенно на контр-доводы, которые обычно взывают не к практическому удобству бывалого системного программиста, а к теоретической идейности и обобщённым сферическим понятиям, к которым человек еще и не сам пришёл, а где-то прочитал/услышал.
А мне понравилось "… основанное на отказе Килдала не принимать требования IBM о неразглашении". Вот и думай, что это значит %)
ЦПУ…
Топорно получилось :(. Спасибо всем в этой ветке! Будем совершенствоваться :).
NUL-terminated string имеет ещё одну очень важную особенность: это универсальный формат, совместимый с сетью. Если бы у нас строки передавались как (int)(array), то вы представляете себе, сколько бы было пролито слёз по поводу того, СКОЛЬКО БИТ в int'е, знаковый он или беззнаковый (а есть ещё окамловский знаковый, угу), и какой у него порядок байт.
Более того, мы бы не имели возможности работать со строками неизвестной длинны: сейчас их можно парсить конечным автоматом «пока не NULL продолжаем работать», а в случае с кортежной записью, мы бы всегда должны были бы говорить размер строки ДО того, как её передавать. Даже если мы сами не знаем, какой оно там длины.
Правильно говорить о дурацкой идее делать sprintf/gets — это да. Но однозначно осуждать null-строки как ошибку — я бы не стал.
Более того, мы бы не имели возможности работать со строками неизвестной длинны: сейчас их можно парсить конечным автоматом «пока не NULL продолжаем работать», а в случае с кортежной записью, мы бы всегда должны были бы говорить размер строки ДО того, как её передавать. Даже если мы сами не знаем, какой оно там длины.
Правильно говорить о дурацкой идее делать sprintf/gets — это да. Но однозначно осуждать null-строки как ошибку — я бы не стал.
Наверное можно сказать что оба решения имеют свои горы плюсов и минусов в равном степени.
Разные ситуации — разные плюсы/минусы.
Возможно наилучший вариант, было бы использовать оба варианта, а может и наихудший.
Не редко адрес + длина используется и довольно успешно в WinAPI, за что лично я делаю большой поклон Microsoft.
Разные ситуации — разные плюсы/минусы.
Возможно наилучший вариант, было бы использовать оба варианта, а может и наихудший.
Не редко адрес + длина используется и довольно успешно в WinAPI, за что лично я делаю большой поклон Microsoft.
>WinAPI
вот уже нашли образец для подражания, честное слово.
вот уже нашли образец для подражания, честное слово.
Microsoft кстати очень хорошо решила проблему со строками, например в mfc строки представлены как «размер + строка + null».
Лет 10 назад Крис Касперски в журнале «Программист» написал хорошую статью по этому поводу с различными замерами паскаль, си и mfc строк. Оптимизированная конкатенация с заранее известным размером вполне очевидно может быть выполнена до двух раз быстрее.
Лет 10 назад Крис Касперски в журнале «Программист» написал хорошую статью по этому поводу с различными замерами паскаль, си и mfc строк. Оптимизированная конкатенация с заранее известным размером вполне очевидно может быть выполнена до двух раз быстрее.
Многим не нравится WinAPI, но мне почему-то кажется, что навряд ли кто-то из них смог бы спроектировать API хотя бы не хуже того, как это сделали ребята из MS.
В каком сетевом протоколе, интересно, используются нулевые строки? HTTP/FTP/SMTP/IMAP — например используют 0x0a/0x0d. DNS пакеты вроде содержат длину строки адреса.
Тем более, что в итоге любой уважающий себя разработчик берет или пишет свою библиотеку для работы со строками, которая хранит длину строки в ней — ну а те, кто использует допотопные char* и strdup, за который жечь надо железом — те обычно висят в топах уязвимостей с buffer overflow.
Даже в PHP из-за двойного представления строк был долгонеисправляемый баг не так давно: PHP-ные функцие работали с бинарными строками, а вот fopen() — понимала NUL как конец строки.
Тем более, что в итоге любой уважающий себя разработчик берет или пишет свою библиотеку для работы со строками, которая хранит длину строки в ней — ну а те, кто использует допотопные char* и strdup, за который жечь надо железом — те обычно висят в топах уязвимостей с buffer overflow.
Даже в PHP из-за двойного представления строк был долгонеисправляемый баг не так давно: PHP-ные функцие работали с бинарными строками, а вот fopen() — понимала NUL как конец строки.
В передаче по сетям уже столкнулись с этими проблемами и их решением стал ASN.1
Вообще-то, есть такое понятие «сетевой порядок байтов», потому с порядком байтов в int'е всё понятно. Про битность и знаковость — согласен, равно как и про строки неизвестной длины.
Что касаемо «null-строки — ошибка» — есть занимательное чтиво.
От себя добавлю что разработчики Windows, похоже, не сошлись во мнениях по поводу формата строк в своей операционке. В результате на уровне ядра/native api царят строки с указанием длины (UNICODE_STRING) позволяющие писать высокопроизводительный код без алгоритма маляра Шлемиля. Однако на уровне API/CRT сплошь и рядом используются null-terminated строки, потому в прикладных программах волей-неволей куча пробежек «в поисках заветного нуля», которые явно не улучшают производительность, да и безопасность страдает.
Что касаемо «null-строки — ошибка» — есть занимательное чтиво.
От себя добавлю что разработчики Windows, похоже, не сошлись во мнениях по поводу формата строк в своей операционке. В результате на уровне ядра/native api царят строки с указанием длины (UNICODE_STRING) позволяющие писать высокопроизводительный код без алгоритма маляра Шлемиля. Однако на уровне API/CRT сплошь и рядом используются null-terminated строки, потому в прикладных программах волей-неволей куча пробежек «в поисках заветного нуля», которые явно не улучшают производительность, да и безопасность страдает.
а ведь вы правы! а то, было, я засомневался из-за статьи СИ предоставляла работу со строками на низком уровне, почти таком же как ассембелер, они к этому стремились и говорили прямо и открыто — следите за своими структурами не меньше, чем в асме. зато «низкоуровневая» работа со строками и переменными оставляла незауженное поле для деятельности и трюков. правда, вот такой вот ценой. но что мешало людям, которые неуверенно оперировали с типами данных написать себе обвязку, тем более есть целые библиотеки работы со строками и variable safe handling — всевозможные проверки на диапазон и переполнение.
А если длина строки была бы более одного байта, то каком формате они должны идти в big endian или в little endian? А если бы ребята тридцать (кстати, почему тридцать, если статья написана в 2011, а речь идет о начале 70-х?) приняли решение об использовании длины, то длина была бы точно 1 байт и мы бы поимели какую-нибудь странную оптимизацию, типа, если последний байт строки равен 0x7F, то в предыдущих 4-х байтах идет адрес продолжения этой строки или еще что-нибудь подобное.
В общем, null-terminated строки наломали дров, конечно, но я очень сомневаюсь, что в то время можно было прийти к решению, последствия от которых были бы меньше, чем сейчас.
В общем, null-terminated строки наломали дров, конечно, но я очень сомневаюсь, что в то время можно было прийти к решению, последствия от которых были бы меньше, чем сейчас.
4 байта и баста. Я очень сомневаюсь, что вы захотите передавать 8-гигабайтную текстовую строку как nul-terminated. Хотя бы потому что вряд ли она дойдёт за один коннект ;)
В крайнем случае есть и универсальный формат:
первый байт (n) — размерность длины
0 — пустая строка
1 — длина занимает 1 байт
2 — длина 2 байта
3 — длина занимает 4 байта
4 — длина занимает 8 байт
следующие 2^(n-1) байт — собственно длина в big-endian, а дальше указанное количество символов. Я думаю, строк длиной вплоть до 256^(2^254)-1 вам хватит надолго :)
В крайнем случае есть и универсальный формат:
первый байт (n) — размерность длины
0 — пустая строка
1 — длина занимает 1 байт
2 — длина 2 байта
3 — длина занимает 4 байта
4 — длина занимает 8 байт
следующие 2^(n-1) байт — собственно длина в big-endian, а дальше указанное количество символов. Я думаю, строк длиной вплоть до 256^(2^254)-1 вам хватит надолго :)
Согласен, но вот в семидесятых никто не принял бы вариант «4 байта и баста». Это ж сейчас 4 байта туда, 4 — сюда — это мелочи, а тогда у тебя 512 байт (!) рама и баста:)
Но, мне кажется, что влияние этой ошибки автором в любом случае преувеличено.
Возьмите, в качестве примера BSTR. Ее формат следующий: вначале 4 байта длины, затем сама строка, а в конце идет 2 нулевых байта. В этом случае, мы получаем выгоду «от двух миров»: мы за О(1) получаем длину строки и, в принципе, получаем обратную совместимость с С-строками (при учете, что нули не содержатся внутри строки, поскольку в BSTR это не запрещено).
Так что, по поводу null-terminated string и самой большой ошибки во вселенной, я не согласен.
Но, мне кажется, что влияние этой ошибки автором в любом случае преувеличено.
Возьмите, в качестве примера BSTR. Ее формат следующий: вначале 4 байта длины, затем сама строка, а в конце идет 2 нулевых байта. В этом случае, мы получаем выгоду «от двух миров»: мы за О(1) получаем длину строки и, в принципе, получаем обратную совместимость с С-строками (при учете, что нули не содержатся внутри строки, поскольку в BSTR это не запрещено).
Так что, по поводу null-terminated string и самой большой ошибки во вселенной, я не согласен.
4 байта — тю на вас. Маскимум для backslash0-завершенных строк это в пределах до 1024 байт (имена файлов, путь до файла, и так далее и тому подобное). Для файлов кстати еще один символ имеет свойство коварности '/'. По сути ведь «путь» — это не строка вовсе, а кортеж имен.
Не совсем понял Ваше высказвание про сеть и байты. Сериализация структур данных — отдельная задача, не связанная с их представлением в памяти машины. Формат и протокол передачи между терминалами на данном уровне OSI четко согласуется и иногда стандартизируется в RFC.
Кроме того, десериализация строк в формате (int)(array) реализовывать в разы проще и надежнее, чем NULL-ending, т.к. буфер нужной длины резервируем сразу.
Про парсинг строк неизвестной длины: здесь Вы путаете концепт строки и символьного потока. Строка — это объект в памяти фиксированной и заранее известной длины, допускающий доступ к любому символу по смещению. Поток — объект неизвестной длины, допускающий в общем случае только последовательный посимвольный доступ. Конечные автоматы работают именно с символьными потоками.
Видимо Керниган и Ричи в свое время тоже мыслили о строках исключительно как о символьных потоках.
Кроме того, десериализация строк в формате (int)(array) реализовывать в разы проще и надежнее, чем NULL-ending, т.к. буфер нужной длины резервируем сразу.
Про парсинг строк неизвестной длины: здесь Вы путаете концепт строки и символьного потока. Строка — это объект в памяти фиксированной и заранее известной длины, допускающий доступ к любому символу по смещению. Поток — объект неизвестной длины, допускающий в общем случае только последовательный посимвольный доступ. Конечные автоматы работают именно с символьными потоками.
Видимо Керниган и Ричи в свое время тоже мыслили о строках исключительно как о символьных потоках.
Строка — это объект в памяти фиксированной и заранее известной длины, допускающий доступ к любому символу по смещению.
Поэтому я не люблю utf8 :)
Поэтому я не люблю utf8 :)
Сжатые данные еще хуже в этом смысле — и ничего, живут же с этим как-то.
Сжатые данные не используют в контекстах, где нужна DMA скорость и random access.
сколько бы было пролито слёз по поводу того, СКОЛЬКО БИТ в int'е, знаковый он или беззнаковый (а есть ещё окамловский знаковый, угу), и какой у него порядок байт.
С порядком байт вроде удалось договориться — big-endian (хоть он и менее логичен для железок, ну да бог с ним). Зато сколько бит пролито в XML никто не парится :) А против nul-terminated строк в сетевом трафике есть очень веский довод — необходимость принимать символы по одному байту, чтобы не перечитать лишнего. Либо опять буфера, буфера, буфера…
Вообще, всё что ломает DMA каналы и затрудняет данных пачками с заранее известной длиной должно быть со временем искоренено. Это и nul-strings, и utf-8, и XML, и HTTP со своими текстовыми заголовками. Незачем внутреннему устройству компьтеров human-readability, она мешает.
С порядком байт вроде удалось договориться — big-endian (хоть он и менее логичен для железок, ну да бог с ним). Зато сколько бит пролито в XML никто не парится :) А против nul-terminated строк в сетевом трафике есть очень веский довод — необходимость принимать символы по одному байту, чтобы не перечитать лишнего. Либо опять буфера, буфера, буфера…
Вообще, всё что ломает DMA каналы и затрудняет данных пачками с заранее известной длиной должно быть со временем искоренено. Это и nul-strings, и utf-8, и XML, и HTTP со своими текстовыми заголовками. Незачем внутреннему устройству компьтеров human-readability, она мешает.
Что может быть альтернативой utf8? UNICODE16 уже не справляется со всеми символами unicode. Если мы сделаем UNICODE32, то это будет во-первых жирновато (4 байта на символ), а во-вторых что мы будем делать, когда окажется, что символов не хватает? Устраивать всемирную панику класса ipv4->ipv6?
Учитывая что подавляющая часть WinAPI (включая GDI) работает как раз с Unicode16 и что на винде сидит поболее пользователей, чем на posix системах, у меня сильные сомнения, что эти символы over 64k так уж сильно нужны в универсальном доступе в любой строке мира — возможно их следует отнести к графике, а не к тексту. К тому же уже отписывался в другом комменте, почему вдруг 64k стало не хватить — иероглифы надо рассматривать не как буквы, а как слова, состоящие из одинаковых элементов (символов), для поддержки каких-то тайских иероглифов так и начали делать. После того как уже испанахали половину свободного пространства китайским и японским по одному иероглифу на кодовую позицию. К тому же, кто будет рисовать фонты для миллиона символов, не говоря уже о 4 миллиардах?
А не слишком ли дороговато получится при необходимости работы с редкими символами (например, для написания курсовика по вэньяню) — менять платформу, потомучто в виндах «64k символов хватит для любых задач»?
А её и так придётся менять, потому что Windows GDI со всеми его вордами и экселями работает с 64k символов. Плюс я думаю очень вряд ли эти символы будут набираться с клавиатуры, а не браться в виде растровых сканов из вэньяньских летописей. Так же я не думаю, что вы найдёте вменяемые шрифты с вэньянем.
А не слишком ли дороговато получится
Не слишком. В вэньяне нет денег, и поэтому он не нужен.
А не слишком ли дороговато получится
Не слишком. В вэньяне нет денег, и поэтому он не нужен.
Софт с поддержкой utf-8 менять не придётся.
То, что в винде используется 64k это критерий только ограниченности винды, а не нужд людей.
То, что в винде используется 64k это критерий только ограниченности винды, а не нужд людей.
Софт с поддержкой utf-8 менять не придётся.
Ок, софт будет. А шрифты откуда возьмутся? :)
То, что в винде используется 64k это критерий только ограниченности винды, а не нужд людей.
Метрика искренности желания — готовность заплатить деньги. Эта же метрика определяет и развитие/ограниченность винды — что в ней есть, а чего в ней нет. Раз MS до сих пор не сунулась в over-64k набор символов, значит там нет рынка, т.е. людям это не надо.
Ок, софт будет. А шрифты откуда возьмутся? :)
То, что в винде используется 64k это критерий только ограниченности винды, а не нужд людей.
Метрика искренности желания — готовность заплатить деньги. Эта же метрика определяет и развитие/ограниченность винды — что в ней есть, а чего в ней нет. Раз MS до сих пор не сунулась в over-64k набор символов, значит там нет рынка, т.е. людям это не надо.
Тайское письмо — алфавитное.
Японское письмо — слоговое, с использованием китайских иероглифов.
Иероглифы на запчасти раскладываются только в корейском хангуле, но алгоритм комбинирования элементов на порядок сложнее парсинга utf8.
Зайдите на unicode.org/charts/unihanrsindex.html
и посмотрите как комбинируются «одинаковые» элементы в иероглифах.
Японское письмо — слоговое, с использованием китайских иероглифов.
Иероглифы на запчасти раскладываются только в корейском хангуле, но алгоритм комбинирования элементов на порядок сложнее парсинга utf8.
Зайдите на unicode.org/charts/unihanrsindex.html
и посмотрите как комбинируются «одинаковые» элементы в иероглифах.
Китайские иероглифы тоже бьются на части, китайские клавиатуры на этом принципе устроены (недавно была статья на хабре). По сути это можно свести к навороченному XY кернингу в шрифтах.
Не стоит проводить аналогию между «глиф» = «знакоместо». Все проблемы уникдов с иероглифами именно от этого «европейского» подхода к буквам.
Не стоит проводить аналогию между «глиф» = «знакоместо». Все проблемы уникдов с иероглифами именно от этого «европейского» подхода к буквам.
Сложность такого навороченного кернинга значительно превышает сложность кодирования символов.
И зачем, по-вашему, китайцы и корейцы изобретали кучу «посимвольных» (в том числе переменнобайтовых) кодировок иероглифов задолго до юникода?
Может, они чего-то не знают о конструировании иероглифов, чего знаете вы?
Может, они чего-то не знают о конструировании иероглифов, чего знаете вы?
Чтобы сохранить совместимость с европейскими растеризаторами шрифтов.
Не угадали.
Кодировки придумывались для телеграфа.
А на момент создания компьютерных кодировок (середина 80ых) европейские растеризаторы никак не умели рисовать иероглифы.
Кодировки придумывались для телеграфа.
А на момент создания компьютерных кодировок (середина 80ых) европейские растеризаторы никак не умели рисовать иероглифы.
А на момент создания компьютерных кодировок (середина 80ых) европейские растеризаторы никак не умели рисовать иероглифы.
Зашитые в видеопамять битмапы символов — тоже своеобразный «растеризатор». Чтобы натянуть на эту битмаповую модель иероглифы, пришлось делать по иероглифу на знакоместо, по-моему был даже период, когда их из кусочков собирали по 2-4 экранных символа в текстовом режиме на один иероглиф. Те же технические особенности продиктовали и кодировку в телеграфе.
А когда на смену битмапам и ромашковым печатным машинкам пришли векторные растеризаторы, никто этот подход рефакторить не стал — кодировки так и остались еще с довекторных времён.
Зашитые в видеопамять битмапы символов — тоже своеобразный «растеризатор». Чтобы натянуть на эту битмаповую модель иероглифы, пришлось делать по иероглифу на знакоместо, по-моему был даже период, когда их из кусочков собирали по 2-4 экранных символа в текстовом режиме на один иероглиф. Те же технические особенности продиктовали и кодировку в телеграфе.
А когда на смену битмапам и ромашковым печатным машинкам пришли векторные растеризаторы, никто этот подход рефакторить не стал — кодировки так и остались еще с довекторных времён.
Если под UNICODE16 подразумевалась UTF16, то в ней может быть представлен любой Unicode character, но она, как и UTF8, является variable-width. Кроме того, UTF16 может быть BE, а может быть LE, что тоже не является преимуществом перед UTF8, которая таких проблем лишена.
Возможно имелась в виду UCS2, которую часто неверно отождествляют с UTF16, она действительно не покрывает весь Unicode.
Возможно имелась в виду UCS2, которую часто неверно отождествляют с UTF16, она действительно не покрывает весь Unicode.
Энтони Хоар считает миллиардно-долларовой ошибкой свое изобретение, Null reference:
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
Я с ним согласен =)
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
Я с ним согласен =)
Конечно использование завершающихся NULL строк, не очень хорошая затея. Но дело в том что это единственный формат, который позволяет не заморачиваться на ее длину. И при достаточно малой длине это хорошее решение. В случае же добавления длины строки, надо думать какого размера будет этот самый счетчик. Если один байт, то максимальная длина строки 255 байтов, если два байта то ладно уже лучше 64 килобайта, но и накладные расходы уже на использование строк больше. Приемлемым было бы решение в 4 байта, но это дает уже существенные накладные расходы.
Кстати почему в статье нет упоминания про BigEndian и LittleEndian. Эта штука жизни мешает довольно сильно.
Кстати почему в статье нет упоминания про BigEndian и LittleEndian. Эта штука жизни мешает довольно сильно.
Давно придумали VLQ и его вариации. Первый бит обозначает наличие следующего байта, остальные биты — знаковые.
Получается для строк длиной до 127 (27) байт нужен 1 байт, для строк длиной до 16383 (214) — 2 байта и т.д.
Есть еще другой вариант — BER (и ASN.1), который используется, например, в SNMP: если установлен первый бит, то следующие 7 бит означают количество следующих байт содержащих значение, если же первый бит не установлен, то в следующих 7 битах само значение.
То есть для коротких строк (до 127 байт) будет всё тот же один байт, а для сверхдлинных в несколько мегабайт говорить об экономии 4-5 байт как-то глупо, не говоря уже о том, что это вообще странная затея передавать (и принимать) огромные строки не зная когда они закончатся. Ведь по сути именно это и породило многочисленные переполнения буфера с вытекающими из этого уязвимостями.
Кстати, в Delphi (камнями не кидаться), например, у типа String есть размер, но для совместимости в конце есть и null. PChar(string) вернет вполне валидную null-terminated строку (а PInteger(PChar(string)-4) будет указателем на её длину), но при этом программа на Delphi не будет испытывать неудобств в работе с нулями в самой строке.
А вот вам исходник strlen() из FreeBSD:
А по ссылке из glibc.
Не очень то дешевая операция для такой простой, казалось бы, задачи.
Всё ещё хотите работать со строками неизвестной длины?
Получается для строк длиной до 127 (27) байт нужен 1 байт, для строк длиной до 16383 (214) — 2 байта и т.д.
Есть еще другой вариант — BER (и ASN.1), который используется, например, в SNMP: если установлен первый бит, то следующие 7 бит означают количество следующих байт содержащих значение, если же первый бит не установлен, то в следующих 7 битах само значение.
То есть для коротких строк (до 127 байт) будет всё тот же один байт, а для сверхдлинных в несколько мегабайт говорить об экономии 4-5 байт как-то глупо, не говоря уже о том, что это вообще странная затея передавать (и принимать) огромные строки не зная когда они закончатся. Ведь по сути именно это и породило многочисленные переполнения буфера с вытекающими из этого уязвимостями.
Кстати, в Delphi (камнями не кидаться), например, у типа String есть размер, но для совместимости в конце есть и null. PChar(string) вернет вполне валидную null-terminated строку (а PInteger(PChar(string)-4) будет указателем на её длину), но при этом программа на Delphi не будет испытывать неудобств в работе с нулями в самой строке.
А вот вам исходник strlen() из FreeBSD:
size_t strlen(const char *str) {
const char *s;
for (s = str; *s; ++s);
return(s - str);
}
А по ссылке из glibc.
Не очень то дешевая операция для такой простой, казалось бы, задачи.
Всё ещё хотите работать со строками неизвестной длины?
Давно придумали VLQ и его вариации. Первый бит обозначает наличие следующего байта, остальные биты — знаковые.
Получается для строк длиной до 127 (27) байт нужен 1 байт, для строк длиной до 16383 (214) — 2 байта и т.д.
Есть еще другой вариант — BER (и ASN.1), который используется, например, в SNMP: если установлен первый бит, то следующие 7 бит означают количество следующих байт содержащих значение, если же первый бит не установлен, то в следующих 7 битах само значение.
У меня вопрос! А что делать с unicode при этом раскладе, а так же что делать с однобайтовыми кодировками использующими все биты?
Кстати, в Delphi (камнями не кидаться), например, у типа String есть размер, но для совместимости в конце есть и null.
Это кстати пошло из pascal.
Ну и собственно про то что с большими строками с NULL терминацией работать плохо, я отлично знаю. Плохо когда этого не знают.
vlq касается только служебной записи о длине строки. Остальные байты никак не меняются.
Кстати говоря, по поводу unicode: почитайте, как устроен utf-8 и вы заметите удивительное сходство с идеей vlq :)
Кстати говоря, по поводу unicode: почитайте, как устроен utf-8 и вы заметите удивительное сходство с идеей vlq :)
А чем ваш юникод отличается от другого набора байтов?
Ну да, длина строки и количество занимаемых ей байтов не равны, но даже std::string в своей реализации имеет отдельные length и capacity.
Для «общения» с недоверенным источником очевидно лучше передавать байтовый размер, так как в конце может оказаться 0x80, а вы будете пытаться считать еще байт, что по сути примерно то же самое что и отсутствующий ноль при ожидании null-terminated строки.
Ну да, длина строки и количество занимаемых ей байтов не равны, но даже std::string в своей реализации имеет отдельные length и capacity.
Для «общения» с недоверенным источником очевидно лучше передавать байтовый размер, так как в конце может оказаться 0x80, а вы будете пытаться считать еще байт, что по сути примерно то же самое что и отсутствующий ноль при ожидании null-terminated строки.
Вот, кстати, не совсем. Нуль-терминированная строка с известным размером будет побыстрее, чем не-нуль-терминированная. Потому как при операциях по всей длинне не обязательно постоянно делать сравнение указателя с концом, можно просто брать флаг после операции с самими данными.
Извиняюсь, в первом предложении не «знаковые», а «значимые».
А невозможность использования одного из 256-и значений внутри самой строки не дает существенных накладных расходов?
почему внутри строки? это только в первых байтах кодирующих длину первый бит означает что возьмите еще один байт. А как длина получена — дальше в строке все можно юзать :)
Можно, но надо не 1 байт, а два (PDP имела 16 разрядную шину адреса), об этом лишнем байте автор и говорит.
Вы о чем?
О том, что где бы не записывалась длинна, хоть в самой строке, хоть где-то рядом, хоть в специальной области, на тот момент она бы потребовала двух байт, а не одного, как нулевой байт.
Два байта необходимо, поскольку процессор имел 16 разрядную шину адреса, не уверен по поводу использования сегментации, но все равно это означает, что можно адресовать 64кб, соответственно максимальна длина строки — 65536 — 2 байта на длинну.
По тем временам это и был накладной расход в дополнительный байт на каждую строку, о котором Вы говорите.
Два байта необходимо, поскольку процессор имел 16 разрядную шину адреса, не уверен по поводу использования сегментации, но все равно это означает, что можно адресовать 64кб, соответственно максимальна длина строки — 65536 — 2 байта на длинну.
По тем временам это и был накладной расход в дополнительный байт на каждую строку, о котором Вы говорите.
Выше уже все написали про хранение длины строки. Как это связано с 16-и разрядными процессорами я не въезжаю.
Нулевой байт дает намного больше накладных расходов. При хранении, при операциях, везде.
Нулевой байт дает намного больше накладных расходов. При хранении, при операциях, везде.
Можно ведь придумать какой-то производный от паскалевских и сишных строк вариант.
Например:
VLQ, строка, [NULL]
Если VQL отлично от 0, то это строка фиксированной длины, собственно в VQL эта длина и записана, NULL в конце не добавляется. Если VQL равно 0, то это NULL-завершаемая строка. Второй вариант на случай если нужно принять строку неизвестной длины. Хотя строки неизвестной длины наверное лучше не принимать.
Например:
VLQ, строка, [NULL]
Если VQL отлично от 0, то это строка фиксированной длины, собственно в VQL эта длина и записана, NULL в конце не добавляется. Если VQL равно 0, то это NULL-завершаемая строка. Второй вариант на случай если нужно принять строку неизвестной длины. Хотя строки неизвестной длины наверное лучше не принимать.
'Наилучшим примером, который я смог найти, является использование NUL-завершенных текстовых строк в C/Unix/Posix. Стоял очень простой выбор: должен ли язык C представлять строки как кортеж адрес + длина или просто как адрес и некий магический символ (NUL), отмечающий конец строки? Именно это решение приняло динамическое трио Кен Томпсон, Деннис Ритчи и Брайан Керниган в начале 70-х, и они были вольны выбрать любой способ. Я не смог найти ни одной записи о решении, которое я признаю слабым кандидатом: у меня нет никаких доказательств, что это решение было осознанным.'
Странно видеть такое замечание от разработчика (http://en.wikipedia.org/wiki/Poul-Henning_Kamp). Недостаток такого представления в основном сказывается только при вычислении длины строки. Не надо забывать, что одно из достоинств, благодаря которому С стал одним из основных языков, это его адресная арифметика. А для нее такое представление строк идеально подходит, особенно при однопроходной обработке. Например:
int strcmp (const char *s1, const char *s2) {
while (*s1 == *s2++)
if (*s1++ == '\0')
return 0;
return *s1 — s2[- 1];
}
В результате задействовано только две переменные. Запишите это все через массивы, нужно будет иметь 2 переменных для массива символов, две на размер этих массивов, одна на текущее положение в массивах. А также раздутый примерно в 2-3 раза код.
Конечно адресная арифметика не так проста, но за эффективность надо платить.
Я поэтому считаю, что 'трио Кен Томпсон, Деннис Ритчи и Брайан Керниган', все сделали правильно, в едином ключе, а Poul-Henning Kamp написал не по делу. Лучше бы, он тогда свою статью назвал так «Нужно отказаться от адресной арифметики в C и перейти на массивы», но тогда не получился бы C.
Странно видеть такое замечание от разработчика (http://en.wikipedia.org/wiki/Poul-Henning_Kamp). Недостаток такого представления в основном сказывается только при вычислении длины строки. Не надо забывать, что одно из достоинств, благодаря которому С стал одним из основных языков, это его адресная арифметика. А для нее такое представление строк идеально подходит, особенно при однопроходной обработке. Например:
int strcmp (const char *s1, const char *s2) {
while (*s1 == *s2++)
if (*s1++ == '\0')
return 0;
return *s1 — s2[- 1];
}
В результате задействовано только две переменные. Запишите это все через массивы, нужно будет иметь 2 переменных для массива символов, две на размер этих массивов, одна на текущее положение в массивах. А также раздутый примерно в 2-3 раза код.
Конечно адресная арифметика не так проста, но за эффективность надо платить.
Я поэтому считаю, что 'трио Кен Томпсон, Деннис Ритчи и Брайан Керниган', все сделали правильно, в едином ключе, а Poul-Henning Kamp написал не по делу. Лучше бы, он тогда свою статью назвал так «Нужно отказаться от адресной арифметики в C и перейти на массивы», но тогда не получился бы C.
Не понятно, а что мешает программистам для своих приложений написать модуль строк хранящих длину? Это совсем не сложно.
Тема статьи надумана, гораздо больше проблем, на мой взгляд, вызывает адресная арифметика.
Тема статьи надумана, гораздо больше проблем, на мой взгляд, вызывает адресная арифметика.
Ничего не мешает. developer.gnome.org/glib/2.28/glib-Strings.html
1) для многих (интерпретируемых прежде всего) языков этот модуль наверняка будет не столь эффективен, как стандартные библиотеки
2) рано или поздно придётся вызывать функции стандартных библиотек и API ОС, а значит ещё конвертацией туда-сюда придётся озаботиться
2) рано или поздно придётся вызывать функции стандартных библиотек и API ОС, а значит ещё конвертацией туда-сюда придётся озаботиться
Самая дорогая однобайтовая ошибка, это в договоре на миллиард долларов вместо $ поставить р )
имею сильнейший гемморой с софтом управления своими железяками — на стороне железяк сидят управляющие регистры, которые начинаются с 0x00 и часто имеют значения 0x00. В Qt мне по случаю полного программистского невежества очень удобно работать с классом QString, но очень неудобно с классом QByteArray и с методами readRawData() и writeRawData. Сижу бывало весь вечер напролет и матерю эти чертовы строки.
Ну а если отвлечься от однобайтовости, то хочется передать отдельный привет товарищам Кириллу и Мефодию.
Ну а если отвлечься от однобайтовости, то хочется передать отдельный привет товарищам Кириллу и Мефодию.
При использовании NUL-завершенной строки, попытка работы с ней частями, превышающими один байт, может привести к обращению к символам за символом NUL. Если NUL символ является последним байтом страницы виртуальной памяти и следующая страница не определена, это может привести к крушению процесса с ошибкой «страница не найдена» [«page not present»].>
На деле этого никогда не произойдёт. Библиотека осуществляет доступ к строке как к многобайтовым целым не начиная с начала строки, а начиная с первого её байта, кратному размеру удобного для процесса целого (часто совпадающему по размеру с указателем). Это называется выравнивание, а при доступе к памяти без выравнивания на одних процессорах происходят тормоза, а на других — ошибки выполнения.
Границы и размер страниц тоже выровнены по этому размеру, из-за чего выход за пределы страницы в поисках NULL-байта не произойдёт, так как часть многобайтного целого числа никогда не будет проходить по границе страницы.
Начало строки может быть не выровняно в памяти, а динамически созданные буферы вообще находятся в куче и положение буфера зависит от свободных слотов в куче. Даже если ее обходить фрагментами по 2, 4 и т.д. байт, есть риск вылезти за границу страницы.
Копирование строки не будет обращаться к строке как к числам с первых байтов, а начнет делать это по выравниванию. Это и гарантирует непересечение границы страницы. Грубо говоря, код вместо
для платформы с выравниванием по 4 байтам имеет вид примерно
void strcpy(char* _dest, const char* _src) {
int *dest = _dest, src = _src;
while (!contains_null_byte(*src)) {
*dest++ = *src++;
}
*dest = 0;
/* обработка граничных случаев */
}для платформы с выравниванием по 4 байтам имеет вид примерно
void strcpy(char* _dest, const char* _src) {
if (_dest & 3 != _src & 3) {
while (*_src) *_dest++ = *_src++;
*_dest = 0;
return;
}
while (_dest & 3 && *_dest) {
*_dest++ = *_src++;
}
int *dest = _dest, src = _src;
while (!contains_null_byte(*src)) {
*dest++ = *src++;
}
_dest = dest; _src = src;
while (*src) *_dest++ = *_src++;
*_dest = 0;
}
То есть, доступ к памяти всегда будет проходить по границе страницы, и будет определено, что строка либо заканчивается на текущей странице, либо продолжается на следующей.
А кто гарантирует выравнивание?
Спасибо за пояснения, так понятней. Вы правы, предложенный Вами алгоритм устраняет проблему. Но он только работает, если обе строки начинаются по одному смещению от границы выравнивания, в остальных слуачях все равно побайтно. Вот об этом и говорит автор, что для оптимизации необходимо усложнять алгоритмы.
Вы о чем сейчас?
Ни о каких выравниваниях речи не идет. Null-байт может без проблем быть последним на странице (как и сказано в статье), следующая страница вполне может быть не определена для процесса (как и сказано в статье) и в таком случае, если я напрямую буду работать со строкой кусками больше чем 1 байт (и тут меня никто не ограничивает в выборе кусков и выборе начала отсчета) — приложение вылетит (как и сказано в статье).
Ни о каких выравниваниях речи не идет. Null-байт может без проблем быть последним на странице (как и сказано в статье), следующая страница вполне может быть не определена для процесса (как и сказано в статье) и в таком случае, если я напрямую буду работать со строкой кусками больше чем 1 байт (и тут меня никто не ограничивает в выборе кусков и выборе начала отсчета) — приложение вылетит (как и сказано в статье).
А почему Вы будете обращаться к следующей странице, если Вы знаете, что на текущей странице строка уже закончилась?
В выборе начала отсчёта и кусков Вас как раз ограничивает выравнивание.
В выборе начала отсчёта и кусков Вас как раз ограничивает выравнивание.
Ну во первых никакое выравнивание меня не ограничивает в выборе размера куска, которым я хочу манипулировать, меня ограничивает адресация, заставляя выбирать кусок, кратный одному байту, а вот написать процедуру, которая берет блоки по 1000 байт мне ничто не мешает, и в случае строки без длины я такой процедурой пользоваться просто не смогу, т.к. она может свалиться.
Ну и вообще — далеко не все платформы дают ошибку при обращении по невыровненному адресу, так что ни о каком выравнивании речи нет.
Ну и вообще — далеко не все платформы дают ошибку при обращении по невыровненному адресу, так что ни о каком выравнивании речи нет.
>Ну во первых никакое выравнивание меня не ограничивает
На ряде платформ оно ограничит Вас SIGBUSом, на других — снизившейся в 4 раза производительностью. *((int*)0) = 0 Вы тоже можете написать и язык Вас в этом не ограничивает, но так делать не нужно.
>вот написать процедуру, которая берет блоки по 1000 байт мне ничто не мешает
Я же написал — «на деле этого никогда не произойдёт», а не «не существует никаких возможностей написать код, который столкнётся с этой проблемой». Потому что работа с кусками по 1000 байт в данном контектсе не имеет смысла, а имеет смысл копирование кусками по 4/8 байт, чем все активно и пользуются.
На ряде платформ оно ограничит Вас SIGBUSом, на других — снизившейся в 4 раза производительностью. *((int*)0) = 0 Вы тоже можете написать и язык Вас в этом не ограничивает, но так делать не нужно.
>вот написать процедуру, которая берет блоки по 1000 байт мне ничто не мешает
Я же написал — «на деле этого никогда не произойдёт», а не «не существует никаких возможностей написать код, который столкнётся с этой проблемой». Потому что работа с кусками по 1000 байт в данном контектсе не имеет смысла, а имеет смысл копирование кусками по 4/8 байт, чем все активно и пользуются.
Ну во первых то что есть некоторые платформы с невозможностью так сделать — ни о чем не говорит.
Второе — читаем статью и там ничего о копировании или прочем, так что какой контекст? В контексте как раз этого совершенно небыло. Там сказано что нельзя работать со строкой кусками — а это на деле очень даже может произойти.
А то получается что вы взяли несколько своих конфигураций и юз-кейсов и делаете вид, что автор статьи именно ваш случай имеет ввиду, и поэтому он не прав, потому что частно в вашем случае проблем не будет. Только вот автор говорит на самом деле о гораздо более общей проблеме.
Второе — читаем статью и там ничего о копировании или прочем, так что какой контекст? В контексте как раз этого совершенно небыло. Там сказано что нельзя работать со строкой кусками — а это на деле очень даже может произойти.
А то получается что вы взяли несколько своих конфигураций и юз-кейсов и делаете вид, что автор статьи именно ваш случай имеет ввиду, и поэтому он не прав, потому что частно в вашем случае проблем не будет. Только вот автор говорит на самом деле о гораздо более общей проблеме.
>Ну во первых то что есть некоторые платформы с невозможностью так сделать — ни о чем не говорит.
Когда таких платформ — 99%, это о чём-то говорит.
>и поэтому он не прав, потому что частно в вашем случае проблем не будет. Только вот автор говорит на самом деле о гораздо более общей проблеме.
Где я говорил, что автор не прав? Я пытался показать, что это замечание может привести к указанным последствиям намного реже, чем может показаться.
Когда таких платформ — 99%, это о чём-то говорит.
>и поэтому он не прав, потому что частно в вашем случае проблем не будет. Только вот автор говорит на самом деле о гораздо более общей проблеме.
Где я говорил, что автор не прав? Я пытался показать, что это замечание может привести к указанным последствиям намного реже, чем может показаться.
Ничего не знаю про 99%, давайте цифры по распространенности и с пруфами.
По второму пункту — тоже самое, «намного реже» нужно аргументировать, а не просто показать что в одном из случаев копирования ошибок нет.
По второму пункту — тоже самое, «намного реже» нужно аргументировать, а не просто показать что в одном из случаев копирования ошибок нет.
>Ничего не знаю про 99%, давайте цифры по распространенности и с пруфами.
en.wikipedia.org/wiki/Data_structure_alignment#Architectures
Распространенность архитектур сами нагуглите?
>По второму пункту — тоже самое, «намного реже» нужно аргументировать, а не просто показать что в одном из случаев копирования ошибок нет.
Код для копирования/прочих манипуляций со строками есть в stdlib. Можете поставить профайлер и посмотреть на Вашей системе, сколько времени он выполняется. Ещё можете найти мне хотя бы 5 примеров в распространенных проектах, где используется доступ к строкам блоками по 1000 байт.
en.wikipedia.org/wiki/Data_structure_alignment#Architectures
Распространенность архитектур сами нагуглите?
>По второму пункту — тоже самое, «намного реже» нужно аргументировать, а не просто показать что в одном из случаев копирования ошибок нет.
Код для копирования/прочих манипуляций со строками есть в stdlib. Можете поставить профайлер и посмотреть на Вашей системе, сколько времени он выполняется. Ещё можете найти мне хотя бы 5 примеров в распространенных проектах, где используется доступ к строкам блоками по 1000 байт.
Я как раз к тому, что самая распространенная архитектура для десктопов как раз может работать без выравнивания — а это не малый кусок, чтобы его игнорировать.
Что такое stdlib? Кто сказал про C++? Вроде и статья не о C++, и блог не о C++, да и разговор не о C++ — так причем тут C++?
Что такое stdlib? Кто сказал про C++? Вроде и статья не о C++, и блог не о C++, да и разговор не о C++ — так причем тут C++?
>Я как раз к тому, что самая распространенная архитектура для десктопов как раз может работать без выравнивания — а это не малый кусок, чтобы его игнорировать.
Эта архитектура рекомендует выравнивание и не гарантирует доступ с выравниванием и без выравнивания с одинаковой скоростью.
>Что такое stdlib? Кто сказал про C++? Вроде и статья не о C++, и блог не о C++, да и разговор не о C++ — так причем тут C++?
О C++ никто не и говорил — там строки с длинной и к ним не применяются эти функции. В C#/Java/Python/вставьте_сюда_Ваш_любимый_язык — скорее всего, тоже.
Я говорил о C, на котором работают почти все эти языки и куча юзерспейсных программ.
Пожалуйста, перестаньте себе противоречить — сначала Вы требуете показать конкретный случай, который я считаю частоиспользуемым, а потом не принимаете его, так как он привязан к языку.
Эта архитектура рекомендует выравнивание и не гарантирует доступ с выравниванием и без выравнивания с одинаковой скоростью.
>Что такое stdlib? Кто сказал про C++? Вроде и статья не о C++, и блог не о C++, да и разговор не о C++ — так причем тут C++?
О C++ никто не и говорил — там строки с длинной и к ним не применяются эти функции. В C#/Java/Python/вставьте_сюда_Ваш_любимый_язык — скорее всего, тоже.
Я говорил о C, на котором работают почти все эти языки и куча юзерспейсных программ.
Пожалуйста, перестаньте себе противоречить — сначала Вы требуете показать конкретный случай, который я считаю частоиспользуемым, а потом не принимаете его, так как он привязан к языку.
Не гарантирует с одинаковой скоростью != не работает.
Я просил аргументировать, а не представить один случай. Аргументировать то, что приведенные случаи покрывают настолько большой процент — что проблема не является актуальной, как представлено в статье.
Еще раз — не который вы считаете частоиспользуемым, а который подтвержденно является настолько частоиспользуемым, что проблему можно считать не актуальной.
Я просил аргументировать, а не представить один случай. Аргументировать то, что приведенные случаи покрывают настолько большой процент — что проблема не является актуальной, как представлено в статье.
Еще раз — не который вы считаете частоиспользуемым, а который подтвержденно является настолько частоиспользуемым, что проблему можно считать не актуальной.
Кстати говоря, для использования тех же SSE регистров — разве кто-то гарантирует мне на 32 разрядной платформе выравнивание по 128 битам?
0. мне нравиться постановка — основатели самого используемого системного языка сделали ошибку! Они сделали язык, который фактически стандартизовал системный код, вытеснил ассемблер из системного программирования и заложил основы популярности unix. Насколько на это повлияла совместимость с асмом — еще тот вопрос. В качестве примера — куча языков и реализаций несовместимые по вызовам угасали.
В общем называть ошибкой это не то что нельзя, а как-то по детски что ли…
1. рассуждения о цифрах в миллиард без хотя бы базовых прикидок — фуфло. Мне кажется что они правы в том что nul-terminated было дороже, но на сколько — это вопрос. Но есть вероятность что проблем было бы не меньше и затраты на обработку строк с известной длинной соизмеримы. В общем говоря об ошибке надо бы представить доказательства а не мусолить аргументы.
2. Очевидно что за 40 лет ситуация изменилась кардинально и можно говорить что было бы лучше. Следует учесть что когда-то памяти было мало и она была дорогая и сколько было сэкономлено памяти — еще тот вопрос. Это сейчас железо дешёвое.
Очень даже возможно что если посчитать байт на строчку в долларах будет миллиардная экономия.
В общем называть ошибкой это не то что нельзя, а как-то по детски что ли…
1. рассуждения о цифрах в миллиард без хотя бы базовых прикидок — фуфло. Мне кажется что они правы в том что nul-terminated было дороже, но на сколько — это вопрос. Но есть вероятность что проблем было бы не меньше и затраты на обработку строк с известной длинной соизмеримы. В общем говоря об ошибке надо бы представить доказательства а не мусолить аргументы.
2. Очевидно что за 40 лет ситуация изменилась кардинально и можно говорить что было бы лучше. Следует учесть что когда-то памяти было мало и она была дорогая и сколько было сэкономлено памяти — еще тот вопрос. Это сейчас железо дешёвое.
Очень даже возможно что если посчитать байт на строчку в долларах будет миллиардная экономия.
Статья конечно интересная, но она хороша как хороший иллюстративный пример. Пример, как одно решение, принятое когда-то в рабочем порядке, может оказать влияние на глобальное развитие технологий на десятки лет. Да и вообще задуматся, какую роль в нашей жизни играют рудименты, то есть наследие когда-то принятых решений.
Поэтому если все-таки не вырывать «null terminated» из исторического контекста, то нет особого повода метать направо и налево осуждающие возгласы. Вы же, надеюсь, не осуждаете отсталость, несовершенство и экологическу вредность технологий работы с металлом бытовавших в бронзовом веке.
Поэтому попробую вкратце вернуть «полемику» назад в исторический контекст из которого она успешно общими стараниями выпала.
Так вот, (пожалуйста, фанфары) сейчас Капитан Очевидность, откроет Вам «большой-большой секрет»: Когда Отцы-основатели придумывали язык C они совсем-совсем не заморачивались над тем, чтобы все использованные ими архитектурные конструкции эффективно работали на компьютерах 21века. Они вообще, наверное даже не делали предположений насчет того, какими будут компьютеры 21 века.
У них стояла достаточно четкая и понятная задача создание высокоуровнего языка, с помощью которого можно решать большинство задач не менее эффективно, чем с использованием ассемблера. Да, еще о «зоопарке» они тогда не думали, у них под рукой была PDP-архитектура, и именно для нее они разрабатывали «высокоуровневый ассемблер». Как вы понимаете, единственно возможный способ эффективно решить эту задачу — сделать конструкции высокоуровневого языка максимально легко отображаемыми на аппаратную архитектуру.
А вот после такого «введения», pадумайтесь, почему в языке C нет например оператора циклического сдвига? Почему в язык C «забыли положить» операцию возвратить первый/последний включенный бит в машинном слове? Или почему нет оператора подсчета битов в байте? Ведь было бы так удобно?
Ответ простой: их «не положили», потому что таких ассемблерных инструкций просто не было в системе комманд PDP-11!
Поэтому, личности, утверждающие что операции автоинкремента якобы «синтаксический сахар языка C», по меньшей мере показывают свою некомпетентность по историческому вопросу. В языке C не задумывался синтаксический сахар совсем, как понятие. Операции ++,-- это все лишь способ эффективно использовать имевшийся в тогдашней системе комманд режим автоинкрементной адресации (справедливая логика: почему бы не получить профит на пустом месте, просто заюзав в языке то, что «одной ассемблерной коммандой» нахаляву дается в процессоре).
А теперь, (еще, пожалуйста, фанфары) про «null-byte» решение! Опять-таки, если мы заглянем в описание архитектуры PDP-11, то мы обнаружим что в отличии от большинства современных архитектур, комманды пересылки данных модифицировали флаговый регистр.
Как в самом языке C и соответственно в стандартной библиотеке языка C этот «профит на пустом месте» следующий из этой «фичи» использован направо и налево — везде и повсеместно! Именно за счет этой особенности архитектуры большинство операций манипулирующих с null-terminated строками за счет подобного «знания архитектуры PDP» легко могли быть превращены в простой и компактный код зачастую всего в несколько ассемблерных комманд!!!
И это был наверное едиственнный способ создать возможность написания операционной системы на высокоуровневом языке!!! Просто потому что в те годы, память мерялась байтами а не гигабайтами! ;)
Прошли годы, и оказалось, что язык C и Unix вдруг (неожиданно для самих авторов) оказались «суперпортируемымы». И они взяли с собой все, в том числе и те особенности, которые им достались «в наследство» от древниго Unix на PDP-архитектуре.
Кстати, я бы отдал должное Кернигану, Ричи и Томпсону, ведь большинство из тех решений которые ими были приняты более чем 40 лет назад (вдумайтесь в эту цифру! более сорока лет!), успешно работают на современных архитектурах!
Да, некоторые правда решения вроде null-terminated strings оказались действительно не очень заточенными на архитектуру современных процессоров с их векторизацией, out of order execution-ом, cache prefetch-ингом, branch prediction-ом, и прочими «прелестями» которых не было в конце 60х годов прошлого тысячелетия.
Так вот, наверное очень легко «задним умом» считать, сколько бы кто-то там заработал если бы сорок лет назад Керниган с Ричи придумали другую систему кодирования строк. (Вы знаете, если бы я в 1993 не маялся бы всякой ерундой а купил бы акций АО МММ, а потом бы через два годика продал… ну вы поняли, задним умом все сильны).
Легко, сидя в 2011 году осуждать «рудименты PDP-11». Однако если приглядется, вся компьютерная технология соткана из таких рудиментов (в одной только x86-архитектуре я могу сходу назвать десятки «8-битных рудиментов», про программные же «рудименты» даже Капитану Очевидность говорить стыдно).
Да и не только компьютерная технология. Попробуйте, уважаемые хабрачитатели, задуматься, а сколько в вашей ДНК за миллиарды лет эволюции накопилось «рудиментарного кода»? У вас два глаза, две руки и две ноги, потому что это случайно оказалось оптимальным решением для какого-то предка жившего сотни миллионов лет назад. Может, ради прикола, посчитаем сколько стоило «в условных единицах» эволюционное решение нашего далекого предка (принятое сотни миллионов лет назад) иметь две руки а не четыре? :) Только, когда будете считать, имейте ввиду, что кто знает, возможно если бы наш далекий предок тогда не «принял бы решение» иметь две руки и две ноги, нас с вами бы на свете не было, так что с «рудиментами» не все так однозначно;)
Так, что трудно сказать «ошибка ли это» или это «необходимое решение». Я бы это не называл «ошибкой». Это «решение», и весьма осознанное! И как любое важное решение оно имело свою «стоимость», и не малую — но все имеет свою цену!
Но если бы эта цена не была заплачена, мы бы наверное сейчас не имели ничего из того, что мы сейчас имеем! Просто попробуйте задуматся на этот счет!
Поэтому если все-таки не вырывать «null terminated» из исторического контекста, то нет особого повода метать направо и налево осуждающие возгласы. Вы же, надеюсь, не осуждаете отсталость, несовершенство и экологическу вредность технологий работы с металлом бытовавших в бронзовом веке.
Поэтому попробую вкратце вернуть «полемику» назад в исторический контекст из которого она успешно общими стараниями выпала.
Так вот, (пожалуйста, фанфары) сейчас Капитан Очевидность, откроет Вам «большой-большой секрет»: Когда Отцы-основатели придумывали язык C они совсем-совсем не заморачивались над тем, чтобы все использованные ими архитектурные конструкции эффективно работали на компьютерах 21века. Они вообще, наверное даже не делали предположений насчет того, какими будут компьютеры 21 века.
У них стояла достаточно четкая и понятная задача создание высокоуровнего языка, с помощью которого можно решать большинство задач не менее эффективно, чем с использованием ассемблера. Да, еще о «зоопарке» они тогда не думали, у них под рукой была PDP-архитектура, и именно для нее они разрабатывали «высокоуровневый ассемблер». Как вы понимаете, единственно возможный способ эффективно решить эту задачу — сделать конструкции высокоуровневого языка максимально легко отображаемыми на аппаратную архитектуру.
А вот после такого «введения», pадумайтесь, почему в языке C нет например оператора циклического сдвига? Почему в язык C «забыли положить» операцию возвратить первый/последний включенный бит в машинном слове? Или почему нет оператора подсчета битов в байте? Ведь было бы так удобно?
Ответ простой: их «не положили», потому что таких ассемблерных инструкций просто не было в системе комманд PDP-11!
Поэтому, личности, утверждающие что операции автоинкремента якобы «синтаксический сахар языка C», по меньшей мере показывают свою некомпетентность по историческому вопросу. В языке C не задумывался синтаксический сахар совсем, как понятие. Операции ++,-- это все лишь способ эффективно использовать имевшийся в тогдашней системе комманд режим автоинкрементной адресации (справедливая логика: почему бы не получить профит на пустом месте, просто заюзав в языке то, что «одной ассемблерной коммандой» нахаляву дается в процессоре).
А теперь, (еще, пожалуйста, фанфары) про «null-byte» решение! Опять-таки, если мы заглянем в описание архитектуры PDP-11, то мы обнаружим что в отличии от большинства современных архитектур, комманды пересылки данных модифицировали флаговый регистр.
Как в самом языке C и соответственно в стандартной библиотеке языка C этот «профит на пустом месте» следующий из этой «фичи» использован направо и налево — везде и повсеместно! Именно за счет этой особенности архитектуры большинство операций манипулирующих с null-terminated строками за счет подобного «знания архитектуры PDP» легко могли быть превращены в простой и компактный код зачастую всего в несколько ассемблерных комманд!!!
И это был наверное едиственнный способ создать возможность написания операционной системы на высокоуровневом языке!!! Просто потому что в те годы, память мерялась байтами а не гигабайтами! ;)
Прошли годы, и оказалось, что язык C и Unix вдруг (неожиданно для самих авторов) оказались «суперпортируемымы». И они взяли с собой все, в том числе и те особенности, которые им достались «в наследство» от древниго Unix на PDP-архитектуре.
Кстати, я бы отдал должное Кернигану, Ричи и Томпсону, ведь большинство из тех решений которые ими были приняты более чем 40 лет назад (вдумайтесь в эту цифру! более сорока лет!), успешно работают на современных архитектурах!
Да, некоторые правда решения вроде null-terminated strings оказались действительно не очень заточенными на архитектуру современных процессоров с их векторизацией, out of order execution-ом, cache prefetch-ингом, branch prediction-ом, и прочими «прелестями» которых не было в конце 60х годов прошлого тысячелетия.
Так вот, наверное очень легко «задним умом» считать, сколько бы кто-то там заработал если бы сорок лет назад Керниган с Ричи придумали другую систему кодирования строк. (Вы знаете, если бы я в 1993 не маялся бы всякой ерундой а купил бы акций АО МММ, а потом бы через два годика продал… ну вы поняли, задним умом все сильны).
Легко, сидя в 2011 году осуждать «рудименты PDP-11». Однако если приглядется, вся компьютерная технология соткана из таких рудиментов (в одной только x86-архитектуре я могу сходу назвать десятки «8-битных рудиментов», про программные же «рудименты» даже Капитану Очевидность говорить стыдно).
Да и не только компьютерная технология. Попробуйте, уважаемые хабрачитатели, задуматься, а сколько в вашей ДНК за миллиарды лет эволюции накопилось «рудиментарного кода»? У вас два глаза, две руки и две ноги, потому что это случайно оказалось оптимальным решением для какого-то предка жившего сотни миллионов лет назад. Может, ради прикола, посчитаем сколько стоило «в условных единицах» эволюционное решение нашего далекого предка (принятое сотни миллионов лет назад) иметь две руки а не четыре? :) Только, когда будете считать, имейте ввиду, что кто знает, возможно если бы наш далекий предок тогда не «принял бы решение» иметь две руки и две ноги, нас с вами бы на свете не было, так что с «рудиментами» не все так однозначно;)
Так, что трудно сказать «ошибка ли это» или это «необходимое решение». Я бы это не называл «ошибкой». Это «решение», и весьма осознанное! И как любое важное решение оно имело свою «стоимость», и не малую — но все имеет свою цену!
Но если бы эта цена не была заплачена, мы бы наверное сейчас не имели ничего из того, что мы сейчас имеем! Просто попробуйте задуматся на этот счет!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Самая дорогая однобайтовая ошибка