次世代言語22 Go Nim Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2021/08/22(日) 08:59:03.31

スレタイ以外の言語もok

前スレ
次世代言語21 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1587276362/

**デフォルトの名無しさん** · 2021/11/09(火) 12:36:57.75

>>540
素直にcopyか参照にしとけば良かったのにね。
効率求めるならCOWにした方が良さそう。なんでCOWにしなかったのかな？COWは並列処理とあんまり相性良くないけど。

**デフォルトの名無しさん** · 2021/11/09(火) 12:47:14.84

スケープゴートを用意し比較的人口の多いGoを攻撃する、Rustは悪くないのに"危険がいっぱいなこいつ"の悪辣性

**デフォルトの名無しさん** · 2021/11/09(火) 12:56:13.87

go最強！！！！

**デフォルトの名無しさん** · 2021/11/09(火) 13:08:33.41

>>554
信者が無理矢理な理屈で暴れてるのはRust信者だろ
そんなことしてるからいつまで経っても普及しないオタク言語止まりなんだよ

**デフォルトの名無しさん** · 2021/11/09(火) 17:57:07.15

capacity は、単なるデフォルト値だろ

別に、それを超えても良いのだろ？

**デフォルトの名無しさん** · 2021/11/09(火) 18:50:44.35

RustはD言語の再来と言われるほど期待されてる。

**デフォルトの名無しさん** · 2021/11/09(火) 19:55:55.57

倒してしまっても構わんのだろ？

**デフォルトの名無しさん** · 2021/11/09(火) 20:01:35.84

うんこ野郎の独演会

**デフォルトの名無しさん** · 2021/11/09(火) 20:12:33.83

>>559
超えていいよ。超えたときには別のバッファが作成されて、元のバッファの要素がコピーされる、ってだけだから。

キャパシティを意識するとしたら、このようなバッファ作成回数を減らしたいっていうような、パフォーマンスを意識するときが多いんじゃないかな。
普通は明示的にキャパシティを設定せずとも、デフォルトの2のべき乗サイズのキャパシティがいい感じのパフォーマンスになるけどね。

**デフォルトの名無しさん** · 2021/11/09(火) 20:57:16.81

スライス<T>型がユーザー定義型だったら
それは言語の欠陥ではなくユーザーのミスでしかなかったのに

スライス<T>型をユーザーが再発明できない原因をよく考えるべき

**デフォルトの名無しさん** · 2021/11/09(火) 23:26:26.60

>RustはD言語の再来と言われるほど

言われたくないだろうな

**デフォルトの名無しさん** · 2021/11/09(火) 23:33:50.69

注目度がだいぶ劣るけど後継は多分nimだから・・・

**デフォルトの名無しさん** · 2021/11/10(水) 01:07:58.28

C++の再来はありますか？

**デフォルトの名無しさん** · 2021/11/11(木) 10:10:47.29

去ってないから

**デフォルトの名無しさん** · 2021/11/11(木) 14:23:06.64

C/C++は簡単にやばいコードを書けてそれを発見するコストが高いという問題がある
特にC++は使いこなすための練度のハードルが高いせいか凶悪と言ってもいいｗ

**デフォルトの名無しさん** · 2021/11/11(木) 14:56:27.50

C++がよくあそこまで流行ったもんだよね
こうなる前に他の言語を作る動きはなかったのかしら。まあそれが1995年のJavaだったのかなあ。昔すぎて自分にはよくわからんけど

**デフォルトの名無しさん** · 2021/11/11(木) 15:12:54.92

むしろそれまではCしかなかった
Windowsが出てきて、その開発の主要言語でVisual C++が出てきたのでC++が流行った
と思ってる
インターネットが急速に発展したのはWindows 95以降だったので、それまでの流行りは処理系の人気に依存してた
と思う
その頃のUnix系や汎用機の世界までは俺も知らんｗ
勝手にUnix系はCで汎用機はCOBOLだったんじゃないかと思ってるｗ

**デフォルトの名無しさん** · 2021/11/11(木) 15:29:17.41

要は、スマホのように説明書不要と称する物を特許とか著作権とかの規制で縛って課金する方法と
本体を無料であげる代わりに分厚い説明書を買わせる方法がある

