как создать массив не известной длинны?

Здраствуйте!

можно конечно объявить буффер в самом конце секции данных и никаких проблем казалось бы, но мне нужно несколько массивов, как лучше сделать?

буду очень признателен за любую помощь

 

СОЗДАТЬ массив неизвестной длинны нельзя, её все же надо знать. Есть неслосько способов, например:
buff dd ?
...
invoke LocalAlloc,LPTR,10
mov [buff],eax
...

все, создан массив в 10 байт. В переменной buff хранится адресс этого массива.
После использования надо освобождать буфер.
invoke LocalFree,[buff]

 

twgt

Можно создавать кусками, пользуясь функцией realloc.

 

Но ведь куски тоже имеют размер

 

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

 

Теперя ясно

 

Вы что товарищи? - какой LocalAlloc, realloc, куски, списки?
Правильный ответ на этот вопрос:
VirtualAlloc - снача резервируем c большим запасом адресное пространство (флаг MEM_RESERVE)
а затем по мере необходимости заполняем его реальной памятью (флаг MEM_COMMIT)
Имхо лучше это наращивание в SEHе делать, как Дядка Рихтер советует

 

Хочеш сказать что мой метод не верный?
По другим темам, создаваемым автором этой темы ясно что он тока учится, собственно как и я, и теперь давай, объясняй ему как пользоваться виртуал аллоком чтобы у него заработало. Я предложил легкий способ, а не быстрый!

 

Нефрагментируемая куча aka Heap - панацея)

 

twgt
Хорошо, пусть у него будет альтернатива - лёгкий способ, на основе морально устаревшей ещё в во времена 9х LocalAlloc с перспективой "лёгкого" освоения связанных списков
Но хотя бы для общего развития ТС желательно-бы узнать и как это делается по нормальному

 

Y_Mur:
Имхо, все с опытом придет... Ко всем же пришло, ты думаю тоже не начинал освоение массивов с виртуала

 

Код (Text):

1.    ; Резервируем 1Гб в адресном пространстве нашего процесса (это совсем не нагрузит систему)
2.    mov [AddrArray], FUNC(VirtualAlloc, 0, 1024*1024*1024, MEM_RESERVE, PAGE_READWRITE)
3.    ; 0 означает, что Win сама определит по какому стартовому адресу разместить
4.    ; запрашиваемый блок зарезервированных адресов
5.    
6.    ; Размещаем в нём 10кБ реальной памяти
7.    invoke VirtualAlloc, [AddrArray], 10*1024, MEM_COMMIT, PAGE_READWRITE
8.    ; записываем в неё данные:
9.    invoke wsprintf, [AddrArray], zSTR('Первый блок данных')
10.  
11.    ; Увеличиваем размер массива до 10Мб
12.    invoke VirtualAlloc, [AddrArray], 10*1024*1024, MEM_COMMIT, PAGE_READWRITE
13.    ; записываем данные за пределы первоначальных 10кБ:
14.    mov edi, [AddrArray]
15.    add edi, 50*1024 ; смещение в 50кБ
16.    invoke wsprintf, edi, zSTR('Второй блок данных')
17.  
18.    ; Выделяем "оторванный" кусок реальной памяти в середине зарезервированного адресного пространства
19.    mov edi, [AddrArray]
20.    add edi, 500*1024*1024 ; смещение в 500 Мб
21.    invoke VirtualAlloc, edi, 4*1024, MEM_COMMIT, PAGE_READWRITE
22.    ; записываем данные в этот кусок памяти:
23.    invoke wsprintf, edi, zSTR('Демонстрация работы с разреженными массивами')

Ну а если кому-то очень хочется потренироваться в освоении методики построения связанных списков, то это конечно хорошо, они пригодятся, только не стоит применять их к таким задачам

ЗЫ: а тонкости работы с VirtualAlloc отлично описаны и Рихтера и не раз обсуждались на форуме (leo как всегда давал подробные и наглядные разьяснения), так что поиск по форуму рулит

 

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

 

Y_Mur
Использовать VirtualAlloc всегда и везде - это крайность. Разве хип и динамические массивы в АПИ предусмотрены только для лохов?!

 

Quantum

Можно поподробнее, что за дин массивы в АПИ?

 

Y_Mur

Гранулярность выделения памяти (commit) = 4К, поэтому "размещать" 10К, а не 12 не имеет смысла

 

ShadoWich
Win2k: comctl32!DPA_* и comctl32!DSA_*
http://msdn2.microsoft.com/en-us/library/ms672621.aspx

 

Quantum
Note: This function is available through Microsoft Windows XP Service Pack 2 (SP2) and Windows Server 2003. It might be altered or unavailable in subsequent versions of Windows.

не густо конечно, я бы такие не юзал

 

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

 

Quantum
Ноги растут из связных списков - классика.
А насчет открамсывания кусков размером 1Гиг - вот так нынче Мелкософт и пишет, это не есть повод для подражания ))