Kotlin 4

**デフォルトの名無しさん** · 2018/07/17(火) 18:00:27.88

JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう
https://kotlinlang.org

※前スレ
http://mevius.5ch.net/test/read.cgi/tech/1521401186/

**デフォルトの名無しさん** · 2018/10/18(木) 13:01:35.45

>>783
あるかなあ？元から国際化考えて作られたものだからnativeになったからといって新たにそれのバグが追加されるとは思えんが。

**デフォルトの名無しさん** · 2018/10/18(木) 13:10:28.86

GUI側でなんかありそうな気はうっすらする

**デフォルトの名無しさん** · 2018/10/18(木) 13:53:48.29

>>790
私がKotlin native習得に挫折するなら話は分かりますが、Kotlin nativeそのものが頓挫することは
ないんじゃないでしょうか？

**デフォルトの名無しさん** · 2018/10/18(木) 14:01:13.13

>>793
普通にあるよ
何を勘違いしてるのか知らないが、たかが小さな会社の俺プラットフォームでプロダクションには現状誰も使ってないんだぞ？
そんなもん毎日のように腐るほど生み出されては消えていっている
逆に成功したら超ラッキー、くらいのレベルだ
Kotlinユーザーってほぼ例外なく他の言語も使えるから、Javaがゴタゴタしてるからって無理にKotlinに固執する理由もない
言っちゃ悪いけど、他に選択肢を持っている人がオモチャとして観察するフェーズであり、キャリアを賭けるようなもんじゃない

**デフォルトの名無しさん** · 2018/10/18(木) 14:29:52.26

これから新規でクロスプラットフォームでアプリ作るとしたらflutterとkotlin nativeどっちがいいんすか

**デフォルトの名無しさん** · 2018/10/18(木) 14:41:31.35

React nativeがいいよ

**デフォルトの名無しさん** · 2018/10/18(木) 14:52:18.29

>>794
なるほど、社内でのKotlin nativeプロジェクトにおける開発という意味で頓挫と仰っておられたのですね
了解しました
Kotlin自体の開発元のJetBrains社によるKotlin native開発の頓挫のことを指してるのかと思ってしまったので。。
確かに現場視点から見ると、著作権云々より色々考慮しなくてはいけないことがあるんでしょうね

私の元々の質問の意図は、Kotlin nativeで作成したネイティブバイナリのコードであれば、Oracleの著作権
侵害とは一切関わりのないコードが生成できるのかと確認することでした
実際の現場での開発運用までいくと、会社による顧客へのサポート対応とか諸々の課題を当然考慮しないと
いけないでしょうが、今回の質問はそこまで踏み込んでおらず、あくまでOracleの著作権の影響範囲とその
回避について、Kotlin nativeの開発は有用か尋ねたつもりでした

多分私を学生だと思われて、現場の泥臭いことを教えていただいたのですね
勘違いさせてすみません
50近いオッサンが、趣味と好奇心の延長で質問したことですので

**デフォルトの名無しさん** · 2018/10/18(木) 15:56:54.48

>>797
そうじゃなくてJetBrainsによるKotlin native開発が頓挫する話だ
JetBrainsはMSやOracle、Googleといった力押しで言語を普及させることのできるような企業と比較すれば遥かに「小さな会社」だよ
趣味なら好きにすればいいし、頓挫しても経験は決してゼロにはならないけど、
Javaロックインよりも遥かに大きなリスクを抱えることになるというのは理解しておきなさい

**デフォルトの名無しさん** · 2018/10/18(木) 16:23:08.89

>>794に禿げ上がるほど同意しすぎて禿げたわ

まだまだおもちゃとしか言えないレベルだよな。
とは言え一年前に比べたらだいぶ進化してるから、一年後にどうなってるかはわからない。

**デフォルトの名無しさん** · 2018/10/18(木) 17:02:31.96

>>798
なるほど、まだKotlin nativeは使い物になるレベルに達していない代物なのですね
色々ご教授いただき、ありがとうございました。

正直、従来のKotlinとKotlin nativeとの言語としての完成度の差を知らなかったので、
大変勉強になりました
今は、（Kotlin nativeではなく）ノーマル（従来）のKotlinを触って勉強したいと思います

**デフォルトの名無しさん** · 2018/10/18(木) 18:54:28.76

使い物になるかどうか俺にはまだわからない。

**デフォルトの名無しさん** · 2018/10/18(木) 20:57:17.61

flutterは使い物になってるん

