с одним небольшим расширением (доступно в gcc/clang) сишка прекрасно годится и для уёб-разработки. Хотя null-terminated строки всё-таки не очень эффективно, это всё равно работает быстро на старых 486 компах (да, умельцы на них activitypub сервера пускают)
https://codeberg.org/grunfink/snac2/src/branch/master/html.c#L459
Суть расширения - аттрибут cleanup, который позволяет освобождать память автоматически.
Как это работает? В проекте выше реализованы контейнеры для строк, списков, словарей (типа json или dict в python) в виде линейной структуры. Когда буффер одного из этих типов присваеивается переменной типа xs* - время его жизни определяется блоком, в котором она определена. cleanup деструктор - просто функция free(), хотя по идее можно было динамически определять тип и ещё что-то делать. Для динамического определения типа буффера используется первый байт - контрольные символы определяют тип объекта (список/словарь/число), всё остальное - строка - это полезно к примеру при итерации по списку/словарю.
Дальше все функции которые изменяют объект - возвращают новый. Его всегда надо присвоить в xs* переменную, чтобы он потом удалился автоматически. Бонусом можно выводить строки обычным printf форматом.
Может показаться дико? Но код выглядит вполне читабельным и аккуратным, без огромного количества бойлерплейта, свойственного уёбу.
не выкинули, там как раз вся прелесть в том, что строка это просто нуль-терминированный буффер, а всё что не строка - хранится как строка с контрольным байтом в начале
Вообще даже c++ сильно теряет от нулль-терминированных строк. string_view появился только в c++17, что очень поздно (да, STL - как всегда бесполезная фигня без задач)
Я пробовал в одном проекте переходить на строки в виде структуры из пары указателей (начало-конец) - удобно, zero-copy подстроки, владеть строками может единый пул-строка без всяких терминирующих нулей, так и можно писать их после структуры (например если (uintptr_t)begin == (uintptr_t)(&end + 1) - строка владеющая, иначе - нет). Но всё упирается в необходимость взаимодействия со внешним кодом. Пути в ядерных сисколах - готовь нуль-терминированную строку, imgui - тоже (хотя там есть ветка string_view, но похоже, что она никогда не попадёт в апстрим и так и останется feature branch). А в остальном, пока не надо взаимодействовать со внешним кодом - сравнение строк идёт куда быстрее (сначала сравнивается длина, потом memcmp), копирование - простой memcpy с заранее известной длиной, создание из литерала сразу по sizeof без всяких strlen(), нужна подстрока - просто запиши в структуру указатель на её начало и конец.
std::string имеет часть этих преимуществ, но всё равно заставляет нулль-терминировать буфер
Кстати вот у жабки строки не нуль-терминированные, и substring раньше работало за O(1) без копирования, но начиная с какой-то версии от этого отказались (я так понимаю, решили, что много памяти жрёт, когда маленькие подстроки держат буферы от уже несуществующих больших строк), и сейчас substring всегда копирует буфер. «std::string имеет часть этих преимуществ, но всё равно заставляет нулль-терминировать буфер» так у неё и бесплатный c_str() имеется
«было сделано копирование в отличии от жабы» Вот это самый прикол. При том, что как раз в жабе заявляется дроч на обратную совместимость и WORA, вот так поменяли поведение в одной из самых базовых вещей. На днях на лоре тред был про шестую жабу, там ещё Dimez писал, что у него где-то на каком-то проде производительность падала при переходе на java7/8 относительно java6. https://www.linux.org.ru/forum/general/17940910?cid=17941339
с одним небольшим расширением (доступно в gcc/clang) сишка прекрасно годится и для уёб-разработки. Хотя null-terminated строки всё-таки не очень эффективно, это всё равно работает быстро на старых 486 компах (да, умельцы на них activitypub сервера пускают) https://codeberg.org/grunfink/snac2/src/branch/master/html.c#L459 Суть расширения - аттрибут cleanup, который позволяет освобождать память автоматически. Как это работает? В проекте выше реализованы контейнеры для строк, списков, словарей (типа json или dict в python) в виде линейной структуры. Когда буффер одного из этих типов присваеивается переменной типа xs* - время его жизни определяется блоком, в котором она определена. cleanup деструктор - просто функция free(), хотя по идее можно было динамически определять тип и ещё что-то делать. Для динамического определения типа буффера используется первый байт - контрольные символы определяют тип объекта (список/словарь/число), всё остальное - строка - это полезно к примеру при итерации по списку/словарю. Дальше все функции которые изменяют объект - возвращают новый. Его всегда надо присвоить в xs* переменную, чтобы он потом удалился автоматически. Бонусом можно выводить строки обычным printf форматом. Может показаться дико? Но код выглядит вполне читабельным и аккуратным, без огромного количества бойлерплейта, свойственного уёбу.
Дно какое-то, самую мякотку сишки выкинули.
никуда не выкинули. Стоит тебе перепутать xs с xs_val и мякотка радостно отстреливает тебе ногу
Выкинули строки как массивы.
не выкинули, там как раз вся прелесть в том, что строка это просто нуль-терминированный буффер, а всё что не строка - хранится как строка с контрольным байтом в начале
Ок.
Вообще даже c++ сильно теряет от нулль-терминированных строк. string_view появился только в c++17, что очень поздно (да, STL - как всегда бесполезная фигня без задач) Я пробовал в одном проекте переходить на строки в виде структуры из пары указателей (начало-конец) - удобно, zero-copy подстроки, владеть строками может единый пул-строка без всяких терминирующих нулей, так и можно писать их после структуры (например если (uintptr_t)begin == (uintptr_t)(&end + 1) - строка владеющая, иначе - нет). Но всё упирается в необходимость взаимодействия со внешним кодом. Пути в ядерных сисколах - готовь нуль-терминированную строку, imgui - тоже (хотя там есть ветка string_view, но похоже, что она никогда не попадёт в апстрим и так и останется feature branch). А в остальном, пока не надо взаимодействовать со внешним кодом - сравнение строк идёт куда быстрее (сначала сравнивается длина, потом memcmp), копирование - простой memcpy с заранее известной длиной, создание из литерала сразу по sizeof без всяких strlen(), нужна подстрока - просто запиши в структуру указатель на её начало и конец. std::string имеет часть этих преимуществ, но всё равно заставляет нулль-терминировать буфер
Кстати вот у жабки строки не нуль-терминированные, и substring раньше работало за O(1) без копирования, но начиная с какой-то версии от этого отказались (я так понимаю, решили, что много памяти жрёт, когда маленькие подстроки держат буферы от уже несуществующих больших строк), и сейчас substring всегда копирует буфер. «std::string имеет часть этих преимуществ, но всё равно заставляет нулль-терминировать буфер» так у неё и бесплатный c_str() имеется
В шарпе тоже не нуль-терминированные и изначально было сделано копирование в отличии от жабы, но можно создать вьюху над строкой.
«было сделано копирование в отличии от жабы» Вот это самый прикол. При том, что как раз в жабе заявляется дроч на обратную совместимость и WORA, вот так поменяли поведение в одной из самых базовых вещей. На днях на лоре тред был про шестую жабу, там ещё Dimez писал, что у него где-то на каком-то проде производительность падала при переходе на java7/8 относительно java6. https://www.linux.org.ru/forum/general/17940910?cid=17941339
Имеется, но ради этого c_str оно должно постоянно нулль-терминированную строку держать