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

@geg_Ma3gau · Регистрация: 26.02.2011

Author24 — интернет-сервис помощи студентам

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

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

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

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

@Jewbacabra · 25.10.2014, 16:31

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

@TheCalligrapher · 26.10.2014, 01:21

Сообщение от geg_Ma3gau

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

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

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

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

C

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

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-битных платформах вы можете таким образом выделить массив любого обозримого размера.

@geg_Ma3gau · 27.10.2014, 00:47 **[ТС]**

Верхний вариант.

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

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

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

Нижний вариант

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

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

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

Сейчас попробую.

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

C

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))]'
В данной строке нельзя приравнивать переменные разных типов.

Динамический массив создаю таким образом, как по ссылке Как правильно создать двумерный массив указателей с использованием calloc? и ввод данных в него

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

C

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

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

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

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

@Jewbacabra · 27.10.2014, 00:55

Сообщение от geg_Ma3gau

int (*arr)[M][K] = malloc(N * sizeof *arr); //<-----вот тут выдаётся ошибка

Используй C компилятор, а не C++, либо явно приведи тип

C

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

@geg_Ma3gau · 27.10.2014, 01:23 **[ТС]**

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

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

C

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-мерному массиву.

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

C

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);
}

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

@TheCalligrapher · 27.10.2014, 05:49

Сообщение от geg_Ma3gau

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

C

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))]'
В данной строке нельзя приравнивать переменные разных типов.

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

Сообщение от geg_Ma3gau

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

C

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

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

Сообщение от geg_Ma3gau

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

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

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

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

@Alexandr_1982 · 27.10.2014, 06:47

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

@taras atavin · 27.10.2014, 06:53

Сообщение от Alexandr_1982

т количества оперативной памяти зависит. 80x80x80 съедает примерно 500 мегабайт.

Это какого же типа элементы по целому килобайту весят?

@TheCalligrapher · 27.10.2014, 08:38

Сообщение от Alexandr_1982

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

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

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

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

@taras atavin · 27.10.2014, 08:41

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

@TheCalligrapher · 27.10.2014, 08:50

Сообщение от taras atavin

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

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

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

@taras atavin · 27.10.2014, 09:11

Сообщение от TheCalligrapher

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

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

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

Сообщение от TheCalligrapher

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

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

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

@TheCalligrapher · 27.10.2014, 09:33

Сообщение от taras atavin

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

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

Сообщение от taras atavin

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

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

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

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

Сообщение от taras atavin

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

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

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

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

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

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

C

#include <stdlib.h>
 
#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];
}

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

@taras atavin · 27.10.2014, 10:00

Сообщение от TheCalligrapher

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

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

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

Сообщение от TheCalligrapher

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

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

@geg_Ma3gau · 27.10.2014, 13:39 **[ТС]**

Я тут уже применяю массивы наподобие 200 на 200 на 600, так что ничего не падает )). Больше для меня смысла нет, т к дифур идёт в разнос.

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

Добавлено через 6 минут
A ту ошибку я поправил, все заработало. Просто указал явно тип переменной, которую должен вернуть malloc, там это где-то сверху уже написано.

@SmittWesson · 27.10.2014, 13:58

Сообщение от geg_Ma3gau

Хотелось бы иметь больше узлов сетки в будущем.

Для такого кода, это нормально. Дело в том, что с квадратными скобками, для массивов выдляется определённое пространство. При его заполнении, получите ошибку переполнения. Для расширения этой области, в Си, существует malloc и callok. Не очень разбирался в их работе, т.к. сразу "подсел" на С++. В С++, для распределения памяти, ипользуется оператор new - del. Его конструктор, выделяет память динамически, причём не резервируя какую-то область. Советую пользоваться именно ним. Хотя.... (у каждого, свои тараканы в голове).

Сообщение от taras atavin

На спектруме этому мешает расположение в младших адресах зашитых в ПЗУ интерпретатора и системы

Тарас. Ты мне всё больше и больше нравишься

. +1.

@Jewbacabra · 27.10.2014, 14:30

Сообщение от SmittWesson

При его заполнении, получите ошибку переполнения.

