C# vs Kotlin

Привет всем!

Java c C# уже сравнивали несколько раз. А как насчёт улучшенного (а может кто то считает "улучшенного") варианта java - языка Kotlin?

0

Сообщение от Fulcrum_013 Слышал. Но оно точно так же стало ненужным.

Не слышали. Немодальное окно станет ненужным, когда ему скажут таким стать.

Сообщение от Fulcrum_013 И ни одного где корректность поведения обеспечивал бы GC.

Все примеры показывают корректность работы приложений с GC. Просто вы не хотите признавать.

Добавлено через 51 секунду
Fulcrum_013, приведите пример на C#, чтобы было видно, что GC бесполезен. Вы не можете.

0

Сообщение от Usaga Немодальное окно станет ненужным, когда ему скажут таким стать.

А когда на него ссылки потеряли оно типа ненужным быть сразу вдруг перестало?

Добавлено через 2 минуты

Сообщение от Usaga Все примеры показывают корректность работы приложений с GC. Просто вы не хотите признавать.

Приложение на языке с GC не есть работа GC. Т.е. C#!=GC. Для обеспечения корректности работы в вашем примере используются абсолютно теже средства как к примеру в дельфе в которой вообще никакой автоматики нет. Зачем нужен GC если корректность работы необходимо точно так же обеспечивать вручную?

Добавлено через 41 секунду

Сообщение от Usaga приведите пример на C#, чтобы было видно, что GC бесполезен. Вы не можете.

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

0

Сообщение от Fulcrum_013 А когда на него ссылки потеряли оно типа ненужным быть сразу вдруг перестало?

Тогда такое окошко будет трудновато закрыть. Так, что не надо на такое окно ссылку терять.

Сообщение от Fulcrum_013 Приложение на языке с GC не есть работа GC. Т.е. C#!=GC. Для обеспечения корректности работы в вашем примере используются абсолютно теже средства как к примеру в дельфе в которой вообще никакой автоматики нет. Зачем нужен GC если корректность работы необходимо точно так же обеспечивать вручную?

Работа с GC - отсутствие всякой работы с GC, как и необходимости в умных (и не очень) указателях и деструкторах. Вы можете такое сказать про свой код на С++?

Сообщение от Fulcrum_013 И я вам вам его приводил. И вы абсолютно то же пример привели. Ручное слежение за взаимосвязями без которого GC обеспечить корректность работы не в состоянии.

Никакого ручного слежения я не приводил. Единственное место, где-то что-то отдалённое было - WeakReferences. Но и то потому, что ваш пример был натягиванием желаемого на действительное. Дальнейшим примером с байндингом, я вам показал как привально такое делать, и WeakReferences не нужны в практическом коде.

0

Сообщение от Usaga Никакого ручного слежения я не приводил

Без вызова Dispose не работает. C вызовом Dispose работает. Какая разница как называется Dispose или Destroy или FreeAndNill или operator delete? Суть от этого не меняется - ручное отслеживание появления и перебор мусора. И это делает GC ненужным от слова совсем. И никаких средств автоматизировать этот процесс в языках GC быть не может. В отличии от языков без GC.

Добавлено через 6 минут
И причина не в том что GC как то испортился, он может это корректно обрабатывать если вызывать GC.Collect после каждого изменения ссылки. Причина в том что задачи вышли далеко за те рамки для которых пригодно отложенное решение вопроса. А при инстантном сканировании перебор мусора гораздо дешевле, при этом позволяет создать средства автоматики кастомизируемые под правила конкретной предметной области конкретной задачи. Т.е. автоматически решать задачи управления взаимосвязями которые GC не предназначен решать от слова совсем.

0

Сообщение от Fulcrum_013 Без вызова Dispose не работает. C вызовом Dispose работает. Какая разница как называется Dispose или Destroy или FreeAndNill или operator delete? Суть от этого не меняется - ручное отслеживание появления и перебор мусора. И это делает GC ненужным от слова совсем. И никаких средств автоматизировать этот процесс в языках GC быть не может. В отличии от языков без GC.

