Начал изучать С++. Пока пишу маленькие консольные приложения.
У меня есть матрица NxM, в которой будет находится индекс другого одномерного массива. Если бы M и N были бы константы, то вроде бы все просто, но я хочу чтобы матрица могла становится больше. Еще мне хотелось бы, что если бы я удалял в матрице уже заполненный елемент, то в массиве элемент с этим индексом тоже удалялся, а в следующий раз при добавлении нового элемента в матрицу, в массиве добавлялся элемент не в конец, а на место удаленного.
Подскажите мне в какую сторону подумать, т.е что лучше использовать в моем случае, т.к. массивы здесь вроде бы совсем не подходят.

On Mon, 05 Dec 2005 08:58:07 +0200, wrote:

> Начал изучать С++. Пока пишу маленькие консольные приложения.
> У меня есть матрица NxM, в которой будет находится индекс другого одномерного массива. Если бы M и N были бы константы, то вроде бы все просто, но я хочу чтобы матрица могла становится больше. Еще мне хотелось бы, что если бы я удалял в матрице уже заполненный елемент, то в массиве элемент с этим индексом тоже удалялся, а в следующий раз при добавлении нового элемента в матрицу, в массиве добавлялся элемент не в конец, а на место удаленного.
> Подскажите мне в какую сторону подумать, т.е что лучше использовать в моем случае, т.к. массивы здесь вроде бы совсем не подходят.


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

а еще вопрос — зачем все так сложно — может быть можна проще ... ?

Здравствуйте, andrij, Вы писали:

A>а еще вопрос — зачем все так сложно — может быть можна проще ... ?
Я бы и хотел попроще, да не знаю как

On Mon, 05 Dec 2005 12:36:06 +0200, wrote:

> Здравствуйте, andrij, Вы писали:
>
> A>а еще вопрос — зачем все так сложно — может быть можна проще ... ?
> Я бы и хотел попроще, да не знаю как

может опишите проблему ?

Здравствуйте, Аноним, Вы писали:

А>Начал изучать С++. Пока пишу маленькие консольные приложения.
А>У меня есть матрица NxM, в которой будет находится индекс другого одномерного массива. Если бы M и N были бы константы, то вроде бы все просто, но я хочу чтобы матрица могла становится больше. Еще мне хотелось бы, что если бы я удалял в матрице уже заполненный елемент, то в массиве элемент с этим индексом тоже удалялся, а в следующий раз при добавлении нового элемента в матрицу, в массиве добавлялся элемент не в конец, а на место удаленного.
А>Подскажите мне в какую сторону подумать, т.е что лучше использовать в моем случае, т.к. массивы здесь вроде бы совсем не подходят.

Эк ты затейливо описал проблему. Не сразу и разглядеть можно, что ты в ней делаешь.
А делаешь, судя по всему, вот что: типизированную кучу (аллокатор).

"Массив" — это куча с фиксированным размером блока, заточенная под какой-то определённый тип.
"Индекс", хранимый в матрице — это (аналог указателя) на объект, размещённый в "массиве".
Менеджер кучи (который следит за жизнью и смертью элементов) называется аллокатором.
(Если следовать STL-совместимости, то придётся решить ряд проблем; если нет, и всё не выйдет за пределы класса матрицы — то достаточно лишь доступа по индексу и функций создания/убивания элементов).

Кстати говоря, а эта куча разделяется между всеми матрицами данного типа, или у каждого объекта-матрицы она своя?

Здравствуйте, Кодт, Вы писали:

К>Эк ты затейливо описал проблему. Не сразу и разглядеть можно, что ты в ней делаешь.
К>А делаешь, судя по всему, вот что: типизированную кучу (аллокатор).
К>"Массив" — это куча с фиксированным размером блока, заточенная под какой-то определённый тип.
К>"Индекс", хранимый в матрице — это (аналог указателя) на объект, размещённый в "массиве".
К>Менеджер кучи (который следит за жизнью и смертью элементов) называется аллокатором.
К>(Если следовать STL-совместимости, то придётся решить ряд проблем; если нет, и всё не выйдет за пределы класса матрицы — то достаточно лишь доступа по индексу и функций создания/убивания элементов).

Мне сейчас будет не по силам делать совместимо с STL. Хотя, наверное, это будет интересно и поучительно для меня.
Я сейчас почитал про аллокаторы, пока мало чего понял, буду обдумывать еще. А вот про типизированную кучу, я ни чего не нашел. Вы имели в виду простой динамический массив, или что-то другое.

К>Кстати говоря, а эта куча разделяется между всеми матрицами данного типа, или у каждого объекта-матрицы она своя?
У каждой матрицы будет своя.

Здравствуйте, andrij, Вы писали:

A>может опишите проблему ?

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

Здравствуйте, Аноним, Вы писали:

К>>(Если следовать STL-совместимости, то придётся решить ряд проблем; если нет, и всё не выйдет за пределы класса матрицы — то достаточно лишь доступа по индексу и функций создания/убивания элементов).

А>Мне сейчас будет не по силам делать совместимо с STL. Хотя, наверное, это будет интересно и поучительно для меня.
А>Я сейчас почитал про аллокаторы, пока мало чего понял, буду обдумывать еще. А вот про типизированную кучу, я ни чего не нашел. Вы имели в виду простой динамический массив, или что-то другое.

Я имел в виду кучу, в которой могут находиться только объекты одного и того же типа. Соответственно, блоки одного размера. Это значит, что не будет фрагментации, и здорово упрощает управление.
А будет ли эта куча сделана поверх массива, размер которого задаётся при компиляции или при создании; или же поверх списка массивов (deque — он обладает важным свойством: при reserve он не инвалидирует ссылки на свои элементы) или просто в виде списка (так, чисто для отладочных целей)... это большого значения не имеет.

На самом деле, с аллокатором всё очень просто.
Это объект, который имеет 2 функции: выделить память и утилизировать память.
(Ну, там разных функций больше — но сводятся они к этим двум).

Но, в отличие от malloc/free или new/delete, он заведомо (ещё при компиляции) знает тип объектов, с которыми имеет дело. Поэтому он может работать с типизированной кучей (которую сам внутри себя и поддерживает).
Кроме того, аллокатор уверен: указатель, который ему отдали на убиение — заведомо указывает на объект из его собственной кучи; и, например, он может вычислить индекс блока.

Иногда аллокатор может использоваться для того, чтобы более-менее безболезненно сопровождать контейнеры, чьи внутренние структуры размещены разными менеджерами стандартной кучи (например, две DLL со статическим CRT — у каждой из них свой собственный менеджер, и нужно уметь обратиться именно к нему).

Но главное не это. STL-аллокаторы взаимозаменяемы.
То есть, ты можешь заостриться на отладке своей матрицы с обычным std::allocator<YourMatrixItem> (элементы индексной таблицы — указатели!), а потом оптимизировать её, заменив стандартный на your_matrix_item_allocator.
Возможно, что тебе даже не понадобится сделать этот шаг.