Есть ли у GCC в MinGW ограничения на объём переменных?

Afaik для win32 ограничение 2Гб, может еще gcc сокращает, но это уже врядли.

Быдло-виста? 32Mb для всех консольных

Как память выделяешь для массивов? Выделяй в куче, а не на стеке.

> Быдло-виста? 32Mb для всех консольных

Говорят в Windows 7 Билл отыграется на всех злых шутниках, вспоминавших ему про 640к, и урежет "консольному миру" память до 640к на 1 приложение.

> Как память выделяешь для массивов?

Просто объявляю внутри main()

double array1[2008], array2[2008][2009]; и т.п.

> Выделяй в куче, а не на стеке.

Это как? Использовать malloc?

> Это как? Использовать malloc?

Имено, либо `new' в C++, если речь о плюсах. Не забывай про free :)

+ либо использовать STL'ные контейнеры в случае плюсов.

> для win32 ограничение 2Гб, может еще gcc сокращает

Про gcc и спрашиваю. У меня от силы на 2 мегабайтах массивов начинает падать.

> Быдло-виста? 32Mb для всех консольных

Откуда данные? С эмуляцией MS-DOSа не путаешь? Кроме того, проблемы начинаются уже на 2 мегабайтах.

> Говорят в Windows 7 Билл отыграется на всех злых шутниках, вспоминавших ему про 640к, и урежет "консольному миру" память до 640к на 1 приложение.

Откуда данные? С эмуляцией MS-DOSа не путаешь? Проблемы начинаются уже на 2 мегабайтах.

Кроме того, XP

Ну увеличь размер стека при компиляции, если принципиально не желаешь использовать размещение в куче.

Возможно, что-то вроде этого: http://www.cygwin.com/ml/cygwin/2003-03/msg01394.html

> Не забывай про free :)

Тогда заодно спрошу: как его правильно использовать? У меня другая программа, где я использовал malloc близко к началу и free в самом конце, заканчивалась с ошибкой наподобие "попытка освободить память второй раз". Я предположил, что память освобождается автоматически при выходе, и убрал free совсем. Как правильно поступать в этом случае?

> Откуда данные? С эмуляцией MS-DOSа не путаешь? Кроме того, проблемы начинаются уже на 2 мегабайтах.

Про Windows 7 ясное дело, это чисо прикол, а про 32 Mb в висте, -- чистой воды серьезная правда: http://www.trnicely.net/misc/vista.html

Ааааа, КАПЧА: truered, я тру красноглазый (что в принципе верно, капельки капаю, что-бы воспаление прошло)

> Просто объявляю внутри main()
> double array1[2008], array2[2008][2009]; и т.п.

это только мне кажется, что за такое нужно линчевать без суда и следствия :-?

// wbr

> Ну увеличь размер стека при компиляции, если принципиально не желаешь использовать размещение в куче.

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

> Возможно, что-то вроде этого: http://www.cygwin.com/ml/cygwin/2003-03/msg01394.html

Спасибо, но не помогло.

> Возиться долго с кучей.

Это шутка такая? http://www.utdallas.edu/~rxc064000/dynamic_multi_dim.htm -- chapter 23.2: Dynamically Allocating Multidimensional Arrays

> http://www.trnicely.net/misc/vista.html

По ссылке написано "Windows Vista restricts non-Win32 apps to 32 MB of memory". Далее говорится о DJGPP и эмуляции доса.

Более того:

1. Поковырявшись в реестре можно увеличить этот предел.

2. В MinGW и GCC из Cygwin этого ограничения не наблюдали.

3. У меня XP.

> > Просто объявляю внутри main() double array1[2008], array2[2008][2009]; и т.п.

> это только мне кажется, что за такое нужно линчевать без суда и следствия :-?

Да, я даже до быдлокодера не дотягиваю. Можешь объяснить, что тебе так страшно не понравилось?

> Это шутка такая?

К сожалению, нет. Путаюсь в указателях :(

> http://www.utdallas.edu/%7Erxc064000/dynamic_multi_dim.htm

Спасибо. Зачем резервировать каждую строку массива отдельно? Нельзя ли запросить память для массива одним куском nrows*ncolumns*sizeof(int)?

Кроме того, по ссылке говорится про новые возможности в gcc и C99. О чём речь?

> http://www.utdallas.edu/%7Erxc064000/dynamic_multi_dim.htm

По ссылке оттуда на http://www.eumus.edu.uy/eme/c/c-notes_summit/intermediate/top.html ещё кое-что нашлось. Спасибо.

>double array1[2008], array2[2008][2009]; и т.п.

>Про gcc и спрашиваю. У меня от силы на 2 мегабайтах массивов начинает падать.

у тебя в одной этой строчке уже больше 30 Мб памяти выделено.

> у тебя в одной этой строчке уже больше 30 Мб памяти выделено.

Знаю. Первоначально было около 33 М во всех массивах, прекратило падать на ~2060400 байтах, когда уменьшил большой массив в ~16 раз.

>Можешь объяснить, что тебе так страшно не понравилось?

1. размер стека ограничен.
2. стек - это не место для хранения больших массивов данных. вынеси их в глобальные переменные либо обьяви как static либо создай в куче (malloc/new и не забудь их потом освободить free/delete)

> это только мне кажется, что за такое нужно линчевать без суда и следствия :-?

Ну не так строго, но заставить почитать умные книжки стоит.

> Да, я даже до быдлокодера не дотягиваю. Можешь объяснить, что тебе так страшно не понравилось?

выделять данные на стеке такими массивами? это явное надругательство над системой [любой] и она честно бьёт за это по рукам.

man malloc

// wbr

> стек - это не место для хранения больших массивов данных.

Спасибо.

> вынеси их в глобальные переменные либо обьяви как static либо создай в куче

Можно ли объявлять массив как static внутри функции?

> не забудь их потом освободить free/delete

Тогда повторю вопрос: http://www.linux.org.ru/jump-message.jsp?msgid=2865796&cid=2866168 Почему такая программа может в конце ругаться на двукратное освобождение памяти?

int main(int argc, char *argv[]){
// чтение данных из файла, вычисление cw
long int* ar=calloc(cw,4);
// чтение данных в массив ar[cw], работа с массивом
free(ar);}

> выделять данные на стеке такими массивами? это явное надругательство над системой

Понятно. Можно ли как-то объявлять переменные, чтобы они создавались не в стеке, а в куче, или только через malloc и аналоги?

Скорее всего твоя "работа с массивом" портит память

Если C++, то можно посмотреть в сторону STL::vector, который будет делать это за тебя. Да и не только в сторону вектора, но и других STL'ных контейнеров.

> Скорее всего твоя "работа с массивом" портит память

В смысле? Неправильные индексы массива, вместо записи в массив портятся другие области памяти? Этого нет, индексы массива всегда >=0 и <cw. Вплоть до того, что проверял правильность индекса при каждом обращении к ar[].

Если массивов несколько, в каком порядке вызывать для них free? В обратном порядку создания?

> В обратном порядку создания?

Да. Но вообще лучше используй вектор, либо книжки почитай, либо смени язык.

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

> STL::vector

В него можно добавлять элементы через push_back только по одному?

> В смене языка ничего плохого нет.

Кроме времени на его изучение. :(

> В том же руби ты сможешь все свои мегабайты спокойно посчитать без угрозы жизни и здоровью окружающим

Во сколько раз он медленнее чем C? :)

>Почему такая программа может в конце ругаться на двукратное освобождение памяти?

может быть происходит выход за границы массива? в Си массивы начинаются с нулевого элемента и заканчиваются cw-1 элементом.

> выход за границы массива?

Многократно проверял: 0<=i<cw.

Но, кажется, нашёл: вызывалась функция из библиотеки, которая тоже резервировала память. Ту память надо отдать перед освобождением ar[]?

> Кроме времени на его изучение.

Судя по вопросам С ты не владеешь. Терять тебе нечего ))

> Во сколько раз он медленнее чем C? :)

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

4.2