Dispose никак не связан со сборкой мусора. Это не аналог delete. Только команда объекту "вольно". Объект не переходит в состояние "уничтожен". Логика метода Dispose() произвольная. В случае форм - просто команда закрыться. А поскольку ссылок на форму не осталось, рано или поздно GC это дело подметёт.

Сообщение от Fulcrum_013 Т.е. автоматически решать задачи управления взаимосвязями которые GC не предназначен решать от слова совсем.

А он и не предназначался для этого. Его задача - убирать мусор. И он с этим справляется на ура, как вы могли увидеть своими глазами в размещаемых здесь примерах кода. Причём от программиста вообще ничего для этого не требуется.

0

Сообщение от Usaga Dispose никак не связан со сборкой мусора.

Dispose связан с разрывом ссылок без которого GC ничего убрать вообще не в состоянии, и инстантным высвобождением ресурсов. A delete связан с вызовом деструктора, который точно так же как Dispose занимается разрывом ссылок и высвобождением ресурсов. При этом при проходе по мусору для разрыва ссылок мы получаем попутно т.е вообще на халяву, список высвобождаемых блоков. Надеюсь понимаете что гораздо дешевле этим списком сразу же воспользоваться чем сканировать потом живых для построения этого же списка?

Добавлено через 27 минут

Сообщение от Usaga А он и не предназначался для этого.

Ну и я о чем.

Сообщение от Usaga Его задача - убирать мусор

А она не решабельна без решения задачи разрыва взаимосвязей для которой GC не предназначен.

Сообщение от Usaga И он с этим справляется на ура, как вы могли увидеть своими глазами в размещаемых здесь примерах кода.

Вот как раз и вижу что без ручного решения задачи разрыва взаимосвязей GC ничего не делает. Потому что ничто не подпадает под его определение мусора. Приведение же объектов в состояние пригодное для уборки GC требует инстантного прохода по мусору что делает GC ненужным, и при этом в языках с GC не имеет средств автоматического осуществления.

0

Fulcrum_013, Dispose() не связан с разрывом ссылок и уж тем более ничего общего с delete не имеет. Dispose() - метод, призывающий объект освободить ресурсы. Сам объект остаётся живим. Да и что за ресурсы он должен освобождать (и должен ли вообще) - на усмотрение разработчика. Т.е. это часть бизнес-правил.

delete - начало физического уничтожения. Это никакая ни аналогия Dispose().

Dispose() может быть не вызван, но сборщик объект всё равно грохнет, когда до него доберётся, если ссылок на объект не осталось. В случае с формой, то Dispose() - просто перевызов Close() и не более.

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

Добавлено через 2 минуты

Сообщение от Fulcrum_013 Ну и я о чем.

Так никто вам этого и не доказывает. Это вы придумали себе аргумент, который мне втюхиваете.

Сообщение от Fulcrum_013 А она не решабельна без решения задачи разрыва взаимосвязей для которой GC не предназначен.

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

Сообщение от Fulcrum_013 Вот как раз и вижу что без ручного решения задачи разрыва взаимосвязей GC ничего не делает. Потому что ничто не подпадает под его определение мусора.

В рассмотренных выше примерах, ручной работы по разрыву связей было на порядок меньше, чем в аналогичных примерах на С++, где нужно или деструктор описывать или умные указатели применять. Не тянет это на автоматику. В примеры на C# такого не требовали, как можно заметить.

Добавлено через 2 минуты
Fulcrum_013, давайте вы приведёте мне пример кода на С++, без умных указателей и деструкторов и мы с вами вместе посмотрим, насколько автоматически у вас рвутся ссылки и убираются ненужные объекты?

0

Сообщение от Usaga Dispose() не связан с разрывом ссылок

