Объединение выделенной памяти

Есть одна задачка... Пытаюсь написать на фасме редактор текста. Я выделяю область оперативной памяти в 64кб под печатаемый текст. Стал вопрос: если текст привысит этих 64кб то как добавить память? Заранее скажу что охота работать с одним блоком, а не множеством мелких блоков памяти. Придумал выделять новый блок размером больше предыдущего на 64кб потом копировать все из старого блока ну и старый блок удалять. Можно ли как то это покрасивше сделать средствами WINAPI?
Заранее спасибо!

 

Painter

По-красивше или нет, но всё то же самое умеет делать HeapReAlloc.

 

Спасибо. У меня просто документация по апи на английском, где искать не знал. Теперь буду разбираться что к чему.

 

l_inc
Хм, зарезервировать памяти (много, много!), выделить малую часть, словить эксепшн при попытке выйти за предел выделенного буффера - выделить больше.
Не?

 

Z3N
То ли Вы решили, что это я задаю вопрос, то ли усмотрели где-то в моём ответе намёк на единственность предложенного решения. Хотя резервировать много-много означает потерю большого куска адресного пространства без надобности.

 

l_inc
=)
Не знаю, просто чего-то захотелось написать именно Вам.

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

Ну, можно и не много-много, а умеренно-умеренно. Просто мне вариант выделения памяти по сепшенам кажется удобнее. Честно говоря, даже и знаю как творит свою чёрную магия РеАллок, может она вообще эти блоки памяти копирует. Но должен отдать должное, что вариант с РеАллок легче будет, особенно для новичка.

 

Z3N

Не скажется. Но легко может сказаться на дальнейших попытках выделения памяти любого рода в пределах процесса.

Можно. Но при превышении умеренного объёма всё равно придётся копировать.

Резервирует чуть больше. Если очередная попытка выделения превышает зарезервированный объём, то копирует.

 

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

 

Painter
Еще в прошлом тысячелетии программисты придумали списки и прочие простейшие вещи для решения таких проблем. Но все равно никто не хочет их использовать И не надо будет копировать.

 

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

 

valterg

Если можно, ссылку на литературу. Для интереса почитаю. Мот когда и буду использовать...

 

Dmitry_Milk

Я кстати тоже про это подумал, но видимо l_inc читал про это.

 

valterg

Думается обработка текста, эта не "такая проблема", для которой придуманы списки
Если речь идет о редакторе текста, то копирование это вообще не "проблема", а "нормальное явление" т.к. оно может понадобиться не только при реаллокации массива, но и при любых операциях вставки\удаления текста

Dmitry_Milk

А "системный реаллок" в природе существует?

 

Painter

Главное, чтобы не "обычно", а "точно"\на_100%, иначе сколько не возьми, а все равно придется предусматривать реаллокацию. Если же сразу задать некий разумный предел, например 1Мб, то можно его сразу и выделить через VirtualAlloc (которая как известно по умолчанию лишь резервирует адреса, а физ.память выделяет только по мере обращения к ней)

 

Dmitry_Milk

Перекомпонует, адресное пространство поменяется и привет сегфолт.

 

leo

Я тоже сначала думал поставить разумный предел, выбор колустался либо 1мб либо 4мб. Но обдумав решил что в принципе и этот размер можно превысить. И опять та же реАллокация получиться.

 

Ну такой реаллок мог бы возвращать новый валидный адрес. То есть, рассматривать такой реаллок как выделение новой памяти, копирование (а на самом деле просто ремапинг страниц) , освобождаение старой памяти, возврат адреса новой памяти. Пользователь должен получить этот адрес и пользоваться уже только им. Если пользователь полез по старому адресу - сам дурак, зачем лезть туда, где собственноручно дал команду "здесь можно освободить, и дайте пусть в другом месте, но больше"? Если он просто руками бы делал new, потом копировал, потом delete - он ведь не полез бы потом туда, где освободил.

Естественно, все это применимо только к аллокейшнам, начинающимся на границах страниц.

 

Ну а тот же HeapReAlloc?

 

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

Как частный, но очень красивый случай - сделать каждый такой блок просто отдельной строкой целиком. Ну, то есть, хранить весь текст связным списком одиночных строк.

 

Dmitry_Milk

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