к сожалению не обязательно

Сообщение от SmittWesson

Для расширения этой области, в Си, существует malloc и callok.

какой области? malloc calloc используются для динамического выделения памяти

Сообщение от SmittWesson

Его конструктор

Кого?

Сообщение от SmittWesson

Советую пользоваться именно ним.

Это совет для соседнего раздела

@SmittWesson · 27.10.2014, 14:37

Сообщение от Jewbacabra

к сожалению не обязательно

Именно "к сожалению". Для хакеров, лакомый кусок.

Сообщение от Jewbacabra

какой области? malloc calloc используются для динамического выделения памяти

Не знаю. Знаю, чо беспрерывная. Сталкивался.

Сообщение от Jewbacabra

Это совет для соседнего раздела

Возможно. Я на форуме - новичёк, но не в жизни.

@taras atavin · 27.10.2014, 14:42

Кстати, а какие такие принципиальные препятствия против построения стека не на массиве, но и на списке массивов? Не делают и не целесообразно - это да.

@TheCalligrapher Вездепух 12802 / 6677 / 1797 Регистрация: 18.10.2014 Сообщений: 16,902
	27.10.2014, 08:50	12
	Сообщение от taras atavin Но стек то располагается в физической оперативной, а не вируальной памяти. Это откуда вы такое взяли? Вся память процесса, включая стек, располагается в виртуальном адресном пространстве процесса. Это относится и к коду процесса, и к стеку процесса и ко всем остальным данным процесса. Причина, по которой невозможно определять большие локальные переменные, заключается в том, что размер стека процесса ограничен. Но это не имеет никакого отношения ни к какой оперативной памяти. Это обусловлено просто тем, что диапазон адресов для будущего стека должен быть зафиксирован заранее, еще во время компиляции программы. И никто не заказывает себе стеки гигантского размера - это не нужно. В 32-битных системах, где адресное пространство ограничено, это было бы просто расточительно. В 64-битных системах вы, при желании, можете назначить себе огромный стек. Но так делать просто не принято. Стек не предназначен для гигантских объектов. 0

@taras atavin 4226 / 1796 / 211 Регистрация: 24.11.2009 Сообщений: 27,562
	27.10.2014, 10:00	15
	Сообщение от TheCalligrapher Нет. Так традиционно и исторически сложилось, что стек в машинных платформах растет сверху вниз, т.е. от старших А разве я сказал, что над вершиной? С учётом направления роста стека и положения вершины под дном за - это как раз под, то есть на адресах младше стековых. Добавлено через 20 минут Сообщение от TheCalligrapher Так, например, обстоят дела в Intel платформах. Т.е. вершина стека изначально располагается по адресу, скажем, 0x100000 и постепенно опускается в направлении младших адресов (условно говоря - в направлении адреса 0x0). Именно по этой причине стек не может расширяться. А кто мешает переполнить адрес на вычитании и продолжить расти с верхней границы адресного пространства? На спектруме этому мешает расположение в младших адресах зашитых в ПЗУ интерпретатора и системы, а между стеком и ПЗУ ещё и видеостраницы. Но пока стек не дорос до видеопамяти, между ним и видеопамятью можно выделять память. И эйси, пусть от 0x100000 до ноля. 256 килобайт максимального размера и 256 килобайт постоянного размера - не одно и то же, команда pop стек сокращает. И нет ни одного принципиального препятствия против того, чтоб двинуть весь сегмент в тот момент, когда он упрётся в нижнюю границу, на 256 килобайт вверх, а адресовать всегда не в абсолютных адресах а относительно указателя дна стека. Но это надо проверять, какая память могла попасть на эти адреса и перемещать и её тоже и можно получить кучу проблем в том случае, если на том месте, куда надо передвинуть стек, вдруг оказалась хотябы одна страница, перемещать которую по адресному пространству запрещено. Так не делают даже полные извращенцы, но это не значит, что стек не может быть большим. Он по факту не бывает совсем уж гигантским. И по факту на всех современных машинах имеет зарезервированный размер. Зарезервированный, то есть задана лишь верхняя граница размера стека и на тех адресах, куда он в принципе может расти, не выделятся ни какая другая память. Но фактический размер стека бывает и меньше и меняется при каждом вызове подпрограммы, или возврате. И чтоб гигантский стек и дальше не становился экзотическим системным требованием, использовать его надо экономно, а не заводить в нём массивы по миллиону элементов. 0

