C# vs Kotlin

Привет всем!

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

0

Сообщение от Curry Насчёт передачи данных сообщениями

Передаются не сами данные. Передается сигнал о готовности данных.

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

Сообщение от Curry А ещё бывают языки с зелёными тредами

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

Сообщение от Curry Есть распараллеливание, есть конкуренция.

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

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

Сообщение от Curry Да я не конретизировавал в примере что за модули связываются.

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

0

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

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

0

Fulcrum_013, автовызов грохнет? Это после того как мы пнём удаление вызовом delete, прикручиваением смарт-поинтеров или явным размещением в стеке? Это не ручная работа, да?

0

Usaga, А нужность/ненужность объекта вам все равно вычислять по правилам предметной области при изменении его состояний. GC этих правил знать не может так что тут он не помощник а помешник. Если заметили то весь сыр бор всегда вокруг добавить "все остальное" в метод определяющий ненужность. Вот собственно автоматическим добавлением "всего остального" автоматика на деструкторах и занимается. Определить же тип взаимосвязи вы все равно обязаны на этапе анализе задачи. Потому что в ООП предусмотрено два типа взаимосвязей и любой набор автоматики будет иметь минимум два типа ссылок. Как я вам показывал в примере с коственной утечкой GC от этой обязанности никоим образом не освобождает. А насчет явно на стеке/статической композиции - ну если это размещение оснновное, мало того использования сырых указателей явного вызова new можно избежать везде кроме низкоуровневых библиотек (во всяком случае для наиболее ходового набора контейнеров и структур данных) - ну сами понимаете писать new на каждом шагу на каждый мелкий объект - это просто какой то анахронизм из лихих 90-х.

0

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

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

0

Сообщение от Usaga Выкинули ссылку на него и всё.

Для этого нужно знать где эту ссылку искать.

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

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

Зачем для этого нужен оверхед в рантайме если это определяется в компайлтайме?

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

Совсем не тоже самое. Касательно простых объектов - сели их все на стек. Они сами разберутся кому из них нужен буфер в куче.

Сообщение от Usaga с той лишь разницей, что не надо возиться со смартпоинтерами и выбирать

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

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

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

Совсем не то же самое. Необходимо подстраиваться под то что заложено GC, вместо того чтобы указать автомату что именно он должен должен делать для того или иного объекта/типа ссылки. Как вы к примеру будете решать при помощи GC задачу удаления объектов на которые ссылается менее 2 объектов заданного типа? А такая задача встречается очень часто.

0

Сообщение от Fulcrum_013 Для этого нужно знать где эту ссылку искать.

Если вы не знаете, где она, то вам объект УЖЕ не нужен.

Сообщение от Fulcrum_013 Зачем для этого нужен оверхед в рантайме если это определяется в компайлтайме?

Оверхед минимальный. Профит - в почти полном отсутствии необходимости что-то делать в коде. GC сам разберётся. Второе сильно перевешивает первое.

Сообщение от Fulcrum_013 Совсем не тоже самое. Касательно простых объектов - сели их все на стек. Они сами разберутся кому из них нужен буфер в куче.

Ну. Заводите структуры, а не объекты. Тоже поселятся на стеке.

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

Он не течёт. Код вы видели. Никакие слабые ссылки не нужны. А в тех редких случаях, где нужны, ну ок. Таких ситуаций минимум. Пример, который вы показывали (где всё решилось WeakReference) - искусственный и некорректный.

Сообщение от Fulcrum_013 Совсем не то же самое. Необходимо подстраиваться под то что заложено GC, вместо того чтобы указать автомату что именно он должен должен делать для того или иного объекта/типа ссылки. Как вы к примеру будете решать при помощи GC задачу удаления объектов на которые ссылается менее 2 объектов заданного типа? А такая задача встречается очень часто.

Нет никакой необходимости подстраиваться. Всё просто работает. Само. А в плюсах вам надо сидеть и выбирать, на стек вы объект положите или в кучу, в смартпоинтер завернёте или владельца создадите. Есть разница, а?

