Можно ещё по принципу БД устроить, хотя тоже самое будет в конечном счёте. Есть тут спец. по этим вопросам, но он обижается, когда его так называют :-)

Я не спец, потому что проффессия у меня не та.

P.S
БД 50% Done!!!
А статьи о управлени памяти будут. Будут.
Сперва нужно с остальным разобратся.

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

Правило 1 Средство против фгагментации -- сама фрагментация

Файл действительно бъётся на страницы, желатльно размером страницы виртуальной.

Создаётся таблица изменённый страниц.

При нехватке памяти выделяется Новая страница, в которую сганяются данные.

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

А вот ещё метод:

1. Сначала делаем такой объект - Collection называется. Динамически растущий в обе стороны массив содержащий адреса. Такая вещь всегда в хозяйстве пригодится.

2. Потом делаем небольшую структуру, которая будет представлять из себя одну строку текста:

LINEDEF struc
  lnFlags db ?
  lnRoom  db ?
  lnText  db 2 dup (?)
LINEDEF ends

lnFlags - флаги для строки: selected, bookmarked, breakpoint, collapsed block of text, etc. - всё, что надо...

lnRoom - сколько символов можно поместить в строку без ре-аллокации, та же роль как если бы обьявить: 'char str [64]' - в этом случае 64.

lnText - здесь начинается текст.

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

4. Ну и последнее: аллокация/ре-аллокация LINEDEF происходит как:

FULL_LINE_ROOM = LINEDEF.lnRoom + sizeof (LINEDEF)

и потом цепляем этот LINEDEF объект в наш Collection.

5. Для каждого документа лучше иметь отдельный heap allocator.

Это и есть разреженные массивы :))

Edmond, AsmGuru62
Нда, я уже выпадаю в осадок. Естественно, я ни слова не понял из того, что вы тут наговорили. Но общую мысль уловил (хотя бы потому, что сам такую жевал). Буду читать тринадцатый раз и медитировать (ну нравится мне это состояние духа :) Думаю, справлюсь. Респект всем.

>Дык, текстовый редактор :) Только мне нужны различные
>шрифты, изображения, произвольное расположение этого
>добра и тотальный контроль. Так что richedit отпадает.
>На мой вкус, к счастью.
Это похоже на PowerPoint, браузер или CorelDRAW. Я когда-то подобие PowerPoint начинал.
Короче, сначала надо решить, какая будет логика документа:
1.текстовая (напр. в браузере картинку сложно по конкретным координатам поставить - она привязана к строке)
2.объектная (в Corel'е файл есть список объектов, у каждого свои координаты в документе)

Потом реализовать соответствующую логику.
В принципе получается что-то объектное:

сигнатура объекта
тип объекта
указатель на содержимое объекта

А в содержимом уже информация конкретного типа объекта.
Тогда может быть так:
текст->(шрифт, цвет, цвет фона...)
текст->(другой шрифт, цвет...)
картинка->(адрес файла) ;или смещение, если встроеная
URLссылка->(адрес, флаги...)
При такой организации получаем:

Каждый объект занимает немного места (проще найти место в памяти для него при любой фрагментации)
Проще это всё потом последовательно рисовать для юзера
Поиск по тексту ведётся быстро (большую часть поиска мы прыгаем по маленьким дескрипторам объектов, а внутрь входим только если тип объекта подходящий)
Вставляем в документ принципиально, что хотим, любой тип объекта

Единственное, нужен свой формат организации таких данных. Но если прога создаёт свой формат файла, то проблем нет. А потом можно и конвертацию в любой известный тип файла реализовать.

Ой, простите, я тут чего-то накуролесил. Ещё не совсем разобрался с системой форума. А удалить своё сообщение не могу.
А может мне статью написать? Хотя я уже всю идею то и выложил.

SolidCode
Конечно, напишите, а то я опять нифига не понял :)
Нет, не надо повторять подробней. Теоретически все понятно. Просто не знаю с какого конца надо начинать воплощать на практике. Если захотите поучаствовать, могу скинуть сделанное, выкладывать на людях просто стыдно :(
P.S. Это попытка WYSIWUG для этого форума. Уже третий месяц переписываю сделанные пятнадцать строк, и как дохожу до этого места, придумываю новую концепцию, бросаюсь переписывать все под нее, и снова выясняю, что это никуда не годится и надо снова переделывать. Меня это уже порядком доконало :(

"P.S. Это попытка WYSIWUG для этого форума. Уже третий месяц переписываю сделанные пятнадцать строк, и как дохожу до этого места, придумываю новую концепцию, бросаюсь переписывать все под нее, и снова выясняю, что это никуда не годится и надо снова переделывать. Меня это уже порядком доконало :("
===
Стыдно признаться, однако в моих архивах лежит 7 версий (незаконченных, разумеется!..) моей задумки - AsmDev32. Ну, наверное, номер восемь будет в точку.
===

Сделал так: сначала все так же тупо пишется в линейную стуктуру типа "строка". Когда в начало/середину пишется лишний символ, все справа сгоняется на 256 байт направо, теперь можно безболезненно добивать 255 символов, после этого последует еще один сдвиг. Если символ удаляется, прога ищет ближайшую 256-байтную границу справа и двигает все до нее влево. Если двигать нечего (байт после удаляемого - нулевой), сдвигает весь текст после границы влево на те же 256 байт (то есть забивает освобожденный блок заполненными). Насколько я понял, это и есть истинный разреженный массив. Получается, в худшем случае он будет занимать памяти в 2 раза больше, чем линейный, в моем случае это не смертельно (вряд ли у кого нибудь получится пост больше чем на 64к :)

Я здесь: sergeysolid на сервере mail.ru.
Уважаемый hGoblin
При разработке этого проекта возможно ли Вам сначала на каком-либо логическом псевдо-языке написать концептуальный алгоритм всей системы? В сложных местах прописать более подробно. И только потом, когда Вы уже сами чувствуете всю систему, когда во сне Вы видите как она работает, только потом выполнять систему в коде.
Это чтобы сто раз не переписывать. Чтобы, когда всё уже написали, на стадии отладчика не обнаруживать, что всё это не то и работает не так.

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

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