@SmittWesson 236 / 196 / 21 Регистрация: 04.06.2014 Сообщений: 1,309
	27.10.2014, 13:58	17
	Сообщение от geg_Ma3gau Хотелось бы иметь больше узлов сетки в будущем. Для такого кода, это нормально. Дело в том, что с квадратными скобками, для массивов выдляется определённое пространство. При его заполнении, получите ошибку переполнения. Для расширения этой области, в Си, существует malloc и callok. Не очень разбирался в их работе, т.к. сразу "подсел" на С++. В С++, для распределения памяти, ипользуется оператор new - del. Его конструктор, выделяет память динамически, причём не резервируя какую-то область. Советую пользоваться именно ним. Хотя.... (у каждого, свои тараканы в голове). Сообщение от taras atavin На спектруме этому мешает расположение в младших адресах зашитых в ПЗУ интерпретатора и системы Тарас. Ты мне всё больше и больше нравишься . +1. 0

Новые блоги и статьи
Как написать микросервис с нуля на C# InfoMaster 14.01.2025 В современном мире разработки программного обеспечения микросервисная архитектура стала стандартом де-факто для создания масштабируемых и гибких приложений. Этот архитектурный подход предполагает. . .	Как создать интернет-магазин на PHP и JavaScript InfoMaster 14.01.2025 В современном мире электронная коммерция стала неотъемлемой частью бизнеса. Создание собственного интернет-магазина открывает широкие возможности для предпринимателей, позволяя достичь большей. . .	Как написать Тетрис на Ассемблере InfoMaster 14.01.2025 Тетрис – одна из самых узнаваемых и популярных компьютерных игр, созданная в 1984 году советским программистом Алексеем Пажитновым. За прошедшие десятилетия она завоевала симпатии миллионы людей по. . .	Как создать игру "Танчики" на Unity3d и C# InfoMaster 14.01.2025 Разработка игр – это увлекательный процесс, сочетающий в себе творчество и технические навыки. В этой статье мы рассмотрим создание классической игры "Танчики" с использованием Unity3D и языка. . .	Организую платный онлайн микро-курс по доработке Android-клиента Telegram _Ivana 14.01.2025 Официальная версия и распространенные форки не полностью устраивают? Сделай свою кастомную версию клиента! 4 занятия по 2 часа (2 недели пн, ср 19:00-21:00 по Москве). Первое вводное занятие. . .	Как создать приложение для фитнеса для iOS/iPhone на Kotlin InfoMaster 14.01.2025 Создание собственного фитнес-приложения — это не только захватывающий, но и полезный процесс, ведь оно может стать вашим верным помощником на пути к здоровому и активному образу жизни. В современных. . .
Как создать приложение магазина для iOS/iPhone на Swift InfoMaster 14.01.2025 Введение в разработку iOS-приложений Разработка приложений для iPhone и других устройств на базе iOS открывает огромные возможности для создания инновационных мобильных решений. В данной статье мы. . .	Это работает. Скорость асинхронной логики велика. Вопрос видимо останется в стабильности. Плата - огонь! Hrethgir 13.01.2025 По прошлому проекту в Logisim Evolution https:/ / www. cyberforum. ru/ blogs/ 223907/ blog8781. html прилагаю файл архива проекта Gowin Eda и снимок. Восьмибитный счётчик из сумматора+ генератор сигнала. . .	UserScript для подсветки кнопок языков программирования в зависимости от текущего раздела volvo 13.01.2025 В результате работы этого скрипта подсвечиваются нужные кнопки не только в форме быстрого ответа, но и при редактировании сообщения: / / ==UserScript== / / @name CF_DefaultLangSelect / / . . .	Введение в модели и алгоритмы машинного обучения InfoMaster 12.01.2025 Машинное обучение представляет собой одну из наиболее динамично развивающихся областей искусственного интеллекта, которая фокусируется на разработке алгоритмов и методов, позволяющих компьютерам. . .	Как на Python создать нейросеть для решения задач InfoMaster 12.01.2025 В контексте стремительного развития современных технологий особое внимание уделяется таким инструментам, как нейросети. Эти структуры, вдохновленные биологическими нейронными сетями, используются для. . .	Как создать нейросеть для генерации картинок на Python InfoMaster 12.01.2025 Генерация изображений с помощью искусственных нейронных сетей стала одним из наиболее захватывающих направлений в области компьютерного зрения и машинного обучения. В этой статье мы рассмотрим. . .