**デフォルトの名無しさん** · 2021/11/11(木) 17:04:48.90

>>571
なるほど。たしかにWindowsとVisual Studioがキラーアプリケーションだったんだ
MicrosoftがObjective-Cを採用してたら、Objective-Cがめちゃ流行ったんだろうし、やはりプラットフォーマーは強いな
MicrosoftかAppleのいずれかがLispを採用してたら、Lispの存在感も桁違いだったんだろうなあ。そういう世界線を見てみたい

**デフォルトの名無しさん** · 2021/11/11(木) 17:23:23.65

ネットの怪文書を処理する難度がC++よりも凶悪なのでC++が良心的に思える

**デフォルトの名無しさん** · 2021/11/11(木) 18:27:16.30

C++は諦めが肝心の言語
機能を全部使うと死ぬ

**デフォルトの名無しさん** · 2021/11/11(木) 19:54:16.99

関数型の言語は当時Unix系の開発者(学術系多め)がemacs lispを中心に好んで使ってたよ(開発ツールとして)
ただWindowsとPCの普及にともなってunixやemacs自体が段々下火になっていった
処理系とはIDEのことなので、IDEの開発効率とその付属ライブラリが言語選択の決め手ということ
当時はC++以外だとpascal(delphiなど)を使う人やVBを使う人がいた
appleは丁度ジョブスいなかったので低迷中だったかな
当時強かったのはMS/IBM/Sunあたりかなぁ
※個人の感想/主観であることに注意

**デフォルトの名無しさん** · 2021/11/11(木) 23:33:58.00

どうしてprologのことを無視するかなあ
80年代後半から90年代初頭にかけては
unixではprologの天下
Cよりも早くコーディングできた

**デフォルトの名無しさん** · 2021/11/11(木) 23:45:48.82

それ天下とはいっても流行してた、って意味じゃないよね？
GNUのソフトウェアもほとんどC言語だろうし・・・。

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

prologはいいんだけどrust製prologのscryerとか見てるとISO準拠にこだわるのやめてくれと思う
文法とか組み込みオペレータ、組み込みプレディケートとかライブラリも新時代に合わせて工夫してほしい
昔ながらのコードをそのまま動かせる…
それは昔ながらのPrologで動かしてもろて…
じゃあprologじゃなくていいじゃんって？
そうだよ！基礎コンセプトそのままでガワを新しく整えたのがほしいんだよ！

**デフォルトの名無しさん** · 2021/11/12(金) 00:06:01.94

Prologが分かる奴はErlangもRustも分かるから早急に次世代に行けた

**デフォルトの名無しさん** · 2021/11/12(金) 02:10:18.26

prologなんて誰も使ってなかったよｗ

**デフォルトの名無しさん** · 2021/11/12(金) 14:30:35.33

>>579
それ、何てOz？
Oz触ったこと無いけど。

**デフォルトの名無しさん** · 2021/11/12(金) 14:41:26.85

swi-prologなら若干拡張されてるけど、prolog自体が昔からほぼ使われておらず
存在自体あまり知られてないし、結局手続き的思考が必要だし、用途が限定される使いにくい言語だと俺は思ってるｗ

**デフォルトの名無しさん** · 2021/11/12(金) 14:59:17.99

調べてみるとICOTとかいう、Prologをメインに使って、500億円も予算をかけたプロジェクトがあったらしいけど、なんだったんだろうな

**デフォルトの名無しさん** · 2021/11/12(金) 21:33:34.72

第五世代コンピューターと論理プログラミングを基にした現代の深層学習とは違う人工知能・・・ウッ頭が
つまりはアランケイのSmalltalkが最強ってことだろ？

**デフォルトの名無しさん** · 2021/11/13(土) 11:37:24.38

コストが高いか安いかでくるくる掌返すのはポジショントークだよな
しかもサンクコスト

**デフォルトの名無しさん** · 2021/11/13(土) 12:37:16.91

Prologは夢を見すぎたな
結局バグは仕様そのものとかいろんな理由で起きるというのに

**デフォルトの名無しさん** · 2021/11/13(土) 13:27:58.51

メモリ安全みたいなテーマに限定すれば夢が無限に大きくはならんだろ
夢を見たことではなくテーマを表す言葉を使わなかったことを反省しよう

