次世代言語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/17(水) 12:22:44.44

>>803
それはかなりの曲解
自動化しているのは結果として起こる「メモリ解放」
その「メモリ管理」自体は手動の範囲内だとはっきり書かれている

**デフォルトの名無しさん** · 2021/11/17(水) 12:26:39.90

一生懸命にC++を味方に引き込もうとする姿が哀れに思える。C++は全部プログラマが気にして細心の注意を
払い神のごとくコントロールする言語なのに、一緒にされたらC++プログラマーは嫌

**デフォルトの名無しさん** · 2021/11/17(水) 12:39:06.76

RAIIでやりくりするほうがある種スッキリしてるし
それを欲する層は居なくはならないよ

**デフォルトの名無しさん** · 2021/11/17(水) 12:50:33.28

>>803
追加解説サンキュー。
普通はそう考えるよなぁ。

自分で引用しているのにその内容を無視するのはなぁ。
それで騙せると相手を馬鹿にしているのか、本当にそうだと幻覚でも見ているのか……

>>807
まずははっきり書かれている部分を示してくれない？確認するから。

**デフォルトの名無しさん** · 2021/11/17(水) 12:53:41.30

>>807
>その「メモリ管理」自体は手動の範囲内だとはっきり書かれている

どこに？
どこにshared_ptrの利用は手動メモリ管理の範囲内ですってはっきり書かれてるの？
shared_ptrに言及してるのはそのページでは↓ここしかないけど？
「This can also be used with deterministic reference counting. In C++, this ability is put to further use to automate memory deallocation within an otherwise-manual framework, use of the shared_ptr template in the language's standard library to perform memory management is a common paradigm. shared_ptr is not suitable for all object usage patterns, however. 」

**デフォルトの名無しさん** · 2021/11/17(水) 13:09:29.01

>>806
goのdefer文のがよっぽど楽だと思うけどね。
デストラクタみたいにオブジェクトに紐づくのは不自然なことが多い。

**デフォルトの名無しさん** · 2021/11/17(水) 13:20:45.45

そもそもWikipediaをソースに議論するのが間違っとる

**デフォルトの名無しさん** · 2021/11/17(水) 13:58:13.62

実用上はGCのタイミングとやり方をプログラマが制御できるかどうかだね

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

「RustはGCじゃない！」
「え？ARCでしょ？別にどうでも良いじゃん？」
「shared_ptrがうんたら、なんちゃらで、RustのArcの”A”は自動じゃない！Wikiによると（長すぎるので省略）」
「C++やRustはスッキリ！C#のIDisposableはRustの真似！」
「？？？」
「C++を仲間に引き入れたいだけだろｗ」
「だからWikiによると（長すぎるので省略）shared_ptrは手動なんだ！うぇぇん！バーカｗ」

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

第三者目線で観ると一人で自演してるようにしか観えない

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

だろ？

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

>>812
例えばどういうケースで不自然になるの？

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

>>802は別にGC起因の問題じゃなくて単なるシンタックスの問題だろ
メモリの解放とその他のリソースの解放を、GC言語ではレイヤの異なる別の問題として扱っているだけだ
C++やRustではそのusingに相当する言語機構を用いてメモリ解放の面倒も見なければならないわけで、本質的には負担が増えている
最近のバージョンのC#では using var r = みたいな記法もできるようになって記述負荷の問題は解決したが、そういう問題じゃないんだろ？

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

copy constructor と
move constructor だな

**デフォルトの名無しさん** · 2021/11/17(水) 18:32:09.16

そもそshared_ptr自体使わない。
new/deleteも使わない。
RAII、所有権と唱えると設計がすっきりする。

**デフォルトの名無しさん** · 2021/11/17(水) 18:46:34.87

>>821
単独所有者限定はRustですら諦めたデザインなのに。

**デフォルトの名無しさん** · 2021/11/17(水) 18:56:42.09

>>822
HTML5仕様のパーサー、木コンテナ、ダブル配列ベースのTRIE木コンテナ、それら木へのイテレータ/アダプター、CSS Syntax Module Lv3仕様のパーサーなど書いた結論。
new/deleteすら要らない。
偉い人が言ってることは全部ほんとだった。

