Кто нибудь, объясните, почему:

Это что за нехороший класс такой. Его размер больше хранимой в нем строки!

Во втором случае у тебя массив из 4х экземпляров класса std::string.

А вообще здесь тоже народ возмущается: http://forums.msdn.microsoft.com/en-US/vcl...7-e482c4e461a7/

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

Ужжас. Целых 32 байта. Как жить дальше?  
Неужели в системных требованиях придется писать "1 mb. ram"?      

Не, не. sizeof() возвращает размер в байтах. Посмотрите файлик basic_string.h, там действительно напихали всего.

упс, я думал он в биты перевел...

SABROG - Я всегда юзал сей класс даже не задумываясь об этом.
В данном случае мне нужно создать массив из 6 000 000 объектов, и памяти явно не хватает, ~1.3 Gb сжирает, поэтому я и решил проверить.
Проверил, расстроился... Лучше бы и не зал сего  

Ну пустые классы занимать будут тогда 183 мегабайта в твоем массиве.

Я не знаю какая у тебя задача, но можно попробывать использовать массив обычных char'ов, а строки разделять \0'ми. Но это конечно, если есть возможность последовательного заполнения массива и еще надо будет написать алгоритм поиска строки по индексу.

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

Неа, так не пойдет... Нужно изменять значение строк.

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

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

Любопытный бенчмарк на сравнение Си и STL строк, не в пользу последних: http://deepencpp.blogspot.com/2007/08/stds...comparison.html

Lazin, а у меня тоже подобная ситуация возникала, из базы данных делается выборка окола 1.5 млна записей, по 20 колонок в каждой. Т.е. 30 млн. строк., которые распихваются по структурам и векторам. Сжирается вся оператива и вся виртуалка. Далее происходят операции типа парсинга этого всего дела. Объединения, конвертация из текста в числа и т.п. После того как алгоритм отработает результат пихается в Excel файл и после этого память освобождается. Теоретически можно как-то выгружать ненужные участки и подгружать новые по 10 раз, но это скажется на скорости работы программы. Т.е. либо скорость, либо память.

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


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

Давно уже пора переходить на x64 и не мучиться с ограничением 2гб.

если это не расчитано на машины с большим кол-вом оперативы, аля серверы. Тогда надо подумать, не ошиблись ли вы случаем с выбором алгоритма?

ничего любопытного, STL реализаций много, а значит этот бенчмарк идет лесом, и второе: по вашему за удобство ничем не надо расплачиваться?


+1

неужели для обработки одной строки нужно знать все остальные, может как-нибудь, в несколько проходов можно все обработать?

Хотябы light-weight классы строковые сделали бы, где можно реализовать хотябы простые операции без которых невозможна работа и с обычными char массивами.