Какой максимальный размер массива в c

мне надо чтоб элементы массива были по миллиону, но в этом случае делает ошибку, а когда берешь их например по 100000 то все делает нормально. Есть ли какое ограничение на это дело в с++, или у меня просто такой компилятор?

Последний раз редактировалось MaTBeu; 28.03.2010 в 23:26 .
Linux C++ Qt ARM
Регистрация: 30.11.2008
Сообщений: 3,030

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

Дилетант широкого профиля.

«Слова ничего не стоят — покажите мне код!» © Линус Торвальдс

Пользователь
Регистрация: 13.05.2009
Сообщений: 47

но когда у меня 100 000 было это же 400 кб.
у меня прост наверно нестандартный компилятор , dev-c++
попробуйте у кого борландский или от микрософта есть

Регистрация: 26.04.2008
Сообщений: 2,689

Раньше размер массива, а вернее размер всех переменных должен был укладываться в размер стека, который задаётся в параметрах компилятора. Однако, последнии борланды на это внимание не обращают и дают сразу 2 Гб.

Пользователь
Регистрация: 04.01.2010
Сообщений: 23

Так как переменные создаються в стэековой памяти, то ограничения идут именно оттуда. Если не ошибаюсь стек виндой выделяеться в размере 1Мб. У меня на Visual Studio 2008 правда дает создание массива array [100000000] до 8 нулей, при этом компилиться нормально. А вообще создавай массив в динамической памяти там размер ограничен только твоей оперативной памятью.

int *arr = new int [100000];

Каков максимальный размер массива?

Я занимаюсь интегрированием на прямоугольных сетках, для записи значений в узлах сетки я использую тройной массив arr[][][].

программа ещё терпит, когда массив я задаю размером 45x45x45, однако 50x50x50 уже не поддерживается, прога выдаёт ошибку в винде. Хотелось бы иметь больше узлов сетки в будущем.

Как задавать массивы с большими размерностями, чем 45 45 45? Знаю, что указатель в общем-то задаёт 1d массив неизвестного размера, указатель на указатель- двумерный массив, указатель на указатель на указатель — 3-мерный массив. Правильно я думаю, что можно отказаться от записи arr[][][] и перейти на задание массивов указателями, чтобы можно было получить намного больше переменных при задании?

Можно какие-то мысли мне на этот счёт рассказать, ну и если можно — показать как правильно пишется. Да, ещё приходится передавать массив в функции.

94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
Ответы с готовыми решениями:

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

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

Каков максимальный размер одномерного массива
Добрый день. Хочу узнать, можно ли создать в Visual Studio 2010 одномерный массив размером в.

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

Эксперт PHP

4877 / 3880 / 1609
Регистрация: 24.04.2014
Сообщений: 11,371

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

Эксперт C Эксперт С++

11126 / 6084 / 1663
Регистрация: 18.10.2014
Сообщений: 15,294

Цитата Сообщение от geg_Ma3gau Посмотреть сообщение

Как я понимаю, в вашем случае размер(ы) требуемого массива не известны на стадии компиляции, так?

Реализовывать многомерные массивы через двойные-тройные-и т.п. указатели можно, но не обязательно. Многоуровневые указатели используются для реализации т.наз. jagged/ragged массивов («рваных» массивов), в которых под-массивы меньшей размерности могут выделяться выборочно и независимо. Кстати, при работе с такими массивами не надо отказываться от синтаксиса ‘arr[][][]’ — этот синтаксис чудесным образом прекрасно работает и со «рваными» массивами, несмотря на то, что их семантика отличается от встроенных массивов.

Но так как вы пишете на языке С, вы можете просто воспользоваться поддержкой массивов переменного размера в языке (начиная с С99) и просто выделять ваш массив в динамической памяти одним блоком

1 2 3 4 5 6 7 8 9 10

int main() { size_t N = 10, M = 20, K = 35; int (*arr)[N][M][K] = malloc(sizeof *arr); . (*arr)[i][j][k] = 10; . free(arr); }

Альтернативный вариант будет выглядеть так

1 2 3 4 5 6 7 8 9 10

int main() { size_t N = 10, M = 20, K = 35; int (*arr)[M][K] = malloc(N * sizeof *arr); . arr[i][j][k] = 10; . free(arr); }