**デフォルトの名無しさん** · 2021/11/13(土) 13:40:18.34

ループをすべて再帰で書くというのがちょっと難しいが
デバグが楽だし、保守もしやすい
ライブラリをどさっと作れば流行ったかもしれないな
のちのperl,javaのように

**デフォルトの名無しさん** · 2021/11/13(土) 15:45:12.67

>>589
末尾再帰ループ化できない再帰はスタックが溢れる
最近はループを更にわかりやすくイテレータ連鎖で書くのが主流だね

>>588
Rustの発想は目からウロコだった
他の言語たちが最初からガベージコレクション前提にしてた状況でGCなし言語があそこまで出来るとは驚き

>>587
論理宣言型言語は結局は現実のCPU命令手続きとのギャップを処理系でカバーするも効率面も厳しく

**デフォルトの名無しさん** · 2021/11/13(土) 16:19:14.47

また過大評価してGC無しなんて言うけど理論上は参照カウントはGCアルゴリズムだし、そんなのは原始的で
最も基本のGCに分類される。仮にこれから今のRc系のGCに参照カウントGCの非同期が搭載されたりすれば
その動作はスイープマーク系や世代別GCに近くなる。（その可能性は少ないが）現在なぜ良い結果が出るかと
いえば構造上、連鎖的な多量GCが少なくなるために、スループットが高くなる事だけ。
レテンシーで見ればJavaやC#のGoなどの処理は毎回GCするとは限らないので、その分だけ処理が速い

**デフォルトの名無しさん** · 2021/11/13(土) 16:22:04.94

君、頭悪いでしょ

**デフォルトの名無しさん** · 2021/11/13(土) 17:00:56.00

末尾呼び出し最適化が保証されてる言語でのみ
枕を高くして再帰で書きまくれるというもの
ocamlはいいぞ

**デフォルトの名無しさん** · 2021/11/13(土) 17:01:06.08

>>591
まずほとんどのデータは参照カウントで管理しないから極一部のケース対象にしか論じていないね
次に参照カウントゼロ時に即座に解放する場合はガベージが一度も発生しないためガベージコレクションとは通常言わないです
最後に列挙しているGC言語はC/C++/Rustよりもベンチマークでも遅いですね

**デフォルトの名無しさん** · 2021/11/13(土) 17:14:56.21

末尾再帰はプログラミングテクニックではなく、コンパイラ等におけるコード最適化の技術です。
（多くは手続き言語における自己呼び出しをTailに変形してスタック消費をゼロにしたりする）

「ループを再帰で書く」まったく意味ないどころか、言語問わず末尾再帰最適化が未実装のコンパイラ等では
弊害しかありません。「イテレータ連鎖？で書く」は普通のループ大きく変わりませんが、言語によりけりで
手続き言語では非同期処理やサイドエフェクトのある処理では上手く書けません。

そもそもPrologの一階述語論理における再帰処理というのは再帰定義自体が、関数型プログラミングの元と
なる論理型プログラミングで、多くの普及している手続き言語のような弊害がないために成り立つだけです。

**デフォルトの名無しさん** · 2021/11/13(土) 17:29:13.45

>>594
(1)多くの言語のデータ管理はヒープとスタックです。スタックには（よほど特殊なOSでない限り）違いがありません。

(2)「参照カウントゼロ時に即座に解放する場合」意味のある日本語で書きましょう、開放すると言っておきながら
ガベージが無いといったり、RustであればRc<T>やArc<T>で参照カウントゼロ時は確保してないということです。

(3)「ベンチマークでも遅い」例えばCPUのベンチマークだって幾つも項目がありますが、その中のスループットは
高い（near =早い）と言っているのです。一方でレテンシーは遅いのです。

なぜそんなに強引に推し通したいのか、理解不能です。

**デフォルトの名無しさん** · 2021/11/13(土) 18:05:59.35

ベンチマークの数値ってもうRustのコンパイルエラーと同じぐらい意味不明と思われてるね
Prologさんを500億の言語にしても誰もほめてくれないし

**デフォルトの名無しさん** · 2021/11/13(土) 18:55:57.32

