Qiita 7 - キータぞ、来たぞ、キータだぞー (768ﾚｽ)
Qiita 7 - キータぞ、来たぞ、キータだぞー http://mevius.5ch.io/test/read.cgi/tech/1757733847/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
1: デフォルトの名無しさん [sage] 2025/09/13(土) 12:24:07.83 ID:mucntwOq Hello hackers ! Qiitaは、エンジニアリングに関する知識を記録・共有するためのサービスです。 コードを書いていて気づいたことや、自分がハマったあの仕様について、 他のエンジニアと知見を共有しましょう ;) https://qiita.com/ Qiita（キータ）は、Incrementsが運営するプログラミング情報のナレッジコミュニティ。 2016年現在で日本最大のプログラマーコミュニティとされている[1]。 https://internet.watch.impress.co.jp/docs/news/1025972.html 前スレ Qiita https://mevius.5ch.net/test/read.cgi/tech/1542357242/ Qiita 2 - キータぞ、来たぞ、キータだぞー https://mevius.5ch.net/test/read.cgi/tech/1658762410/ Qiita 3 - キータぞ、来たぞ、キータだぞー https://mevius.5ch.net/test/read.cgi/tech/1685235361/ Qiita 4 - キータぞ、来たぞ、キータだぞー https://mevius.5ch.net/test/read.cgi/tech/1705486836/ Qiita 5 - キータぞ、来たぞ、キータだぞー https://mevius.5ch.net/test/read.cgi/tech/1717651046/ Qiita 6 - キータぞ、来たぞ、キータだぞー https://mevius.5ch.net/test/read.cgi/tech/1739527246/ http://mevius.5ch.io/test/read.cgi/tech/1757733847/1
2: デフォルトの名無しさん [sage] 2025/09/14(日) 01:56:40.69 ID:CZ0V8fQ4 『【Go】配列を再帰的に逆順にするサンプルコードを書いてみた』 > 再帰を使うことで、ループを使わずにエレガントに実装できる。 根本的なところで誤解してる人な模様。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/2
3: デフォルトの名無しさん [sage] 2025/09/14(日) 02:53:44.41 ID:bGojT+ur >>2 一般論として 再帰で表現した方が抽象度が高く理解しやすく定義そのまま表現できることが多い 特に末尾再帰をコンパイラがループへ変換してくれて実行効率が同等ならば全ての点で再帰による表記が勝る http://mevius.5ch.io/test/read.cgi/tech/1757733847/3
4: デフォルトの名無しさん [sage] 2025/09/14(日) 12:10:16.28 ID:RhzWmJy7 入力配列と出力配列渡してループで処理するわ http://mevius.5ch.io/test/read.cgi/tech/1757733847/4
5: デフォルトの名無しさん [sage] 2025/09/14(日) 12:59:52.05 ID:ZqIkDajJ 記事の再帰版のコードは > func ReverseArray(arr []int, start, end int) []int { > // ベースケース: 配列の中央に到達したら終了 > if start >= end { > return arr > } > > // 要素を交換 > arr[start], arr[end] = arr[end], arr[start] > > // 再帰呼び出し: 範囲を狭めて継続 > return ReverseArray(arr, start+1, end-1) > } 引数で渡した配列の内容書き換えるんでreturn要らないんだよなあ。 再帰で書くよか繰り返しで書いた方が余程シンプルとも思う。 func ReverseArrayWithFor(arr []int, start, end int) { for start < end { arr[start], arr[end] = arr[end], arr[start] start += 1 end -= 1 } } http://mevius.5ch.io/test/read.cgi/tech/1757733847/5
6: デフォルトの名無しさん [sage] 2025/09/14(日) 13:06:57.84 ID:ZqIkDajJ 記事のスライス操作版のコードは > // ReverseArrayWithSlice はスライス操作で配列を逆順にする（再帰） > func ReverseArrayWithSlice(arr []int) []int { > // ベースケース: 要素が1つ以下なら逆順にする必要なし > if len(arr) <= 1 { > return arr > } > > // 最初の要素を取り出し、残りを再帰的に逆順にしてから結合 > return append(ReverseArrayWithSlice(arr[1:]), arr[0]) > } 引数の配列内容を書き換えないし再帰を説明する上では面白い例だと思うが、パフォーマンスは最低だ罠。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/6
7: デフォルトの名無しさん [sage] 2025/09/14(日) 13:28:33.58 ID:ZqIkDajJ そもそもの話として、ひとつの記事の中で複数の関数が引数だとか配列の内容を書き換えるのかどうかとか仕様が合ってないから比較になってないのよね。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/7
8: デフォルトの名無しさん [] 2025/09/14(日) 13:42:25.65 ID:yOrWt/NI >>7 問題はそこだね ループでも書けるよとかの筋違いな批判は要らんて http://mevius.5ch.io/test/read.cgi/tech/1757733847/8
9: デフォルトの名無しさん [sage] 2025/09/14(日) 14:21:09.67 ID:ZqIkDajJ ・引数は配列を渡すのみ ・内容を逆にした配列を返し、引数で渡した配列の内容は書き換えない という条件にしたとして、繰り返しで書くより再帰のほうが良い書き方ができるだろうか? func ReverseArrayWithFor(arr []int) []int { n := len(arr) result := make([]int, n) for i := 0; i < n; i++ { result[i] = arr[n - i - 1] } return result } 「全ての点で再帰による表記が勝る」という人には再帰の素晴らしさをぜひ証明してほしいところだが口だけ番長だろうなあ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/9
10: デフォルトの名無しさん [sage] 2025/09/14(日) 15:20:41.57 ID:wFXoVVHv >>9 大昔からの古典すら知らない無知 LISPも知らないんだろうな http://mevius.5ch.io/test/read.cgi/tech/1757733847/10
11: デフォルトの名無しさん [sage] 2025/09/14(日) 15:24:57.73 ID:ZqIkDajJ GoとLISPの区別もつかない人とはなあｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/11
12: デフォルトの名無しさん [sage] 2025/09/14(日) 15:30:37.23 ID:ZqIkDajJ 記事のスライス操作版のコードは > // ReverseArrayWithSlice はスライス操作で配列を逆順にする（再帰） > func ReverseArrayWithSlice(arr []int) []int { > // ベースケース: 要素が1つ以下なら逆順にする必要なし > if len(arr) <= 1 { > return arr > } > > // 最初の要素を取り出し、残りを再帰的に逆順にしてから結合 > return append(ReverseArrayWithSlice(arr[1:]), arr[0]) > } 要素数1の配列を渡した場合は引数の配列をそのまま返してしまうので // ベースケース: 要素が0以下なら逆順にする必要なし if len(arr) <= 0 { とした方が良いな。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/12
13: デフォルトの名無しさん [sage] 2025/09/14(日) 15:35:06.93 ID:ZqIkDajJ 試しに ・引数は配列を渡すのみ ・内容を逆にした配列を返し、引数で渡した配列の内容は書き換えない 再帰で書いてみたが func ReverseArray(arr []int) []int { n := len(arr) result := make([]int, n) copy(result, arr) var reverseArray func(int, int) reverseArray = func(start int, end int) { if start < end { result[start], result[end] = result[end], result[start] reverseArray(start + 1, end - 1) } } reverseArray(0, n - 1) return result } エレガントとは程遠いな。 ぜひLISP仕込みのエレガントな例をGoで書いて披露してほしいものだ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/13
14: デフォルトの名無しさん [sage] 2025/09/14(日) 17:50:25.98 ID:ZqIkDajJ ChatGPTに下記の質問投げたらそこそこ納得できる回答くれたわ。 「Go言語は末尾再帰はサポートされてるの?」 「末尾再帰最適化されないところでの再帰呼び出しは引数の範囲が不定だとスタックがどれくらい使われるかの予測はしづらいので要はGoでは引数の範囲が不定なところでの再帰呼び出しは使わない方が無難てことですね。」 「関数型言語で育った人とかで「再帰は繰り返し処理より常に正義」とかって人いるじゃない。ああいう人にはGoは辛いかもですね。」 「Lispにloopがサポートされても意地でも使わないとかの人いましたね。」 http://mevius.5ch.io/test/read.cgi/tech/1757733847/14
15: デフォルトの名無しさん [] 2025/09/14(日) 18:13:30.88 ID:pN1ZIB1N >>6 何言ってんの爆速ですわ http://mevius.5ch.io/test/read.cgi/tech/1757733847/15
16: デフォルトの名無しさん [sage] 2025/09/14(日) 18:45:10.81 ID:d1cvwZ2J ＞何言ってんの爆速ですわ コードと実行結果のひとつでも挙げりゃ良いのだけど、それができない人がなんか言ってる感じｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/16
17: デフォルトの名無しさん [sage] 2025/09/14(日) 19:42:15.05 ID:buQYk9+g >>13 下手すぎ 最初に丸ごとcopyする時点でプログラミングのセンスがない http://mevius.5ch.io/test/read.cgi/tech/1757733847/17
18: デフォルトの名無しさん [sage] 2025/09/14(日) 19:59:01.07 ID:d1cvwZ2J 丸ごとcopyしない>>17のセンスある実装に期待ｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/18
19: デフォルトの名無しさん [sage] 2025/09/14(日) 21:05:23.33 ID:gAWV5uS0 いつも的外れな記事批判を繰り返している連投クンは本気でわからないようだな 元データを改変せずに新たに逆順を返す再帰関数を書きたいのならば例えばこうする func ReverseArray(input []int) []int { if len(input) == 0 { return nil } else { return append(ReverseArray(input[1:]), input[0]) } } http://mevius.5ch.io/test/read.cgi/tech/1757733847/19
20: デフォルトの名無しさん [sage] 2025/09/15(月) 00:35:19.13 ID:aenReHhk >>19と他のコードでベンチマークしてみた。要素数は10から10000。 https://ideone.com/DZJosr > 10: > ReverseArray9: 0.000001 > ReverseArray13: 0.000000 > ReverseArray19: 0.000002 > 100: > ReverseArray9: 0.000000 > ReverseArray13: 0.000000 > ReverseArray19: 0.000016 > 1000: > ReverseArray9: 0.000002 > ReverseArray13: 0.000040 > ReverseArray19: 0.000104 > 10000: > ReverseArray9: 0.000011 > ReverseArray13: 0.000293 > ReverseArray19: 0.000958 http://mevius.5ch.io/test/read.cgi/tech/1757733847/20
21: デフォルトの名無しさん [sage] 2025/09/15(月) 00:39:24.47 ID:Wq0UyIVm エンジニアならベンチ結果で語るべきだよな！ http://mevius.5ch.io/test/read.cgi/tech/1757733847/21
22: デフォルトの名無しさん [sage] 2025/09/15(月) 00:41:02.81 ID:oHygyuIm 末尾再帰を自動的にループ化しないシステムもあれば appendするだけで毎回ムダに新たに別メモリを確保してしまうシステムもある Goは最悪だと実証された http://mevius.5ch.io/test/read.cgi/tech/1757733847/22
23: デフォルトの名無しさん [sage] 2025/09/15(月) 00:50:27.97 ID:cAmqpZFr このクソ仕様がGoの敗因っぽいね ＞appendは毎回新たなスライスを生成します http://mevius.5ch.io/test/read.cgi/tech/1757733847/23
24: デフォルトの名無しさん [sage] 2025/09/15(月) 08:10:37.10 ID:aenReHhk >>17が丸ごとcopyしないセンスある実装を晒してくれなかったので書いてみた。 func ReverseArray(arr []int) []int { n := len(arr) result := make([]int, n) var reverseArray func(int) reverseArray = func(i int) { if i < n { result[i] = arr[n - 1 - i] reverseArray(i + 1) } } reverseArray(0) return result } やはりセンスある感じではないな。素直に for で繰り返した方が素直な感じ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/24
25: デフォルトの名無しさん [sage] 2025/09/15(月) 08:16:11.29 ID:aenReHhk ベンチマーク結果 https://ideone.com/mBV6Jr > 10: > ReverseArray9: 0.000001 > ReverseArray13: 0.000001 > ReverseArray19: 0.000003 > ReverseArray24: 0.000000 > 100: > ReverseArray9: 0.000000 > ReverseArray13: 0.000001 > ReverseArray19: 0.000024 > ReverseArray24: 0.000001 > 1000: > ReverseArray9: 0.000003 > ReverseArray13: 0.000061 > ReverseArray19: 0.000143 > ReverseArray24: 0.000006 > 10000: > ReverseArray9: 0.000013 > ReverseArray13: 0.000446 > ReverseArray19: 0.001487 > ReverseArray24: 0.000060 ReverseArray24が案外良いのは恐らくは再帰呼び出しをループにする最適化が行われている感じ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/25
26: デフォルトの名無しさん [sage] 2025/09/15(月) 08:27:46.98 ID:aenReHhk ideone では Go のコンパイラが 1.12.1 と旧く、もっと新しい版(1.24.2)だと ReverseArray9 と ReverseArray24 の差は小さくなる模様。 https://godbolt.org/z/KW87qMWsf 出力コードも見ようとしたけどちょっと見る気起きないな。 main_ReverseArray19_pc0 の中で再帰呼び出ししてることは > CALL main.ReverseArray19(SB) 確認したが。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/26
27: デフォルトの名無しさん [sage] 2025/09/15(月) 08:41:05.40 ID:7N5dcPCF 一番シンプルにわかりやすい>>19を再帰呼び出しのままは厳しいな appendするたびに作り直すらしいGoの仕様が足を引っ張ってるのだろうか http://mevius.5ch.io/test/read.cgi/tech/1757733847/27
28: デフォルトの名無しさん [sage] 2025/09/15(月) 09:31:01.39 ID:G/lRv3X8 今のQiitaはこの程度の話すらコメ欄ではできないのがクソなんだよなあ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/28
29: デフォルトの名無しさん [sage] 2025/09/15(月) 12:47:17.00 ID:aenReHhk なんか同じパラメータでの呼び出しを2回繰り返すと ReverseArray13 と ReverseArray19 だけ 2回目の速度が向上するな? https://ideone.com/zLdldJ > 1000: > ReverseArray9: 0.000003 > ReverseArray13: 0.000089 > ReverseArray19: 0.000174 > ReverseArray24: 0.000007 > 1000: > ReverseArray9: 0.000004 > ReverseArray13: 0.000005 > ReverseArray19: 0.000016 > ReverseArray24: 0.000007 > 10000: > ReverseArray9: 0.000018 > ReverseArray13: 0.000574 > ReverseArray19: 0.001747 > ReverseArray24: 0.000059 > 10000: > ReverseArray9: 0.000024 > ReverseArray13: 0.000035 > ReverseArray19: 0.000207 > ReverseArray24: 0.000055 キャッシュの影響ではなさそうだがなんぞコレ? こういうのは楽しい。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/29
30: デフォルトの名無しさん [sage] 2025/09/15(月) 13:03:08.76 ID:aenReHhk 要素数を1000から1000刻みで増やしていくと6000でガクッとパフォーマンス落ちてるな。 https://ideone.com/2yAyfW 再帰呼び出しを深く行うことでスタックが足りなくなりスタック領域の拡張が行われそれでパフォーマンスが落ちてる気がする。 予めスタック領域が十分拡張されてれば ReverseArray13 と ReverseArray19 のパフォーマンスも 1回目から比較的マシになりそうな気がする。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/30
31: デフォルトの名無しさん [sage] 2025/09/15(月) 13:16:02.23 ID:aenReHhk 試しにmain()の先頭にスタック領域を拡張してくれそうな処理を入れてみた。 var enlarge func(int) enlarge = func(n int) { if n > 0 { enlarge(n - 1) } } enlarge(100000) 実行結果 https://ideone.com/cJl9AC > 1000: > ReverseArray9: 0.000005 > ReverseArray13: 0.000011 > ReverseArray19: 0.000028 > ReverseArray24: 0.000009 > 10000: > ReverseArray9: 0.000032 > ReverseArray13: 0.000048 > ReverseArray19: 0.000273 > ReverseArray24: 0.000110 こうかは ばつぐんだ！ http://mevius.5ch.io/test/read.cgi/tech/1757733847/31
32: デフォルトの名無しさん [sage] 2025/09/15(月) 13:23:08.72 ID:aenReHhk >>25で > ReverseArray24が案外良いのは恐らくは再帰呼び出しをループにする最適化が行われている感じ。 というのは多分間違いで、ReverseArray24 の前に実行している ReverseArray13 や ReverseArray19 のお陰でスタック領域が予め拡張されていたため ReverseArray24 の実行でスタック領域拡張処理が発生しなかったことがパフォーマンスが案外良かったことの原因と思われる。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/32
33: デフォルトの名無しさん [sage] 2025/09/15(月) 19:24:06.27 ID:OSZOiNza IDコロコロ切り替えてる人は自分の投稿に自信がないのかな http://mevius.5ch.io/test/read.cgi/tech/1757733847/33
34: デフォルトの名無しさん [sage] 2025/09/15(月) 22:14:31.00 ID:wx2AhEF9 >>33 いや自信ないのはお前 いまはIDコロコロを言う流れでない 直前の投稿は同一IDで8件投稿してIDコロコロでない 安価なくIDコロコロと言われても何を言ってるのかわからない お前が自分の投稿に自信ないのは空気を読めず日本語が不自由だから http://mevius.5ch.io/test/read.cgi/tech/1757733847/34
35: デフォルトの名無しさん [sage] 2025/09/16(火) 01:27:30.19 ID:JSTZ1Kt/ IDコロコロに反応する人がいるのは面白いねえｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/35
36: デフォルトの名無しさん [] 2025/09/16(火) 02:12:35.47 ID:NVXmEvhV 図っ星 http://mevius.5ch.io/test/read.cgi/tech/1757733847/36
37: デフォルトの名無しさん [sage] 2025/09/16(火) 09:08:34.57 ID:zaWo9xwV Qiitaのコメ欄で有意義な議論ができない問題、バカなこと言ってる側が複垢使うとかで相手を攻撃的と通報する可能性までありそうだなｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/37
38: デフォルトの名無しさん [sage] 2025/09/16(火) 19:41:50.97 ID:Wr/gNYaO >>9や>>24のコードがダサくて>>19がシンプルなのは再帰の有無ではなくコードの抽象的な度合いが原因だと思う http://mevius.5ch.io/test/read.cgi/tech/1757733847/38
39: デフォルトの名無しさん [] 2025/09/17(水) 08:59:29.24 ID:JW/5kEOI 数学的に言うと Σ(Sigma) は 再帰の方が抽象的なんか？ ループでも等価だと思うんだが http://mevius.5ch.io/test/read.cgi/tech/1757733847/39
40: デフォルトの名無しさん [sage] 2025/09/17(水) 09:21:49.27 ID:0mQm0ojt >>38 再帰を使わないシンプルな版を書いて主張すれば良い http://mevius.5ch.io/test/read.cgi/tech/1757733847/40
41: デフォルトの名無しさん [sage] 2025/09/17(水) 09:26:43.33 ID:MzfCTW9l >>9 arr[n - i - 1]が不格好ではあるな http://mevius.5ch.io/test/read.cgi/tech/1757733847/41
42: デフォルトの名無しさん [sage] 2025/09/17(水) 10:55:53.14 ID:0mQm0ojt >>41 func ReverseArray(arr []int) []int { n := len(arr) result := make([]int, n) for i, j := 0, n - 1; i < n; i, j = i + 1, j - 1 { result[i] = arr[j] } return result } http://mevius.5ch.io/test/read.cgi/tech/1757733847/42
43: デフォルトの名無しさん [sage] 2025/09/17(水) 21:20:35.77 ID:0mQm0ojt しまったー！ ElixirChip初お目見え会今日だったじゃーん 忘れてたわー！ざーんねーん！ とか言ったりして。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/43
44: デフォルトの名無しさん [sage] 2025/09/17(水) 22:01:15.40 ID:+QFNSyi5 配列などの各要素を巡る抽象化はイテレータだよ 抽象化の役割分担がわかりやすいRustで説明すると 今回の各要素の順番を逆順にしたベクタを作る関数はこうなる fn reverse_value<T: Clone>(input: &[T]) -> Vec<T> { input .iter() // 各要素への参照を巡るイテレータ .rev() // それを逆順に巡る .cloned() // 各要素への参照から値を複製して値を得る .collect() // それらの値を今回は返り型で指定のVecへ収集 } このイテレータは各要素への参照(ポインタ)を動かしていくので 今回のように値を複製したい場合は.cloned()が必要となる それを無しにすると以下のように各要素への参照のベクタが得られる fn reverse_reference<T>(input: &[T]) -> Vec<&T> { input .iter() // 各要素への参照を巡るイテレータ .rev() // それを逆順に巡る .collect() // それらの参照を今回は返り型で指定のVecへ収集 } このように抽象化された各パーツを組み合わせることで 可読性と安全性と高速実行を両立させている http://mevius.5ch.io/test/read.cgi/tech/1757733847/44
45: デフォルトの名無しさん [sage] 2025/09/17(水) 22:14:21.95 ID:Iu+PtAN6 改行CRとLFの真実：MS-DOS・BIOS・WIN10での挙動比較 https://qiita.com/earthen94/items/9c1a1fb8e1c7a2f32432 > Windows10 > '\r'で行頭に戻ることは確認できましたが、'\n'では下の行に下がるだけでなく行頭に自動的に戻されてしまうようです。 '\n'で行頭に移動するのはC言語の仕様で「\n 改行（new line）現表示位置を次の行の最初の位置に移動する。」となってるからで、WindowsではユニバーサルCランタイム (UCRT)が標準出力をテキストモードでオープンしてるため '\n' が '\r' + '\n' に変換されるからで、さらに最近の Windows Terminal は '\n' の動作が行頭に移動するようなってるので、とか説明せんといかんのかな、メンドい。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/45
46: デフォルトの名無しさん [sage] 2025/09/17(水) 22:54:27.39 ID:Iu+PtAN6 せっかくなので>>44の関数のベンチマークをしてみた。 https://godbolt.org/z/KxYEdofWd reverse_value() のほうがちょっと速いのかな。 Rustって知らんけどblack_boxなんてあんのは面白いな。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/46
47: デフォルトの名無しさん [sage] 2025/09/17(水) 23:13:57.67 ID:2et8KGNs >>46 参照型つまりアドレスたぶん64bitを収容と i32型つまり32bitを収容のサイズの異なる比較になってしまってないかね？ http://mevius.5ch.io/test/read.cgi/tech/1757733847/47
48: デフォルトの名無しさん [sage] 2025/09/18(木) 00:40:20.60 ID:sD2s9VAq for でぐるぐる回すとこんな感じかな。 fn reverse_array<T: Clone>(input: &[T]) -> Vec<T> { let mut result = Vec::with_capacity(input.len()); for i in (0..input.len()).rev() { result.push(input[i].clone()); } result } https://godbolt.org/z/5dc1KaWsd http://mevius.5ch.io/test/read.cgi/tech/1757733847/48
49: デフォルトの名無しさん [sage] 2025/09/18(木) 01:41:40.32 ID:sD2s9VAq 出力の関数名間違ってたので訂正 https://godbolt.org/z/Kb7b3hc6P http://mevius.5ch.io/test/read.cgi/tech/1757733847/49
50: デフォルトの名無しさん [sage] 2025/09/18(木) 16:56:30.82 ID:E/kzpuoF >>44 元のGoのコードがintの配列扱ってるのにジェネリック化してCloneで効率下げてるのなんで?? http://mevius.5ch.io/test/read.cgi/tech/1757733847/50
51: デフォルトの名無しさん [sage] 2025/09/18(木) 17:45:09.89 ID:530bwAJW >>50 Rustのジェネリックは効率を下げなくて従来の型指定した時と全く同じように動作することが特徴です RustのCloneとは参照先から値を複製することです 例えば32bit数値の場合ならばCPUによるメモリ/レジスタ⇔メモリ/レジスタ間のロードやセーブが複製であって必ず行われることなので効率が下がることはありません http://mevius.5ch.io/test/read.cgi/tech/1757733847/51
52: デフォルトの名無しさん [sage] 2025/09/18(木) 23:44:30.13 ID:aCgogNys Rustが広まってる理由はC並みの高速実行をゼロコスト抽象化によるコードの可読性・保守性・開発効率の高さで実現したことにあるからね 安全性などはついでのオマケ http://mevius.5ch.io/test/read.cgi/tech/1757733847/52
53: デフォルトの名無しさん [sage] 2025/09/21(日) 18:14:05.85 ID:MlvLaXh2 再帰派、息してる? http://mevius.5ch.io/test/read.cgi/tech/1757733847/53
54: デフォルトの名無しさん [] 2025/09/21(日) 19:59:36.62 ID:kxRRh56H もれちんは再吃不能 http://mevius.5ch.io/test/read.cgi/tech/1757733847/54
55: デフォルトの名無しさん [sage] 2025/09/21(日) 19:59:57.80 ID:hyRHfdTv 天才すぎて再起不能 http://mevius.5ch.io/test/read.cgi/tech/1757733847/55
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 713 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.017s