Зачем использовать c строки в С++?

Ответ 1

Единственные причины, по которым я должен был их использовать, - это взаимодействие с сторонними библиотеками, использующими строки стиля C. Также могут возникать эзотерические ситуации, когда вы должны использовать строки стиля C по причинам производительности, но чаще всего использование методов на строках С++, вероятно, происходит быстрее из-за вложения и специализации и т.д.

Во многих случаях при работе с этими API-интерфейсами можно использовать метод c_str(), но вы должны знать, что char * return is const, и вы не должны изменять строку с помощью этого указателя. В таких ситуациях вы все равно можете использовать вектор <char> вместо этого, и, по крайней мере, получить более легкое управление памятью.

Ответ 2

Еще несколько заметок памяти:

Строки C представляют собой типы POD, поэтому их можно выделить в сегменте данных только для чтения. Если вы объявляете и определяете константы std::string в области пространства имен, компилятор будет генерировать дополнительный код, который выполняется до main(), который вызывает конструктор std::string для каждой константы. Если ваше приложение имеет много постоянных строк (например, если вы создали код С++, который использует константные строки), в этой ситуации могут быть предпочтительны строки C.

Некоторые реализации std::string поддерживают функцию SSO ( "оптимизация коротких строк" ​​или "оптимизация небольших строк" ), где класс std::string содержит хранилище для строк до определенной длины. Это увеличивает размер std::string, но часто значительно уменьшает частоту распределения/освобождения свободного хранилища, повышая производительность. Если ваша реализация std::string не поддерживает SSO, то при создании пустого std::string в стеке будет выполняться распределение свободного хранилища. Если это так, использование временных строк, связанных с стеком, может оказаться полезным для критически важного кода, который использует строки. Конечно, вы должны быть осторожны, чтобы не стрелять себе в ногу, когда вы это делаете.

Ответ 3

Потому что, как они поступают из многочисленных API/библиотек?

Ответ 4

Скажем, у вас есть некоторые строковые константы в вашем коде, что является довольно распространенной потребностью. Лучше определить их как строки C, чем как объекты С++ - более легкие, портативные и т.д. Теперь, если вы собираетесь передавать эти строки различным функциям, хорошо, если эти функции принимают строку C вместо того, чтобы требовать Строковый объект С++.

Конечно, если строки изменяемы, то гораздо удобнее использовать строковые объекты С++.

Ответ 5

Управление памятью. Недавно мне пришлось обрабатывать строки (фактически капли из базы данных) размером около 200-300 МБ в многопоточном приложении. Это была ситуация, когда одна-единственная копия строки могла сломать 32-битное адресное пространство. Я должен был точно знать, сколько копий строки существует. Хотя я евангелист STL, я использовал char *, потому что он дал мне гарантию того, что дополнительная память или даже дополнительная копия не были выделены. Я точно знал, сколько места ему понадобится.

Кроме того, стандартная строковая обработка STL пропускает некоторые отличные функции C для обработки/обработки строк. К счастью, std::string имеет метод c_str() для доступа const во внутренний буфер. Чтобы использовать printf(), вам все равно придется использовать char * (какая сумасшедшая идея команды С++ не включать в себя функции printf-like, одну из самых полезных функций EVER на C. Я надеюсь, что boost:: формат скоро будет включен в STL.

Ответ 6

Если код С++ является "глубоким" (близко к ядру, сильно зависящему от библиотек C и т.д.), вы можете явно использовать строки C, чтобы избежать большого количества преобразований в и из std::string. Если вы взаимодействуете с другими языковыми доменами (Python, Ruby и т.д.), Вы можете сделать это по той же причине. В противном случае используйте std::string.

Ответ 7

Если для функции требуется строка константа, я по-прежнему предпочитаю использовать 'const char *' (или const wchar_t *), даже если программа использует std::string, CString, EString или что-то другое.

Слишком много источников строк в большой базе кода, чтобы убедиться, что вызывающая сторона будет иметь строку как std::string и 'const char *' - самый низкий общий знаменатель.

Ответ 8

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

Если вы потратите гораздо больше времени на отладку плохих char * кодов и утечек памяти, я предлагаю, чтобы все нестатические строки были каким-то типом строкового объекта... пока профилирование не покажет, что вы можете и должны сделать что-то лучше; -)

Ответ 9

Учитывая выбор, обычно нет причин выбирать примитивные строки C (char*) над строками С++ (std::string). Однако часто у вас нет роскоши выбора. Например, конструкторы std::fstream берут C строк по историческим причинам. Кроме того, библиотеки C (вы уже догадались!) Используют строки C.

В вашем собственном С++-коде лучше всего использовать std::string и извлечь строку C-объекта по мере необходимости с помощью функции c_str() функции std::string.

Ответ 10

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

Ответ 11

Это зависит от используемых вами библиотек. Например, при работе с MFC часто проще использовать CString при работе с различными частями Windows API. Он также работает лучше, чем std::string в приложениях Win32.

Однако std::string является частью стандарта С++, поэтому, если вы хотите улучшить переносимость, перейдите к std::string.

Ответ 12

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

Ответ 13

c не несут накладных расходов на класс.

c обычно могут привести к более быстрому коду, поскольку они ближе к уровню машины

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

Существует огромное количество вызовов, которые требуются по историческим причинам.

Научитесь использовать строки c и stl строки и использовать каждый, когда имеет смысл это сделать.

Ответ 14

В некоторых сообщениях упоминаются проблемы с памятью. Это может быть хорошей причиной избегать std::string, но char *, вероятно, не самая лучшая замена. Это все еще язык OO. Ваш собственный класс строк, вероятно, лучше, чем char *. Это может быть даже более эффективно - например, вы можете применить Оптимизацию небольших строк.

В моем случае я пытался получить строки размером 1 ГБ из 2-Гбайт файла, набивать их в записях около 60 полями, а затем сортировать их в 7 раз из разных полей. Мой код предшественников занял 25 часов с char *, мой код работал через 1 час.

Ответ 15

1) "строковая константа" - это строка C (const char *), преобразующая ее в const std::string & это процесс выполнения, не обязательно простой или оптимизированный. 2) Библиотека fstream использует строки c-style для передачи имен файлов.

Мое правило состоит в том, чтобы передать const std::string & если я собираюсь использовать данные как std::string в любом случае (скажем, когда я их храню в векторе) и const char * в других случаях.

Ответ 16

Устаревший код, который не знает std::string. Кроме того, перед открытием С++ 11 открытие файлов с помощью std:: ifstream или std:: ofstream возможно только при условии, что const char * является входом в имя файла.

Ответ 17

Строки STL, безусловно, намного проще в использовании, и я не вижу причин их не использовать.

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

Ответ 18

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