Статья:
Строки в С и С++

Автор(ы): Сергей Аристов
Дата: 28.12.2003
Это первая часть, в которой обсуждаются «традиционные» строки в С. В С++ существуют более удобные механизмы для работы со строковыми данными, эти механизмы рассматриваются во второй части статьи. А зачем вообще обсуждать неудобные С-строки, если есть С++? К сожалению, совсем забыть о строках в стиле С нельзя по двум причинам:
1. существует большое библиотек (например, API операционных систем) работающих именно с С-строками
2. строковые классы в С++ все равно основаны на традиционных С-строках, и если мы хотим разобраться в том, как они работают, нам придется понимать их основы.

Авторы:
Сергей Аристов

Аннотация:
Это первая часть, в которой обсуждаются «традиционные» строки в С. В С++ существуют более удобные механизмы для работы со строковыми данными, эти механизмы рассматриваются во второй части статьи. А зачем вообще обсуждать неудобные С-строки, если есть С++? К сожалению, совсем забыть о строках в стиле С нельзя по двум причинам:
1. существует большое библиотек (например, API операционных систем) работающих именно с С-строками
2. строковые классы в С++ все равно основаны на традиционных С-строках, и если мы хотим разобраться в том, как они работают, нам придется понимать их основы.

Здравствуйте, Сергей Аристов, Вы писали:

СА>Статья:


СА>Авторы:
СА> Сергей Аристов

СА>Аннотация:
СА>Это первая часть, в которой обсуждаются «традиционные» строки в С. В С++ существуют более удобные механизмы для работы со строковыми данными, эти механизмы рассматриваются во второй части статьи. А зачем вообще обсуждать неудобные С-строки, если есть С++? К сожалению, совсем забыть о строках в стиле С нельзя по двум причинам:
СА>1. существует большое библиотек (например, API операционных систем) работающих именно с С-строками
СА>2. строковые классы в С++ все равно основаны на традиционных С-строках, и если мы хотим разобраться в том, как они работают, нам придется понимать их основы.

Чегото мельчают статьи — смылс написания данной статьи для меня остается загадкой.
нет чтобы действительно чтото интересное написать чего нет в литературе или на русском не издавалось
а про строки в любой книжке по C++ написано

LF>Чегото мельчают статьи — смылс написания данной статьи для меня остается загадкой.
LF>нет чтобы действительно чтото интересное написать чего нет в литературе или на русском не издавалось
LF>а про строки в любой книжке по C++ написано


я тоже заметил какую моду сейчас на это. уже не первая статья про c++ строки попадается за последний месяц.

Здравствуйте, LaFlour, Вы писали:

L> Чегото мельчают статьи — смылс написания данной статьи для меня остается
L> загадкой. нет чтобы действительно чтото интересное написать чего нет в
L> литературе или на русском не издавалось а про строки в любой книжке по
L> C++ написано

Согласен. Предупреждение "Не забывайте пользоваться правильными функциями!" вообще философски звучит...

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

-- Всего хорошего!
-- Alex Alexandrov, e-mail: alex_alexandrov@fromru.com

Здравствуйте, LaFlour, Вы писали:

LF>Здравствуйте, Сергей Аристов, Вы писали:

СА>>Статья:

В данном фрагменте
for (i=0;i<strlen(str);i++) {
// работа со строкой, не изменяющая ее длину
}

str — это const char*. Компилятор сможет заменить вызовы strlen(str) на константу?

Здравствуйте, alexandrov_alex, Вы писали:
_> А то получается — статья ради статьи...
имхо статья ради баллов

LF>>Здравствуйте, Сергей Аристов, Вы писали:

СА>>>Статья:

А>В данном фрагменте
А>for (i=0;i<strlen(str);i++) {
А> // работа со строкой, не изменяющая ее длину
А>}

А>str — это const char*. Компилятор сможет заменить вызовы strlen(str) на константу?

а на каком основании?

Здравствуйте, dad, Вы писали:


LF>>>Здравствуйте, Сергей Аристов, Вы писали:

СА>>>>Статья:

А>>В данном фрагменте
А>>for (i=0;i<strlen(str);i++) {
А>> // работа со строкой, не изменяющая ее длину
А>>}

А>>str — это const char*. Компилятор сможет заменить вызовы strlen(str) на константу?

dad>а на каком основании?

Хотя srt и указатель, но все же const. Компилятор 1 раз вычисляет strlen(str) и оптимизирует цикл, заменяя вызов
strlen(str) на уже вычисленную в общем-то константу?

