exit. но скорей всего он не закроется до завершения проги. тогда используй мою прогу для запуска приложений. она создает отдельный процесс и закрывается.
почитать команды можно так:
пуск-выполнить-cmd-help
Полная версия этой страницы: Алгоритмы и формулы
Цитата(gamecreator @ 23 Jan 2009, 19:50)
пуск-выполнить-cmd-help
Проще "help > c:\help.txt", и потом читать из файла.
Ну вы даёте товарищи 
start ... без ожидания процесса.
start ... без ожидания процесса.
Нужно сортировать список из файла, не изменяя в конечном итоге файл. Число записей в файле неограниченно (теоретически), поэтому заносить в массив не получается. Подскажите, как можно реализовать сортировку налету. Язык С++
Заноси в список.
Если оперная память неограничена, то используй какие нить динамические типы данных: список, массив или еще чего.
Может кому-нибудь известен еще способ? Динамический массив тоже забраковали 
А список чего? можно использовать операционную систему) создавать файлы с именами списка (ОС их отсортирует). Это если элементы списка строки, которые могут являться именами файла. Можно использовать БД. Формулировка задачи непонятна.
Ясен пень, массив забраковали.
Цитата
Может кому-нибудь известен еще способ? Динамический массив тоже забраковали
Забраковали только использование стандартных средств для работы с массивами данных или в принципе данную ветку методов решения ? Просто динамический массив можно проэмулировать через выделение участка памяти и дальнейшую работу с ним напрямую. Еще, если хочется блеснуть неординарностью выбираемых подходов и широтой знаний, можно задейстовать hash-таблицу). Но скорее всего хотят именно связанный список, да.
А вы что ли обычно накривую с динамическими массивами работаете?
Добавлено ([mergetime]1245434604[/mergetime]):
Чо тут думать, однонаправленный список, если память позволяет, если нет - новый файл.
Добавлено ([mergetime]1245434604[/mergetime]):
Чо тут думать, однонаправленный список, если память позволяет, если нет - новый файл.
Цитата
А вы что ли обычно накривую с динамическими массивами работаете?
Имеется в виду прямой доступ к памяти.
Приведи мне пример не прямого доступа к памяти с использованием динамического массива. Я тебя не понимаю. Использование функций чо ли для доступа к памяти?
Прямой доступ к памяти массива = доступ по адресу в памяти. Пример:
Непрямой доступ к памяти массива = доступ по индексу ячейки массива. Пример:
...В конечном итоге, разумеется, практически любые обращения к памяти транслируется в прямое, но на этапе разработки - это несколько разные вещи.
Код
Dim DArray.L(10)
PokeL(@DArray() + 2*SizeOf(Long), 1)
A = PeekL(@DArray() + 2*SizeOf(Long))
PokeL(@DArray() + 2*SizeOf(Long), 1)
A = PeekL(@DArray() + 2*SizeOf(Long))
Непрямой доступ к памяти массива = доступ по индексу ячейки массива. Пример:
Код
Dim DArray.L(10)
DArray(2) = 1
A = DArray(2)
DArray(2) = 1
A = DArray(2)
...В конечном итоге, разумеется, практически любые обращения к памяти транслируется в прямое, но на этапе разработки - это несколько разные вещи.
Цитата
А список чего? можно использовать операционную систему) создавать файлы с именами списка (ОС их отсортирует). Это если элементы списка строки, которые могут являться именами файла. Можно использовать БД. Формулировка задачи непонятна.
Нужно эмулировать работу базы данных на си. Все данные читаются из файла, где в каждой строке 4-5 параметров, и в имени файла далеко не все строки могут быть использованы, бо на символы ограничений нет.
Цитата
Забраковали только использование стандартных средств для работы с массивами данных или в принципе данную ветку методов решения?
Он стоит на своем - размер файла неограничен, использовать массивы для сохранения и сортировки тупо нельзя из-за размера.Цитата
можно задейстовать hash-таблицу
Честно, не имею даже представления что это
Цитата
Но скорее всего хотят именно связанный список
А это что? )
Цитата
Нужно эмулировать работу базы данных на си.
А это, простите, как ? Методы сортировки записей в разных СУБД не идентичны, вообще-то.
Цитата
Он стоит на своем - размер файла неограничен, использовать массивы для сохранения и сортировки тупо нельзя из-за размера.
Ну, вообще-то он не прав, но вопрос был не об этом: что насчет ручного выделения участка памяти (того же HeapAlloc) и дальнейшей работы с ним, как с массивом ?
Цитата
Честно, не имею даже представления что это
"Структура данных, реализующая интерфейс ассоциативного массива, что позволяет хранить пары (ключ, значение) и выполнять три операции: операцию добавления новой пары, операцию поиска и операцию удаления пары по ключу. Существует два варианта хэш-таблиц: с прямой и открытой адресацией. Хэш-таблица содержит некоторый массив H, элементы которого есть пары (хэш-таблица с открытой адресацией) или списки пар (хэш-таблица с прямой адресацией)."
(С) Wikipedia
Примечание: с определенными деталями этой формулировки можно, при желании, поспорить, но в целом она корректна.
Цитата
А это что? )
"Структура данных, состоящая из узлов, каждый из которых содержит как собственные данные, так и одну или две ссылки («связки») на следующее и/или предыдущее поле. Принципиальным преимуществом перед массивом является структурная гибкость: порядок элементов связного списка может не совпадать с порядком расположения элементов данных в памяти компьютера, а порядок обхода списка всегда явно задаётся его внутренними связями."
(С) Wikipedia
Примечание: тебе нужен именно двунаправленный список.
Насколько я понимаю, основная прелесть задачи состоит именно в том, что файл в ОП заведомо никак не помещается, ни одним большим массивом символов, ни связным списком, ни тем более B-деревом.
Более того, одна запись потенциально тоже не помещается.
Более того, одна запись потенциально тоже не помещается.
Цитата
Более того, одна запись потенциально тоже не помещается.
Ну, с Win32 так не получится в принципе: там просто не поддерживается чтение данных из файла напрямую в регистры процессора. Вот под DOS еще можно, при очень большом на то желании, соорудить что-то подобное, вот только я очень сильно сомневаюсь, что DrakoLich'у это под силу (ничего личного)...
Цитата(Chrono Syndrome @ 20 Jun 2009, 19:15)
...там просто не поддерживается чтение данных из файла напрямую в регистры процессора...
Издеваешься, что ли? А если нет, то к чему тут чтение файлов в регистры?
Если файл и даже одна запись потенциально не помещается в оперативной памяти, то не поместится и в регистре. Да и Дос с Виндовзом тут ни при чем...
Для решения задачи необходимо хорошо продумать механизм кеширования файла в памяти, желательно в нескольких буферах, организовать поиск нужной записи в файле, сравнение двух записей (напомню, переменной и, возможно, разной длины), ну и, разумеется, разработать алгоритм отображения отсортированного файла в таких вот непростых условиях.
Цитата
Издеваешься, что ли? А если нет, то к чему тут чтение файлов в регистры?
Да я просто к тому, что совсем без попадания данных записи в оперативную память обойтись в обычных условиях не удастся.
Цитата
Для решения задачи необходимо хорошо продумать механизм кеширования файла в памяти, желательно в нескольких буферах, организовать поиск нужной записи в файле, сравнение двух записей (напомню, переменной и, возможно, разной длины), ну и, разумеется, разработать алгоритм отображения отсортированного файла в таких вот непростых условиях.
Не соглашусь: кеширование, если одна запись и правда может не поместится в оперативную память, здесь совершенно излишне - достаточно одного промежуточного буфера фиксированной длины. Отображение, кстати, тут реализовать проще всего.
Понял в чем непонятка! 
"Данные не помещаются в оперативную память!" - это по-английски "The data don't fit the RAM", а не "The data aren't placed to the RAM"
То есть, по-русски, оперативки не хватает.
А кешировать лучше сразу две строки (чтобы иметь возможность их сравнивать, как-то так), так что как минимум два буфера.
"Данные не помещаются в оперативную память!" - это по-английски "The data don't fit the RAM", а не "The data aren't placed to the RAM"
То есть, по-русски, оперативки не хватает.
А кешировать лучше сразу две строки (чтобы иметь возможность их сравнивать, как-то так), так что как минимум два буфера.
Ну, для одиночного сравнения каждой записи хватит и единственного буфера с эталонной строкой, а массовое слабо применимо, если даже (цитирую) "одна запись потенциально тоже не помещается" .
Сравниваем одну запись с другой, обе в память целиком быть загружены потенциально не могут, обе могут находиться в разных секторах файла. Разумеется, обе записи надо частично загрузить в память, сравнить их начала, если начала совпадают, продолжить загрузку и сравнение, пока не будет найдено первое отличие. Такие дела. Да, еще вначале надо как-то позиционироваться на начало записи.
Вначале нужно вывести минимальную строку, затем вторую по величине, затем третью и т.д. до максимальной. Причем это нужно сделать, не создавая дополнительных файлов и не изменяя исходный.
И еще одна мысль: файл можно открыть два раза (получить два хендла), тогда можно немного упростить работу с текущей позицией.
Вначале нужно вывести минимальную строку, затем вторую по величине, затем третью и т.д. до максимальной. Причем это нужно сделать, не создавая дополнительных файлов и не изменяя исходный.
И еще одна мысль: файл можно открыть два раза (получить два хендла), тогда можно немного упростить работу с текущей позицией.
Цитата
Разумеется, обе записи надо частично загрузить в память, сравнить их начала, если начала совпадают, продолжить загрузку и сравнение, пока не будет найдено первое отличие.
Именно, но статические буферы для хранения этих фрагментов не требуются - их вполне можно подержать на стеке, все равно ведь содержимое будет постоянно разрушаться при дозагрузке.
Цитата
Причем это нужно сделать, не создавая дополнительных файлов и не изменяя исходный.
А где сказано, что нельзя использовать дополнительные файлы ?
Ну, с дополнительным файлом получается вообще легко: создать индексный файл, с записями фиксированного размера, включающими: номер записи исходного файла и смещение от начала файла до начала записи, а затем отсортировать его по возрастанию содержимого записей.
После этого, последовательно проходя по индексу, обработать все записи. (Все нормальные СУБД так делают!)
После этого, последовательно проходя по индексу, обработать все записи. (Все нормальные СУБД так делают!
)
Цитата
21.06.2009 18:58:34, Chrono Syndrome
На сей раз просто техническая полемика.
21.06.2009 18:58:48, Chrono Syndrome
Да я и согласилась уже почти.
21.06.2009 18:59:36, I am
с чем
21.06.2009 18:59:47, I am
дф2 уже уныл чуть более чем полностью
21.06.2009 18:59:55, I am
в этом помогла мышиная возня ХоТа
21.06.2009 19:00:03, I am
из за которой набежало тысячи школоты
21.06.2009 19:01:32, Chrono Syndrome
http://forum.df2.ru/index.php?act=ST&f=83&t=8575&st=120
21.06.2009 19:10:27, I am
сортировка большого файла иначе делается
21.06.2009 19:10:54, Chrono Syndrome
Как ?
21.06.2009 19:11:38, I am
ну вкратце делаем так
берем шмат файла например в 200мег
кидаем в память сортируем пишем на диск в 1ый файл
второй шмат также сортируем пишем на диск в 2ой файл
и т.д.
21.06.2009 19:11:53, Chrono Syndrome
Так. Дальше что ?
21.06.2009 19:12:00, I am
после этого сливаем эти куски
для этого нам надо 2*Н записей строк
21.06.2009 19:12:17, Chrono Syndrome
Ну, слили.
21.06.2009 19:12:28, Chrono Syndrome
У нас естьф аргментально остортиврованный файл.
21.06.2009 19:13:02, I am
Х(номер файла,0) = значение из текушей строки файла
Х(номер файла,1) = значение из следуший за текушей строкой файла
и еще храним номер этой самой строки
21.06.2009 19:13:32, I am
вот и сравнивая между собой каждые строчки сдвигаем счетчики строк в каждом куске
21.06.2009 19:13:43, I am
итого при слдиянии выйдет что большой файл сортирован
21.06.2009 19:14:18, Chrono Syndrome
Хм...
21.06.2009 19:14:25, Chrono Syndrome
Интнрестная методика.
21.06.2009 19:14:29, I am
21.06.2009 19:12:28, Chrono Syndrome
У нас естьф аргментально остортиврованный файл.
хитрым слиянием
21.06.2009 19:14:30, Chrono Syndrome
*Интерестная.
21.06.2009 19:14:43, I am
не тупо дописывая в конец
21.06.2009 19:15:02, I am
а среди этих Н записей находим минимальную
она будет первой строкой в итоговом файле
21.06.2009 19:15:17, I am
в Н ом куске где мы ее нашли сдвинули счетчик строки на еденичку
21.06.2009 19:15:27, I am
снова находим минимальное
21.06.2009 19:15:42, I am
где нашли пишем в итоговый файл еще строку
сдвигаем на еденичку
21.06.2009 19:15:54, I am
а естть еще более хитрые методики
21.06.2009 19:16:00, I am
там как раз оба поля можно учитывать
21.06.2009 19:16:09, I am
но чем проще алг тем меньше в нем ошибок
21.06.2009 19:16:17, Chrono Syndrome
Логично).
21.06.2009 19:16:22, I am
короче все просто как 5 копеек обосцать
21.06.2009 19:16:59, I am
главное чтобы школота не забыла что все куски надо сортировать одним и тем же методом по которому нам нужен отсортированный итог
21.06.2009 19:17:33, I am
минус тока один
на временные файлики нам нужна ТЕМП папка в размере исходного файла
21.06.2009 19:17:44, Chrono Syndrome
Разумеется.
21.06.2009 19:18:12, I am
ну и при диком желании уж операции чтения из кусков мона кешировать блоками по Н кб чтобы винт не убивать
21.06.2009 19:18:56, I am
передавай школоте привед
21.06.2009 19:19:08, Chrono Syndrome
.
21.06.2009 19:19:18, Chrono Syndrome
Можешь запостить алгоритм).
21.06.2009 19:19:28, I am
скопипасть я не против
21.06.2009 19:19:32, Chrono Syndrome
Только приведи его в понятный школоте вид).
21.06.2009 19:19:45, I am
тока из копипаста строку "школоте привед" не удаляй
21.06.2009 19:19:54, Chrono Syndrome
)))
21.06.2009 19:20:02, Chrono Syndrome
Ладно, если ничего не предложат -запощу.
21.06.2009 19:20:39, I am
ye yt [ji z cfv crjgbgfcn.
21.06.2009 19:20:49, I am
ну не хош я сам скопипащю
21.06.2009 19:20:59, Chrono Syndrome
Скопипасть).
На сей раз просто техническая полемика.
21.06.2009 18:58:48, Chrono Syndrome
Да я и согласилась уже почти.
21.06.2009 18:59:36, I am
с чем
21.06.2009 18:59:47, I am
дф2 уже уныл чуть более чем полностью
21.06.2009 18:59:55, I am
в этом помогла мышиная возня ХоТа
21.06.2009 19:00:03, I am
из за которой набежало тысячи школоты
21.06.2009 19:01:32, Chrono Syndrome
http://forum.df2.ru/index.php?act=ST&f=83&t=8575&st=120
21.06.2009 19:10:27, I am
сортировка большого файла иначе делается
21.06.2009 19:10:54, Chrono Syndrome
Как ?
21.06.2009 19:11:38, I am
ну вкратце делаем так
берем шмат файла например в 200мег
кидаем в память сортируем пишем на диск в 1ый файл
второй шмат также сортируем пишем на диск в 2ой файл
и т.д.
21.06.2009 19:11:53, Chrono Syndrome
Так. Дальше что ?
21.06.2009 19:12:00, I am
после этого сливаем эти куски
для этого нам надо 2*Н записей строк
21.06.2009 19:12:17, Chrono Syndrome
Ну, слили.
21.06.2009 19:12:28, Chrono Syndrome
У нас естьф аргментально остортиврованный файл.
21.06.2009 19:13:02, I am
Х(номер файла,0) = значение из текушей строки файла
Х(номер файла,1) = значение из следуший за текушей строкой файла
и еще храним номер этой самой строки
21.06.2009 19:13:32, I am
вот и сравнивая между собой каждые строчки сдвигаем счетчики строк в каждом куске
21.06.2009 19:13:43, I am
итого при слдиянии выйдет что большой файл сортирован
21.06.2009 19:14:18, Chrono Syndrome
Хм...
21.06.2009 19:14:25, Chrono Syndrome
Интнрестная методика.
21.06.2009 19:14:29, I am
21.06.2009 19:12:28, Chrono Syndrome
У нас естьф аргментально остортиврованный файл.
хитрым слиянием
21.06.2009 19:14:30, Chrono Syndrome
*Интерестная.
21.06.2009 19:14:43, I am
не тупо дописывая в конец
21.06.2009 19:15:02, I am
а среди этих Н записей находим минимальную
она будет первой строкой в итоговом файле
21.06.2009 19:15:17, I am
в Н ом куске где мы ее нашли сдвинули счетчик строки на еденичку
21.06.2009 19:15:27, I am
снова находим минимальное
21.06.2009 19:15:42, I am
где нашли пишем в итоговый файл еще строку
сдвигаем на еденичку
21.06.2009 19:15:54, I am
а естть еще более хитрые методики
21.06.2009 19:16:00, I am
там как раз оба поля можно учитывать
21.06.2009 19:16:09, I am
но чем проще алг тем меньше в нем ошибок
21.06.2009 19:16:17, Chrono Syndrome
Логично).
21.06.2009 19:16:22, I am
короче все просто как 5 копеек обосцать
21.06.2009 19:16:59, I am
главное чтобы школота не забыла что все куски надо сортировать одним и тем же методом по которому нам нужен отсортированный итог
21.06.2009 19:17:33, I am
минус тока один
на временные файлики нам нужна ТЕМП папка в размере исходного файла
21.06.2009 19:17:44, Chrono Syndrome
Разумеется.
21.06.2009 19:18:12, I am
ну и при диком желании уж операции чтения из кусков мона кешировать блоками по Н кб чтобы винт не убивать
21.06.2009 19:18:56, I am
передавай школоте привед
21.06.2009 19:19:08, Chrono Syndrome
.21.06.2009 19:19:18, Chrono Syndrome
Можешь запостить алгоритм).
21.06.2009 19:19:28, I am
скопипасть я не против
21.06.2009 19:19:32, Chrono Syndrome
Только приведи его в понятный школоте вид).
21.06.2009 19:19:45, I am
тока из копипаста строку "школоте привед" не удаляй
21.06.2009 19:19:54, Chrono Syndrome
)))
21.06.2009 19:20:02, Chrono Syndrome
Ладно, если ничего не предложат -запощу.
21.06.2009 19:20:39, I am
ye yt [ji z cfv crjgbgfcn.
21.06.2009 19:20:49, I am
ну не хош я сам скопипащю
21.06.2009 19:20:59, Chrono Syndrome
Скопипасть).
Идея супер! Признавайтесь, проверка четности целого числа поиском по двум базам данных тоже принадлежит вам?
Цитата(tolich @ 21 Jun 2009, 20:03)
Идея супер! Признавайтесь, проверка четности целого числа поиском по двум базам данных тоже принадлежит вам?
создание подобных предрасчитанных таблиц вполне имеет смысл
например помнитсься в 2000 винде хеш пароля не привязан к аппаратной части а только к паролю
потому однажды созданная реверсная база размером кажется на 8 гигабайт давала в течение пару минут пасс от хеша.
и да работа с винтом вполне нормальное явление не надо его стеснятся тем более когда память ограниченна
90% выших хитрых вариантов будут медленней чем обычное решение "в лоб"
Напомню задачу:
То что вы предлагаете - отсортировать исходный файл (так или иначе) и записать его в какой-то результирующий. Так вот, условия задачи это запрещают. Сортировка должна производиться на лету.
Напомню, не все, что годится для практической работы, допустимо при выполнении домашки по программированию.
Добавлено ([mergetime]1245604821[/mergetime]):
Ёу, 777!
Цитата(DracoLich @ 16 Jun 2009, 14:47)
Нужно сортировать список из файла, не изменяя в конечном итоге файл. Число записей в файле неограниченно (теоретически), поэтому заносить в массив не получается. Подскажите, как можно реализовать сортировку налету. Язык С++
То что вы предлагаете - отсортировать исходный файл (так или иначе) и записать его в какой-то результирующий. Так вот, условия задачи это запрещают. Сортировка должна производиться на лету.
Напомню, не все, что годится для практической работы, допустимо при выполнении домашки по программированию.
Добавлено ([mergetime]1245604821[/mergetime]):
Ёу, 777!
Цитата(DracoLich @ 16 Jun 2009, 14:47)
Нужно сортировать список из файла, не изменяя в конечном итоге файл. Число записей в файле неограниченно (теоретически), поэтому заносить в массив не получается. Подскажите, как можно реализовать сортировку налету. Язык С++
а в условии нет доп пунка типа и памяти даже на хранение поинтеров на записи не хватает?
вот вам тупой и адцки медленный метод но "на лету" хотя я бы сделал так как я описал:
(но дня него надо достаточно памяти чтобы хранить номер записи + еще немножко
)делаем линейный проход по ВСЕМУ списку
найденый минимальный пишем в выходной файл
запоминаем его номер
делаем второй проход по списку
ищем второй по минимуму(как раз используя сверку с найденным минимальным) и пишем в выходной файл
запоминаем номер
(все опреации при желании можно реализовать чтением с винта чтобы в памяти держать только пару сотен нужных байт
типа смешение в байтах от начала записи
текущий проверямый байт записи и т.д.)
и т.д.
на это у нас памяти хватит?
только предупреждаю вы поседеете
не забудьте определить свой супер длинный тип чисел (например 1мег для хранения числа) и арифмитические операции с ними
ведь у нас почти бесконечность записей
Цитата
ведь у нас почти бесконечность записей
А поскольку бесконечные объекты неконструктивны, то они представлены в памяти компьютера быть не могут. Следовательно, задача неверно сформулирована и решена быть не может!
Get serious. Да, блин, прогресс не стоит на месте. Если с десяток лет назад эта задача и была актуальна, то сейчас ее имеет смысл ставить разве что для контроллеров лифта, в которых, я где-то читал, нет printf().
Да и то — вполне возможно, что и контроллеры лифта давно уже с ним! Да, я понимаю, что при современных объемах оперативки у персоналок формулировка задачи смешна? Либо файл настолько мал, что его без проблем можно прочитать весть в память и в памяти все отсортировать и вывести на экран, либо файл слишком велик, чтобы поместиться в оперативку, и тогда его вывод на экран, даже без сортировки, займет пару лет.
В общем, советов мы надавали, осмысленность задачи обсудили, предлагаю — а ну ее нафик!
ну в прицнипе то обсудили все возможное и невозможное. будем пробовать. Спасибо всем.
Драколич, сдался? ))
Спросил бы что именно подразумевает препод, и тогда уже сделать.
Спросил бы что именно подразумевает препод, и тогда уже сделать.
да епт )
Ок. Текстовый файл сожержит данные в 3-4 стобцах, нужно орагнизовать сортировку по 1/2/3/4 (любому выбранному) стоблцу. База огромна, и массивы (именно массивы) использовать запрещено. Так яснее?
Ок. Текстовый файл сожержит данные в 3-4 стобцах, нужно орагнизовать сортировку по 1/2/3/4 (любому выбранному) стоблцу. База огромна, и массивы (именно массивы) использовать запрещено. Так яснее?
...А, ну тогда все совсем просто: делай через связанные списки, вряд ли ошибешся.
К.О. говорит, что строка символов — тоже, вообще-то, массив.
Так что совсем без них не обойтись. Даже если просто буферизовать файл, массив нужен. Препод — лось!
Так что совсем без них не обойтись. Даже если просто буферизовать файл, массив нужен. Препод — лось!
Ну, скорее, опять же мой фейл в некорректности сказаного - нельзя использовать массивы для хранения всей базы, т.к. она не влезет в память. А юзать некоторые ограниченные массивы вполне реально. Нельзя занести всю базу в массив 
Хм, а если занести в массив только данные из использумого для сортировки таблицы столба в комплекте с адресом начала содержащей их строки ?
Вот я оп чем и писал, все умных строят, а чуваку скорее всего что-то до нельзя простое надо, тупо список статики по 3-4 инта.
Добавлено ([mergetime]1245848966[/mergetime]):
Нарыл чо то похожее в загашниках, только тут какие-то левые методы есть.
И тут одинаковые строки не добавляются, и добавляй элементы сразу в нужное место списка пробегая его от начала, типа пузырёк
Можешь конечно сначала надобавлять, а потом сортировать другим методом.
Добавлено ([mergetime]1245849059[/mergetime]):
Какая то <фигня> с форматированием.
/Chrono Syndrome: у нас не выражаются, считай предупреждением.
Добавлено ([mergetime]1245848966[/mergetime]):
Нарыл чо то похожее в загашниках, только тут какие-то левые методы есть.
И тут одинаковые строки не добавляются, и добавляй элементы сразу в нужное место списка пробегая его от начала, типа пузырёк
Можешь конечно сначала надобавлять, а потом сортировать другим методом.
Код
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <getopt.h>
#define MAX_WORD 64
struct lnode
{
char *word;
struct lnode *next;
};
struct lnode *lalloc()
{
return malloc(sizeof(struct lnode));
}
struct lnode *addlist(struct lnode *root, char *w)
{
struct lnode *p = root;
if (p==NULL)
{
p = lalloc();
p->next = NULL;
p->word = (char *) strdup(w);
return p;
}
while (p->next != NULL)
{
if (strcmp(p->word, w) == 0)
return root;
else
p = p->next;
}
if (strcmp(p->word, w) == 0)
return root;
p->next = lalloc();
p = p->next;
p->word = (char *) strdup(w);
p->next = NULL;
return root;
}
struct lnode *lfree(struct lnode *root)
{
if (root == NULL)
return NULL;
struct lnode *p, *tmp;
p = root;
while (p->next != NULL)
{
tmp = p->next;
free(p->word);
free(p);
p = tmp;
}
free(p->word);
free(p);
return NULL;
}
void lprint(struct lnode *root)
{
struct lnode *tmp = root;
while(tmp != NULL)
{
printf("%s ", tmp->word);
tmp = tmp->next;
}
printf("\n");
}
int listlen(struct lnode *root)
{
int count = 0;
struct lnode *p = root;
while(p != NULL)
{
p = p->next;
++count;
}
return count;
}
char **ltoarr(struct lnode *root, int count)
{
struct lnode *p = root;
int i = 0;
char **res = malloc(sizeof(char *) * count);
for(;i<count;++i)
{
res[i] = p->word;
p = p->next;
}
return res;
}
#include <stdlib.h>
#include <string.h>
#include <getopt.h>
#define MAX_WORD 64
struct lnode
{
char *word;
struct lnode *next;
};
struct lnode *lalloc()
{
return malloc(sizeof(struct lnode));
}
struct lnode *addlist(struct lnode *root, char *w)
{
struct lnode *p = root;
if (p==NULL)
{
p = lalloc();
p->next = NULL;
p->word = (char *) strdup(w);
return p;
}
while (p->next != NULL)
{
if (strcmp(p->word, w) == 0)
return root;
else
p = p->next;
}
if (strcmp(p->word, w) == 0)
return root;
p->next = lalloc();
p = p->next;
p->word = (char *) strdup(w);
p->next = NULL;
return root;
}
struct lnode *lfree(struct lnode *root)
{
if (root == NULL)
return NULL;
struct lnode *p, *tmp;
p = root;
while (p->next != NULL)
{
tmp = p->next;
free(p->word);
free(p);
p = tmp;
}
free(p->word);
free(p);
return NULL;
}
void lprint(struct lnode *root)
{
struct lnode *tmp = root;
while(tmp != NULL)
{
printf("%s ", tmp->word);
tmp = tmp->next;
}
printf("\n");
}
int listlen(struct lnode *root)
{
int count = 0;
struct lnode *p = root;
while(p != NULL)
{
p = p->next;
++count;
}
return count;
}
char **ltoarr(struct lnode *root, int count)
{
struct lnode *p = root;
int i = 0;
char **res = malloc(sizeof(char *) * count);
for(;i<count;++i)
{
res[i] = p->word;
p = p->next;
}
return res;
}
Добавлено ([mergetime]1245849059[/mergetime]):
Какая то <фигня> с форматированием.
/Chrono Syndrome: у нас не выражаются, считай предупреждением.
Эм, чувак.
>и массивы (именно массивы) использовать запрещено.
>она не влезет в память.
Ты уж определись, а то ведь метод с файлами придётся пользовать.
>и массивы (именно массивы) использовать запрещено.
>она не влезет в память.
Ты уж определись, а то ведь метод с файлами придётся пользовать.
Цитата
Вот я оп чем и писал, все умных строят, а чуваку скорее всего что-то до нельзя простое надо, тупо список статики по 3-4 инта.
Что надо чуваку толком не знает никто, включая самого чувака. Представленная задача решается десятками способов различной степени извращенности, тогда как мы тут вслепую гадали на всемогущей ф-ии Random, какому именно из них чувака хотят обучить. И да, мы в конце-концов действительно предположили, что преподаватель попросту сам не до конца понял что он сказал, после чего DracoLich'у было вновь предложено реализовать сортировку через связанный список. Вот только лично я теперь, честно говоря, ожидаю дальнейших сюрпризов...
связанные списки кажутся нормальным вариантом. Посмотрим, что он скажет на такое
нельзя использовать массив для хранения ВСЕЙ базы. в остальных случаях можно
Цитата
>и массивы (именно массивы) использовать запрещено.
>она не влезет в память.
>она не влезет в память.
нельзя использовать массив для хранения ВСЕЙ базы. в остальных случаях можно
Хм, но логически можно со списками обращаться точно так же как с массивами - написать обертки.
В OpenGL чтобы использовать всю текстуру, в glTexCoord2f подставляются значения 0 и 1. Вопрос - как написать формулу для вычленения определенного кадра из текстуры? Расположены кадры в ряд, значит по одной координате все очевидно. Если просто разделить номер текущего кадра на их количество, возникают неточности - "заезжает" на соседний...
Используй число кадров РАВНОЕ 2n, тогда никаких ошибок округления не будет.
EDIT: впрочем, если текстура между пикселями сглаживается, это не спасает… сглаживание лучше отключить или чуть-чуть, на полпикселя, сдвигать текстурные координаты "внутрь" кадра.
EDIT: впрочем, если текстура между пикселями сглаживается, это не спасает… сглаживание лучше отключить или чуть-чуть, на полпикселя, сдвигать текстурные координаты "внутрь" кадра.
CODE
procedure RotateEast(inp: Pointer; res: Pointer; size: integer);
asm //eax,edx,ecx
pushad
mov edi,size //сохранить размерность
mov esi,0
@@loop:
push edi
mov ebx,[eax] //inp
imul edi,4
imul edi,ecx
add edi,edx
mov [edi+esi*4],ebx //res
pop edi
add eax,4
dec ecx //ecx - оптимально номер горизонтальной линии
jnz @@loop
push edi
imul edi,4
add ebx,edi
pop edi
mov ecx,edi
inc esi
cmp esi,edi //esi - доп.смещение вправо
jle @@loop
popad
end;
procedure RotateSouth(inp: Pointer; res: Pointer; size: integer);
asm //eax,edx,ecx
pushad
imul ecx,ecx
imul ecx,4
sub ecx,4
@@loop:
mov ebx,[eax] //inp
mov [edx+ecx],ebx //res
add eax,4
sub ecx,4
cmp ecx,0
jg @@loop
popad
end;
procedure RotateWest(inp: Pointer; res: Pointer; size: integer);
asm
end;
function PixelRotate(inp: TDataArray; a: integer; size: integer): TDataArray;
var
i: integer;
v: Pointer;
new: TDataArray;
begin
SetLength(new,length(inp));
for i:=0 to high(inp) do begin
v:=nil;
GetMem(v,size*size*4);
case a of
//1: RotateEast(inp[i],v,size);
2: RotateSouth(inp[i],v,size);
//3: RotateWest(inp[i],v,size);
else CopyMemory(inp[i],v,size);
end;
new[i]:=v;
end;
result:=new;
end;
Мне нужно написать поворот 32-битного изображения в памяти. ЧТо я делаю не так? Какая-то хрень с памятью в RotateEast (при чем вылетает где-то на GetMem, отладчик нифига не показывает), и кривота результата в RotateSouth.
Ситуация упрощается тем, что все пиксели размещаются в памяти плотно, т.к. размеры картинки соответствующие.
Замени локальные пуши и попы на сохранение в стеке. Дальше не стал разбираться - комментов мало.
Сохранение в стеке - что-то вроде:
var temp: integer;
__asm{
mov temp, edi;
...
mov edi, temp;
}
Сохранение в стеке - что-то вроде:
var temp: integer;
__asm{
mov temp, edi;
...
mov edi, temp;
}
Переделал немного:
procedure RotateEast(inp: Pointer; res: Pointer; size: integer);
var // eax edx ecx
i: integer;
asm
pushad
mov i,ecx //сохранить размерность
mov esi,0 //дополнительный счетчик от 0 до (size-1)
@@loop:
dec ecx //ecx: счетчик от (size-1) до 0
mov ebx,[eax] //inp - получить пиксель
mov edi,i //вычисление адреса конечной точки:
imul edi,4 //4*номер_строки*размер_изображения
imul edi,ecx //ecx - номер строки
add edi,edx //edx = res (адрес картинки-приемника)
mov [edi+esi*4],ebx //добавление к адресу позиции в строке*4
add eax,4 //смещение указателя источника (1 пиксель прочитан)
cmp ecx,0 //ecx - номер горизонтальной линии приемника
jne @@loop //возврат к циклу
mov ecx,i //восстановление счетчика внутреннего цикла
inc esi //верхний цикл
cmp esi,i //esi - доп.смещение вправо
jne @@loop
popad
end;
Добавлено ([mergetime]1282041519[/mergetime]):
кажется, работает
CODE
procedure RotateEast(inp: Pointer; res: Pointer; size: integer);
var // eax edx ecx
i: integer;
asm
pushad
mov i,ecx //сохранить размерность
mov esi,0 //дополнительный счетчик от 0 до (size-1)
@@loop:
dec ecx //ecx: счетчик от (size-1) до 0
mov ebx,[eax] //inp - получить пиксель
mov edi,i //вычисление адреса конечной точки:
imul edi,4 //4*номер_строки*размер_изображения
imul edi,ecx //ecx - номер строки
add edi,edx //edx = res (адрес картинки-приемника)
mov [edi+esi*4],ebx //добавление к адресу позиции в строке*4
add eax,4 //смещение указателя источника (1 пиксель прочитан)
cmp ecx,0 //ecx - номер горизонтальной линии приемника
jne @@loop //возврат к циклу
mov ecx,i //восстановление счетчика внутреннего цикла
inc esi //верхний цикл
cmp esi,i //esi - доп.смещение вправо
jne @@loop
popad
end;
Добавлено ([mergetime]1282041519[/mergetime]):
кажется, работает
Кто знает, как написать прогу на паскале, которая будет выбирать случайно один из двух вариантов с указанной вероятностью. А также выбирать один из нескольких вариантов с равной вероятностью.
кажется, random
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.