Максимальный размер массива в таком варианте будет ограничен не размером стека, а разрядностью платформы и наличием свободного адресного пространства. Т.е. на 64-битных платформах вы можете таким образом выделить массив любого обозримого размера.

Регистрация: 26.02.2011
Сообщений: 23

первая строчка: задание размеров массива

вторая:задание указателя на начало массива arr[i][j][k], причём этому указателю присваивается адрес с заранее выделенной памятью соответствующего размера функцией malloc. Видимо, эта функция как-то обходит ограничение на размер единовременно выделяемой памяти стеком.

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

первая строка: то же самое

вторая строка: аналогично верхнему варианту, однако создаётся указатель на массив размерности на 1 меньше, при этом по адресу указателя выделяется место для нужного количествa таких «маленьких» массивов, чтобы хватило в точности на прежний, большой

Третья строка: ну видимо, такое задание массива во второй строке позволяет языку СИ интерпретировать область соответствующую область памяти как самый обычный массив (так он и задан в языке си, т е как несколько массивов поменьше размерностью.)

Добавлено через 2 часа 48 минут
В общем, вышеизложенные примеры не прошли, вот с каким результатом

1 2 3 4 5

int N = 10; int M = 20; int K = 35; int (*arr)[M][K] = malloc(N * sizeof *arr); //

error: invalid conversion from `void*’ to `int (*)[((unsigned int)((int)M))][((unsigned int)((int)K))]’
В данной строке нельзя приравнивать переменные разных типов.

А у меня так удалось его создать

1 2 3 4 5 6 7 8 9 10 11 12

double ***arr; arr = (double ***)malloc(60 * sizeof(*arr)); for(int j=0 ; j60 ; j++) { arr[j] = (double **)malloc(40 * sizeof(*arr[j])); for(int k=0 ; k40 ; k++) { arr[j][k] = (double*)malloc(40 * sizeof(*arr[j][k])); } }

ПОПРАВИЛ Стоп я извиняюсь там была ошибка, теперь все хорошо спасибо всё получилось. Массив удаётся увеличивать.

Добавлено через 7 минут
Массив удаётся увеличивать насколько мне нужно и делать его куда более большим! Отлично получилось, спасибо.

Добавлено через 11 минут
Только в моём примере это, конечно, 3-мерный массив.

Эксперт PHP

4877 / 3880 / 1609
Регистрация: 24.04.2014
Сообщений: 11,371

Цитата Сообщение от geg_Ma3gau Посмотреть сообщение

int (*arr)[M][K] = malloc(N * sizeof *arr); //<-----вот тут выдаётся ошибка Используй C компилятор, а не C++, либо явно приведи тип

1 2 3 4

const int N = 10; const int M = 20; const int K = 35; int (*arr)[M][K] = (int(*)[M][K])malloc(N * sizeof(*arr));

Регистрация: 26.02.2011
Сообщений: 23

В общем, получается делать 3-мерный динамически заданный массив, не ограниченный в размерах стеком.

Сообщение выше: сейчас попробую.

1 2 3 4 5

int N = 10; int M = 20; int K = 35; int (*arr)[M][K] = (int(*)[M][K])malloc(N * sizeof *arr);

Да, так получилось без ошибки. Значит и такой способ тоже работает.

Добавлено через 5 минут
Да, работает на больших массивах, я проверил. 80 на 80 на 80 точно берет, и выше — тоже. Даже 180x180x180. В общем все хорошо.

Добавлено через 19 минут
Но хочу заметить, что вот этим способом в данном сообщении malloc применяется лишь по одной «оси» массива, а в другом способе — сразу по всем трём. Здесь наверняка стек зарежет массив на этапе создания двумерного массива arr[M][K], хотя это конечно куда более мягкое условие на размер стороны массива по сравнению с зарезанием по 3-мерному массиву.

хотя похоже, что вариант

1 2 3 4 5 6 7 8 9 10

int main() { size_t N = 10, M = 20, K = 35; int (*arr)[N][M][K] = malloc(sizeof *arr); . (*arr)[i][j][k] = 10; . free(arr); }

не имеет такого недостатка и тут тоже абсолютно нет ограничения стеком.

Эксперт C Эксперт С++

11126 / 6084 / 1663
Регистрация: 18.10.2014
Сообщений: 15,294