**デフォルトの名無しさん** · 2021/11/17(水) 19:10:07.77

ｗｗｗ

**デフォルトの名無しさん** · 2021/11/17(水) 19:32:37.01

>>811
ずばりそこに書かれてる

　This can also be used with deterministic reference counting.
　In C++, this ability is put to further use to automate memory deallocation within an otherwise-manual framework, use of the shared_ptr ...
　C++においては、RAIIを決定論的参照カウント方式と共に使うことで、メモリ解放を自動化するのに利用している。その他の点では手動のフレームワークの範囲内で。

ようするに自動化はあくまでも『メモリ解放』だけであって
その他の点で(otherwise)は『手動のフレームワーク』すなわちこのwikipedia項目『手動メモリ管理』の範囲内(within)だと明記されている
shared_ptrが自動でメモリ解放するのは当たり前だけどもあくまでも手動メモリ管理の範囲内ということ

**デフォルトの名無しさん** · 2021/11/17(水) 20:02:17.52

vector、listなどSTLのコンテナは基本的なストレージとして設計されてるそうで、実際、その他のコンテナはこの上に実装できる。
tree、ダブル配列ベースのTRIE木などをこれらの上に実装して不都合は無かった。
速度的にもmap、unordered_mapなどと比較するレベルで、普通に使える。

**デフォルトの名無しさん** · 2021/11/17(水) 20:07:40.05

イテレータを使い分けることで、終了タグが現れる行きがかり順の走査と単純な木としての走査を行える二面性を持つHTML木も作ってみた。
単純な木として走査するならDOMのように見え、HTML文書として走査するなら（タグのバランスが取れていない）壊れたHTMLも扱える。

**デフォルトの名無しさん** · 2021/11/17(水) 20:10:27.74

うん

**デフォルトの名無しさん** · 2021/11/17(水) 20:11:35.74

そういう作業をした結果、HTML5とは、インターネットエクスプローラーを倒すためにデザインされており、プログラミング的な合理性は全くないと理解した。
また、HTMLを簡単に扱えないようにするため、いろいろ詭弁を使いながら仕込みを行っている。
HTML5のおかげで、賢いベンチャーが現れてグーグルを倒すようなことを防げる。

**デフォルトの名無しさん** · 2021/11/17(水) 20:21:18.87

R！A！I！I！
これですべて解決。
RAII強し。

**デフォルトの名無しさん** · 2021/11/17(水) 20:21:26.12

>>825
メモリ解放を自動化しているならそれはGCでは？
逆にGCはそれ以外何の仕事をすると？

**デフォルトの名無しさん** · 2021/11/17(水) 20:26:26.17

>>831
例えばunque_ptrもメモリ解放を自動化していますがGCとは呼ばれませんよね
つまりメモリ解放の自動化とGCは別のことです

**デフォルトの名無しさん** · 2021/11/17(水) 20:30:25.82

セガサターン言語！

**デフォルトの名無しさん** · 2021/11/17(水) 20:34:46.44

RAIIで無駄なくやりくりするのがC++の思想なんだろうね
スマートポインタもRAIIがもたらすリソース解除実行の一例で
ヒープメモリをデストラクタでdeleteしてるだけだから

**デフォルトの名無しさん** · 2021/11/17(水) 21:40:20.88

>>831
>>832は（今までのやり取りにもある通り）悪意を持って情報を隠すから気をつけろ。

>>684以降、誰も異論を挟んでいないWikipediaの解説
ガベージコレクションとは、コンピュータプログラムが動的に確保したメモリ領域のうち、
『不要になった』領域を自動的に解放する機能である。
にある通り、『不要になった』かどうかを自動的に判断するのがポイント。

自動で判断しないc++のunique_ptrはGCの機能とは言わんが、（仕様に従う限り）自動で判断するshared_ptrはGCの機能と言える。

**デフォルトの名無しさん** · 2021/11/17(水) 22:09:03.50