Типа байндинги в вашем примере Dispose ни разу не разрывает?

Сообщение от Usaga и уж тем более ничего общего с delete не имеет

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

Добавлено через 2 минуты

Сообщение от Usaga Я вам уже несколько примеров показывал, где это вообще ничего не требует от разрабочика.

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

0

Сообщение от Fulcrum_013 Типа байндинги в вашем примере Dispose ни разу не разрывает?

Их развязывает форма, когда закрывается. Закрыться она может и по вызову Close().

Сообщение от Fulcrum_013 Имеет абсолютно то же назначение что и деструктор, неявно вызываемый при вызове delete.

Деструктор уничтожает объект, переводя в неконсистентное состояние. Dispose() не уничтожает объект, только просит высвободить что можно и закрыть хендлеры (если таковые есть). Разные вещи. Никакой связи между ними нет и в помине.

Добавлено через 1 минуту

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

Вопрос разрыва байндингов - обнуление единственной ссылки на модель к которой действуют привязки. Элементарная операция.

Давайте посмотрим на аналогичную на С++, но без умных указателей и деструкторов?

0

Сообщение от Usaga Не тянет это на автоматику

Это тянет на кастомизируемую под предметную область автоматику. С GC же без костыля WeakReference как видим течет, да и тот не работает корректно. Ну не тянет этот ваш GC на автоматику не тянет. А тем более на кастомизируемую.
Еще раз для тех кто академиев не кончали и знаниев не имеют - в ООП есть два типа взаимосвязей. Поэтому для их реализации нужно не менее двух типов ссылок. И определить типы этих взаимосвязей разработчик обязан при анализе задачи и никакой язык от этой обязанности не избавит, может только помочь реализовать их поведение автоматически, чего GC сделать не в состоянии потому что предназначен для решения абсолютно противоположной задачи.

Добавлено через 2 минуты

Сообщение от Usaga Деструктор уничтожает объект, переводя в неконсистентное состояние.

Деструктор разрывает ссылки и высвобождает ресурсы. Это и есть неконсистентное состояние. Т.е. точно так же как и Dispose приводит объект в состояние пригодное для безопасной уборки. Высвобождением же памяти занимается operator delete. И именно потому что безопасное удаление буфера невозможно без предварительного приведения в пригодное для этого состояние перед вызовом delete и вставляется неявный вызов деструктор. Т.е. разница только в том что при ошибке в деструкторе (который в подавляющем большинстве случаев автоматически генерится и ошибка там практически невозможно) сразу же вылетит экскепшин, а при ошибке в рукописном Dispose() объект или незаметно утечет или оставит незакрытыми ресурсы.

Добавлено через 28 минут

Сообщение от Usaga Давайте посмотрим на аналогичную на С++, но без умных указателей и деструкторов?

Ну будет абсолютно точно так же как делается в дельфе и шарпе где автоматики нет. Умные указатели как раз и предназначены для того чтобы этот процесс кастомно автоматизировать. А автогенерацию деструкторов ну как бы в С++ ее отключить нельзя.

Сообщение от Usaga Вопрос разрыва байндингов - обнуление единственной ссылки на модель к которой действуют привязки. Элементарная операция.

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

Добавлено через 9 минут

Сообщение от Usaga Вопрос разрыва байндингов - обнуление единственной ссылки на модель к которой действуют привязки. Элементарная операция.

Ага. Которая абсолютно ничем не отличается от вызова delete, потому что точно так же иницирует просмотр мусора и без вызова которой все потечет. Т.е. вручную у вас все с вашим GC вручную.

0

Сообщение от Fulcrum_013 Это тянет на кастомизируемую под предметную область автоматику. С GC же без костыля WeakReference как видим течет, да и тот не работает корректно. Ну не тянет этот ваш GC на автоматику не тянет. А тем более на кастомизируемую.

