контейнеры stl, out of range

[sss]

Алексей1153++, блин, не понимаю. Приемный поток выделяет необходимый буфер, блокирует очередь, заталкивает запись об буфере, освобождает очередь...  Поток обработки данных блокирует очередь, вынимает все записи о готовых буферах, освобождает очередь, обрабатывает данные, освобождает данные. Что может быть удобнее?

[Алексей++]

sss, удобнее, когда ничего из этих двух строк текста делать не надо )
Это не буфера с данными, а массив элементов (не байтов)

[Антон (LogRus)]

sss, не помню такого или я был молодой и глупый

[sss]

sss, не помню такого или я был молодой и глупый

У меня маразм наверное. Извини....

[Алексей++]

если параметр вектора - простой тип
std::vector<BYTE> v;
то гарантируется ли, что все значения обнулены при resize для новых элементов ?

[Антон (LogRus)]

вектор для некоторых операций требует наличие конструктора по умолчанию
к этим операциям относится resize
как это работает?
выделяется новая память туда копируются старые данные, на месте новых данных вызывается inplace new с конструктором по умолчанию, для простых типов это 0, НО не что не мешает иметь вектору специальной перегрузке для простых типов (особенно если вектор из MSVS), хотя стандарт требует вызвать конструктор по умолчанию:

void resize(size_type sz);
Effects: If sz < size(), equivalent to erase(begin() + sz, end());. If size() < sz, appends sz
- size() default constructed elements to the sequence.
Requires: T shall be DefaultConstructible.

предлагаю просто проверить

[Алексей++]

проверить- не проверить, это всё неправильно ) Гарантированно ли там будут нули ?

Ну в любом случае, я инкапсулировал простой тип в свой класс. Чтоб потом не стрельнуло где нибудь ) Неприятно же будет

[Антон (LogRus)]

Алексей1153++, по стандарту гарантировано (точнее гарантирован вызов конструктора по умолчанию), но помнится MS не слишком следует стандартам.

[Алексей++]

вот то то и оно оно оно В общем, оставлю классик с конструкториком

[lapulya]

Ахренеть!!!! что делается... я чуть со стула не упал... пушистый решил заюзать stl... ЗВЕЗДУ ПУШИСТОМУ!!!!!!!
Ну если есть вопросы пиши!

[Finch]

lapulya, Мне просто интересно, ты специально ждеш месяца 3, чтоб ответить? Это наверно уже четвертая или пятая старая тема, поднятая тобой только за 1 сутки.

[lapulya]

нет. я просто редко хожу, а что это противозаконно или кого то бесит? Если да, то ок, не буду писать на темы сроком более 2 недель.

[Алексей++]

lapulya,

Финч, да ладно, нормально же пишет

[RXL]

lapulya, не надо так уж резко реагировать - Финч только поинтересовался. А вообще, заходи по-чаще

[Алексей++]

делаю пул элементов некоего класса s_Knot.
Размер пула меняется шагом в, скажем, 1024 элемента.
Применяю вектор, и ради задуманного пришлось нагородить следующее (шаги огорода пронумерованы)

1)
просто сделать так-

Код:

		typedef std::vector<s_Knot> td_pool;
		td_pool	m_pool;

нельзя, так как при реаллокации станут невалидны указатели на элементы. Поэтому делаем субконтейнер

2)

Код:

		struct s_Knot_container
		{
			s_Knot* pk;

		private:
			void del()
			{
				if(pk)
				{
					delete pk;
					pk=0;
				}
			}

		public:
			s_Knot_container()
			{
				 pk=new s_Knot;
			}


			~s_Knot_container(){ del(); }

			s_Knot_container(const s_Knot_container& src)
			{
				pk=0;//обязательно
				*this=src;
			}

			void operator =(const s_Knot_container& src)
			{
				pk=src.pk;
				((s_Knot_container*)&src)->pk=0;
			}
		};

		typedef std::vector<s_Knot_container> td_pool;
		td_pool	m_pool;

но и тут не всё ладно: выясняется, что при реаллокации STL делает:
 - создаёт один экземпляр элемента s_Knot_container (вызывается его конструктор, там выделяется память под один s_Knot)
 - потом STL выделяет место под требуемое количество элементов и КОПИРУЕТ туда во все элементы первый выделенный.
- в итоге - все выделенные элементы вектора имеют  pk==0, а лишь один, нулевой элемент -  pk!=0. Ладно. Далее идём:

3)
 субконтейнер теперь выглядит так

Код:

		struct s_Knot_container
		{
			s_Knot* pk;

		private:
			void del()
			{
				if(pk)
				{
					delete pk;
					pk=0;
				}
			}

		public:
			s_Knot_container()
			{
				pk=0;
			}


			~s_Knot_container(){ del(); }

			s_Knot_container(const s_Knot_container& src)
			{
				pk=0;//обязательно
				*this=src;
			}

			void operator =(const s_Knot_container& src)
			{
				if(!pk)
				{
					 if(src.pk)
					 {
						pk=src.pk;
						((s_Knot_container*)&src)->pk=0;
					 }
					 else
					 {
						 pk=new s_Knot;

					 }
				}
			}
		};

		typedef std::vector<s_Knot_container> td_pool;
		td_pool	m_pool;

теперь, всё, как надо: при переаллокации старые субконтейнеры перекидывают свои данные на "старое" место, не уничтожая свои pk (->s_Knot), затем выделется новая порция субконтейнеров со своими, новыми, s_Knot.
Указатели на s_Knot "не теряются", ведь память в куче не трогается, перекопируются только указатели.

4) ВНИМАНИЕ, вопрос! Моя задача решается как-то проще (с вектором ли или с чем-то ещё из STL) или именно так только и возможно?

[lapulya]

Ну переопредели оператор = и копирующий конструктор у класса объекта, который хранится в контейнере (в твоем случае s_Knot) и все будет, хотя ихмо это изврат. Более того, если хранить в контейнерах объекты, то положить в них объекты наследников (типа class SUB_s_Knot : public s_Knot) будет некорректно, поскольку они "срежутся" до s_Knot. Короче это геморрой...

Рекомендую хранить в контейнере указатели на объекты (в 99% это лучший вариант для пользовательских типов), а объекты в векторе лучше хранить на стандартные/встроенные типы, которые не переписывают свое содержимое в операторе = и конструкторах, а копируют только ссылки на внутренние ресурсы (ну как std::string) и делают это быстро.

Код:

class MyObject {...};
class MyUBObject : public MyObject {...};

typedef std::vector<MyObject *> MyObjects;
MyObjects objects;
objects.push_back(new MyObject());
objects.push_back(new MySUBObject());

А какова прикладная задача? Почти уверен, что хранение указателей подойдет.

ЗЫ

нельзя, так как при реаллокации станут невалидны указатели на элементы.

Реаллокация тут не причем, указатели будут невалидны как только ты попытаешься что-то извлечь из контейнера (тут опять будет создан новый объект)!!! Так что до реаллокации очередь может и не дойти

[Алексей++]

Нет, производных от s_Knot не предвидится. А сама структура содержит только указатели и данные, которые можно при инитке тупо обнулить - я склоняюсь к мысли просто выделять пул в виде байтового массива, кратного структуре, да обнулять этот массив. Ну и завернуть это в класс, который будет возвращать правильные указатели и увеличивать пул, когда надо ) Тогда отпадает вектор и память из кучи разом под много элементов выделяется. Скорость, однако

[lapulya]

Алексей1153++, Все же непонятно почему бы не хранить указатели. Кстати если ты сейчас не предвидишь наследования от твоего класса (содержимого контейнера), возможно это потребуется позже (но это уже ближе к лирике, но все же). Хранение указателей:
1. полностью решает твою прикладную задачу
2. работает быстро (быстрее только декуе и ничего больше, ну или список, так там и реаллокации нет )
3. без проблем расширяется (ну ты прикинь надо будет увеличить структуру на пару членов и т.д.), а тебе с такой "зашивкой" придется попотеть (да еще и не ЗАБЫТЬ исправить во всех местах!!! - безопасность!!!).
4. Ничего дополнительного писать не надо (все уже написано за нас)

Я у своего первого поста еще про реаллокацию дописал.

[Алексей++]

lapulya, мне обобщения не потребуются, производные тоже, добавление мемберов - тоже вряд ли. Буду экспериментировать, вся ночь впереди )))

[Антон (LogRus)]

4) ВНИМАНИЕ, вопрос! Моя задача решается как-то проще (с вектором ли или с чем-то ещё из STL) или именно так только и возможно?

0. Какая задача.
1. попробуй дек, он не вызывает реалокации при вставке в конец и не ивалидирует иретароры
2. почему бы не использовать контейнер указателей