**デフォルトの名無しさん** · 2018/10/18(木) 21:23:22.75

現状大差ない
どちらもプロダクトに投入してる例はあるけどまだまだこれから

**デフォルトの名無しさん** · 2018/10/18(木) 23:19:27.58

React Native + Kotlin/JS + Objective-C でアプリ書いてるけど
React Native + Kotlin/Common + Kotlin/Native (RCT_EXPORT_MODULEだけObjC) を考えてる

**デフォルトの名無しさん** · 2018/10/18(木) 23:56:45.28

React Nativeは糞なん

**デフォルトの名無しさん** · 2018/10/19(金) 00:01:12.66

>>804
Kotlin使ってるならObjCじゃなくSwift使えよ
構文とか似てるし

**デフォルトの名無しさん** · 2018/10/19(金) 05:50:07.67

>>804
なんでそんな目に見える苦行の道を選んだのかw

**デフォルトの名無しさん** · 2018/10/19(金) 06:53:56.43

>>806
以前別アプリで使ってたけど型推論あるとビルドクッソ遅いの直ったの？

**デフォルトの名無しさん** · 2018/10/19(金) 10:32:23.06

ちょっとでも欠点を見つけるとそれを理由にして新しいものを拒否するやつってどこの世界にも必ずいるよな

**デフォルトの名無しさん** · 2018/10/19(金) 11:39:41.80

それ以上に、古いものの欠点を過剰に騒ぎ立てて新しいものをゴリ押ししようとする奴のほうが多い気がする

**デフォルトの名無しさん** · 2018/10/19(金) 11:45:04.89

あと個人的な経験でいうと、新しいものの欠点はむしろ検討段階で見落とされて後で問題になることが非常に多い
新規導入におけるビジネス判断って、フィーチャーだけに目が行って非機能仕様や細かい制約はあまり考慮されないもんだ

**デフォルトの名無しさん** · 2018/10/19(金) 11:47:27.55

顔真っ赤だぞ

**デフォルトの名無しさん** · 2018/10/19(金) 12:05:14.92

今ある問題に目を瞑って現状維持に固執するやつは多い
新しいものを見ると特に検証もせず推し進めるやつもいる

**デフォルトの名無しさん** · 2018/10/19(金) 12:17:58.33

新しいものを受け入れられなくなった時が老化の始まりだと思っている

**デフォルトの名無しさん** · 2018/10/19(金) 13:18:39.60

人は歩みを止めた時に、そして挑戦を諦めた時に年老いてゆくのだと思います。

このソフトを使えばどうなるものか。危ぶむなかれ、危ぶめば道はなし。
踏み出せばその一足が道となり、その一足が道となる。

迷わず使えよ、使えばわかるさありがとう！

**デフォルトの名無しさん** · 2018/10/19(金) 13:35:53.85

都合よく自分の使いたいものを想定して一般論を語るのはいけない
こんな糞パッケージや糞製品導入した奴は子ねって思ったこと、ITエンジニアならあるだろ?

**デフォルトの名無しさん** · 2018/10/19(金) 18:28:06.35

自社が製品として販売しているオリジナルフレームワークを自社サービスで使っているせいで仕事を辞めたことはある。
本当に、本当にゴミフレームワークだった。

◆QZaw55cn4c · 2018/10/19(金) 19:44:06.11

>>814
その新しいものとやらが実際には価値のないものだったら動かない方が勝りますね

**デフォルトの名無しさん** · 2018/10/19(金) 19:53:50.60

重要なのは新しいか古いかではなく、自分の望みを叶える事に使える道具かどうかだ。

**デフォルトの名無しさん** · 2018/10/20(土) 07:22:23.67

>>819
叶えるのに最適かどうか、と言わないとC言語でなんでもできるおじさんがやって来るぞ。

**デフォルトの名無しさん** · 2018/10/20(土) 12:16:34.27

C++よりCだな

**デフォルトの名無しさん** · 2018/10/20(土) 13:28:58.42

>>820
そういやそうだな。
C、そしてアセンブラ最強になってしまう。

**デフォルトの名無しさん** · 2018/10/28(日) 15:23:51.96

Kotlin の Char には isAlphabetic() がないのな。
しょうがないからプログラムの上の方にこんなの作って使っている。

fun Char.isAlphabetic() = Character.isAlphabetic(toInt())

こういうのってこうやって簡単に作れちゃうから最初から標準のライブラリに入れてないんだろうか?
しかし最初からあってくれた方が楽と言えば楽だなあ。