Это не кастомизация, а ручная реализация того, что GC может сделать сам. Пример с WeakReference не показательный, ибо так никто не делает.

Сообщение от Fulcrum_013 Деструктор разрывает ссылки и высвобождает ресурсы. Это и есть неконсистентное состояние. Т.е. точно так же как и Dispose приводит объект в состояние пригодное для безопасной уборки.

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

Сообщение от Fulcrum_013 Т.е. разница только в том что при ошибке в деструкторе (который в подавляющем большинстве случаев автоматически генерится и ошибка там практически невозможно) сразу же вылетит экскепшин, а при ошибке в рукописном Dispose() объект или незаметно утечет или оставит незакрытыми ресурсы.

Объект не утечёт, ибо Dispose() не отменяет сборки мусора вообще никак. Как и не вызывает её.

Сообщение от Fulcrum_013 Ну будет абсолютно точно так же как делается в дельфе и шарпе где автоматики нет. Умные указатели как раз и предназначены для того чтобы этот процесс кастомно автоматизировать. А автогенерацию деструкторов ну как бы в С++ ее отключить нельзя.

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

Сообщение от Fulcrum_013 Ну дак вызов delete тоже элементарная операция из за которой вы он какой вой подняли даже при том что она автоматически производится. А эту операцию вручную отслеживать надо когда запустить с вашими GC. А вот те же средствва которые помогают автоматически delete взывать и эту операцию автоматически делают. И например в дельфе где таких средствов нету как и в шарпе обеспечение этих элементарных операций раздуло библиотеки до гига кода. То же самое и у винформза под капотом.

delete нужно или вручную вызывать, или прикручивать "кастомизацию". В управляемых языках этого делать не надо. Всё и так работает. Примеры вы видели, хоть и не стали запускать. Что и где в .NET раздуло - ваши личные ни на чём не основанные домыслы, ибо знать этого вы не можете.

Сообщение от Fulcrum_013 Ага. Которая абсолютно ничем не отличается от вызова delete, потому что точно так же иницирует просмотр мусора и без вызова которой все потечет. Т.е. вручную у вас все с вашим GC вручную.

Никакой связи с delete и "просмотром мусора" нет и в помине. Простой BindingSource.DataSource = null в том месте, где надо и тогда, когда надо. Здесь нет аналогий с delete. Да и такого не всегда надо, если модель, к которой привязались, сама осталась без ссылок. Такое очень часто делается - View Model как обёртка над моделью приложения.

Fulcrum_013, в общем, доказательства будут вашим тупым словам или нет?

0

Сообщение от Usaga Деструктор - последний этап перед полным уничтожением объекта. Dispose() - обычный метод, который можно вызывать хоть тысячу раз и который со сборкой мусора никак не связан.

ДЕструктор точно такой же обычный метод который точно так же можно вызывать явно.

Сообщение от Usaga Никакой связи с delete и "просмотром мусора" нет и в помине

Есть у деструктора который при вызове delete неявно вызывается.

Добавлено через 1 минуту

Сообщение от Usaga Простой BindingSource.DataSource = null в том месте, где надо и тогда, когда надо.

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

Добавлено через 1 минуту

Сообщение от Usaga В управляемых языках этого делать не надо

В управляемых языках это надо точно так же. Только там это невозможно в отличии от автоматики плюсов, а поэтому делается в ручную аки в паскале.

Добавлено через 3 минуты

Сообщение от Usaga Да и такого не всегда надо, если модель, к которой привязались, сама осталась без ссылок

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

Добавлено через 3 минуты

Сообщение от Usaga в общем, доказательства будут вашим тупым словам или нет?

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

Добавлено через 7 минут

Сообщение от Usaga что в управляемых языках умные указатели не нужны.