0

Сообщение от Usaga Если вы не знаете, где она, то вам объект УЖЕ не нужен.

Пример. По правилам предметной области то что объект не нужен вычислилось в методе объекта. Где искать ссылки?

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

Сообщение от Usaga GC сам разберётся.

Пруф в студию. Кучу примеров где GC нихрена не разбирается вам уже приведено. Анализ алгоритма который показывает что GC для задач ООП не предназначен тоже.
Еще раз. Или пример в студию с автоматическим решением вопроса с удалением взаимосвязи при удалении одного из связываемых ею объектов или прикройте хлеборезку по поводу того что GC сам разберется.

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

Сообщение от Usaga Таких ситуаций минимум.

В ООП неслабых ссылок вообще нет. Либо слабые (агрегация), либо слабо-владеющие (композиция). В ООП ссылка не препятствует удалению. Вместо этого есть ответственные за удаление (те в кого объект композирован) и характерна обратная задача - разрыв связей удаляемых. Эта задача решаема исключительно инстантным просмотром мусора.

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

Сообщение от Usaga Нет никакой необходимости подстраиваться. Всё просто работает. Само.

Ну покажите как он сам не течет или с зомбаками справляется или ресурсы сам отпускает вовремя. Для того чтобы это было само GC.Collect должен вызываться после каждого изменения какой либо ссылки. Очевидно что просмотр мусора при таких раскладах гораздо дешевле.

Сообщение от Usaga А в плюсах вам надо сидеть и выбирать, на стек вы объект положите или в кучу, в смартпоинтер завернёте или владельца создадите. Есть разница, а?

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

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

Сообщение от Usaga Тоже поселятся на стеке.

вы строку как селите?
string a;
а массив как селите?
List<T> b= new List<b>();
а в плюсах
точно так же селится
string a;
vector b;
так где надо а где не надо думать куда его селить?

0

Сообщение от Fulcrum_013 Пример. По правилам предметной области то что объект не нужен вычислилось в методе объекта. Где искать ссылки?

У владельца объекта. Если ссылки находятся на руках других частей системы, то объект нужен. Всё тоже самое справедливо и в С++.

Сообщение от Fulcrum_013 Пруф в студию. Кучу примеров где GC нихрена не разбирается вам уже приведено. Анализ алгоритма который показывает что GC для задач ООП не предназначен тоже. Еще раз. Или пример в студию с автоматическим решением вопроса с удалением взаимосвязи при удалении одного из связываемых ею объектов или прикройте хлеборезку по поводу того что GC сам разберется.

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

Сообщение от Fulcrum_013 Ну покажите как он сам не течет или с зомбаками справляется или ресурсы сам отпускает вовремя. Для того чтобы это было само GC.Collect должен вызываться после каждого изменения какой либо ссылки. Очевидно что просмотр мусора при таких раскладах гораздо дешевле.

Я вам уже показывал реальный пример. Слабо его запустить?

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

Это тупая ложь. Такого головняка нет. Я это вам уже показывал. А вы мне такой головняк показать не смогли.

Сообщение от Fulcrum_013 вы строку как селите? string a; а массив как селите? List<T> b= new List<b>(); а в плюсах точно так же селится string a; vector b; так где надо а где не надо думать куда его селить?

О чём этот кусок бреда? В шарпе не нужно об этом думать. Хотите на стёке объект локально держать? Сделайте его структурой, а не классом.

0

Сообщение от Usaga У владельца объекта.

Т.е. объект должен сообщить владельцу о том что он больше не нужен для чего должен иметь на него обратную ссылку. А остальные взаимосвязи о которых владельцу знать сто лет не надо где искать?

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

Сообщение от Usaga А вы мне такой головняк показать не смогли.

Утечки и зомбаки это не головняк?

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

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

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

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

Сообщение от Usaga Сделайте его структурой, а не классом.

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

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

