C vs C++ vs Rust Part.3

**デフォルトの名無しさん** · 2022/01/27(木) 22:19:47.56

闘え
※前スレ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/
C vs C++ vs Rust Part.2
https://mevius.5ch.net/test/read.cgi/tech/1639539350/

**デフォルトの名無しさん** · 2022/03/15(火) 19:46:14.60

>>480
その様子だと君にはどちらも無理だろう
もし書けると言うならば
そのcombinationsをRustで型Tのイテレータとして実装コードを出してごらん

**デフォルトの名無しさん** · 2022/03/15(火) 19:57:31.66

>>481
そんなことねーよｗ

>>482
まあね。その剥き出し感がいいんだよ遊びで使う分には。見えてない部分がないところ。
一応言っておくと難しい機能は公開するようなコードでは使わないよ。

>>483
https://docs.rs/itertools/0.7.8/src/itertools/combinations.rs.html

**デフォルトの名無しさん** · 2022/03/15(火) 20:02:15.14

>>482
C++のSFINAEはもちろん酷くて論外だが
逆にRustの現状のトレイト実装ルールは実装型を互いに排他を満たす必要があり厳しすぎる
もちろんRustコンパイラは進化し続けていて一部特殊化がそろそろ安定化しそうで少し緩和となり期待

**デフォルトの名無しさん** · 2022/03/15(火) 20:03:31.49

若い頃はSFINAEのパズル解く感じが好きでヤバいコード結構書いてたけど、だんだんあれは正気ではなかったなと思うようになってきた

**デフォルトの名無しさん** · 2022/03/15(火) 20:06:07.03

>>486
やめてそういうこと言うのｗ

**デフォルトの名無しさん** · 2022/03/15(火) 20:13:48.68

>>484
あなたはそのリンクを出すことでRustを全く知らない無知だとバレました
なぜならそのリンクのitertoolsバージョン0.7.8は4年前なのです
検索でリンクを拾ってこない限りそんな超古いバージョンを示す人はいません
あなたはプログラミング未経験者もしくは初心者であることがバレてしまいました

**デフォルトの名無しさん** · 2022/03/15(火) 20:30:44.95

>>484
偉そうなこと言っていてRustを理解できす挫折した落ちこぼれだったのか
>>480でRustを蔑んでいたから怪しいと思っていたらやっぱりか

**デフォルトの名無しさん** · 2022/03/15(火) 20:46:50.19

>>488-489
別に最新だろうがすぐ行けるだろｗ
俺が自分で書いたら正解はコレって出す予定だったからわざわざ出題したチキンなんだろ？
だからこれにしただけｗ

**デフォルトの名無しさん** · 2022/03/15(火) 21:05:33.57

>>490
言い訳ばかりだな
じゃあもう一つの>>460のsubsetsイテレータをRustで書けたら認めてやろう

**デフォルトの名無しさん** · 2022/03/15(火) 21:23:06.07

もしプログラミングが不慣れで難しいようだったら
イテレータを「どんな仕様」にしてしまってもいいぜ
それがヒントだ

**デフォルトの名無しさん** · 2022/03/15(火) 21:27:42.88

お前に認めてもらう必要なんてねーよｗ Rustを使うやつはバカしかいないんだなｗ

**デフォルトの名無しさん** · 2022/03/15(火) 21:37:04.88

>>493
今回は検索してリンクを拾ってこれなかったのね

**デフォルトの名無しさん** · 2022/03/15(火) 21:38:31.66

煽って正解もらいたいバカしかいないの？ｗ

**デフォルトの名無しさん** · 2022/03/15(火) 22:05:39.63

>>492
subsetsをどんな仕様のイテレータでもいいってことは
初心者でもすぐ出てくるあれでいいってことか

>>495
これは超初心者でもいいからプログラミングをしたことがあるのか
それとも煽っているだけなのかが判明しちゃう良問のようです
断念ですか

**デフォルトの名無しさん** · 2022/03/15(火) 22:10:01.54

断念もクソもなんでお前らに言われて俺がやる必要があるんだよｗバカだろｗ
ハッキリ言っておくが俺はRust書けるし、多分お前らより詳しいよ普通にｗ
こういうのがRust推してる信者頭おかしくて性格歪んだやつしかいない雰囲気100%で毛嫌いされてる理由なんだろうなｗ

**デフォルトの名無しさん** · 2022/03/15(火) 22:11:58.21