А костыли типа weakreference и using зачем тогда добавили? А потому что в ООП вопрос автоматического определения нужности/ненужности объекта не актуален. Он задачезависим и четко задается правилами предметной области - т.е. подкапотная автоматика решать его не в состоянии и как следствие вообще не нужна. А актуален вопрос автоматического разрыва взаимосвязей и высвобождения ресурсов для объектов ненужность которых определена по правилам предметной области. Но GC для этого не предназначен и корректно его решать не может даже с костылями. Для решения этого вопроса предназначены средства создания смартпоинтеров.
Т.е. с GC как в том анекдоте получается - задача вскипятить чай при полном чайнике и горящем костре - залить костер из чайника, задача сведена к предыдущей.

Добавлено через 19 минут

Сообщение от Usaga И я говорил не про автогенерацию дестукторов, а про их ручное описание с ручным же высвобождением ресурсов. Покажите мне такой пример.

Аналогично делаются и смартпоинтеры. Так что наличие/отсутсвие их в стандартной библиотеке никак не мешает их реализации c поведением подстроенным под реалии конкретной предметной области в отличии от GC, который ни инстантно реагировать на выход из скопа/удаление из списка не умеет ни средств кастомизации не имеет.

Добавлено через 1 минуту

Сообщение от Usaga Без них всё будет убрано.

Ну как видим не убирается.

Добавлено через 2 минуты

Сообщение от Usaga Как и не вызывает её.

Он просто обеспечивает ее возможность, разрывая взаимосвязи, без разрыва которых объекты не подпадают под правила определения мусора заложенные в GC. Разрыв же взаимосвязей необходимо производить инстантно при потери ссылки, иначе они не смогут быть произведены вообще. Что делает GC ненужным от слова совсем.

Добавлено через 4 минуты

Сообщение от Usaga И я говорил не про автогенерацию дестукторов, а про их ручное описание с ручным же высвобождением ресурсов.

Т.е. вы вообще не в теме как плюсы работают? О чем тогда речь? Идите учите матчасть по плакатам.

Добавлено через 23 минуты

Сообщение от Usaga Что и где в .NET раздуло - ваши личные ни на чём не основанные домыслы, ибо знать этого вы не можете.

Примеров фреймверков с ручным менеджментом взаимосвязей с доступным исходником море. В том числе и прообраза .NET - VCL. При этом возможны два варианта менеджмента взаимосвязей - полный ручник и кастомизируемая автоматика на деструкторах которая реализует тот же принцип что и ручник в автоматическом режиме. При этом автоматика на деструкторах делает GC ненужным от слова совсем.

Добавлено через 8 минут
Точно так же кстати как и ручной менеджмент взаимосвязей.

0

Сообщение от Fulcrum_013 ДЕструктор точно такой же обычный метод который точно так же можно вызывать явно.

Деструктор вызывают только питекантропы с точкой на лбу. И после вызова деструктора объект будет в неконсистентном состоянии. Dispose() такого не делает.

Сообщение от Fulcrum_013 Есть у деструктора который при вызове delete неявно вызывается.

using не является аналогом delete. Он не вызывает никаких деструкторов, он не уничтожает объект. Этот метод предназначен только для смены состояния объекта. Сам объект остаётся живым и целым.

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

Тем, что тут нет никакого удаления ничего.

Сообщение от Fulcrum_013 В управляемых языках это надо точно так же. Только там это невозможно в отличии от автоматики плюсов, а поэтому делается в ручную аки в паскале.

Это делать не надо. Я вам уже несколько разных примеров показал это доказывающих.

Сообщение от Fulcrum_013 А если не осталось?

Значит модель ещё нужна. Элементарно же.

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

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

Сообщение от Fulcrum_013 А костыли типа weakreference и using зачем тогда добавили?

Это не костыли. WeakReference для особых ситуаций, если вдруг станет нужно. Практика показывает, что не нужно почти никогда. Dispose() - для управления состоянием при выходе из скоупа. Удобно, но не связано со сборкой.

