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

Это сообщение отредактировал(а) En_t_end - 18.12.2006, 09:16

в общем случае вставки и вырезания ловятся динамическим программированием

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

но проблема в том, что матрица размером в квадрат размера файла - очень большой объект
обработать его может оказаться просто нереально

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

En_t_end, если есть время, то можешь попробовать разобраться с исходником программы cmp из пикета GNU diffutils. Имхо, там хороший алгоритм! 

Если ты не пишешь проприетарную софтину, а разрабатываешь открытое ПО (распространяемое по лицензии GNU [L]GPL), пишешь прогу для себя, или тебе просто нужна эффективная утилита для сравнения своих файлов (с точки зрения пользователя), то можешь использовать код проекта GNU. В двух последних случаях можешь просто использовать команду cmp, если пользуешься юниксом.

V_A_KeRneL, 

Мне говорили про неё. Но насколько мне известно, она работает эффективно только с текстовыми файлами.

maxim1000, 

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

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

skyboy, 
Хм... а вообще надо ли создавать матрицу ? недостаточно ли будет просто позиционироваться в файлах ?
maxim1000, 
Кстати, а как совместить этот метод с поиском различий ?

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

А то если честно, не ясно что вам нужно. ;)

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

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


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