21/08/17 21:03:40.91 iE5VyQYC.net
>>647
上３つの式は正しいのに、なんで下２つの式はそうなるのか
701:デフォルトの名無しさん
21/08/17 21:04:44.45 iE5VyQYC.net
>>687
見間違えた
一番下の式だけだね
702:デフォルトの名無しさん
21/08/17 21:18:21.30 sY2NwSu8.net
実際はc++わからんけどrustわかればマウント取れそうじゃね？って馬鹿しか手を出してないという現実。
703:デフォルトの名無しさん
21/08/17 21:24:14.87 hwU1GG4D.net
Rustは、GoogleTrendsでは他の言語に比べて低空飛行だけど(Kotlinと同じくらい
ではあるが)、他の言語が下がる傾向があるのに対してRustだけは少しずつ上がってる。
Stackoverflowでは既にC++の30%～40%位まで質問の量が迫ってきているとか。
なので良く分からない。
GoogleTrendsが実際と合ってないという説も見かけた。
704:デフォルトの名無しさん
21/08/17 21:26:37.22 hwU1GG4D.net
crates.ioでcrateをダウンロードされた回数が20億回を越えていたり、
投稿されたcrateの数が3万種類を超えたりとか。
20億回というのはとんでもない大きな数字。
全世界のプログラマの数は2,500万人くらいだそうだから相当な数だ。
良く分からないくらい異常に大きな数値。
705:デフォルトの名無しさん
21/08/17 21:35:56.30 hYkkAkQv.net
iocrateはきっと誰かがwhile true do; cargo build; cargo clean;doneみたいの流し続けたんだろ
c++よりマシなのは確かだがredosだかみたいの全然進まんしc++,cな代替物にはなれなさそう
tech giantsみたいな連中が根幹部分rustに変えるみたいな事言ってるけど流行ってる感じ全然しないよね(´・ω・｀)
706:デフォルトの名無しさん
21/08/17 21:40:50.24 jTG+Bjsl.net
久しぶりに流行ってない流行らないアピールきてるね
707:デフォルトの名無しさん
21/08/17 21:41:43.37 LO76a4+c.net
土方では流行らないでしょ
708:デフォルトの名無しさん
21/08/17 21:45:28.03 yac5fWyQ.net
リポジトリの分散化考えないとマジ負荷が半端無さそう
709:デフォルトの名無しさん
21/08/17 21:49:53.88 fMgDzJWA.net
rustで作ったライブラリは他の言語から使いやすいんかい？
c\c++置き換えるなら、むしろそここそ一番重要かもしれん。
710:デフォルトの名無しさん
21/08/17 22:12:04.05 53TH2cCY.net
>>696
Rustのライブラリは他言語からは使いにくいのが問題になっていると聞いたが。
多分、C/C++のライブラリのようにはいかないと思う。
711:デフォルトの名無しさん
21/08/17 22:14:00.60 53TH2cCY.net
>>692
前半、なるほど。
githubで最高人気であるところのvue.jsも、いいねは2万くらいだったと思うし。
なんか数値に異常さを感じる。
712:デフォルトの名無しさん
21/08/17 22:16:21.15 53TH2cCY.net
vue.jsのgithubでのStar数は、18万7,000だった。
crate.ioのダウンロード回数はこの1万倍を越えている。
普通に使っているだけでは辻褄が合いそうに無いな。
全世界の全てのプログラマが100回くらいcrateをダウンロードしたことになる。
713:デフォルトの名無しさん
21/08/17 22:54:36.64 Ok9gkDKS.net
crates.ioのDL数と比較すべきはnpmのDL数では？
URLﾘﾝｸ(www.npmtrends.com)
714:デフォルトの名無しさん
21/08/18 00:15:56.99 24ORvnDg.net
crates.ioのダウンロード数は依存crateのCIが走る度に増えるようなものだからそりゃ多くなるでしょ
GitHubのstarと比較したのはなぜ？
715:デフォルトの名無しさん
21/08/18 00:33:37.55 c7Y+RcIr.net
別にプログラマが手動でダウンロードするわけではないんだが…
1回コンパイルすると100個以上落としてくるのも普通だから
2千万回コンパイルが実行された、という程度の話
ざっくり5年で均せば1日1万回ってとこか
716:デフォルトの名無しさん
21/08/18 01:06:03.53 WOvB8ChX.net
CIだろうね。人がcargoを直に打ってるとは思えん
717:デフォルトの名無しさん
21/08/18 01:16:27.76 wcIqldgw.net
強力にキャッシュが効くはずのCIでツールが未整備なために効かず
異常にDL数が伸びてしまっただけだろう
718:デフォルトの名無しさん
21/08/18 04:35:06.87 AXrkZvXQ.net
CIのライブラリインストールが動画の次に無駄な帯域を食ってると言われているだけある
719:デフォルトの名無しさん
21/08/18 09:18:01.26 k0LDI8WO.net
>>639
難しく考えすぎ
&と*の関係は単純明白
let a = 123; // a: i32
let b = a; // b: i32
let p = &b; // p: &i32
let q = p; // q: &i32
let &r = &p; // r: &i32
let x = &q; // x: &&i32
let s = *x; // s: &i32
let c = *r; // c: i32
let y = &&c // y: &&i32
let z = y; // z: &&i32
let d = **z; // d: i32
720:デフォルトの名無しさん
21/08/18 09:35:44.42 GD93l4al.net
ライブラリが他言語から使いにくいってのも謎だな
他言語からならC ABI一択なわけで、どの言語でライブラリ書こうが使い勝手は同じだと思うが
721:デフォルトの名無しさん
21/08/18 09:48:19.81 JVjfL7Fa.net
>>697
例えばPyO3でPythonからRust呼び出せるよ
722:デフォルトの名無しさん
21/08/18 10:49:15.04 NS5B/B7Q.net
>>672
自動的な参照外し(*を記載してないのに*適用)って、値を使うところで&Tや&&Tなどが使われたときにTの値になる、というルールだからそれも数学的でしょ。
あと&Tではない各種スマートポインタや自作の型を、*記載で参照外しする時も、Derefトレイト実装通りに行われるからこれも数学的。
723:デフォルトの名無しさん
21/08/18 11:27:15.93 k0LDI8WO.net
>>647氏が混乱したのもそこかもね
例えば
let a = 99;
let b = &a;
assert_eq!(100, b + 1);
assert_eq!(100, *b + 1);
つまり値を使う所では参照のままではなく安全に*が自動適用
構造体のフィールドアクセスも
struct Point {x: i32, y: i32}
let p = Point {x: 19, y: 31};
let q = &p;
assert_eq!(p.x, q.x);
assert_eq!(p.y, (*q).y);
つまりフィールドアクセスする所では参照のままではなく安全に*が自動適用
だからC言語などにある「q->y」という記法がRustには不要なので存在しない
724:デフォルトの名無しさん
21/08/18 11:41:08.71 XfIyaV62.net
こじつけの自己レス自演が気持ち悪い
これでバレないとおもってるんだからww
お前も頑張って勉強中なの丸出しなのになぜそんなに上から目線で書きたがる？
725:デフォルトの名無しさん
21/08/18 12:12:05.22 cmZsMbhP.net
>>710
assert_eq!(100, b + 1); は通るけど
assert_eq!(99, b); はコンパイルエラーになるところがミソかな
726:デフォルトの名無しさん
21/08/18 12:12:56.84 Lbl25gGI.net
演算子も含めてメソッド呼出しのときの self の参照が調整されるのは言語コアの機能だけど
演算子の右辺で参照が剥がされるのは参照を受け取るバージョンのメソッドも用意されてるから
という理解でいいんだよね？
727:デフォルトの名無しさん
21/08/18 12:16:13.67 UTiWVDvk.net
>>710
>assert_eq!(100, b + 1);
`b + 1`のbは*が自動適用されてるわけじゃない
728:デフォルトの名無しさん
21/08/18 12:52:27.85 KGSse8GZ.net
そこはstd::ops::Addトレイトのimplがあるかどうか
ただしi32と&i32に対してはあるけど&&i32に対してはない
そのためさきほどの例だと
let a = 99;
let c = &&a;
assert_eq!(100, **c + 1); // i32はそのままOK
assert_eq!(100, *c + 1); // &i32は参照外してi32でOK
assert_eq!(100, c + 1); // &&i32のAddトレイト定義はないからコンパイルエラー
729:デフォルトの名無しさん
21/08/18 13:56:40.85 XmrgRQmj.net
繰り返し間違った内容垂れ流すのいい加減やめれ
730:デフォルトの名無しさん
21/08/18 14:02:16.47 NAGfODce.net
>>715で合ってるよ
731:デフォルトの名無しさん
21/08/18 14:42:37.07 tdn9Bdbv.net
ご愁傷様
732:デフォルトの名無しさん
21/08/18 15:05:20.49 PR0UGd3d.net
ご安全に*
733:デフォルトの名無しさん
21/08/18 19:37:59.33 e8CK2aK/.net
質問したようなのと近い流れになってて助かった
(0..7).filter(|&x| x == 0);
↑これ通るから ↓こうしたら駄目だった。なんでなん？
let mut vec0 = vec![1, 2, 3, 4, 5, 6];
vec0.iter().filter(|&x| x == 1);
そこで、様々テストしたら、↓の方法でコンパイルが通ることがわかった
どのやり方が一般的なん？個人的には1か4かと思うんだけど。あと、2は+0することで型推論が働いてるのん？
vec0.iter().filter(|&x| *x == 1); //1
vec0.iter().filter(|&x| x + 0 == 1); //2
vec0.iter().filter(|&x| x == &1); //3
vec0.iter().filter(|&x| x.clone() == 1); //4
vec0.iter().filter(|x| **x == 1); //5
vec0.iter().filter(|x| *x == &1); //6
734:デフォルトの名無しさん
21/08/18 19:43:27.81 4IMEZtM2.net
全部結果まで含めて正しかった？
735:デフォルトの名無しさん
21/08/18 19:48:58.01 e8CK2aK/.net
ベクタの内容を↓にして
let mut vec0 = vec![1, 2, 1, 4, 1, 6];
1の数をcountするようにして表示させてみたけど、>>720の1～6のやり方でどれもcountの数は同じだね
736:デフォルトの名無しさん
21/08/18 20:01:07.37 e8CK2aK/.net
いいぞ！いいぞ！これも通るぞ！！
let mut test6 = vec0.iter().filter(|&&x| x == 1).count();
let mut test7 = vec0.iter().filter(|x| x == &&1).count();
let mut test8 = vec0.iter().filter(|x| *x + 0 == 1).count();
ヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノ
737:デフォルトの名無しさん
21/08/18 20:03:48.63 gDWYR9GO.net
Bible終えるのにどれぐらい時間かかりましたか？
738:デフォルトの名無しさん
21/08/18 20:30:38.07 4eCzRIG7.net
>>720
739: (0..7).filter(|&x| x == 0);と同等なのは let v = vec![1,2,3,4,5,6]; v.into_iter().filter(|&x| x==0);
740:デフォルトの名無しさん
21/08/18 20:47:56.15 e8CK2aK/.net
>>725
うおー、まじか！
わかったありがとう。だからforループはちょっと違う挙動になるんだな
741:デフォルトの名無しさん
21/08/18 21:38:07.08 KGSse8GZ.net
違いをわかりやすく示すと
let vec0 = vec![1, 2, 3, 4, 5, 6];
assert_eq!(Some(&1), vec0.iter().next());
assert_eq!(Some(1), vec0.into_iter().next());
742:デフォルトの名無しさん
21/08/18 21:41:22.71 e8CK2aK/.net
ありがとうありがとう
&TのイテレータとTのイテレータが別々になっているとはおもわなんだ
743:デフォルトの名無しさん
21/08/18 21:54:22.03 8n3xPETQ.net
まだ慣れてないからideに言われるがままに直してるな、、
744:デフォルトの名無しさん
21/08/18 22:38:04.93 ErZJGc/A.net
イテレータ回りはこのスライドが良いと思ったけど多少基礎知識ないときついかもしれんな
URLﾘﾝｸ(speakerdeck.com)
745:デフォルトの名無しさん
21/08/18 23:13:44.45 KGSse8GZ.net
>>728
そう考えるよりもムーブor借用と捉えるほうがいいかな
vec0.into_iter()だとムーブになるから値そのものが次々と来る。しかしその後にvec0は使えない。
vec0.iter()だと借用になるから値への参照が次々と来る。その後もvec0は使える。
(&vec0).into_iter()でも借用になるから値への参照が次々と来る。その後もvec0は使える。
746:デフォルトの名無しさん
21/08/19 02:05:43.13 58T7qCMn.net
この2つは何が違うんですか？
演算子?
URLﾘﾝｸ(tourofrust.com)
unwrap
URLﾘﾝｸ(tourofrust.com)
747:はちみつ餃子
21/08/19 02:52:20.85 z/GAGLjl.net
>>732
これは例がよくないな。
もう一段ほど関数呼出しを挟む構造になっていればより分かり易くなる気がする。
? 演算子はエラーだったときにそのエラー値を返り値として return する。
つまりその例の場合は do_something_that_might_fail が
エラー値を返したときは main から抜ける。
関数がエラーを出したときに上位にもエラーとして伝播させる機能。
unwrap は Result を剥がすが、エラー値だったときにはその場で panic する。
unwrap を書くというのは「エラー値が返されることはないことをプログラマとして保証する」
または「そのエラーに対して対処する方法はない、対処する気はない」という表明で、
assert 的な意味合いを含む。
エラーの対処を書くのが面倒だけど Result を剥がして型は合わせないといけない
というときに雑に unwrap することはあるんだけど、
多少なりとも汎用的なライブラリにするなら (事前条件が正しい限り) panic が
起こるのは好ましくはないので使い方は慎重に。
748:デフォルトの名無しさん
21/08/19 03:04:22.69 KOsZ1Iay.net
>>732
?演算子はほぼtry!マクロのsyntax sugar
言語自体に組み込んだ時にその適用範囲を広げた
try!マクロとは見やすく省略して書くと
Result型rに対してはtry!(r)がほぼmatch r { Ok(n) => n, Err(e) => return Err(e) }となる
つまり?演算子はOption型やResult型の尻につけてNoneやErrの時にreturnする
一方でunwrapはpanicして死ぬ
749:デフォルトの名無しさん
21/08/19 06:51:23.03 3IqCrn23.net
ほぉ、なるへそ
noneとかへの振る舞いの遅延行為としての?op
ある関数を呼んだ関数自体でerrへの振る舞い決定すべきだと考えた場合は?opにする
とすると?op含んだ関数のcallerはmatchとかのタイプ別振る舞い定義をちょっとやかましめ書く必要ありだな
いまいちpanicの振る舞いが分からん
spawned threadが内部でパニくった場合その娘、息子スレッド（スレッドの下層スレッド）とそのスレッド自体にのみunwindが適用されるんだよな？(´・ω・｀)
750:デフォルトの名無しさん
21/08/19 08:14:51.20 1vsNr98D.net
何でやねん(笑)
751:デフォルトの名無しさん
21/08/19 12:31:22.21 vGJ7k9jZ.net
vec0.iter().filter(|&x| x == &1);
これの数字に&つけて型同じにしたら通るってのが納得できないな～
比較がプリミティブ型の変数同士だったら自動的に数値として扱って欲しい
752:デフォルトの名無しさん
21/08/19 13:09:24.52 5RRw/fpd.net
>>737
それは強い静的型付けのメリット
異なる型同士の==が通るのは困る
といいたいところだけど
PartialEqトレイト次第で異なる型でも==してくれる場合もある
文字列など
でも整数は厳密でi32とi16ですら不許可
753:デフォルトの名無しさん
21/08/19 13:34:53.71 vGJ7k9jZ.net
>>738
でも、上の例で
vec0.iter().filter(|&x| x + 0 == 1);
が通るのは+0したときに中身がプリミティブ型だから数値だけ取り出してくれてるんでそ？
754:デフォルトの名無しさん
21/08/19 13:41:52.67 NIu45PdU.net
>>739
それはまた別で>>715
つまり足し算の実装
755:デフォルトの名無しさん
21/08/19 14:53:02.41 qnkUxlpG.net
&i32 + i32 の計算ができるようAddトレイトで実装されていて、結果をi32で返すようになってるからエラーにならないってことでしょ？
756:デフォルトの名無しさん
21/08/19 14:59:15.22 OmSSsNQv.net
>>741
そのとぉーり！
757:デフォルトの名無しさん
21/08/19 15:34:51.11 SriMwJau.net
>>741
ご丁寧にi32+i32 i32+&i32 &i32+i32 &i32+&i32の4種類をカバーしてくれてるね
&&i32はサポートしていないため
vec0.iter().filter(|x| x+1==2)はコンパイルエラー
758:デフォルトの名無しさん
21/08/19 16:37:43.70 gHMNbMrQ.net
まず>>715の間違いを反省しようね
>let a = 99;
>let c = &&a;
>assert_eq!(100, *c + 1); // &i32は参照外してi32でOK
759:デフォルトの名無しさん
21/08/19 16:44:47.80 hQY8lbBV.net
>>744
それであってるぜ
&i32+i32は左だけ参照を外してi32にして足し算する
760:デフォルトの名無しさん
21/08/19 17:44:32.43 t/I60tUF.net
そりゃ当たり前だろw
とことんダメなやつだな
761:デフォルトの名無しさん
21/08/19 18:58:02.70 58T7qCMn.net
>>733
>>734
丁寧に教えてくれて、ほんとありがとう
762:デフォルトの名無しさん
21/08/19 21:41:29.08 vGJ7k9jZ.net
>>743
なるほど、なんかすべての挙動を把握しないとならないんだね
でも、やっぱり「&1」が通用するのは納得いかない(´･ω･`)
763:デフォルトの名無しさん
21/08/19 22:05:30.35 RF3Q0l8Y.net
>>748
基本的には正しく型を用いれば済む
&i32は数値ではなく数値への参照にすぎない
*付けなくても済む便宜の恩恵を受けるのはよいけどそれを理解したうえでしているかどうかの違い
764:デフォルトの名無しさん
21/08/19 22:29:20.97 c562wt5h.net
String と &str が == で比較できるなら i32 と &i32 も比較できて良い気はする
単に impl がないだけだから pull req 送ったら取り込んで貰えるのでは
765:デフォルトの名無しさん
21/08/19 22:55:59.39 vGJ7k9jZ.net
もう純粋に&1て、1の参照じゃんね
その意味がわからんし、存在意義がわからん
変数同士ならわかるけど、定数的に書いてるんだったらもうプリミティブ型だったら
中身で判断してくれよヽ(`Д´)ﾉｳﾜｧｧｧﾝ
766:デフォルトの名無しさん
21/08/19 23:28:13.13 2mmZi2HD.net
>>750
今もi32と&i32の組み合わせ4通り定義
そこへ&&i32が加わると9通り定義
そこまでする意義は？
>>751
だからx==&1ではなくて素直に*x==1と書こう
767:デフォルトの名無しさん
21/08/19 23:48:19.67 k/U3ouxt.net
>>751
プリミティブのwrapper crateを作って自分の好きなように定義すれば万事解決
768:デフォルトの名無しさん
21/08/19 23:58:39.37 A1SUdzrU
769:.net
770:デフォルトの名無しさん
21/08/20 00:03:22.90 o+L+NM8T.net
推奨する方法をやりやすく、推奨しない方法をやりにくく
Rustは他の言語に比べると特に後者についてよく考えられてる
771:デフォルトの名無しさん
21/08/20 00:07:53.98 iQK+FWFq.net
>>754
postgresクレートのquery()でparamsに数字を書きたいときとか
pub fn query<T>(&mut self, query: &T, params: &[&(dyn ToSql + Sync)]) -> Result<Vec<Row>, Error>
where
T: ?Sized + ToStatement
772:デフォルトの名無しさん
21/08/20 01:09:30.92 W7hoDzmL.net
>>752
*x == 1 と書けというのは分かるんだけど
impl PartialEq<String> for &str や impl Add<&i32> for i32 があるのに
impl PartialEq<&i32> for i32がないのは一貫性がないように思う
なんで実装されていないのだろうか
773:デフォルトの名無しさん
21/08/20 01:11:40.00 W7hoDzmL.net
>>757
自己解決
RFC1332で議論されていた
774:デフォルトの名無しさん
21/08/20 01:12:10.07 hEbF/PXF.net
rubyもpythonも見よう見まねで書けるんだけどなー
javaなんてC++とほとんど同じだから半日もあればマスターできる
でもrustだけは勉強しないと無理っぽい
難しいよ
775:デフォルトの名無しさん
21/08/20 01:34:49.41 qcewwL/9.net
>>757
実は整数と文字列ではそこの逆転現象が起きていて
Stringと&strの等号比較はOK
assert!("xyz".to_string() == "xyz")
しかしStringをmatch文でアームに&strだとコンパイル型エラーでNG
// assert!(match "xyz".to_string() { "xyz" => true, _ => false, });
&i32とi32の等号比較はコンパイル型エラーでNG
// assert!(&123 == 123);
しかし&i32をmatch文でアームにi32だと比較OK
assert!(match &123 { 123 => true, _ => false, });
776:デフォルトの名無しさん
21/08/20 01:38:48.16 omEK/Sui.net
オブジェクトの同一性 (メモリ上の同一の場所に配置されている) を判定したいときって
参照を == で比較しても駄目ですよね？
ポインタを取り出すのも恰好が悪いように思うんですが、
なんか定番の方法ってあります？
777:デフォルトの名無しさん
21/08/20 01:44:35.28 qcewwL/9.net
>>754
消費(ムーブ)せずに参照で済ませるためにiter()を使うと当然 &1 が出てくる
let vec0 = vec![1, 2, 3, 4, 5, 6];
assert_eq!(Some(&1), vec0.iter().next());
assert_eq!(Some(1), vec0.into_iter().next());
これはVecだから消費するinto_iter()が使えば 1 に出来るけど
スライスだと消費という概念がないから必ず &1 が出てきてしまう
778:デフォルトの名無しさん
21/08/20 01:55:55.02 jENR+46K.net
>>761
Rustは所有権があるから同一メモリを指すのは所有権を持つものへの参照同士かな
つまりコード上明白であり比較する必要性がないことに？
779:デフォルトの名無しさん
21/08/20 02:30:09.57 qcewwL/9.net
こういうことかな
複数の参照もmut参照も生ポインタも当然すべて同じアドレスを指している
let mut i = 123;
let pi1 = &i;
let pi2 = &i;
println!("{:p}", pi1); // 0x7fffebf915a4
println!("{:p}", pi2); // 0x7fffebf915a4
let pi3 = &mut i;
println!("{:p}", pi3); // 0x7fffebf915a4
let rpi3r = pi3 as *mut i32; // 生ポインタ
println!("{:p}", rpi3); // 0x7fffebf915a4
生ポインタを使って書き換えると元の変数が書き換わるので確かにこれは変数の格納アドレス
unsafe {
println!("{}", *rpi3); // 123
*rpi3 = 456;
}
println!("{}", i); // 456
780:デフォルトの名無しさん
21/08/20 02:32:13.12 0J8On0UY.net
ptr::eqで
781:デフォルトの名無しさん
21/08/20 10:16:46.67 Z3M3k8Ob.net
メンテナンス性最悪の自己満足オナニー言語
782:デフォルトの名無しさん
21/08/20 11:41:07.99 0Iuc7w1s.net
>>766
それは逆
メンテナンス性は最も優れているプログラミング言語の一つ
783:デフォルトの名無しさん
21/08/20 13:42:55.60 ZqTwz4dI.net
ポインタ関連の問題が所有権と参照で絶対に発生しないってのはデカイよね
784:デフォルトの名無しさん
21/08/20 13:59:09.33 lR6AxyIv.net
将来の苦痛を先に解消できるのが良いのにな、不具合も絞り込みやすい
メンテナンス性悪いってどの辺言ってんのか聞いてみたい
785:デフォルトの名無しさん
21/08/20 14:18:54.33 nkJxp5PO.net
一年ぶりに触るソースを大規模改修しても、コンパイル通せばほぼ動く安心感ある
他言語（特に動的型言語）だと相当テストを作り込まない限り、このメンテナンス性は得られない印象
786:デフォルトの名無しさん
21/08/20 14:28:37.40 y1HLeTwS.net
データ設計を少し考えさせられることによって
メモリ安全性を得ただけでなく見通しも良くなったｗ
787:デフォルトの名無しさん
21/08/20 15:07:52.58 No4kn/Ah.net
潜在的にバグの原因となる変数の扱いすると
コンパイラが怒るのは安心できる
788:デフォルトの名無しさん
21/08/20 15:24:51.42 W7hoDzmL.net
>>768
絶対に発生しないは言い過ぎ
789:デフォルトの名無しさん
21/08/20 15:31:54.88 sJeXN42B.net
繰り返しでiter()を使ったりinto_iter()を使ったり、ループを使ったり、高階を使ったり。。
そして文字列が複数あったり、更にそれをマクロにされると、それで書き直しが必要だったり
多くの言語でも初心者と上級者で当然、コードの美麗さに違いが出るが余りにも差があり過ぎ
たった「一年ぶり」でコンパイルが通らない言語なんてあるだろうけど、そんな話じゃない
790:デフォルトの名無しさん
21/08/20 16:06:16.17 c/gVhnyt.net
イテレータなんてどの言語にもあるし困るようなことか？
無理やり導入で汚い言語よりもRustは綺麗に洗練されていて書きやすい
791:デフォルトの名無しさん
21/08/20 16:12:21.41 BL1Grv4c.net
同じようなことなのに人によって書き方が全然違うからクソって言いたいんじゃないの？
792:デフォルトの名無しさん
21/08/20 17:10:02.79 H8grjHSU.net
何が何故問題なのか説明できないイチャモンなんかほっとけ
793:デフォルトの名無しさん
21/08/20 20:06:41.30 W7hoDzmL.net
文字列が複数種類あることが嬉しい人のための言語
嬉しくない人は別の言語を使うべき
794:デフォルトの名無しさん
21/08/20 20:28:27.92 TearUC8B.net
>>778
例えばいわゆるスクリプト言語などはいずれもRustのString型相当のものしかないため非効率でメモリ食い散らかす状態になっていますね
Rustはそれに加えて部分を指し示すだけの文字列スライス&str型を持っているので無駄なアロケーションを防いで効率の良いコードを書けるようになっていますね
795:デフォルトの名無しさん
21/08/20 21:05:31.52 ma1oO0u7.net
>>774
> 繰り返しでiter()を使ったりinto_iter()を使ったり、ループを使ったり、高階を使ったり。
あなたはちょっと無知すぎます。
まず高階関数とも言われるmap()やfilter()等を用いるにはイテレータが必須ですから同じことを指しています。
どちらかを選ぶようなものではありません。
次にRustのforループもイテレータ必須で内部でイテレータを作ってforループを回していますから同じことです。
forループ方式と高階関数方式の2種類で書けてしまうじゃないか！と言いたいのでしょうが、これは他のプログラミング言語でも同じで2種類あります。
796:デフォルトの名無しさん
21/08/20 21:07:42.14 EDzGRqES.net
内包表記なる書き方がある言語もあるらしいねｗ
797:デフォルトの名無しさん
21/08/20 21:38:29.08 6XnQ3Oqv.net
繰り返しでiter()を使ったりinto_iter()を使ったりと複数のやり方があるのはおかしいとの御指摘だが
into_iter()は値のイテレータ
iter()は参照のイテレータ
同じものに対して適用しても別のイテレータが得られる
798:デフォルトの名無しさん
21/08/20 21:47:24.73 pKmgqbo7.net
少し前までは荒らし以外は結構いいスレだったが
近頃はC++スレでダベってた暇人たちが引っ越して来ちゃってゴミスレ化しつつあるね
799:デフォルトの名無しさん
21/08/20 22:24:24.81 ZqTwz4dI.net
>>782
これ、同じメソッドにするのではなくて、イテレータにするのはiter()で共通にして、
参照する場合には、別のメソッドにしたほうがいいんじゃないのかなと思う
例えば
iter() ← 値
iter().ref() ← 参照
とか
800:デフォルトの名無しさん
21/08/20 22:50:20.88 hEbF/PXF.net
なんで配列にイテレータないんや！
配列を使うな！ vecを使えということなのか
そういえばC++でもvector使えとか言われてたな
もっと配列にも愛を！
ところでvecより配列の方がうれしいことってある？
実は配列いらない子なんじゃないかと思い始めた
801:デフォルトの名無しさん
21/08/20 23:02:42.83 Dd/EBaxX.net
>>784
それはiterのシグネチャがメソッドチェーンするかどうかで変わってしまうから
今のRustの型システムでは表現不能だと思う
プログラマ視点でも、後続する関数呼び出しがその手前に影響するってのはかなりわかりにくいのでは？
802:デフォルトの名無しさん
21/08/20 23:22:41.88 tipMusVW.net
>>785
スタックとかヒープとかアロケーションとか気にならない用途ならRust使わなくてもいいと思うの
803:デフォルトの名無しさん
21/08/20 23:47:01.90 Omw4vOgK.net
>>786
moveをデフォルトにするのは無理だけど
iter()は参照でiter().into()で値ならCow的なのでなんとかなる気がする
804:デフォルトの名無しさん
21/08/20 23:47:19.51 iQK+FWFq.net
>>785
> Rust 1.53からは配列型に対して直接IntoIteratorトレイトが実装されるようになり、配列をそのままループに使うことが出来るようになりました。
URLﾘﾝｸ(tech-blog.optim.co.jp)
805:デフォルトの名無しさん
21/08/20 23:54:51.56 hEbF/PXF.net
>>787
いやいや、もちろん配列との比較なんだから、アロケーションの発生しない処理の話だよ
スタックを気にするなら、むしろヒープに置いた方がいいし
(キャッシュミスヒットの話じゃなくて、スタックオーバーフローの話ね)
806:デフォルトの名無しさん
21/08/20 23:55:03.84 Dd/EBaxX.net
>>788
それだとinto_iterとは意味変わっちゃってるのでは
intoで元のコレクションのコピーが作られて、それをイテレートするってことでしょ？
コピーを作らず所有権を奪って値をイテレートする方法がなくなってしまう
807:デフォルトの名無しさん
21/08/20 23:56:59.11 hEbF/PXF.net
>>789
おお！ 知らなかった。
ってかめっちゃ最近じゃん！
追いかけるの大変だな
808:デフォルトの名無しさん
21/08/21 01:58:33.16 kcBD0DB/.net
>>784
iter().cloned() とか使えば良いのでは
809:デフォルトの名無しさん
21/08/21 05:48:08.14 lXSuJ2vU.net
hoge.iter()だと参照でhoge.iter().fuga()だとhogeの所有権ぶんどる、みたいなのは無理な気がする
810:デフォルトの名無しさん
21/08/21 06:24:06.23 kvS3AY0X.net
>>790
Vecは可変長なので必ずヒープからアロケーションが発生します
一方で配列は必ず固定長でスタックに置かれます
>>784
(&vec0).into_iter()はvec0.iter()となるので
into_iter()だけにすることも出来なくはないと思いますが
書き方が面倒なので簡潔なiter()と共存してるのだと思います
811:デフォルトの名無しさん
21/08/21 09:34:58.66 v7gED8U+.net
>>791
Cow使えばできるという話じゃないよ
lazyに所有権を取得するような機能を持った型を追加すれば
今の型システムでも表現できないってことはないんじゃないかって話
そういう型を追加することを型システムの変更と言うのであれば
今の型システムでは表現できないてのに同意するよ
812:デフォルトの名無しさん
21/08/21 09:43:26.29 KTz5aeQ/.net
>>795
アロケーションが発生するのは伸長するときだけでしょ
伸長するような用途だったら、そもそも配列使えないし
>一方で配列は必ず固定長でスタックに置かれます
だめじゃん。スタックオーバーフロー考慮するならvecの方がいいじゃん
まあ、自分も組み込み以外でスタックフレームのサイズなんて考慮したことないけど
813:デフォルトの名無しさん
21/08/21 09:50:40.59 KTz5aeQ/.net
>>795
ちなみにスタックにあることによってL2キャッシュに載りやすいだろ！
という意見ならそれは同意する。サイズが小さければね。
814:デフォルトの名無しさん
21/08/21 10:08:08.47 /0ZvMIRv.net
>>797
> アロケーションが発生するのは伸長するときだけでしょ
いいえ。
Vecの実体は必ずヒープにアロケーションされます。
Vec自体は(指定しなければ)スタック上で、ヒープへのポインタや長さなどで構成されて固定長です。
Stringも内部はVec<u8>なので同様です。
815:デフォルトの名無しさん
21/08/21 10:12:53.88 KTz5aeQ/.net
>>799
ああ、アロケーションじゃなくてヒープにってところを問題視してる？
ガベージコレクションの発生を懸念してる？
816:デフォルトの名無しさん
21/08/21 10:22:22.66 HwKH2mPW.net
>>800
Rustではガベージコレクションは起きない
しかしスタック上かヒープ上かの区別は重要
スタック上のデータはその関数を終える時に消滅する
817:デフォルトの名無しさん
21/08/21 10:31:43.28 KTz5aeQ/.net
>>801
>Rustではガベージコレクションは起きない
ヒープを使ってるんだから起きないわけないだろ
＞スタック上のデータはその関数を終える時に消滅する
Vecの中身だって関数を終えるときに解放されるでしょ
されないんだっけ？
そもそもの話は配列を使ってるところをVecにしても問題なくね？ってことなんだけど
どこが問題になるかの例を示してもらえたら、わかりやすい
818:デフォルトの名無しさん
21/08/21 10:58:14.92 Hi//C77Q.net
rustにはガベージコレクションがないんだぜ・・・
819:デフォルトの名無しさん
21/08/21 11:04:35.75 eqU3IJp1.net
デストラクタ的な機構で後始末するのはガベージコレクションとは普通言わない
820:デフォルトの名無しさん
21/08/21 11:09:11.24 JLDZmydZ.net
Cでもひーぷをつかうとがべーじこれくしょんがおきるの？
821:デフォルトの名無しさん
21/08/21 11:11:34.22 6mCMrQuL.net
ヒープへのメモリアロケーションはコストが高いから避けたいんでしょ
822:デフォルトの名無しさん
21/08/21 11:25:28.41 ozkLLafu.net
>>802
RustにGCはない
Vecの中身(配列相当部分)はスタック上ではなくヒープ上なので関数を終えるときに解放されない
Vec自体が消える時に解放される
Vec自体(ポインタと長さなど)はスタック上にあれば関数を終える時に消える
もちろんVec自体を関数の返り値として返すことは出来る
受け取った上位の関数でVecの中身を使える
例えば
fn main() {
let mut v: Vec<i32> = make_i32_vec_from_args();
v.push(999);
println!("{:?}", v);
}
fn make_i32_vec_from_args() -> Vec<i32> {
let mut v = Vec::new();
std::env::args().skip(1).map(|s| s.parse::<i32>().unwrap()).for_each(|n| v.push(n));
v
}
$ cargo run 111 222 333
[111, 222, 333, 999]
823:デフォルトの名無しさん
21/08/21 11:42:53.96 3jqa2oM2.net
そういや何でalloca()無いの？
824:デフォルトの名無しさん
21/08/21 12:23:12.36 kcBD0DB/.net
>>795
Box<[T; N]> のように配列がヒープに置かれる場合もある
825:デフォルトの名無しさん
21/08/21 12:35:23.13 5zDPvhJy.net
>>809
それはBoxだからであって、そんなこと言い出したら整数だってヒープに置かれうる
しかし普通に「整数型はスタックに置かれる」と言われる時は、Boxを使わない場合を意味している
Boxを使えばヒープに置かれるのは自明だからだ
したがって、整数や配列やVecの管理データ部分はそのままだとスタックに置かれるがVecのデータ実体は常にヒープに置かれる、で良い
826:デフォルトの名無しさん
21/08/21 13:25:00.39 KTz5aeQ/.net
うーん、なんだかなー
みんなヒープのことを無限にバイトを吐き出す魔法の箱かなんかだと思ってない？
>>805
>Cでもひーぷをつかうとがべーじこれくしょんがおきるの？
当然
Cのmalloc/freeやC++のnew/deleteでもガベージコレクションは発生する
wikipediaの「ヒープ領域」がよくまとってるよ
いくつかの理由からfree/deleteのガベージコレクションはJavaやC#のガベージコレクションよりも超高速だ
それでも、組み込みの世界ではガベージコレクションのせいでリアルタイム性が失われることを嫌がって、
ヒープを使わなかったりする
じゃあ、組み込みでは動的なメモリをどうするかっていうと、リンクドリストのノードをメモリブロックに
見立てて、メモリ管理システムにしたりする
これだと取得も解放も定数時間のコストだからね
>>807
すまん、例をみてますます配列なくても困らない気がしてきた
配列でできて、Vecにできないことはないの？
827:デフォルトの名無しさん
21/08/21 13:35:03.05 +9L1DmAB.net
>>811
Rustにはガベージコレクションはありません
おっしゃる通りヒープからの取得も解放も定数時間のコストで行なわれ更にガベージが溜まることはありません
Rustでは生存期間や所有権に貸し借りが明白になっているため、使用中のものが解放されたり、解放済みが使われたり、使用済みが解放されなかったりは起きません
828:デフォルトの名無しさん
21/08/21 13:50:09.86 KTz5aeQ/.net
>>812
>ヒープからの取得も解放も定数時間のコストで行なわれ
これってどういう原理？ 本当に定数ならそれもうヒープじゃないんじゃ
ヒープツリーを辿る処理も未使用ノードを結合する処理も定数時間って
ありえないと思うんだけど
829:デフォルトの名無しさん
21/08/21 14:16:15.10 G8x/1s0B.net
もしかしてmalloc/freeのヒープメモリ管理のことをこの人はガベージコレクションと呼んでいるのかも
そのためRustにガベージコレクションがないことを理解できていないような感じ？
830:デフォルトの名無しさん
21/08/21 14:22:08.01 KTz5aeQ/.net
調べた
・rustのヒープはフリーリストアロケータじゃない
（サイズごとのメモリスラブをさらに分割して使う）
・取得・解放は定数時間じゃない
(メモリスラブ全体が未使用になったときに、デフラグして別サイズのスラブとして利用可能になる)
→これ実質ガベージコレクション処理じゃん
・当然デフラグは発生するが、大して問題にならない
→そうだろうね。C++でさえアロケータ書いたことない
・問題になるならアロケータを自作することも可能(デフォルトはjemalloc)
だそうだ。
ヒープはヒープ構造じゃないのか……
831:デフォルトの名無しさん
21/08/21 14:36:21.13 KTz5aeQ/.net
>>814
>もしかしてmalloc/freeのヒープメモリ管理のことをこの人はガベージコレクションと呼んでいるのかも
freeの中にもガベージコレクション処理があるんだよという話
javaと違ってマーク＆スイープ処理いらないから早いけどね
>そのためRustにガベージコレクションがないことを理解できていないような感じ？
そんなことはわかってる
今は処理コストの話をしてる
サイズが変わらないVecと配列(配列なのでもちろん固定長)でそこまで優位の差があるのかと訊いた
そこでVecはヒープを使う(からダメだ)という答えが返ってきたので、
ヒープを使うとなぜダメなんだ？ ガベージコレクションのオーバーヘッドを気にしてるのか？と
そうするとrustはガベージコレクションありませんと言われた
じゃあ、結局のところヒープを使うとなぜダメなんだ？
832:デフォルトの名無しさん
21/08/21 14:43:58.08 3jqa2oM2.net
勝手に定義した「ガベージコレクション」なんか議論するだけ時間の無駄
833:デフォルトの名無しさん
21/08/21 14:48:02.99 HlQuVij0.net
>>816
あなたが完全に間違っている
それを世間ではガベージコレクションとは呼ばない
834:デフォルトの名無しさん
21/08/21 14:50:34.09 KTz5aeQ/.net
>>818
辞書が絶対とは言いたくないがwikipediaの「ヒープ領域」見て
835:デフォルトの名無しさん
21/08/21 14:52:48.65 Hi//C77Q.net
自分でfreeしたものをGCと呼ぶとは強者が現れたな
836:デフォルトの名無しさん
21/08/21 14:53:06.41 O7+p4qIy.net
それこそwikipediaの「ガベージコレクション」見てもらった方がいいのでは。
837:デフォルトの名無しさん
21/08/21 14:53:37.02 6mCMrQuL.net
もうジェマロクはデフォルトじゃないよ
838:デフォルトの名無しさん
21/08/21 14:58:27.12 Hi//C77Q.net
そういやこんな記事があったよ
実装言語を「Go」から「Rust」に変更、ゲーマー向けチャットアプリ「Discord」の課題とは
URLﾘﾝｸ(atmarkit.itmedia.co.jp)
> 平均すれば高速に動作していたものの、数分ごとに平均応答時間が急に大きくなり、
> ユーザーエクスペリエンスを損なっていた。調査したところ、
> これはGoの中核機能であるメモリモデルとガベージコレクタ（GC）に起因することが分かった。
> Rustではガベージコレクションが不要だ。
> 同社がRead StatesサービスをRustで実装しようと考えたのはこれが理由だ。
> Rustを使えば、Goで実装した場合に生じた平均応答時間の急増は見られないだろう。
839:デフォルトの名無しさん
21/08/21 15:02:21.85 KTz5aeQ/.net
>>820
だから、ここではコストの話をしてるんだって言ってんのに
>>821
見た。もちろん知ってる。
本題からずれてる。自動解放とかデフラグの定義の話がしたいんじゃない
配列とVecのことが知りたいんだって
なんだってこう話を逸らすんだ？
840:デフォルトの名無しさん
21/08/21 15:02:56.01 watXYiN6.net
>>819
URLﾘﾝｸ(ja.wikipedia.org)
> 7月15日（土）12:22の版で記述いただいた内容のうち、「ガベージコレクション」という部分だけ誤りと思われるので、7月19日（水）02:32の版で消させていただきました
せやな。
841:デフォルトの名無しさん
21/08/21 15:10:24.32 hSZ/tOwO.net
>>824
まずはプログラミング言語におけるガベージコレクションとは何かを理解して
次にRustではそのガベージコレクションがないことを理解して
その上で何を質問したいのかを整理してはいかがでしょうか？
それを終えてからでないとあなただけ用語の定義が異なったままでは話が進みません
842:デフォルトの名無しさん
21/08/21 15:10:57.04 IZ1Oj5x4.net
ガベコレは普通javaとかpyのコンパイラやらインタプリタがreference counterをオブジェクトに勝手に付随させる事を想定するけどな
Vec arr処理コストの違いに関してはbuffer使わないんだからarrayの方が基本的には糞みたいに早いと思うがな
そこらosとかによって最適化図られるからオブジェクト生成のとき以外は決定的な違いあんまなさそうだが
要素数をコンパイルタイムに決定(これのアルゴにもよるが)出来るなら普通はシンプル配列の方が速いよね
goはparallel threadingみたいな部分で変なgc実装してて大量に独立の計算量ハード問題導入するからねそこらへんがドイヒーなんだろうな
俺は好きだけど(´・ω・｀)
843:デフォルトの名無しさん
21/08/21 16:18:04.16 iwjgeVKb.net
>>824
何度も説明されている通り
配列は固定長なのでデータ管理部分はなく配列は通常スタック上
Vecは可変長なのでデータ管理部分がありそれは通常スタック上そして配列相当部分は常にヒープ上
844:デフォルトの名無しさん
21/08/21 16:29:59.01 0b1Dm8dh.net
コンパクションとガベージコレクションの区別がついてない
世の中のガベージコレクターがコンパクションもやってるからといって
コンパクションのみを指してガベージコレクションとは呼ばない
845:デフォルトの名無しさん
21/08/21 16:33:27.85 Ay6lvOn8.net
ふりだしに戻る >>787
846:デフォルトの名無しさん
21/08/21 16:37:39.49 KTz5aeQ/.net
>>828
それの何が問題？
stringの実装はヒープだけど問題ないよね？
こういう使い方をすると配列より100倍くらい遅いとか、メモリリークするからVec止めて配列使えとか
そういう注意点ある？
もちろんループの中でVec::newするとオーバーヘッドでかいとか、
そういうわざとらしいのはなしにして
あえていうなら初期化の記述量がちょっと増える、とか？
847:デフォルトの名無しさん
21/08/21 16:59:15.86 dJkGQ7Qm.net
>>831
誰も何も問題にしていませんよ
あなたが勘違いをして勝手な何かを問題にしているだけ
StringはVecにstructの皮を被せただけなので状況は同じ
848:デフォルトの名無しさん
21/08/21 17:06:03.36 Hi//C77Q.net
>>829
HDDの頃はよく使ってたHDD最適化と容量を増やすみたいなソフトを思い出した
HDDのデフラグ → メモリコンパクション
HDDにある不要なキャッシュの削除 → ガベージコレクション
こんな感じに似てるな
849:デフォルトの名無しさん
21/08/21 17:16:16.64 eqU3IJp1.net
ヒープがヒープ構造じゃないのかとか言ってるから本当に何も知らなかったのだろう
オレオレ用語使われると混乱するからとりあえずmalloc動画くらいみて勉強してきてほしい
850:デフォルトの名無しさん
21/08/21 17:26:30.08 KTz5aeQ/.net
>>834
そこ話の本筋じゃないんだよなー
Vecはヒープ使ってるからダメって言われて、何がダメか説明してくれって言ってるだけなんだけどなー
851:デフォルトの名無しさん
21/08/21 17:30:07.73 pF+sRbnf.net
>>835
ヒープ使ってるからダメ、なんて誰も言っていない
全ては君の勘違い
852:デフォルトの名無しさん
21/08/21 17:31:33.62 KTz5aeQ/.net
>>836
そうなの？ じゃあ結論として配列はVecに置き換えても問題ないってこと？
853:デフォルトの名無しさん
21/08/21 17:52:04.92 eqU3IJp1.net
Vecは固定長配列(型[u8; 32]とかで表されるやつ)を置き換える用途としては使えないが, 逆に言えばそれだけ
854:デフォルトの名無しさん
21/08/21 18:26:53.45 Hi//C77Q.net
むしろ配列なんてクレート使わないとコンパイル時点で数値が決まってないと使えないから
ほとんど出番がないんだから、どこに悩む必要があるというのか
855:デフォルトの名無しさん
21/08/21 18:30:22.30 AgJApIsV.net
>>835
＞Vecはヒープ使ってるからダメって言われて、何がダメか説明してくれって言ってるだけなんだけどなー
あなたの妄想ではないですか？
スレを読みましたが、
Vecはヒープ使ってるからダメと言われた書き込みが見当たりません。
856:デフォルトの名無しさん
21/08/21 18:31:04.95 3jqa2oM2.net
ヒープは悪であるということをハッキリと言う
857:デフォルトの名無しさん
21/08/21 18:41:19.82 tswurJ+7.net
Linux のデフォルトではスタックの大きさは 8 メガが上限じゃなかったっけ？
(Windows だともっと小さかったはず)
大きさが固定 (コンパイル時に確定する) でかつ十分に小さく寿命が短いなら配列をスタックにおく
のは性能的に有利 (確保と解放のコストが小さい) だが、大きさを見積もれないときにスタックに置くと
スタックが足りないときにどうにもできないで即死するしかない。
大きさのわからない配列はスタックに置くべきではないというのが世の常識というもの。
少なくとも高レイヤのアプリケーションでは。
858:デフォルトの名無しさん
21/08/21 20:16:15.20 3jqa2oM2.net
仮想メモリなんだからスタック8GBに設定すればいいんじゃないの？
859:デフォルトの名無しさん
21/08/21 20:43:23.20 7GAoG1Iq.net
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴
著者： アンドレアス・ルンプ
バージョン： 1.5.1
URLﾘﾝｸ(nim-lang.github.io)
Nimは限りなく抑え込まれたタイプ量で高い生産
860:性とPythonのような高い可読性を実現し ているにもかかわらず、Cのソースコードを吐き出せるのでC言語でリモートワークされ ている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる 「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます
861:デフォルトの名無しさん
21/08/21 20:47:51.35 6mCMrQuL.net
Nimは知らんがパイソンが読みやすいなんて
862:デフォルトの名無しさん
21/08/21 20:53:42.26 Z4f8T8IW.net
pythonが特別読みやすいとは思わんが、pythonで読みづらいコード書くやつが
何で実装しても読みやすいものを書くことはないだろう。
863:デフォルトの名無しさん
21/08/21 20:55:25.62 6DBrqemS.net
>>844
Pythonはたまたま外部ライブラリ充実などで普及していますが、あまりよろしくない言語です。
そのためPythonで開発したいという人はいないです。
なので「Pythonのような高い可読性を実現している」と宣伝されても逆効果。
864:デフォルトの名無しさん
21/08/21 20:58:33.68 O7+p4qIy.net
>>844の人は関係ないスレに迷惑かけて、nimユーザーのイメージダウンが目的なんだろうか。
865:デフォルトの名無しさん
21/08/21 21:35:33.43 PyG7lKVy.net
積極的にPython使おうとは思わんなぁ。インタプリタ系はRuby使っているわ
Luaも結構良い感じだと思う
866:デフォルトの名無しさん
21/08/21 21:54:02.20 tswurJ+7.net
うん。 プログラマは Python をそんなに気に入ってない場合は多いと思う。
ただ現代ではプログラミングするのはプログラマとは限らない。
Python は元々はコンポーネントを組み合わせる、いわゆるグルー言語として設計されていて、
エンドユーザ向けの性質を持っている。 BASIC 系と似た立場かな。
このくらいに制限されていたほうがかえって使いやすいという場合は確かにある。
必要なコンポーネントが出そろっている状況で上位のロジックを組み立てる分には
Python も便利なこともあるにせよ、言語としての出来はそんなに良くない。
867:デフォルトの名無しさん
21/08/21 21:59:07.63 7GAoG1Iq.net
>>845
>Nimは知らんがパイソンが読みやすいなんて
Pythonは構文にインデントを組み込むことによってざっと眺めた時に人間が読みやすい
一般的には上記の事をPythonは高い可読性があると表現されています
この事は「Pythonは可読性の高い言語」ググれば約 265,000 件出てきます
他の言語と可読性は同じだろって意見の人もいますが少数派ですね
868:ハノン
21/08/21 22:21:31.89 .net
>>851
ｽﾚﾘﾝｸ(tech板:963番)
「javascriptは可読性の高い言語」で検索すると約 334,000 件
869:デフォルトの名無しさん
21/08/21 22:31:37.65 7PPLxZL+.net
元の文脈的に
nimも構文にインデントを組み込んでるからpythonが出てきただけでそういう議論がしたいんじゃないと思う
870:デフォルトの名無しさん
21/08/21 22:36:10.82 7GAoG1Iq.net
>>852
>「javascriptは可読性の高い言語」で検索すると約 334,000 件
単に検索件数が多いだけで、上位10件の表示内容を読んでも
「javascriptは可読性の高い言語」と言う内容のページは1つも見つかりません
対して「Pythonは可読性の高い言語」は上位10件の内5件見つかりました
871:デフォルトの名無しさん
21/08/21 22:41:14.03 7GAoG1Iq.net
>>853
おっしゃる通りです(/ω＼)
872:デフォルトの名無しさん
21/08/21 22:56:47.50 lXSuJ2vU.net
ただのコピペ荒らし
まったくRustもNimも関係ないスレでも見るし
873:デフォルトの名無しさん
21/08/21 23:00:47.35 YSvCkW+D.net
Rust Tourだけやっていても作業の流れが身につかなさそうなので、写経を始めました
そこでまず出くわしたのがTokioのバージョンの壁で、バージョンによって動いたり動かなかったり差がありました
クレートの無難なバージョンがどれか、クレート同士の無難な食い合わせはどれか、など、どうやって知れば良いのですか？
874:デフォルトの名無しさん
21/08/21 23:07:06.11 7GAoG1Iq.net
>>857
Nimの写経を始めましょう
875:デフォルトの名無しさん
21/08/21 23:07:52.34 kcBD0DB/.net
写経なら写し元と同じバージョンにそろえるのがよいのでは
876:デフォルトの名無しさん
21/08/21 23:24:51.23 7GAoG1Iq.net
>>859
>写経なら写し元と同じバージョンにそろえるのがよいのでは
Nimのバージョン 1.5.1を写経しましょう
Nimの実験的特徴
著者： アンドレアス・ルンプ
バージョン： 1.5.1
URLﾘﾝｸ(nim-lang.github.io)
877:デフォルトの名無しさん
21/08/21 23:48:46.37 PyG7lKVy.net
組み込み系ではMicroPythonが流行っているらしいが全く魅力を感じないｗ
878:デフォルトの名無しさん
21/08/21 23:53:13.51 +zMEbJ+6.net
Nimを調べてみたのだが
Rustよりも高機能な点を見つけられなかった
もし有るならば書いてください
無ければ去ってください
879:デフォルトの名無しさん
21/08/22 02:15:33.57 0Cz6ueFz.net
>>862
>Nimを調べてみたのだがRustよりも高機能な点を見つけられなかった
>もし有るならば書いてください
>無ければ去ってください
そんな寂しい事言わないでかまってよ～(´;︵;`)
行末のセミコロンが必要ない
タイプ数がもりもり減ります。
Rust にはもちろん必要です。
main が要らない
スクリプト言語感覚でいきなりコードを書けます。
Rust は main が必要です。
>Nimキチガイ
いつもみんなによく言われます
いや～照れますね～ｖ（=＾0＾=）ｖ
880:デフォルトの名無しさん
21/08/22 02:16:39.23 KEfgBimj.net
>>863
nimのスレ立ててそっちでやってよ
881:デフォルトの名無しさん
21/08/22 02:32:40.46 w5XnK8W7.net
>>863
あなたは知恵遅れか何か？
Rustより高機能な点を問われているのに、セミコロンが必要ないとかどうでもいい話しかできないの？
答えられないならここから出ていきなさい。
882:デフォルトの名無しさん
21/08/22 02:33:23.15 j+Q/a+4n.net
構うな
さっさとNG
883:デフォルトの名無しさん
21/08/22 02:35:27.65 0Cz6ueFz.net
>>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); <- 毎度これを書かされる
うざいっす。
884:デフォルトの名無しさん
21/08/22 02:38:26.87 0Cz6ueFz.net
>>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 の場合はご多分にもれずラッパー行きで超絶面倒くさいです。比較用に書きたいんですが結構な文章量になるのでやめます。
885:デフォルトの名無しさん
21/08/22 02:44:19.98 0Cz6ueFz.net
>>866
そんな寂しい事言わないでかまってよ～(´;︵;`)
Nimはmut mut しなくて良い
Rust はまともな変数を使おうとすると mut mut しないといけません。デフォルトだと再代入できませんから。
普通再代入しまくりますよね？定数ライクに使いた�
886:｢機会なんて殆どないですよね？なのに mut を毎度書かされます。 let n:int = 10 let mut m: int = 10 Nim ならこうですよ。 let n = 10 # immutable var m = 10 # mutable 素敵。
887:デフォルトの名無しさん
21/08/22 02:55:06.51 0Cz6ueFz.net
>>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 に似たダブスタの呪いもオマケで付いてます。
おかげさまで関数はほぼ全て明示的に参照渡しをするハメになります。
「だったらデフォルトそうしとけよ！ & をイチイチ書かせんなやワレ！」と思わないのってある種の才能だと思います
888:デフォルトの名無しさん
21/08/22 02:59:07.86 0Cz6ueFz.net
>>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
}
イミュータブルだからですって。はぁ・・・。
889:デフォルトの名無しさん
21/08/22 03:01:25.00 0Cz6ueFz.net
>>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 にはこんな呪いある"ワケ"がないです。
890:デフォルトの名無しさん
21/08/22 03:06:14.74 0Cz6ueFz.net
>>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() は書き方が違うだけで意味は同じです。
891:デフォルトの名無しさん
21/08/22 03:09:40.85 0Cz6ueFz.net
>>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 と似せて書いたらこうなるよって話でこんな書き方しません。
892:デフォルトの名無しさん
21/08/22 03:11:53.65 0Cz6ueFz.net
>>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
893:デフォルトの名無しさん
21/08/22 03:16:29.28 0Cz6ueFz.net
>>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"
894:デフォルトの名無しさん
21/08/22 03:20:10.82 0Cz6ueFz.net
>>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"
895:デフォルトの名無しさん
21/08/22 03:23:05.87 0Cz6ueFz.net
>>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
896:デフォルトの名無しさん
21/08/22 03:24:44.35 0Cz6ueFz.net
>>862
分配束縛
Nim は標準ではできませんが
URLﾘﾝｸ(github.com)
を突っ込むことで可能です。
897:デフォルトの名無しさん
21/08/22 03:26:55.98 0Cz6ueFz.net
>>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 はこんな書き方そもそも出来ません。
898:デフォルトの名無しさん
21/08/22 03:31:02.98 0Cz6ueFz.net
>>862
コンパイラがケチくさくない
nim c -r hoge
これで hoge.nim をコンパイルします。
拡張子なんて指定する必要ありません。
-r で実行もします。
Rust の場合
rustc hoge <- ダメ
コンパイルと同時に実行しようと思ったら
rustc hoge.rs && ./hoge
うーん・・・
899:デフォルトの名無しさん
21/08/22 03:36:37.77 0Cz6ueFz.net
>>862
実行速度・メモリ使用量・ファイルサイズが小さい
Rust と比べて Nim の実効速度はどっこいかむしろ速いです。
Rust はこんだけイライラする書き方を強制されるにも関わらずたいして速くないとかもう哀れすぎます。
コンパイル後のファイルサイズは話にならないレベルで比べ物になりません。
fizzbuzz の例(FizzBuzz を無駄にベンチマークしてみた By Nim、golang、Rust、Crystal、その他 - 強まっていこう)で言うと
項目 Nim Rust
実行速度 0.37s 0.44s
ファイルサイズ 82K 3.4M
メモリ 356K 900K
こんな感じです。
900:デフォルトの名無しさん
21/08/22 03:40:59.41 EcXIWh+x.net
>>882
無知がやるとそうなるわな
901:デフォルトの名無しさん
21/08/22 08:37:49.63 0Cz6ueFz.net
>>883
>無知がやるとそうなるわな
バカ丸出し
Nimは標準実装されたnimコンパイラが強力なマクロで
最適化されたCのソースコードを吐き出して、Cコンパイラ
で極小バイナリまで生成するから、コンパイルするだけで
後はプログラマがする仕事が無いので怠けててもいい
Rustは標準実装されたコンパイラでコンパイルするだけでは
超巨大なバイナリを生成するので、最適化せれたチューニング
を施して小さなバイナリを生成�
902:ｵなければならないから プログラマの仕事が増えて怠けられない
903:デフォルトの名無しさん
21/08/22 08:40:06.97 BRNN665g.net
>>884
仕組みすら理解してないのか
904:デフォルトの名無しさん
21/08/22 08:43:57.27 c6eQFYhO.net
>>880
それはブロックスコープといって多くの言語が備えておりプログラミングの基礎です
まさかNimには存在しないのですか？
905:デフォルトの名無しさん
21/08/22 08:57:00.52 QorwbXcj.net
rustスレでnim nim言ってる奴荒らしだろ
906:デフォルトの名無しさん
21/08/22 09:00:12.62 0Cz6ueFz.net
>>862
マクロのシンタックスを別で覚える必要がない
Rust のマクロは構文が全く変わってしまいます。
そしてそれは脳が全力で受付を拒否する素敵な仕上がりとなっております。
公式で自ら「マクロベースのコードの欠点は、組み込みルールの少なさに
由来するそのコードの理解のしづらさです。」と言いのけちゃう代物で
「なんじゃそりゃ」と言う言葉しか出ません。
Nim は構文がそのまま使えます。なので強力なマクロを使いこなすための
障壁の低さは比べ物になりません。
907:デフォルトの名無しさん
21/08/22 09:19:59.80 k4RSCji3.net
次世代言語22 Go Nim Rust Swift Kotlin TypeScript
ｽﾚﾘﾝｸ(tech板)
908:デフォルトの名無しさん
21/08/22 09:21:24.81 k4RSCji3.net
nim
ｽﾚﾘﾝｸ(tech板)
909:デフォルトの名無しさん
21/08/22 09:49:19.77 sxhQ+hXZ.net
実際rustって色々リンクするから、最小バイナリでかいよな
でも、それで困ったことってあるか？
俺はない
910:デフォルトの名無しさん
21/08/22 09:53:06.17 DrnSGK6Q.net
>>891
それはリンクする状況にするからであってRustのせいではない
例えばRustを使って組み込みやWASM等でもバイナリでかいと思ってないよね
911:デフォルトの名無しさん
21/08/22 10:05:41.39 qkR4Cuiq.net
Rustは他に比べれば最小のバイナリでしょ、コンパイラ/リンカーが長い年数を掛けて最適化されたCより大きいが。
一番不満なのが公式はビルドが速いというがそんなに早くない事だけ。それ以外は従来のC/C++（C++17/20/23
なんかを除く)より圧倒的に安全だし、明示的であるからこそタイプ量が多い。
Nimに比べて大きいというのはRustのコンパイラがまだCを吐き出してた頃から最適化されていないから、Nimと
いうかGCCやClangに比べ、ほんの少し大きくなる。リンクするものが大きければバイナリが大きくなるのは
当然でGoなんかはまさにそれでしょ、goroutineを共有ライブラリに押し込めることは出来ないから
912:デフォルトの名無しさん
21/08/22 10:06:16.71 sxhQ+hXZ.net
>>892
まあ、ユーザコード自体のサイズがでかいわけじゃないのは同意
913:デフォルトの名無しさん
21/08/22 10:17:01.78 qkR4Cuiq.net
もう１つ不満がある事は、Rustならメモリーリークしないと言う奴がいる事、公式も明言してる通り
グローバルの循環参照を作成してしまえば簡単にリークするのに、意識高い系のコード書かないやつが
メモリーリークしないんだと他の言語も触ったことの無い初心者に力説する事。盛大にリークしてて
正常に動いてるプログラムを直すのは大変・・・
ま、これは言語のせいじゃないけどね、他は凄い良く出来てる、Linuxカーネルに採用されるような
他の言語（第３の言語）は当分出てこないだろうと思うほど
914:デフォルトの名無しさん
21/08/22 10:35:44.30 FTtcJrTl.net
Rustのメモリ安全性は、メモリリークしない、ではないからな。
915:デフォルトの名無しさん
21/08/22 10:40:22.74 VB7b1YKz.net
>>895
Rustは弱参照があるから強参照の循環参照を作らずに済みます
よってまとまなプログラミングをしていればメモリーリークは起きません
916:デフォルトの名無しさん
21/08/22 10:42:20.85 sxhQ+hXZ.net
>>895
javaでも同じことを言う奴がいる
「GCが頻発する。GC壊れてる」
壊れてるのはお前のコードだ
917:ハノン
21/08/22 10:52:46.02 .net
>>867
構ってあげるから別スレ建ててください
C へのトランスレータであることは魅力的ですよね
918:デフォルトの名無しさん
21/08/22 10:54:43.87 j+Q/a+4n.net
>>895は分かってる人だろう
ちゃんと読んでるか？
919:デフォルトの名無しさん
21/08/22 11:49:45.30 PExPKGEq.net
ビット全探索する関数作ったヽ(´ー｀)ノ
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());
など
920:デフォルトの名無しさん
21/08/22 12:16:08.62 0Cz6ueFz.net
>>862
Rust の良いところ
さすがに Rust を批判ばかりしていては公平性に欠ける報道となり官邸から怒られます。
Rust にも良いところはあります。
fn <- 短い！
proc <- 長い！
これはメリットですよ。タイプが2回ずつ減るのは素敵なことです。
しっかしこれだけ馬鹿げた冗長さを押し付けてくる言語のくせして、
何故ここだけすっきりしているのやらさっぱり意味がわからないです。
あ、結局ディスってもうた・・・。
921:デフォルトの名無しさん
21/08/22 12:22:55.13 pVXVequb.net
>>902
どうでもいいだろ
それが0文字の言語も8文字の言語も併用しているが長さで困ったことはない
タイプ数を気にするのは愚か者だけだ
922:デフォルトの名無しさん
21/08/22 12:30:03.84 zDmwJZXZ.net
この仕組みを教えて下さい
もしかして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.
923:デフォルトの名無しさん
21/08/22 12:37:43.49 vEK5NNFF.net
>>895
他の言語に比べれば循環参照を作るハードルはかなり高いでしょ
現実的な用途でborrow checkerに引っかからないような循環参照を作って
リーク以外は機能的に問題ないコードを書くのは初心者には難しいと思う
924:デフォルトの名無しさん
21/08/22 12:55:40.93 QorwbXcj.net
さすがにマルチポストは荒らし以外の何物でもないな
925:デフォルトの名無しさん
21/08/22 13:03:58.26 sxhQ+hXZ.net
>>904
the compiler will collapse the discriminant of the first option into the second.
って言ってるから
Option<Option<u8>>はOption<u8>に変換されるってことじゃない？
926:デフォルトの名無しさん
21/08/22 13:18:58.50 cSh20jP2.net
>>554-555
あたりが物になるのはいつかなぁ
組み込みだとLLVM縛りは結構きつい
927:デフォルトの名無しさん
21/08/22 13:46:33.46 j+Q/a+4n.net
>>904
Optionで9回包んでもsizeは2のままだったのでそういうわけではなさそう
None, Some(_), Some(Some(_)) の3バリアントがあるのと同じようなレイアウトになる模様
↓はOption<Option<Option<u8>>>の例
URLﾘﾝｸ(play.rust-lang.org)
928:デフォルトの名無しさん
21/08/22 14:20:53.63 sxhQ+hXZ.net
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か区別してるのかな
929:デフォルトの名無しさん
21/08/22 14:35:04.66 vEK5NNFF.net
[0..=3]<u8>になってるね
nightlyで#[rustc_layout(…)]を使うと確認できる
#![feature(rustc_attrs)]
#[rustc_layout(abi, size, debug)]
type Foo = Option<Option<Option<u8>>>;
930:デフォルトの名無しさん
21/08/22 15:31:41.81 PExPKGEq.net
Itertoolsが便利すぎて今までの自分が可愛そうすぎる(´･ω･`)
931:デフォルトの名無しさん
21/08/22 17:33:05.93 0Cz6ueFz.net
>>862
技術書典に出会っていなかったら俺はNimをさわってないと思う
背景
俺たち「そろそろ技術書典に参戦するか」
俺たち「何書く？」
俺たち「マイナー言語を触ってみよう。言語選択は早い者勝ちね」
ワイ「(マイナーの定義はさておき)Nimでオナシャス」
ワイ「(アドカレあるし、記事まとめておくかぁ...)」
Nimとは？
Nim は アンドレアス・ランプフ氏によって設計・開発された命令型、マルチパラダイム、
コンパイル言語という特徴を持つプログラミング言語です。
アンドレアス・ランプフ氏は3DICC社に所属するエンジニアです。彼はNim開発以前に様々
な言語を触っていたようです。が、どの言語も満足せず、自身で作成することにしたようです。
それがNimプロジェクトの始まりで、2005年頃のようでした。
当初NiｍはNimrod(旧約聖書の登場人物)という名前でしたが、マーケティング上の理由から
2014年12月29日にリリースされたバージョン 0.10.2 からNimに変更されました。
932:デフォルトの名無しさん
21/08/22 18:20:04.94 qHvaNpwK.net
結局rustもC++を遥かに超える型地獄なんだな
933:デフォルトの名無しさん
21/08/22 18:47:16.61 eu6eNh6V.net
こんだけ型がっちがちに固められた言語触っちゃったら他の言語に戻れない
PythonとかPythonとか
934:デフォルトの名無しさん
21/08/22 19:10:19.80 E7wqFzW/.net
型地獄って何？
935:デフォルトの名無しさん
21/08/22 19:11:44.78 CqI7brJQ.net
二度と出られぬかーたーじーごーくーーー
936:デフォルトの名無しさん
21/08/22 19:15:51.20 +34cYDX+.net
実行時にバグるよりコンパイルエラーでコンパイル出来ない方が遥かに優れていると思ってるけど, そう思わないと型が辛くなるだろうなぁ
937:デフォルトの名無しさん
21/08/22 19:27:07.94 PExPKGEq.net
JavaScriptで組んでたときに、文字の数字を数値型に変換したくて、
"10" + 0
みたいにしてたことを思い出した
938:デフォルトの名無しさん
21/08/22 20:28:11.75 O/1WEaVf.net
C++でしんどいの型の部分じゃないけどな
939:デフォルトの名無しさん
21/08/22 20:45:47.91 JES5Vdct.net
>>919
JSようしらんけどこれって"100"にならないんだ？
940:デフォルトの名無しさん
21/08/22 21:02:27.49 0Cz6ueFz.net
>>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")
941:デフォルトの名無しさん
21/08/22 21:06:05.83 0Cz6ueFz.net
>>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")
942:デフォルトの名無しさん
21/08/22 22:37:49.54 Wmq9vv9f.net
RustにはGCないから云々言われるけどメモリ以外のリソースもRAIIとムーブセマンティクスの力でいい感じに扱えるのは良いよね
他の言語だと with 式などでスコープ抜けたら解放は出来るけど
クロージャにキャプチャされる場合など長時間生き残るようなケースをちゃんと扱えたりするのだろうか
943:デフォルトの名無しさん
21/08/23 00:06:22.12 q1PbYAS3.net
>>921
"100"になるよ
944:デフォルトの名無しさん
21/08/23 00:25:43.80 WImWpxqb.net
>>898
JavaはグローバルのGCがあるから意味が違うよ。リークしているように見えるがプログラムが正常に
終了をすればGCが起こる（だからJavaは停止時にフリーズしたようになるプログラムが多数）
>>905
ハードルは高くないよ。循環参照をWeak<T>でなくRc<T>で書いてしまえば普通にリークする
リファレンスカウントになっているのだから当たり前だけどね
URLﾘﾝｸ(doc.rust-jp.rs)
945:デフォルトの名無しさん
21/08/23 01:03:20.75 LyXSTYiq.net
GC言語にも弱参照はあるのでまともなプログラマーならば強循環参照は作らない
RustはGCが無しでメモリ安全性を保証できる言語であるとともにメモリリークも避けることができる言語
946:デフォルトの名無しさん
21/08/23 01:18:03.41 9dmEVPj+.net
GCは強循環参照も問題なく回収できるんだよ
947:デフォルトの名無しさん
21/08/23 01:30:55.93 gt/OOSS+.net
>>928
GCは方式の異なる段階があって
弱参照を使う循環参照なら強参照カウンタだけで回収できる
強参照のみの循環参照までも回収する方式は様々あるけどいずれも重い
だからGC言語にも弱参照があって賢い配慮あるプログラマーが使えるようになっている
948:デフォルトの名無しさん
21/08/23 02:08:47.17 mUiDivSN.net
>>926
その日本語訳に書いてる通り
「循環参照は簡単にできることではありませんが、不可能というわけでもありません。 Rc<T>値を含むRefCell<T>値があるなどの内部可変性と参照カウントのある型がネストして組み合わさっていたら、 循環していないことを保証しなければなりません;」
RefCell<Rc<T>>を使いこなせるのに循環参照で盛大にリークさせる人も
Rc<T>をWeak<T>に直すのが大変っていう人も
かなりの激レアさんだと思う(個人の感想)
949:デフォルトの名無しさん
21/08/23 08:54:29.06 7vUkULmy.net
>>929
誤り
GC言語の弱参照は強循環参照対策ではなく、キャッシュなどで長寿命のオブジェクトがGCを妨げることを避ける目的で使用される
だから例えば、ウインドウはボタンを管理しボタンは自身がクリックされたことをウインドウに通知する、ただしボタンが動的に追加削除されることはない、
といったような互いに寿命が一致する循環参照が生じるケースでは弱参照は普通使用しない
マークアンドスイープは十分に高速なので、参照カウンタをGCと併用するのはあまり一般的ではない
950:デフォルトの名無しさん
21/08/23 08:57:57.29 ksTslrDC.net
ネストしたstructの奥深いところにひっそりRcが隠れてたら
知らない間に循環参照になってることもあるかもしれない
951:931
21/08/23 09:17:05.48 7vUkULmy.net
念のため補足しておくが、寿命が一致しない循環参照の場合は弱参照を使わなければならないというわけではない
ウインドウとボタンの例でいうと、普通に考えてボタンが動的に削除されようとしていることをウインドウが知らないわけないから、そのタイミングでウインドウが持つボタンへの参照を削除すればいいだけだ
GC言語で弱参照が必要とされるのは極めて特殊なケースに限られており、ほとんど使用されることはない
952:デフォルトの名無しさん
21/08/23 09:53:29.91 IzWPiInz.net
>>933
特殊なケースではないと思う
GC言語でも何らかのツリー構造をあつかうことはよくあって
その時に親から子へは普通に強参照でも子から親へは弱参照の方が有利だよね
弱参照を使っていれば一部のサブツリーを捨てた時に循環参照ではなくなる
これはGC言語だけではなくRustでも同様で、サブツリーを捨てたらそのトップへの強参照が消えて連鎖的にサブツリーが回収されますよね？
953:デフォルトの名無しさん
21/08/23 10:15:02.98 6chE64yn.net
>>934
別に有利じゃないから普通にどっちも強参照使うのが普通だよ
マークアンドスイープは循環参照で遅くなったりしないから
954:デフォルトの名無しさん
21/08/23 10:25:19.17 9/DhhYFq.net
>>935
マークアンドスイープ方式のみでGCする言語ばかりではない
GCは奥が深い
弱参照の使用はそこで有利
955:デフォルトの名無しさん
21/08/23 10:28:37.19 6chE64yn.net
ちなみにGC言語は常に強参照を使うことを前提に最適化されているので、必要もないのに弱参照を多用すると確実に遅くなるよ
Javaだと弱参照それ自体がヒープアロケーションされるオブジェクトだったりするので、とんでもなく非効率だ
956:デフォルトの名無しさん
21/08/23 10:36:03.26 ZbJNhF7k.net
>>937
Rustでは弱参照を使うデメリットありますか？
957:デフォルトの名無しさん
21/08/23 10:50:20.08 6chE64yn.net
>>938
生存期間を意識した非対称なコーディングをしなければならないこと、だね
親子関係の循環参照でどちらを弱参照にすべきかはケースバイケースであり、>>934が思っているほど単純な話ではない
別にRustを批判してるわけじゃないが、GC言語から見ればそれ自体がデメリットなんだよ
958:デフォルトの名無しさん
21/08/23 11:23:41.21 XXiZs56E.net
これまでRust書いている時にトレーシングGCが欲しくなったことはありますか？
それはどのようなプログラムを書いている時ですか？