@geg_Ma3gau 1 / 1 / 0 Регистрация: 26.02.2011 Сообщений: 23
		1
	Каков максимальный размер массива? 25.10.2014, 16:20. Показов 17435. Ответов 36 Метки нет (Все метки) Я занимаюсь интегрированием на прямоугольных сетках, для записи значений в узлах сетки я использую тройной массив arr[][][]. программа ещё терпит, когда массив я задаю размером 45x45x45, однако 50x50x50 уже не поддерживается, прога выдаёт ошибку в винде. Хотелось бы иметь больше узлов сетки в будущем. Как задавать массивы с большими размерностями, чем 45 45 45? Знаю, что указатель в общем-то задаёт 1d массив неизвестного размера, указатель на указатель- двумерный массив, указатель на указатель на указатель - 3-мерный массив. Правильно я думаю, что можно отказаться от записи arr[][][] и перейти на задание массивов указателями, чтобы можно было получить намного больше переменных при задании? Можно какие-то мысли мне на этот счёт рассказать, ну и если можно - показать как правильно пишется. Да, ещё приходится передавать массив в функции. 0

@Jewbacabra 4925 / 3920 / 1620 Регистрация: 24.04.2014 Сообщений: 11,441
	25.10.2014, 16:31	2
	geg_Ma3gau, размер статического массива в локальной области видимости как минимум не должен превосходить размер стека. Смотри в сторону динамического выделения памяти. 0

@Alexandr_1982 191 / 90 / 33 Регистрация: 04.11.2013 Сообщений: 474 Записей в блоге: 4
	27.10.2014, 06:47	8
	От количества оперативной памяти зависит. 80x80x80 съедает примерно 500 мегабайт. На 90x90x90 уже более 700 мегабайт. На 100x100x100 из-за нехватки оперативной памяти, трехмерный массив падает. 0

@taras atavin 4226 / 1796 / 211 Регистрация: 24.11.2009 Сообщений: 27,562
	27.10.2014, 06:53	9
	Сообщение от Alexandr_1982 т количества оперативной памяти зависит. 80x80x80 съедает примерно 500 мегабайт. Это какого же типа элементы по целому килобайту весят? 0

@TheCalligrapher Вездепух 12802 / 6677 / 1797 Регистрация: 18.10.2014 Сообщений: 16,902
	27.10.2014, 08:38	10
	Сообщение от Alexandr_1982 От количества оперативной памяти зависит. 80x80x80 съедает примерно 500 мегабайт. На 90x90x90 уже более 700 мегабайт. На 100x100x100 из-за нехватки оперативной памяти, трехмерный массив падает. От количества оперативной памяти НЕ зависит. Приложения в современных операционных системах уже давно работают в виртуальной памяти. Размер оперативной памяти влияет на производительность системы и приложений, но никак не влияет на размер максимального массива. На размер максимального массива влияет только размер адресного пространства процесса, т.е. в первую очередь "битность" системы: 32 или 64 бит. Мне не знакомы системы, которые не позволяли бы создать трехмерный массив скалярных значений 100x100x100. Это какие-то несчастные 4 мегабайта? 0

@taras atavin 4226 / 1796 / 211 Регистрация: 24.11.2009 Сообщений: 27,562
	27.10.2014, 08:41	11
	Но стек то располагается в физической оперативной, а не вируальной памяти. 0

