公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust
Web上の実行環境
https://play.rust-lang.org
日本語の情報
https://rust-jp.rs/
※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/
※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/
前スレ
Rust part10
https://mevius.5ch.net/test/read.cgi/tech/1617367084/
探検
Rust part11
レス数が900を超えています。1000を超えると表示できなくなるよ。
2021/06/17(木) 00:24:12.56ID:NvYoNP9C
849デフォルトの名無しさん
2021/08/21(土) 21:35:33.43ID:PyG7lKVy 積極的にPython使おうとは思わんなぁ。インタプリタ系はRuby使っているわ
Luaも結構良い感じだと思う
Luaも結構良い感じだと思う
850デフォルトの名無しさん
2021/08/21(土) 21:54:02.20ID:tswurJ+7 うん。 プログラマは Python をそんなに気に入ってない場合は多いと思う。
ただ現代ではプログラミングするのはプログラマとは限らない。
Python は元々はコンポーネントを組み合わせる、いわゆるグルー言語として設計されていて、
エンドユーザ向けの性質を持っている。 BASIC 系と似た立場かな。
このくらいに制限されていたほうがかえって使いやすいという場合は確かにある。
必要なコンポーネントが出そろっている状況で上位のロジックを組み立てる分には
Python も便利なこともあるにせよ、言語としての出来はそんなに良くない。
ただ現代ではプログラミングするのはプログラマとは限らない。
Python は元々はコンポーネントを組み合わせる、いわゆるグルー言語として設計されていて、
エンドユーザ向けの性質を持っている。 BASIC 系と似た立場かな。
このくらいに制限されていたほうがかえって使いやすいという場合は確かにある。
必要なコンポーネントが出そろっている状況で上位のロジックを組み立てる分には
Python も便利なこともあるにせよ、言語としての出来はそんなに良くない。
851デフォルトの名無しさん
2021/08/21(土) 21:59:07.63ID:7GAoG1Iq >>845
>Nimは知らんがパイソンが読みやすいなんて
Pythonは構文にインデントを組み込むことによってざっと眺めた時に人間が読みやすい
一般的には上記の事をPythonは高い可読性があると表現されています
この事は「Pythonは可読性の高い言語」ググれば約 265,000 件出てきます
他の言語と可読性は同じだろって意見の人もいますが少数派ですね
>Nimは知らんがパイソンが読みやすいなんて
Pythonは構文にインデントを組み込むことによってざっと眺めた時に人間が読みやすい
一般的には上記の事をPythonは高い可読性があると表現されています
この事は「Pythonは可読性の高い言語」ググれば約 265,000 件出てきます
他の言語と可読性は同じだろって意見の人もいますが少数派ですね
852ハノン ◆QZaw55cn4c
2021/08/21(土) 22:21:31.89 >>851
https://mevius.5ch.net/test/read.cgi/tech/1587276362/963
「javascriptは可読性の高い言語」で検索すると約 334,000 件
https://mevius.5ch.net/test/read.cgi/tech/1587276362/963
「javascriptは可読性の高い言語」で検索すると約 334,000 件
853デフォルトの名無しさん
2021/08/21(土) 22:31:37.65ID:7PPLxZL+ 元の文脈的に
nimも構文にインデントを組み込んでるからpythonが出てきただけでそういう議論がしたいんじゃないと思う
nimも構文にインデントを組み込んでるからpythonが出てきただけでそういう議論がしたいんじゃないと思う
854デフォルトの名無しさん
2021/08/21(土) 22:36:10.82ID:7GAoG1Iq >>852
>「javascriptは可読性の高い言語」で検索すると約 334,000 件
単に検索件数が多いだけで、上位10件の表示内容を読んでも
「javascriptは可読性の高い言語」と言う内容のページは1つも見つかりません
対して「Pythonは可読性の高い言語」は上位10件の内5件見つかりました
>「javascriptは可読性の高い言語」で検索すると約 334,000 件
単に検索件数が多いだけで、上位10件の表示内容を読んでも
「javascriptは可読性の高い言語」と言う内容のページは1つも見つかりません
対して「Pythonは可読性の高い言語」は上位10件の内5件見つかりました
855デフォルトの名無しさん
2021/08/21(土) 22:41:14.03ID:7GAoG1Iq >>853
おっしゃる通りです(/ω＼)
おっしゃる通りです(/ω＼)
856デフォルトの名無しさん
2021/08/21(土) 22:56:47.50ID:lXSuJ2vU ただのコピペ荒らし
まったくRustもNimも関係ないスレでも見るし
まったくRustもNimも関係ないスレでも見るし
857デフォルトの名無しさん
2021/08/21(土) 23:00:47.35ID:YSvCkW+D Rust Tourだけやっていても作業の流れが身につかなさそうなので、写経を始めました
そこでまず出くわしたのがTokioのバージョンの壁で、バージョンによって動いたり動かなかったり差がありました
クレートの無難なバージョンがどれか、クレート同士の無難な食い合わせはどれか、など、どうやって知れば良いのですか？
そこでまず出くわしたのがTokioのバージョンの壁で、バージョンによって動いたり動かなかったり差がありました
クレートの無難なバージョンがどれか、クレート同士の無難な食い合わせはどれか、など、どうやって知れば良いのですか？
858デフォルトの名無しさん
2021/08/21(土) 23:07:06.11ID:7GAoG1Iq >>857
Nimの写経を始めましょう
Nimの写経を始めましょう
859デフォルトの名無しさん
2021/08/21(土) 23:07:52.34ID:kcBD0DB/ 写経なら写し元と同じバージョンにそろえるのがよいのでは
860デフォルトの名無しさん
2021/08/21(土) 23:24:51.23ID:7GAoG1Iq >>859
>写経なら写し元と同じバージョンにそろえるのがよいのでは
Nimのバージョン 1.5.1を写経しましょう
Nimの実験的特徴
著者： アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html
>写経なら写し元と同じバージョンにそろえるのがよいのでは
Nimのバージョン 1.5.1を写経しましょう
Nimの実験的特徴
著者： アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html
861デフォルトの名無しさん
2021/08/21(土) 23:48:46.37ID:PyG7lKVy 組み込み系ではMicroPythonが流行っているらしいが全く魅力を感じないｗ
862デフォルトの名無しさん
2021/08/21(土) 23:53:13.51ID:+zMEbJ+6 Nimを調べてみたのだが
Rustよりも高機能な点を見つけられなかった
もし有るならば書いてください
無ければ去ってください
Rustよりも高機能な点を見つけられなかった
もし有るならば書いてください
無ければ去ってください
863デフォルトの名無しさん
2021/08/22(日) 02:15:33.57ID:0Cz6ueFz >>862
>Nimを調べてみたのだがRustよりも高機能な点を見つけられなかった
>もし有るならば書いてください
>無ければ去ってください
そんな寂しい事言わないでかまってよ～(´;︵;`)
行末のセミコロンが必要ない
タイプ数がもりもり減ります。
Rust にはもちろん必要です。
main が要らない
スクリプト言語感覚でいきなりコードを書けます。
Rust は main が必要です。
>Nimキチガイ
いつもみんなによく言われます
いや～照れますね～ｖ（=＾0＾=）ｖ
>Nimを調べてみたのだがRustよりも高機能な点を見つけられなかった
>もし有るならば書いてください
>無ければ去ってください
そんな寂しい事言わないでかまってよ～(´;︵;`)
行末のセミコロンが必要ない
タイプ数がもりもり減ります。
Rust にはもちろん必要です。
main が要らない
スクリプト言語感覚でいきなりコードを書けます。
Rust は main が必要です。
>Nimキチガイ
いつもみんなによく言われます
いや～照れますね～ｖ（=＾0＾=）ｖ
864デフォルトの名無しさん
2021/08/22(日) 02:16:39.23ID:KEfgBimj >>863
nimのスレ立ててそっちでやってよ
nimのスレ立ててそっちでやってよ
865デフォルトの名無しさん
2021/08/22(日) 02:32:40.46ID:w5XnK8W7866デフォルトの名無しさん
2021/08/22(日) 02:33:23.15ID:j+Q/a+4n 構うな
さっさとNG
さっさとNG
867デフォルトの名無しさん
2021/08/22(日) 02:35:27.65ID:0Cz6ueFz >>863
>nimのスレ立ててそっちでやってよ
そんな寂しい事言わないでかまってよ～(´;︵;`)
Nim は標準出力への文字列出力が楽
Nim では echo で改行付きの出力ができます。shell と同じですね。通常は改行付きで出力することの方が多いでしょ。
Nim はしょっちゅうやることは簡単にできるようになっています。
そんな Nim の echo は可変引数で値を受け取り型が何なんだろうとお構いなしに出力できます。
let n = 10
let str = "HOGE"
echo "Number: ", n, " String: ", str
一方 Rust は
let n = 10;
let str = "HOGE";
println!("Number: {} String: {}", n, str);
なんかよく判らんマクロでいちいちびっくりさせなきゃいけないです。よく使うものが冗長だとゲンナリします。
変数を直接ぶち込むことも出来ませんしね。
let n = 10
echo n
普通出来るでしょこんなもん・・・。ところが Rust は出来ない。
let n = 10;
println!(n); <- エラー
println!("{}", n); <- 毎度これを書かされる
うざいっす。
>nimのスレ立ててそっちでやってよ
そんな寂しい事言わないでかまってよ～(´;︵;`)
Nim は標準出力への文字列出力が楽
Nim では echo で改行付きの出力ができます。shell と同じですね。通常は改行付きで出力することの方が多いでしょ。
Nim はしょっちゅうやることは簡単にできるようになっています。
そんな Nim の echo は可変引数で値を受け取り型が何なんだろうとお構いなしに出力できます。
let n = 10
let str = "HOGE"
echo "Number: ", n, " String: ", str
一方 Rust は
let n = 10;
let str = "HOGE";
println!("Number: {} String: {}", n, str);
なんかよく判らんマクロでいちいちびっくりさせなきゃいけないです。よく使うものが冗長だとゲンナリします。
変数を直接ぶち込むことも出来ませんしね。
let n = 10
echo n
普通出来るでしょこんなもん・・・。ところが Rust は出来ない。
let n = 10;
println!(n); <- エラー
println!("{}", n); <- 毎度これを書かされる
うざいっす。
868デフォルトの名無しさん
2021/08/22(日) 02:38:26.87ID:0Cz6ueFz >>865
そんな寂しい事言わないでかまってよ～(´;︵;`)
NimはC の関数を気軽に持ってくる
たった一行足すだけで C の関数を使うことが出来るようになります。
proc printf*(format: cstring) {.header: "<stdio.h>", importc: "printf", varargs.}
let n = 10
let str = "HOGE"
printf "Number: %d String: %s\n", n, str
どうですこれ？C の資産を気軽に使うことができるんです。SWIG 等の鬱陶しいラッパーを使うこと無くです。
Rust の場合はご多分にもれずラッパー行きで超絶面倒くさいです。比較用に書きたいんですが結構な文章量になるのでやめます。
そんな寂しい事言わないでかまってよ～(´;︵;`)
NimはC の関数を気軽に持ってくる
たった一行足すだけで C の関数を使うことが出来るようになります。
proc printf*(format: cstring) {.header: "<stdio.h>", importc: "printf", varargs.}
let n = 10
let str = "HOGE"
printf "Number: %d String: %s\n", n, str
どうですこれ？C の資産を気軽に使うことができるんです。SWIG 等の鬱陶しいラッパーを使うこと無くです。
Rust の場合はご多分にもれずラッパー行きで超絶面倒くさいです。比較用に書きたいんですが結構な文章量になるのでやめます。
869デフォルトの名無しさん
2021/08/22(日) 02:44:19.98ID:0Cz6ueFz >>866
そんな寂しい事言わないでかまってよ～(´;︵;`)
Nimはmut mut しなくて良い
Rust はまともな変数を使おうとすると mut mut しないといけません。デフォルトだと再代入できませんから。
普通再代入しまくりますよね？定数ライクに使いたい機会なんて殆どないですよね？なのに mut を毎度書かされます。
let n:int = 10
let mut m: int = 10
Nim ならこうですよ。
let n = 10 # immutable
var m = 10 # mutable
素敵。
そんな寂しい事言わないでかまってよ～(´;︵;`)
Nimはmut mut しなくて良い
Rust はまともな変数を使おうとすると mut mut しないといけません。デフォルトだと再代入できませんから。
普通再代入しまくりますよね？定数ライクに使いたい機会なんて殆どないですよね？なのに mut を毎度書かされます。
let n:int = 10
let mut m: int = 10
Nim ならこうですよ。
let n = 10 # immutable
var m = 10 # mutable
素敵。
870デフォルトの名無しさん
2021/08/22(日) 02:55:06.51ID:0Cz6ueFz >>862
Nim所有者・借用なんてもんでイライラしない
Rust には C のポインタが可愛く見えるレベルで高くそびえ立つ鉄壁の初心者ガード、悪夢の"所有者・借用"の概念が存在します。
プログラムに慣れた人間ですら混乱に陥れ、書いている最中に精神力と人生の貴重な時間をガンガン削ってくれる究極の嫌がらせです。
Rust は変数のコピーしちゃうと元のやつが使えなくなるクソ仕様なのです。書き手にメリットなんて一切無い。C++の悪しきメモリ管理の呪いを持ち込んで来てその中でもさらに悪い部分をデフォルトにした感じです。
struct Point {
x: i32,
y: i32,
}
fn Print(p: Point) {
println!("x = {}, y = {}", p.x, p.y);
}
fn main() {
let mut a: Point = Point{ x: 10, y: 15 };
Print(a);
// エラー！
println!("x = {}, y = {}", a.x, a.y);
}
Print(a) で1回コピーされているのでその後使うと死にます。ウソでしょ？と思うでしょ？ホントです。
そしてプリミティブ型ならOKと言う Java に似たダブスタの呪いもオマケで付いてます。
おかげさまで関数はほぼ全て明示的に参照渡しをするハメになります。
「だったらデフォルトそうしとけよ！ & をイチイチ書かせんなやワレ！」と思わないのってある種の才能だと思います
Nim所有者・借用なんてもんでイライラしない
Rust には C のポインタが可愛く見えるレベルで高くそびえ立つ鉄壁の初心者ガード、悪夢の"所有者・借用"の概念が存在します。
プログラムに慣れた人間ですら混乱に陥れ、書いている最中に精神力と人生の貴重な時間をガンガン削ってくれる究極の嫌がらせです。
Rust は変数のコピーしちゃうと元のやつが使えなくなるクソ仕様なのです。書き手にメリットなんて一切無い。C++の悪しきメモリ管理の呪いを持ち込んで来てその中でもさらに悪い部分をデフォルトにした感じです。
struct Point {
x: i32,
y: i32,
}
fn Print(p: Point) {
println!("x = {}, y = {}", p.x, p.y);
}
fn main() {
let mut a: Point = Point{ x: 10, y: 15 };
Print(a);
// エラー！
println!("x = {}, y = {}", a.x, a.y);
}
Print(a) で1回コピーされているのでその後使うと死にます。ウソでしょ？と思うでしょ？ホントです。
そしてプリミティブ型ならOKと言う Java に似たダブスタの呪いもオマケで付いてます。
おかげさまで関数はほぼ全て明示的に参照渡しをするハメになります。
「だったらデフォルトそうしとけよ！ & をイチイチ書かせんなやワレ！」と思わないのってある種の才能だと思います
871デフォルトの名無しさん
2021/08/22(日) 02:59:07.86ID:0Cz6ueFz >>862
struct Point {
x: i32,
y: i32,
}
fn Print(p: &Point) {
println!("x = {}, y = {}", p.x, p.y);
}
fn main() {
let mut a: Point = Point{ x: 10, y: 15 };
Print(&a);
println!("x = {}, y = {}", a.x, a.y);
}
これだとまぁエラーにはなりません。が、参照だからといってこんなことやったら死にます。
fn Print(p: &Point) {
println!("x = {}, y = {}", p.x, p.y);
p.x = 10; <- die
}
イミュータブルだからですって。はぁ・・・。
struct Point {
x: i32,
y: i32,
}
fn Print(p: &Point) {
println!("x = {}, y = {}", p.x, p.y);
}
fn main() {
let mut a: Point = Point{ x: 10, y: 15 };
Print(&a);
println!("x = {}, y = {}", a.x, a.y);
}
これだとまぁエラーにはなりません。が、参照だからといってこんなことやったら死にます。
fn Print(p: &Point) {
println!("x = {}, y = {}", p.x, p.y);
p.x = 10; <- die
}
イミュータブルだからですって。はぁ・・・。
872デフォルトの名無しさん
2021/08/22(日) 03:01:25.00ID:0Cz6ueFz >>862
だからこう書けですって。
fn Print(p: &mut Point) {
println!("x = {}, y = {}", p.x, p.y);
p.x = 100;
}
fn main() {
let mut a: Point = Point{ x: 10, y: 15 };
Print(&mut a);
println!("x = {}, y = {}", a.x, a.y);
}
はい来た。mut mut mut mut mut mut mut mut mut ああぁぁああぁ～～～！！！
なんでよく使う方を面倒臭くしたがるんですか、この言語を作っている方々は。
その他又貸しの呪いやらなにやら超盛り沢山ですし。もうね私とはセンスが全く合わないです。
ぬぅぅうぅうぉぉおぉおぁぁあぁあああ！！！！！Rustよ！もうお前には頼まん！malloc と free を俺によこせうぉるぅぁあ！！こんな訳のわからんものに付き合わされるんだったら自分でメモリ管理した方がマシだわ！！！
とよくみんな発狂しませんよね。我慢強いですね。馬鹿じゃないの。
とっても良い子である Nim にはこんな呪いある"ワケ"がないです。
だからこう書けですって。
fn Print(p: &mut Point) {
println!("x = {}, y = {}", p.x, p.y);
p.x = 100;
}
fn main() {
let mut a: Point = Point{ x: 10, y: 15 };
Print(&mut a);
println!("x = {}, y = {}", a.x, a.y);
}
はい来た。mut mut mut mut mut mut mut mut mut ああぁぁああぁ～～～！！！
なんでよく使う方を面倒臭くしたがるんですか、この言語を作っている方々は。
その他又貸しの呪いやらなにやら超盛り沢山ですし。もうね私とはセンスが全く合わないです。
ぬぅぅうぅうぉぉおぉおぁぁあぁあああ！！！！！Rustよ！もうお前には頼まん！malloc と free を俺によこせうぉるぅぁあ！！こんな訳のわからんものに付き合わされるんだったら自分でメモリ管理した方がマシだわ！！！
とよくみんな発狂しませんよね。我慢強いですね。馬鹿じゃないの。
とっても良い子である Nim にはこんな呪いある"ワケ"がないです。
873デフォルトの名無しさん
2021/08/22(日) 03:06:14.74ID:0Cz6ueFz >>862
type Point = object
x: int
y: int
proc print(this: Point) =
echo "x = ", this.x, ", y = ", this.y
var p = Point(x: 10, y: 15)
p.print()
echo "x = ", p.x, ", y = ", p.y
まぁ普通はこうですよね・・・。Rust がぶっ飛んで異常なだけです。ありえないです。
ちなみに Nim の場合 print(p) と p.print() は書き方が違うだけで意味は同じです。
type Point = object
x: int
y: int
proc print(this: Point) =
echo "x = ", this.x, ", y = ", this.y
var p = Point(x: 10, y: 15)
p.print()
echo "x = ", p.x, ", y = ", p.y
まぁ普通はこうですよね・・・。Rust がぶっ飛んで異常なだけです。ありえないです。
ちなみに Nim の場合 print(p) と p.print() は書き方が違うだけで意味は同じです。
874デフォルトの名無しさん
2021/08/22(日) 03:09:40.85ID:0Cz6ueFz >>862
参照で渡す場合はこうなります。
type Point = object
x: int
y: int
proc print(this: ref Point) =
echo "x = ", this.x, ", y = ", this.y
this.x = 100
var p = Point.new
p.x = 10
p.y = 15
p.print()
echo "x = ", p.x, ", y = ", p.y
new で Point object を作成すると参照のオブジェクトが出来ます。これを渡すために print 側の引数には ref をつけてあげます。new 関数でメンバに値を割り当てることは出来ないので後から渡してやります。
つっても上のやつはあくまで Rust と似せて書いたらこうなるよって話でこんな書き方しません。
参照で渡す場合はこうなります。
type Point = object
x: int
y: int
proc print(this: ref Point) =
echo "x = ", this.x, ", y = ", this.y
this.x = 100
var p = Point.new
p.x = 10
p.y = 15
p.print()
echo "x = ", p.x, ", y = ", p.y
new で Point object を作成すると参照のオブジェクトが出来ます。これを渡すために print 側の引数には ref をつけてあげます。new 関数でメンバに値を割り当てることは出来ないので後から渡してやります。
つっても上のやつはあくまで Rust と似せて書いたらこうなるよって話でこんな書き方しません。
875デフォルトの名無しさん
2021/08/22(日) 03:11:53.65ID:0Cz6ueFz >>862
普通オブジェクトなんて参照だろ、って事で Nim では以下のように書くのが慣例化しています。
type
Point = ref PointObj
PointObj = object
x: int
y: int
proc print(this: Point) =
echo "x = ", this.x, ", y = ", this.y
this.x = 100
var p = Point(x: 10, y: 15)
p.print()
echo "x = ", p.x, ", y = ", p.y
オブジェクトとそのリファレンスを同時に定義して、通常使わない方のオブジェクト側にサフィックスをつけておくと、まぁ素のオブジェクトも作りたきゃ作れるし、って話です。
自分は正直リファレンスだけで良いので更に手を抜いてこう書きますけどね。
type
Point = ref object
x: int
y: int
普通オブジェクトなんて参照だろ、って事で Nim では以下のように書くのが慣例化しています。
type
Point = ref PointObj
PointObj = object
x: int
y: int
proc print(this: Point) =
echo "x = ", this.x, ", y = ", this.y
this.x = 100
var p = Point(x: 10, y: 15)
p.print()
echo "x = ", p.x, ", y = ", p.y
オブジェクトとそのリファレンスを同時に定義して、通常使わない方のオブジェクト側にサフィックスをつけておくと、まぁ素のオブジェクトも作りたきゃ作れるし、って話です。
自分は正直リファレンスだけで良いので更に手を抜いてこう書きますけどね。
type
Point = ref object
x: int
y: int
876デフォルトの名無しさん
2021/08/22(日) 03:16:29.28ID:0Cz6ueFz >>862
パターンマッチ？case でしょ？
Nim も case でそれっぽく書けます。
複式パターン
fn main() {
let x = 1;
match x {
1 | 2 => println!("1 | 2"),
3 => println!("3"),
_ => println!("other"),
}
}
let x = 1
case x
of 1, 2: echo "1 | 2"
of 3: echo "3"
else: echo "other"
パターンマッチ？case でしょ？
Nim も case でそれっぽく書けます。
複式パターン
fn main() {
let x = 1;
match x {
1 | 2 => println!("1 | 2"),
3 => println!("3"),
_ => println!("other"),
}
}
let x = 1
case x
of 1, 2: echo "1 | 2"
of 3: echo "3"
else: echo "other"
877デフォルトの名無しさん
2021/08/22(日) 03:20:10.82ID:0Cz6ueFz >>862
範囲
fn main() {
let x = 1;
match x {
1...5 => println!("1...5"),
_ => println!("other"),
};
}
let x = 1
case x
of 1..5: echo "1..5"
else: echo "other"
範囲
fn main() {
let x = 1;
match x {
1...5 => println!("1...5"),
_ => println!("other"),
};
}
let x = 1
case x
of 1..5: echo "1..5"
else: echo "other"
878デフォルトの名無しさん
2021/08/22(日) 03:23:05.87ID:0Cz6ueFz >>862
case の返りを受け取る
fn main() {
let x = 1;
let s = match x {
1 => "one",
2 => "two",
_ => "other",
};
println!("{}", s)
}
let x = 1
let s = case x
of 1: "one"
of 2: "two"
else: "other"
echo s
case の返りを受け取る
fn main() {
let x = 1;
let s = match x {
1 => "one",
2 => "two",
_ => "other",
};
println!("{}", s)
}
let x = 1
let s = case x
of 1: "one"
of 2: "two"
else: "other"
echo s
879デフォルトの名無しさん
2021/08/22(日) 03:24:44.35ID:0Cz6ueFz880デフォルトの名無しさん
2021/08/22(日) 03:26:55.98ID:0Cz6ueFz >>862
仕様バグがない
Rust の以下の挙動は全く理解ができません。
fn main() {
let x = 'x';
let c = 'c';
match c {
// x: c c: c
x => println!("x: {} c: {}", x, c),
}
// x: x
println!("x: {}", x)
}
普通 x にマッチすると思わないでしょこれ。
さらにその直後 x が 'c' に変わってるとか予想だにしませんよ。
まぁ普通はこんな書き方しないと思いますがこんな調子ではどこでどうハマるか予測不可能です恐ろしすぎます。
Nim はこんな書き方そもそも出来ません。
仕様バグがない
Rust の以下の挙動は全く理解ができません。
fn main() {
let x = 'x';
let c = 'c';
match c {
// x: c c: c
x => println!("x: {} c: {}", x, c),
}
// x: x
println!("x: {}", x)
}
普通 x にマッチすると思わないでしょこれ。
さらにその直後 x が 'c' に変わってるとか予想だにしませんよ。
まぁ普通はこんな書き方しないと思いますがこんな調子ではどこでどうハマるか予測不可能です恐ろしすぎます。
Nim はこんな書き方そもそも出来ません。
881デフォルトの名無しさん
2021/08/22(日) 03:31:02.98ID:0Cz6ueFz >>862
コンパイラがケチくさくない
nim c -r hoge
これで hoge.nim をコンパイルします。
拡張子なんて指定する必要ありません。
-r で実行もします。
Rust の場合
rustc hoge <- ダメ
コンパイルと同時に実行しようと思ったら
rustc hoge.rs && ./hoge
うーん・・・
コンパイラがケチくさくない
nim c -r hoge
これで hoge.nim をコンパイルします。
拡張子なんて指定する必要ありません。
-r で実行もします。
Rust の場合
rustc hoge <- ダメ
コンパイルと同時に実行しようと思ったら
rustc hoge.rs && ./hoge
うーん・・・
882デフォルトの名無しさん
2021/08/22(日) 03:36:37.77ID:0Cz6ueFz >>862
実行速度・メモリ使用量・ファイルサイズが小さい
Rust と比べて Nim の実効速度はどっこいかむしろ速いです。
Rust はこんだけイライラする書き方を強制されるにも関わらずたいして速くないとかもう哀れすぎます。
コンパイル後のファイルサイズは話にならないレベルで比べ物になりません。
fizzbuzz の例(FizzBuzz を無駄にベンチマークしてみた By Nim、golang、Rust、Crystal、その他 - 強まっていこう)で言うと
項目 Nim Rust
実行速度 0.37s 0.44s
ファイルサイズ 82K 3.4M
メモリ 356K 900K
こんな感じです。
実行速度・メモリ使用量・ファイルサイズが小さい
Rust と比べて Nim の実効速度はどっこいかむしろ速いです。
Rust はこんだけイライラする書き方を強制されるにも関わらずたいして速くないとかもう哀れすぎます。
コンパイル後のファイルサイズは話にならないレベルで比べ物になりません。
fizzbuzz の例(FizzBuzz を無駄にベンチマークしてみた By Nim、golang、Rust、Crystal、その他 - 強まっていこう)で言うと
項目 Nim Rust
実行速度 0.37s 0.44s
ファイルサイズ 82K 3.4M
メモリ 356K 900K
こんな感じです。
883デフォルトの名無しさん
2021/08/22(日) 03:40:59.41ID:EcXIWh+x >>882
無知がやるとそうなるわな
無知がやるとそうなるわな
884デフォルトの名無しさん
2021/08/22(日) 08:37:49.63ID:0Cz6ueFz >>883
>無知がやるとそうなるわな
バカ丸出し
Nimは標準実装されたnimコンパイラが強力なマクロで
最適化されたCのソースコードを吐き出して、Cコンパイラ
で極小バイナリまで生成するから、コンパイルするだけで
後はプログラマがする仕事が無いので怠けててもいい
Rustは標準実装されたコンパイラでコンパイルするだけでは
超巨大なバイナリを生成するので、最適化せれたチューニング
を施して小さなバイナリを生成しなければならないから
プログラマの仕事が増えて怠けられない
>無知がやるとそうなるわな
バカ丸出し
Nimは標準実装されたnimコンパイラが強力なマクロで
最適化されたCのソースコードを吐き出して、Cコンパイラ
で極小バイナリまで生成するから、コンパイルするだけで
後はプログラマがする仕事が無いので怠けててもいい
Rustは標準実装されたコンパイラでコンパイルするだけでは
超巨大なバイナリを生成するので、最適化せれたチューニング
を施して小さなバイナリを生成しなければならないから
プログラマの仕事が増えて怠けられない
885デフォルトの名無しさん
2021/08/22(日) 08:40:06.97ID:BRNN665g >>884
仕組みすら理解してないのか
仕組みすら理解してないのか
886デフォルトの名無しさん
2021/08/22(日) 08:43:57.27ID:c6eQFYhO887デフォルトの名無しさん
2021/08/22(日) 08:57:00.52ID:QorwbXcj rustスレでnim nim言ってる奴荒らしだろ
888デフォルトの名無しさん
2021/08/22(日) 09:00:12.62ID:0Cz6ueFz >>862
マクロのシンタックスを別で覚える必要がない
Rust のマクロは構文が全く変わってしまいます。
そしてそれは脳が全力で受付を拒否する素敵な仕上がりとなっております。
公式で自ら「マクロベースのコードの欠点は、組み込みルールの少なさに
由来するそのコードの理解のしづらさです。」と言いのけちゃう代物で
「なんじゃそりゃ」と言う言葉しか出ません。
Nim は構文がそのまま使えます。なので強力なマクロを使いこなすための
障壁の低さは比べ物になりません。
マクロのシンタックスを別で覚える必要がない
Rust のマクロは構文が全く変わってしまいます。
そしてそれは脳が全力で受付を拒否する素敵な仕上がりとなっております。
公式で自ら「マクロベースのコードの欠点は、組み込みルールの少なさに
由来するそのコードの理解のしづらさです。」と言いのけちゃう代物で
「なんじゃそりゃ」と言う言葉しか出ません。
Nim は構文がそのまま使えます。なので強力なマクロを使いこなすための
障壁の低さは比べ物になりません。
889デフォルトの名無しさん
2021/08/22(日) 09:19:59.80ID:k4RSCji3 次世代言語22 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1629590343/
https://mevius.5ch.net/test/read.cgi/tech/1629590343/
890デフォルトの名無しさん
2021/08/22(日) 09:21:24.81ID:k4RSCji3891デフォルトの名無しさん
2021/08/22(日) 09:49:19.77ID:sxhQ+hXZ 実際rustって色々リンクするから、最小バイナリでかいよな
でも、それで困ったことってあるか？
俺はない
でも、それで困ったことってあるか？
俺はない
892デフォルトの名無しさん
2021/08/22(日) 09:53:06.17ID:DrnSGK6Q893デフォルトの名無しさん
2021/08/22(日) 10:05:41.39ID:qkR4Cuiq Rustは他に比べれば最小のバイナリでしょ、コンパイラ/リンカーが長い年数を掛けて最適化されたCより大きいが。
一番不満なのが公式はビルドが速いというがそんなに早くない事だけ。それ以外は従来のC/C++（C++17/20/23
なんかを除く)より圧倒的に安全だし、明示的であるからこそタイプ量が多い。
Nimに比べて大きいというのはRustのコンパイラがまだCを吐き出してた頃から最適化されていないから、Nimと
いうかGCCやClangに比べ、ほんの少し大きくなる。リンクするものが大きければバイナリが大きくなるのは
当然でGoなんかはまさにそれでしょ、goroutineを共有ライブラリに押し込めることは出来ないから
一番不満なのが公式はビルドが速いというがそんなに早くない事だけ。それ以外は従来のC/C++（C++17/20/23
なんかを除く)より圧倒的に安全だし、明示的であるからこそタイプ量が多い。
Nimに比べて大きいというのはRustのコンパイラがまだCを吐き出してた頃から最適化されていないから、Nimと
いうかGCCやClangに比べ、ほんの少し大きくなる。リンクするものが大きければバイナリが大きくなるのは
当然でGoなんかはまさにそれでしょ、goroutineを共有ライブラリに押し込めることは出来ないから
894デフォルトの名無しさん
2021/08/22(日) 10:06:16.71ID:sxhQ+hXZ >>892
まあ、ユーザコード自体のサイズがでかいわけじゃないのは同意
まあ、ユーザコード自体のサイズがでかいわけじゃないのは同意
895デフォルトの名無しさん
2021/08/22(日) 10:17:01.78ID:qkR4Cuiq もう１つ不満がある事は、Rustならメモリーリークしないと言う奴がいる事、公式も明言してる通り
グローバルの循環参照を作成してしまえば簡単にリークするのに、意識高い系のコード書かないやつが
メモリーリークしないんだと他の言語も触ったことの無い初心者に力説する事。盛大にリークしてて
正常に動いてるプログラムを直すのは大変・・・
ま、これは言語のせいじゃないけどね、他は凄い良く出来てる、Linuxカーネルに採用されるような
他の言語（第３の言語）は当分出てこないだろうと思うほど
グローバルの循環参照を作成してしまえば簡単にリークするのに、意識高い系のコード書かないやつが
メモリーリークしないんだと他の言語も触ったことの無い初心者に力説する事。盛大にリークしてて
正常に動いてるプログラムを直すのは大変・・・
ま、これは言語のせいじゃないけどね、他は凄い良く出来てる、Linuxカーネルに採用されるような
他の言語（第３の言語）は当分出てこないだろうと思うほど
896デフォルトの名無しさん
2021/08/22(日) 10:35:44.30ID:FTtcJrTl Rustのメモリ安全性は、メモリリークしない、ではないからな。
897デフォルトの名無しさん
2021/08/22(日) 10:40:22.74ID:VB7b1YKz898デフォルトの名無しさん
2021/08/22(日) 10:42:20.85ID:sxhQ+hXZ900デフォルトの名無しさん
2021/08/22(日) 10:54:43.87ID:j+Q/a+4n >>895は分かってる人だろう
ちゃんと読んでるか？
ちゃんと読んでるか？
901デフォルトの名無しさん
2021/08/22(日) 11:49:45.30ID:PExPKGEq ビット全探索する関数作ったヽ(´ー｀)ノ
fn bit_search<T: Copy>(vec: &Vec<T>) -> Vec<Vec<T>> {
let mut tmp_vec: Vec<Vec<T>> = Vec::new();
for i in 0..(1 << vec.len()) {
let mut slist = (0..vec.len())
.filter(|it| i & (1 << it) != 0)
.map(|it| vec[it]).collect();
tmp_vec.push(slist);
}
return tmp_vec;
}
使い方
let vec0 = bit_search(&(0..5).collect());
など
fn bit_search<T: Copy>(vec: &Vec<T>) -> Vec<Vec<T>> {
let mut tmp_vec: Vec<Vec<T>> = Vec::new();
for i in 0..(1 << vec.len()) {
let mut slist = (0..vec.len())
.filter(|it| i & (1 << it) != 0)
.map(|it| vec[it]).collect();
tmp_vec.push(slist);
}
return tmp_vec;
}
使い方
let vec0 = bit_search(&(0..5).collect());
など
902デフォルトの名無しさん
2021/08/22(日) 12:16:08.62ID:0Cz6ueFz >>862
Rust の良いところ
さすがに Rust を批判ばかりしていては公平性に欠ける報道となり官邸から怒られます。
Rust にも良いところはあります。
fn <- 短い！
proc <- 長い！
これはメリットですよ。タイプが2回ずつ減るのは素敵なことです。
しっかしこれだけ馬鹿げた冗長さを押し付けてくる言語のくせして、
何故ここだけすっきりしているのやらさっぱり意味がわからないです。
あ、結局ディスってもうた・・・。
Rust の良いところ
さすがに Rust を批判ばかりしていては公平性に欠ける報道となり官邸から怒られます。
Rust にも良いところはあります。
fn <- 短い！
proc <- 長い！
これはメリットですよ。タイプが2回ずつ減るのは素敵なことです。
しっかしこれだけ馬鹿げた冗長さを押し付けてくる言語のくせして、
何故ここだけすっきりしているのやらさっぱり意味がわからないです。
あ、結局ディスってもうた・・・。
903デフォルトの名無しさん
2021/08/22(日) 12:22:55.13ID:pVXVequb904デフォルトの名無しさん
2021/08/22(日) 12:30:03.84ID:zDmwJZXZ この仕組みを教えて下さい
もしかして2bit＋1byte＝2bytesってこと？
> > Option<Option<T>> has layout [0..1][0..1]<u8> , i.e., be of size 3
>
> False. Thanks to @eddyb’s work, the compiler will collapse the discriminant of the first option into the second. Thus, mem::size_of::<Option<Option<u8>>>() == 2.
もしかして2bit＋1byte＝2bytesってこと？
> > Option<Option<T>> has layout [0..1][0..1]<u8> , i.e., be of size 3
>
> False. Thanks to @eddyb’s work, the compiler will collapse the discriminant of the first option into the second. Thus, mem::size_of::<Option<Option<u8>>>() == 2.
905デフォルトの名無しさん
2021/08/22(日) 12:37:43.49ID:vEK5NNFF >>895
他の言語に比べれば循環参照を作るハードルはかなり高いでしょ
現実的な用途でborrow checkerに引っかからないような循環参照を作って
リーク以外は機能的に問題ないコードを書くのは初心者には難しいと思う
他の言語に比べれば循環参照を作るハードルはかなり高いでしょ
現実的な用途でborrow checkerに引っかからないような循環参照を作って
リーク以外は機能的に問題ないコードを書くのは初心者には難しいと思う
906デフォルトの名無しさん
2021/08/22(日) 12:55:40.93ID:QorwbXcj さすがにマルチポストは荒らし以外の何物でもないな
907デフォルトの名無しさん
2021/08/22(日) 13:03:58.26ID:sxhQ+hXZ >>904
the compiler will collapse the discriminant of the first option into the second.
って言ってるから
Option<Option<u8>>はOption<u8>に変換されるってことじゃない？
the compiler will collapse the discriminant of the first option into the second.
って言ってるから
Option<Option<u8>>はOption<u8>に変換されるってことじゃない？
908デフォルトの名無しさん
2021/08/22(日) 13:18:58.50ID:cSh20jP2909デフォルトの名無しさん
2021/08/22(日) 13:46:33.46ID:j+Q/a+4n >>904
Optionで9回包んでもsizeは2のままだったのでそういうわけではなさそう
None, Some(_), Some(Some(_)) の3バリアントがあるのと同じようなレイアウトになる模様
↓はOption<Option<Option<u8>>>の例
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=31c195fa7390041e3a2d7ce9ff1417f2
Optionで9回包んでもsizeは2のままだったのでそういうわけではなさそう
None, Some(_), Some(Some(_)) の3バリアントがあるのと同じようなレイアウトになる模様
↓はOption<Option<Option<u8>>>の例
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=31c195fa7390041e3a2d7ce9ff1417f2
910デフォルトの名無しさん
2021/08/22(日) 14:20:53.63ID:sxhQ+hXZ 909のコードを借りて確かめてみたら
<Option<Option<Option<u8>>>>(&Some(Some(None)));
と<Option<u8>>(&Some(None))が
<Option<Option<Option<u8>>>>(&Some(Some(Some(0))));
と<Option<u8>>(&Some(0))が同じ結果になったよ
1byte目が00の場合None、00以外の場合Some
<Option<Option<Option<u8>>>>(&Some(None))みたいに
OptionとSomeのレイヤの数が違うと1byte目の結果が違うみたい
1byte目でどのレイヤのSome/Noneか区別してるのかな
<Option<Option<Option<u8>>>>(&Some(Some(None)));
と<Option<u8>>(&Some(None))が
<Option<Option<Option<u8>>>>(&Some(Some(Some(0))));
と<Option<u8>>(&Some(0))が同じ結果になったよ
1byte目が00の場合None、00以外の場合Some
<Option<Option<Option<u8>>>>(&Some(None))みたいに
OptionとSomeのレイヤの数が違うと1byte目の結果が違うみたい
1byte目でどのレイヤのSome/Noneか区別してるのかな
911デフォルトの名無しさん
2021/08/22(日) 14:35:04.66ID:vEK5NNFF [0..=3]<u8>になってるね
nightlyで#[rustc_layout(…)]を使うと確認できる
#![feature(rustc_attrs)]
#[rustc_layout(abi, size, debug)]
type Foo = Option<Option<Option<u8>>>;
nightlyで#[rustc_layout(…)]を使うと確認できる
#![feature(rustc_attrs)]
#[rustc_layout(abi, size, debug)]
type Foo = Option<Option<Option<u8>>>;
912デフォルトの名無しさん
2021/08/22(日) 15:31:41.81ID:PExPKGEq Itertoolsが便利すぎて今までの自分が可愛そうすぎる(´･ω･`)
913デフォルトの名無しさん
2021/08/22(日) 17:33:05.93ID:0Cz6ueFz >>862
技術書典に出会っていなかったら俺はNimをさわってないと思う
背景
俺たち「そろそろ技術書典に参戦するか」
俺たち「何書く？」
俺たち「マイナー言語を触ってみよう。言語選択は早い者勝ちね」
ワイ「(マイナーの定義はさておき)Nimでオナシャス」
ワイ「(アドカレあるし、記事まとめておくかぁ...)」
Nimとは？
Nim は アンドレアス・ランプフ氏によって設計・開発された命令型、マルチパラダイム、
コンパイル言語という特徴を持つプログラミング言語です。
アンドレアス・ランプフ氏は3DICC社に所属するエンジニアです。彼はNim開発以前に様々
な言語を触っていたようです。が、どの言語も満足せず、自身で作成することにしたようです。
それがNimプロジェクトの始まりで、2005年頃のようでした。
当初NiｍはNimrod(旧約聖書の登場人物)という名前でしたが、マーケティング上の理由から
2014年12月29日にリリースされたバージョン 0.10.2 からNimに変更されました。
技術書典に出会っていなかったら俺はNimをさわってないと思う
背景
俺たち「そろそろ技術書典に参戦するか」
俺たち「何書く？」
俺たち「マイナー言語を触ってみよう。言語選択は早い者勝ちね」
ワイ「(マイナーの定義はさておき)Nimでオナシャス」
ワイ「(アドカレあるし、記事まとめておくかぁ...)」
Nimとは？
Nim は アンドレアス・ランプフ氏によって設計・開発された命令型、マルチパラダイム、
コンパイル言語という特徴を持つプログラミング言語です。
アンドレアス・ランプフ氏は3DICC社に所属するエンジニアです。彼はNim開発以前に様々
な言語を触っていたようです。が、どの言語も満足せず、自身で作成することにしたようです。
それがNimプロジェクトの始まりで、2005年頃のようでした。
当初NiｍはNimrod(旧約聖書の登場人物)という名前でしたが、マーケティング上の理由から
2014年12月29日にリリースされたバージョン 0.10.2 からNimに変更されました。
914デフォルトの名無しさん
2021/08/22(日) 18:20:04.94ID:qHvaNpwK 結局rustもC++を遥かに超える型地獄なんだな
915デフォルトの名無しさん
2021/08/22(日) 18:47:16.61ID:eu6eNh6V こんだけ型がっちがちに固められた言語触っちゃったら他の言語に戻れない
PythonとかPythonとか
PythonとかPythonとか
916デフォルトの名無しさん
2021/08/22(日) 19:10:19.80ID:E7wqFzW/ 型地獄って何？
917デフォルトの名無しさん
2021/08/22(日) 19:11:44.78ID:CqI7brJQ 二度と出られぬかーたーじーごーくーーー
918デフォルトの名無しさん
2021/08/22(日) 19:15:51.20ID:+34cYDX+ 実行時にバグるよりコンパイルエラーでコンパイル出来ない方が遥かに優れていると思ってるけど, そう思わないと型が辛くなるだろうなぁ
919デフォルトの名無しさん
2021/08/22(日) 19:27:07.94ID:PExPKGEq JavaScriptで組んでたときに、文字の数字を数値型に変換したくて、
"10" + 0
みたいにしてたことを思い出した
"10" + 0
みたいにしてたことを思い出した
920デフォルトの名無しさん
2021/08/22(日) 20:28:11.75ID:O/1WEaVf C++でしんどいの型の部分じゃないけどな
921デフォルトの名無しさん
2021/08/22(日) 20:45:47.91ID:JES5Vdct >>919
JSようしらんけどこれって"100"にならないんだ？
JSようしらんけどこれって"100"にならないんだ？
922デフォルトの名無しさん
2021/08/22(日) 21:02:27.49ID:0Cz6ueFz >>862
Nimの特徴
直感的でわかりやすいシンタックス
公式サイトの記載からNimの特徴を見てみましょう。
以下は公式サイトに掲載されているNimのコード例です。
Nimの最初の特徴して挙げられているのが、そのシンタックスで、曰く「直感的でわかりやすい」とのことです。
Python(のインデントを含めた多くの特徴)やPascalを参考にしているらしいので似ていると思いますが、シンプルですね。
import strformat
type
Person = object
name*: string # Field is exported using `*`.
age: Natural # Natural type ensures the age is positive.
var people = [
Person(name: "John", age: 45),
Person(name: "Kate", age: 30)
]
for person in people:
# Type-safe string interpolation.
echo(fmt"{person.name} is {person.age} years old")
Nimの特徴
直感的でわかりやすいシンタックス
公式サイトの記載からNimの特徴を見てみましょう。
以下は公式サイトに掲載されているNimのコード例です。
Nimの最初の特徴して挙げられているのが、そのシンタックスで、曰く「直感的でわかりやすい」とのことです。
Python(のインデントを含めた多くの特徴)やPascalを参考にしているらしいので似ていると思いますが、シンプルですね。
import strformat
type
Person = object
name*: string # Field is exported using `*`.
age: Natural # Natural type ensures the age is positive.
var people = [
Person(name: "John", age: 45),
Person(name: "Kate", age: 30)
]
for person in people:
# Type-safe string interpolation.
echo(fmt"{person.name} is {person.age} years old")
923デフォルトの名無しさん
2021/08/22(日) 21:06:05.83ID:0Cz6ueFz >>862
Nimの特徴
直感的でわかりやすいシンタックス
公式サイトの記載からNimの特徴を見てみましょう。
以下は公式サイトに掲載されているNimのコード例です。
Nimの最初の特徴して挙げられているのが、そのシンタックスで、曰く「直感的でわかりやすい」とのことです。
Python(のインデントを含めた多くの特徴)やPascalを参考にしているらしいので似ていると思いますが、シンプルですね。
import strformat
type
Person = object
name*: string # Field is exported using `*`.
age: Natural # Natural type ensures the age is positive.
var people = [
Person(name: "John", age: 45),
Person(name: "Kate", age: 30)
]
for person in people:
# Type-safe string interpolation.
echo(fmt"{person.name} is {person.age} years old")
Nimの特徴
直感的でわかりやすいシンタックス
公式サイトの記載からNimの特徴を見てみましょう。
以下は公式サイトに掲載されているNimのコード例です。
Nimの最初の特徴して挙げられているのが、そのシンタックスで、曰く「直感的でわかりやすい」とのことです。
Python(のインデントを含めた多くの特徴)やPascalを参考にしているらしいので似ていると思いますが、シンプルですね。
import strformat
type
Person = object
name*: string # Field is exported using `*`.
age: Natural # Natural type ensures the age is positive.
var people = [
Person(name: "John", age: 45),
Person(name: "Kate", age: 30)
]
for person in people:
# Type-safe string interpolation.
echo(fmt"{person.name} is {person.age} years old")
924デフォルトの名無しさん
2021/08/22(日) 22:37:49.54ID:Wmq9vv9f RustにはGCないから云々言われるけどメモリ以外のリソースもRAIIとムーブセマンティクスの力でいい感じに扱えるのは良いよね
他の言語だと with 式などでスコープ抜けたら解放は出来るけど
クロージャにキャプチャされる場合など長時間生き残るようなケースをちゃんと扱えたりするのだろうか
他の言語だと with 式などでスコープ抜けたら解放は出来るけど
クロージャにキャプチャされる場合など長時間生き残るようなケースをちゃんと扱えたりするのだろうか
925デフォルトの名無しさん
2021/08/23(月) 00:06:22.12ID:q1PbYAS3 >>921
"100"になるよ
"100"になるよ
926デフォルトの名無しさん
2021/08/23(月) 00:25:43.80ID:WImWpxqb >>898
JavaはグローバルのGCがあるから意味が違うよ。リークしているように見えるがプログラムが正常に
終了をすればGCが起こる（だからJavaは停止時にフリーズしたようになるプログラムが多数）
>>905
ハードルは高くないよ。循環参照をWeak<T>でなくRc<T>で書いてしまえば普通にリークする
リファレンスカウントになっているのだから当たり前だけどね
https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html
JavaはグローバルのGCがあるから意味が違うよ。リークしているように見えるがプログラムが正常に
終了をすればGCが起こる（だからJavaは停止時にフリーズしたようになるプログラムが多数）
>>905
ハードルは高くないよ。循環参照をWeak<T>でなくRc<T>で書いてしまえば普通にリークする
リファレンスカウントになっているのだから当たり前だけどね
https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html
927デフォルトの名無しさん
2021/08/23(月) 01:03:20.75ID:LyXSTYiq GC言語にも弱参照はあるのでまともなプログラマーならば強循環参照は作らない
RustはGCが無しでメモリ安全性を保証できる言語であるとともにメモリリークも避けることができる言語
RustはGCが無しでメモリ安全性を保証できる言語であるとともにメモリリークも避けることができる言語
928デフォルトの名無しさん
2021/08/23(月) 01:18:03.41ID:9dmEVPj+ GCは強循環参照も問題なく回収できるんだよ
929デフォルトの名無しさん
2021/08/23(月) 01:30:55.93ID:gt/OOSS+ >>928
GCは方式の異なる段階があって
弱参照を使う循環参照なら強参照カウンタだけで回収できる
強参照のみの循環参照までも回収する方式は様々あるけどいずれも重い
だからGC言語にも弱参照があって賢い配慮あるプログラマーが使えるようになっている
GCは方式の異なる段階があって
弱参照を使う循環参照なら強参照カウンタだけで回収できる
強参照のみの循環参照までも回収する方式は様々あるけどいずれも重い
だからGC言語にも弱参照があって賢い配慮あるプログラマーが使えるようになっている
930デフォルトの名無しさん
2021/08/23(月) 02:08:47.17ID:mUiDivSN >>926
その日本語訳に書いてる通り
「循環参照は簡単にできることではありませんが、不可能というわけでもありません。 Rc<T>値を含むRefCell<T>値があるなどの内部可変性と参照カウントのある型がネストして組み合わさっていたら、 循環していないことを保証しなければなりません;」
RefCell<Rc<T>>を使いこなせるのに循環参照で盛大にリークさせる人も
Rc<T>をWeak<T>に直すのが大変っていう人も
かなりの激レアさんだと思う(個人の感想)
その日本語訳に書いてる通り
「循環参照は簡単にできることではありませんが、不可能というわけでもありません。 Rc<T>値を含むRefCell<T>値があるなどの内部可変性と参照カウントのある型がネストして組み合わさっていたら、 循環していないことを保証しなければなりません;」
RefCell<Rc<T>>を使いこなせるのに循環参照で盛大にリークさせる人も
Rc<T>をWeak<T>に直すのが大変っていう人も
かなりの激レアさんだと思う(個人の感想)
931デフォルトの名無しさん
2021/08/23(月) 08:54:29.06ID:7vUkULmy >>929
誤り
GC言語の弱参照は強循環参照対策ではなく、キャッシュなどで長寿命のオブジェクトがGCを妨げることを避ける目的で使用される
だから例えば、ウインドウはボタンを管理しボタンは自身がクリックされたことをウインドウに通知する、ただしボタンが動的に追加削除されることはない、
といったような互いに寿命が一致する循環参照が生じるケースでは弱参照は普通使用しない
マークアンドスイープは十分に高速なので、参照カウンタをGCと併用するのはあまり一般的ではない
誤り
GC言語の弱参照は強循環参照対策ではなく、キャッシュなどで長寿命のオブジェクトがGCを妨げることを避ける目的で使用される
だから例えば、ウインドウはボタンを管理しボタンは自身がクリックされたことをウインドウに通知する、ただしボタンが動的に追加削除されることはない、
といったような互いに寿命が一致する循環参照が生じるケースでは弱参照は普通使用しない
マークアンドスイープは十分に高速なので、参照カウンタをGCと併用するのはあまり一般的ではない
932デフォルトの名無しさん
2021/08/23(月) 08:57:57.29ID:ksTslrDC ネストしたstructの奥深いところにひっそりRcが隠れてたら
知らない間に循環参照になってることもあるかもしれない
知らない間に循環参照になってることもあるかもしれない
933931
2021/08/23(月) 09:17:05.48ID:7vUkULmy 念のため補足しておくが、寿命が一致しない循環参照の場合は弱参照を使わなければならないというわけではない
ウインドウとボタンの例でいうと、普通に考えてボタンが動的に削除されようとしていることをウインドウが知らないわけないから、そのタイミングでウインドウが持つボタンへの参照を削除すればいいだけだ
GC言語で弱参照が必要とされるのは極めて特殊なケースに限られており、ほとんど使用されることはない
ウインドウとボタンの例でいうと、普通に考えてボタンが動的に削除されようとしていることをウインドウが知らないわけないから、そのタイミングでウインドウが持つボタンへの参照を削除すればいいだけだ
GC言語で弱参照が必要とされるのは極めて特殊なケースに限られており、ほとんど使用されることはない
934デフォルトの名無しさん
2021/08/23(月) 09:53:29.91ID:IzWPiInz >>933
特殊なケースではないと思う
GC言語でも何らかのツリー構造をあつかうことはよくあって
その時に親から子へは普通に強参照でも子から親へは弱参照の方が有利だよね
弱参照を使っていれば一部のサブツリーを捨てた時に循環参照ではなくなる
これはGC言語だけではなくRustでも同様で、サブツリーを捨てたらそのトップへの強参照が消えて連鎖的にサブツリーが回収されますよね？
特殊なケースではないと思う
GC言語でも何らかのツリー構造をあつかうことはよくあって
その時に親から子へは普通に強参照でも子から親へは弱参照の方が有利だよね
弱参照を使っていれば一部のサブツリーを捨てた時に循環参照ではなくなる
これはGC言語だけではなくRustでも同様で、サブツリーを捨てたらそのトップへの強参照が消えて連鎖的にサブツリーが回収されますよね？
935デフォルトの名無しさん
2021/08/23(月) 10:15:02.98ID:6chE64yn936デフォルトの名無しさん
2021/08/23(月) 10:25:19.17ID:9/DhhYFq937デフォルトの名無しさん
2021/08/23(月) 10:28:37.19ID:6chE64yn ちなみにGC言語は常に強参照を使うことを前提に最適化されているので、必要もないのに弱参照を多用すると確実に遅くなるよ
Javaだと弱参照それ自体がヒープアロケーションされるオブジェクトだったりするので、とんでもなく非効率だ
Javaだと弱参照それ自体がヒープアロケーションされるオブジェクトだったりするので、とんでもなく非効率だ
938デフォルトの名無しさん
2021/08/23(月) 10:36:03.26ID:ZbJNhF7k >>937
Rustでは弱参照を使うデメリットありますか？
Rustでは弱参照を使うデメリットありますか？
939デフォルトの名無しさん
2021/08/23(月) 10:50:20.08ID:6chE64yn940デフォルトの名無しさん
2021/08/23(月) 11:23:41.21ID:XXiZs56E これまでRust書いている時にトレーシングGCが欲しくなったことはありますか？
それはどのようなプログラムを書いている時ですか？
それはどのようなプログラムを書いている時ですか？
941デフォルトの名無しさん
2021/08/23(月) 11:40:32.83ID:ueMbvV/8942デフォルトの名無しさん
2021/08/23(月) 13:03:00.15ID:mUiDivSN PythonやSwiftの自動参照カウント方式はGCとは呼ばない派がいるんだね
Rustの場合は弱参照を使うかどうかに関わらず
生存期間を常に意識してコーディングする必要がある
どちらを弱参照にすべきかは所有権を考えれば明白
Rustの場合は弱参照を使うかどうかに関わらず
生存期間を常に意識してコーディングする必要がある
どちらを弱参照にすべきかは所有権を考えれば明白
943デフォルトの名無しさん
2021/08/23(月) 13:26:39.80ID:gvYYeNdp C++ スレでスマートポインタが GC かどうかという話題が出たことあるわ。
そこで現れた GC の定義としては大まかに
① 十分に信頼してメモリ管理をまかせることが出来る能力がある
② メモリ管理を意識することなく利用できる
のいずれか (または両方) が上げられていて、
その上で信頼性の程度、意識するというのがどの程度のことを言うのかで
様々な線引きがある感じだった。
たとえば①については参照カウンタだと循環を解決できないが、
それはエッジケースでしかなくてたいした問題じゃないと考えるか
そうでないかは人によるが、いずれにしてもまかせるに足る能力で
考えるという考え方。
②についてはメモリ管理を自動化する能力ではなく見せ方の問題だとする派閥。
スマートポインタは管理方法も管理内容も決まっていて
プログラマがそれを利用するという明示が含まれるので GC ではないという考え方もあるし、
管理の開始こそ明示的な宣言ではあるものの
直接的な管理は隠されているので GC だという主張もある。
どちらに線を引くかは異論があるにせよ、プログラマの側からどう「見えるか」という
抽象度の問題とする考え方。
そこで現れた GC の定義としては大まかに
① 十分に信頼してメモリ管理をまかせることが出来る能力がある
② メモリ管理を意識することなく利用できる
のいずれか (または両方) が上げられていて、
その上で信頼性の程度、意識するというのがどの程度のことを言うのかで
様々な線引きがある感じだった。
たとえば①については参照カウンタだと循環を解決できないが、
それはエッジケースでしかなくてたいした問題じゃないと考えるか
そうでないかは人によるが、いずれにしてもまかせるに足る能力で
考えるという考え方。
②についてはメモリ管理を自動化する能力ではなく見せ方の問題だとする派閥。
スマートポインタは管理方法も管理内容も決まっていて
プログラマがそれを利用するという明示が含まれるので GC ではないという考え方もあるし、
管理の開始こそ明示的な宣言ではあるものの
直接的な管理は隠されているので GC だという主張もある。
どちらに線を引くかは異論があるにせよ、プログラマの側からどう「見えるか」という
抽象度の問題とする考え方。
944デフォルトの名無しさん
2021/08/23(月) 13:46:29.34ID:VyqoTEns >>943
違うよ
GCの定義は明白で
「ガベージが生じて溜まっていってそれらをまとめてコレクションすること」
だからRustで例えばノードツリーのトップが何らか任意の方法でドロップとなった時
連鎖的にツリー全体が次々とRcの強参照カウント0となりツリー全体が解放されるのはGCではない
即座に消えてガベージは溜まって行ってないため
違うよ
GCの定義は明白で
「ガベージが生じて溜まっていってそれらをまとめてコレクションすること」
だからRustで例えばノードツリーのトップが何らか任意の方法でドロップとなった時
連鎖的にツリー全体が次々とRcの強参照カウント0となりツリー全体が解放されるのはGCではない
即座に消えてガベージは溜まって行ってないため
945デフォルトの名無しさん
2021/08/23(月) 14:21:58.28ID:cpmwRu6w946デフォルトの名無しさん
2021/08/23(月) 14:28:20.76ID:cpmwRu6w あ、すまん。LISPはマークアンドスイープで、その後に参照カウントが発明されてるわ。
947デフォルトの名無しさん
2021/08/23(月) 14:53:47.52ID:HA74v0pt >>945
参照カウント方式か否かは焦点ではなくて、ゴミがたまっていってまとめて処理することをgarbage collectionと呼ぶ。
RustのRc利用はゴミがたまっていかないのでGCと呼ばれていない。
参照カウント方式か否かは焦点ではなくて、ゴミがたまっていってまとめて処理することをgarbage collectionと呼ぶ。
RustのRc利用はゴミがたまっていかないのでGCと呼ばれていない。
948デフォルトの名無しさん
2021/08/23(月) 15:46:33.74ID:a+6ajIdY >>944
「溜まっていってそれらをまとめて」というのは間違いだな。
wikipediaの記載にある
「不要になった（メモリ）領域を自動的に解放する機能」
というのが正しい。
ポイントは「不要と判断」して「解放」というところ。溜まる必要もまとめて解放する必要も無い。
「溜まっていってそれらをまとめて」というのは間違いだな。
wikipediaの記載にある
「不要になった（メモリ）領域を自動的に解放する機能」
というのが正しい。
ポイントは「不要と判断」して「解放」というところ。溜まる必要もまとめて解放する必要も無い。
レス数が900を超えています。1000を超えると表示できなくなるよ。
ニュース
- 【速報】中国、水産物輸入停止と通達 「処理水」理由、日本政府へ ★5 [おっさん友の会★]
- 高市首相答弁を“引き出した”立民・岡田克也氏が改めて説明「なぜ慎重な答弁をされなかったのか。非常に残念に思っている」 [ぐれ★]
- 中国側が首相答弁の撤回要求、日本側拒否★7 [夜のけいちゃん★]
- NHK会長 新語・流行語大賞ノミネート「オールドメディア」に反論「言われる筋合いはない」「新しいメディアだと思っている」 [muffin★]
- 【速報】 米大使「はっきりさせておこう、米国は尖閣諸島含め日本の防衛に全面コミット、中国がどうしようが変わらない」 [お断り★]
- 自民、経済対策で子ども1人に2万円給付へ 児童手当に上乗せ 所要額は約4000億円 [ぐれ★]
- ネトウヨ首長を選んだ結果、日本に損害与える。白浜のネトウヨパンダ町長と同じ構図か!?😲 [521921834]
- 【速報】高市首相「つい言い過ぎた」 存立危機事態の答弁について [237216734]
- 【速報】中国、水産物輸入停止★2 [989870298]
- 【ネトウヨ悲報】基地内で女性をレイプした基地外米兵「記憶がない」 [834922174]
- 高市総理「あなた、やるんでしょ？あのね、稼いでね。稼げるようにしてね。稼がなきゃだめよ、稼ぐのよ！じゃあ、あとよろしく(ｶﾞﾁｬﾝ」 [256556981]
- 山上妹「統一信者から安倍自民への投票を求められた」法廷で証言 [947332727]