>>835
またゴールポストを移動させたの？
その「自動的に判断」「自動に判断」などは今までこのスレに一度も出て来ておらず誰も主張してきていない初登場の言葉
そしてその意味の定義がなされていないから解釈次第になる

**デフォルトの名無しさん** · 2021/11/17(水) 22:12:01.05

Rust 2021 Edition

**デフォルトの名無しさん** · 2021/11/17(水) 22:12:58.72

だぜぇｗｗｗ

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

ちゃんと必要十分条件を考えてください

**デフォルトの名無しさん** · 2021/11/17(水) 22:57:46.68

こいつらがプログラム作るの勘弁してほしいんだが

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

法律で禁止するべきと？

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

まだWikipediaとか不毛なことやってたのか
もうちょっとまともな文献を挙げてみると
リチャード・ジョーンズ「ガベージコレクション」
では参照カウント方式GCの具体例としてBoostのshared_ptrを取り上げて、トレーシングGCとの比較が行われている
著者はメモリ管理についての国際会議（ISMM）の創設者なので、少なくとも学会レベルではshared_ptrはGCの一形態として認識されていると考えていい
もちろん学会が世の中の全てではないから「俺の常識ではGCではない」と主張するのは自由だけど

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

激おこなの？

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

>>825
やっぱり何言っても無駄だったか

「自動だけどそれは手動の範囲内」ww

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

GCはGCまかせのタイミングでいつかきっとメモリを解放できる
RAIIはRAIIオブジェクト破棄のタイミングで※1リソース※2を解放できる

※1 shared_ptrの場合は参照カウンタを見て
※2 shared_ptrの場合はメモリを

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

shared_ptrがGCかそうでないかはどうでもいいからさ、
GCの動作有無をアプリ開発層のプログラマから制御できる次世代言語はどれよ？

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

真実は>>660
それ以上でもそれ以下でもない

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

【結論】紅しょうがは無料だけど良心の範囲内！

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

>>846
D

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

99％のプログラマーはこんなアスペルガーの領域のことまで考えてプログラミングやってないと思う

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

>>836
ゴールポストは>>684から変えてないし、まともな異論も出てない。「手動メモリ管理」とかも>684を否定しているわけではないだろ。それとも>684はデタラメと主張するのかね？
嘘ばかりの歴史改竄主義者だな。

世間一般の認識は>>842みたいだから、>836の心の中のGCについては勝手にすれば？歴史改竄しないかぎりだけど。

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

キミはおそらく誰からも相手されとらんだけではｗ

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

お前らが大好きなWikipediaの文言だぞ

https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

Reference counting
Main article: Reference counting

Reference counting garbage collection is where each object has a count of the number of references to it. Garbage is identified by having a reference count of zero. An object's reference count is incremented when a reference to it is created, and decremented when a reference is destroyed. When the count reaches zero, the object's memory is reclaimed.

As with manual memory management, and unlike tracing garbage collection, reference counting guarantees that objects are destroyed as soon as their last reference is destroyed, and usually only accesses memory which is either in CPU caches, in objects to be freed, or directly pointed to by those, and thus tends to not have significant negative side effects on CPU cache and virtual memory operation.

There are a number of disadvantages to reference counting; this can generally be solved or mitigated by more sophisticated algorithms

https://ja.wikipedia.org/wiki/%E3%82%AC%E3%83%99%E3%83%BC%E3%82%B8%E3%82%B3%E3%83%AC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3

スマートポインタ

なお、C言語で参照カウント方式のガベージコレクションを利用する場合、通常煩雑なコーディングを必要とするが、C++では以下のようなRAIIを活用したスマートポインタを利用することで緩和できる。

・Boost C++ライブラリのboost::shared_ptrおよびboost::shared_array。
・参照カウントの増減処理をカスタマイズできるboost::intrusive_ptrもある。
・C++11以降のstd::shared_ptr
・Active Template LibraryのATL::CComPtr - COMオブジェクトのスマートポインタ。
・Windows Runtime LibraryのMicrosoft::WRL::ComPtr - Windowsランタイムオブジェクトのスマートポインタ。COMオブジェクトにも使用可能。

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

>>823
否定はしないが賛成もしない
new を出来るだけ避ける様に心がければ delete の心配が無くなるのは当たり前

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

