C# vs Kotlin

Привет всем!

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

0

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

Тем, что когда окну закрыться - решаете вы. И это только закрытие окна. А деструктор - уничтожение. Закрытое окно можно открыть снова. А уничтоженное?

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

Просто - она есть у фремворка WinForms (класс Application).

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

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

Ну так они есть - https://github.com/dotnet/winforms. Ройтесь в них на здоровье.

1

Сообщение от Usaga Это не значит, что байндинги разрываются

Пруф в студию.

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

Сообщение от Usaga Это значит, что они не мешают сборке.

Пруф в студию.

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

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

Ибо не умеете и не осилите?

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

Сообщение от Usaga Ну так они есть - https://github.com/dotnet/winforms. Ройтесь в них на здоровье.

НУ дак вот и найдите в них подтверждение вашим словам. Его там нет.

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

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

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

Сообщение от Usaga А деструктор - уничтожение

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

0

Fulcrum_013, Я не знаю о чем вы там спорили, наверно, о том, что палка - не трансформатора, ну да ладно.
Насчет Dispose. Чего он там аналог не знаю. По сути это просто метод интерфейса. А обращаясь к определению msdn, то Dispose освобождает неуправляемые ресурсы. Как бы намек на то, что в остальных случаях он не нужен. Dispose еще можно вызывать для отписки от событий, чтобы утечек не было. Это как бы не проблема сборщика, т.к. ты сам впихиваешь другому объекту ссылку на себя, а потом не удаляешь ее и ждешь почему же объект жив. И говоря на чистоту, Dispose - лишь метод. То есть, можно не можно вызывать, все зависит от того, как ты закодировал метод Dispose (ну или как его написал кто-то другой), а вообще можно и самому взять и определить метод, который будет освобождать ресурс, и как бы ничего противозаконного, только using для такого объекта работать не будет. И вообще Dispose есть не у всех объектов. Деструктор и Dispose вещи разные. Dispose кто-то должен вызвать ручками, ведь это обычный метод. А деструктор вызывает сборщик. Обращаясь к "стандартной" реализации IDisposable (которую предлагает VS): в деструкторе проверяется был ли вызван Dispose и он вызывается. Это что-то на тот случай, если кто-то так и не догадался вызвать Dispose, когда надо. Разницу в применении может продемонстрировать Dispose у файлов: пока файл открыт программой, его не могут открыть другие. Если в данный момент, скажем, после окончания записи, ты вызвал Dispose - то все, к файлу есть доступ. А если ты забыл, то тебе придется надеяться на случай и ждать пока сборщик сгребет объект и вызовет деструктор, который вызовет Dispose. И то как бы не гарантия (но в данном случае, зная реализацию Dispose для файлов, это так), что так будет. В деструкторе можно писать что угодно.

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

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

Ну вот насчет этого как раз и говорит msdn: для работы с неуправляемыми ресурсами.

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

Сообщение от Fulcrum_013 Т.е. делает то же самое что и Dispose.

Я думаю тут надо спорить о том, что писать в деструкторах, а что в Dispose.

Сообщение от Fulcrum_013 разрывает связи

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

Сообщение от Fulcrum_013 Т.е. делает то же самое что и Dispose.

А с чем тут спорить? С тем, что я могу написать в деструкторе Dispose(), а могу и не написать?

1

Сообщение от RaevskiAnatoly А деструктор вызывает сборщик.

Вы путаете деструкторы (которых в системах с GC нет), и финализаторы.

1

Сообщение от Curry Вы путает деструкторы (которых в системах с GC нет), и финализаторы.

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

Добавлено через 2 минуты
Curry, Кстати.

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

1

Сообщение от Curry Вы путает деструкторы (которых в системах с GC нет), и финализаторы.

В C# деструкторы называются финализаторами. Но, вызвать их явно нельзя из вне, поскольку финализаторы в C# просто синтаксический сахар над Finalize:
Так что прямой аналогии между деструкторами в C++ (том же) и C# нет.

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

Сообщение от Fulcrum_013 Т.е. делает то же самое что и Dispose.

Нет. Метод Dispose - метод, который, по соглашению, должен высвобождать неуправляемые ресурсы объекта, с которыми GC не взаимодействует. А финализатор - предназначен для подготовки объекта к удалению (вызывать внутри финализатора Dispose никем не запрещается).

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

Сообщение от Fulcrum_013 При этом поелику список высвобождаемых буферов известен заранее, то то что Dispose не высвобождает их сразу - это огромнейший недостаток, дающий гигантский и абсолютно бесполезный отложенный оверхед.