Сообщение от Fulcrum_013 Аналогично делаются и смартпоинтеры. Так что наличие/отсутсвие их в стандартной библиотеке никак не мешает их реализации c поведением подстроенным под реалии конкретной предметной области в отличии от GC, который ни инстантно реагировать на выход из скопа/удаление из списка не умеет ни средств кастомизации не имеет.

Вот. В C# такое писать не надо.

Сообщение от Fulcrum_013 Ну как видим не убирается.

Видим, что убирается. Примеры я вам привёл. Осталось только запустить.

Сообщение от Fulcrum_013 Он просто обеспечивает ее возможность, разрывая взаимосвязи, без разрыва которых объекты не подпадают под правила определения мусора заложенные в GC. Разрыв же взаимосвязей необходимо производить инстантно при потери ссылки, иначе они не смогут быть произведены вообще. Что делает GC ненужным от слова совсем.

Ничего он не разрывает. Запустите пример и уберите using. Вы удивитесь.

Сообщение от Fulcrum_013 Т.е. вы вообще не в теме как плюсы работают? О чем тогда речь? Идите учите матчасть по плакатам.

Ага. В вашем примере выше деструктор с fclose(handle) сам написался? Вы тут ни при чём? И при этом лечите мне про автоматику?

Сообщение от Fulcrum_013 Примеров фреймверков с ручным менеджментом взаимосвязей с доступным исходником море

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

Это значит, что вы не понимаете той темы, в которой хейтите.

0

Сообщение от Usaga Запустите пример и уберите using.

Удивлюсь чему? Тому что форма на которую потерянна ссылка осталась висеть на экране и имеет место утечка ресурсов? Ничего удивительного при использовании анахранизма под названием GC в этом нет.

Добавлено через 4 минуты

Сообщение от Usaga Ага. В вашем примере выше деструктор с fclose(handle) сам написался? Вы тут ни при чём? И при этом лечите мне про автоматику?

Вообще то про кастомизируемую автоматику. Программист указывает как уничтожать тот или иной объект что компилятор или любое другое средство спроектированное без учета конкретной предметной области знать естественно не может абсолютно, а вот когда это сделать определяет уже автоматика, при чем точно так же кастомизируется и способ определения.
С вашим же GC подобную операцию придется и вручную описыват и вручную вызывать.

Добавлено через 3 минуты

Сообщение от Usaga Раз за разом, я ваши заявления опровергаю, а вы переключаетесь на другую тему.

Что вы опровергли? Где уничтожение потерянной формы GC? Почему она висит на экране без действий аналогичных полностью ручному управлению?

Сообщение от Usaga Вот. В C# такое писать не надо.

В С# это проcто невозможно. А нужно точно так же.

Сообщение от Usaga Ничего он не разрывает.

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

Добавлено через 1 минуту

Сообщение от Usaga Начиналось всё с того, что вообще никакого приложения на .NET написать нельзя.

Начиналось с того что GC в условиях ООП бесполезен и не имеет абсолютно никаких различий с полностью ручным управлением памятью.

0

Сообщение от Fulcrum_013 Удивлюсь чему? Тому что форма на которую потерянна ссылка осталась висеть на экране и имеет место утечка ресурсов? Ничего удивительного при использовании анахранизма под названием GC в этом нет.

Она не остаётся. Пример работает корректно.

Сообщение от Fulcrum_013 Вообще то про кастомизируемую автоматику. Программист указывает как уничтожать тот или иной объект что компилятор или любое другое средство спроектированное без учета конкретной предметной области знать естественно не может абсолютно, а вот когда это сделать определяет уже автоматика, при чем точно так же кастомизируется и способ определения. С вашим же GC подобную операцию придется и вручную описыват и вручную вызывать.

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

Сообщение от Fulcrum_013 Что вы опровергли? Где уничтожение потерянной формы GC? Почему она висит на экране без действий аналогичных полностью ручному управлению?