Цитата Сообщение от geg_Ma3gau Посмотреть сообщение

В общем, вышеизложенные примеры не прошли, вот с каким результатом

1 2 3 4 5

int N = 10; int M = 20; int K = 35; int (*arr)[M][K] = malloc(N * sizeof *arr); //

Это говорит о том, что вы используете компилятор С++. Я же сказал выше, что этот код — специально для С. Причем для более-менее современного С. И темой этого форума является именно С.

Цитата Сообщение от geg_Ma3gau Посмотреть сообщение

А у меня так удалось его создать

1 2 3 4

double ***arr; arr = (double ***)malloc(60 * sizeof(*arr)); . }

Вы строите именно то, что называется «рваным» массивом (jagged или ragged array).

Цитата Сообщение от geg_Ma3gau Посмотреть сообщение

Только в моём примере это, конечно, 3-мерный массив.

3-мерный массив у нас у обоих, только способ его организации разный. В моих примерах — стандартный языковый 3-мерный массив, т.е. фактически одномерный массив с выполняемым компилятором пересчетом индексов. Ваш массив — это «самодельный» массив, построенный совсем по-другому.

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

Оба варианта работоспособны. Выбирайте какой вам больше подходит.

191 / 90 / 33
Регистрация: 04.11.2013
Сообщений: 474
Записей в блоге: 4

От количества оперативной памяти зависит. 80x80x80 съедает примерно 500 мегабайт. На 90x90x90 уже более 700 мегабайт. На 100x100x100 из-за нехватки оперативной памяти, трехмерный массив падает.

4226 / 1795 / 211
Регистрация: 24.11.2009
Сообщений: 27,562

Цитата Сообщение от Alexandr_1982 Посмотреть сообщение

т количества оперативной памяти зависит. 80x80x80 съедает примерно 500 мегабайт.
Это какого же типа элементы по целому килобайту весят?

Эксперт C Эксперт С++

11126 / 6084 / 1663
Регистрация: 18.10.2014
Сообщений: 15,294

Цитата Сообщение от Alexandr_1982 Посмотреть сообщение

От количества оперативной памяти НЕ зависит.

Приложения в современных операционных системах уже давно работают в виртуальной памяти. Размер оперативной памяти влияет на производительность системы и приложений, но никак не влияет на размер максимального массива. На размер максимального массива влияет только размер адресного пространства процесса, т.е. в первую очередь «битность» системы: 32 или 64 бит.

Мне не знакомы системы, которые не позволяли бы создать трехмерный массив скалярных значений 100x100x100. Это какие-то несчастные 4 мегабайта?

4226 / 1795 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
Но стек то располагается в физической оперативной, а не вируальной памяти.

Эксперт C Эксперт С++

11126 / 6084 / 1663
Регистрация: 18.10.2014
Сообщений: 15,294

Цитата Сообщение от taras atavin Посмотреть сообщение

Но стек то располагается в физической оперативной, а не вируальной памяти.

Это откуда вы такое взяли? Вся память процесса, включая стек, располагается в виртуальном адресном пространстве процесса. Это относится и к коду процесса, и к стеку процесса и ко всем остальным данным процесса.

Причина, по которой невозможно определять большие локальные переменные, заключается в том, что размер стека процесса ограничен. Но это не имеет никакого отношения ни к какой оперативной памяти. Это обусловлено просто тем, что диапазон адресов для будущего стека должен быть зафиксирован заранее, еще во время компиляции программы. И никто не заказывает себе стеки гигантского размера — это не нужно. В 32-битных системах, где адресное пространство ограничено, это было бы просто расточительно. В 64-битных системах вы, при желании, можете назначить себе огромный стек. Но так делать просто не принято. Стек не предназначен для гигантских объектов.

4226 / 1795 / 211
Регистрация: 24.11.2009
Сообщений: 27,562

Цитата Сообщение от TheCalligrapher Посмотреть сообщение