Код:

boost::ptr_vector<animal> vec;
vec.push_back( new animal ); // you add it as pointer ...
vec[0].eat();                // but get a reference back

3. твой прокси класс, просто умный указатель с передачей владения аля std::auto_ptr
4. ознакомься с советами 1-9 из книги Скотт Мейерс "Эффективное использование STL" взять можно тут http://www.coders-library.ru/uploads/books/public/STL_Meiers.rar

[Алексей++]

LogRus , задача в том, чтобы не выделять память кусочечками много раз, а одним куском про запас. Я сначала думал, что вектор так и делает, но, похоже, ошибался. Поэтому STL сюда таким способом не применим, разве что , действительно, вектор указателей на кусок памяти, где массив элементов был выделен new. Вечером займусь этим вопросом )

[Антон (LogRus)]

1. Можно сделать резерв
2. Можно написать свой аллокатор

Вопрос вот в чём: зачем нужен этот изврат?
Не смотря на то, что у нас в компании высокие требования к скорости кода, мы редко пользуемся аллокаторами и не раньше чем их необходимость будет доказана тестами производительности.

меня почти всегда устраивает deque как контейнер элементов:
1. нет реалокации
2. быстрая вставка в конец
3. память выделяется блоками по несколько элементов
4. не требует больших непрерывных кусков памяти
5. имеет произвольный доступ.

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

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

Поэтому STL сюда таким способом не применим

"Ты просто не умеешь их готовить" ©

[Алексей++]

необходимость будет доказана тестами производительности.

это я обязательно проведу Самому интересно

меня почти всегда устраивает deque как контейнер элементов:
1. нет реалокации
2. быстрая вставка в конец
3. память выделяется блоками по несколько элементов
4. не требует больших непрерывных кусков памяти
5. имеет произвольный доступ.

попробую. Пункт 3 мне и нужен

элементов, то первые 2000 добавлений не будут вызывать реалокацию

вот вот А реаллокация - это потеря указателей, что есть не очень

Ты просто не умеешь их готовить

а я и не спорю

[RXL]

Леш, если элементы из контейнера не удаляются в произвольном порядке, попробуй отказаться от указателей и использовать индексы. Я использую, в основном, vector и map, долговременных указателей не использую и адресую либо через итератор, либо по индексу.

[Алексей++]

Можно попробовать. (Но индекс - это дольше, чем указатель)

[Антон (LogRus)]

Можно попробовать. (Но индекс - это дольше, чем указатель)

минимально, опять ты на спичках экономишь
вот смотри разницу обращения по индексу и по указателю.

Код:

int * p = &vector[n];
*p = 8;
................
*(&vector[0] + n) = 8;
................
// или так
int * p = &vector[0];
*(p + n) = 8;

[Алексей++]

LogRus, как всё это снаружи выглядит, я в курсе Но оператор [ 0] придётся вызывать каждый раз. А что там внутри у вектора происходит - я не смотрел

[Антон (LogRus)]

Алексей1153++, vector[0] это фактически (в релизе) *vector.data
т.е. vector[n] сводится к *(vector.data+n), таже самая работы с чистым указателем, всё как ты любишь

[lapulya]

Алексей1153++,

попробую. Пункт 3 мне и нужен

Если хранить в контейнере объекты (не указатели), то при получении (любым способом) объекта из контейнера ты получишь копию!!! этого объекта, т.е. внешние указатели будут не верны! Если хранить в контейнере поинтеры, то затраты (накладные расходы) на реаллокацию и т.д. (а т.д. = много чего, фактически абсолютно все, что относится так или иначе к манипулированию объектами в контейнере) минимальны + все внешние указатели валидны. Итого, рекомендую хранить поинтеры.

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

[lapulya]

LogRus,
Я бы так делать не советовал... насколько мне помнится (могу и ошибаться), но

Стандарт гарантирует, что вектор должен выделить последовательный участок памяти для хранения в нем данных, но только это... т.е. ни больше и ни  меньше. То, что вектор обязан выделить массив элементов этого типа и более того, что доступ к i-ому элементу возможен по такому адресу *(vector[0] + i), этого стандарт не гарантирует (во втором я уверен почти на 100% ). Да, большинство компиляторов именно так и делают (подозреваю, что так делают все компиляторы), но используя доступ подобным образом программист действует на свой страх и риск.