端的に言うと、流行りばかり気にするすごい頭悪い人たちと同じ匂いがするんだよｗ

**デフォルトの名無しさん** · 2022/03/15(火) 22:16:52.73

>>497
Rustに詳しいならば
既存のこれを使えばいい、と即答できる問題
あるいはsubsetsイテレータという問題だから仕様が自由に何でもいいならば初心者でもコードを一瞬で示せる問題
どちらも出来ないならRust未経験と断定できる

**デフォルトの名無しさん** · 2022/03/15(火) 22:31:30.23

permutationやcombinationとか普通にはあまり使わないんだよ
競プロとかやってる実利のないコードをメインに書いてるバカがそういうのをやたら使いたがって、俺より遅いコードしか書けないし、創造的なロジックもどうやら苦手そうなのに、そういう問題やたら出してくるんだよね
俺は元々そういうの得意だけど、その手の問題を好き好んで出してくるバカに答えを書いてやるのが嫌なんだよｗ
納得？

**デフォルトの名無しさん** · 2022/03/15(火) 22:43:02.13

>>500
permutationやcombinationのアルゴリズムが少し難しいのはわかります
でも今回はsubsetsですよ
さらに>>492でどんな仕様にしてもいいと言っていてしかもそれがヒントだと言ってるのでこれは気付きますよ

**デフォルトの名無しさん** · 2022/03/15(火) 22:45:50.74

俺pythonで書いてるし、自分でもすぐ書けるけど、お前に回答すんのが嫌なんだよｗ
なぜならお前がバカだからｗ何度もそう書いてんだけどｗ

**デフォルトの名無しさん** · 2022/03/15(火) 22:50:52.11

ああ、ちなみにpermutationやcombinationのアルゴリズムは簡単ｗ

**デフォルトの名無しさん** · 2022/03/15(火) 22:53:14.37

さきほどcombinationsイテレータをググって古いversionのitertoolsのソースで回答したよな>>484
ところが今回のsubsetsについては回答できない
検索で出てこないから答えられないのだとわかる

**デフォルトの名無しさん** · 2022/03/15(火) 23:04:20.16

永久に書いてやるよｗ
すぐ書けるけど、お前に回答すんのが嫌なんだよｗ
なぜならお前がバカだからｗ何度もそう書いてんだけどｗ

**デフォルトの名無しさん** · 2022/03/15(火) 23:07:34.34

>>503
なるほど
subsetsのアルゴリズムは難しくて無理でしたか

**デフォルトの名無しさん** · 2022/03/15(火) 23:09:47.42

永久に書いてやるよｗ
すぐ書けるけど、お前に回答すんのが嫌なんだよｗ
なぜならお前がバカだからｗ何度もそう書いてんだけどｗ

**デフォルトの名無しさん** · 2022/03/15(火) 23:20:19.51

>>507
さきほどcombinationsイテレータをググって古いversionのitertoolsのソースで回答したよな>>484
itertoolsをもし本当に使ったことがあるならばsubsetsもあるだろうことくらいわかるだろ？

**デフォルトの名無しさん** · 2022/03/15(火) 23:24:18.79

>>508
>>507

**デフォルトの名無しさん** · 2022/03/15(火) 23:32:35.94

>>508
そこは英語力の問題かな
subsetsが見つからなかった時にpowersetを探せるかどうか

**デフォルトの名無しさん** · 2022/03/15(火) 23:54:14.91

俺理系院卒だから数学一般教養くらいはあるぞｗ
難しい話をしてるつもりなのかもしれんけどｗ

**デフォルトの名無しさん** · 2022/03/16(水) 00:52:00.92

>>481
俺はC++もRustも基本的部分は理解しているつもりで、書こうと思えば Rustでも
書けると思うが、書こうとは思えない。
しかし、C++は使う。

**デフォルトの名無しさん** · 2022/03/16(水) 10:39:48.98

同じことをやるにしてもrustは面倒くさそう

**デフォルトの名無しさん** · 2022/03/16(水) 14:20:20.70

rustは詳しく知れば知るほど使える領域が狭いことに気付く。まあ勉強して損することはないとは思うけど。

**デフォルトの名無しさん** · 2022/03/16(水) 16:01:45.47

まぁ、Rustがものすごく人気になるようだったら、Rustを下敷きにしたC++サブセット Smart C++が出てくると思うわ。

そしてc++はライブラリアン向けのunsafe的な扱いになる、と。

