Создание безразмерного одномерного массива
Может, лучше использовать динамический массив?
Т е мне надо данные из файла считать в массив обьявить массив больше 65535 у меня не получилось поэтому я могу только открывать файлы размером не балее 64 кб, а надо хотя бы 3-5 метров
1) Больше 65535 чего? Элементов, или суммарной памяти?
2) Какая OS, среда?
3) Покажи участки кода.
У меня 65535 элементов вот код обьявления
const nmax = 65535;
type diapazon = 1..nmax;
masstr = array[diapazon] of char;
var mas :^masstr;
проще наверное будет с потоком: TFileStream
динамически:
getmem(c, 5*1024*1024)
либо выделяй память динамически. У тебя будет указатель на начало блока (переменная типа pointer), при необходимости обращения к части блока просто сдвигай этот указатель на необходимое количество байт:
допустим необходимо обратится к 1-ому байту (нумерация начинается с 0)
byte(pointer(dword(c)+1)^)=10
Стек автоматически расширяется. Но проблема в том, что есть куча (динамическая область памяти), которая тоже автоматически расширяется. Причем куч, в принципе, может быть несколько. И есть множество других областей памяти - код, память ядра и т. д. Так что даже при наличии виртуального адресного пространства в 4 ГБ все равно расширение упрется в другую область где-нибудь на паре сотен Мб.
А размер стека в настройках проекта, насколько мне известно, задает только начальный размер стека, а он, повторяю, может расширяться.
Можно выделить свою собственную область памяти (не в куче, а вообще - свою область), и сразу зарезервировать под нее побольше места, если заранее известно, что это место будет активно использоваться (я резервировал порядка 2,5 Гб, работало). Это не напряг для системы - ведь память можно не выделять реально, а просто резервировать, так, чтобы ее никто (в смысле, никакая другая область) не могла выделить или зарезервировать. А собственно выделение производить по мере необходимости. См. VirtualAlloc. Но проблема "упирания" в другие области остается.
А вообще, сортировка и все такое прочее легко производятся при отображении файлов на память, поскольку работа тут идет так же, как с памятью - не нужно вызывать операции чтения/записи файлов. Просто работаем с переменными. Но проблема ограничения памяти остается. Из этой проблемы есть выход - отображать файл на память окнами - создать несколько окон, спозиционированных в разные места файла, как только требуется читать/писать данные в другое место, куда нет окна - создавать новое окно, если кончилось адресное пространство - закрывать какое-то из других окон, которое не используется. См. CreateFileMapping и MapViewOfFile. Точно не знаю, но подозреваю, что некоторые СУБД могут пользоваться подобным алгоритмом.
Отмечу, что создание отображения в память не означает, что данные тут же прочитаются из файла - нет, операция практически мгновенная, данные будут читаться страницами при первом обращении к странице.
Все вышеописанное касается исключительно Windows.
...
А что, в Delphi/Kylix (я по ним не специалист) действительно существует такая проблема, как динамическое выделение памяти???
А что, в Delphi (я по ним не специалист) действительно существует такая проблема, как динамическое выделение памяти???
нет проблем с динмическим выделением памяти :) хош стандартные возможности, хош все API в твоем распоряжении
Мучения с CreateFileMapping/MapViewOfFile ради 3-5Мб - ИМХО, того не стоят...
Не совсем понятно тогда, откуда столь бурное обсуждение столь элементарной проблемы...