Алгоритмы и формулы Опции

[gamecreator]

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

почитать команды можно так:
пуск-выполнить-cmd-help

[Shaidar Haran]

пуск-выполнить-cmd-help

Проще "help > c:\help.txt", и потом читать из файла.

Ну вы даёте товарищи
start ... без ожидания процесса.

[DracoLich]

Нужно сортировать список из файла, не изменяя в конечном итоге файл. Число записей в файле неограниченно (теоретически), поэтому заносить в массив не получается. Подскажите, как можно реализовать сортировку налету. Язык С++

[Gloin]

Заноси в список.

[Монца]

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

[DracoLich]

Может кому-нибудь известен еще способ? Динамический массив тоже забраковали

[Монца]

А список чего? можно использовать операционную систему) создавать файлы с именами списка (ОС их отсортирует). Это если элементы списка строки, которые могут являться именами файла. Можно использовать БД. Формулировка задачи непонятна.

[Gloin]

Ясен пень, массив забраковали.

[Guevara-chan]

Может кому-нибудь известен еще способ? Динамический массив тоже забраковали

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

[Gloin]

А вы что ли обычно накривую с динамическими массивами работаете?

Добавлено ([mergetime]1245434604[/mergetime]):
Чо тут думать, однонаправленный список, если память позволяет, если нет - новый файл.

[Guevara-chan]

А вы что ли обычно накривую с динамическими массивами работаете?

Имеется в виду прямой доступ к памяти.

[Gloin]

Приведи мне пример не прямого доступа к памяти с использованием динамического массива. Я тебя не понимаю. Использование функций чо ли для доступа к памяти?

[Guevara-chan]

Прямой доступ к памяти массива = доступ по адресу в памяти. Пример:

Код

Dim DArray.L(10)
PokeL(@DArray() + 2*SizeOf(Long), 1)
A = PeekL(@DArray() + 2*SizeOf(Long))

Непрямой доступ к памяти массива = доступ по индексу ячейки массива. Пример:

Код

Dim DArray.L(10)
DArray(2) = 1
A = DArray(2)

...В конечном итоге, разумеется, практически любые обращения к памяти транслируется в прямое, но на этапе разработки - это несколько разные вещи.

[DracoLich]

А список чего? можно использовать операционную систему) создавать файлы с именами списка (ОС их отсортирует). Это если элементы списка строки, которые могут являться именами файла. Можно использовать БД. Формулировка задачи непонятна.

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

Забраковали только использование стандартных средств для работы с массивами данных или в принципе данную ветку методов решения?

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

можно задейстовать hash-таблицу

Честно, не имею даже представления что это

Но скорее всего хотят именно связанный список

А это что? )

[Guevara-chan]

Нужно эмулировать работу базы данных на си.

А это, простите, как ? Методы сортировки записей в разных СУБД не идентичны, вообще-то.

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

Ну, вообще-то он не прав, но вопрос был не об этом: что насчет ручного выделения участка памяти (того же HeapAlloc) и дальнейшей работы с ним, как с массивом ?

Честно, не имею даже представления что это

"Структура данных, реализующая интерфейс ассоциативного массива, что позволяет хранить пары (ключ, значение) и выполнять три операции: операцию добавления новой пары, операцию поиска и операцию удаления пары по ключу. Существует два варианта хэш-таблиц: с прямой и открытой адресацией. Хэш-таблица содержит некоторый массив H, элементы которого есть пары (хэш-таблица с открытой адресацией) или списки пар (хэш-таблица с прямой адресацией)."
(С) Wikipedia
Примечание: с определенными деталями этой формулировки можно, при желании, поспорить, но в целом она корректна.

А это что? )

"Структура данных, состоящая из узлов, каждый из которых содержит как собственные данные, так и одну или две ссылки («связки») на следующее и/или предыдущее поле. Принципиальным преимуществом перед массивом является структурная гибкость: порядок элементов связного списка может не совпадать с порядком расположения элементов данных в памяти компьютера, а порядок обхода списка всегда явно задаётся его внутренними связями."
(С) Wikipedia
Примечание: тебе нужен именно двунаправленный список.

[tolich]

Насколько я понимаю, основная прелесть задачи состоит именно в том, что файл в ОП заведомо никак не помещается, ни одним большим массивом символов, ни связным списком, ни тем более B-деревом.
Более того, одна запись потенциально тоже не помещается.

[Guevara-chan]

Более того, одна запись потенциально тоже не помещается.

Ну, с Win32 так не получится в принципе: там просто не поддерживается чтение данных из файла напрямую в регистры процессора. Вот под DOS еще можно, при очень большом на то желании, соорудить что-то подобное, вот только я очень сильно сомневаюсь, что DrakoLich'у это под силу (ничего личного)...

[tolich]

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

Издеваешься, что ли? А если нет, то к чему тут чтение файлов в регистры?
Если файл и даже одна запись потенциально не помещается в оперативной памяти, то не поместится и в регистре. Да и Дос с Виндовзом тут ни при чем...

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

[Guevara-chan]

Издеваешься, что ли? А если нет, то к чему тут чтение файлов в регистры?

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

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

Не соглашусь: кеширование, если одна запись и правда может не поместится в оперативную память, здесь совершенно излишне - достаточно одного промежуточного буфера фиксированной длины. Отображение, кстати, тут реализовать проще всего.