@meJevin

Привет, читал про std::string на разных сайтах.


1. Там говорят, С++ 11 гарантирует, что std::string будет stored contiguously in memory. В этом я не сомневаюсь, но каким еще образом можно в памяти хранить std::string?

2. Говорят, что std::string на самом деле имеет null-terminator на конце. Это так? Вроде да, я в этом немного убедился в своей студии. Сделал четыре std::string'a, через цикл от 0 до size()+1 вывел все представления их символов в виде int, и да, последний символ был '\0' (в int виде просто 0).

Но все равно, некоторые говорят, что если мы имеем std::string str("hello"); и пытаемся получить доступ к желанному null-terminator'у, у нас может быть UB. Т.е. писать такое: std::cout << (int)str[str.size()] << std::endl; не стоит. Правда может быть UB?

3. Что под капотом у std::string на самом деле? Можете объяснить простым языком, если не трудно?

0

@_Ivana

да любым - например, в виде односвязного списка чаров.

ЗЫ1: если абстракция предоставляет внешний апи - не стоит лезть и курочить ее нутрь. Потому что завтра новый Степанов перепишет эти стринги по-другому с сохранением апи, и ваша программа, рассчитывающая на нуль-терминатор, может свалиться. Например, паскалевские строки - хранят размер в первом байте. И можно на это рассчитывать. Но тогда длина не более 255, кому-то это однажды надоело, и он стал хранить длину в первом слове - двух байтах. И кто пользовался апи - не заметили, а кто рассчитывал на реализацию - приплыли.

ЗЫ2: расположение строк строго в линейной области памяти - это хорошо. В Си. А в Яве с Шарпом решили гениально совместить это требование (само по себе необязательное - см. п 1) с иммутабельностью строк И начались ужасы от тех, кто не особо понимал, как это готовить без всяких стрингбилдеров, ибо при для иммутабельности строки при операциях (конкатенация/выделение подстроки и т.п.) копируются в новые области памяти, которые аллоцируются, и если в цикле - то долго и медленно... И из-за этой имхо странной реализации многие не желающие думать императивные программисты делают вывод о том, что иммутабельные структуры данных в функциональных языках всегда копируются и жрут память и время....

0

@meJevin

Это понятно, но ведь по перформансу-то долбанет же? Поэтому лучше всего contiguously in memory, так?

0

@HenryDukart

meJevin, требования ко всем контейнерам предъявляются не на их реализацию, а на производительность. Реализовать можете как угодно, лишь бы удовлетворяло условиям сложности.

0

@_Ivana

Ну вы же не вчера структуры данных узнали. Долбанет по доступу за О(1) к любому элементу, зато позволит быстро расширять с головы, в отличие от стандартных массивов. В хаскеле, например, 2 типа строк - высокоуровневые - списки чаров, низкоуровневые - байтстринги. Тот же Джоэл Спольски, когэа в Майкрософте Эксель на Сях костылил, влепил туда паскалевские строки - "поэтому Эксель такой быстрый" (С). Короче - в зависит от области применения.

0

@avgoor

Неправда ваша. В стандарте четко написано:
Т.е. под капотом у него может быть только си-строка. (Почему не просто массив чаров без терминального нуля - тоже написано, но в требованиях к operator[], c_str() и data(), которая в c++17, кстати, станет неконстантной).

0

@_Ivana

Да шел бы он, стандарт (простите за непопулярное имхо) ТС спрашивал каким еще образом можно - я ответил.

0

@avgoor

Но, господин! Если: то это будет не std::string из C++.

0

@_Ivana

Резонно На это мы или свой буст не стд-шный навелосипедим, или стандарт поменяем (вроде какая-то российская компания стала официальным членом комитета что-ли, и может принимать предложения от соотечественников). Или и то и другое одновременно

0

@avgoor

Даже если и так, std::string всегда будет содержать способ каста к си-строке "для совместимости"™. Теоретически можно сделать стринг на списках, с мутабельным массивом, и только кэшировать туда данные. Но, так может сделать только "мудакъ"®. А реализацию STL "мудаки"® не пишут.

1

@_Ivana

И что? Уж каст то для совместимости можно сделать из чего угодно.
Я не знаком с авторами стл, чтобы иметь о них какое-либо мнение. Зато хорошо знаком с одним парнем, который выкинул нахрен все стл-ство (на которое молились предыдущие разрабы) из пендосского проекта, написал свои реализации и убыстрил его в несколько раз.

0

@avgoor

Та же фигня. Но это - фундаментальное свойство любой техники: Любое специальное устройство всегда оптимальнее общего.
Вопрос цены (в смысле затрат памяти итд).

0

@Mr.X

Да ладно! Так-то по стандарту контейнер, например, есть массив, т.е. занимает непрерывный кусок памяти.

0

@HenryDukart

Mr.X, разве где-то описывается внутреннее устройство контейнера?

1

@avgoor

Адын: Два: Три:

0

@HenryDukart

avgoor, про внутреннюю реализацию ни слова.

Добавлено через 19 минут
avgoor, ну ни слова это я загул конечно. Спасибо за такое точное определение.

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

0

@Mr.X

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

0

@HenryDukart

Mr.X, вы, наверное, про метод data().

0

@avgoor

А указатели где хранить? В другом месте будет массив {1, 2, 3, 4, 5, ...}? Зачем? И самое главное, если список всегда располагается в памяти по последовательным адресам - такой список называется массивом.
В прочем выше я уже писал: "теоретически, можно...".

0

@Mr.X

Я про то, что элементы вектора по стандарту хранятся в массиве, а адрес первого элемента вектора указывает на начало этого массива.

0