Почему char занимает 1 байт, а строка с одним символом — 2 байта?

Question

[nkorobkov]

Слышал что-то про добавление в конце строк " \0 ", но не вдавался в подробности. Кто знает, ответьте пожалуйста!

Answer 1

[Кирилл Романов]

Все правильно, этот 1 байт занимает символ конца строки '\0'

Answer 2

[redakoc]

Существует 2 типа строк:

Типа С.
Тип Паскаль.

К языкам это не имеет отношения: язык Паскаль может использовать строки типа С, язык С может использовать строки типа Паскаль. Название просто исторически возникло, т.к. изначально в С и Паскале были только одного вида строки (разные, такие как описано ниже).

Строка типа С - это массив байтов, заканчивающийся нулем. То есть строка не может содержать символ с кодом 0 (не числом 0, а символ с кодом 0, нулевой байт). Длина строки всегда = количество символов + 1 байт (с нулевым кодом) в конце строки.

Строка типа Паскаль в начале хранит 1 байт, указывающий длину строки, затем идет массив символов. Строка может содержать внутри себя символы с кодом 0. Но не может быть длиннее 255 байт. В памяти такая строка занимает те же что и С = число символов в строке + 1 байт в начале, хранящий её длину.

А еще есть строки UNICODE, UTF8, строки типа Паскаль, где длина указана 2-мя байтами (т.е. максимальная длина 65535 символов в строке).

Длина таких строк в байтах может быть очень и очень разной. Совсем не соответствующей числу символов. Разница будет не на 1 байт (как в простых строках типа С и типа Паскаль). Более того, например, в UTF8 длина строки в байтах будет зависеть от того, что именно написано. )))

В наше время я настоятельно рекомендую изучать не простые char, а обратить внимание именно на UNICODE.
А там вовсе не один байт на один символ. )))))

Comments

[abcd0x00]

В памяти такая строка занимает те же что и С = число символов в строке + 1 байт в начале, хранящий её длину.

Максимальная длина - 255 символов.
А в C максимальная длина - 4294967295 символов (вместимость size_t).

К тому же, благодаря такому устройству, в C-строках можно гулять туда-сюда с помощью указателя.

[redakoc]

abcd0x00:

У вас совершенно не внятное замечание. Ну включим "зануда-mode":

1. С помощью указателя можно гулять по ЛЮБОЙ строке. Более того, зная сразу, где конец строки без того, что проверять все байты на 0, гулять по строке типа Паскаль проще, чем по строке типа С.

2. Зачем вам на практике 4204067..... ? Если речь идет о текстовом редакторе, то там совсем по другому организовано хранение. Не в одной строке.

3. Разве что в примитивных текстовых редакторах можно все запихнуть в одну строку. Но при попытке редактировать в таком редакторе большой файл вы стазу же столкнетесь с большими задержками при самых обычных операциях вставки-удаления символов в/из середину.

4. Если тебе нужно работать со строками такой длины 4204067..., то для строки типа Паскаль никто не мешает использовать не 1 (ограничение на максимальную длину 255), а 4 байта для хранения длины. Что? На 3 байта больше приходится тратить оперативной памяти? И это-то при общей длине строки 4 гигабайта? Ты серьезно считаешь это недостатком?

5. Что? В строка типа Паскаль можно хранить на 3 полезных байта меньше? При длине строки 4204067... ты считаешь это важным? Хорошо. Храним строку в структуре - отдельно размер, отдельно указатель на саму строку. В этом случае строка, размер которой определяется не наличием 0 в конце, а длина которой храниться отдельно позволяет хранить строки более длинные на 1 байт. Кому только это надо.

5. То, что ты сразу знаешь длину, а тебе не нужно бегать и считать, ища ноль - преимущество по скорости для многих типовых операций. А если действительно используются возможности по максимуму, то есть работаем с гигантскими строками 4204067..., то искать конец строки в такой строке - просто глупо. Лучше знать заранее.

6. В строке нельзя хранить 0. Как показывает практика, если уж речь идет о строках такой длины как 4295967..., то это скорее всего уже не обычный текст, а какие-то данные не текстовые, просто хранимые в виде строкоподобного массива, а там запросто и 0 может встречаться внутри строки, что делает невозможно использование обычной строки для хранения таких длинных строк с данными.

7. Вывод: число 4204067... хорошо попонтоваться, что "я знаю такую штуку как size_t", а фактически практической пользы от этого мало.

[abcd0x00]

redakoc:

1. С помощью указателя можно гулять по ЛЮБОЙ строке.

С помощью указателя можно гулять по нескольким строкам, сложенным друг за другом.
В Паскале это всё будет снова молиться на размер одной строки.

2. Зачем вам на практике 4204067..... ? Если речь идет о текстовом редакторе, то там совсем по другому организовано хранение. Не в одной строке.

Да базу данных можно хранить так, файловую систему, много чего.

3. Разве что в примитивных текстовых редакторах можно все запихнуть в одну строку.

Я бы не стал так делать, потому что оно не пройдёт тест на огромный файл.

4. Если тебе нужно работать со строками такой длины 4204067..., то для строки типа Паскаль никто не мешает использовать не 1 (ограничение на максимальную длину 255), а 4 байта для хранения длины.

Предлагаешь заморачиваться с подбиранием размера, а я вот просто сохраню строку с нуль-символом.
Пока ты будешь размеры подбирать, я уже полпрограммы напишу и буду чаёк попивать.

5. Что? В строка типа Паскаль можно хранить на 3 полезных байта меньше? При длине строки 4204067... ты считаешь это важным?

Да я могу хоть каталог файлов так сохранить один за другим. Маркерная система - это обычная система, которую придумали ещё до C. В данном случае маркер конца данных - нуль-символ. У тебя нет таких навыков, поэтому все мысли только через размер данных идут.

А если действительно используются возможности по максимуму, то есть работаем с гигантскими строками 4204067..., то искать конец строки в такой строке - просто глупо.

Конечно, проходить по всей строке с проверками на нуль-символ, - способ неправильный. Зато можно работать с данными напрямую, без заморочек с размером. Можно нарезать их прямо с середины. В любом месте можно встать и поставить начало внутренней строки (подстроки). Вот там есть пример в библиотеке - strtok() - когда строку можно нарезать на слова, сохраняя указатели на них. Можно и интереснее операции делать - ограничений нет. С размером этой возможности нет, там всё тупо и ограничено.

[redakoc]

abcd0x00:

Да базу данных можно хранить так, файловую систему, много чего.

0 в конце подразумевает линейный перебор в поисках конца.
В БД и файловой системы индексы используются, иначе они работают неприемлимо долго.
А при наличие индекса ноль в конце уже не нужен.

[redakoc]

abcd0x00:

Предлагаешь заморачиваться с подбиранием размера, а я вот просто сохраню строку с нуль-символом.
Пока ты будешь размеры подбирать, я уже полпрограммы напишу и буду чаёк попивать.

Все эти вещи давно уже в библиотеках да в компилятор встроены.

[redakoc]

abcd0x00:

Да я могу хоть каталог файлов так сохранить один за другим. Маркерная система - это обычная система, которую придумали ещё до C. В данном случае маркер конца данных - нуль-символ. У тебя нет таких навыков, поэтому все мысли только через размер данных идут.

А как ты там файлы искать будешь?
"Миллиард файлов длинной миллиард байтов", как ты выразился.
Сколько займет времени поиск, скажем, файла номер 500 001 из такой сплошной структуры.
В таких случаях используют каталог вложенных файлов, а где каталог - там и размеры.

