Qiita 7 - キータぞ、来たぞ、キータだぞー

**デフォルトの名無しさん** · 2025/09/13(土) 12:24:07.83

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/

**デフォルトの名無しさん** · 2025/09/14(日) 01:56:40.69

『【Go】配列を再帰的に逆順にするサンプルコードを書いてみた』
> 再帰を使うことで、ループを使わずにエレガントに実装できる。
　
根本的なところで誤解してる人な模様。

**デフォルトの名無しさん** · 2025/09/14(日) 02:53:44.41

>>2
一般論として
再帰で表現した方が抽象度が高く理解しやすく定義そのまま表現できることが多い
特に末尾再帰をコンパイラがループへ変換してくれて実行効率が同等ならば全ての点で再帰による表記が勝る

**デフォルトの名無しさん** · 2025/09/14(日) 12:10:16.28

入力配列と出力配列渡してループで処理するわ

**デフォルトの名無しさん** · 2025/09/14(日) 12:59:52.05

記事の再帰版のコードは

> 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
　　}
}

**デフォルトの名無しさん** · 2025/09/14(日) 13:06:57.84

記事のスライス操作版のコードは

> // ReverseArrayWithSlice はスライス操作で配列を逆順にする（再帰）
> func ReverseArrayWithSlice(arr []int) []int {
> 　　// ベースケース: 要素が1つ以下なら逆順にする必要なし
> 　　if len(arr) <= 1 {
> 　　　　return arr
> 　　}
>
> 　　// 最初の要素を取り出し、残りを再帰的に逆順にしてから結合
> 　　return append(ReverseArrayWithSlice(arr[1:]), arr[0])
> }

引数の配列内容を書き換えないし再帰を説明する上では面白い例だと思うが、パフォーマンスは最低だ罠。

**デフォルトの名無しさん** · 2025/09/14(日) 13:28:33.58

そもそもの話として、ひとつの記事の中で複数の関数が引数だとか配列の内容を書き換えるのかどうかとか仕様が合ってないから比較になってないのよね。

**デフォルトの名無しさん** · 2025/09/14(日) 13:42:25.65

>>7
問題はそこだね
ループでも書けるよとかの筋違いな批判は要らんて

**デフォルトの名無しさん** · 2025/09/14(日) 14:21:09.67

・引数は配列を渡すのみ
・内容を逆にした配列を返し、引数で渡した配列の内容は書き換えない
という条件にしたとして、繰り返しで書くより再帰のほうが良い書き方ができるだろうか?

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
}

「全ての点で再帰による表記が勝る」という人には再帰の素晴らしさをぜひ証明してほしいところだが口だけ番長だろうなあ。

**デフォルトの名無しさん** · 2025/09/14(日) 15:20:41.57

>>9
大昔からの古典すら知らない無知
LISPも知らないんだろうな

**デフォルトの名無しさん** · 2025/09/14(日) 15:24:57.73

GoとLISPの区別もつかない人とはなあｗ

**デフォルトの名無しさん** · 2025/09/14(日) 15:30:37.23

記事のスライス操作版のコードは

> // 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 {

とした方が良いな。

**デフォルトの名無しさん** · 2025/09/14(日) 15:35:06.93

試しに
・引数は配列を渡すのみ
・内容を逆にした配列を返し、引数で渡した配列の内容は書き換えない
再帰で書いてみたが

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で書いて披露してほしいものだ。

**デフォルトの名無しさん** · 2025/09/14(日) 17:50:25.98

ChatGPTに下記の質問投げたらそこそこ納得できる回答くれたわ。

「Go言語は末尾再帰はサポートされてるの?」
「末尾再帰最適化されないところでの再帰呼び出しは引数の範囲が不定だとスタックがどれくらい使われるかの予測はしづらいので要はGoでは引数の範囲が不定なところでの再帰呼び出しは使わない方が無難てことですね。」
「関数型言語で育った人とかで「再帰は繰り返し処理より常に正義」とかって人いるじゃない。ああいう人にはGoは辛いかもですね。」
「Lispにloopがサポートされても意地でも使わないとかの人いましたね。」

**デフォルトの名無しさん** · 2025/09/14(日) 18:13:30.88

>>6
何言ってんの爆速ですわ

**デフォルトの名無しさん** · 2025/09/14(日) 18:45:10.81

＞何言ってんの爆速ですわ
　
コードと実行結果のひとつでも挙げりゃ良いのだけど、それができない人がなんか言ってる感じｗ

**デフォルトの名無しさん** · 2025/09/14(日) 19:42:15.05

>>13
下手すぎ
最初に丸ごとcopyする時点でプログラミングのセンスがない

**デフォルトの名無しさん** · 2025/09/14(日) 19:59:01.07

丸ごとcopyしない>>17のセンスある実装に期待ｗ

**デフォルトの名無しさん** · 2025/09/14(日) 21:05:23.33

いつも的外れな記事批判を繰り返している連投クンは本気でわからないようだな
元データを改変せずに新たに逆順を返す再帰関数を書きたいのならば例えばこうする

func ReverseArray(input []int) []int {
if len(input) == 0 {
return nil
} else {
return append(ReverseArray(input[1:]), input[0])
}
}

**デフォルトの名無しさん** · 2025/09/15(月) 00:35:19.13

>>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

**デフォルトの名無しさん** · 2025/09/15(月) 00:39:24.47

エンジニアならベンチ結果で語るべきだよな！

**デフォルトの名無しさん** · 2025/09/15(月) 00:41:02.81

末尾再帰を自動的にループ化しないシステムもあれば
appendするだけで毎回ムダに新たに別メモリを確保してしまうシステムもある
Goは最悪だと実証された

**デフォルトの名無しさん** · 2025/09/15(月) 00:50:27.97

このクソ仕様がGoの敗因っぽいね

＞appendは毎回新たなスライスを生成します

**デフォルトの名無しさん** · 2025/09/15(月) 08:10:37.10

>>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 で繰り返した方が素直な感じ。

**デフォルトの名無しさん** · 2025/09/15(月) 08:16:11.29

ベンチマーク結果

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が案外良いのは恐らくは再帰呼び出しをループにする最適化が行われている感じ。

**デフォルトの名無しさん** · 2025/09/15(月) 08:27:46.98

ideone では Go のコンパイラが 1.12.1 と旧く、もっと新しい版(1.24.2)だと ReverseArray9 と ReverseArray24 の差は小さくなる模様。

https://godbolt.org/z/KW87qMWsf

出力コードも見ようとしたけどちょっと見る気起きないな。
main_ReverseArray19_pc0 の中で再帰呼び出ししてることは
> CALL main.ReverseArray19(SB)
確認したが。

**デフォルトの名無しさん** · 2025/09/15(月) 08:41:05.40

一番シンプルにわかりやすい>>19を再帰呼び出しのままは厳しいな
appendするたびに作り直すらしいGoの仕様が足を引っ張ってるのだろうか

**デフォルトの名無しさん** · 2025/09/15(月) 09:31:01.39

今のQiitaはこの程度の話すらコメ欄ではできないのがクソなんだよなあ。

**デフォルトの名無しさん** · 2025/09/15(月) 12:47:17.00

なんか同じパラメータでの呼び出しを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

キャッシュの影響ではなさそうだがなんぞコレ? こういうのは楽しい。