>>846
node.js

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

>>823
newを使わない要らないとはヒープを一切使わないという意味ですか？
それともC言語のように自分でmalloc等を用いてヒープメモリ管理を行うべきという意味ですか？
前者はそれら挙げている物のプログラミングが不可能だから後者の何十年も前に戻っただけですか？

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

>>856
C++の標準ライブラリにあるstd::string、コンテナクラス、unique_ptr、shared_ptrなどを使っていればnewを書かずにヒープメモリを使うことができるし、shared_ptr以外はスコープを抜けたときに自動的にデストラクタを呼んでヒープを解放してくれる。
ちゃんとC++を使えばほとんどの場合手動でメモリ解放せずに済むよ。

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

>>856
それはRAIIを判ってない発言だからたぶん恥ずかしい

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

>>857
コンテナの中身がポインタだったら？

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

本人も認めてるけどRAIIってネーミングセンスがないよな

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

>>856
この辺見るといいと思う
https://www.youtube.com/watch?v=86xWVb4XIyE&;t=1790s

shared_ptrがGCの一種って話も出てくる

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

>>857
しかし元の方は>>821でdeleteを使わないだけでなくshared_ptrも使わないとおっしゃっているのです
つまり解放をどうするのか問題が残ります
あとコンテナ自体の解放に加えて要素が値だけで構成されずポインタを含む場合はその先の解放も必要ですよね

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

>>858
ある程度の構造を持ったデータを扱う場合
RAIIではそのクラスのデストラクタでdeleteが発生しますよね？
>>823はdeleteも要らないと書いていますがそこはどうするのでしょう？

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

new/deleteを明記しないってだけやろ

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

golangなんかだとbenchでB/opやallocs/opが取れるけど、他の言語はあまりメモリー量は重要視してないのかな？
最終的にはエネルギー毎のjoule/opとか出してほしいけど、IntelとAMDそしてARMで全然違うのはCOP21とかは
何も考えてない偽善だろう

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

>>862
所有権について言及してるしunique_ptrを使うのでしょう

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

流れを踏まえると
C#はせっかくGCがあるのに
自分でいちいち手動のDisposeを描かされる