**デフォルトの名無しさん** · 2018/10/28(日) 15:42:20.00

直接JavaのAPIを呼ぶべきだからだよ
そんな基準でKotlin版作ってたらキリがない
そもそもCharacterのメソッドってプログラマの使いやすさよりもUnicodeの仕様を正しく反映することを意図して作られていて、
そんなに頻繁に使うようなものではないだろ
知ってると思うけどisAlphabeticって平仮名とか含むんだぞ？

**デフォルトの名無しさん** · 2018/10/28(日) 16:24:20.91

おっUnicodeのクソさならおじさん語っちゃうぞ

**デフォルトの名無しさん** · 2018/10/28(日) 16:49:19.52

クロスプラットフォーム狙うなら用意しなきゃ駄目だな

**デフォルトの名無しさん** · 2018/10/28(日) 17:53:59.71

>>825
じゃJstarの開発マニュアルから初めてくれ

全て聞き流してあげよう

**デフォルトの名無しさん** · 2018/10/28(日) 19:45:18.26

>>824
Charでやっといてくれればnativeでコンパイルする時にもそのままにできるという利点がある。

**デフォルトの名無しさん** · 2018/10/28(日) 20:35:21.54

なんでByte型に符号が必要なんだろ。
扱いづらすぎ
c#のbyte型にしてたもんせ

**デフォルトの名無しさん** · 2018/10/29(月) 10:36:46.12

そして符号付きbitシフトとかどこで使うのか、今でも意味不明
Javaの負の遺産を引きずってるなー

**デフォルトの名無しさん** · 2018/10/29(月) 10:45:27.47

Kotlinがそれなりに流行ったのはJavaの呪いを受け入れたからに他ならない
その代償がその程度であれば小さいもんだろう

**デフォルトの名無しさん** · 2018/10/29(月) 11:08:01.70

そういや符号付きシフトライト使わんな

**デフォルトの名無しさん** · 2018/10/29(月) 11:25:07.20

javaつうか元々cの右シフトの挙動が定義されてなかったから、それを引きずってるだけ

**デフォルトの名無しさん** · 2018/10/29(月) 13:20:28.49

まあそこらへんは存在したとしてもどうせ使うことはないだろうから別にいいよ

◆QZaw55cn4c · 2018/10/29(月) 20:41:03.84

>>830
シフトに関しては符号付き、符号無しの区別は重要だと思いますよ

**デフォルトの名無しさん** · 2018/10/29(月) 20:46:14.26

算術シフトなんて今時使わんのう

**デフォルトの名無しさん** · 2018/10/29(月) 20:54:00.50

ビットシフトはビットシフトで考えたほうが早いオールドタイプを宥めるために存在する
彼らの言う「ビットシフトでやったほうが速い処理」が必要な、いつか来る未来というのは結局来ずに終わる可能性のほうが高い
残りの折り返し見えた人生、来るほうにかけて生きてもいいけどさ

◆QZaw55cn4c · 2018/10/29(月) 21:01:19.06

>>837
冪剰余のバイナリ法をみても、ビットシフトは重要だと思いますよ…

**デフォルトの名無しさん** · 2018/10/29(月) 21:12:23.49

符号無しシフトは非常に稀には使うけど符号付きシフトは使った記憶がない
とはいえKotlinでは記号じゃないから負の遺産とは思わないな

C++みたいに右シフトがtemplate構文の邪魔するとかなったら呪縛もいいとこだけど

**デフォルトの名無しさん** · 2018/10/29(月) 21:19:40.25

ビットシフトを使うほどカリッカリにパフォーマンスに拘る時にkotlin、というかjvm言語を使うかって話よね。
必要な場面があるのは分かるけど、今時のサーバーで普通のシステムを動かす前提なら普通はまず求められないし、可読性を犠牲にしてまで使うべきだとは思わない。

**デフォルトの名無しさん** · 2018/10/29(月) 22:03:26.21

主に移植性や相互運用性のために残ってるだけで批判の対象になるようなケースはほとんど実在しないと思うけどな

◆QZaw55cn4c · 2018/10/29(月) 22:40:20.39

>>839
＞右シフトがtemplate構文の邪魔するとか
C++11 lator でこの制限はなくなりました

**デフォルトの名無しさん** · 2018/10/29(月) 23:00:18.21

使うシチュエーションは確かにあるけどものすごく稀だな
あれば2年に1回くらいは使うかもしれないけどなかったらなかったで別に困らない