Сборщик мусора не знает ничего о методе Dispose. Это обычный метод. Только был вынесен в интерфейс IDisposable для стандартизации кода. Когда вызывать метод - решает программист.

0

Сообщение от Fulcrum_013 Пруф в студию.

Пруфы вам предоставлялись. Вы их запускать не стали.

Сообщение от Fulcrum_013 НУ дак вот и найдите в них подтверждение вашим словам. Его там нет.

Ткните в конкретное место.

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

Ну так его и надо закрыть перед такой потерей.

Сообщение от Fulcrum_013 Т.е. делает то же самое что и Dispose.

Не совсем. Dispose не делает объект невалидным. И вообще доступен для прямого вызова и не запрещает перевызывать этот метод множество раз. А деструктор вызывается в процессе уничтожения. Разные вещи.

1

Сообщение от Usaga Не совсем. Dispose не делает объект невалидным.

Как это не делает?

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

То же самое и с деструктором.

Сообщение от Usaga А деструктор вызывается в процессе уничтожения. Разные вещи.

НЕ путайте уничтожение объекта и уничтожение буфера. Это две огромные разницы. Преимущество деструктора именно в том что он автоматически вызывается перед уничтожением буфера.

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

Сообщение от Usaga Ну так его и надо закрыть перед такой потерей.

Автоматика где?

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

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

Вы предоставили пруфы исключительно того что к обеспечению корректного поведения GC абсолютнно не причастен. Ну не может он ресурсами управлять не может. Об этом в любой доке и на любом заборе написано кроме как в алгоритме показано.
А окно какой -никакой но ресурс оси.

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

Сообщение от Соколиный глаз Нет. Метод Dispose - метод, который, по соглашению, должен высвобождать неуправляемые ресурсы объекта, с которыми GC не взаимодействует. А финализатор - предназначен для подготовки объекта к удалению (вызывать внутри финализатора Dispose никем не запрещается).

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

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

Сообщение от RaevskiAnatoly Это как бы не проблема сборщика, т.к. ты сам впихиваешь другому объекту ссылку на себя, а потом не удаляешь ее и ждешь почему же объект жив

Это проблема именно GC. При этом именно GC полностью исключает автоматику в этом вопросе. А наличие подобной автоматики делает GC абсолютно ненужным. При этом наличие двунаправленных ссылок необходимо для реализации правил взаимосвязей ООП.

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

Сообщение от Соколиный глаз Когда вызывать метод - решает программист.

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

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

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

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

Речь как бы не о шарповском куцем обрубке а о полноценном плюсовом деструкторе. Который и гарантия и пишутся которые для подавляющего большинства классов вообще автоматически. Т.е. суть его ручного написания только в том чтобы указать как именно какой тип ресурса высвобождать. Остальное - когда вызвать делает автоматика.

Сообщение от RaevskiAnatoly Ну вот насчет этого как раз и говорит msdn: для работы с неуправляемыми ресурсами.

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

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

Сообщение от RaevskiAnatoly Это как бы не проблема сборщика, т.к. ты сам впихиваешь другому объекту ссылку на себя, а потом не удаляешь ее и ждешь почему же объект жив. И говоря на чистоту, Dispose - лишь метод. То есть, можно не можно вызывать, все зависит от того, как ты закодировал метод Dispose (ну или как его написал кто-то другой), а вообще можно и самому взять и определить метод, который будет освобождать ресурс, и как бы ничего противозаконного, только using для такого объекта работать не будет. И вообще Dispose есть не у всех объектов.

Dispose должен быть у всех объектов которые могут прямо или косвенно владеть объектами поизведенными абстрактными фабриками и/или реализуют паттерн композит. И вызывать для них Dispose необходимо явно. Иначе никакой уборки не состоится вообще.

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

Сообщение от RaevskiAnatoly Это как бы не проблема сборщика, т.к. ты сам впихиваешь другому объекту ссылку на себя, а потом не удаляешь ее и ждешь почему же объект жив.

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

0

Сообщение от Fulcrum_013 Как это не делает?

Вот так вот. Совершенно просто. Dispose не является частью "логики удаления" или чего-то аналогичного. Просто метод с произвольной логикой.

Сообщение от Fulcrum_013 То же самое и с деструктором.

Серьёзно? Вызывать деструктор вручную - нормально?

Сообщение от Fulcrum_013 НЕ путайте уничтожение объекта и уничтожение буфера. Это две огромные разницы. Преимущество деструктора именно в том что он автоматически вызывается перед уничтожением буфера.