残念な言語(キリっ

と言わざるを得ない

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

GoやJavaなんかだとGCがあるからやばい、って思えるほどシビアなプロジェクトの開発をしてみたいもんだ

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

>>863-864
デストラクタ内のdeleteは勘定に入れなくて良いルールなんだろう

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

>>867
というより可能な限りGCを動かさないように
値型を多用してコレクションも
System.Collectionsじゃなくて
System.Collections.Genericのほうを使うとかして
ヒープ側を使わないようにする悲しい頑張りが必要

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

まあ、ネイティブコンパイラが必須なケースが少ないからこそ
JavaScriptインタプリタのようなものをC++やRustで書いて使ってるんだよな

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

>>870
C#ならガベージの生成を避けるようなケースでもC++なら気にせずヒープ使いまくれるってことか？
そうでないならそれはGCの問題ではないことになるぞ

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

まだgcの定義の話してんのかよ
文脈依存用語を絶対的な意味で決めつけようとする意味あんの？

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

Railsの高速化に貢献する新たなJITコンパイラを搭載したRuby 3.1プレビュー1が公開

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

>>874
すまないがもはや汎用言語でない言語はスレ違い

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

>>869
newしないんだったらdeleteだって書く必要ないでしょデストラクタであっても

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

「汎用言語」と呼ばれるにはミドルウェアを書くのにも適してる言語じゃないといけないの？

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

Rubyより採用実績の少ない言語は皆専用言語

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

このスレといいフレームワーク系のスレといい、お気に入り以外を攻撃してワンワン噛みつく奴ばっかや…
ニュースリリースぐらい大目に見たれよ？Wikipediaを何行も張り付けるウンコの１０倍は有用だぜ？

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

>>864
なるほど
クラス宣言側でdeleteを使っていても関数側でdeleteを明記しなければdeleteを使っていないことになるのですね

>>821
> deleteも使わない。

>>823
> deleteすら要らない。

ここまではっきりと書かれているので当然クラス宣言の中でもdeleteを使わない意味だと受け取っていました

ところでクラス宣言のデストラクタでdeleteを使う形はスマートポインタと完全に同じ形になっていますが
この自動的にメモリを解放する手法はGCに該当するのでしょうか？

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

いちいち質問して答えを待ってると判断が遅いんだよね
自分のお気に入りの答えを自分で判断する方が圧倒的に早い

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

C++はJavaと違うって事では。

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

早漏DTの意見でした

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

組み込みのmruby は、apache などのmiddleware も書ける。
C の文字列の代わりに、mruby の文字列を使うと簡単・安全

人工衛星、イザナギ・イザナミなどに使っている

mrubyの本も出た。
micro python, Lua の代わりに使う

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

>>880
自動的に開放しているからGCの一種

**デフォルトの名無しさん** · 2021/11/19(金) 00:42:48.75

>>880
クラス宣言ってshared_ptrの実装のこと言ってる？

**デフォルトの名無しさん** · 2021/11/19(金) 05:13:09.95

mrubyとか名前ダサくね？
信者になればかっこよく見えるの？
名前重要とかどこいった

**デフォルトの名無しさん** · 2021/11/19(金) 10:31:20.07

ruby.js

**デフォルトの名無しさん** · 2021/11/19(金) 12:27:45.87

そんなこと言ってるとrustに別実装の処理系が出来た時にディスられるぞ
rustだからstainlessとか

**デフォルトの名無しさん** · 2021/11/19(金) 12:47:40.77

すでに別実装はあったような

**デフォルトの名無しさん** · 2021/11/19(金) 13:41:02.55

>>889
なんでもかんでもxxx.rsって付くのはダサいけど、xxx.jsと同じかな

**デフォルトの名無しさん** · 2021/11/19(金) 13:55:37.85

GCある言語でもインスタンスの生成や参照切れで解放されることくらいは
知ってる必要があるんだが、それもまともにわかってなさげなやつで溢れてる。

**デフォルトの名無しさん** · 2021/11/19(金) 13:56:15.69

ださい拡張子
.cs
.ts
.ps
.gs

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

>>892
誰一人まったく解放されないなんて言ってる奴いないと思うが、どこの世界線から来た人？

**デフォルトの名無しさん** · 2021/11/19(金) 18:18:36.72

>>886

class foo
{
　　~foo()=delete; // このdeleteのことを言ってる。
};

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

>>895
アスペか？

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

>>896
ID末尾をxにしてるのは、C++とC#の両方を表現してるのかい？

**デフォルトの名無しさん** · 2021/11/19(金) 19:57:08.72

宣言のdeleteって言うから。

**デフォルトの名無しさん** · 2021/11/19(金) 20:09:20.65

>>898
流石にnew/deleteとdelete宣言は別物だろうなぁ。
同じ単語を使っているのはc++のケチ臭い用語の流用の結果だし。

**デフォルトの名無しさん** · 2021/11/19(金) 20:52:12.15

デストラクタのdelete自体も嵐を呼ぶ話題だけど。

**デフォルトの名無しさん** · 2021/11/19(金) 21:04:37.53

>>895
それならRAIIで本体をGCさせる時に連動GCさせる時の常套手段

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

たぶんJavaの人じゃないかと思うんだよね。

**デフォルトの名無しさん** · 2021/11/19(金) 22:08:12.78

>>901
本体もGCと呼ぶかは議論が分かれそうだが
付属部分を連動GCすることだけを目的に本体が実体を無くしたものがunique_ptrだよな

**デフォルトの名無しさん** · 2021/11/20(土) 00:19:22.26

自動変数もGCなのか？

**デフォルトの名無しさん** · 2021/11/20(土) 02:24:49.30

>>584
電気メーカーが糊口をしのぐための税金バラマキ国プロ
昔も今も変わらない

**デフォルトの名無しさん** · 2021/11/20(土) 08:44:52.28

1. 昔も今もどっちも変わらない
2. GCもスマポもどっちも変わらない
3. 1も2も3もどれでも変わらない