GCなければキャッシュの効果は高くなりそうだけどねｗ

**デフォルトの名無しさん** · 2021/11/13(土) 19:58:21.21

>>596
おそらくC++やRustを使ったことがないのだろうけどC++のshared_ptrやRustのRc Arcを使うのは所有者が複数になる特殊ケースのみ
それらのみが参照カウンタを用いるけど所有者がいなくなった時点で自動的にリソース解放される
これをGCと呼ぶ人はいない
もちろんそれ以外のケースは参照カウンタも使わずに解放される
そのためGC言語は原理的にどうやってもCやC++やRustに勝つことはできない

**デフォルトの名無しさん** · 2021/11/13(土) 20:16:30.44

特殊な界隈でそういう習慣があるのか知らんが
参照カウンタは普通にGCの実装方式の一つと
言われてるだろ

**デフォルトの名無しさん** · 2021/11/13(土) 20:50:12.12

末尾再帰ができないのをループで書いても
スタックがあふれるけど

**デフォルトの名無しさん** · 2021/11/13(土) 20:53:18.97

例えば、ベンチマーク時間が30秒だとして、どれだけ回数を多く実行できるかがスループットであり
gcのあると言われる言語の中でgcの時間/頻度を調整できるものは30秒gcをしなければ、余計な処理が
走らないために数値が当然高くなる。もちろん処理中に使用メモリが常に増大して終了時のみに解放を
するため整合性のある説得力のあるベンチマークとは言いませんが、特定の処理に限ってメモリーが
溢れないのであれば、十分に取りうる選択肢です。

そして1msが致命的となるような処理では重要ですが特定桁までPIを求めたりフィボナッチ数列の処理
時間を計測したり、あんまり意味がないですね
多くは最適化がどこまでなされているか、配列などの範囲チェックなどのランタイムチェックが足枷に
なっているか、などが違うだけで言語的な特性だとは言いません。

上のほうでshared_ptrなんて持ち出してバカ言ってる人がいるけど言語は適用範囲が違えば有利な分野が
違います。「勝つ」なんて、Cなんて基本は配列などの範囲チェックなんかはやってないわけで原理的な
説明に１つもなってません。CとRustを同列に並べることがどうかしてる、Rustは範囲チェックなどは
安全な言語として当然やってるわけでRustだってアロケーションは他のgcの言語と同じく従来はjemallocで
今は違いますが確保と解放がセットになっている事が、今は有利に働いているが、将来的にはそうだという
確信はありません。そうでなければgcの研究なんて見捨てられるでしょう

**デフォルトの名無しさん** · 2021/11/13(土) 21:00:37.35

またGCの定義をmalloc/freeとreference countとtracing GCの3つの間でお手玉して好き放題言う流れか

**デフォルトの名無しさん** · 2021/11/13(土) 21:05:09.14

更に言えば多くの独立したgcのある言語は、gcにおけるメモリー断片化を防ぐコンパクション処理を独自にやっている訳でOSに任せているRustが有利なのはその通りですが、だからと言ってその処理を行って無い事を不正という話には全くなりませんし、原理的にどうやっても等という結論出すことは全く意味がありませんね

**デフォルトの名無しさん** · 2021/11/13(土) 21:14:45.54

>>600
参照カウンタはオペレーティングシステム内でもファイルシステムでも用いられている普遍的なデータ管理方式
参照カウンタを用いていることをガベージコレクションだと主張する人はいない
C++もRustも所有者が複数とせざるを得ない特殊ケースにおいて最適最速な方式として参照カウンタを用いている

>>602
やはりCもC++使ってことがない初心者だったのか
shared_ptrはCではなくC++です
そしてC++のshared_ptrはRustのArcと同じもので参照カウンタを用いている
あなたの無茶苦茶な主張では「C++とRustはGC言語」となるが世間では当然そんな主張は存在しない
もう一つのあなたのデタラメな主張「GC言語は速い」というデータも世間には見当たらない

**デフォルトの名無しさん** · 2021/11/13(土) 21:24:08.80

ガベージコレクション
https://ja.wikipedia.org/wiki/ガベージコレクション
じゃあページの記述を削除して直して来いよ。顔真っ赤にしなくても良い話だぜ？書き間違いぐらい読もうよ？
「GC言語は速い」などという主張はしていないのも読めないから呆れるんだよ、妄信するあんたらを

