боксинг — только при get/set, но весь диапазон java.lang.Byte закеширован

Понял, логично, спасибо.

В итоге слайс на котлине для байт-массива есть?

Уффф, я уж подумал что глаза обманывают и где-то спрятано копирование))

как оказалось спрятано

Я всё ещё с переменным успехом пытаюсь понять эту конструкцию в asList(). @Harmonizr, просвети меня, как это работает? Для не сильно следящих: https://github.com/JetBrains/kotlin/blob/1.2.20/libraries/stdlib/src/generated/_Arrays.kt#L13011 /** * Returns a [List] that wraps the original array. */ public fun ByteArray.asList(): List<Byte> { return object : AbstractList<Byte>(), RandomAccess { override val size: Int get() = this@asList.size override fun isEmpty(): Boolean = this@asList.isEmpty() override fun contains(element: Byte): Boolean = this@asList.contains(element) override fun get(index: Int): Byte = this@asList[index] override fun indexOf(element: Byte): Int = this@asList.indexOf(element) override fun lastIndexOf(element: Byte): Int = this@asList.lastIndexOf(element) } } Мы возвращаем AbstractList<Byte> с примешенным к нему маркером RandomAccess, и делегируем все методы этому самому AbstractList<Byte>. Но у него ж abstract override fun get(index: Int): E. Откуда берётся реализация?

Я всё ещё с переменным успехом пытаюсь понять эту конструкцию в asList(). @Harmonizr, просвети меня, как это работает? Для не сильно следящих: https://github.com/JetBrains/kotlin/blob/1.2.20/libraries/stdlib/src/generated/_Arrays.kt#L13011 /** * Returns a [List] that wraps the original array. */ public fun ByteArray.asList(): List<Byte> { return object : AbstractList<Byte>(), RandomAccess { override val size: Int get() = this@asList.size override fun isEmpty(): Boolean = this@asList.isEmpty() override fun contains(element: Byte): Boolean = this@asList.contains(element) override fun get(index: Int): Byte = this@asList[index] override fun indexOf(element: Byte): Int = this@asList.indexOf(element) override fun lastIndexOf(element: Byte): Int = this@asList.lastIndexOf(element) } } Мы возвращаем AbstractList<Byte> с примешенным к нему маркером RandomAccess, и делегируем все методы этому самому AbstractList<Byte>. Но у него ж abstract override fun get(index: Int): E. Откуда берётся реализация?

override fun get(index: Int): Byte = this@asList[index]

this@asList -- это кто именно?

оригинальный обект

проблема в другом

как вы хотите все равно вызовется toList()