[redakoc]

abcd0x00:

Конечно, проходить по всей строке с проверками на нуль-символ, - способ неправильный. Зато можно работать с данными напрямую, без заморочек с размером.

Нельзя.
При выполнении операции, нужно быть уверенным, что ты не выходишь за пределы выделенной под строку памяти.

Можно нарезать их прямо с середины. В любом месте можно встать и поставить начало внутренней строки (подстроки). Вот там есть пример в библиотеке - strtok() - когда строку можно нарезать на слова, сохраняя указатели на них. Можно и интереснее операции делать - ограничений нет. С размером этой возможности нет, там всё тупо и ограничено.

Как раз наборот, дурачок.
При разрезании строки твоим методом вставки нуля в середину - нужно СДВИГАТЬ всю последующую часть строки на один байт.
А вот наличие отдельной структуры, хранящей длины виртуально нарезанных строк позволяет разрезать строки без массовых ненужных перемещений в памяти.
)))
Тупачок, успехов в говнокоде.

[redakoc]

redakoc:

Зато можно работать с данными напрямую, без заморочек с размером. Можно нарезать их прямо с середины. В любом месте можно встать и поставить начало внутренней строки (подстроки).

1. Для чего придется сдвинуть ВПРАВО на 1 байт вторую получившуюся подстроку.
2. Единственное что можно сделать быстро - выделить первую подстроку. Методом Паскалевских строк что тоже делается так же.
3. Что вы будете делать с памятью выделенной под вторую часть строки.
4. Самый быстрый метод разрезания строк (без сдвигов) - гигантская (без 0) строка. И отдельный каталог, содержащий определения (адреса и размеры) виртуально порезанных подстрок.
А этот метод поближе все же именно к ПАСКАЛЕВСКИМ строкам.

Вот там есть пример в библиотеке - strtok() - когда строку можно нарезать на слова, сохраняя указатели на них. Можно и интереснее операции делать - ограничений нет. С размером этой возможности нет, там всё тупо и ограничено.

Методом добавления 0 разрезать строку на подстроки, сохраняя указатели на них, невозможно.
Так как уже вторая подстрока должна быть сдвинута на 1 байт вправо, третья подстрока на 2 байта вправо и т.д.

Если до вас не дошло, то сдвиг этот требуется, чтобы добавить 0.

Если этого не сделать, а оставить старый указатель, то или теряется один символ в первой строке (последний) или то вторая подстрока будет указывать ровно на 0, то есть станет пустой (и третья подстрока потеряет 1 символ из начала).

[abcd0x00]

redakoc:

0 в конце подразумевает линейный перебор в поисках конца.

То есть, по-твоему, кто сделал такие строки, - это просто дебилы. Один ты умник.
Да, оно подразумевает линейный перебор, и все это знают и всегда знали.

В БД и файловой системы индексы используются, иначе они работают неприемлимо долго.

Речь про хранение идёт. Ты предлагаешь хранить длину рядом с каждой строкой, потому что другого варианта нет.
То есть к индексами добавляется и длина эта.
Или ты ещё пуще пошёл и длину сохранил в индекс, чтобы ещё веселее было.

А при наличие индекса ноль в конце уже не нужен.

Да, походу, так и есть, ты предлагаешь индексировать на пустом месте. То есть жрать память попусту.

Все эти вещи давно уже в библиотеках да в компилятор встроены.

Какие вещи? Определение длины строки?

А как ты там файлы искать будешь?

По адресу в адресном пространстве.

В таких случаях используют каталог вложенных файлов, а где каталог - там и размеры.

А кто тебе сказал, что на любой файловой системе должен быть каталог?
Узлы должны быть, каталоги - если нужно только.

Нельзя.
При выполнении операции, нужно быть уверенным, что ты не выходишь за пределы выделенной под строку памяти.

Там же маркер в конце, забыл? Дурилка ты картонная.
Что ты хочешь сказать, что я не могу для строки правильно выделить память до сохранения?

Как раз наборот, дурачок.

Дурачок-то пока что ты здесь тут.

При разрезании строки твоим методом вставки нуля в середину - нужно СДВИГАТЬ всю последующую часть строки на один байт.

Епать, а strtok() что делает? Значит, ты просто не знаешь, как работает strtok(), раз такую ахинею пронёс.
Строка меняется, цель - получить подстроку.

А вот наличие отдельной структуры, хранящей длины виртуально нарезанных строк позволяет разрезать строки без массовых ненужных перемещений в памяти.

Позволяет, конечно, но нахрен нужны эти размеры в памяти? При нарезке на подстроки нужно просто расставить маркеры, а длина всего массива известна заранее. Потом эти подстроки ещё можно нарезать, никаких длин не надо знать.

4. Самый быстрый метод разрезания строк (без сдвигов) - гигантская (без 0) строка. И отдельный каталог, содержащий определения (адреса и размеры) виртуально порезанных подстрок.

В C делаешь структуру (указатель, длина), если нужно исходную строку сохранить. Если же это нафиг не надо, то просто нарезаешь её без всяких структур и заморочек с ними. А сдвиги, ну это ты сам придумал себе и героически победил у себя в голове.

Методом добавления 0 разрезать строку на подстроки, сохраняя указатели на них, невозможно.

Ну да, я понял, что ты пропёрся из-за своего тупого паскалевского мышления. Не в том смысле, что ты тупой, а в том, что Паскаль притупляет мышление и у паскалистов всё сводится к одному способу всегда, потому что язык большего не позволяет. В C же гибкость - обычное дело. Ты можешь и хранить длину, и не хранить длину.

Ты бы ещё подучился, как сайт работает. Ты когда пишешь по сто сообщений, мне приходит по сто уведомлений. Не будь столь расточительным, делай как я - сначала в редакторе набираешь, а потом отправляешь один раз.

[redakoc]

abcd0x00:

То есть, по-твоему, кто сделал такие строки, - это просто дебилы. Один ты умник.
Да, оно подразумевает линейный перебор, и все это знают и всегда знали.

Такие строки имеют один-единственный плюс - очень простое описание.

И именно поэтому строки, заканчивающиеся нулем, и их близкие родственники - строки, заканчивающиеся переводом строки (в двух вариациях Win и nix - там разные символы в конце), используются в межпрограммных взаимодействиях:

API, JSON, XML, HTTP и т.п.

Строки стиля Паскаль не удобны для этого. Попробуй запиши в файл 100 строк типа Паскаль и 100 строк заканчивающихся 0/CR/LF - и убедись что Паскалевские строки неудобны для чтения человеком, с границы строки С-стиля прекрасно видны невооруженным глазом.

Для работы со строками же внутри самой программы это смысла особого не имеет. Сейчас, когда в компиляторы и стандартные библиотеки встроены строки типа Паскаль и работа с ними проста и удобна. С С-строками приходится лишний раз думать а не забыл ли ты 0, а не вставил ли случайно 0 в середину строки. Работа со строками заканчивающимися 0 - это все больше старые библиотеки или те, что предусматривают взаимодействие с другими системами - например Windows API.

[redakoc]

abcd0x00:

Речь про хранение идёт. Ты предлагаешь хранить длину рядом с каждой строкой, потому что другого варианта нет.
То есть к индексами добавляется и длина эта.
Или ты ещё пуще пошёл и длину сохранил в индекс, чтобы ещё веселее было.