**デフォルトの名無しさん** · 2021/11/13(土) 21:51:51.77

もっと詳しく書かれている英語版に明確に書かれていますね
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
Many programming languages require garbage collection, ...
these are said to be garbage collected languages.
Other languages were designed for use with manual memory management,
but have garbage-collected implementations available (for example, C and C++).
「多くのプログラミング言語はGCを必要としていてそれらはGC言語と言われる」
「その他の言語は手動メモリ管理で設計されたがGC実装も利用可能(例としてCとC++)」
つまりCとC++および状況が全く同じRustはGC言語ではないです

**デフォルトの名無しさん** · 2021/11/13(土) 22:03:01.49

はあ。。馬鹿馬鹿しい

**デフォルトの名無しさん** · 2021/11/13(土) 22:10:48.49

お前らの判断が遅いのは「審判は第三者でなければならない」という習慣のせいかな
自分が審判になって自分で好き放題に判断すれば早いんだが

**デフォルトの名無しさん** · 2021/11/13(土) 22:13:59.53

tracing GC の方が有利なアプリケーションって具体的に何？

**デフォルトの名無しさん** · 2021/11/13(土) 22:29:17.51

いろいろなプロセスが動かないバッチ処理なんかは逐一確保と解放を繰り返さない分だけ、調整すれば早いでしょ

**デフォルトの名無しさん** · 2021/11/13(土) 23:05:29.89

>>611がここでプロセスとか言い出してるのを見てもわかるように
GC言語が有利というトンデモ主張している人は基本的な常識知識がないようだ

**デフォルトの名無しさん** · 2021/11/13(土) 23:09:26.37

自分の間違いを認める人が全くいなくてこのスレはわけわからん

**デフォルトの名無しさん** · 2021/11/13(土) 23:10:29.14

馬鹿はほっとけ

**デフォルトの名無しさん** · 2021/11/13(土) 23:31:48.59

前提の違う話が交錯してるだけｗ言いたいやつに言わせとけばいいｗ

**デフォルトの名無しさん** · 2021/11/13(土) 23:42:47.00

>>611さんの解読
(1)バッチ処理だといろいろなプロセスが動かなくて
(2)つまりバッチ処理でなければいろいろなプロセスが動いて
(3)そしてバッチ処理でいろんなプロセスが動かなければ逐一確保と解放を繰り返さなくて
(4)逐一確保と解放を繰り返さない分だけ調整すれば早い
とおっしゃってるようだけど

(1)バッチ処理でもよくあるパイプライン式ならいろんなプロセスは動くし
(2)バッチ処理でなくてリアルタイムにストリーム処理でもプロセス一つだけもあってそもそもバッチ処理とプロセス数は関係ないし
(3)プロセス数が増えてメモリを使うことで起きうる確保と解放ならばOSによるメモリ管理とスワップの話になるし
(4)OSによるスワッピングが起きなければ起きた時より確かに実行速いのはその通りだけど
プログラミング言語によるメモリ管理やGCの話とは関係ないですね

**デフォルトの名無しさん** · 2021/11/13(土) 23:55:33.15

言いたいことを自由に言うのは良いことだよ
ただ、言われたことを全部聞く義務があると思うのは悪い

**デフォルトの名無しさん** · 2021/11/14(日) 00:37:07.99

GCの方式の一つとして参照カウント方式があるが増減のオーバヘッドや不完全性からGCとしては少数派で主流はトレーシング方式
一方でC++/shared_ptrやRust/Rcは参照カウント方式をとっているがガベージをコレクションする形ではなく停止もなく全体が対象でもないため少なくとも通常のGCとは呼ばないかな
そのためC/C++/RustはGCのない言語と一般的に言われている
このあたりは共通認識でよいのではなかろうか

**デフォルトの名無しさん** · 2021/11/14(日) 00:48:00.30

書き込みが多すぎてなんの前提で話をしてるのかよくわからんが、通常のGCじゃないならなんなんだ。PerlはGCじゃないのか

**デフォルトの名無しさん** · 2021/11/14(日) 00:54:15.03