Вот именно. Вызывается перед уничтожением. Dispose не имеет отношения к уничтожению.

Сообщение от Fulcrum_013 Автоматика где?

Там же, где и в С++, когда работаете с указателем.

Сообщение от Fulcrum_013 Вы предоставили пруфы исключительно того что к обеспечению корректного поведения GC абсолютнно не причастен. Ну не может он ресурсами управлять не может. Об этом в любой доке и на любом заборе написано кроме как в алгоритме показано. А окно какой -никакой но ресурс оси.

Какими ресурсами? Откуда взялось управление ресурсами со стороны GC? Вы решили, что GC за вас должен бизнес-логику реализовывать или что?

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

Dispose не предшествует сборке мусора. Откуда вообще вы эту взаимосвязь высмотрели?

0

Сообщение от Usaga Вызывать деструктор вручную - нормально?

Абсолютно.

Сообщение от Usaga Там же, где и в С++, когда работаете с указателем.

Абсолютно нет. При работе со смартпоинтерами инстантно преберается мусор.

Сообщение от Usaga Какими ресурсами?

В данном случае окнами.

Сообщение от Usaga Dispose не предшествует сборке мусора. Откуда вообще вы эту взаимосвязь высмотрели?

Ну оттудова что без разрыва взаимосвязей производимых Dispose ниче не уберется. Оно мусором ничего не посчитает.

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

Сообщение от Usaga Вот именно. Вызывается перед уничтожением. Dispose не имеет отношения к уничтожению.

Т.е. автоматика подготовки к безопасному уничтожению с GC недоступна.

0

Сообщение от Fulcrum_013 Абсолютно.

Это общепринятая практика или только вы так делаете?

Сообщение от Fulcrum_013 Абсолютно нет. При работе со смартпоинтерами инстантно преберается мусор.

В .NET не нужны смартпоинтеры. Внезапно, да?

Сообщение от Fulcrum_013 В данном случае окнами.

Это не ресурс.

Сообщение от Fulcrum_013 Ну оттудова что без разрыва взаимосвязей производимых Dispose ниче не уберется. Оно мусором ничего не посчитает.

Пример покажете?

Сообщение от Fulcrum_013 Т.е. автоматика подготовки к безопасному уничтожению с GC недоступна.

Dispose не имеет отношения к сборе мусора. При этом сборка мусора идёт корректно. Я вам уже приводил примеры.

0

Сообщение от Usaga Dispose не имеет отношения к сборе мусора. При этом сборка мусора идёт корректно. Я вам уже приводил примеры.

В которых без вызова Dispose сборщик ничего мусором посчитать не моет.

Сообщение от Usaga Пример покажете?

Показывал уже. Да и ваш пример с окошком из этой же серии.
без вызова Dispose из using не закрывается.

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

Сообщение от Usaga В .NET не нужны смартпоинтеры. Внезапно, да?

Пруф в студию.
К примеру закрытие окна по выходу ссылки из скопа.

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

Сообщение от Usaga Это общепринятая практика или только вы так делаете?

Все контейнеры так делают для хранимых элементов. Это операция обратная placement new. Т.е. для случаев когда объект живет в каком то общем и т.д. буфере предоставляемым кастомным аллокатором (т.е. распределяемым не через глобальный new). Ну обычно это очень глубоко под капотом библиотек используется.

Добавлено через 10 минут
А при использовании глобального оператора delete вызов деструктора просто добавляется компилятором автоматически.

т.е. код

компилятор преобразует в что то наподобие
Добавлено через 2 часа 28 минут

Сообщение от Usaga Dispose не является частью "логики удаления" или чего-то аналогичного

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

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

Сообщение от Соколиный глаз Метод Dispose - метод, который, по соглашению, должен высвобождать неуправляемые ресурсы объекта, с которыми GC не взаимодействует.

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

0

Возвращаясь к названию темы и СП. Создатели Kotlin качественно переработали сишножавный синтаксис. К примеру, доставляет то, что ключевое слово new оказалось избыточным. Если в выражении встречается MyClass(), то что это ещё может быть как не создание экземпляра класса? Так зачем впереди new ? Может я ошибаюсь, но мне кажется, что new свободно можно было бы выкинуть и в C++, Java, C#.

0

Сообщение от Curry Может я ошибаюсь, но мне кажется, что new свободно можно было бы выкинуть и в C++