Если речь идет о настоящей базе данных или настоящей файловой системе - я предлагаю не глупить и вообще не хранить 0 в конце строки. Этот 0 и вреден для данных (нельзя без перекодировки хранить символ с кодом 0 в самих данных) и зря тратит место.

А для работы с БД и файлами все равно используются специализированные структуры: индексы и каталоги. Для простого обращения к произвольному элементу этих служебных структур очень многое построено на таблицах элементов фиксированной длины.

То, что ты предлагаешь - использовать 0 для разделения данных в БД - это годится только для древних ленточных устройств хранения. И, да, ты прав. Именно так это в БД и было. Лет 30 назад и более.

[redakoc]

abcd0x00:

Да, походу, так и есть, ты предлагаешь индексировать на пустом месте. То есть жрать память попусту.

А это как хочешь считай.

Но ВСЕ БД предполагают наличие служебных структур. И весьма жирных структур. Иначе пользоваться этими БД с нормальной скоростью попросту невозможно.

Если хочешь экономить место, то есть работа без индексов, есть динамическое построение индексов.... Все это есть.

Но СУБД, в которых данные никакими дополнительными полями не обслуживаются - таких не существует в природе.

[redakoc]

abcd0x00:

Какие вещи? Определение длины строки?

Все типовые операции со строками давным давно делаются элементарно и обслуживаются компиляторами и библиотеками.

Реализовывать такие вещи вручную и экономить каждый байт имеет смысли или:

на встраиваемых системах (причем не тех, что на ARM, а на микроконтроллерах попроще)
или когда пишешь специализированный софт, именно для работы со строками.

[redakoc]

redakoc:

А кто тебе сказал, что на любой файловой системе должен быть каталог?
Узлы должны быть, каталоги - если нужно только.

И аналог FAT - место то как распределять.
Обойтись без этого можно разве что в append-only файловых системах.

[redakoc]

abcd0x00:

Там же маркер в конце, забыл? Дурилка ты картонная.
Что ты хочешь сказать, что я не могу для строки правильно выделить память до сохранения?

Не тупи.
Оба вида строки - и типа С и типа Паскаль - существуют уже очень давно.
И на них прекрасно реализуются все виды применения.

Епать, а strtok() что делает? Значит, ты просто не знаешь, как работает strtok(), раз такую ахинею пронёс.
Строка меняется, цель - получить подстроку

Ты привел пример этой функции как пример для использования в крутячем алгоритме разрезания строки.
Признай - никакой он не крутячий, так как требует сдвига второй части.

[redakoc]

abcd0x00:

Позволяет, конечно, но нахрен нужны эти размеры в памяти? При нарезке на подстроки нужно просто расставить маркеры, а длина всего массива известна заранее. Потом эти подстроки ещё можно нарезать, никаких длин не надо знать.

Для того нужен, для чего ты называешь подходящим разрезание строк посередке нулем.
Это полный дебилизм.
Кроме времени на двиг строки тебе нужно еще и про распределение памяти на хвосте позаботиться.
Твой "простой" алгоритм - просто добавь 0 в середину - на практике неэффективен.

[redakoc]

abcd0x00:

В C делаешь структуру (указатель, длина), если нужно исходную строку сохранить. Если же это нафиг не надо, то просто нарезаешь её без всяких структур и заморочек с ними. А сдвиги, ну это ты сам придумал себе и героически победил у себя в голове.

Ну я всегда подозревал, что никакой рост производительности компьютеров не позволит компенсировать рост дебилизма говнокодеров. Компьютеры все мощнее и мощнее, а программы не столько пропорционально шустрее, как компьютеры.

Ведь даже программисты на сравнительно низкоуровневом С, оказывается, просто пользуются готовыми функциями и не понимают как это все на самом деле работает.

То есть ты даже НЕ ПОНИМАЕШЬ, что твой алгоритм нарезания строк вставкой 0 в середину подразумевает 2 операции, существенно снижающих производительность:

- сдвиг второй половины разрезанной строки вправо, чтобы освободить место для концевого нуля первой половины
и
- добавление памяти в конце второй половины (откуда ты будешь брать память под сдвигаемой конец строки, если изначально не позаботился кстати интересно)

[redakoc]

abcd0x00:

Ну да, я понял, что ты пропёрся из-за своего тупого паскалевского мышления. Не в том смысле, что ты тупой, а в том, что Паскаль притупляет мышление и у паскалистов всё сводится к одному способу всегда, потому что язык большего не позволяет. В C же гибкость - обычное дело. Ты можешь и хранить длину, и не хранить длину.

На Паскале сейчас никто не пишет почти.
Паскалевские строки давно вошли в других языки.

Будь добр, гений.
Приведи здесь пример своего кода, реализующего твой "эффективный простой безсдвиговый" алгоритм:

1. Есть 1 строка длины 10, завершающаяся 0. "abcdefghij".
2. Разрежь ее на 2 части методом вставки нуля в середину. получишь "abcde" "fghij" и 0 между ними.
3. Запомни положение (адреса) второй части строки в указателе IDIOT. Он будет указывать на строку "fghij"
4. А затем разрежь своим "эффективным" методом получившуюся ранее первую часть. Например, на "abc" "de"
5. И после этого, используя, ранее сохраненный указатель IDIOT, попытайся вывести строку.
Если все просто круто и фиксировано, ты просто разрезал и нет никаких лишних телодвижений - то у тебя должно получиться.
))))
То есть все три строки "abc", "de", "fghij" никуда не денутся.

P.S.:
Моя версия:
IDIOT будет указывать на строку длинной 0, то есть просто так разрезать строку и не потерять её по старому указателю не получится.
Если же указатель останется тем же и строка останется той же, то ты потеряешь что-то из символов "abcde".

[abcd0x00]

redakoc:

То есть ты даже НЕ ПОНИМАЕШЬ, что твой алгоритм нарезания строк вставкой 0 в середину подразумевает 2 операции, существенно снижающих производительность:

А я не буду их сдвигать.

Приведи здесь пример своего кода, реализующего твой "эффективный простой безсдвиговый" алгоритм:

А ты не врубаешься, что мне строка de нафиг не нужна?
Нужны только abc и ghi.
Вот подумай сам, как из этого получить эти две подстроки.
abcdefghij

Я ставлю два указателя (да, ты не знал, что можно два ставить) на a и g.
a + 3 = 0
g + 3 = 0
И всё. У меня теперь в этих указателях подстроки.
Какой Паскаль там.
А дальше я могу из них брать что? Правильно, я могу из них взять подстроки bc и gh.
А вот ты будешь на Паскале очень долго там лазить, потому что тебе надо будет всегда помнить всю эту строку, где у ней там что начинается, какого она там размера и всё время что-то высчитывать в численном виде, чтобы в этих подстрочных размерах не ошибиться.

[redakoc]

abcd0x00: ты не разрезал строку. ты разрезал и ОБРЕЗАЛ. ты потерял символы. твоим методом невозможно быстро (без сдвигов, оставляя неизменным ссылки на подстроки) разрезать строку.

[abcd0x00]

redakoc: я не терял символы, такие операции проводятся над копией строки либо строка уже использована и не нужна. Очень часто аргументы командной строки используют один раз за всё выполнение и вот их запросто так можно нарезать.

[redakoc]

abcd0x00:
Если ты проводишь над КОПИЕЙ то где твоя хваленая эффективность.

Аргументы командной строки это точно миллиард символов обрабатываемый миллиард раз. Хороший пример. ))) Командная строка уже много лет как прекрасно нарезается готовыми библиотеками, многие системы программирования умеют это и стандартными (не дополнительными) библиотеками.