>>619
そこは日本語をちゃんと読んで欲しかった

＞参照カウント方式をとっているがガベージをコレクションする形ではなく停止もなく全体が対象でもないため少なくとも通常のGCとは呼ばないかな

**デフォルトの名無しさん** · 2021/11/14(日) 00:55:47.54

ごめん。それでもわからんけど、Perlは参照カウント方式を使ってるんだけど、通常のGC言語ではない、ってこと？

**デフォルトの名無しさん** · 2021/11/14(日) 01:02:54.74

>>621
ま、まじですか？
日本語で「WWWはXXX方式をとっているがYYYという状況のためZZZではない」な文章を「XXX方式はZZZでない」と解釈する人を初めて見ましたｗ

**デフォルトの名無しさん** · 2021/11/14(日) 01:04:14.81

つまり、君は何が言いたいの？

**デフォルトの名無しさん** · 2021/11/14(日) 01:17:50.43

意図的に歪曲して言いがかりを付けたいだけなようなのでやめときます
一般的な共通認識を>>618に書いただけです

**デフォルトの名無しさん** · 2021/11/14(日) 01:42:47.96

ビジー状態とアイドル状態を繰り返すようなアプリはアイドル時にGCできるから有利な場合もあるのかな
shared_ptrでも実装工夫すれば同じことはできはするだろうけどめんどくさそう

**デフォルトの名無しさん** · 2021/11/14(日) 07:13:40.75

C#も、ついに10.0まできた。
貪欲に機能を追加し、着実に進化(複雑化)しているし、最先端とは言わないけど先端を走っていると思うんだ。
もう少し評価してあげてもいいと思うんだけど、みんな興味ないの？正直Goより・・・・

**デフォルトの名無しさん** · 2021/11/14(日) 08:17:41.01

C#はjavaと比べられる位置なので・・・興味ないというか既にみんな知ってるよね

**デフォルトの名無しさん** · 2021/11/14(日) 11:00:50.01

まだやってたのかｗｗ
ＧＣ言語であるない論破ｗｗｗもとを見ればＧＣアルゴリズムだって言ってるけど、途中で
絶対Rustに勝てないマンがＧＣ言語ではない言い出してるが、マジどうでもいいなｗｗｗ

絶対勝てないならここを見る必要もないだろ、Rustすれでワッショイワッショイやってろ

**デフォルトの名無しさん** · 2021/11/14(日) 13:01:51.01

C#は開発者文化を含めJava以上に単一言語で全部済ませる志向が強い言語なんだよね
実際俺も信者だったし信者ばかりの環境で仕事してたこともあって、いかにC#が優れているかはよく分かってるつもり
チームにC#を導入したら最後、他に手を出す理由を正当化することができなくなってしまい、結局つまんない職場になっちゃうんだよ
だから俺は一切C#使わないことにしてる

**デフォルトの名無しさん** · 2021/11/14(日) 13:56:35.32

Good は Great の敵

**デフォルトの名無しさん** · 2021/11/14(日) 15:27:05.72

>>625
C++にはGCが無いためそういうのは必要ない
shared_ptrは単なるスマートポインタで使い終わると自動的にdeleteが呼ばれるだけ
RustのRcも同じ

**デフォルトの名無しさん** · 2021/11/14(日) 16:22:12.42

>>631
shared_ptrなりRcなりは普通にコーディングするとスコープ抜けたり所有権失ったり獲得した領域が不要になったタイミングで即時freeされるけど
ビジー状態終了後にまとめてfreeしたいならそれまで参照を生かしておくなどの工夫が必要だよね
いわゆるGCならGCを一時的に止めるだけで比較的簡単に実現できる

ただ、C++やRustでこういう状況に対応しようとしたら arena 使うのが定石な気もするのであまり意味のない比較だったかも

そもそもこういうワークロードが現実的にどの程度存在するかもよくわからないし
freeのオーバーヘッドがどの程度大きいかにも依るので
実際のアプリケーションのベンチマークとかとらないとちゃんとした議論はできない気がしてきた

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

shared_ptrやRcは参照カウント方式のGC機能を提供するライブラリ
これらをGCとは呼ばないというのは無理がありすぎる