Есть виртуальные адреса памяти, а есть виртульная папять, то есть файл подкачки. Почитайте как про флаг разрешения свопинга страницы. Те данные, с которыми должен работать процессор, находятся в физической оперативной памяти и мало того, даже закачиваются в кеш, а свопятся на винт только те страницы, которые в данный момент не нужны. И даже приложение может запретить свопинг своих страниц, не говоря о самой системе. Причём, выборочно, то есть свопинг одних страниц запретить, а свопинг других страниц оставить разрешённым. При этом даже если конкретное данное используется в данный конкретный момент, не известно, на каком физическом адресе оно находится, потому что оно всё равно остаётся в виртуальном адресном пространстве. Гарантировать можно только его нахождение где то в пределах какой то неизвестной планки памяти. Стек же нужен постоянно, но не очень то велик. А зачем свопировать то, что и постоянно нужно, и много места не занимает? Так что от свопинга стека система только потеряет.

Добавлено через 6 минут

Цитата Сообщение от TheCalligrapher Посмотреть сообщение

Это обусловлено просто тем, что диапазон адресов для будущего стека должен быть зафиксирован заранее.

Нет. Даже на спектруме стек отлично рос и уменьшался. Ограничено адресное пространство, известна текущая вершина стека и его дно. Всё. Сразу за вершиной стека можно выделять память, но её надо освободить до того, как на этом место вырастет стек. Не освободишь — стек съест эти данные.

Добавлено через 6 минут
Просто перемещать стек в виртуальном адресном пространстве накладно, искать, какая именно страница мешает расти стеку и перемещать вместо стека её — тоже, при этом есть и неперемещаемые по требованию приложений страницы и из гарантированных способов даже не избежать глюков, а просто вовремя их обнаружить остался только стек зарезервированного размера. Но иметь фиксированный размер стек не может в силу самого принципа разрушающего чтения.

Эксперт C Эксперт С++

11126 / 6084 / 1663
Регистрация: 18.10.2014
Сообщений: 15,294

Цитата Сообщение от taras atavin Посмотреть сообщение

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

Цитата Сообщение от taras atavin Посмотреть сообщение

И даже приложение может запретить свопинг своих страниц, не говоря о самой системе. [..]Стек же нужен постоянно, но не очень то велик. А зачем свопировать то, что и постоянно нужно, и много места не занимает? Так что от свопинга стека система только потеряет.

Это какая-то ерунда. Специфика использования стека такова, что как правило в оперативной памяти нужна лишь верхушка стека, где располагаются активные переменные. Весь стек никому в памяти не нужен. С чего бы это?

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

Операционные системы, конечно, могут оптимизировать свопинг стека как-то особенно, но утверждать, что стек не может свопиться вообще — это бред сивой кобылы. Почитайте любую литературу по архитектуре любой ОС с виртуальной памятью — там все написано.

Цитата Сообщение от taras atavin Посмотреть сообщение

Нет. Так традиционно и исторически сложилось, что стек в машинных платформах растет сверху вниз, т.е. от старших адресов к младшим. Так, например, обстоят дела в Intel платформах. Т.е. вершина стека изначально располагается по адресу, скажем, 0x100000 и постепенно опускается в направлении младших адресов (условно говоря — в направлении адреса 0x0). Именно по этой причине стек не может расширяться. Как только минимальный адрес достигнут, стеку больше некуда расти. Именно по этой причине вы должны задавать желаемый размер стека при компиляции программы. И начальный адрес стека определяется настройками линкера в процессе компиляции программы. В линкере MSVC это опция ‘/stack’. В линкере gcc это опция ‘—stack’.

Добавлено через 10 минут
(Возвращаясь к более ранним деталям дискуссии.)

Компилируя вашу программу с

gcc -m64 -Wl,—stack,2000000000 test.c

вы можете, например, объявлять локальные массивы из 500x500x500 элементов типа ‘double’

1 2 3 4 5 6 7 8 9

#include #define N 500 int main(void){ double a[N][N][N]; a[rand() % N][rand() % N][rand() % N] = rand(); return (int) a[rand() % N][rand() % N][rand() % N]; }

Но в любом случае это — извращение. Стек не предназначен для гигантских объектов. Если вам нужны огромные объекты — пользуйтесь динамической памятью.

4226 / 1795 / 211
Регистрация: 24.11.2009
Сообщений: 27,562

Цитата Сообщение от TheCalligrapher Посмотреть сообщение

Нет. Так традиционно и исторически сложилось, что стек в машинных платформах растет сверху вниз, т.е. от старших

А разве я сказал, что над вершиной? С учётом направления роста стека и положения вершины под дном за — это как раз под, то есть на адресах младше стековых.

Добавлено через 20 минут