**デフォルトの名無しさん** · 2018/10/30(火) 13:02:10.09

ビットシフトな。実務で使うことはまあないな。
何かの解析とか組み込み系なら多用するだろうけど、そんなところではそもそもこちょりん使わないだろう。

**デフォルトの名無しさん** · 2018/10/30(火) 13:25:58.04

ビットシフトは画像処理やBluetoothで使いまくるぞ

**デフォルトの名無しさん** · 2018/10/30(火) 13:57:51.39

だからそういうのを自前で実装するケースってそうそうないやろ、って話でしょ

**デフォルトの名無しさん** · 2018/10/30(火) 14:20:24.64

元々ビット単位で詰め込んであるようなデータの解析には使った方が見易くなるかも知れない。ネットワークのパケットとか、その他色々あるよね。

もちろん割り算や余り計算すれば特定のビット抜き出す事はできるし、恐らく最適化されると最終的なコードは同じになるだろうけどね。

なのでどう書くと見易くなるかの問題だな。16で割って8の余り出すように書くか 4 ビット右シフトして 7 を and するように書くか。
だいたいは後者の方が見易く分かりやすいかも知れないが、場合によっては前者の方が良いかも知れない。

**デフォルトの名無しさん** · 2018/10/30(火) 14:46:02.26

ビット操作するなら素直にビット操作演算子つかえばいいんじゃね
ことりんはわり算した時のビット内容に規定があるのかわからんし

**デフォルトの名無しさん** · 2018/10/30(火) 17:13:35.01

なんだ、低レベルな処理をkotlinで書きたい人って結構いるもんなのか。
そういうのはCか最近ならGoあたりを使うと思ってた。

**デフォルトの名無しさん** · 2018/10/30(火) 17:37:55.08

最初は普通にkotlinで書いて、ボトルネックになるようならネイティブに逃がすでしょ。画像処理とか明らかにヘビーなことやるなら最初からネイティブで書くけど。

ところでkotlinネイティブで、本体の部分はJVMとかでkotlinで書いて、ヘビーな部分はkotlinネイティブで書いて利用するとか芸当簡単にできるようになるのか?

**デフォルトの名無しさん** · 2018/10/30(火) 17:40:45.12

例えばandroid画像処理アプリ本体はdalvikのkotlinで動かして、画像処理本体はkotlinで書くけどネイティブでとか。

**デフォルトの名無しさん** · 2018/10/30(火) 18:47:41.21

論理的にはできるはずだから、パフォーマンス比較してみたいなそれは

**デフォルトの名無しさん** · 2018/10/31(水) 00:32:35.54

透過的にできるようになるといいな。例えばメソッドに native 付けておけばそのメソッドは自動でネイティブにコンパイルされるとか。

**デフォルトの名無しさん** · 2018/10/31(水) 00:37:12.39

Androidならともかく、PCの方の非海賊版JVMのパフォーマンスをnativeが超えるのは相当難しそう

**デフォルトの名無しさん** · 2018/10/31(水) 06:48:37.29

そこはnativeってかLLVMの範疇の話だべ

**デフォルトの名無しさん** · 2018/10/31(水) 10:40:22.28

Kotlin1.3の新機能
https://aakira.app/blog/2018/10/whatsnew-kotlin13/

いろいろ面白い

**デフォルトの名無しさん** · 2018/10/31(水) 11:08:01.55

>>855
LLVMのコードってほとんどただの抽象化された機械語だから、
Kotlinを動かすならこれまでJVMに依存してたランタイムの機能を独自に相当作り込まなきゃいけないよ

**デフォルトの名無しさん** · 2018/10/31(水) 13:31:42.08

1.3はcontractが地味に嬉しい

**デフォルトの名無しさん** · 2018/11/01(木) 21:27:46.03

10月初めのと基本同じ情報だけど日本語で来てるから貼っとく

Kotlin 1.3リリース ? コルーチン、Kotlin/Nativeベータ
https://blog.jetbrains.com/jp/2018/10/30/1511

**デフォルトの名無しさん** · 2018/11/01(木) 23:50:12.25

これだけの大幅機能追加なら、そろそろJavaみたいにKotlin3とかに名前変更してもいいと思うけどな

**デフォルトの名無しさん** · 2018/11/02(金) 06:54:17.88

Goとかrustみたいに、システムプログラミング向けとしてもkotlin /native は使われる将来性はある?

**デフォルトの名無しさん** · 2018/11/02(金) 07:04:17.48