@taras atavin 4226 / 1796 / 211 Регистрация: 24.11.2009 Сообщений: 27,562
	27.10.2014, 09:11	13
	Сообщение от TheCalligrapher Это откуда вы такое взяли? Вся память процесса, включая стек, располагается в виртуальном адресном пространстве процесса. Это относится и к коду процесса, и к стеку процесса и ко всем остальным данным процесса. Есть виртуальные адреса памяти, а есть виртульная папять, то есть файл подкачки. Почитайте как про флаг разрешения свопинга страницы. Те данные, с которыми должен работать процессор, находятся в физической оперативной памяти и мало того, даже закачиваются в кеш, а свопятся на винт только те страницы, которые в данный момент не нужны. И даже приложение может запретить свопинг своих страниц, не говоря о самой системе. Причём, выборочно, то есть свопинг одних страниц запретить, а свопинг других страниц оставить разрешённым. При этом даже если конкретное данное используется в данный конкретный момент, не известно, на каком физическом адресе оно находится, потому что оно всё равно остаётся в виртуальном адресном пространстве. Гарантировать можно только его нахождение где то в пределах какой то неизвестной планки памяти. Стек же нужен постоянно, но не очень то велик. А зачем свопировать то, что и постоянно нужно, и много места не занимает? Так что от свопинга стека система только потеряет. Добавлено через 6 минут Сообщение от TheCalligrapher Это обусловлено просто тем, что диапазон адресов для будущего стека должен быть зафиксирован заранее. Нет. Даже на спектруме стек отлично рос и уменьшался. Ограничено адресное пространство, известна текущая вершина стека и его дно. Всё. Сразу за вершиной стека можно выделять память, но её надо освободить до того, как на этом место вырастет стек. Не освободишь - стек съест эти данные. Добавлено через 6 минут Просто перемещать стек в виртуальном адресном пространстве накладно, искать, какая именно страница мешает расти стеку и перемещать вместо стека её - тоже, при этом есть и неперемещаемые по требованию приложений страницы и из гарантированных способов даже не избежать глюков, а просто вовремя их обнаружить остался только стек зарезервированного размера. Но иметь фиксированный размер стек не может в силу самого принципа разрушающего чтения. 0

@geg_Ma3gau 1 / 1 / 0 Регистрация: 26.02.2011 Сообщений: 23
	27.10.2014, 13:39 [ТС]	16
	Я тут уже применяю массивы наподобие 200 на 200 на 600, так что ничего не падает )). Больше для меня смысла нет, т к дифур идёт в разнос. Caligrapher, я имел ввиду, что и в моей, и в Вашей программе именно 3д массивы, а 2д - в ссылке, которую я указывал, так что я ничего такого не хотел сказать. Добавлено через 6 минут A ту ошибку я поправил, все заработало. Просто указал явно тип переменной, которую должен вернуть malloc, там это где-то сверху уже написано. 0

@Jewbacabra 4925 / 3920 / 1620 Регистрация: 24.04.2014 Сообщений: 11,441
	27.10.2014, 14:30	18
	Сообщение от SmittWesson При его заполнении, получите ошибку переполнения. к сожалению не обязательно Сообщение от SmittWesson Для расширения этой области, в Си, существует malloc и callok. какой области? malloc calloc используются для динамического выделения памяти Сообщение от SmittWesson Его конструктор Кого? Сообщение от SmittWesson Советую пользоваться именно ним. Это совет для соседнего раздела 0

@SmittWesson 236 / 196 / 21 Регистрация: 04.06.2014 Сообщений: 1,309
	27.10.2014, 14:37	19
	Сообщение от Jewbacabra к сожалению не обязательно Именно "к сожалению". Для хакеров, лакомый кусок. Сообщение от Jewbacabra какой области? malloc calloc используются для динамического выделения памяти Не знаю. Знаю, чо беспрерывная. Сталкивался. Сообщение от Jewbacabra Это совет для соседнего раздела Возможно. Я на форуме - новичёк, но не в жизни. 0

@taras atavin 4226 / 1796 / 211 Регистрация: 24.11.2009 Сообщений: 27,562
	27.10.2014, 14:42	20
	Кстати, а какие такие принципиальные препятствия против построения стека не на массиве, но и на списке массивов? Не делают и не целесообразно - это да. 0