Сообщение от Usaga Там всё корректно работает.

Вы это называете корректно? А необходимость в using или ручном вызове Hide или Dispose для обеспечения корректного поведения как раз и делает GC ненужным от слова совсем.

0

Сообщение от Fulcrum_013 Т.е. объект должен сообщить владельцу о том что он больше не нужен для чего должен иметь на него обратную ссылку. А остальные взаимосвязи о которых владельцу знать сто лет не надо где искать?

Объект не обязан такое делать. Это дело владельца определять, нужен объект или нет.

Сообщение от Fulcrum_013 Утечки и зомбаки это не головняк?

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

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

Давайте-ка вы не будете передёргивать, а? Ручное управление памятью вы в том примере заметили где? Вот то-то же.

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

Но сейчас же вы паритесь приподнося это как лютый плюс языка.

Сообщение от Fulcrum_013 Вы это называете корректно? А необходимость в using или ручном вызове Hide или Dispose для обеспечения корректного поведения как раз и делает GC ненужным от слова совсем.

Да, корректно. Using не является обязательным, я вам уже об этом сказал. Вы специально игнорируете слова? Ручной вызов Hide() так же не является проблемой, ибо явный императивный механизм закрытия. Не хотите? Заверните в using ограничив скоуп. Вы в плюсах ровно тоже самое делаете. Наличию сборщика мусора это никак не противоречит.

0

Сообщение от Usaga Using не является обязательным, я вам уже об этом сказал.

Да набалаболили вы много. А вот документация от разрабов GC По этому поводу абсолютно другого мнения.

Сообщение от Usaga Ручной вызов Hide() так же не является проблемой, ибо явный императивный механизм закрытия. Не хотите? Заверните в using ограничив скоуп. Вы в плюсах ровно тоже самое делаете. Наличию сборщика мусора это никак не противоречит.

Оно просто делает сборщик ненужным.

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

Сообщение от Usaga Давайте-ка вы не будете передёргивать, а? Ручное управление памятью вы в том примере заметили где? Вот то-то же.

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

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

Сообщение от Usaga Вы в плюсах ровно тоже самое делаете.

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

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

Сообщение от Usaga Давайте-ка вы не будете передёргивать, а? Ручное управление памятью вы в том примере заметили где? Вот то-то же.

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

0

Сообщение от Fulcrum_013 Да набалаболили вы много. А вот документация от разрабов GC По этому поводу абсолютно другого мнения.

Балабол тут только один персонаж. Который даже пример запустить не может, который я ему привёл. Или запустил, понял, что обосрался и теперь порит чушь.

Сообщение от Fulcrum_013 Оно просто делает сборщик ненужным.

Момент закрытия формы и её уборка сборщиком - разные вещи.

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

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

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

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

1

Usaga, И этого персонажа зовут Usaga.

0

Fulcrum_013, слишком много ошибок вы в своём нике допустили.

0

Сообщение от Usaga Балабол тут только один персонаж. Который даже пример запустить не может, который я ему привёл.

И этого персонажа зовут Usaga. Который даже не в состоянии привести пример работы GC а не других средств, делающих GC ненужным от слова совсем.

0

Где же ваша хвалёная профессиональность? Или самописцы STL'я ошибок своих никогда не признают?

0

Сообщение от Usaga А убирает труп формы, когда она становится не нужна.

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

0

Fulcrum_013, пример вам был дан. И не один. И все корректные. Вы же обратного примера не смогли привести. Всё, что вы тут выкладывали я исправлял парой строк кода и всё начинало работать как надо.

Вы не можете обосновать свою хейтерскую позицию, ибо у вас тупо нет на это компетенции. Только эмоции и ЧСВ.

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

Сообщение от Fulcrum_013 А не нужна она становится при выходе из скопа ссылки на нее. Где вынос трупа с экрана?

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

0

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

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

Сообщение от Usaga И не один. И все корректные.

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

0