В с++ можно упаковать очень глубоко в нетрях библиотек а вот выкинуть никак. MyClass() создается на стеке. А должен быть и способ создания на куче (ну или еще где то где разработчик объекта пожелает). Этим и занимается new.
А вот в Java и Java++ (алсо новн аз шарп) где на стеке никак таки по всей видимости можно что в котлине и сделали. В дельфе для объектов классов VCL которые на стеке селить запрещено кста ти сделали тоже самое еще в 90-х.

Добавлено через 8 минут
В плюсаж же давно рекомендуется создавать классы на куче через make_shared и make_unique или аналогичный функционал для своих смарт-поинтеров, а new и delete использовать только при реализации оных смартов.

0

Сообщение от Fulcrum_013 В с++ можно упаковать очень глубоко в нетрях библиотек а вот выкинуть никак. MyClass() создается на стеке. А должен быть и способ создания на куче

0

Сообщение от Curry на куче (с гипотетическим изменением синтаксиса)

Как ему объяснить на какой именно куче?

Добавлено через 7 минут
Добавлено через 10 минут
т.е. такой финт вносит неоднозначность с обоих сторон. Для его разруливания, в любом случае, где-то придется явно указать что мы имеем в виду. Удобнее это делать для конкретного объекта для которого требуется уточнение, чем к примеру указывать все параметры шаблона. Это уже не касаясь темы placement new который прочно и метко прописался в библиотеках, и остальных его форм с дополнительным функционалом.

0

Сообщение от Fulcrum_013 а этого гаврика где селить?

Bar на стеке, Foo на куче. Если справа от знака =, то на куче.

Сообщение от Fulcrum_013 Как ему объяснить на какой именно куче?

Пример приведите где указываете кучу.

При передаче тут же создаваемого объекта в аргумент функции. В большинстве случаев известен тип аргумента. Если MyClass или MyClass&, то объект создаётся на стеке, а если MyClass*, то на куче, т.к. за MyFunc(*(new MyClass())) надо по рукам бить.
При неоднозначности, так же как с перегруженными функциями, тип указывать явно.

placement new совсем другая языковая конструкция, пусть живёт, как и перегрузка operator new.

0

Сообщение от Curry Если справа от знака =, то на куче.

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

Сообщение от Curry т.к. за MyFunc(*(new MyClass())) надо по рукам бить

Ну по рукам в таких случаях плюсы бъют сразу. поэтому делают MyFunc(MyClass{}); и сразу явно понятно что оно на стеке и соответсвующий шаблон на месте

Сообщение от Curry В большинстве случаев известен тип аргумента

Это в С с классами. в С++ он в большинстве случаев выводится.

Сообщение от Curry При неоднозначности, так же как с перегруженными функциями, тип указывать явно.

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

Сообщение от Curry placement new совсем другая языковая конструкция, пусть живёт, как и перегрузка operator new.

Ну у него ровно 22 формы в том числе перегружаемые с произвольным набором параметров
https://en.cppreference.com/w/... erator_new

0

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

Я в курсе, и что? От new можно избавиться и принять, что Bar bar = Foo{}; на куче, а Bar bar(Foo{}); на стеке.

Сообщение от Fulcrum_013 Это в С с классами. в С++ он в большинстве случаев выводится.

Пусть выводится. Если выводится только вариант MyClass* то на кучу, если MyClass, то на стек. Если понаделали перегрузок то указывать явно.

Сообщение от Fulcrum_013 Ну вот и получаается тут читаем тут не читаем

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

Сообщение от Fulcrum_013 Ну у него ровно 22 формы

И пусть. Я не предлагаю перегрузку оператора new убрать, а только при создании объекта на куче слово new выкинуть.
А эти перегруженные, пусть применяются.

0

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

Оно взялось из msdn (да, а не по слухам и передовым теориям-аналогиям). Он нужен только для неуправляемых ресурсов. Во всех остальных случаях это может реализовываться иначе.
Когда мне нужно сделать объект мусором, я потеряю на него все ссылки. Просто обнуллю переменные или отпишу объект от события и тп. Никаких диспосеров херососеров я вызывать не буду. Если же я знаю, что на объекте завязаны неуправляемые ресурсы, то я вызову Dispose. Тогда вопрос лишь в том, что считать неуправляемыми ресурсами. Я не вникал особо в спор про окна, но по-моему слишком много споров не о чем. Куда закинуть код. Какой коллбек лучше: Close, Dispose или подождать деструктора, памяти и так много.

Добавлено через 5 минут
Curry, вот кстати, больше всего что меня выносит в шарпе: почему static-модификатор класса не позволяет опускать static для всех членов. Можно, конечно, кинуть мне, что так однозначней, что память короткая, забудешь, а потом произойдет страшный взрыв.

0