снач собстно пишу лабу - компилятор, пнятно простенький для простенького языка. И как во всех компиляторах, имеется текст-ареа для текста программы (реализовано через JTextArea). Пользователь указывает искходник, и текст их исходника переписуется сюда. После этого пользователь имеет возможность менять код и компилить. Так вот, сейчас компиляция идет из файла. Т.е. пользователь клацает "компиле", файл перезаписуется (ВЕСЬ, что кажется не есть гуд) и после этого идет считывание лексем с файла. Компилятор однопроходный.
Хочеться:
1. Оптимизировать как-то перезапись. Это возможно? Что возможно я знаю, и даже имею некоторые соображения... но какие-то они очень не оптимальные...
2. Хочется, что бы компилятор считывал символы из окна, а не файла. Если нада изменить текст-ареа на другой компонент - велком с удовольствием выслушаю предложения... Идея getText и считівать со стоки не приемлима Помнится, біл компонент, дающий образ или что-то такое содержания... вобщем. что бы всеь текст в память не загонять... Или все же лучше компилить путем сохранения изменений в файл, а потом считывать из файла... Кто что думает?
Спасибо за помощь!

integral, честно говоря, ты сюда намешал проблемы реализации и ещё чего-то... я не понял сути вопроса.

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

Учитывая то, что даже если у тебя файл размером 1 метр, и пользователь добавит в начало 1 байт, тебе всё равно придётся так или иначе переписывать весь файл... ты ещё хочешь это реализовывать? 

мэппинг файлов тебе поможет
CreateFileMapping() - Windows
mmap() - Linux

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

P.S.


а почему, если не секрет?

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



Почему? Есть вариант в одном потоке запустить сохранение, а в другом - компиляцию.

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

Метр это много     ? Вообще-то, 21-ый век на дворе. Тыкай препода носом в "преждевременная оптимизация --- корень всех зол" из любой мало мальский уважающей себя книге по программингу.


Это сообщение отредактировал(а) Mayk - 20.1.2008, 17:57

ППКС.
Хотя знаю по опыту, препод может тупо на всё это забить. Но попытаться стоит.

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

Добавлено через 3 минуты и 21 секунду
во многих средах реализовано сохранение перед компиляцией, поэтому вполне естественно сохранить его в файл, а потом читать его оттуда
кроме того, раз уж компилятор однопроходный, анализ файла не должен приводить к необходимости хранения его целиком в памяти

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

К этому — это к чему? К оптимизации без запуска профилировщика? ИМХО — Определенно Плохая Идея.

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

Добавлено через 3 минуты и 25 секунд
ИМХО, здесь ситуация, как с изучением инстранного языка - человек должен уметь выражать свои мысли и понимать чужие
даже если на данный момент нет англоязычного человека рядом, два русскоязычных человека садятся рядом и начинают общаться, хотя, если подумать реально, значительно проще передать эту информацию на русском

Древний MS Word писал в свой .doc, изнутри больше похожий на файловую систему. Естественно в новых форматах от этого ушли, ресурсов больно много 

Можно повторить путь гиганта, создать средний файл (растёт по мере надобности блоками), внутри разбить на небольшие блоки, связать в одно дерево (B+ tree). Дальше по задаче, можно при каждом сейве блок изменять (параллельное редактирование многими пользователями затруднительно), либо изобразить простенькую БД (даже с журналом можно  ), что будет отдельным тредом изменения сбрасывать на диск (не деструктивное изменение, т.е. копируем блок, вносим изменения). Изменения в некотором буфере в памяти. При доле фантазии может выйти аналог SQLite