OberonCore

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

Вот в соседнем цехе коллеги сообщают:


Это не ради памяти. Это генетически в нас заложено ))

раньше да (поэтому и пишу, что было плохо реализовано). сейчас, насколько помню, есть официальный системный вызов «создать безымянный временный файл», у него сразу имени не будет (могу ошибаться, возможно это только обёртка в libc — см. `tmpfile 3`).

более того: это полностью соответствует парадигме «освобождением ресурсов занимается GC». ведь в языке нет официального `try/finally` — которое было бы необходимо, если бы операция подразумевалась явной.

Тут как раз всё нормально через метод Closed.

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

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

Место - это исчерпаемый ресурс и это совершенно халатно позволять чему-то быть, что уже не нужно, но система ещё не знает об этом, потому что не провела очистку в неопределённый момент времени, при том, что нехватка ОЗУ и ППЗУ - это разные вещи.

Ещё одно предложение для ошибки ради ошибки.

Именно.

Если Вы хотя бы немного посмотрите исходники VisualOberon, то увидите, что они пестрят расширениями OO2C, которые в сторону КП, но с более уродливым синтаксисом. Так что нельзя утверждать, что VO написан на чистом Обероне-2.

КП в качестве языка реализации предложил Стюарт Гринхилл; я, подумав, с ним согласился. Смысл костылять в О2, если на КП это ложится гармоничнее.

Второй момент: для реализации VO нужно воссоздать окружение и библиотеки OO2C. Вот и хочу прикинуть, получится ли это на Ofront+. Хватит ли нам его средств вместо жутких расширений OO2C.

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

Не понял, что за чем следует, но нет. Сборка мусора, не связанная со сторонними ресурсами, в этом отношении не имеет недостатков. Проблема появляется тогда, когда объекты разных типов памяти оказываются связанными, но о проблемах ППЗУ язык не знает. Мусор в ППЗУ в условии нехватки места не может быть удалён, потому что в ОЗУ пока ещё места достаточно. Если продлить понятие сборки мусора с исключительно ОЗУ и на ППЗУ, то проблема тоже может уйти, но по понятным причинам этого нет.

сборщик мусора в Оберонах является и менеджером освобождения ресурсов (это примерно как «менеджер по клинингу»; уборщик — он и есть уборщик). это не ошибка, это было так задумано. управление памятью — лишь одна из задач GC. так сделано ровно по той же причине, по которой убрано DISPOSE. возвращение явного ручного управления ресурсами на пользовательском уровне — это то же самое, что и возвращение ручного управления памятью. оно не выполняет никакой практической задачи кроме радости программиста от того, что вместо записи алгоритмов ему опять дали покрутить винтики. а риторика «RAM — это одно, HDD/SDD/etc. — другое» в данном случае просто попытка ввести новые сущности туда, где они не нужны.

а если вам срочно-срочно необходимо убедиться, что всё закрыто, то для этого есть паттерн, который довольно часто применяется и в коде BBCB: вызывайте `Kernel.Collect;`. но скорее всего, в реальном софте вам это понадобится примерно никогда.

никто не мешает организовать и другие оптимизации с подсчётом ссылок, и закрывать ещё не собраные файлы при вызове `Old()` или `New()` (потому что это единственные места, где оно важно). но постулировать явный `Close` и нагружать приложения заботой управлять тем, чем отлично автоматически управляет машина — неверно. его вообще надо бы выкинуть, как и DISPOSE, но тогда сломается совместимость.

Это неправда, и общедоступный Close существует вовсе не потому, что разработчики хотели "порадоваться". И Adimetrius даже приводил пример, но лишь один из всего множества, если речь заходит о, тем более, всех разновидностях ресурсов.

И это не правда, потому что
1. Дело не только в том, что я пишу, но и в том, что я использую, и беда в том, что многие разработчики рассуждают также, как Вы, не ведая, что творят.
2. Ресурс может долго удерживаться ненужной ссылкой, и это распространённый способ утечки ресурсов.
3. Нехватка ОЗУ никак не связана с нехваткой ППЗУ, и просто так делать обход ОЗУ ради ППЗУ - это ненужный костыль.

