次世代言語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(水) 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もどれでも変わらない

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

>>904
約一名にとってはそうみたい

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

>>904
自動変数は参照あっても解放されるからGCにはならんね。

**デフォルトの名無しさん** · 2021/11/20(土) 12:28:48.64

君らはいつになったら回収されるん？

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

Rustの悪口言ったやつ許さんから

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

Rustの母ちゃんでべそ～

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

RustがすごいんじゃなくてGCがクソ

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

バグを無くすにはGCじゃなくテストですよ。

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

ソースを読まなくてもできるテストは
不正アクセスと同じではないが似ている

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

抽象バカはテストが書けないので困る。

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

rustは少なくともCである程度のプログラムを書いてハマった経験がないと
この機能何のためにあるの？ってのがわからない

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

Rustを最近学んでるだけど、すぐに学習曲線やばい言語だということを納得した
おれはC++のスマートポインタらへん知ってるから、かなりマシなほうだと思うけど、
たしかにC/C++やってない人にはそうとうにキツそうだね

やってない人にオススメできる気がしない

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

>>917
それは逆
Rustに苦労している人たちはC++経験者かつ頭が固くてC++から離れて頭をゼロにして学習する能力がない人たちだと言われている

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

>>918
そんな話どこで言われてるの？

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

まぁC++一筋十数年って人だと大変かもね
C++に加えてScalaとかHaskellあたりを履修済みだとだいぶ楽

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

rustもC++もScalaもHaskellも分かるが、まるでそうは思わないｗ

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

rustもC++もScalaもHaskellも分かるが、まるでそうは思わないｗ

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

C++11以降の流れをある程度追えているなら問題なかろうよ

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

03で止まってる人なら辛いかもね

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

最新のC++の方向性見るとこれなら
最初からRustやればとは思わない？

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

C++はCみたいな書き方も出来るが、rustは最初からrustでないといけないから難しいと思う

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

今はc/c++の知識を階段として学んでいる人多いだろうけど、今後はrustしかわかりませんみたいなrustネイティブも出てくるのかな？
これってアセンブリ→cのときにも言われてた？
cを理解するにはアセンブリがわかってないと無理みたいな

**デフォルトの名無しさん** · 2021/11/25(木) 16:03:54.47

よくしらんけど、学習曲線を緩和させるような取り組みもいちおう検討されてるんでしょ？

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

>>926
Cみたいな書き方できるのをメリットと見るかデメリットと見るか？

**デフォルトの名無しさん** · 2021/11/25(木) 16:59:45.85

CはBASICほど遅くなくアセンブラ(機械語)が必要ない、当時俺にとっては奇跡の言語だった
C/C++/VB→Javaのときは実際にJavaしか分かりません、が大量に発生した