Пример запустите и сами увидите.

Сообщение от Fulcrum_013 В С# это проcто невозможно. А нужно точно так же.

Это не нужно. Это лишние действия. C# позволяет без этого обходиться. Примеры вам даны. Вы их запускать не стали. Значит сказать на это вам просто нечего.

Сообщение от Fulcrum_013 Или код Dispose() формы в студию или пишите пример биндинга с разрывом сами. Подтвердите ваши голословные утверждения хотя бы чем нибудь.

Ещё раз: запустите пример без Dispose. У вас есть рабочий пример, его только запустить надо. Вот вам и доказательства.

Сообщение от Fulcrum_013 Начиналось с того что GC в условиях ООП бесполезен и не имеет абсолютно никаких различий с полностью ручным управлением памятью.

А кончилось тем, что вы как уж под каблуком извиваетесь. Вам уже примеры рабочие показали, доказывающие вашу неправоту. Вы даже запускать не удосуживаетесь.

Вы пример кода с формой и байндингами запускать не будете? Тогда и гнать прекращайте. У вас кончились аргументы.

0

Сообщение от Usaga Ещё раз: запустите пример без Dispose. У вас есть рабочий пример, его только запустить надо. Вот вам и доказательства.

Запусти. Потерянная форма висит незакрытой. Где автоматика?

Добавлено через 1 минуту

Сообщение от Usaga Вы пример кода с формой и байндингами запускать не будете?

Вот как раз по поводу него и вопрос. Где разрыв байдингов потерянной формы?

0

Сообщение от Fulcrum_013 Запусти. Потерянная форма висит незакрытой. Где автоматика?

А закрывать её кто будет? Это ваша обязанность, а не GC.

Сообщение от Fulcrum_013 Вот как раз по поводу него и вопрос. Где разрыв байдингов потерянной формы?

Закройте форму и увидите, что байндинги резко перестают мешать уборке формы.

0

Сообщение от Usaga А закрывать её кто будет? Это ваша обязанность, а не GC.

Т.е. рвать биндинги и убирать то что вышло из скопа GC получается не в состоянии? Дык о чем в исходе и говорилось.

Добавлено через 2 минуты

Сообщение от Usaga Закройте форму и увидите, что байндинги резко перестают мешать уборке формы.

Ну дак в Hide() разрыв и прописан вручную. Dispose только вызывает Hide(). Только вот GC не может убрать потерянную форму, без ручного вызова ручного разрыва байндингов? И чем это отличается от ручного вызова деструкторов перед выходом из скопа? Где автоматика?

0

Сообщение от Fulcrum_013 Т.е. рвать биндинги и убирать то что вышло из скопа GC получается не в состоянии?

Это здесь вообще не причём. Закрытое окно не мешает сборке и благополучно удаляется. Значит байндинги этому не мешают. Момент закрытия окна - не компетенция ни GC, ни деструктора. Хотите закрыть окно? Вызовите Hide\Close или Dispose. GC этого делать не обязан.

Сообщение от Fulcrum_013 Ну дак в Hide() разрыв и прописан вручную. Dispose только вызывает Hide(). Только вот почему GC не может убрать потерянную форму, без ручного вызова ручного разрыва байндингов? И чем это отличается от ручного вызова деструкторов перед выходом из скопа?

Открытая форма не являет потерянной. Ручное закрытие формы или через Dispose не связано с удалением. Это не тоже самое. Хотите по выходу из скоупа форму закрыть - заверните в using.

0

Сообщение от Usaga Это здесь вообще не причём.

Это здесь как раз и причем. Чем "не забыть закрыть окно" отличается от "не забыть вызвать деструктор"?

Добавлено через 37 секунд

Сообщение от Usaga Открытая форма не являет потерянной

Как это не является если у вас нет на нее ссылки?

Добавлено через 3 минуты

Сообщение от Usaga Значит байндинги этому не мешают.

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

0