Твои примеры на уровне задачек по программированию для школьников или студентов (первый год обучения программированию). В реальных задачах все по другому.

[abcd0x00]

redakoc:

Если ты проводишь над КОПИЕЙ то где твоя хваленая эффективность.

Так копия там ТОЛЬКО тогда, когда это необходимо.
В частности, при применении strtok(), которая вставляет нули вместо разделителей (ты бы хоть узнал, что это за функция, чтобы не спрашивать одно и то же по 500 раз), копия может и не создаваться.
Есть работа с копией, есть работа без копии.

Командная строка уже много лет как прекрасно нарезается готовыми библиотеками

Во-первых, это может быть непереносимо - когда для одной платформы есть библиотека, а для другой нет. А во-вторых, когда нужен свой способ обработки командной строки, отличающийся от общепринятых, то существующие реализации в этом не помогут. Но при этом по аргументам надо пройти не более одного раза.
Тот же пример - недавно вышел Go, в котором вообще своя библиотека со своим способом, которая отвергает POSIX, выдумывая что-то своё.

Твои примеры на уровне задачек по программированию для школьников или студентов

Ну, ты вообще никогда ничего не писал. Мышление, как у препода-теоретика обычного. Всё, что я тебе объясняю, я объясняю тебе потому, что ты этого не видишь. А не видишь, потому что не практикующий. В том же примере касаемо сети ты просто никогда не писал сетевых программ, иначе хорошо бы представлял протоколы, в которые паскалевские строки никак не вписываются. Там максимум похожее есть при передаче бинарных данных, но это не строки.

[redakoc]

Так копия там ТОЛЬКО тогда, когда это необходимо.

Копия на миллиард символов всегда неэффективно.
Напоминаю исходные нашей беседы: твой довод, что "миллиард нуль-терминированных строк длинной миллиард символов эффективнее строк, чей размер хранится".

[redakoc]

abcd0x00:

Во-первых, это может быть непереносимо - когда для одной платформы есть библиотека, а для другой нет.

Функция обрабатывающая строки непереносима между платформами?
Ты дурак?

[redakoc]

abcd0x00:

В том же примере касаемо сети ты просто никогда не писал сетевых программ, иначе хорошо бы представлял протоколы, в которые паскалевские строки никак не вписываютс

Не подмазывайся к моим умным мыслям. Если поглядеть по истории нашей беседы, то прекрасно видно, что это именно я рассказал тебе, что паскалевские строки неудобны в протоколах междупрограммного обмена.

[redakoc]

abcd0x00:

Во-первых, это может быть непереносимо - когда для одной платформы есть библиотека, а для другой нет. А во-вторых, когда нужен свой способ обработки командной строки, отличающийся от общепринятых, то существующие реализации в этом не помогут. Но при этом по аргументам надо пройти не более одного раза

1. Строковые функции чуть ли не первое, переносимостью которого озабочиваются разработчики. Нет там подобных проблем с встроенными (стандартными) и любыми серьезными библиотеками.

2. Опять задачка из школьного курса информатики.

У программистов есть такая профессиональная болезнь (ну вы то еще не знаете, что вы не уникальны, вы еще не начинали работать по специальности, не видели такого много раз) - хаять все чужое и выдумывать с нуля свой велосипед, вместо того, чтобы немного напрячься и изучить уже готовое стандартное решения. Функций для обработки параметров командной строки напридумано достаточно много, чтобы найти среди них готовую.

Веских причин, по которой разбирать параметры нужно уникальным очень быстрым самостоятельно написанным алгоримом не существует - так как время запуска нового процесса (программы) несопоставимо больше, чем время разбора командной строки.

Точнее причин существует ровно 2:
а) обучение программированию
б) неспособность реализовать что-то серьезное, которая выливается в вечное совершенствование примитивных алгоритмов и похвальбу этим. на этапе первых двух лет обучения программированию это еще понятно. но в 3-му году я бы ожидал о программиста, правильно выбравшего свою профессию, нечта большего.

[abcd0x00]

redakoc:

Напоминаю исходные нашей беседы: твой довод, что "миллиард нуль-терминированных строк длинной миллиард символов эффективнее строк, чей размер хранится".

Конечно эффективнее, при хранении это экономит 4 гигабайта. При чтении разница только в проверках. А что больше времени происходит, хранение или чтение? Естественно, хранение.
А на коротких строках, пример - "hello", нуль-терминированные эффективнее размерных, потому что размер не нужен вообще. А если размер не нужен, то и операции с размером тоже не нужны. Что ты предлагаешь, короткую строку в пять символов блочно выводить? Это что файл какой-то? Никто не юзает fwrite() для них.

Функция обрабатывающая строки непереносима между платформами?
Ты дурак?

Ну, я ж говорю, ты тупой. Есть непереносимые библиотеки. А функции - в библиотеках. Если программа линкуется с библиотекой, которой нет в другой операционной системе, это как называется? Речь же идёт о функциях разбора аргументов командной строки. Ты съехал просто, подменив их функциями для работы с любыми строками.

именно я рассказал тебе, что паскалевские строки неудобны в протоколах междупрограммного обмена

О чём ты говоришь, очень хорошо видно, что ты слово API пишешь слишком трепетно, как будто это что-то заоблачное. Значит, не разрабатывал собственные. Да и LF - целое достижение, ты ещё скажи, что знаешь наизусть код LF. Смешно просто.

Функций для обработки параметров командной строки напридумано достаточно много, чтобы найти среди них готовую.

Ну, вот в Go придумали свои, я тут Олежку пердуна валил, дал ему задание, он свинтил. Понтов было выше крыши. А почему? Потому что они нарушили POSIX и сказали "а вы просто нас не понимаете, это такая продвинутая реализация". Потому и надо там писать свой разборщик, хотя в библиотеке, поставляемой с компилятором, есть это их новаторское средство.

[redakoc]

Ну, я ж говорю, ты тупой. Есть непереносимые библиотеки. А функции - в библиотеках. Если программа линкуется с библиотекой, которой нет в другой операционной системе, это как называется? Речь же идёт о функциях разбора аргументов командной строки. Ты съехал просто, подменив их функциями для работы с любыми строками.

Различные функции (библиотеки) разбора командной строки чуть ли не самые распространенные по всем платформам. Причин выбирать редкую не переносимую и потом на нее жаловаться - не существует.

[redakoc]

Конечно эффективнее, при хранении это экономит 4 гигабайта. При чтении разница только в проверках. А что больше времени происходит, хранение или чтение? Естественно, хранение.

Все наоборот.

Миллиард строк длинной миллиард хранится на диске, а не в оперативной памяти.
На объеме хранения уже несколько десятилетий как не экономят байтики. Стоимость дисковой памяти ничтожна, скорость доступа к ней крайне мала.

И именно поэтому для хранения на диске используются различные хитрые дополнительные структуры, ускоряющие доступ, позволяющие обойтись без полного чтения миллиарда байт, если нужен только последний килобайт из миллиарда байт.

Исключением являются только архивные данные с последовательным чтением. Но для таких данных все равно используют контроль целостности данных, так что обойтись одним 0 на миллиард символов не получится.

[redakoc]

abcd0x00:

А на коротких строках, пример - "hello", нуль-терминированные эффективнее размерных, потому что размер не нужен вообще.

Это верно только для узкоспециализированных решений для работы именно со строками.

