R
Привет. Могу я задать вопрос о том, с какого источника лучше начать изучение Kotlin как первого языка программирования? Подойдёт ли книга: Learn Kotlin for Android Development. Peter Spath. 2019?
Size: a a a
2020 December 11
AN
Переформатирование KEEP: https://github.com/Kotlin/KEEP/commit/02a379f1677c56fb59cf05389049917216db1c00
AN
Ruslan
Привет. Могу я задать вопрос о том, с какого источника лучше начать изучение Kotlin как первого языка программирования? Подойдёт ли книга: Learn Kotlin for Android Development. Peter Spath. 2019?
Лучше начать с официальной документации. Если Kotlin - первый язык, я не рекомендую начинать с андроида.
R
Спасибо за ответ!
ВМ
Вопрос по K/N
Планируется ли добавление деструкторов или их аналогов?
В jvm вся память управляется vm, а для освобождения нативной памяти предлагается использовать finalizer
Тут же мы либо всё делаем внутри mrmScoped, либо управляем ручками, что несколько затрудняет написание общего кода при использовании библиотечных нативных структур
Планируется ли добавление деструкторов или их аналогов?
В jvm вся память управляется vm, а для освобождения нативной памяти предлагается использовать finalizer
Тут же мы либо всё делаем внутри mrmScoped, либо управляем ручками, что несколько затрудняет написание общего кода при использовании библиотечных нативных структур
AN
Вопрос по K/N
Планируется ли добавление деструкторов или их аналогов?
В jvm вся память управляется vm, а для освобождения нативной памяти предлагается использовать finalizer
Тут же мы либо всё делаем внутри mrmScoped, либо управляем ручками, что несколько затрудняет написание общего кода при использовании библиотечных нативных структур
Планируется ли добавление деструкторов или их аналогов?
В jvm вся память управляется vm, а для освобождения нативной памяти предлагается использовать finalizer
Тут же мы либо всё делаем внутри mrmScoped, либо управляем ручками, что несколько затрудняет написание общего кода при использовании библиотечных нативных структур
Все варианты котлин работают с managed memory, то есть с автоматической сборкой мусора. В K-N дополнительно к этому есть memScoped
ВМ
finalize в K/N не зовётся, при этом, еяпп, GC освобождает память непосредственно при потере ссылки, то есть без бед с "GC собрал это потом"
AN
Вопрос по K/N
Планируется ли добавление деструкторов или их аналогов?
В jvm вся память управляется vm, а для освобождения нативной памяти предлагается использовать finalizer
Тут же мы либо всё делаем внутри mrmScoped, либо управляем ручками, что несколько затрудняет написание общего кода при использовании библиотечных нативных структур
Планируется ли добавление деструкторов или их аналогов?
В jvm вся память управляется vm, а для освобождения нативной памяти предлагается использовать finalizer
Тут же мы либо всё делаем внутри mrmScoped, либо управляем ручками, что несколько затрудняет написание общего кода при использовании библиотечных нативных структур
finalizer deprecated
AN
finalize в K/N не зовётся, при этом, еяпп, GC освобождает память непосредственно при потере ссылки, то есть без бед с "GC собрал это потом"
Это сейчас будет изменено. Будет полноценный GC вместо ARC
ВМ
То есть если у меня есть некоторая структура данных, которая есть нативно и в js, и на jvm, и на с, мне в последнем случае придётся писать свою реализацию?
AN
То есть если у меня есть некоторая структура данных, которая есть нативно и в js, и на jvm, и на с, мне в последнем случае придётся писать свою реализацию?
Не понял вопроса. Что именно вы хотите сделать?
AN
То есть если у меня есть некоторая структура данных, которая есть нативно и в js, и на jvm, и на с, мне в последнем случае придётся писать свою реализацию?
У вас везде GC будет одинаково работать.
ВМ
Есть некоторая структура данных, которой нет в наличии в мультиплатформенной библиотеке котлина
Однако имеется её реализация в стандартной библиотека java и рантайме js
Логично написать expected обёртку, чтобы все платформы могли её использовать
При этом и в jvm, и в js она будет корректно собрана GC, однако её сишная реализация окажется внутри некоторого kotlin-объекта
Сам объект будет так же собран, вопрос про то, где освобождать эту самую структуру, если она себе что-то навыделяла malloc'ами и ожидает, что мы её потом деинициализируем
Однако имеется её реализация в стандартной библиотека java и рантайме js
Логично написать expected обёртку, чтобы все платформы могли её использовать
При этом и в jvm, и в js она будет корректно собрана GC, однако её сишная реализация окажется внутри некоторого kotlin-объекта
Сам объект будет так же собран, вопрос про то, где освобождать эту самую структуру, если она себе что-то навыделяла malloc'ами и ожидает, что мы её потом деинициализируем
ВМ
В текущей реализации выглядит как "подождёт до выхода из memScoped", что не совсем логично — обёртка может оказаться в совершенно другом месте уже в общем коде, в то время как в нативном уже вызовется free
AN
Есть некоторая структура данных, которой нет в наличии в мультиплатформенной библиотеке котлина
Однако имеется её реализация в стандартной библиотека java и рантайме js
Логично написать expected обёртку, чтобы все платформы могли её использовать
При этом и в jvm, и в js она будет корректно собрана GC, однако её сишная реализация окажется внутри некоторого kotlin-объекта
Сам объект будет так же собран, вопрос про то, где освобождать эту самую структуру, если она себе что-то навыделяла malloc'ами и ожидает, что мы её потом деинициализируем
Однако имеется её реализация в стандартной библиотека java и рантайме js
Логично написать expected обёртку, чтобы все платформы могли её использовать
При этом и в jvm, и в js она будет корректно собрана GC, однако её сишная реализация окажется внутри некоторого kotlin-объекта
Сам объект будет так же собран, вопрос про то, где освобождать эту самую структуру, если она себе что-то навыделяла malloc'ами и ожидает, что мы её потом деинициализируем
Если это expect, то все вопросы с менеджментом памяти должны решаться на стороне С. Иначе получится стандартная проблема с тем, что не известно, кто владеет объектом, и кто его должен освобождать. Туда лучше не ходить, это кошмарное место
AN
Это ключевое отличие managed runtime от direct memory management. Собственно передавать неконтролируемые объекты - это крайне плохая практика везде. В том же Rust это unsafe
AN
Никто не мешает вам сделать https://kotlinlang.org/api/latest/jvm/stdlib/kotlinx.cinterop/free.html. Но тут сами себе будете виноваты, если что пойдет не так.
ВМ
Если это expect, то все вопросы с менеджментом памяти должны решаться на стороне С. Иначе получится стандартная проблема с тем, что не известно, кто владеет объектом, и кто его должен освобождать. Туда лучше не ходить, это кошмарное место
Вот собственно я и спрашиваю по какой-нибудь механизм, кроме рукописного NativePlacement с собственным GC, убирающим нативный мусор по протухающим WeakRef на обёртки
AN
Вот собственно я и спрашиваю по какой-нибудь механизм, кроме рукописного NativePlacement с собственным GC, убирающим нативный мусор по протухающим WeakRef на обёртки
Я такого не видел и надеюсь, что не будет. Человек, который хочет втаскивать опасные объекты в рантайм должен пять раз подумать о том, что он делает.
ВМ
Тогда получается, что этот managed runtime не может нормально пользоваться структурами из сишных библиотек