**デフォルトの名無しさん** · 2022/03/16(水) 17:58:27.77

>>515
無理じゃないかな。

**デフォルトの名無しさん** · 2022/03/16(水) 20:15:10.51

rustが他言語の仕様に影響を与える部分はでてくるだろうね。

**デフォルトの名無しさん** · 2022/03/16(水) 21:02:09.61

反面教師にはなるよねｗ

**デフォルトの名無しさん** · 2022/03/16(水) 21:24:41.08

>>512
それはあなたの能力では理解できなかったから思うだけで留まり実際には書けていない

>>513
逆だ
同じことが簡潔に書ける

>>514
むしろ幅広い分野で有効
後発だからとも言えるが言語仕様が幅広いパラダイムを洗練して採り入れていることが勝因とみた

**デフォルトの名無しさん** · 2022/03/16(水) 21:56:01.01

少なくともC++はリプレイスしてほしいな

**デフォルトの名無しさん** · 2022/03/16(水) 21:58:33.64

Rust信者って本当にバカだなｗ
妄想で他人を説得はできないんだよ
グラフ構造を標準ライブラリとunsafe使わずに簡潔に書いてみろよｗ
他の言語で出来ないやつないから
Rustも超狭い領域ではオンリーワンくらい有効なんだけど、それ以外では趣味でしか使われない

**デフォルトの名無しさん** · 2022/03/16(水) 23:51:54.51

>>491 >>492
横からやけどほんまにどんな仕様にしてもええの？
それなら長さlenのsubsetsイテレータは10文字で完成
『0..(1<<len)』
数字を2進数で見てbit立っている要素による各subset
0は全ての要素がないから空集合

それで納得してもらえんのやったら入力inputとして
(0..(1 << len))
.map(|c| (0..len)
.filter_map(move |i| (c & (1 << i) != 0).then(|| &input[i]))
.collect::<Vec<_>>())
これでちゃんとしたsubsetsイテレータが完成
例えばinput = &["a", "b", "c"]ならば以下が順に出る
[]
["a"]
["b"]
["a", "b"]
["c"]
["a", "c"]
["b", "c"]
["a", "b", "c"]

**デフォルトの名無しさん** · 2022/03/16(水) 23:53:02.55

>>491 >>492
横からやけどほんまにどんな仕様にしてもええの？
それなら長さlenのsubsetsイテレータは10文字で完成
『0..(1<<len)』
数字を2進数で見てbit立っている要素による各subset
0は全ての要素がないから空集合

それで納得してもらえんのやったら入力inputとして
(0..(1 << len))
.map(|c| (0..len)
.filter_map(move |i| (c & (1 << i) != 0).then(|| &input[i]))
.collect::<Vec<_>>())
これでちゃんとしたsubsetsイテレータが完成
例えばinput = &["a", "b", "c"]ならば以下が順に出る
[]
["a"]
["b"]
["a", "b"]
["c"]
["a", "c"]
["b", "c"]
["a", "b", "c"]

**デフォルトの名無しさん** · 2022/03/17(木) 01:31:24.96

collectするならfoldで十分かな

fn subsets<T>(input: &[T]) -> impl Iterator<Item=Vec<&T>> {
let len = input.len();
(0..(1 << len))
.map(move |c| (0..len)
.fold(vec![], |mut v, i| {
if c & (1 << i) != 0 {
v.push(&input[i])
};
v
})
)
}

**デフォルトの名無しさん** · 2022/03/17(木) 02:22:57.24

C++でsubsetsイテレータを書くとどんな感じになるの？

**デフォルトの名無しさん** · 2022/03/17(木) 02:29:21.66

>>519
馬鹿

**デフォルトの名無しさん** · 2022/03/17(木) 02:39:09.51

Rust同様どうとでも出来るよｗ
C++のは古いから名前がアレだけど
俺は>>522じゃないけどfilterとmapで書いた方が分かりやすいとは思う
この書き方でpushとかは見たくなかったｗ

**デフォルトの名無しさん** · 2022/03/17(木) 02:53:46.50

うむ

>>522
filter_mapとthenによるOption利用が分かりやすいな

**デフォルトの名無しさん** · 2022/03/17(木) 03:28:10.97

>>527
ぜひC++版お願い

**デフォルトの名無しさん** · 2022/03/17(木) 04:22:11.55

>>529
何度でも言うけど、そういう要求は飲まない
金くれたら書くよｗ

**デフォルトの名無しさん** · 2022/03/17(木) 08:12:49.73