>>861
プリミティブのintと参照のIntを明示的に区別する仕様ではないから向いていないのではと思う。

**デフォルトの名無しさん** · 2018/11/02(金) 07:05:33.59

>>861
低いレイヤーを直接触るようなことはやりにくいから、あえて使う理由もないと思う
出来ないことはないだろうけど

**デフォルトの名無しさん** · 2018/11/02(金) 07:23:29.85

参照型にnullを許さないってのも、微妙だな
書いてて疲れる。

hoge?.fuga
とか
hoge!!
とか返って可読性が落ちてる希ガス

**デフォルトの名無しさん** · 2018/11/02(金) 07:41:58.45

>>864
そうだよ
面倒だから使いたくないでしょ
使わないようにしたいんだよ
だからそうなっている

**デフォルトの名無しさん** · 2018/11/04(日) 10:09:12.87

情報少ないけどKotlin/NativeはGCでなくARCってことでいいのかな

参考
https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-preview-kotlin-without-a-vm/
https://github.com/JetBrains/kotlin-native/issues/587
https://github.com/JetBrains/kotlin-native/issues/1698

>>861
GoはGCによる停止時間を極小化するために学術レベルのことやってる
　(全体の処理効率が多少下がってもリアルタイム性優先)
RustはGCでない
Kotlin/NativeがARCならシステムプログラミング用途でも支障無いと思う

**デフォルトの名無しさん** · 2018/11/04(日) 12:16:15.86

arcだとすると既存プログラムはコードを書き換えないといけない場合があると思うけど、それを承知で採用してるの？

**デフォルトの名無しさん** · 2018/11/04(日) 12:25:22.13

やってみたかっただけでしょ
所詮オモチャなんだから

**デフォルトの名無しさん** · 2018/11/04(日) 12:38:32.84

ARC with cyclic collector というのをちらほら見る
弱参照を使わなくても既存コードのままで問題無いようだ

ただこれがGCのような停止時間を発生させるかなどはよく分からなかった

**デフォルトの名無しさん** · 2018/11/04(日) 13:09:57.98

おもちゃなのか

**デフォルトの名無しさん** · 2018/11/04(日) 13:11:27.17

諸々の問題の解決を試みているうちに、気がついたら出来上がったものはGCそのものだったというオチになりそう
既存の枯れた技術を舐めてかかって自分で実装してみてはじめてそれが十分に優れていたことに気付く
技術の過度な抽象化による間違った万能感に陥りがちなITエンジニアにはよくあること

**デフォルトの名無しさん** · 2018/11/04(日) 13:21:16.17

オリジナル言語を頑張って作ったが結局動作的にLispになったみたいな話だな

**デフォルトの名無しさん** · 2018/11/04(日) 14:17:20.37

そのまんまでしょ。弱参照ないARCで管理するが、循環参照用に定期的にGCは走らせる。

**デフォルトの名無しさん** · 2018/11/04(日) 14:21:36.32

だから循環参照するクラス大量だとフルGC走らせるのと同じことになるが、大抵のプログラムでは循環参照するクラスはそんな大量じゃないので大抵のケースではARC with cyclic collectorの方が速くなるとか

**デフォルトの名無しさん** · 2018/11/04(日) 14:23:51.54

ところでkotlinにweak reference見たいのあったっけ?

**デフォルトの名無しさん** · 2018/11/04(日) 14:54:43.50

>>870
大人の

**デフォルトの名無しさん** · 2018/11/04(日) 14:58:25.67

>>875
nativeでは kotlin.native.ref.WeakReference
jvmでは java.lang.ref.WeakReference が有る
jsには無いからcommonにも無い

**デフォルトの名無しさん** · 2018/11/04(日) 19:14:10.57

javaや.netにあるのは知ってるから質問けど
そっか、所詮、最大公約数になるから他の言語に引きずられまくりでjsとかにねぇからkotlinで標準で用意されてねぇのか。

**デフォルトの名無しさん** · 2018/11/04(日) 20:08:53.22

いやKotlinに無い理由はJavaにあるからだよ
建前はともかく、実態はAltJavaとしてしか使われてないしJBもそれを前提に開発してるのが実情

**デフォルトの名無しさん** · 2018/11/04(日) 22:06:08.12

現状だとメモリ管理は対応プラットフォームの機能に寄生するみたいな感じになってるのは気になるね
iOS向けだとiOSのARCを利用するし、Cなら手動で開放してる
Kotlin/Native として統一的なメモリ管理機構を作らないと、プラットフォームを超えたコードの共有化とかはかなり限定的なものになりそう