Здравствуйте, Сергей Аристов, Вы писали:

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

Помните, как в C устроены строки: они представляют собой последовательность байтов, и последний байт всегда содержит особое значение 0. Это порождает два очевидных следствия:

1.. Единственый способ определить, где строка кончается (то есть узнать её длину) — это пройти по ней в поисках нулевого байта в самом конце.
2.. Строка не может содержать нулевые байты. Так что хранить произвольные двоичные данные вроде картинки в формате JPEG в строке нельзя.
Почему строки в языке C так работают? А потому что микропроцессор PDP-7, на котором разрабатывались UNIX и C, имел такой строковый тип ASCIZ. ASCIZ означало "ASCII с нулём (zero) на конце."

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

Хотя, это тоже субъектив...

-- Всего хорошего!
-- Alex Alexandrov, e-mail: alex_alexandrov@fromru.com

Здравствуйте, Аноним, Вы писали:

> Здравствуйте, dad, Вы писали:
>
LF>>>> Здравствуйте, Сергей Аристов, Вы писали:
>
СА>>>>> Статья:
>
А>>> В данном фрагменте
А>>> for (i=0;i<strlen(str);i++) {
А>>> // работа со строкой, не изменяющая ее длину
А>>> }
>
А>>> str — это const char*. Компилятор сможет заменить вызовы strlen(str)
А>>> на константу?
>
dad>> а на каком основании?
>
> Хотя srt и указатель, но все же const. Компилятор 1 раз вычисляет
> strlen(str) и оптимизирует цикл, заменяя вызов strlen(str) на уже
> вычисленную в общем-то константу?

Компилятор не имеет права делать предположений о функциональности strlen. Может, у нее побочные эффекты есть? Вызывать он ее должен каждый раз.

-- Всего хорошего!
-- Alex Alexandrov, e-mail: alex_alexandrov@fromru.com

А>>>str — это const char*. Компилятор сможет заменить вызовы strlen(str) на константу?

dad>>а на каком основании?

А>Хотя srt и указатель, но все же const. Компилятор 1 раз вычисляет strlen(str) и оптимизирует цикл, заменяя вызов
А>strlen(str) на уже вычисленную в общем-то константу?

весьма логично, но не понятно с чего бы это компилятору догадываться, что возвращаемое
значение зависит только от передаваемогьо значения?
другое дело — это требования к for стандартом — толи один раз вычисляется условие толи
каждую итерацию ?

Здравствуйте, dad, Вы писали:


А>>>>str — это const char*. Компилятор сможет заменить вызовы strlen(str) на константу?

dad>>>а на каком основании?

А>>Хотя srt и указатель, но все же const. Компилятор 1 раз вычисляет strlen(str) и оптимизирует цикл, заменяя вызов
А>>strlen(str) на уже вычисленную в общем-то константу?

dad>весьма логично, но не понятно с чего бы это компилятору догадываться, что возвращаемое
dad>значение зависит только от передаваемогьо значения?
dad>другое дело — это требования к for стандартом — толи один раз вычисляется условие толи
dad>каждую итерацию ?

Имелась в виду именно strlen, а не какая-либо функция вообще.

Здравствуйте, Аноним, Вы писали:

> Имелась в виду именно strlen, а не какая-либо функция вообще.

А чего в ней есть такого неземного? Чем она отличается от прочего разнообразия функций?

-- Всего хорошего!
-- Alex Alexandrov, e-mail: alex_alexandrov@fromru.com

А>Имелась в виду именно strlen, а не какая-либо функция вообще.

так это бибилотечная функция а не языковая конструкция. компилятор "неприделах"

_>По поводу достоинств и недостатков сишного подхода к хранению строк рекомендую посмотреть вот это. Все это, как обычно, обусловлено исторической необходимостью, а вовсе не целесообразностью. В частности:

_>

_>Хотя, это тоже субъектив...


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

кстати, не встречал бибилотеки ориентированной на паскалевские строки? в winapi например некоторые ункции требуют нулевой байт с диной строки. чудеса короче.

Здравствуйте, Вы писали:

> В данном фрагменте
>

 > for (i=0;i<strlen(str);i++) {
 >     // работа со строкой, не изменяющая ее длину
 > }
 >

> str — это const char*. Компилятор сможет заменить вызовы strlen(str)
> на константу?