>>520
リプレースはしなくていい。
コーダーとかが通常使う安全運転版と、ライブラリアン用のフル版が住み分け・共存できればいい。
従来はコーディング規約とライブラリでやっていたところだけど、こういうのはshared ptrみたいに旨が使う共通仕様にしたほうがいい。

**デフォルトの名無しさん** · 2022/03/17(木) 08:19:10.27

Rustに移行すれば
色んな問題が一気に解決するだけでなく
プログラミングもしやすくなって一石二鳥

**デフォルトの名無しさん** · 2022/03/17(木) 08:41:07.21

>>532
サンプルコードがもっと充実してきて、標準的なコーディングが普及してきてから検討するわ。

Rustは土方向け言語目指しているのに、今のRustの仕様だと土方に難しすぎるから中途半端。それならc++＆コーディング規約でいいや。

**デフォルトの名無しさん** · 2022/03/17(木) 08:49:29.01

>>533
君たち土方には難しいのかも知れないが普通のプログラマーにとっては難しくないしコーティングがC++より快適

**デフォルトの名無しさん** · 2022/03/17(木) 08:57:01.71

Pythonくらいしかやったことない人にとって難しいのはそうだろうけど
C++14/17についていってる人ならRust余裕だと思うけどなぁ

**デフォルトの名無しさん** · 2022/03/17(木) 10:08:01.84

Rustに出来てC++が似たようなことを出来ないってことはまずないよ
ただ同じことをしたい場合、手間がすごいかかる(23は知らんけど)
そしてどう転んでもエラーがRustほど人間に優しくなったりはしない(と思う)

C++に出来てRustが似たようなことを出来ないってこともそんなに多くない
まあでもこっちは本当に出来ない
https://www.reddit.com/r/rust/comments/n7rjfk/what_can_c_do_that_rust_cant_2021_edition/

ただRustは初心者には難しすぎ、ある程度他の言語をやってる人にも難しいというハンデがある
なのでスクリプト言語感覚でRustをやろうと思うのはちょっとオススメできない
楽を出来る場面は確かにあるので、そこをどの程度メリットと捉えるか
制約をどの程度デメリットと捉えるかで評価が分かれる

**デフォルトの名無しさん** · 2022/03/17(木) 12:06:55.23

>>534
土方にやらせる話をしているんだよ。

Rust信者がそういう意識なら、RustがJavaみたいに流行ることは無いな。
やっぱりHaskellコースかね。

**デフォルトの名無しさん** · 2022/03/17(木) 16:20:31.29

>>534
>君たち土方には難しいのかも知れないが普通のプログラマーにとっては難しくないしコーティングがC++より快適
自分がどれくらい矛盾してること言ってるのかも理解してなさげ。

**デフォルトの名無しさん** · 2022/03/17(木) 18:26:55.16

>>522
Rustはスクリプト言語のように簡潔に書ける点もいいね
それでいてC言語並に速い
C++は簡潔に書けず手間暇かかりすぎる

**デフォルトの名無しさん** · 2022/03/17(木) 18:35:40.91

お手軽さっていう話だと、関数の仮引数の型も型推論してほしい、ってたまに思っちゃう

**デフォルトの名無しさん** · 2022/03/17(木) 18:44:45.18

>>540
技術的にはできるし、できるならやりたくなっちゃうところをあえて削ったのは英断だと思ってる
過去のコードや他人のコードを読むときに直近に型があるのは大きい

**デフォルトの名無しさん** · 2022/03/17(木) 18:59:38.79

> 仮引数の型も型推論
OCamlだとそれはフツーにできてるのにね

> 過去のコードや他人のコードを読むときに直近に型があるのは大きい

同じような話だがJavaのジェネリクスで

> List<Foo> list = new ArrayList<>();
> この右辺のパラメータが省略できるのを有難がるのは残念で
> ホントは左を省略してvar ist = new ArrayList<Foo>();
> と書けたほうが嬉しいのにJavaはやっぱりダメダメ

みたいな意見をみたことがあるが、左を残すことこそ大事なんだよな
実装に対してではなくてインタフェースに対してプログラミングするのであって
変数の型を必要最低限の小さいインタフェースで宣言するのが嬉しいのに
それをわかってないやつはタイピング数などで判断して世迷い言を言う

**デフォルトの名無しさん** · 2022/03/17(木) 19:25:12.70

