Как должен выглядеть интерфейс приема строк?

Question

Это продолжение this question. Предположим, что я пишу интерфейс C++, который принимает или возвращает строку const. Я могу использовать константный символ * завершается нулем строку:

void f(const char* str); // (1) 

Другой способ будет использовать зЬй :: строка:

void f(const string& str); // (2) 

Также можно написать перегрузку и принять как:

void f(const char* str); // (3) 
void f(const string& str); 

Или даже шаблон в сочетании с усилением строковых алгоритмов:

template<class Range> void f(const Range& str); // (4) 

Мои мысли:

• (1) не C++ иш и могут быть менее эффективными, когда последующие операции необходимо знать длину строки.
• (2) Плохо, потому что теперь f("long very long C string"); вызывает конструкцию std :: string, которая включает выделение кучи. Если f использует эту строку, чтобы передать ее на какой-то низкоуровневый интерфейс, который ожидает C-строку (например, fopen), то это просто пустая трата ресурсов.
• (3) вызывает дублирование кода. Хотя один f может вызывать другой в зависимости от того, что является наиболее эффективной реализацией. Однако мы не можем перегружать на основе типа возврата, как в случае std :: exception :: what(), который возвращает const char *.
• (4) не работает с отдельной компиляцией и может привести к еще большему раздуванию кода.
• Выбор между (1) и (2), основанный на том, что необходимо для реализации, - это утечка детализации реализации в интерфейс.

Вопрос в следующем: какой предпочтительный способ? Есть ли какая-то одна рекомендация, которой я могу следовать? Каков ваш опыт?

Edit: Существует также пятый вариант:

void f(boost::iterator_range<const char*> str); // (5) 

, который имеет плюсы из (1) (не нужно построить объект строки) и (2) (от размера строка явно передается функции).

Answer 1

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

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

Только если я на самом деле хотел использовать const особенности интерфейса std::string внутри функции бы я в самом интерфейсе const std::string&, и я не уверен, что только с помощью size() было бы достаточно для оправдания.

Во многих проектах, к лучшему или к худшему, часто используются альтернативные классы строк. Многие из них, например std::string, дают дешевый доступ к нулевому концу const char*; для преобразования в std::string требуется копия. Требование const std::string& в интерфейсе диктует стратегию хранения, даже если внутренним функциям функции не нужно указывать это. Я считаю, что это нежелательно, так как принятие const shared_ptr<X>& диктует стратегию хранения, тогда как принятие X&, по возможности, позволяет вызывающему пользователю использовать любую стратегию хранения для переданного объекта.

Недостатки const char* заключаются в том, что чисто с точки зрения интерфейса он не применяет ненулевое значение (хотя в некоторых интерфейсах иногда используется разница между пустым и пустым строками, это не может делаться с std::string), а const char* может быть адресом только одного символа. На практике, однако, использование const char* для передачи строки настолько распространено, что я считаю, что считать это отрицательным как довольно тривиальную проблему. Другие проблемы, такие как кодирование символов, указанных в документации на интерфейс (применяется как к std::string, так и к const char*), гораздо важнее и, вероятно, вызовет большую работу.

Answer 2

Если вы имеете дело с чистой базой кода на C++, я бы пошел с №2 и не беспокоился о вызывающих функции, которые не используют ее с std :: string, пока не возникнет проблема. Как всегда, не беспокойтесь о оптимизации, если не возникнет проблема. Сделайте свой код чистым, легким для чтения и легко расширяемым.

Answer 3

Существует одна рекомендация, которой вы можете следовать: используйте (2), если у вас нет очень веских причин.

A const char* str как параметр не делает его явным, какие операции разрешены для выполнения на str. Как часто он может быть увеличен до его segfaults? Является ли это указателем на char, массив char s или строку C (то есть массив с нулевым завершением char)?

Answer 4

Также можно написать перегрузки и принимают как:

void f(const string& str) уже принимает как из-за неявное преобразование из const char* в std::string. Так что # 3 имеет небольшое преимущество перед # 2.

Answer 5

Ответ должен зависеть от того, что вы намерены делать в f. Если вам нужно выполнить сложную обработку со строкой, подход 2 имеет смысл, если вам просто нужно перейти к некоторым другим функциям, затем выберите на основе этих других функций (скажем, для аргументов, ради которых вы открываете файл - что бы больше всего смысла?;))

Answer 6

Я бы выбрал void f(const string& str) если функция тела не делает char -анализ; означает, что это не относится к char* от str.

Answer 7

Использование (2).

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

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

(2) ясно сообщает, что функция принимает, и имеет право ограничения.

Конечно, все 5 являются улучшениями над foo(char*), с которыми я столкнулся больше, чем хотелось бы упомянуть.

Answer 8

У меня нет особого предпочтения. В зависимости от обстоятельств я чередуюсь с большинством ваших примеров.

Другого варианта я иногда использую похож на ваш Range пример, но используя обычный старый итератор диапазоны:

template <typename Iter> 
void f(Iter first, Iter last); 

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

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

void f(const char* first, const char* last); 

Опять же, это может быть тривиально используется как с C-строками, так и с C++ std::string (как я помню, C++ 03 явно не требует, чтобы строки были смежными, но каждая реализация, которую я знаю, использует смежно выделенные строки, и я считаю, что C++ 0x будет явно требовать Это).

Таким образом, эти версии позволяют мне передавать больше информации, чем простой параметр C-style const char* (который теряет информацию о длине строки и не обрабатывает внедренные нули) в дополнение к поддержке обоих основных типов строк (и, возможно, любой другой класс строк, о котором вы можете думать) идиоматическим способом.

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

К сожалению, обработка строк не является самой сильной стороной C++, поэтому я не думаю, что существует один «лучший» подход. Но пара итераторов является одним из нескольких подходов, которые я обычно использую.