Чистота кода

Работает и есть не просит - пусть работает.

Если что-то ломает, то можно и поправить.

Оверхед от конвертации [u8] в char.

В C/C++ вообще боль от кодировки сорцов. Поэтому никто не хранит не latin1 в сорцах. В современных языках таких проблем нет.

всё не так просто. этот текст - такой пример.

всё не так просто. этот текст - такой пример.

на сервере Java - модная, стильная, юникодная. а выше - две «одинаковые» строки. И полностью одинаковые семантически.

А что придёт во время сабмита какой-нибудь формочки на модную жаву - кто ж его там знает.

Их куча либ юзает.

Ты уверен что эти либы нужны в плюсах и для них нету нормальной обертки? В конце концов, обычно ты отвечаещь за выделение памяти, потому - std::vector как минимум.

совершенно верно. но так-то, и ASCII поддерживает такие фичи

«u\b_n\b_d\b_e\b_r\b» == under

правда, ни разу не видел, чтобы кто-то их использовал

u8 символ в 1-байтовый char не сконвертится. или вы о чём?

В C/C++ вообще боль от кодировки сорцов. Поэтому никто не хранит не latin1 в сорцах

как там, в 1993? доллары покупай

ГЫ!! В индокитае и не такое умеют.

За выделение const char* тоже?

// ура не нужно

нормально. но вообще есть скоростная библиотека ввода-вывода. работает иногда даже быстрее стандартной: http://www.fastformat.org

сравнительные бенчмарки: http://www.fastformat.org/performance.html

глянь мой коммент чуть выше. про fastformat.

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

Да, блин... Весь SQLite в один .c-файл засовывают.

Оверхед от конвертации [u8] в char.
u8 символ в 1-байтовый char не сконвертится. или вы о чём?

Чтобы сконвертировать utf8 в utf32 нужно брать от одного до 4 байт (в зависимости от символа) и сконвертироаать их в 32битный char. Во первых будет оверхед на конвертацию а во вторых будет 4x оверхед по памяти. И выйгрыша никакого в результате не будет, потому что индексация code point'ов никому не нужна, нужны grapheme clusters, а они даже в utf32 не влазят в 32 бита.

Да понятно, что это не проблема, просто лень было заморачиваться, тк это не самое узкое место было.

Unicode декларирует полную эквивалентность вышеприведённых строк. Это не способ рисования человечков из значков. ASCII такого не делает. Не нужно смешивать поддержку форматирования для матричных принтеров и семантическое содержание строк Unicode. В Unicode ё и ё эквивалентны, хотя и являются разным набором байт.

В rust char 4 байта.

Не вижу проблемы с тем, чтобы скопировать это в std::string или std::vector в зависимости от нужд.

А говнокода с strcmp-говномя уже насмотрелся - такое пишут только неосиляторы c++ (те, для кого сложно освооить алгоритмы, итераторы и лямбды).

Ура!

strcmp(cstr, «yoba») == 0

std::string {cstr} == «yoba»

Очень люблю копировать и выделять память, спасибо!

invy упоролся, но таки string_view вместо string тут должен вменяемо работать.

А говнокода с strcmp-говномя уже насмотрелся - такое пишут только неосиляторы c++ (те, для кого сложно освооить алгоритмы, итераторы и лямбды).

скорее вы не освоили POSIX и врядли расскажете чем отличается std::equal от memcmp, например

что использовать - алгоритмы/итераторы/лямбды или стандартную библиотеку Си зависит от задачи. Довольно смешно иногда смотрятся попытки отдельных неосиливших особей написать «неговнокод»(ц) через жопу.

Ура, будущее.

как там в 2017ом?

использовать posix api напрямую - верный способ отстрелить себе не только ноги, но и все остальное.

еще любопытнее потом вылавливать single-event баги таких «оптимизаторов».

использовать posix api напрямую - верный способ отстрелить себе не только ноги, но и все остальное.

если вам так страшно от posix api, идите писать на руби для веб. меньше стресса, дольше проживете.

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

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

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

Зачем нужна проверка длинны на строках с \0?

Парсишь getline-ом поди?

Все что я хотел сказать, это то, что в стандартной библиотеке просто _нет_ нормальных фунций/оберток для_работы_с/над const char*.

Пихать везде овнящий std::string при этом, очень разумно, конечно.

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

Особенно если у нее нет альтернатив.

а strlen что даст если передали мусор вместо C строки?

Зачем нужна проверка длинны на строках с \0?

Затем что никаких гарантий что там будет 0 нету. Я фигею - 50 лет проблеме, а до сих пор нахдятся те, кто хотят наступать на грабли.

Парсишь getline-ом поди?

Паршу специально предназначеным парсером.

Все что я хотел сказать, это то, что в стандартной библиотеке просто _нет_ нормальных фунций/оберток для_работы_с/над const char*.

Потому что не нужно.

segfault даст. в лучшем случае.

вот как раз-таки опыт работы учит писать безопасно без экономии на спичках.

Затем что никаких гарантий что там будет 0 нету. Я фигею - 50 лет проблеме, а до сих пор нахдятся те, кто хотят наступать на грабли.

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

Что же делать?!

Ах, точно, если либа возвращает битую std::string - значит проблема в либе.

А вот если у либы в доках написано, что там null-terminated string, а возвращает мусор, то это проблема const char* и опасного api.

Ясно, понятно.

тогда при чём тут канделябр к strcmp?

А, точно, расскажи плиз, что такое консистентное состояние std::string.

А то я не понимаю что-то. Это точно строка вообще?

Это же массив байтиков+длина, да?

А строки то где, строки?

Ща \0 из std::string в xml-и писать начну, ну строка же, правда? Стоп, а какая кодировка?

Ой, я же в другом месте protobuf «строкой» с байтиками кормлю.

Памагите.

вот как раз-таки опыт работы учит писать безопасно без экономии на спичках

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

Никаких гарантий, что std::string вернется в консистентном соcтоянии.
А, точно, расскажи плиз, что такое консистентное состояние std::string.

Сам придумал - сам и рассказывай.

По существу, я так понимаю, сказать нечего?

Канделябром - чтобы не использовали.

Сравни серьезность ошибок и вероятность их происхождения:

либа возвращает битую std::string

и

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

Я тебе не предлагаю использовать Си строки, я предлагаю их сравнивать. Привет.

Я тебе не предлагаю использовать Си строки, я предлагаю их сравнивать. Привет.

зачем вы спорите с агрессивным школьником? не мешайте ему делать уроки и учить раст

Все что я хотел сказать, это то, что в стандартной библиотеке просто _нет_ нормальных фунций/оберток для_работы_с/над const char*

В стандартной библиотеке C++ много чего нет. Например, нет ничего для разработки GUI. Что не помешала появлению туевой хучи GUI приложений на C++, написанных с использованием Qt, wxWidgets, FLTK, FOX, MFC/ATL и пр.

Аналоги того же string_view существуют уже очень и очень давно (например, Google-овский StringPiece).

лучше уж std::strcmp(str, «whatever») вызвать на C строку вместо std::string(str) == «whatever». а почему - ударят канделябром за отвратительный перформанс в какой-нибудь задаче по сортировке массивов строковых данных - станет понятно.

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

другое дело, что на практике терминалы и С-строки этот стандарт нарушают