Rust学習しはじめだがEnumの仕組みは良いと思う。
C#あたりに組み込まれればいいのに。

**デフォルトの名無しさん** · 2022/03/17(木) 20:43:27.53

enum Optionとか便利で簡潔に
null nil undefined -1など無くして安全に出来ていいよね
それでいてコンパイル後は最適化されたり消えたりして効率も両立されたり

**デフォルトの名無しさん** · 2022/03/17(木) 20:52:32.01

別にC++でも同じことはできるけどね
自分で組めばC++14とかでもrxっぽく書いたり、Optionの実装も余裕
手間さえ惜しまなければｗ

**デフォルトの名無しさん** · 2022/03/17(木) 20:55:03.76

Javaも最近は左側省略できるよ
おっしゃるとおり基底型何にするかは選べないけどｗ

**デフォルトの名無しさん** · 2022/03/17(木) 20:58:40.56

C++17にstd::optional<T>があるにはあるのだが...

膨大な量の既存のSTLが無効値をoptionalに置き換えられることはない
つまり無効値でoptionalを返す風潮ができにくいから悲しみ

**デフォルトの名無しさん** · 2022/03/17(木) 20:59:36.98

引数の型推論は原理的にはかなり出来そうだけど
例えば引数がas_ref()で使われていて変換後がPathなら引数はimpl AsRef<Path>までやっちゃう？
でもその利用者へのインタフェース明示や可読性と保守性を考えると型明記でいいような気がする

**デフォルトの名無しさん** · 2022/03/17(木) 21:13:38.45

C++もautoだらけlambdaだらけにすると引数も戻り値も結構型書かなくていいけど、遠すぎて何に怒られてるのか分からん代入エラーが出たりもするｗ
Rustも同じだけどエラーは分かりやすい

**デフォルトの名無しさん** · 2022/03/17(木) 21:15:46.46

>>545
そこはやろうと思えばできるレベルと
Rustが標準ライブラリで全面採用サポートしてるレベルで天と地の差があるよね
例えば>>522もbool値がthenでOptionを生成してそれをfilter_mapが受け取ることで簡潔なコードになっていたり

**デフォルトの名無しさん** · 2022/03/17(木) 21:23:13.02

そこはfilterとmapの方が分かりやすい

**デフォルトの名無しさん** · 2022/03/17(木) 21:32:28.43

一般的にfilter_mapはわかりやすと速さを両立
だからわざわざfilter_mapやfilter_map_okが用意されている

**デフォルトの名無しさん** · 2022/03/17(木) 21:35:05.28

そんなところは全く速さに影響しないと思うよ

**デフォルトの名無しさん** · 2022/03/17(木) 21:43:21.73

>>553
その種類のイテレータを2段は最適化前はもちろん速さに影響するけど
最適化により最終コードが同一コードになることを確認したということ？

**デフォルトの名無しさん** · 2022/03/17(木) 21:49:32.84

お前は速くなることを確認したんかい？ｗ
俺は出来るけど速くならないことを確認する必要がないと判断したｗ
お前は恐らく出来ないｗ

**デフォルトの名無しさん** · 2022/03/17(木) 21:58:49.13

コードそのままならイテレータ2つより1つの方が速いと明白なので
速さが同じと主張する>>555が最適化で同じコードになることを示す必要がある

**デフォルトの名無しさん** · 2022/03/17(木) 22:05:07.99

明白じゃねーよｗｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/17(木) 22:19:03.24

たぶん>>557氏はイテレータの動作原理を知らないのだと思う
例えばfilterは構造体Filterを返しそのメソッドnext()がイテレータを進めるごとに呼ばれる
同様にmapは構造体Mapを返しそのメソッドnext()がイテレータを進めるごとに呼ばれる
最適化前はそれら二重のオーバヘッドがある

**デフォルトの名無しさん** · 2022/03/17(木) 22:24:52.40

速さに関して議論するなら最適化のコードがどうなるかを確認すべきでは
特にイテレーターアダプターを何度も噛ませてもfor文相当のコードが生成されるというのはrustの売りのひとつだよね

**デフォルトの名無しさん** · 2022/03/17(木) 22:29:02.79

もし最適化後に有意に速度差があるなら、それは性能バグとしてIssueにあげるべき問題だと思う

**デフォルトの名無しさん** · 2022/03/17(木) 22:31:57.85

>>559
その通りで最適化で非常に効率な最終コードとなる
ただし今回のケースでfilter().map()がfilter_map()と同一コードになるかどうかは自明ではない
したがって>>553に立証義務がある

