Делаю вот такой код:
a_table = new unsigned int[modulus];
b_table = new unsigned int[modulus];

Далее идет заполнение таблиц a_table и b_table . Но в диспетчере задач видно, как зажирается по ходу исполнения программы память. Под конец программа падает.

Очевидно, что new[] не выделяет память, а резервирует (что объяснило бы постоянное увеличение памяти), существует ли разумный способ именно выделить память в куче? Стэк и глобальный массив не предлагать. И как такой механиз вообще мог вызвать падение?

| Сообщение посчитали полезным:

int AllocMem(). я на тоже самое ток в делфе наступил, когда переменные начали наезжать на код,затирая его.. причем это были динамические массивы.

-----
Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме....

| Сообщение посчитали полезным:

Такое возможео при стандартных утечках. Память периодически выделяем и не возвращаем. На каждый new должен быть свой delete, если я правильно понял суть проблемы. Причём на массив это должен быть delete [] var.

-----
Следуй за белым кроликом

| Сообщение посчитали полезным:

neomant
Ну допустим у меня есть такой delete[] на каждый из массивов. Программа падает ДО вызова delete. Основная операция в цикле заполнения - операция умножения, вынесенная в отдельную процедуру. Процедура вызываетя нерекурсивно, результат берется по модулю, соответствующему размера массива. Т.е. выход за диапазон массива исключается. Все индексы беззнаковые, т.е. пишется точно туда.

| Сообщение посчитали полезным:

int проверь, не нализают ли данные на код!
ЗЫ во время падеша посмотри вверх модуля по коду, не затерт ли?

-----
Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме....

| Сообщение посчитали полезным:

int
Никогда не возникала у меня такая ситуация со встроенными new и delete. Возможно, если вы выделяете, скажем, так:



И предположим, что modulus = 5. Так вот к такому динамическиому массиву нельзя обратиться так:



Т.е. обратиться-то можно, и, скорее всего, это не вызовет иксепшена, но вы затрёте участок служебной инфы, которая используется диспетчером куч, и delete[] не отработает. И да, будет утечка либо сбой, либо всё вместе.

Если, конечно, есть уверенность, что это имеено криворукая реализация компилятора, то перегружайте new, и юзайте API HeapCreate/HeapDestroy/HeapAlloc/HeapFree.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

Давайте посмотрим код выделения, работы с массивом, освобождения. Ну чудес ведь не бывает. И в 99.9% это ошибки реализации, а не компиляторов.

-----
Следуй за белым кроликом

| Сообщение посчитали полезным:

int пишет:
И как такой механиз вообще мог вызвать падение?
выход за границы массива
проверяется легко (кроме случая ручками правит <= на < в циклах)
взять какой нибудь std::array
ну или std::vector
или любой самописный с улучшеными оптимизациями,
и если есть выход за границы то ексепшен в лучшем случае поймаешь

---
ох что то я ступил, думал об одном посоветовал другое
банально умный указатель на массив(scoped_array/shared_array) и ненадо никаких array и vector
выход за границы по оператору operator[] там тоже ексепшен

| Сообщение посчитали полезным:

reversecode +1! я о чем говорю.. я убил както воскресенья в попытке понять где борланд накосячил с дниамическими массивами.. типа SetLenth +1 на 3ей итерации убивал всю прогу.. перерыл 2 модуля, оказалось компиллер гонит. в делфе об этом говорица как рекомендация.. не рекомендуеца часто изменять размеры выделенной памяти.. козлы. вобщем либо руками АЛОК либо статик массив с запасом

-----
Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме....

| Сообщение посчитали полезным:

Да не, все оказалось банально. Глаза замылились просто.

for (i = 0; i < modulus / 20; j++)

"Буковки похожие".

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

| Сообщение посчитали полезным:

1) особенность работы malloc / можно проверить на разных студиях
2) особенности работы MMU разной версии винды/ тоже можно проверить

после чего легко можно вынести вердикт,
исходники malloc есть в студиях

свой вариант, переопределять new/delete под аллокатор который сразу будет резервировать всю память

----
сделай например memset после new
что бы зарезервировать в MMU место

| Сообщение посчитали полезным:

Может конечно "пальцем в небо", но мне этот прием когда-то помог разобраться с довольно загадочным memory leak.
Гляньте, если интересно:
http://www.abstraction.net/content/articles/analyzing%20the%20heaps%20of%20a%20win32%20process.htm

-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным:

int пишет:
Но тем не менее, это не ответ на вопрос, почему размер памяти растет по мере ее использования, а не сразу после выделения.
Если приложение GUI, то сама ОС что-то там выделяет/освобождает под свои нужны в куче приложения. Обычно это не растёт до бесконечности и лечится сворачиванием-разворачиванием окна.

-----
Следуй за белым кроликом

| Сообщение посчитали полезным:

Новая проблема. Не дают выделить память.

На 4-ой строке вылет по std::exception "bad allocation". Как обходить?

Добавлено:
Перекомпилил в 64 бита, все ОК!

| Сообщение посчитали полезным:

"Никогда не возникала у меня такая ситуация со встроенными new и delete. Возможно, если вы выделяете, скажем, так:

Code:

a_table = new unsigned int[modulus];



И предположим, что modulus = 5. Так вот к такому динамическиому массиву нельзя обратиться так:

Code:

a_table[5]



Т.е. обратиться-то можно, и, скорее всего, это не вызовет иксепшена, но вы затрёте участок служебной инфы, которая используется диспетчером куч, и delete[] не отработает. И да, будет утечка либо сбой, либо всё вместе."

Зачем столько фольклора: есть термин -> Undefined behaviour, два слова и всё ясно.

| Сообщение посчитали полезным:

TheNozza
Друг, шел бы ты на RSDN, Кодта плюсам учить. В большинстве RE кода такое месиво, что волосы дыбом встают. Здесь больше беспокоятся о результате, чем о красоте промышленного кода.
И таки да, школьники и студенты начальных курсов - часть типового портрета здешнего обитателя.

-----
старый пень

| Сообщение посчитали полезным: