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

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

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

Быстрее в каких алгоритмах? В какой-то книжке один из создателей C/Unix провел сравнение
программ, написанных на разных языках,
генерирующих текст с претензией на осмысленность, после анализа какой-либо книжки,

Когда я ее читал, лет 5-6 назад, если переписать C++ без std::string и STL алгоритмов,
то все начинало работать в 2 раза быстрее, но это было давно,
и если считать программу падающую или текущую как работающую бесконечно много,
то std::string в бесконечно много раз быстрее.

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

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

С чего бы вдруг низкоуровневые функции были бы быстрее?
Кстати, они не низкоуровневые. Это просто старые функции с тех времен,
когда ничего другого не было.
Сравни то, что тебе дает STL с тем, как бы добился такой же
функциональности со старыми функциями.
Только после этого сравнивай скорости.

Ну, к примеру, с std::string ты имеешь строки переменной длины.
Что надо сделать со старыми функциями, чтобы достичь такого же удобства и надежности?

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

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

Думаю если оверхед какой-то и есть то мизерный.

В Философии сейчас похожая тема обсуждается:

Скорость работы с использованием классов и без

Автор: Kokoban
Дата: 03.08.06

Вот любопытная ссылка оттуда:

http://www.open-std.org/jtc1/sc22/wg21/docs/18015.html

А>Мне до сих пор по наивности казалось, что работа с более низкоуровневыми функциями должна быть быстрее...
Вообще по секрету скажу что имплементация всяких find'ов и прочее у них одинаковая (хотя вобщем то может зависеть от версии STL и CRT, но все давно вылизано). алгоритм у std::string::find такой же как н strstr, но благодаря тому что std::string::find шаблонная функция компилятор ее может компилять как захочет, а юзая strstr ты как правило просто линкуешься на уже готовую функцию из CRT, которая была скомпилена компилером тех времен + оверхед на cdecl.

Да еще добавлю. std::basic_string хранит в себе begin и end из чего длина строки вычисляется одним вычитанием, а char * — только begin, а end и длину он находит каждый когда надо вызывая strlen и перебирая все символы строки до нулевого. Потому некоторые алгоритмы быстрее на std::string.

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

Важнее понимать, что std::string — динамическая строка, которая использует собственный механизм реаллокации памяти, зависящий в конечном счете от реализации STL. Например, он может работать через один глобальный мьютекс и частая реаллокация строк в многопоточном приложении может сильно замедлить работу.

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

А>Мне до сих пор по наивности казалось, что работа с более низкоуровневыми функциями должна быть быстрее...
Мое сугубо-личное ИМХО таково: поскольку std::string хранит в себе длину строки, а длину обычной строки приходится вычислять банальным сканированием, то многие операции (типа конкатенации) с std::string делаются действительно быстрее. НО! есть одно существенное но, из-за которого лично я std::string практически не использую. Это — необходимость передавать API-функциям именно C-строки! Вот здесь (при преобразовании C-строки в std::string и обратно коснтруктором std::string(const char*) И методом c_str() соответственно) весь выигрыш от скорости операций с "чистыми std::string" в лучшем случае сводится на нет, а реально получаете нехилый проигрыш. Так что пока вы держитесь "чистых std::string" без необходимости их передачи в WinAPI функции — смело используйте std::string — производительность скорее всего окажется выше. Обогнать на низкоуровневых функциях в данном случае можно, только если вести грамотную политику выделения памяти, а именно на предстоящую серию конкатенаций выделить достаточный буфер, а строки копировать в соотв. позицию целевого буфера. Но это уже несопоставимо по трудозатратам и вряд ли овчинка будет стоить выделки (хотя случаи разные бывают).
Но если планируется эти строки интенсивно передавать WinAPI функциям — нафиг std::string! Используйте массивы символов и низкоуровневые функции. И по скорости выиграете и проблем будет меньше.
Все выше сказанное является моим личным ИМХО. Но оно имеет место быть.

Ээээ.. А чем тебя беспокоят API функции? В большинстве реализаций c_str() просто либо внутренний поинтер на данные строки если она не пустая. Если пустая — то выдает указатель на глобальную статическую переменную char zzz[]=""; , Тут никакого проигрыша
При присвоениии аналогично — происходит просто копирование данных в строку, если копируемая строка короче имеющегося буфере — подгоняется end а capacity буфера остается большой.

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

А>Ээээ.. А чем тебя беспокоят API функции?
Да сами API функции меня не больно беспокоят. Беспокоит необходимость преобразований C-строк в std::string .
А>В большинстве реализаций c_str() просто либо внутренний поинтер на данные строки если она не пустая. Если пустая — то выдает указатель на глобальную статическую переменную char zzz[]=""; , Тут никакого проигрыша
А ты случайно c CString не перепутал? Насколько я знаю, внутренние данные строки не содержат завершающего 0. Но даже если ты и прав, глобально это сути дела не меняет.
А>При присвоениии аналогично — происходит просто копирование данных в строку, если копируемая строка короче имеющегося буфере — подгоняется end а capacity буфера остается большой.
Ну да: просто подсчет длины, просто копирование... Какие мелочи! А ведь при работе с C-строками этого можно было не делать (до определенного момента конечно). За это и не люблю. В результате получается, что такие вещи, как получить директорию, пристыковать к ней имя файла и вызвать что-то типа CreateFile без std::string получится дешевле, чем с ними.

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

А>>Мне до сих пор по наивности казалось, что работа с более низкоуровневыми функциями должна быть быстрее...
P>есть одно существенное но, из-за которого лично я std::string практически не использую. Это — необходимость передавать API-функциям именно C-строки!

С API-функциями замечательно работает std::vector<char> и std::vector<wchar_t>.

C>С API-функциями замечательно работает std::vector<char> и std::vector<wchar_t>.

Это если нужно передать строку как out(in,out) параметр. Для in-параметров и c_str() замечательно работает.

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

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

Она может быть быстрее в выполнении, но уж точно не быстрее во времени разработки. А к проблемам производительности std::string можно отнести, в первую очередь, лишние временные объекты и привязанность к одной конкретной policy. Т. е. строка или простая, или COW, или std::deque<char>, или еще какое извращение. Строки же char * лишены этих недостатков за счет того, что сами по себе не умеют ничего вообще, и потому девелопер должен писать что-нть свое, но тогда уже он напишет прогу, идеально подходящую к его конкретной задаче. Говорят, будто ни одна реализация СУБД не использует std::string, равно не используют они char *, а пишут свои классы под свои требования.

Recommended Googling: Shlemiel the Painter's Algorithm

programmater wrote:

> момента конечно). За это и не люблю. В результате получается, что такие
> вещи, как получить директорию, пристыковать к ней имя файла и вызвать
> что-то типа CreateFile без std::string получится дешевле, чем с ними.
Не понял, почему дешевле? Операции += и reserve никто не отменял.