Немного про std::string

Привет, читал про 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

Сообщение от meJevin каким еще образом можно в памяти хранить

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

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

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

0

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

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

0

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

0

Сообщение от meJevin так?

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

0

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

Неправда ваша. В стандарте четко написано:

A basic_string is a contiguous container

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

0

Сообщение от avgoor В стандарте четко написано

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

0

Сообщение от _Ivana ТС спрашивал каким еще образом можно - я ответил

Но, господин! Если:

Сообщение от _Ivana Да шел бы он, стандарт

то это будет не std::string из C++.

0

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

0

Сообщение от _Ivana Или и то и другое одновременно

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

1

Сообщение от avgoor всегда будет содержать способ каста к си-строке "для совместимости"™

И что? Уж каст то для совместимости можно сделать из чего угодно.

Сообщение от avgoor Но, так может сделать только "мудакъ"®. А реализацию STL "мудаки"® не пишут.

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

0

Сообщение от _Ivana написал свои реализации и убыстрил его в несколько раз

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

Сообщение от _Ivana Уж каст то для совместимости можно сделать из чего угодно.

Вопрос цены (в смысле затрат памяти итд).

0

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

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

0

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

1

Сообщение от HenryDukart разве где-то описывается внутреннее устройство контейнера?

Адын:

21.3.1 Class template basic_string 3 A basic_string is a contiguous container

Два:

23.2.1 General container requirements 13 A contiguous container is a container that supports random access iterators and whose member types iterator and const_iterator are contiguous iterators

Три:

24.2 Iterator requirements 24.2.1 In general 5 Iterators that further satisfy the requirement that, for integral values n and dereferenceable iterator values a and (a + n), *(a + n) is equivalent to *(addressof(*a) + n), are called contiguous iterators.

0

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

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

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

0

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

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

0

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

0

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

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

0

Сообщение от HenryDukart Mr.X, вы, наверное, про метод data().

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

0