SABROG, строка хранится в памяти непрерывно. Это вообщем-то факт (чтобы нормально рабоали c_str и data). Поэтому в классе должен быть только указатель на строку. Никак не сама строка.

Я писал раньше, что метод capacity() возвращет количество символов, которое может содержать строка изначально.
Эксперимент показал, что размеры занимаемой памяти никак не менялся, если я создавал 6 млн.ов пустых строк, или 6 млн.ов строк длинной меньше 15 символов (hello, world).

Скажи это разработчикам STLport и STL в MS. А то они совсем идиоты. Ещё расскажи им что хранить в классе длину строки не надо. Ибо "только указатель" это наше всё. 

И? То, что во многих реализациях стл память резервируется заранее - это очевидно. Только к sizeof-у сабжевому это не имеет никакого отношения 

плин не получилось впереёд SABROG'а ответить     
тьфу блин не склеилось


И где же она резервируется как не внутри класса?  Берется из эфира?

Это сообщение отредактировал(а) Mayk - 31.7.2008, 13:47

в классе хранится указатель на выделенную в куче память. Причем тут объект класса?

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

Mayk!  



Добавлено через 1 минуту и 42 секунды
Резервируется, короче, она никак не внутри класса. Ибо размер класса статичен, строки - нет. А очень желательно хранить строку непрерывно (иначе - проблем больше будет). Что касается размера буфера, размера строки, аллокаторов, итераторов и пр. - да, это хранится в самом классе. Не только указатель, но никак ни сама строка.

Добавлено через 2 минуты и 36 секунд

К слову - Dinkumware STL. Платно доступна, кстати, для гцц  

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

Какие алгоритмы могут дать хэш размером в 32 бита ? Я правильно понимаю "хэш" в данном контексте это уникальное значение, которое берется путем математических манипуляций с уникальной строкой. Т.е. если была строка "Hello, World" и я поменяю W на прописную w, то хэш уже будет другой. И хэш будет мне гарантировать, что в базе не появится строка с подобных хешем.

Когда я подобное искал, то не нашел алгоритмов с хэшами меньше 128 бит и то они не гарантировали уникальности. В итоге пришел к выводу, что экономнее хранить строки как есть, т.к. хэши даже для однобайтовых строк слишком длинные.

Хеш - не может быть абсолютно уникальным  Иначе это не хеш - а просто сжатая строка   

Это сообщение отредактировал(а) Любитель - 31.7.2008, 15:03

http://en.wikipedia.org/wiki/Adler-32

Для нескольких миллионов слов пойдёт.



Как они могут гарантировать уникальность? Сколько всего состояний может принять последовательность 128 бит? 2^128. А сколько всего состояний может принять последовательность, например, из 256 бит? Ясно, что 2^256  >> 2^128 и что меньшая последовательность в прицнипе не сможет хранить все состояния первой. Тут вопрос вероятности, а в нормальных хеш-функциях они очень малы, поэтому ими пренебрегают.

Это сообщение отредактировал(а) W4FhLF - 31.7.2008, 15:06

Ну, если быть точным - для строки это в некоторой мере возможно, учитывая, что символом с кодом ниже 32 у нас нет.

boost::hash пишет хэш в size_t, 
2^32 = 4 294 967 296
количество слов = 6 000 000
так что коллизии маловероятны...

Не согласен. Если в цикле нужно проверять размер одной и той же строки, то это расходы на strlen().
Плюс, необходимо знать размер вместимости строки, и предварительно выделять с запасом, чтоб избежать постоянного перевыделения памяти.
имхо.

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


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