В решениях общего назначения, сюрприз, никого не волнует экономия отдельных байтов. Используются универсальные строки, не подбираются идеальные решения под короткие или длинные строки. Наоборот, в средства программирования (компиляторы и т.п.) встраиваются дополнительные проверки (реализуемые и за счет отдельных дополнительных байтиков), что позволяет ловить ошибки.

Это более полезно для создания современных сложных программ, чем экономия байтиков и отказ от дополнительных проверок и повышения рисков багов.

[redakoc]

abcd0x00:

Ну, вот в Go придумали свои, я тут Олежку пердуна валил, дал ему задание, он свинтил. Понтов было выше крыши. А почему? Потому что они нарушили POSIX и сказали "а вы просто нас не понимаете, это такая продвинутая реализация". Потому и надо там писать свой разборщик, хотя в библиотеке, поставляемой с компилятором, есть это их новаторское средство.

1. Ты о чем? Это же другой язык программирования. Не С, даром что похож. Какую ты тут совместимость хочешь?

2. Зачем? Ты как-то хотел использовать какую-то С-библиотеку для разбора параметров командной строки в Go? Но не знаешь как?

3. Пакет "flag" не обязателен, господин школьник. Параметры командной строки в C-подобном стиле берутся из os.Args

[redakoc]

4. А каким боком здесь про 0-терминированные строки? В Go встроенные строки - паскалеподобного типа.

[abcd0x00]

redakoc:

3. Пакет "flag" не обязателен, господин школьник. Параметры командной строки в C-подобном стиле берутся из os.Args

А зачем тогда этот пакет нужен? Он нарушает POSIX, который вырабатывался десятилетиями. И нарушает его, естественно, в далеко не лучшую сторону. Люди придумали нормальную, гибкую систему, эти взяли, своё что-то выдумали за пять минут, а потом лепят отмазки, что их просто не понимают.
Это пример того, как библиотека (пакет этот), не соблюдает стандарт.
То есть наличие какой-то библиотеки ещё ни о чём не говорит, хоть их сотни.
Ты в этом не разбираешься, потому что не пишешь ничего.

2. Зачем? Ты как-то хотел использовать какую-то С-библиотеку для разбора параметров командной строки в Go? Но не знаешь как?

Не соблюдает он POSIX, ты знаешь, что такое POSIX? Очень сомневаюсь.
Держу пари, ты сейчас с винды мне всё это пишешь.
У тебя мозгов не хватает объединить сообщения в одно. Так что это либо телефон, либо винда. На телефон у тебя денег нет (с преподской зарплатой такой возможности нет), остаётся одно.

1. Ты о чем? Это же другой язык программирования.

Другой, конечно. Но речь о библиотеках, а в нём они есть. При этом он современный, а не 20-летней давности.
Для тебя - если библиотека есть, то ею можно пользоваться. Так вот, это - теория. Большинство библиотек непригодно к использованию, а ясно это становится, когда начинаешь ими пользоваться. Для тебя же они все одинаковые, потому что ты не пользовался ими.

4. А каким боком здесь про 0-терминированные строки? В Go встроенные строки - паскалеподобного типа.

В Go строки вообще в виде структур вида (указатель, длина). То есть они там вообще высокоуровневые.
Да они и не заморачивались с производительностью, вообще много с чем там не заморачивались. Вот сейчас споры идут по поводу его качества.

Речь идёт о том, как оптимальнее использовать строки: по-паскалевски или по-сишному. Паскалевский вариант жрёт память, к тому же устаревает, так как размеры растут со временем, а в нём остаются старые размеры. А сишный вариант как был компактным, так и остался, даже с юникодом.

[redakoc]

abcd0x00:

А зачем тогда этот пакет нужен? Он нарушает POSIX, который вырабатывался десятилетиями. И нарушает его, естественно, в далеко не лучшую сторону. Люди придумали нормальную, гибкую систему, эти взяли, своё что-то выдумали за пять минут, а потом лепят отмазки, что их просто не понимают.

А вы предлагаете вообще не развиваться и жить на POSIX столетиями?
Go предлагает 2 варианта - в новом стиле и в старом, выбирай любой.

Неча перекладывать ответственность за собственную некомпетентность на хорошую систему.
Если тебя затрудняет выбор одной из двух готовых технологий, то ты и не программист вовсе.

[redakoc]

abcd0x00:

То есть наличие какой-то библиотеки ещё ни о чём не говорит, хоть их сотни.
Ты в этом не разбираешься, потому что не пишешь ничего.

Чего ради Go должен соблюдать POSIX для C?
Go - другой язык. Вас ввела в заблуждение его похожесть?

Go предлагает вам 2 встроенных в стандартную библиотеку варианта: POSIX-подобный и свой собственный flag.

Если вы не способны разобраться даже в стандартной библиотеке, то это повод идти в школу повышать квалификацию, а не хаять хорошую систему.

[redakoc]

abcd0x00:

Не соблюдает он POSIX, ты знаешь, что такое POSIX? Очень сомневаюсь.

Go соблюдает POSIX ровно настолько насколько авторы языка сочли нужным.
Go вовсе не C и не нужно от него этого ожидать на 100%.

Держу пари, ты сейчас с винды мне всё это пишешь.

С unix-подобного MacOS X. У которого с совместимостью POSIX все довольно хорошо.

У тебя мозгов не хватает объединить сообщения в одно. Так что это либо телефон, либо винда. На телефон у тебя денег нет (с преподской зарплатой такой возможности нет), остаётся одно.

Я не преподаватель. ))))
Я разработчик со ставкой 50-60 долларов в час.

[redakoc]

abcd0x00:

Другой, конечно. Но речь о библиотеках, а в нём они есть. При этом он современный, а не 20-летней давности.
Для тебя - если библиотека есть, то ею можно пользоваться. Так вот, это - теория. Большинство библиотек непригодно к использованию, а ясно это становится, когда начинаешь ими пользоваться. Для тебя же они все одинаковые, потому что ты не пользовался ими.

А чем я пользовался, чтобы писать программы?

[redakoc]

abcd0x00:

В Go строки вообще в виде структур вида (указатель, длина). То есть они там вообще высокоуровневые.

Именно это и означает паскалеподобные строки.

Да они и не заморачивались с производительностью, вообще много с чем там не заморачивались. Вот сейчас споры идут по поводу его качества.

Пусть спорят дальше. А он мне приносит 5000-7000 долларов ежемесячно.

[redakoc]

abcd0x00:

Речь идёт о том, как оптимальнее использовать строки: по-паскалевски или по-сишному. Паскалевский вариант жрёт память, к тому же устаревает, так как размеры растут со временем, а в нём остаются старые размеры. А сишный вариант как был компактным, так и остался, даже с юникодом.

Это никому не надо, кроме как во встраиваемых устройствах, куда даже операционную систему засунуть невозможно.
Даже в смартфонах никто не заморачивается на копеечной экономии, не говоря уже о полноценных компьютерах.

[abcd0x00]

redakoc:

Go предлагает 2 варианта - в новом стиле и в старом, выбирай любой.

Ничего он не предлагает. Он предлагает либо их вариант непродуманный и нарушающий POSIX, либо написание своего варианта с нуля. Ну, и нахрен мне на это тратить время? Мне что больше заняться нечем? Сейчас времена не те, чтобы всё писать заново.

Чего ради Go должен соблюдать POSIX для C?

Так он претендует на роль "обновлённого C", а по сути они там только каналы хорошо сделали. Всё остальное - недоделки, которые они отмазками замазывают (ну, не они, а Пайк в основном).

