stack size в Visual Studio

[niktagor]

 Добрый день. Прошу прощения, если не в ту ветку. В компиляторах последнее сообщение просто датируется июлем. Пытаюсь объявить массив большого размера в Visual Studio. Программа вызывает ошибку, если размер больше 1 МБ. Мучение поиска привело к выводу, что нужно менять stack size проекта. Делаю все, как написано тут: http://msdn.microsoft.com/en-us/library/tdkhxaks.aspx Но не помогает. Какие могут быть причины? Возможно, меня не только размер стека ограничивает?

[Пантер]

Массив чего? Может через указатели сделать?

[Alex_cs_gsp]

Размер адресного пространства для стека действительно по-умолчанию 1Мб. При переполнении стека возникает исключение.  Можно использовать ключ компоновщика /STACK: [reserve],[commit], где reserve - объем виртуальной памяти (наибольший размер, который может иметь стек) commit -физической, которая изначально доступна.  Но этим злоупотреблять не нужно, лучше использовать динамическую память.

[Anchorite]

Используй std::vector

[niktagor]

 /STACK: [reserve],[commit] не помогло. Редактировал эти параметры в настройках проекта.

[Alex_cs_gsp]

/STACK: [reserve],[commit] не помогло. Редактировал эти параметры в настройках проекта.

А код ошибки компиляции сказать можешь, чтобы не гадать? Никогда с таким не сталкивался, но по-видимому возможно, что если объявлен массив в стековой памяти с объектами совокупный sizeof которых более 1Мб, то компоновщик (или компилятор, не знаю) что-нибудь скажет.

[Igors]

/STACK: [reserve],[commit] не помогло. Редактировал эти параметры в настройках проекта.

Неверным путем идете. Данные такого размера размещаются в куче или используются контейнеры (которые сами разместят в той же куче). Пример

Код

C++ (Qt)
// объявление
#define NUM_ELEM   (1000 * 1000)
QVector <double> myData;
myData.resize(NUM_ELEM);
// использование
myData[0] = 5.0;
 

[niktagor]

 А если мне с этими данными высокопроизводительные вычисления делать нужно? Например БПФ на 4096 точек в реальном времени? Векторы все эти - от нечистого. Я хочу работать с данными по указателю. Неужели компьютер с 4ГБ оперативной памяти не может выделить в ней непрервный кусок размером 4МБ? Это ведь 0,1% всего!

[spectre71]

А если мне с этими данными высокопроизводительные вычисления делать нужно? Например БПФ на 4096 точек в реальном времени? Векторы все эти - от нечистого. Я хочу работать с данными по указателю. Неужели компьютер с 4ГБ оперативной памяти не может выделить в ней непрервный кусок размером 4МБ? Это ведь 0,1% всего!

Естественно, что разнообразные библиотечные списки(векторы...) для ординарных случаев.
Ну так и выделяй в куче память под свой массив! Зачем тебе выделять на стеке?

[Alex_cs_gsp]

     Нет я думал ради науки поиграться. А как вы думаете где стек потока находится - также в динамической памяти. Выделите большой кусок, какой вам нужен, а потом делите его как вам хочется, например, сделайте свой менеджер, перегрузив оператор new.
   Если стл, то используйте в векторе метод reserve, который резервирует память, пусть сразу выхватит из кучи памяти, сколько вам нужно. Насчет контейнеров не знаю, но вот алгоритмы stl точно тормозные, когда-то игрался с сортировками, так написанная мною быстрая сортировка и даже сортировка Шелла обходили библиотечную быструю, правда это от компилятора также зависит.

[Igors]

А если мне с этими данными высокопроизводительные вычисления делать нужно? Например БПФ на 4096 точек в реальном времени? Векторы все эти - от нечистого. Я хочу работать с данными по указателю. Неужели компьютер с 4ГБ оперативной памяти не может выделить в ней непрервный кусок размером 4МБ? Это ведь 0,1% всего!

Тогда так

Код

C++ (Qt)
double * myData = new double[NUM_DATA];
...
// когда использование закончено, нужно удалить
delete [] myData;
 

но вот алгоритмы stl точно тормозные, когда-то игрался с сортировками, так написанная мною быстрая сортировка и даже сортировка Шелла обходили библиотечную быструю, правда это от компилятора также зависит.

Я так понимаю дело было в MSVC в режиме debug и всем страхомудием включенным (ITERATOR_DEBUG и.т.д)  

[Alex_cs_gsp]

Я так понимаю дело было в MSVC в режиме debug и всем страхомудием включенным (ITERATOR_DEBUG и.т.д)  

Ага, только я про алгоритмы, контейнеры не тестил. Использовал массивы, т.к. вместо итератора можно передать указатель.

[niktagor]

double * myData = new double[NUM_DATA];

Спасибо, работает! А что при этом происходит? Создается обычный массив в непрерывном куске памяти? Или это какой-то C++ класс double со своими фишками? Я смогу с этим работать по указателю, вычисляя адрес как &MyData + N*sizeof(double)

[Alex_cs_gsp]

Только не   &myData + N*sizeof(double), а myData + N. myData  - уже указатель на первый элемент массива. Для пользователя (программиста) память выглядит непрерывной, как на самом-деле неизвестно. Потом не забудьте удалить память. Советую прочитать какую-нибудь литературу по С++ или даже по Си.

[Igors]

double * myData = new double[NUM_DATA];

Спасибо, работает! А что при этом происходит? Создается обычный массив в непрерывном куске памяти? Или это какой-то C++ класс double со своими фишками? Я смогу с этим работать по указателю, вычисляя адрес как &MyData + N*sizeof(double)

1) Это "экологически чистый" массив, скорость доступа такая же как для myData[NUM_ELEM].

2) Адресную арифметику надо подучить.

Код

C++ (Qt)
double * myData = new double[NUM_ELEM];
myData[4] = 5.0;         // указатель и есть массив
*(myData + 4) = 2.0;  // то же что и myData[4]
 
*(myData + 4 * sizeof(double)) = 1.0;   // а это уже myData[32] 
 

3)

Для пользователя (программиста) память выглядит непрерывной, как на самом-деле неизвестно.

Имеется ввиду что современные ОС могут выделять больше памяти чем есть физически. Но это верно для любых распределений и совсем не значит что new "хуже". Есть небольшие расходы на само new/delete - но это (в данном случае) операция одноразовая