В целом же, закрытие нужно даже для памяти при правильном введении параллельности в язык.

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

А как это связано с Close? Если я удержал где-то ссылку, то, скорее всего, не закрытую. Я делал пару раз такие ошибки в ББ, когда оставлял в кеше читатель текстов. А читатель ссылается на текст, а текст - на файл. Обязанность или возможность вызывать Close не помогла бы эту ошибку раньше выявить.

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

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

Всё сказанное не имело никакого отношения «а я люблю дёргать винтики!». Если Вы не считаете, что предложение не делать Close, а делать Collect, предельно плохим, то это печально.

Итак, если я удержал ссылку, то это намеренное сохранение связи. А если мне связь больше не нужна, то я уничтожаю ссылку. А не совершаю дополнительные действия. Это в общем случае так. Когда кадр уничтожается, кадровая переменная остается в памяти, и на нее могут быть ссылки. А те ссылки, что внутри него - уничтожаются. Получается "терминальная вершина" в графе ссылок. Так же делается с читателями, сканерами, окнами и т.п. Frame.view := NIL, .rider := NIL, Window.doc := NIL, etc.

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

Или ошибочное, как Вы сами писали сообщением раньше. Нередко, завершение - это важный этап. Не менее важный, чем все остальные, явно выделяемые этапы. Ничего удивительного, что закрытие может и, в ряде случаев, должно выделяться явно. И в общем случае это не имеет никакого отношения к сборке мусора в ОЗУ. Закрыть ≠ выбросить. Только сейчас обратил внимание, что это не было проговорено отдельно.

так, чисто чтобы подвести черту: Szyperski, Clemens (1992). Insight ETHOS: On Object-Orientation in Operating Systems (PhD) в разделе 3.4.2.4 использует как раз пример файлов как одно из обоснований поддержки обобщённой системы финализации в GC. таким образом, возврат одного и того же файлового (а также шрифтового, и другого ресурсного) объекта — не какой-то недосмотр или что-то подобное, а один из принципов дизайна системы. ровно по этой причине `.Close` вызывать не просто не надо, а опасно. там же выше говорится, что в GC специально была добавлена возможность быть вызваным в любой момент из любого места кода, так что вызов `Kernel.Collect` если необходимо «настоять» на том, чтобы некий ресурс был освобождён — вполне нормальное решение. более того, сам BBCB довольно активно это делает в разных местах.

я считаю, на этом вопрос с необходимостью `.Close` можно закрывать, Слово Бога ясно всё поясняет.

Думаю, что возможность создания ошибочной ситуации, не очень хорошая, мягко говоря. Вызовы .Close лучше бы были в таком случае сбалансированы. Раз у нас есть счётчик, сколько размещено объектов, то может быть это возможно как-то использовать для избежания проблемы. Скажем, если размещён объект два раза, то и закрывается файл, только тогда, когда оба объекта его отпустили через .Close, или пока они оба не улитизированы сборщиком, и тогда .Close вызовется финализаторами также сбалансированное число раз, и файл будет закрыт. Очень познавательная дискуссия получилась. Может её отделить в отдельную тему на форуме, и когда-нибудь продолжить. Это надо переварить и осмыслить.

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

кстати говоря: только что долго пытался понять, почему читалка текстовой модели, полученой из `Views.Old` (и уже открытой) весело трапается. а потому что код старый и кривой, при скане файлов в подсистеме каждый открывал, брал дату модификации, и — внимание — делал `f.Close`. видимо, в попытке экономить ресурсы. а я как раз до этого HostFiles правил, так что исключить баг в новых правках тоже было сложно.

в общем, сейчас пойду превращать `Close` в noop: я до сих пор не нашёл ни одного случая, когда могло бы понадобиться явно закрывать файлы через этот вызов; зато неаккуратное его использование запросто ломает код в неочевидных местах.


и ещё: может, стоит обсуждение `.Close()` выделить в отдельную тему?

А если я генерирую прошивку, а потом сторонней программой через Dialog.RunExternal её отправляю в микроконтроллер? Получается файл всё же надо закрыть явно, чтобы все файловые буферы записались на диск перед отправкой.