const char* str или char* str — значения не имеет, т.к. в любой вызываемой
функции может быть сделан const_cast. Но если строка была создана
константной (т.е. это литерал или массив const char) и компилятору об этом
"известно" в точке использования, то он вполне имеет право "расчитывать" на то,
что попыток изменить строку не будет.

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

Более того, если транслятор "умеет" анализировать функции, определенные в разных
единицах трансляции, он вполне может делать подобные фокусы и с функциями,
определенными пользователем — во всяком случае стандарт ему этого не запрещает.

Здравствуйте, dad, Вы писали:

А>>Хотя srt и указатель, но все же const. Компилятор 1 раз вычисляет strlen(str) и оптимизирует цикл, заменяя вызов
А>>strlen(str) на уже вычисленную в общем-то константу?

dad>весьма логично, но не понятно с чего бы это компилятору догадываться, что возвращаемое
dad>значение зависит только от передаваемогьо значения?

Ну это уже второй вопрос — как он догадается. Может быть он тока перед этим strlen компилировал, тогда он просто мог проставить флаг — результат этой функции зависит только от передаваемого значения. Другое дело, что большинство компиляторов такой оптимизацией не занимаются.

Здравствуйте, LaFlour, Вы писали:

L> Чегото мельчают статьи — смылс написания данной статьи для меня остается
L> загадкой.

Статьи разные нужны, статьи разные важны Так или иначе, РСДН посещает
значительное количество начинающих, которые высказываются за то, чтобы на РСДН
были статьи самого различного уровня. Эта статья, очевидно, ориентирована на
начинающих. Если она окажется кому-нибудь полезной — замечательно; если нет —
ничего страшного. Таким образом, в худшем случае данная статья может остаться
невостребованной. А в лучшем — поможет какому-нибудь новичку разобраться со
строками. Что же в этом плохого?

L> нет чтобы действительно чтото интересное написать чего нет в литературе
L> или на русском не издавалось а про строки в любой книжке по C++ написано

Присылайте ваши работы по адресу: — мы с удовольствием
опубликуем их на сайте или — в зависимости от уровня статьи — в журнале
RSDN Magazine.

ты прямо как пророк каждый раз новые истины открываешь.

ПК>Если компилятор может наверняка "убедиться", что строка не изменяется и
ПК>содержимое строки или ее длина ему уже "известны", он вполне может заменить вызов
ПК>стандартной функции strlen на соответствующее значение. Ничто
ПК>не запрещает компилятору использовать информацию о семантике стандартных функций
ПК>для оптимизации.

Разве стандарты на библиотеку коррелируются со стандартами на язык вцелом?
Т.е. гипотетически можно разработать некую библиотеку "проллобировать" ее в комитете и ее семантика будет учитываться разработчиками компилятора?
таким образом стандартная бибилотке становится "частью" языка. т.е. функцию strlen можно рассматривать как языковую конмтрукцию, а не бибилотечную ?

ПК>Более того, если транслятор "умеет" анализировать функции, определенные в разных
ПК>единицах трансляции, он вполне может делать подобные фокусы и с функциями,
ПК>определенными пользователем — во всяком случае стандарт ему этого не запрещает.

а что он может "анализировать" ? например, если возвращаемая значение зависит от текущего времени ?

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

Здравствуйте, dad, Вы писали:

ПК>> Ничто не запрещает компилятору использовать информацию о семантике
ПК>> стандартных функций для оптимизации.

d> Разве стандарты на библиотеку коррелируются со стандартами на язык вцелом?

Стандартные библиотеки C и C++ описываются в тех же самых документах,
что и сами языки.

d> Т.е. гипотетически можно разработать некую библиотеку "проллобировать" ее
d> в комитете и ее семантика будет учитываться разработчиками компилятора?

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

d> таким образом стандартная бибилотке становится "частью" языка. т.е. функцию
d> strlen можно рассматривать как языковую конмтрукцию, а не бибилотечную ?

С некоторыми допущениями. В частности, взять адрес strlen можно.

ПК>> Более того, если транслятор "умеет" анализировать функции, определенные
ПК>> в разных единицах трансляции, он вполне может делать подобные фокусы и
ПК>> с функциями, определенными пользователем — во всяком случае стандарт ему
ПК>> этого не запрещает.

d> а что он может "анализировать" ? например, если возвращаемая значение
d> зависит от текущего времени ?

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

d> хотя, это очень интересно. т.е. на данный момент это усложняет
d> программирование на c++ так как делает написание портируемого кода очень
d> трудоемким

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