Если вы не способны разобраться даже в стандартной библиотеке

Я тебе просто задание сейчас дам там реализовать, и ты со своей ставкой спокойненько сольёшься. Думаешь, Олежка идиот? Так зажевал, как миленький. То он Go прославлял, а потом не смог сделать элементарного на нём. Ну, можешь, конечно, отмазки кушать и про ошибки, и про шаблоны с дженериками. Но там кроме каналов нет нихрена.

Go соблюдает POSIX ровно настолько насколько авторы языка сочли нужным.

Не, там по-другому устроено: у них просто не хватает времени на всё, а выпускать язык нужно было поскорее, к тому же они это всё под эгидой Google делают, поэтому там вообще бизнес всё это подгоняет. А когда бизнес руководить начинает, то начинают выпускать фуфло наскоряк, чтобы захватывать рынки и прочее - реализовывать бизнес-интересы.

Именно это и означает паскалеподобные строки.

Да куда там. Да и строки там в символах идут, а символы совсем не байты расходуют. То есть там вообще нет заморочек с тем, как хранить строки, поэтому и за эталон это нельзя принимать.

А он мне приносит 5000-7000 долларов ежемесячно.

А что ты написал? У тебя же ничего нет. У того же Олежки хотя бы книжка есть, одна штука. У тебя же - нихрена, ни того, ни другого. Вон Линус работает, написал Git, весь мир пользуется и бесплатно причём. В общем, что ты произвёл? Твои 250-долларовые заработки никому не интересны.

Это никому не надо, кроме как во встраиваемых устройствах

Всё компактно должно быть. Ты, кстати, сразу видно, не собирал проект на Go. Там же всё в один бинарник засовывается, тоже типа решили поумничать и проигнорировать сложившиеся правила. Ну, и представь себе утилиту ping и утилиту cat. Представил да? две утилитки, каждая по 1.5 мегабайта. А теперь представь сто утилит. То есть получается, что ты должен всё либо в монолитном проекте держать, либо просто впустую тратить место на жёстком диске. И выбора у тебя нет.
А теперь задумайся, почему люди выбирают Git. Наверное, потому что он очень компактный и экономный, а потому и быстрый. Вот тебе и разница.

Answer 3

[abcd0x00]

Нуль-символ обозначает конец строки. То есть строку можно читать, посимвольно смещаясь вправо, пока не встретится конец. Таким образом её длину хранить не нужно.
А теперь представь строку на миллиард символов. Для такой строки затраты на хранение её длины остаются теми же - один байт в котором записан нуль-символ.
А вот если бы длина строки хранилась в переменной, то нужно было бы следить за размером этой переменной, потому что на слишком длинных строках числовое значение длины не помещалось бы в переменную.
Ты думаешь, почему Дельфи такой медленный язык (программа The Bat! работает медленно), потому что там этого нет, из-за чего происходит множество лишних вычислений.

Comments

[Александр Ручкин]

строке на миллиард символов достаточно 4 байт для записи размера
если мало, можно взять 8
по сравнению с миллиардом - мелочь
зато, чтобы вычислить длину строки - надо пройти её от начала и до конца

[Станислав Макаров]

Александр Ручкин да это видимо троллинг такой) Давно такой жести на Тостере не читал.

[Станислав Макаров]

Хорошее чтиво: queue.acm.org/detail.cfm?id=2010365

[Dmitriy Mozgovoy]

=) На скорость это мало влияет, смотря какие операции- иногда даже быстрее будет. Да и в дельфах там оба типа строк неплохо были представлены, по этому только говорить что его компилятор генирит там такой медленный да или жирный код нельзя. Если код там и получался медленный, или жирный, то потому как исторически там много школо-программеров...

[abcd0x00]

Александр Ручкин:

строке на миллиард символов достаточно 4 байт для записи размера
если мало, можно взять 8

Ну, а теперь представь миллиард строк по миллиарду символов, где для каждой строки нужно не только место под размер занимать, но и выполнять операции по вычислению размера.
8 байт - это слишком много, это в восемь раз больше чем 1.

зато, чтобы вычислить длину строки - надо пройти её от начала и до конца

Да можешь отдельно себе сделать структуру без всякого нуль-символа и хранить там всё.
Но когда ты через printf() или cout<< выводишь "hello", то слишком жирно для этого hello выделять 8 байт.

Станислав Макаров:

Хорошее чтиво:

Вот он пишет:
"To a lot of people, C is a dead language"
"When your Java, Python, Ruby, or Haskell program opens a file"
Ты нашёл что читать.
https://en.wikipedia.org/wiki/Poul-Henning_Kamp

[Александр Ручкин]

abcd0x00: И что, в 8⋅10⁹ вдруг станет велико по отношению к 10¹⁸? Кто хранит строки миллиардного размера в C-string literals? И как вот именно это связано с производительностью Delphi?

[Станислав Макаров]

abcd0x00
> 8 байт - это слишком много, это в восемь раз больше чем 1.
Ой, да ладно вам, у вас одно выравнивание структур больше жрать будет.
> Вот он пишет:
> "To a lot of people, C is a dead language"
А вы читайте по теме вопроса. Я вам предлагаю его точку зрения на Си-строки, а не предлагаю записываться к нему в ученики. Хотя чел наверняка поумнее, чем большая часть Тостера.

[asd111]

Дельфи программы тормозят из за того что компилятор плохо оптимизирует по сравнению с современными компиляторами С++. Если в С++ отключить оптимизации, то программа будет работать раза в 1.5 медленнее или даже хуже в зависимости от алгоритма.

[abcd0x00]

Станислав Макаров: этот чел за всю свою прискорбную жизнь не сделал и сотой части того, что сделали те, кого он там критикует. Что он реализовал, md5 и кое-что ещё? Это такие мелочи по сравнению с языком, который преодолел 40 лет, сохранившись в первозданном виде (отменили только gets() ).

asd111:

Дельфи программы тормозят

Они не только тормозят, но и весят слишком много. Это не из-за оптимизаций, а потому что он спроектирован так, чтобы особо не заморачиваться в плане ресурсов окружения.

[abcd0x00]

Александр Ручкин:

Кто хранит строки миллиардного размера в C-string literals?

Так можно хранить их в памяти преспокойно. Главное, чтобы оно в size_t помещалось, так как strlen() требует не больше size_t.

Ты можешь взять файл, сохранить его в память (выделенную) и занулить его в конце - и всё.

[Александр Ручкин]

abcd0x00: файл в конце занулить? это только для текстового сработает, но зачем? тот же std::string вполне себе хранит размер

[Станислав Макаров]

abcd0x00 > Главное, чтобы оно в size_t помещалось, так как strlen() требует не больше size_t
Ну этот же size_t и поместите в качестве первого байта. Почему вы не говорите, что возвращаемый strlen результат "слишком большой"? Потому что чаще будет на стеке в кач. локальной переменной, а не в куче?

[redakoc]

А теперь представь строку на миллиард символов. Для такой строки затраты на хранение её длины остаются теми же - один байт в котором записан нуль-символ.

А для строки типа Pascal затраты на хранение длины составляют на 3 байта больше.
Ты серьезно считаешь это недостатком, если общая длина строки составляет 1 миллиард байт?????
))))

А вот если бы длина строки хранилась в переменной, то нужно было бы следить за размером этой переменной, потому что на слишком длинных строках числовое значение длины не помещалось бы в переменную.

