Чистота кода

Возьмите fmtlib и не трахайтесь со своими лисапедами.

В целом - негативно, но иногда это оправдано.

В большинстве случаев вылизывания кода с точки зрения перформанса C и C++ функции стандартной библиотеки щедро перемешиваются вместе. В случае использования сторонних библиотек очень часто бывает читабельнее использовать <сstring> вместо алгоритмов. new/delete обычно не используется в пользу malloc/realloc/free (в первую очередь из-за realloc). А так обе библиотеки достаточно убоги в плане функциональности и поддержки интероперабельности с остальным зоопарком библиотек.

Ну и лучший в мире std::string - это стековый char[] или std::array для эстетов. Если думать про производительность.

буст обычно ещё быстрее

в первую очередь из-за realloc

а какой смысл realloc? он же принципиально от vector::resize не отличается.

ну, кроме того, что работу vector::resize вы можете контролировать из вашей прикладной программы, а внутренюю работу системных механизмов, стоящих (?, стандарт не гарантирует) - за realloc — нет.

лучший в мире std::string - QString

Там в итоге не в это упёрлось, скорость я победил, упёрся в память после этого.

sscanf - дешево и грязно.

па-ра-па-па-пам.

vector::resize - это new, copy, delete; realloc - это или malloc/copy/free или просто увеличение менеджером памяти размера буфера, если память за выделенным уже куском свободна и размер её достаточен.

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

а сейчас у я пользуюсь обёртками над malloc/free, которые позволяют передавать память между структурами. а то, что все куски выделены единообразно, позволяет освобождать память через free() и не париться. количество аллокаций памяти минимальны, и париться с абстракцией new/delete (где нет гарантий) не хочется.

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

так что всё это очень зависит от ситуации. но там, где хочется производительности, там места std::vector и всяким там std::string обычно нет. достаточно посмотреть на STL алгоритмы - отличный стиль того, как можно работать со всем вместе без оверхеда из-за того, что контейнеры светятся в API.

Для коммерческого программирования - может быть. Если там внутри есть поддержка юникода нормальная (а не как в std::string - неизвестно что с .c_str() как самой полезной функцией)

И да - у меня лично в коде на C++ все входные параметры типа «строка» - это строго пара (const) char * / std::size_t. в редких случаях - просто (const) char *. Такой вот std::string_view для бедных. И точно никаких std::string и прочей ереси. Выхлоп C функции без лишнего копирования передать будет невозможно в последнем случае.

нормальной поддержки юникода нет нигде. буквально.

наверное. поэтому идеальный std::string ещё не написан. ну или написан велосипедным методом у каждого на своём проекте :)

malloc/copy/free

new, copy, delete

ну и? для free ещё обёртки нужны, чтобы вызов деструктора был автоматически

полной поддержки юникода и в других языках нет

все обёртки уже написаны.

а realloc - это оптимистично только инкремент размера занятой памяти в недрах менеджера памяти и никакого копирования. и vector::resize ещё конструктор по умолчанию ещё вызывает - не всегда это бывает нужно. и на каждый push() проверяет нужно ли делать расширение буфера. как там это оптимизируется конкретным компилятором и реализацией stl - проследить невозможно. а с malloc и голым указателем (точнее, С++ной тонкой обёрткой над указателем) всё под контролем, во благо или во вред.

Кое-где есть хотя бы гарантия что базовый набор символов - это ASCII. На C и C++ и этой гарантии нет. А если вдумчиво кодить, то это вызывает серьёзные проблемы и лишние телодвижения. К тому же, базовые наборы символов времени компиляции и времени выполнения могут отличаться - и это просто непреодолимая проблема. Единственный способ на C++11 - это u8"xxxx" в коде (никаких 'x', «xxxx», L"xxxx", L'x') и постоянные перекодирования в системную кодировку времени выполнения.

Это говнокод на c++.

Что называть «полной поддержкой»?

Эксперты, что скажите про strcmp?

Байтоёбство.

работа с полной таблицей символов utf8, последней версии стандарта,

получение через [] или аналогичнй операции очередного символа, а не байта

На C и C++ и этой гарантии нет.

кто вам это сказал? ещё как есть. там разные ф-ции вроде isdigit isblank и подобных только с ASCII и работают

К тому же, базовые наборы символов времени компиляции и времени выполнения могут отличаться - и это просто непреодолимая проблема. Единственный способ на C++11 - это u8"xxxx" в коде (никаких 'x', «xxxx», L"xxxx", L'x') и постоянные перекодирования в системную кодировку времени выполнения.