Цитата Сообщение от TheCalligrapher Посмотреть сообщение

Так, например, обстоят дела в Intel платформах. Т.е. вершина стека изначально располагается по адресу, скажем, 0x100000 и постепенно опускается в направлении младших адресов (условно говоря — в направлении адреса 0x0). Именно по этой причине стек не может расширяться.

А кто мешает переполнить адрес на вычитании и продолжить расти с верхней границы адресного пространства? На спектруме этому мешает расположение в младших адресах зашитых в ПЗУ интерпретатора и системы, а между стеком и ПЗУ ещё и видеостраницы. Но пока стек не дорос до видеопамяти, между ним и видеопамятью можно выделять память. И эйси, пусть от 0x100000 до ноля. 256 килобайт максимального размера и 256 килобайт постоянного размера — не одно и то же, команда pop стек сокращает. И нет ни одного принципиального препятствия против того, чтоб двинуть весь сегмент в тот момент, когда он упрётся в нижнюю границу, на 256 килобайт вверх, а адресовать всегда не в абсолютных адресах а относительно указателя дна стека. Но это надо проверять, какая память могла попасть на эти адреса и перемещать и её тоже и можно получить кучу проблем в том случае, если на том месте, куда надо передвинуть стек, вдруг оказалась хотябы одна страница, перемещать которую по адресному пространству запрещено. Так не делают даже полные извращенцы, но это не значит, что стек не может быть большим. Он по факту не бывает совсем уж гигантским. И по факту на всех современных машинах имеет зарезервированный размер. Зарезервированный, то есть задана лишь верхняя граница размера стека и на тех адресах, куда он в принципе может расти, не выделятся ни какая другая память. Но фактический размер стека бывает и меньше и меняется при каждом вызове подпрограммы, или возврате. И чтоб гигантский стек и дальше не становился экзотическим системным требованием, использовать его надо экономно, а не заводить в нём массивы по миллиону элементов.

Какой максимальный размер массива в С++?

Я, максимально большой, создавала массив размером ~2ГБ, с помощью calloc’a/malloc’a в Win8-x64. С помощью new немногим меньше.

Остальные ответы

Язык не вешает ограничений на массивы в куче, это вопрос ОСи.
Тут похожая тема обсуждается
http://www.sql.ru/forum/207841/kakoy-maksimalnyy-razmer-massiva-mozhno-zadat-v-c

Ну смотря какой у тебя компилятор и какой код.
К примеру досовский реального режима с++ дает максимальный размер массива в 64к — несколько десятков байтов.
В винде 32 бита примерно 2 гб — обьем программы и системных областей (примерно 1.7 га).

Arduino.ru

Хочется прикинуть максимальный размер массива который можно разместить в своей программе.

Плата ArduinoMEGA2560 оригинал.

10Кb — это код. 2 массива с одинаковым размером BYTE myP[] = ;

Компилятор Arduino 1.0.1

Сколько можно втиснуть (зависит от компилятора?) 255 значений BYTE, 65535 значений? или больше?

Проверить самому пока нет возможности, надо переводить в программу значения.Если другой способ, типа линковки файла в котором лежат значения BYTE не в текстовом формате, а как BYTE 1байт — 1 значение?

Войдите на сайт для отправки комментариев

Сб, 04/05/2013 — 00:17
Зарегистрирован: 12.02.2012

Зависит от объема оперативной памяти.

Войдите на сайт для отправки комментариев

Сб, 04/05/2013 — 00:49
Зарегистрирован: 10.06.2012

всего 8K ОЗУ?? за минусом переменных программы?

в ZX -SPECTRUME было 48К, в продвинутых 128К, потом 1М приделали.

а флешпамять 256К только для программы? нельзя ли её задействовать? Только на чтение.

Надо под рукой иметь 2 массива максимально по 64Кb в качестве значений «волны» для ЦАП.

сказано «Для синусоидально сигнала, я написал простой скрипт на Python, который выводит 20000 значений»

«сохранил этот массив в памяти Arduino под названием sine20000[] и беру из него значения которые необходимо отправить в ЦАП. Это намного быстрее, чем вычислять значения каждый раз.»

вроде дошло ключ PROGMEM указывает где массив воткнуть, проверю как соберу данные

Войдите на сайт для отправки комментариев

Какой максимальный размер массива в c