За этим компилятор следит.
А на длинных строках операция проверки заранее известной длины занимает меньше времени, чем операция поиска конца строки.
Преимущество по скорости строк, заканчивающихся нулем как раз на очень маленьких строках. Очень. Например, на строках длиной 3 символа.

Ты думаешь, почему Дельфи такой медленный язык (программа The Bat! работает медленно), потому что там этого нет, из-за чего происходит множество лишних вычислений.

То есть ты считаешь, что перебор строки в поисках концевого нуля - это быстрее?????

Как раз на строках длинной миллиард более целесообразно хранить полную длину строки отдельно. Тогда для того, чтобы её узнать (а это нужно для очень и очень многих операций), будет затрачено НАМНОГО МЕНЬШЕ времени чем перебор миллиарда байтов в поисках конечного 0.

Дельфи прекрасно умеет работать со строками, заканчивающимися 0. Если не память не изменяет такие строки там называются PChar.

Торможение TheBat!, да и другой программы подобной сложности, вызвано вовсе использованием строк того или иного типа. А общей неэффективностью алгоритмов более высокого уровня, построенных поверх строк. Подобная программа, будучи написанной на C# или C++ или Go или Rust тормозила бы примерно так же. Не буду говорить про Python, Ruby и т.п., но при сравнении Delphi vs C++ - косяк всегда не в языке, косяк прежде всего в самом программисте.

P.S.:
На каком компьютере TheBat! тормозит? На Pentium-I, II, III?
Если тормозит на современном, то попробуй переиндексировать базу данных писем.
Или разбить письма по чуть большему количеству папок.
Косяк к этом, а не в типе строк.

[Станислав Макаров]

@abcd0x00
> Это не из-за оптимизаций, а потому что он спроектирован так, чтобы особо не заморачиваться в плане ресурсов окружения.
Я думал так говорят про JS ну или про C# в крайнем случае). А там даже ручного управления памятью не боялись.

[redakoc]

abcd0x00:

Ну, а теперь представь миллиард строк по миллиарду символов, где для каждой строки нужно не только место под размер занимать, но и выполнять операции по вычислению размера.

Для того, чтобы внятно работать с миллиардом строк, каждая из которых длинной в миллиард, тебе понадобится не просто 1 байт в конце строки, а и отдельные индексы.
))))

[redakoc]

abcd0x00:

Они не только тормозят, но и весят слишком много. Это не из-за оптимизаций, а потому что он спроектирован так, чтобы особо не заморачиваться в плане ресурсов окружения.

То что тормозят и требуют специального Runtime программы на C# не напрягает?
Кому сейчас нужна такая оптимизация по объему и скорости?
Сейчас, напротив, в языки встраиваются дополнительные проверки, чтобы программистовские ошибки ловить.

[Станислав Макаров]

abcd0x00
> этот чел за всю свою прискорбную жизнь не сделал и сотой части того, что сделали те, кого он там критикует
Простите, но это фанатизм и непрофессиональные аргументы. У любого серьезного инженера/ученого есть не самые удачные решения, на которые было потрачено меньше времени, чем на другие, или в которых не были учтены какие-то важные факторы. Рано или поздно нужно иметь смелость пересмотреть старые решения, особенно в связи с изменением конъюктуры (например, с удешевлением байта оперативной памяти на несколько порядков), а не бездумно молиться на них до скончания веков.

Я вам сразу сказал - меня не особо интересуют остальные достижения этого человека, читайте по теме. Вы отказываетесь это делать. Видимо вам не хватает опыта и знаний, чтобы самому принять решение в данной ситуации, раз вы начали расставлять авторитеты.

[redakoc]

abcd0x00:

Да можешь отдельно себе сделать структуру без всякого нуль-символа и хранить там всё.
Но когда ты через printf() или cout<< выводишь "hello", то слишком жирно для этого hello выделять 8 байт.

1. Кого это волнует, когда даже на смартфонах сейчас норма более 1 Г оперативки?
2. Кто мешает динамически подбирать нужное количество байтов для хранения длины?
3. Скажите, а вас не напрягает, что программа состоящая из cout << "hello" должна по уму занимать не более 100 байт? А сколько (в разы больше) она на деле занимает?

[abcd0x00]

Александр Ручкин:

тот же std::string вполне себе хранит размер

std::string - это надстройка над строками C, а сейчас как раз речь про них.
Чистая строка C не занимает в памяти ничего, кроме себя, и не требует операций.

Станислав Макаров:

Ну этот же size_t и поместите в качестве первого байта. Почему вы не говорите, что возвращаемый strlen результат "слишком большой"?

Потому что он никак не используется, когда используется строка. Только когда ты хочешь получить длину строки, это имеет значение, но для операций со строкой (чтения/записи) её длина не нужна.
Но даже он не ограничен 4-мя гигабайтами, потому что я привёл размерность, распространённую сегодня. Но size_t может быть и 64-битным и более-битным.
Если же ещё секретнее говорить, то строки можно и длиннее size_t хранить, просто тогда нельзя strlen() вызывать для них.
В этом мощь C, это не Паскаль какой-то там.

redakoc:

А для строки типа Pascal затраты на хранение длины составляют на 3 байта больше.

Речь-то идёт не только об этих затратах памяти, речь идёт об операциях, которые потом используют этот размер повсеместно по 100500 раз, потому что всё сделано потом с учётом этого размера. Просто прочитать до нуль-символа такую строку нельзя.

А на длинных строках операция проверки заранее известной длины занимает меньше времени, чем операция поиска конца строки.

И что она даёт, эта ненужная проверка длины, когда не нужна длина?
Я передаю строку в функцию - передаётся адрес начала. Я так могу передавать много раз, при этом передаётся только адрес начала.
А тут как минимум надо передать адрес И ДЛИНУ.
Умножаем на миллиард - получаем общее замедление.

То есть ты считаешь, что перебор строки в поисках концевого нуля - это быстрее?????

Передача быстрее.

Если не память не изменяет такие строки там называются PChar.

Да, никто не работает с ними, нужно вспоминать. Да и что под них приспособлено там, когда везде используются размерные строки?

Торможение TheBat!, да и другой программы подобной сложности, вызвано вовсе использованием строк того или иного типа. А общей неэффективностью алгоритмов более высокого уровня, построенных поверх строк.

Не, не обязательно строки (там ещё много чего интересного есть), но строки туда тоже вносят свой вклад.

На каком компьютере TheBat! тормозит? На Pentium-I, II, III?

Я тебе из памяти пишу, я уже не юзаю её давно. У меня своя прога, плюс Emacs есть, если что подробнее делать.

То что тормозят и требуют специального Runtime программы на C# не напрягает?

Я не юзаю это непереносимое, привязывающее к винде, ну и медленное к тому же.
Речь о C, даже не о C++.

Станислав Макаров:

Я вам сразу сказал - меня не особо интересуют остальные достижения этого человека

Ну, потому ты и читаешь его. Ты ещё кого-нибудь почитай. Такого материала в интернете тонны. Когда человек не может писать программы, он начинает писать статьи. Это известная тема.

[redakoc]

abcd0x00:

Речь-то идёт не только об этих затратах памяти, речь идёт об операциях, которые потом используют этот размер повсеместно по 100500 раз, потому что всё сделано потом с учётом этого размера. Просто прочитать до нуль-символа такую строку нельзя.

Просто прочитать длину строки (1-2-4 байта)
Просто найти конец строки 0 в строке "hello, world" = прочитать 15 байт, дурачина.

