Вот если мы сравниваем два нулевых указателя, то получаем true.
А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?

Здравствуйте, B0FEE664, Вы писали:

BFE>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?

Наверное, должно как-то зависеть от степени чистоты вакуума.

BFE>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?
У несуществующих файлов есть id, Name, или Hash?
Существование файла — это bool, int, или string[]?

Здравствуйте, Osaka, Вы писали:

BFE>>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?
O>У несуществующих файлов есть id, Name, или Hash?
Есть Name. Возможно даже два.

O>Существование файла — это bool, int, или string[]?
А как надо?

Здравствуйте, Евгений Музыченко, Вы писали:

BFE>>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?
ЕМ>Наверное, должно как-то зависеть от степени чистоты вакуума.

Да ладно! Философия или где?
Вот функция: bool AreEqualFiles(string strFilename1, string strFilename2); что должна возвращать?

Здравствуйте, B0FEE664, Вы писали:

BFE>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?

ну допустим файл это не что иное как file descriptor
несуществующий файл это ENOENT
сравнение двух ENOENT даст true

Здравствуйте, B0FEE664, Вы писали:

BFE>Вот функция: bool AreEqualFiles(string strFilename1, string strFilename2); что должна возвращать?

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

BFE>Да ладно! Философия или где?
BFE>Вот функция: bool AreEqualFiles(string strFilename1, string strFilename2); что должна возвращать?

Ну я бы кидал исключение "FileNotFound", потому что это сделает fail early легиону багов "ой, у нас тут путь потерялся", "ой, расширение не добавили", "ой на Linux case matters", и т.д.

Если принципиально хочется выпендриться, и функция в каком-то довольно универсальном API, то, в случае когда обоих нет, можно сравнить имена. Имена равны => true, потому что это один и тот же файл и он стопудово будет равен самому себе, когда только появится. Имена разные разные => false, по логике того же double NaN.

Но глобально, прежде чем выпендриваться, надо тогда подумать про пользователя этой функции. Если это API для каких-нибудь разных стратегий кэширования, которые открывают файлы исплючительно через OpenOrCreateNew, то для несуществующих файлов вообще можно возвращать всегда true. Потому что с точки зрения такого пользователя существуют абсолютно все файлы, просто часть из них пустые. А если клиент не такой экзотический, то всё-таки исключение однозначно лучше, кмк.

Здравствуйте, B0FEE664, Вы писали:

BFE>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?

Функция сравнения должна возвращать < > или =
А у вас функция проверки идентичности.
И должна она возвращать Identical если одинаковые, Different если разные и NoResult если по каким-то причинам пока невозможно их сравнить

Здравствуйте, B0FEE664, Вы писали:

BFE>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?

Не стоит в один ряд помещать сишные указатели и файлы. Более того, в некоторых языках два nul-указателя/ссылки на объекты не будут равны, на nul надо проверять использованием какого-нибудь isNul()

O>>Существование файла — это bool, int, или string[]?
BFE>А как надо?
Очевидно, если файл должен существовать в нескольких местах, а существует во всех/некоторых/ни в одном, — это разные степени не-существования.
А какая точность нужна в конкретном случае — для этого нужно знать предметную область.

BFE>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?
Если аналогия с указателями, то эти файлы существуют, но пустые.
Должно давать true
Размер одинаковый (ноль), а содержания нет ни одного байта.

Здравствуйте, LaptevVV, Вы писали:

BFE>>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?
LVV>Если аналогия с указателями, то эти файлы существуют, но пустые.
LVV>Должно давать true
LVV>Размер одинаковый (ноль), а содержания нет ни одного байта.

Файл с нулевым размером может существовать, а может не существовать. Два таких файла идентичны?

Здравствуйте, B0FEE664, Вы писали:

BFE>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?

Имхо, эта аналогия не совсем корректна. Значения указетелей нулевые, но сами указатели, всё-таки, существуют как объекты. И более корректной аналогией сравнения нулевых указателей было бы сравнение двух пустых файлов.

Семантика же операции сравнения несуществующих файлов, я думаю, будет определяться спецификой задачи верхнего уровня, в рамках которой потребность в таком сравнении возникла. Операция странная, как по мне, и общего правила я тут не вижу. Короче, как сам решишь, так и будет.

BFE>>>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>>>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?
LVV>>Если аналогия с указателями, то эти файлы существуют, но пустые.
LVV>>Должно давать true
LVV>>Размер одинаковый (ноль), а содержания нет ни одного байта.
D>Файл с нулевым размером может существовать, а может не существовать. Два таких файла идентичны?
А как ты несуществующий файл свяжешь с объектом в программе ?
Ты ж не с самим файлами работаешь, а с объектами программы.
Или filesystem это позволяет ? Я просто не пользовался.

Здравствуйте, LaptevVV, Вы писали:

BFE>>>>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>>>>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?
LVV>>>Если аналогия с указателями, то эти файлы существуют, но пустые.
LVV>>>Должно давать true
LVV>>>Размер одинаковый (ноль), а содержания нет ни одного байта.
D>>Файл с нулевым размером может существовать, а может не существовать. Два таких файла идентичны?
LVV>А как ты несуществующий файл свяжешь с объектом в программе ?
LVV>Ты ж не с самим файлами работаешь, а с объектами программы.
LVV>Или filesystem это позволяет ? Я просто не пользовался.

Просто это одно из условий задачи, сформулированной в изначальном посте. А пост этот в Философии.

Здравствуйте, LaptevVV, Вы писали:

BFE>>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?
LVV>Если аналогия с указателями, то эти файлы существуют, но пустые.
LVV>Должно давать true
LVV>Размер одинаковый (ноль), а содержания нет ни одного байта.

А если у одного из файлов имя invalid?

BFE>>>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>>>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?
LVV>>Если аналогия с указателями, то эти файлы существуют, но пустые.
LVV>>Должно давать true
LVV>>Размер одинаковый (ноль), а содержания нет ни одного байта.

VF>А если у одного из файлов имя invalid?
Тогда пишите новый тип данных, у которого понятие "пустой" содержит не единственное значение.

Здравствуйте, B0FEE664, Вы писали:

BFE>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?

Если "написать функцию сравнения двух файлов, на входе — 2 имени, на выходе — boolean" — это уже утвержденное/согласованное ТЗ, а стандартные функции получения длины и содержимого файла по его имени бросают исключения, то и функция сравнения должна пробросить эти исключения выше — программист не должен фантазировать, добавлять что-то в ТЗ от себя, да еще и писать лишний код. Об этом же и принцип YAGNI.

Если используемые стандартные файловые функции выдают информацию об ошибках доступа/несуществования файлов/папок как-то иначе — было бы логично следовать их принципу (наша функция вроде бы тоже "файловая") и передавать эту инфу выше (только если это не противоречит ТЗ).

Конечно, если есть возможность уточнить ТЗ — лучше это сделать.

Если эту задачу поставил себе сам программист — кому как не ему лучше знать ответ. Но в общем случае опять же YAGNI рулит.

Здравствуйте, B0FEE664, Вы писали:

BFE>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?

Зависит исключительно от внутренних правил системы
1 вариант
Файлы обязаны существовать даже с пустым содержимым, отсутсвующий файл — ошибка.
В этом случае сравнение обязано возвращать false — неравно. Это если оно не возвращает исключений.

2 вариант
Пустые файлы в целях оптимизации могут не записываться. Тогда отсутсвующий файл эквивалентен пустому.
В этом случае должно вернуть true.

Более общего ответа не существует

Здравствуйте, Doom100500, Вы писали:

D>Файл с нулевым размером может существовать, а может не существовать. Два таких файла идентичны?

Конечно, идентичны: "размер одинаковый (ноль), а содержания нет ни одного байта". Мы же не реальное существование файлов ищем — для этого существуют другие функции.

Здравствуйте, B0FEE664, Вы писали:

BFE>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?
Классика же:
https://thedailywtf.com/articles/Classic-WTF-What-Is-Truth

Здравствуйте, hi_octane, Вы писали:

BFE>>Да ладно! Философия или где?
BFE>>Вот функция: bool AreEqualFiles(string strFilename1, string strFilename2); что должна возвращать?
_>Ну я бы кидал исключение "FileNotFound", потому что это сделает fail early легиону багов "ой, у нас тут путь потерялся", "ой, расширение не добавили", "ой на Linux case matters", и т.д.

Бросить исключение просто, но вот поймать...
Ну и к тому же, отсутствие файла может вовсе не являться исключительной ситуацией, если это так, то исключение бросать — это вести себя странно.

Здравствуйте, Евгений Музыченко, Вы писали:

BFE>>Вот функция: bool AreEqualFiles(string strFilename1, string strFilename2); что должна возвращать?
ЕМ>Если она не умеет в исключения, то долг за те проблемы, которые может породить.

Какие, например?

Здравствуйте, Osaka, Вы писали:

O>>>Существование файла — это bool, int, или string[]?
BFE>>А как надо?
O>Очевидно, если файл должен существовать в нескольких местах, а существует во всех/некоторых/ни в одном, — это разные степени не-существования.
O>А какая точность нужна в конкретном случае — для этого нужно знать предметную область.

То есть обобщение сделать невозможно? Тогда хотелось бы примеры случаев, когда функция должна возвращать true для одной ситуации и false для другой.

Здравствуйте, kov_serg, Вы писали:

_>И должна она возвращать Identical если одинаковые, Different если разные и NoResult если по каким-то причинам пока невозможно их сравнить
Можете привести пример, когда NoResult должен обрабатываться иначе, чем Different?

Здравствуйте, Vi2, Вы писали:

D>>Файл с нулевым размером может существовать, а может не существовать. Два таких файла идентичны?
Vi2>Конечно, идентичны: "размер одинаковый (ноль), а содержания нет ни одного байта". Мы же не реальное существование файлов ищем — для этого существуют другие функции.

Интересная мысль. То есть это как со строкой: иногда пустая строка и NULL строка рассматриваются как равные...

Здравствуйте, rg45, Вы писали:

R>Имхо, эта аналогия не совсем корректна. Значения указетелей нулевые, но сами указатели, всё-таки, существуют как объекты. И более корректной аналогией сравнения нулевых указателей было бы сравнение двух пустых файлов.
В этой аналогии имена файлов играют роль указателей. Можно считать, что имена сами по себе существуют.

R>Семантика же операции сравнения несуществующих файлов, я думаю, будет определяться спецификой задачи верхнего уровня, в рамках которой потребность в таком сравнении возникла. Операция странная, как по мне, и общего правила я тут не вижу.
Мне в голову не приходит ситуация, для которой обработка различные файлов отличается от обработки, когда один или оба файла не существуют.

R>Короче, как сам решишь, так и будет.
Да, так обычно и бывает.

Здравствуйте, L_G, Вы писали:

L_G>Если "написать функцию сравнения двух файлов, на входе — 2 имени, на выходе — boolean" — это уже утвержденное/согласованное ТЗ, а стандартные функции получения длины и содержимого файла по его имени бросают исключения, то и функция сравнения должна пробросить эти исключения выше — программист не должен фантазировать, добавлять что-то в ТЗ от себя, да еще и писать лишний код. Об этом же и принцип YAGNI.

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

L_G>Если используемые стандартные файловые функции выдают информацию об ошибках доступа/несуществования файлов/папок как-то иначе — было бы логично следовать их принципу (наша функция вроде бы тоже "файловая") и передавать эту инфу выше (только если это не противоречит ТЗ).

Тоже самое — ситуация неотличима от предыдущего случая: код обработки результата вызова функции дублируется от вызова к вызову.

L_G>Конечно, если есть возможность уточнить ТЗ — лучше это сделать.
Предположим, что вы пишите ТЗ. Какое уточнение вы добавите?

L_G>Если эту задачу поставил себе сам программист — кому как не ему лучше знать ответ. Но в общем случае опять же YAGNI рулит.
Я не следую принципу YAGNI, так как этот принцип ведёт к написанию исключительно ситуативного кода и как следствие к нулевому переиспользованию. Мне просто не интересно писать такой код.

Здравствуйте, B0FEE664, Вы писали:

BFE>Мне в голову не приходит ситуация, для которой обработка различные файлов отличается от обработки, когда один или оба файла не существуют.

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

Здравствуйте, ·, Вы писали:

·>Классика же:
·>https://thedailywtf.com/articles/Classic-WTF-What-Is-Truth

А для этой классики есть классический коан, показывающий необходимость третьего значения?

Здравствуйте, B0FEE664, Вы писали:


L_G>>Конечно, если есть возможность уточнить ТЗ — лучше это сделать.
BFE>Предположим, что вы пишите ТЗ. Какое уточнение вы добавите?
Это зависит от задачи. Например, если ты решаешь задачу сделать бэкап, и надо потом убедиться, что AreEqualFiles("orig.file", "backup.file"). — ты уверен, что тут хочешь true, если дискетку достали в неподходящий момент? Тут явно надо написать страшное сообщение, что "целостность бэкапа не подтверждена" и true/false просто не обойтись.
Другое дело чтобы нарисовать diff например, можно предварительно проверить есть ли разница между "file.a" и "file.b", то true/false — достаточно.

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

Здравствуйте, B0FEE664, Вы писали:

BFE>·>Классика же:
BFE>·>https://thedailywtf.com/articles/Classic-WTF-What-Is-Truth
BFE>А для этой классики есть классический коан, показывающий необходимость третьего значения?
Просто подумать о решаемой задаче? Универсальный покрывающий всю логику псевдокод:

var f1 = open("f1");
var f2 = open("f2");
if(f1.error && f2.error) {
  action0;
} else if(f1.error) {
  action1;
} else if(f2.error) {
  action2;
} else if(f1.contents == f2.contents) {
  action3;
} else {
  action4;
}

Получается:
Если в твоей задаче action0==action1==action2==action3, то твоя "AreEqualFiles" может возвращать true.
Если в твоей задаче action0==action1==action2==action4, то твоя "AreEqualFiles" может возвращать false.
Если в твоей задаче только action0==action1==action2, то твоя "AreEqualFiles" может возвращать Error | Bool
А если вообще всё не равно, то вообще вся лесенка if-ов.

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, kov_serg, Вы писали:

_>>И должна она возвращать Identical если одинаковые, Different если разные и NoResult если по каким-то причинам пока невозможно их сравнить
BFE>Можете привести пример, когда NoResult должен обрабатываться иначе, чем Different?

Когда файлы имеют одинаковую длинну но доступ к одному или к обоим файлам запрещен или ошибки чтения и невозможно вычислить hash за разумное время или без внешнего вмешательства

Здравствуйте, B0FEE664, Вы писали:

BFE>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?

Файл — это контейнер из байтов, находящийся на диске и имеющий имя. То, что он находится на диске, большого значения не имеет. Имя при сравнении по условиям не учитывается.

Отсюда

1. Два непустых контейнера равны, если они побайтно совпадают.
2. Пустой контейнер (файл длины 0) не равен любому непустому контейнеру (файлу с длиной >0).
3. Два пустых контейнера равны.
4. Отсутствующий контейнер (несуществующий файл) не равен никакому существующему контейнеру (файлу), независимо от длины последнего.
5. Два отсутствующих контейнера равны.

P.S. Если речь идет о файлах NTFS, то этот алгоритм требует уточнения. Необходимо сравнить все именованные потоки в этих файлах, в них должны совпадать имена и содержимое. Обычный GetFileSize(Ex) вернет лишь длину неименованного потока данных в этом файле.

Здравствуйте, kov_serg, Вы писали:

_>>>И должна она возвращать Identical если одинаковые, Different если разные и NoResult если по каким-то причинам пока невозможно их сравнить
BFE>>Можете привести пример, когда NoResult должен обрабатываться иначе, чем Different?

_>Когда файлы имеют одинаковую длинну но доступ к одному или к обоим файлам запрещен или ошибки чтения и невозможно вычислить hash за разумное время или без внешнего вмешательства
Смотрите: если к одному файлу доступ разрешён, а к другому нет — то файлы разные, так как у них разные права доступа.
Смотрите: если доступ к обоим файлам запрещен или же ошибки чтения, то как будет выглядеть их обработка?

Здравствуйте, ·, Вы писали:

L_G>>>Конечно, если есть возможность уточнить ТЗ — лучше это сделать.
BFE>>Предположим, что вы пишите ТЗ. Какое уточнение вы добавите?
·>Это зависит от задачи. Например, если ты решаешь задачу сделать бэкап, и надо потом убедиться, что AreEqualFiles("orig.file", "backup.file"). — ты уверен, что тут хочешь true, если дискетку достали в неподходящий момент? Тут явно надо написать страшное сообщение, что "целостность бэкапа не подтверждена" и true/false просто не обойтись.
Ну почему же? Если функция возвращает false, т.е. файлы различны, то надо написать страшное сообщение, что "целостность бэкапа не подтверждена".

·>В общем, не надо писать такую функцию. А подумать о решаемой задаче получше и на основании этого принять решение о дизайне кода.
Может быть, но наверное стоит уточнить:
— всегда можно проверить доступ к файлам до вызова этой функции, но файлы могут исчезнуть в любой момент удалённые другой программой (например)
— обработчик ошибок можно добавить в качестве третьего аргумента функции.

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

BFE>Бросить исключение просто, но вот поймать...
Если в языке программирования сложно поймать исключения — он не годится для продакшн-разработки Основано на личном опыте и опыте тех дедов, которые эти самые исключения изобрели. Деды от души наработались на языках без исключений, "заплатили за них железную цену", и получили такие же железные аргументы за их нужность.

BFE>Ну и к тому же, отсутствие файла может вовсе не являться исключительной ситуацией, если это так, то исключение бросать — это вести себя странно.
We need to go deeper Вот ты проверил по File.Exists, а при чтении файла сетевой диск целиком отвалился (или флэшку вытащили). Теперь надо решить — этот файл пропал, но раз он пропал то его нет — а мы как раз решили не бросать исключение если файла нет. Или вот такое "файла нет" уже совсем другое, и оно уже настоящая проблема? Нужно ли дать вызывающей стороне понять что проблема не просто в "нет файла", а в том что всего сетевого диска больше нет? А вдруг вызывающей стороне надо отличать таймаут чтения файла от исчезновения сетевого адаптера?

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

Здравствуйте, ·, Вы писали:

BFE>>·>Классика же:
BFE>>·>https://thedailywtf.com/articles/Classic-WTF-What-Is-Truth
BFE>>А для этой классики есть классический коан, показывающий необходимость третьего значения?
·>Просто подумать о решаемой задаче?
Просто подумать недостаточно. Было бы хорошо ещё иметь доказательства существования ситуаций, когда третье значение используется.

	Скрытый текст
	·>Универсальный покрывающий всю логику псевдокод: ·> ·>var f1 = open("f1"); ·>var f2 = open("f2"); ·>if(f1.error && f2.error) { ·> action0; ·>} else if(f1.error) { ·> action1; ·>} else if(f2.error) { ·> action2; ·>} else if(f1.contents == f2.contents) { ·> action3; ·>} else { ·> action4; ·>} ·> ·>Получается: ·>Если в твоей задаче action0==action1==action2==action3, то твоя "AreEqualFiles" может возвращать true. ·>Если в твоей задаче action0==action1==action2==action4, то твоя "AreEqualFiles" может возвращать false. ·>Если в твоей задаче только action0==action1==action2, то твоя "AreEqualFiles" может возвращать Error | Bool ·>А если вообще всё не равно, то вообще вся лесенка if-ов.

Ну вот я и спрашиваю, есть ли такие задачи, где action4 отличается от action0,1,2 ?

Здравствуйте, B0FEE664, Вы писали:

_>>Когда файлы имеют одинаковую длинну но доступ к одному или к обоим файлам запрещен или ошибки чтения и невозможно вычислить hash за разумное время или без внешнего вмешательства
BFE>Смотрите: если к одному файлу доступ разрешён, а к другому нет — то файлы разные, так как у них разные права доступа.
Нет. Файлы могут быть одинаковые и разные. Но это пока невозможно определить => данный вопрос должен быть отложен до решения проблем с доступом.

BFE>Смотрите: если доступ к обоим файлам запрещен или же ошибки чтения, то как будет выглядеть их обработка?
Элементарно. Они заносятся в список проблем и обрабатываем остальные файлы.

Здравствуйте, hi_octane, Вы писали:

BFE>>Бросить исключение просто, но вот поймать...
_>Если в языке программирования сложно поймать исключения — он не годится для продакшн-разработки Основано на личном опыте и опыте тех дедов, которые эти самые исключения изобрели. Деды от души наработались на языках без исключений, "заплатили за них железную цену", и получили такие же железные аргументы за их нужность.
Исключения нужны, когда разрабатывается многоуровневая система в которой есть альтернативный способ работы при многокомпонентной системе, а не когда нужно два файла сравнить.

BFE>>Ну и к тому же, отсутствие файла может вовсе не являться исключительной ситуацией, если это так, то исключение бросать — это вести себя странно.
_>We need to go deeper Вот ты проверил по File.Exists, а при чтении файла сетевой диск целиком отвалился (или флэшку вытащили). Теперь надо решить — этот файл пропал, но раз он пропал то его нет — а мы как раз решили не бросать исключение если файла нет. Или вот такое "файла нет" уже совсем другое, и оно уже настоящая проблема?
Нет, обнаруживать проблемы такого рода — это вне функциональности данной функции.

_>Нужно ли дать вызывающей стороне понять что проблема не просто в "нет файла", а в том что всего сетевого диска больше нет?
Нет. Это обнаружится либо на следующем этапе работы, либо вообще не важно.

_>А вдруг вызывающей стороне надо отличать таймаут чтения файла от исчезновения сетевого адаптера?
Мы всё ещё говорим о функции сравнения двух файлов?

_>Попытка взять на себя кусочек чужой ответственности всегда плохо заканчивается.
Именно!

_> Ты не предусмотришь в своей функции всех проблем с тем, что, случается, подсовывают под видом файла. Того что файл есть, но открыть его нельзя из-за прав доступа, и ещё кучи нюансов. И точно также не предусмотришь всех нюансов вызывающей стороны.
Правильно. Именно поэтому все ошибочные ситуации надо рассматривать одинаково, независимо от их природы. Нет доступа? Нет файла? А какая разница? Почему бы в обоих случаях не вернуть false — файлы разные. Что не так?

Здравствуйте, kov_serg, Вы писали:

_>>>Когда файлы имеют одинаковую длинну но доступ к одному или к обоим файлам запрещен или ошибки чтения и невозможно вычислить hash за разумное время или без внешнего вмешательства
BFE>>Смотрите: если к одному файлу доступ разрешён, а к другому нет — то файлы разные, так как у них разные права доступа.
_>Нет. Файлы могут быть одинаковые и разные. Но это пока невозможно определить => данный вопрос должен быть отложен до решения проблем с доступом.
Не-а. Даже если содержимое файлов одинаковое, то это не значит что файлы одинаковые — ведь их атрибуты различаются.

BFE>>Смотрите: если доступ к обоим файлам запрещен или же ошибки чтения, то как будет выглядеть их обработка?
_>Элементарно. Они заносятся в список проблем и обрабатываем остальные файлы.
И как потом обрабатывается этот список проблемных файлов?

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, kov_serg, Вы писали:

_>>>>Когда файлы имеют одинаковую длинну но доступ к одному или к обоим файлам запрещен или ошибки чтения и невозможно вычислить hash за разумное время или без внешнего вмешательства
BFE>>>Смотрите: если к одному файлу доступ разрешён, а к другому нет — то файлы разные, так как у них разные права доступа.
_>>Нет. Файлы могут быть одинаковые и разные. Но это пока невозможно определить => данный вопрос должен быть отложен до решения проблем с доступом.
BFE>Не-а. Даже если содержимое файлов одинаковое, то это не значит что файлы одинаковые — ведь их атрибуты различаются.
Ага не скрепные файлы? Или лежат не не освещенном носителе. Может у вас еще и имя файла должно совпадать?

BFE>>>Смотрите: если доступ к обоим файлам запрещен или же ошибки чтения, то как будет выглядеть их обработка?
_>>Элементарно. Они заносятся в список проблем и обрабатываем остальные файлы.
BFE>И как потом обрабатывается этот список проблемных файлов?
Очень просто он обрабатывается потом. Например у вас 100500 файлов и только 2 проблемных. Вы же не будете останавливать весь споцесс из-за такой мелочи, особенно если порядок файлов не определён.
Просто уведомить того кто поставил задачу о наличии проблем и это уже его задача устранить проблему и запустить повторную обработку.

Здравствуйте, B0FEE664, Вы писали:

BFE>Ну вот я и спрашиваю, есть ли такие задачи, где action4 отличается от action0,1,2 ?
Я ж тебе уже привёл пример выше.
Или ещё вот: "периодически проверяем, нужно ли начать процесс бэкапа?":
Если первого файла нет (action0 | action1) или оба файла есть, но они равны (action3), то ничего не делаем.
Если оба файла есть, но они неравны (action4), то начинаем процесс бэкапа.

Ещё раз. Ты решаешь задачу "как упаковать 5 разных значений в один бит". В общем случае такое не решается. А наличие конкретных частных условий, когда это возможно — не позволяет тебе выдать универсальное решение.

Здравствуйте, B0FEE664, Вы писали:

ЕМ>>Если она не умеет в исключения, то долг за те проблемы, которые может породить.

BFE>Какие, например?

Э-э-э... Типичное понимание термина "файл" — это не математическая абстракция над которой операция сравнения определяется произвольно, а контейнер, с содержимым которого работает операция сравнения. Если контейнер не существует, то с чем работает операция, чтоб она не стала математической абстракцией?

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

Если ситуация отсутствия хотя бы одного из файлов ПРЕДУСМАТРИВАЕТСЯ общей задачей, то логичнее проверить их наличие ДО вызова функции сравнения и соответственно среагировать (и это будет ветвление, а не обработка исключения). Если не предусматривается — то дефолтный обработчик всех необработанных никем исключений — как раз адекватное место для реакции на НЕпредусмотренные ситуации.

BFE>Предположим, что вы пишите ТЗ. Какое уточнение вы добавите?

Возможна масса вариантов, зависящих от общей задачи:
а) ситуация отсутствия файлов предусматривается, является ошибкой конфигурации/интеграции/пользователя и должна быть обработана ДО сравнения — тогда не обрабатывать исключения в сравнении, пусть они сигнализируют об ошибке ПРОГРАММИСТА (забывшего заранее обработать ситуацию)
б) ситуация отсутствия файлов НЕ предусматривается (невозможна/невероятна) — опять же не обрабатывать исключения в сравнении, пусть они сигнализируют об ИСКЛЮЧИТЕЛЬНОЙ ситуации
в) ситуация отсутствия файлов предусматривается, при этом отсутствующий файл можно рассматривать как неотсутствующий (пустой и т.п.) — эту ситуацию другие комментаторы уже рассмотрели, не буду углубляться, т.к. вариантов всё равно больше одного.
г) никакой общей задачи нет, наше ТЗ — на шарообразную функцию в вакууме — тогда для УНИВЕРСАЛЬНОСТИ придется ввести третий входной параметр, в котором будет enum из всех возможных вариантов обработки ситуации несуществования файлов, и все эти варианты реализовать. (Если ЯП позволяет — можно задать дефолтное значение для параметра и можно будет его не прописывать в вызове.)

BFE>Я не следую принципу YAGNI, так как этот принцип ведёт к написанию исключительно ситуативного кода и как следствие к нулевому переиспользованию. Мне просто не интересно писать такой код.

Принцип YAGNI призван экономить время программиста (ну не получается заранее ВСЁ предугадать и написать УНИВЕРСАЛЬНЫЙ код; попытки его таки написать отнимают кучу времени сейчас и вовсе не гарантируют экономии времени в будущем). Сделать программирование интересным — это другая задача, с задачей экономии времени она слабо пересекается.

Здравствуйте, kov_serg, Вы писали:

BFE>>Не-а. Даже если содержимое файлов одинаковое, то это не значит что файлы одинаковые — ведь их атрибуты различаются.
_>Ага не скрепные файлы? Или лежат не не освещенном носителе.
Нет, просто файлы разные.

_>Может у вас еще и имя файла должно совпадать?
проверка имён — это другая функция.

_>Очень просто он обрабатывается потом. Например у вас 100500 файлов и только 2 проблемных. Вы же не будете останавливать весь споцесс из-за такой мелочи, особенно если порядок файлов не определён.
Где-то тут рядом кто-то в таких ситуациях предлагает исключение бросать...

_>Просто уведомить того кто поставил задачу о наличии проблем и это уже его задача устранить проблему и запустить повторную обработку.
Фактически это отсутствие обработки и игнорирование проблем. Если со списком потом никто не работает, то зачем он вообще нужен? Ерунда какая-то... У меня в коде есть ситуация, где ведётся список проблемных файлов, но совершенно с другой целью — игнорировать их при последующей обработке...

Здравствуйте, B0FEE664, Вы писали:

_>>Может у вас еще и имя файла должно совпадать?
BFE>проверка имён — это другая функция.
Хорошо, но уже лучше. И ещё надо не забывать, что:
Если имена не совпали, то это всё равно может быть один и тот же файл (симлинки, хардлинки, сетевые пути, UNC-пути).
Если имена совпали, то при открытии одного того же имени — это могут быть разные файлы.

Здравствуйте, L_G, Вы писали:

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

L_G>Если ситуация отсутствия хотя бы одного из файлов ПРЕДУСМАТРИВАЕТСЯ общей задачей, то логичнее проверить их наличие ДО вызова функции сравнения и соответственно среагировать (и это будет ветвление, а не обработка исключения). Если не предусматривается — то дефолтный обработчик всех необработанных никем исключений — как раз адекватное место для реакции на НЕпредусмотренные ситуации.

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

BFE>>Предположим, что вы пишите ТЗ. Какое уточнение вы добавите?

L_G>Возможна масса вариантов, зависящих от общей задачи:
L_G>а) ситуация отсутствия файлов предусматривается, является ошибкой конфигурации/интеграции/пользователя и должна быть обработана ДО сравнения — тогда не обрабатывать исключения в сравнении, пусть они сигнализируют об ошибке ПРОГРАММИСТА (забывшего заранее обработать ситуацию)
см. выше.

L_G>б) ситуация отсутствия файлов НЕ предусматривается (невозможна/невероятна) — опять же не обрабатывать исключения в сравнении, пусть они сигнализируют об ИСКЛЮЧИТЕЛЬНОЙ ситуации
С трудом, но наверное такое можно себе представить.

L_G>Принцип YAGNI призван экономить время программиста (ну не получается заранее ВСЁ предугадать и написать УНИВЕРСАЛЬНЫЙ код; попытки его таки написать отнимают кучу времени сейчас и вовсе не гарантируют экономии времени в будущем). Сделать программирование интересным — это другая задача, с задачей экономии времени она слабо пересекается.

Ага, я такую "экономию" не один год уже наблюдаю: коллектив переписывает одну и ту же функциональность в который раз. И каждый раз с ошибками отличными от предыдущей реализации. На каждом конкретном месяце экономия есть, а в целом — упущенная выгода. Впрочем это проблемы работодателя, а не работников.

Кстати! Добавление исключения в функцию — это ведь как раз попытка написать универсальный код, особенно если эти исключения не будут задействованы.

Здравствуйте, ·, Вы писали:

·>Если имена совпали, то при открытии одного того же имени — это могут быть разные файлы.
А это как?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Э-э-э... Типичное понимание термина "файл" — это не математическая абстракция над которой операция сравнения определяется произвольно, а контейнер, с содержимым которого работает операция сравнения. Если контейнер не существует, то с чем работает операция, чтоб она не стала математической абстракцией?

Это как со строкой: пустая строка и NULL строка могут рассматриваться как одинаковыми, так и различными. Зависит от задачи. Обычно, однако, пустую строку и NULL строку можно рассматривать равными.

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, ·, Вы писали:

BFE>·>Если имена совпали, то при открытии одного того же имени — это могут быть разные файлы.
BFE>А это как?

Это pipes или псевдо файл из procfs или просто постоянно обновляемый временный файл

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, kov_serg, Вы писали:

BFE>>>Не-а. Даже если содержимое файлов одинаковое, то это не значит что файлы одинаковые — ведь их атрибуты различаются.
_>>Ага не скрепные файлы? Или лежат не не освещенном носителе.
BFE>Нет, просто файлы разные.
Вы уже определитесь. Разные это значит только разное содержимое, любые метаданные туда не входят ни права ни атрибуты ни владелец ни дата на расположение на диске и т.п.

_>>Может у вас еще и имя файла должно совпадать?
BFE>проверка имён — это другая функция.
Это был сарказм.

_>>Очень просто он обрабатывается потом. Например у вас 100500 файлов и только 2 проблемных. Вы же не будете останавливать весь споцесс из-за такой мелочи, особенно если порядок файлов не определён.
BFE>Где-то тут рядом кто-то в таких ситуациях предлагает исключение бросать...
Нинужно никаких исключений они нарушают прямую исполнения. И она превращается в ужос нах. Особенно когда данные обрабатываются малыми группами по 2 — 3 млн шт

_>>Просто уведомить того кто поставил задачу о наличии проблем и это уже его задача устранить проблему и запустить повторную обработку.
BFE>Фактически это отсутствие обработки и игнорирование проблем. Если со списком потом никто не работает, то зачем он вообще нужен? Ерунда какая-то... У меня в коде есть ситуация, где ведётся список проблемных файлов, но совершенно с другой целью — игнорировать их при последующей обработке...
Нет это разнесение ответственности. Эта не задача функции сравнивающей идентичность файлов принимать решение что делать в сложных ситуациях. Её задача просто сообщить о проблемме, а не пытаться решать её или игнорировать втихоря.

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

"Ошибочность" вряд ли есть в предварительной проверке того, существовал ли файл вообще (или его "забыли" создать, или записали в другую папку и т.п. — т.е. в проверке на ошибки пользователя/интеграции/конфигурации/забывчивого программиста).

"Файл в любой момент может быть удалён кем-то ещё" больше походит на описание как раз исключительной (обрабатываемой исключениями) ситуации. Если это ожидаемая ситуация — тогда эти исключения придется либо (так себе вариант) ловить на КАЖДОЙ файловой операции отдельно (в т.ч. и после нашего сравнения, если предусмотрены дальнейшие действия над уже сравнёнными файлами), либо (проще и логичнее) завернуть в один try...catch всю группу операций (более широкую, чем наше сравнение) — и для второго варианта как раз лучше, чтобы в операции сравнения своей обработки исключений (ситуации отсутствия файлов) не было.

Из предложенных вариантов, попробую угадать, (г) (со ВСЕМИ заранее реализованными вариантами реакции на отсутствие файлов) оказывается более приемлемым?

BFE>Ага, я такую "экономию" не один год уже наблюдаю: коллектив переписывает одну и ту же функциональность в который раз. И каждый раз с ошибками отличными от предыдущей реализации. На каждом конкретном месяце экономия есть, а в целом — упущенная выгода. Впрочем это проблемы работодателя, а не работников.

Всегда остаётся вероятность, что YAGNI придумали идиоты и применение этого принципа в массовом индустриальном/энтерпрайзном программировании неоправдано. Но я в этот принцип почему-то поверил и даже широко применяю (видимо, потому, что я очень ленивый программист).
BTW, рационально мыслящие программисты обычно практикуют не переписывание с нуля, а дописывание нового с одновременным рефакторингом старого (рефакторинга в рамках необходимого для того, чтобы новое вписалось органично, а не в виде костылей). Думается, тем коллективом двигало как раз то самое хорошо знакомое тебе стремление сделать программирование интересным.

BFE>Кстати! Добавление исключения в функцию — это ведь как раз попытка написать универсальный код, особенно если эти исключения не будут задействованы.

На всякий случай: у меня о ДОБАВЛЕНИИ исключения в функцию речь не шла, проброска исключений из вызываемых функций выше (в вызывающую) не требует кода.

Здравствуйте, B0FEE664, Вы писали:

BFE>·>Если имена совпали, то при открытии одного того же имени — это могут быть разные файлы.
BFE>А это как?
Когда между открытиями меняется линк или заменяется файл.
Поэтому придумали во всяких less, tail специальный ключик --follow-name.

Здравствуйте, B0FEE664, Вы писали:

BFE>Зависит от задачи.

Вот именно. Но Вы-то поставили вопрос о некой всеобщей функции, которая умеет возвращать только true/false.

BFE>Обычно, однако, пустую строку и NULL строку можно рассматривать равными.

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

В этом смысле языки, не приравнивающие null/nil к пустой строке, исключительно правильны.

Здравствуйте, B0FEE664, Вы писали:

BFE>Вот если мы сравниваем два нулевых указателя, то получаем true.
BFE>А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?

Надо как в БД реализовано. Если что-то сравниваешь с null, то получаешь не true/false, а null

Здравствуйте, kov_serg, Вы писали:

BFE>>·>Если имена совпали, то при открытии одного того же имени — это могут быть разные файлы.
BFE>>А это как?

_>Это pipes или псевдо файл из procfs или просто постоянно обновляемый временный файл

Это не настоящие файлы. Вот как сравнивать содержимое таких файлов? Так что их можно даже не рассматривать, тем более, что они редки о часто не поддерживаются файловой системой.

Здравствуйте, ·, Вы писали:

BFE>>·>Если имена совпали, то при открытии одного того же имени — это могут быть разные файлы.
BFE>>А это как?
·>Когда между открытиями меняется линк или заменяется файл.
·>Поэтому придумали во всяких less, tail специальный ключик --follow-name.

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

Здравствуйте, Евгений Музыченко, Вы писали:

BFE>>Зависит от задачи.
ЕМ>Вот именно. Но Вы-то поставили вопрос о некой всеобщей функции, которая умеет возвращать только true/false.
Речь про строки, то есть аналогия. Не факт, что для файлов должен быть такой же подход.

BFE>>Обычно, однако, пустую строку и NULL строку можно рассматривать равными.
ЕМ>Обычно их как раз нельзя полагать равными. Если объект, связываемый со строкой, равен NULL, это может означать как то, что связь объекта со строкой не установлена или удалена, так и то, что где-то что-то испортилось, и в объект, который должен быть постоянно связан со строкой, попал NULL, и объект попросту не валиден. А если он связан с пустой строкой, то объект валиден, а в строке ничего нет.

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

ЕМ>В этом смысле языки, не приравнивающие null/nil к пустой строке, исключительно правильны.

Впрочем, если это так, то мы возвращаемся к изначальной формулировке. Файл — контейнер и строка — контейнер. NULL строка равна другой NULL строке. Значит два отсутствующих файла равны между собой?

Здравствуйте, L_G, Вы писали:

BFE>>Это ошибочный подход из-за "многопоточности". Файл в любой момент может быть удалён кем-то ещё, поэтому проверка что-либо до вызова функции не гарантирует, что в момент вызова функции файл всё ещё будет существовать.
L_G>"Ошибочность" вряд ли есть в предварительной проверке того, существовал ли файл вообще (или его "забыли" создать, или записали в другую папку и т.п. — т.е. в проверке на ошибки пользователя/интеграции/конфигурации/забывчивого программиста).

Я имел ввиду TOC/TOU

BFE>>Ага, я такую "экономию" не один год уже наблюдаю: коллектив переписывает одну и ту же функциональность в который раз. И каждый раз с ошибками отличными от предыдущей реализации. На каждом конкретном месяце экономия есть, а в целом — упущенная выгода. Впрочем это проблемы работодателя, а не работников.

L_G>Всегда остаётся вероятность, что YAGNI придумали идиоты и применение этого принципа в массовом индустриальном/энтерпрайзном программировании неоправдано. Но я в этот принцип почему-то поверил и даже широко применяю (видимо, потому, что я очень ленивый программист).

Вряд ли. Скорее методология должна соответствовать задаче. YAGNI не годится для V-Model, но подходит для agile. При этом сам agile не подходит для тех задач, где чёткие требования прописанные и подписанные в договоре, где V-Model — самое то.

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

Здравствуйте, kov_serg, Вы писали:

BFE>>Нет, просто файлы разные.
_>Вы уже определитесь. Разные это значит только разное содержимое, любые метаданные туда не входят ни права ни атрибуты ни владелец ни дата на расположение на диске и т.п.

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

Здравствуйте, B0FEE664, Вы писали:

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

"если приложение может сравнить содержимое" а если не может — отсутствие результата тоже результат

Здравствуйте, B0FEE664, Вы писали:

BFE>Значит два отсутствующих файла равны между собой?

Почему меня не покидает ощущение, что Вы вдумчиво подсчитываете чертей/ангелов на кончике иглы?

L_G>>Всегда остаётся вероятность, что YAGNI придумали идиоты и применение этого принципа в массовом индустриальном/энтерпрайзном программировании неоправдано. Но я в этот принцип почему-то поверил и даже широко применяю (видимо, потому, что я очень ленивый программист).

BFE>Вряд ли. Скорее методология должна соответствовать задаче. YAGNI не годится для V-Model, но подходит для agile. При этом сам agile не подходит для тех задач, где чёткие требования прописанные и подписанные в договоре, где V-Model — самое то.

YAGNI — обычно про фазу ПРОЕКТИРОВАНИЯ РЕАЛИЗАЦИИ требований/задачи. (Иногда её выполнят тот же программист, что и кодирует, но не суть.) И тогда ЕСЛИ у проектировщика/программиста возникает вопрос "а не забубенить ли мне/нам в коде ЕЩЕ И ЭТО?", YAGNI дает ответ: "НЕТ, это тебе/нам ПОКА не нужно. Когда будет нужно — поймём и тогда уже забубеним (когда уже нельзя будет отвертеться)."

В V-Model, насколько понимаю, есть выделенная стадия проектирования, которая должна завершиться до начала кодирования, но не суть. ЕСЛИ у проектировщика возник вопрос "а не забубенить ли нам...?" (при неизменности спущенных ему сверху требований), то он вполне может применить YAGNI и решить НЕ забубенивать, поскольку внешние требования этого не требуют и у него ЕСТЬ ВЫБОР. Кстати, экономия времени — это экономия денег (или становится ей при возрастании масштаба). Думаю, YAGNI подтверждает свою полезность статистически (на большинстве случаев), хотя всегда есть шанс не угадать (отказаться от того, что в будущем окажется полезным) и проиграть.

Даже на этапе обсуждения ТЗ с заказчиком YAGNI вполне применимо! Тут уже речь об экономии денег/времени заказчика. Если исполнитель хочет загрузить себя работой по максимуму, ОН применять YAGNI, урезая себе ТЗ и общую сумму договора, конечно же, не станет. Хотя — стоп — он ведь может надеяться на то, что урезанный проект обязательно потребует доработок и общая сумма с доработками будет больше, чем если всё сделать сразу. Тогда опять же использование YAGNI приобретает глубокий смысл

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

BFE>Не, большинство выбирает ехать, а не шашечки и как следствие частые аварии ведущие к костылям.

Тут я рассуждаю о конкретном случае "коллектив переписывает одну и ту же функциональность в который раз."
Если "выбирает ехать, а не шашечки" — о том, что впендюривают костыли, не тратя время на рефакторинг — то это случай, прямо ПРОТИВОПОЛОЖНЫЙ описанному переписыванию с нуля.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Почему меня не покидает ощущение, что Вы вдумчиво подсчитываете чертей/ангелов на кончике иглы?
Это потому, что они тоже не существуют.
Легко работать с объектами, которые существуют, а вы попробуйте сравнить два несуществующих файла. Не так-то это просто!
Как я понял из ответов есть разные подходы:
1) вообще не решать задачу в её рамках;
2) ввести аксиому, что отсутствующий файл равен пустому, тогда два несуществующих файла, очевидно, равны;
3) сказать, что генератор случайных чисел — это тоже файл и через это безумие сделать постановку задачи бессмысленной (ибо файл перестаёт быть равен самому себе);
4) сказать, что файл вне системы рассматривать смысла нет, поэтому надо использовать какие-то внутренние системные свойства...

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

PS Кстати, аналогия с указателями не верна: нулевой указатель и указатель на несуществующий объект — это два разных указателя.

Здравствуйте, B0FEE664, Вы писали:

BFE>вы попробуйте сравнить два несуществующих файла.

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

BFE>1) вообще не решать задачу в её рамках;

Каким образом была поставлена такая задача? Уж не "а давайте придумаем вот такое"?

BFE>Вывод: вопрос сложный

На мой взгляд, вопрос тупо бессмысленный.

BFE>Написал функцию так, чтобы результат был false для случая когда один или оба файла не существуют.

Что на очереди? Функция сравнения файла с указателем, возвращающая true, если файл не существует, а указатель равен нулю, и false в остальных случаях?

Здравствуйте, Евгений Музыченко, Вы писали:

BFE>>вы попробуйте сравнить два несуществующих файла.
ЕМ>Вот совершенно не вижу ни малейшей надобности. Сколько себя помню, ни разу не требовалась функция, успешно завершающаяся при любой (из четырех возможных) конфигурации двух файлов, и возвращающая только true/false. В программах, которые доводилось разбирать, тоже никогда такого не видел.

А сколько раз вообще вам приходилось сравнивать два файла?

Здравствуйте, B0FEE664, Вы писали:

BFE>Это не настоящие файлы. Вот как сравнивать содержимое таких файлов? Так что их можно даже не рассматривать, тем более, что они редки о часто не поддерживаются файловой системой.

Я встречал реализацию в памяти, где имя файла существовало, но в реальности файла на дисках/внешних хранилищах физически не было. Поэтому легко было создавать файлы типа C:\xxx.log с разным содержимым. Если не сделать кэш по именам, то файлы будут разные, хоть и иметь одинаковые имена. Конструкция с оптимизацией, конечно, но удовлетворяет теперешним условиям. Причём не предполагалось, что файл изначально будут в памяти. Так что работа с ними была как с настоящими файлами, и в начале и была таковой.

Здравствуйте, B0FEE664, Вы писали:

BFE>А сколько раз вообще вам приходилось сравнивать два файла?

Сколько-то раз приходилось, не очень много. Это как-то должно влиять на мое мнение по этому вопросу?

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

Здравствуйте, Vi2, Вы писали:

Vi2>Я встречал реализацию в памяти, где имя файла существовало, но в реальности файла на дисках/внешних хранилищах физически не было. Поэтому легко было создавать файлы типа C:\xxx.log с разным содержимым. Если не сделать кэш по именам, то файлы будут разные, хоть и иметь одинаковые имена.

И как там различались эти "разные" файлы с одинаковым именами? Если доступ к этим файлам происходил не по именам, а по каким-то другим реквизитам, то зачем таким файлам имена?

Здравствуйте, Евгений Музыченко, Вы писали:

BFE>>А сколько раз вообще вам приходилось сравнивать два файла?
ЕМ>Сколько-то раз приходилось, не очень много. Это как-то должно влиять на мое мнение по этому вопросу?
Да. На моё мнение. Прежде всего интересен опыт.

ЕМ>Если должно, то мне очень много раз приходилось сравнивать между собой объекты в памяти, но ни разу не возникло мысли сделать универсальную (чтоб непременно возвращала только true/false и не бросала исключений) функцию, которая вместе с существующими объектами втихушку обрабатывала бы и несуществующие.

Чтобы сравнивать работу с объектами в памяти с работой с файлами, нужно, чтобы объекты были доступны для любого приложения в системе и кто угодно мог бы их удалить в любой момент.
Говорят (сам не видел), что такое последний раз было в OS/2, и, как говорилось в рекламе, если в OS/2 у вас повиснет редактор текста, то у вас повиснет вся система, а если в Windows повиснет редактор текста, то повиснет только редактор, а не вся система.

Здравствуйте, B0FEE664, Вы писали:

BFE>Прежде всего интересен опыт.

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

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

ЕМ>>Если должно, то мне очень много раз приходилось сравнивать между собой объекты в памяти, но ни разу не возникло мысли сделать универсальную (чтоб непременно возвращала только true/false и не бросала исключений) функцию, которая вместе с существующими объектами втихушку обрабатывала бы и несуществующие.

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

Такое бывает и с объектами в памяти при многопоточной работе. Но вряд ли встретите в мало-мальски серьезной программе универсальную функцию сравнения произвольных объектов, чтоб возвращала только true/false, невзирая на факт существования объекта. Предикаты вида IsEmpty/IsNotEmpty иногда для упрощения считают несуществующий объект (в том числе файл) пустым, но это сугубо частный случай.

BFE>как говорилось в рекламе, если в OS/2 у вас повиснет редактор текста, то у вас повиснет вся система, а если в Windows повиснет редактор текста, то повиснет только редактор, а не вся система.

Как-то очень странно. Насколько помню характеристики OS/2, она изначально делалась достаточно надежной, и такое влияние рядового приложения на работу системы крайне маловероятно. А вот в 16-разрядных Windowss такое как раз бывало, если приложение слишком хитрожопое.

Здравствуйте, B0FEE664, Вы писали:

BFE>Не согласен. NULL строка — это такая строка, у которой нет значения. Например это строковое поле в базе данных у которого нет никакого значения.
Противоречите сами себе. У NULL строки значения нет. Его семантика — "мы не знаем". У "" значение есть — это пустая строка.
По канону, Len(NULL) даёт NULL — раз мы ничего не знаем о строке, то и длины её мы не знаем.
Len("") даёт 0. IndexOf(NULL, "мама мыла раму") даёт NULL, т.к. на вопрос "где в заданной строке находится неизвестно что" правильным ответом является "мы не знаем".
IndexOf("", "мама мыла раму") даёт 0, т.к. пустая подстрока "встречается" в любой строке везде, и самое первое вхождение — перед первым символом.
Соответственно, "" = "" даёт TRUE, "" = NULL даёт UNKNOWN, и NULL = NULL тоже даёт UNKNOWN.
То, что в Оракле сделано не так — это личные гуси Тома Кайта.