Блин, глуубже не посмотрел.. почему-то надеялся на жабовский саблист(((

this@asList -- это кто именно?

Это ресивер, ByteArray.

Дошло наконец. Классно.

Блин, глуубже не посмотрел.. почему-то надеялся на жабовский саблист(((

можно обойти но писать нужно свой итератор

И да, slice -- не классно. Ну да что поделать, ByteBuffer так ByteBuffer :)

можно обойти но писать нужно свой итератор

А sublist? Не могу найти реализацию

напиши примитивный итератор

А sublist? Не могу найти реализацию

джавовский

Тогда никакого слайса не вызовется и норм

Да, в доке написано The returned list is backed by this list, так что огонь.

@JvmName на методах интерфейсов запрещено? Нигде не задокументировано, но 'not applicable to this declaration'.

Похоже, не только на них. https://stackoverflow.com/q/47848967 https://stackoverflow.com/a/47526540

На второй натыкался, но там «я думаю, что». Надо в компилятор посмотреть :)

Тащемта вся соль ByteBuffer-а в том, что он занимает константное пространство на протяжении жизни всего приложения, в отличии от пачки ByteArray

так что ByteArray или List<Byte> тут особой роли не играет

так что ByteArray или List<Byte> тут особой роли не играет

первый примитивные типы, второй не всегда

я это к тому, что лучше держать один ByteBuffer чем ByteArray пересоздавать

разные задачи, разный подход, код выше будет работать на всех плаформах котлина (вот только по разному, но это не точно)

lateinit — зло и костыли, как и синглтоны с параметрами/зависимостями/состоянием

ну часто либо лейтинит, либо налы, выбирай что больше не нравится

кстати, а насколько чревато использование isInitialized? это уже рефлексия или нет? надо бы наверное конвертнуть код в джаву и глянуть что там

кстати, а насколько чревато использование isInitialized? это уже рефлексия или нет? надо бы наверное конвертнуть код в джаву и глянуть что там

нет, это сравнение с null в чистом виде

а ну тогда вполне ок

разные задачи, разный подход, код выше будет работать на всех плаформах котлина (вот только по разному, но это не точно)

Имхо, лучше всё что связано с байтиками делать максимально близко к платформе

Имхо, лучше всё что связано с байтиками делать максимально близко к платформе

соглашусь, ибо смысл их применения теряется

кстати, а насколько чревато использование isInitialized? это уже рефлексия или нет? надо бы наверное конвертнуть код в джаву и глянуть что там

Лучше в таких случаях не в джаву конвертировать, а на байткод смотреть

Лучше в таких случаях не в джаву конвертировать, а на байткод смотреть

может, но подобные вещи все равно плюс минус верно отображаются даже в джаве

kotlinx.coroutines version 0.22.2 is released with a fresh load of bug fixes for everybody and a couple of new extension methods for your reactive integration needs: https://github.com/Kotlin/kotlinx.coroutines/releases/tag/0.22.2

Добрый вечер, может кто скинуть документацию, книги на русском в pdf?

Добрый вечер, может кто скинуть документацию, книги на русском в pdf?

Документация — на kotl.in, книги доступны на Ozon, например.

Спасибо, документации достаточно

Можно ли как-то в anko-sqlite отключить ленивое создание таблиц/миграцию?

Выглядит перспективненько https://android-developers.googleblog.com/2018/02/introducing-android-ktx-even-sweeter.html

Ktx вроде в день анонса скидывали, или это новое?

Kira возможно, наткнулся на данный пост - вдохновился решил поделиться)

> A serializable class can declare its own serialVersionUID explicitly by declaring a field named "serialVersionUID" that must be static, final, and of type long: Интересно, а должно ли значение поля быть compile-time-константой? Пишут, что можно объявить в компаньоне, но как-то неуверенно: https://stackoverflow.com/a/34242012/3050249

Привет. Подскажите, почему Short::unaryMinus() возвращает Int ? https://github.com/JetBrains/kotlin/blob/1.2.20/core/builtins/native/kotlin/Primitives.kt#L353

если у тебя был Short.MIN_VALUE, то результат унарного минуса больше не влезает в шорт

Привет. Подскажите, почему Short::unaryMinus() возвращает Int ? https://github.com/JetBrains/kotlin/blob/1.2.20/core/builtins/native/kotlin/Primitives.kt#L353

В JVM все действия производятся либо над 32, либо над 64 битами. В Java битовые операции, например, возвращают int, даже если они производились над байтами или шортами.

В JVM все действия производятся либо над 32, либо над 64 битами. В Java битовые операции, например, возвращают int, даже если они производились над байтами или шортами.

?? тупанул, спасибо)

Не только в JVM. В C++ тоже любая арфметика имеет результатом как минимум int

Не только в JVM. В C++ тоже любая арфметика имеет результатом как минимум int

это ведь зависит от архитектуры процессора?

возможно ли что раньше были процессоры с 16битной арифметикой?

это ведь зависит от архитектуры процессора?

От архитектуры процессора зависит размер int.

Процессор считает на регистрах. Вернуть он может минимум то, что лежит на регистре.

возможно ли что раньше были процессоры с 16битной арифметикой?

У процессора, как правило, один размер регистра. В 21 веке это 32 или 64.

Но вообще были и 4х битовые процессоры. Но Java на них не было (

И слава богу

У процессора, как правило, один размер регистра. В 21 веке это 32 или 64.

А как же AL/AH/AX и тд, они же вроде остались

А как же AL/AH/AX и тд, они же вроде остались

Они суть часть RAX, не?

Да, но раньше точно могли юзаться отдельно

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

Да, но раньше точно могли юзаться отдельно

Это не совсем то же самое, что иметь физически отдельный регистр другого размера всё-таки

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

Ну среди прочего да

Точнее говоря, не зависит от платформы уже "пользовательский" язык программирования, который на этой JVM работает

А сама JVM естественно особенности среды должна учитывать

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

Int будет представлять значение одного и того же размера, а его footprint в памяти, кажется, уже не обязан быть строго одинаковым

А как же AL/AH/AX и тд, они же вроде остались

Как легаси, для обратной совместимости? Могу и ошибаться, не знаю.

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

Int в JVM всегда 32 бита.

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

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

И JVM в этом плане мыслит 32-битными словами.

JVM предоставляет возможность писать работающий код для всех случаев.

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

Но вообще это какие-то embeded, наверное, истории.

Понял, спасибо, а то я паниковать уже начал)

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

Какая именно специфика? Многопоточка и Unsafe?

Понял, спасибо, а то я паниковать уже начал)

Это какие-то низкоуровневые частности. Типа того, что на 16 битной системе чтение 32 битного инта не атомарно.

ну JVM гарантирует атомарность чтения/записи volatile-значений

Да.

Короче я про это.

Это какие-то низкоуровневые частности. Типа того, что на 16 битной системе чтение 32 битного инта не атомарно.

Разве такие вещи не закрываются интрисинками на конкретных платформах? В плюсах вроде эти всякие std::atomic<T> вполне себе атомарны, если я правильно помню, даже для значений больше 64 битов. Хотя могу и ошибаться.

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

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

Дайджест Котлин Событий: 8 февраля, Санкт-Петербург: @kug_spb KUG St. Petersburg Meetup #2 https://www.meetup.com/St-Petersburg-Kotlin-User-Group/events/247281601/ 15 февраля, Санкт-Петербург: PS JAVA MEETUP #9 https://billing.timepad.ru/event/662151/ 21 февраля, Минск: BKUG #8 https://bkug.by/2018/02/08/anons-bkug-8/ 24 марта, Киев: K•Night https://www.meetup.com/KyivKUG/events/246800518/ Присылайте мне анонсы, и я буду добавлять ваши митапы в дайджест.

ну JVM гарантирует атомарность чтения/записи volatile-значений

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

Как легаси, для обратной совместимости? Могу и ошибаться, не знаю.

да остались имено для совместимоти, все х86 имеет братную совместимость

хотя раньше так было, сейчас не вкурсе

запись планировалась, должна быть

пасибо

Кстати, там трансляция идет (правда в шакальном качестве ?) https://youtu.be/Z9g93sn6Ai0