[redakoc]

abcd0x00:

И что она даёт, эта ненужная проверка длины, когда не нужна длина?

Длина строки (или другим способом определить ее окончание) нужна в подавляющем большинстве случаев:

Чтение строки,
Сложение строк (там то же чтение внутри),
Вставка в середину (чтобы быть уверенным что не выходишь за пределы строки),
Поиск в строке,
Проверка длины строки (довольно частая операция).

Если при каких то этих операция тебе не нужно знать конца строки, то ты просто уже знаешь ее длину косвенно.

Можно обойтись только при создании новой строки.

Я передаю строку в функцию - передаётся адрес начала. Я так могу передавать много раз, при этом передаётся только адрес начала.
А тут как минимум надо передать адрес И ДЛИНУ.

Не надо. В Паскале также передается ТОЛЬКО адрес начала.

Умножаем на миллиард - получаем общее замедление.

На передаче строк разницы нет вообще, так как передается все тот же указатель.

[redakoc]

abcd0x00:

Да и что под них приспособлено там, когда везде используются размерные строки?

Взаимодействие с ОС. Вызовы API.

[abcd0x00]

redakoc:

Просто прочитать длину строки (1-2-4 байта)
Просто найти конец строки 0 в строке "hello, world" = прочитать 15 байт, дурачина.

И когда ты прочитал длину строки, ты радостный остался с этим знанием длины, а строку читать не стал?
Проталкиваешь фуфло. Ты точно так же будешь читать свою строку.

Длина строки (или другим способом определить ее окончание) нужна в подавляющем большинстве случаев:

Читать/писать надо строку в подавляющем большинстве случаев.

Вставка в середину (чтобы быть уверенным что не выходишь за пределы строки),

Вставка - не такая уж частая операция. Но длину можно узнать ОДИН раз, а потом сто раз использовать, а не хранить её ВСЕГДА рядом, занимая память под это.

Поиск в строке,

Что поиск в строке? Поиск с конца только различается, если по маркеру или по известной длине сравнивать.

Не надо. В Паскале также передается ТОЛЬКО адрес начала.

Ну, достижение, значит. Это огромный плюс, что он передаёт только адрес (ссылку), а потом 100500 раз читает размер.

[redakoc]

abcd0x00:

Вставка - не такая уж частая операция. Но длину можно узнать ОДИН раз, а потом сто раз использовать, а не хранить её ВСЕГДА рядом, занимая память под это.

1. Кого это волнует в наше время? Вон вы замахиваетесь на строки длинной в миллиард символов? Сколько нужно байт на этот миллиард для хранения длинны?

2. Если вам нужно ОДИН раз УЗНАТЬ, но чтобы 100 раз ИСПОЛЬЗОВАТЬ, то все равно нужно ХРАНИТЬ то, что вы уже узнали. Так зачем же тратить время на перебор миллиарда символов, если можно просто сразу хранить.

Ну, достижение, значит. Это огромный плюс, что он передаёт только адрес (ссылку), а потом 100500 раз читает размер.

Так всегда было, какой достижение? Сдается мне ваши познания про то какие бывают строки ограничены весьма маленьким мирком.

1. Программа с строками С-стиля тоже 100500 раз читает размер, если это ей надо по алгоритму. Только в качестве дополнительных накладных расходов добавляется еще то, что этот размер нужно подсчитать еще.
2. Программа с строками стиля Паскаль, если ей по алгоритму этого не нужно, может прекрасно также НЕ ЧИТАТЬ уже определенную длину.

[abcd0x00]

redakoc:

2. Если вам нужно ОДИН раз УЗНАТЬ, но чтобы 100 раз ИСПОЛЬЗОВАТЬ, то все равно нужно ХРАНИТЬ то, что вы уже узнали.

Я могу хранить это, пока это нужно. А когда это не нужно, я могу это удалить и сохранить туда что-нибудь другое. Так что это не одно и то же. Оно может и вообще мне не понадобиться. А у тебя оно будет всегда читать эту длину, потому что без неё нельзя понять, где строка заканчивается. И читать ты будешь по четыре байта всегда.

Ты, кстати, забыл ещё одну вещь. Чем сложнее данные, тем они хуже. То есть нуль-терминированные строки легко передавать, потому что одна строка заканчивается тогда, когда встречается ноль. А ты свои как будешь передавать. Сначала ты будешь должен сообщить, чему равна длина размера, а на той стороне надо будет это помнить. А чтобы сообщить длину размера, надо будет ещё сообщить её эндианство, это если ты случайно забыл, как там оно всё устроено. То есть сериализовать объекты с нуль-терминированными строками гораздо проще, чем эту всю супер-умную систему.

2. Программа с строками стиля Паскаль, если ей по алгоритму этого не нужно, может прекрасно также НЕ ЧИТАТЬ уже определенную длину.

Но хранить-то она его будет, и с каждой строкой, а строк - миллиард. То есть четыре гигабайта уйдёт только на размеры. Так что ты просто не видишь всей картины. За деревьями не видишь леса.

[redakoc]

abcd0x00:

То есть нуль-терминированные строки легко передавать, потому что одна строка заканчивается тогда, когда встречается ноль. А ты свои как будешь передавать. Сначала ты будешь должен сообщить, чему равна длина размера, а на той стороне надо будет это помнить.

Я тут буквально вчера написал, что терминированные строки (0, CR, LF) потому и используются в межпрограммных взаимодействиях, что это удобно.
Ты мои слова повторяешь - не более, сам не способен.

[abcd0x00]

redakoc: не, я просто прочитал это первее того, так как у тебя по двадцать ответов каждый раз и они в почте перемешиваются. CR и LF из другой оперы, текстовый файл ты с ними не сохранишь в память, а с нуль-символом сохранишь, потому что нуль-символ - бинарная тема. А если надо бинарник в памяти сохранять, то там уже размер используется. Так вот можно посчитать сколько сохраняется текстовых файлов и сколько бинарников. Тот же html весь текстовый.

[redakoc]

abcd0x00: Суть одна и та же - строки заканчивающиеся терминатором (неважно каким) удобны для чтения, просты для обмена информацией между различными системами. Потому они и живы.
Для работы внутри программы удобнее строки с известными размерами.

[abcd0x00]

redakoc:

Потому они и живы.

Они простые, потому и живы. Если бы они были сложные, то не смогли бы преодолеть 40-летний рубеж и язык бы умер вместе с ними, как произошло с Паскалем.

[redakoc]

abcd0x00:
Кто умер? Иди в школу.
Строки типа Паскаль сейчас основные в современных языках программирования.
С-подобные строки остались в межпрограммном обмене (только там они и удобнее, чем паскалевские строки) и исторически внутри того же С, к примеру.

Answer 4

[asd111]

одна буква может иметь тип char или w_char
char - одна буква в кодировке ASCII занимает один байт
w_char - одна буква в кодировке UTF-16, занимает 2 байта
\0 - символ конца строки, используется для того чтобы printf и т.п. функции знали где заканчивается область памяти отведенная под строку.

const char *name = "name"; - символ конца строки поставит сам компилятор и длина строки будет не 4 байта, а 5, но при этом strlen должен возвращать длину до \0 т.е. 4 байта, хотя на самом деле хранится 5 байт

Примерно так. Другими словами если нужна строка, то нужно делать на 1 байт больше.
В этом плане проще использовать С++ std::string, std::wstring или Qstring

Answer 5

[Tsiren Naimanov]

char - это 1 символ
string - это строка + её длина