「GC言語」はGCの利用を基本的前提として設計されてる言語という意味なので
non-GC言語にGC機能が用意されてるからといってGC言語に分類されるわけではない

**デフォルトの名無しさん** · 2021/11/14(日) 17:18:41.30

>>626
C#はこの前メソッドチェーンでとやかく言ってた人たちには、LINQ表現などはさらに一歩進んだ考えだが、彼らが
このような記述表現が、仮にお気に入りの言語に入っても大喜びするとはとても思えない。
GCの観点でいえば、JavaやC#などのclassで参照を多用して並列GCでストップのあるものと、Goのようにstruct値
だけだが、軽量スレッドがあるために並列GCにしなければならなかったものとは同じ土俵で比べるべきではない
これは同じく、並列GCを用いないDIO様がいない世界の言語とも比べらずらい。

**デフォルトの名無しさん** · 2021/11/14(日) 17:26:09.38

>>633
shared_ptrやRcはライブラリではありません
単なるスマートポインタです
ポインタを使い終えると対象を自動的に解放します

例えばC++では同じスマートポインタとしてunique_ptrもあって使い終わると自動的にdeleteが呼ばれて解放されます
同様にshared_ptrもあって使い方終わると自動的にdeleteが呼ばれて解放されます

これらのどこにガベージコレクションの要素がありますか？
shared_ptrをGCだと主張するならばunique_ptrについてはどうですか？
もし仮にdeleteが呼ばれて解放することをGCだと主張するならばC++では常にGCが行われていることになってしまいますが？？

**デフォルトの名無しさん** · 2021/11/14(日) 17:53:57.69

>>632
freeはそんなに重くないにしても、メモリアロケーションは論理アドレスから仮想アドレスへ変換し更には連続し
適したサイズの空間を見つけるために当然ながら重くなる。
Linuxカーネルの場合のBuddy実装があるに、tcmalloc/jemalloc/dlmalloc/mimalloc/boehmなど、プログラムに
より適化したOSSの実装が次々と出来ていることからも、仮にプログラムがメモリ漸増するものではなく決定論的な
予測が可能である場合なら、逐一メモリー確保のためにOSに介在するよりも、プログラム開始時にドカンとメモリを
確保したほうが早くなる可能性もある。もし可能なら今の型推論と同じくこれはコンパイル時に解決されるだろう

そういった意味で言えばアロケーションと解放のプログラムからの切り離しは、Goにおけるコンテキストスイッチの
話とも似ていて、言わばローテクともいえる参照カウントや逐一解放が絶対的、将来に渡って良いとは言い切れない。
もちろん並列GCのおける全停止は問題だが

**デフォルトの名無しさん** · 2021/11/14(日) 18:45:12.28

流れまったく読んでないけど
スマートポインタはGCではないだろうｗ
Javaが出るときC++とくらべてこんなにもシンプル！というのと
C++とくらべてGCがある！という宣伝だったと思うけど

**デフォルトの名無しさん** · 2021/11/14(日) 19:33:55.78

ランタイムレベルてmark-and-sweepしたりcopy GCしたりするやつはtracing GCという名前が付いています
使い分けよう

**デフォルトの名無しさん** · 2021/11/14(日) 19:59:08.54

>>637
Javaが出たときにスマートポインタってあったのか？

**デフォルトの名無しさん** · 2021/11/14(日) 20:11:47.32

疎結合という便利な言葉を思い出したから使おう
言語仕様を一切変更することなくスマートポインタを追加とか削除できるのは疎結合だよな

**デフォルトの名無しさん** · 2021/11/14(日) 20:20:08.21

なんでGCの有無を気にするかというと、GCの挙動があるとやりづらい対象があるからでしょ？
GCが前提にある言語だと、大抵はその言語の普通のスタイルからかけ離れた、マイナーなテクニックが必要になってウザい
GCが無くても普通に使える言語ってのは、プログラマのUXを変えずにそういうジャンルに手が届く＝同じノウハウを共有できるから良い

そういう意味ではRustはRc無しで十分に使えてる。何でもかんでもRcやArc！みたいな風潮は無い

**デフォルトの名無しさん** · 2021/11/14(日) 20:23:46.45