**デフォルトの名無しさん** · 2022/03/17(木) 22:36:47.68

立証義務なんてねーだろｗｗｗｗ
できないからって他人に頼るなｗｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/17(木) 22:38:48.81

意味的に同じことやってるんだから、理想的な最適化コンパイラは全く同じバイナリを吐くはずで
遅くなるはずってのも別に自明ではないのでは

**デフォルトの名無しさん** · 2022/03/17(木) 22:46:51.69

>>563
意味の同じプログラムが最適化で常に同じコードになるかどうかは自明ではない
そしてそれを期待することはよいが前提としてはいけない
自明ではないことを同じと主張する側に立証義務がある

**デフォルトの名無しさん** · 2022/03/17(木) 22:48:42.58

できないんだねｗｗｗｗ
rustの吐くコードすげー見にくいしなｗ
それ以前にアセンブラ読めなそうｗ

**デフォルトの名無しさん** · 2022/03/17(木) 22:52:00.13

>>564
ん？別に同じになるのが自明とは言ってないよ
どちらも同程度に自明でないって言ってるだけ
立証はまぁやりたい人がやればいいんじゃない

**デフォルトの名無しさん** · 2022/03/17(木) 22:57:38.05

>>565
> rustの吐くコードすげー見にくいしなｗ

無知っぷりを曝け出してるな

**デフォルトの名無しさん** · 2022/03/17(木) 23:14:09.53

お前が無知なだけｗ

**デフォルトの名無しさん** · 2022/03/17(木) 23:29:12.99

>>565
LLVMがアセンブリを吐いてることも知らないのか

**デフォルトの名無しさん** · 2022/03/17(木) 23:31:17.03

ビビリ単発IDが何もかもを証明しちゃってるｗ
お前は何も分かってないｗ

**デフォルトの名無しさん** · 2022/03/17(木) 23:50:47.22

>>529
C++ではそんなに簡単には書けない

**デフォルトの名無しさん** · 2022/03/17(木) 23:59:39.29

C++でも簡単に書けるよｗ
C++20で導入されたrangeでも使ってみｗ
より古い規格でもユーザーライブラリを使えばRxっぽい記述は簡単に出来る
自分で書くと難しくはないが骨が折れるタイプの実装
並列化を意識しない限りだけどｗ
まあ並列化を意識しないで簡便さを意識すれば無理にRxを使う必要もないけども・・・

**デフォルトの名無しさん** · 2022/03/18(金) 00:00:49.69

>>572
無理でしょ
実際に書いてみ

**デフォルトの名無しさん** · 2022/03/18(金) 00:03:10.42

加えて言えばRxでなければ上限を意識したループで書けるのでメモリ確保が最適化できるし、手でinlineにする部分を選べる分より速く書ける可能性もあるｗ

**デフォルトの名無しさん** · 2022/03/18(金) 00:03:27.72

>>573
いくらくれる？

**デフォルトの名無しさん** · 2022/03/18(金) 00:10:24.15

>>574
無理だ

**デフォルトの名無しさん** · 2022/03/18(金) 00:13:29.40

君にはそうなんだねｗ可哀想にねｗ

**デフォルトの名無しさん** · 2022/03/18(金) 00:37:03.66

前スレの時からそうだけどRustのコードばかり出てくるスレ
C++で同じコードを書くと長く見難くなってしまうからだろうけど

**デフォルトの名無しさん** · 2022/03/18(金) 00:49:14.78

C++20なら普通に同じくらいｗ
あるのはRustの不慣れな部分コードねｗまあこのレベルの作業に良い悪いもないけどｗ
君等のお勉強()にはいいんじゃないのｗ

**デフォルトの名無しさん** · 2022/03/18(金) 03:33:36.54

>>524のC++バージョン教えて

**デフォルトの名無しさん** · 2022/03/18(金) 06:33:28.96

これだけヒント出してやったのにまだ書けないのやばくね？ｗ

**デフォルトの名無しさん** · 2022/03/18(金) 08:39:50.87

>>542
変数の型を必要最低限の小さいインタフェースで宣言するのが嬉しいのに

とか言っているのに、使わない部分も含めてインターフェイスを制限する変数の型制限を有難がるのは笑いどころでしょうか？
「変数の型を固定して、コーダーの想定外の動きをしないように限定する」なら、そういう考えをもあるよね、となるけど。