しかし統一的なメモリ管理機構を言語で用意すると、プラットフォーム側で用意してるメモリ管理機構と重複部分ができて無駄だなとも思う
Xamarinとかはそんな感じだし

**デフォルトの名無しさん** · 2018/11/04(日) 22:31:08.12

ARCはOS関係無くね、Swiftと同じく普通にコンパイラとランタイムによる実装でしょ
現時点でcommon書くときメモリに関して支障は感じないけど
メモリ管理機構ってJVM上やJS上でどういうのを想定してる？

**デフォルトの名無しさん** · 2018/11/04(日) 23:19:36.30

JS はランタイム側でGCやってくれるし、JVMもGCやってくれるので、
アプリケーション側の kotlin コードでメモリ開放する必要ないし、循環参照とかも意識する必要ないでしょう

Kotlin iOS では、Swift や Obj-C と同じランタイム側にあるARCを使っているのではないのかな？
この場合アプリケーション側の kotlin コードでは、循環参照とかを意識しなくてはいけないのでは？

Cライブラリを使ってLinux上で直接動くような Kotlin Native コードの場合には、
malloc や free に相当するもので手動でメモリ確保開放とかやる必要があったりしますよね？
https://kotlinlang.org/docs/reference/native/c_interop.html

**デフォルトの名無しさん** · 2018/11/05(月) 00:00:51.88

んなわけあるかい
LLVMで普通に直接動く実行コードを生成してるだけで、iOSのオブジェクトモデルとは別物だ
iOSに循環参照を自動的に見つけて解放してくれるって事実上の独自GCやぞ
そんなもん勝手に組み込めるんならみんなとっくにやっとる

**デフォルトの名無しさん** · 2018/11/05(月) 00:53:31.72

var x = Foo()
Bar(x)
x = Boo()

以上のような Kotlin コードをコンパイルしたときに、Boo()の結果を x に代入するまえに x に入っていた Foo() への参照をどう処理するかってこと
Bar(x)の結果、だれかが x に入っていた Foo オブジェクトへの参照を保持している可能性がある

JVMやJSだと単に x を上書きするコードにコンパイルすればいいよね
iOS向けにコンパイルするときには release(x) みたいなのを含んだ LLVM コードに変換される？
もしくは、Kotlin が独自の ARC みたいなの持っていて、それに応じた処置がおこなわれるの？

Linux 向けの Kotlin / Native でコンパイルはこのままできるのかな？

**デフォルトの名無しさん** · 2018/11/05(月) 01:36:44.15

>>882 >>884
ObjCランタイムは普通にCのABIのライブラリ群だから
純粋なC言語から呼べるしKotlin/Nativeからも呼べる

iOSでもLinuxでもプラットフォームのAPIを使うには
それに沿ったメモリ構造や解放関数の呼び出しなどのリソース管理が必要だけど
外部呼び出しを除いたKotlin/Nativeの部分にmalloc/free/releaseなどは必要無いよ

**デフォルトの名無しさん** · 2018/11/05(月) 02:10:02.43

>>885
そうすると、 Kotlin / Native で普通に確保したオブジェクトの解放はどういう方式で行われているのかな？
リファレンスカウンタ？ GCでは無いよね？
リファレンスカウンタだとすれば、Kotlin/JVMでは問題無いオブジェクト同士が参照しあう構造は、避けないとダメだよね

**デフォルトの名無しさん** · 2018/11/05(月) 06:27:49.62

ここで不毛な言い争いするくらいなら実際にコード書いて試せばいいのでは。。

**デフォルトの名無しさん** · 2018/11/05(月) 07:27:17.05

>>886

>>873-874 と
https://github.com/JetBrains/kotlin-native/blob/master/FAQ.md

> Q: What is Kotlin/Native memory management model?
> A: Kotlin/Native provides an automated memory management scheme, similar to what Java or Swift provides. The current implementation includes an automated reference counter with a cycle collector to collect cyclical garbage.

**デフォルトの名無しさん** · 2018/11/05(月) 07:52:42.52

>>888
ありがとう。参考になった

**デフォルトの名無しさん** · 2018/11/06(火) 11:37:39.99

Kotlin 1.3 には Kotlin Native がバンドルされているみたいに書いてあるWebページがあるが、されてないよね？
bin ディレクトリ以下はいつも通りのスクリプトやバッチファイルがあるだけで kotlin-native はないんだけど。
何かオプションで変わるのか？