по другому и не сделать

У тебя проблема с дизайном.

Говнокод.

Для коммерческого программирования - может быть.

Не только коммерческого. Qt распространяется на условиях LGPL (но желающие спать спокойно могут купить коммерческую версию).

Если там внутри есть поддержка юникода нормальная

Да, внутри QString по определению полноценный юникод. Плюс куча кодеков в разные кодировки и обратно из коробки - ну и функции преобразования в std::string и wstring до кучи.

В STL же что-то похожее на изкоробочное перекодирование начало появляться только в последних стандартах.

получение через [] или аналогичнй операции очередного символа, а не байта

В QtCore так и сделано.

И да - у меня лично в коде на C++ все входные параметры типа «строка» - это строго пара (const) char * / std::size_t. в редких случаях - просто (const) char *. Такой вот std::string_view для бедных.

Вот читаю и удивляюсь: ну такой умный, ну столько велосипедов сами сделали, как же вы до простейшего аналога этого самого string_view не додумались и продолжаете ходить по старым С-шным граблям (в виде независимой пары ptr+size)? Как так-то?

Или там у вас и остальные лиспапеды трехколесные?

*scan* никто не любит и не без причины

если код с iostreams сделать на питоне, будет быстрее, лол

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

В Rust есть гарантия что строки содержат только корректный utf8 и можно свободно итерировать по scalar value.

Go умеет итерировать по code point, но там строка может содержать любой набор байт, так что гарантий меньше.

Это было ДЗ от openedu (зарегался посмотреть, что за платформа). Ради интереса взял курс по алгоритмам. ДЗ заливается одним файлом, на их стороне компилируется и гоняются тесты, один из тестов был как раз на то, чтобы уложиться по времени и по памяти. Суть в том, что нужна была именно сортировка вставками, каждый шаг сортировки в определённом формате выводится в файл, оно это проверяет, в том числе по шагам смотрит, действительно это алгоритм сортировки вставками, или ты такой хитрец и заменил его на quick sort, чтобы по времени уложиться. Вывод этих шагов в файл занимает значительную часть времени.

Вот ты не в том месте и ускорял. Если у тебя узкое место - iostream, значит ты много его дергаешь.

Если их не лепят прямо в код, а заворачивают в объект, то норм. А так вообще и за cin >> myVar можно смело давать по морде, если это не хеловорд.

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

Ок, как сравнить две сишные строки?

Сишные строки в плюсах - говнокод.

C++ в варианте Qt...

мне кажется какой-то неизвестный автор книги «Qt для чайников» очень сильно травмировал на все левое полушарие большое количество школьников, самое страшное что их уже не вылечить :)

Вкус блюда в основном зависит от повара. Хороший повар из набора любых продуктов может вкусно и безопасно накормить.

Вкусного супа тебе из тараканов.

у меня cat(ну почти он, только ввод-вывод как интов) с переводом на stdio.h замедлился на 40%, ЧЯДНТ?

получение через [] или аналогичнй операции очередного символа

Вопрос в том, что считать символом.

мне кажется какой-то неизвестный автор книги «Qt для чайников» очень сильно травмировал на все левое полушарие большое количество школьников

Нет, всё проще, просто авторы Qt сделали то, чем могла бы стать STL - с гораздо меньшим обмазыванием шаблонной магией, но с гораздо большим количеством классов, из коробки пригодных для прикладных задач. (Хотя надо признать, что начиная с C++11, STL-классы становятся намного приятнее, чем были.)

то, что в стандарте юникод написано, то и считать

говорят, где-то в Азии, едят тараканов

В Rust есть гарантия что строки содержат только корректный utf8

именно utf8, или, как обычно, UCS-2? во многих языках и системах (винда, например) несмотря на формально задекларированный юникод, всего лишь поддерживается UCS-2

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

Go умеет итерировать по code point, но там строка может содержать любой набор байт, так что гарантий меньше.

эталонный вариант неполной поддержки юникода

Сомневаюсь, что тех самых.

Мне это сказал стандарт языка или томик Страуструпа - точно не помню. isdigit - это интерфейс. Там нет привязок к кодовой таблице. А среди известных есть EBCDIC, которая несовместима с ASCII.

Все лисапеды исключительно убогие и нужны только мне.