>>640
単にopt-inであるってだけじゃないですかねそれは
疎結合っていうとインターフェースが適切に定義されていて特定の実装に依存していないこと

**デフォルトの名無しさん** · 2021/11/14(日) 20:24:33.68

意味不明なことを書いたやつが一番偉い

**デフォルトの名無しさん** · 2021/11/14(日) 22:27:20.79

>>635
参照カウント方式はGCじゃないって主張なの？
それならshared_ptrやRcはGCじゃないって言うのは理解はできる(同意はしないけど)

参照カウント方式もGCの一種だけど
それを実装してるshared_ptrやRcはGCじゃないって主張ならちょっと理解不能

ちなみに有名なGC本の「The Garbage Collection Handbook」には
shared_ptrやunique_ptrが参照カウント方式のGCとして説明されてるよ

**デフォルトの名無しさん** · 2021/11/14(日) 23:54:26.37

>>644
C++もRustもこの点で全く同じだからC++で説明すると

まずunique_ptrは所有者が常に1人だけのスマートポインター
所有権は譲渡することができる
所有者のスコープが尽きたら自動的にdeleteが呼ばれて開放(回収)される

次にshared_ptrは所有者が複数可能なスマートポインター
所有権は共有することができる
全ての所有者のスコープが尽きたら自動的にdeleteが呼ばれて開放(回収)される

このようにどちらも全く同じ仕組み
(1) shared_ptrでは所有者の数を数えるためにカウントしているけれどカウントしているとGCなの？
(2) unique_ptrでは所有者1人だからカウントはしていないけど全く同様に自動的にdeleteされて回収だけどGCなの？
(3) スマートポインターを使わない場合は手動でdeleteを呼んで回収だけどGCなの？

以上の3点をよろしくおねがいします
3つとも仕組みは全く同じで同じように回収されていきますがカウントしているとガベージコレクションなのですか？

**デフォルトの名無しさん** · 2021/11/15(月) 00:19:00.87

教科書等の標準的な定義と違うことを言い出す奴が
説明しろよ

**デフォルトの名無しさん** · 2021/11/15(月) 00:48:36.22

garbage collectorとgarbage collectionは別だろう
645の1,2,3はいずれも後者の一手法に該当する
前者は後者を実行する主体であり、スマポは前者には該当しないとするのが普通
能動的にgarbage collectionを行うというよりプログラマ自身がそれを行うための補助に過ぎないからな

**デフォルトの名無しさん** · 2021/11/15(月) 02:20:47.19

俺が信じるGCを信じろ！

**デフォルトの名無しさん** · 2021/11/15(月) 06:44:36.60

手動で解放するコードを書かなくても自動的にヒープメモリを解放してくれるのがGCだよって言えばshared_ptr、unique_ptrはGCになるでしょう。
でもヒープメモリが解放できるようになってもすぐに解放せずにあるタイミングでいっきに解放するのがGCだっていえばshared_ptrとunique_ptrはGCにならないでしょう。

**ハノン** ◆QZaw55cn4c · 2021/11/15(月) 06:52:03.10

>>649
＞手動で解放するコードを書かなくても自動的にヒープメモリを解放してくれるのがGC
足りない。
この条件＋「循環参照も問題なく扱える」という条件を追加して！

＞ヒープメモリが解放できるようになってもすぐに解放せずにあるタイミングでいっきに解放するのがGC
動作タイミングはGCの本質ではないとおもいます

**デフォルトの名無しさん** · 2021/11/15(月) 09:26:37.89

>>648
藁人形論法が標準化されたら平和になるどころか争いが増えるだけだな

**デフォルトの名無しさん** · 2021/11/15(月) 10:23:26.99

なんだ朝鮮人か

**デフォルトの名無しさん** · 2021/11/15(月) 10:35:19.43

うっせー！GCじゃないぞ！こ、これはセガサターンだ！(笑)

**デフォルトの名無しさん** · 2021/11/15(月) 10:59:52.82

争いの原因は多様性ではなく
テンプレ化した標準的な決まり文句なんだよ

**デフォルトの名無しさん** · 2021/11/15(月) 11:17:46.17

なんか変なこと言われてたような気がしたけど、Perlは参照カウンタ方式のGCを採用した言語だよ