Go で迷路ソルバーを書いた

2010-01-13

■[Go] Go で迷路ソルバーを書いた

今流行の迷路問題をプログラミング言語 Go で解いてみました。 Go 歴はほとんどないので勉強がてらにやりました。ソースは gist:275032 です。

アルゴリズムはダイクストラの簡略化版です。マス目にたどり着くまでの距離 (1 マスが 1) をゴールにたどり着くまでどんどんメモっていって、ゴールに達したら逆向きに、ゴールから 1 ずつ距離を減らして行くことでルートを確定する、という単純なやり方です。

実装にかかった時間はちゃんと測ってませんが、 Go の勉強しながらだったので 4 時間くらいだと思います。これでは試験には落第ですね!

以下 Go 言語の感想とか。

Vector の使い方がよく分からない。 int と string は特別扱いでそれ用の構造体 (IntVector、 StringVector) およびメソッドがありますが、あとは Vector 構造体を使っておけってことなんでしょうか。しかし値を取得するときに毎回動的キャスト*1するというのがとてもイケてません。 interface { } というものがそもそも何者なのかもよくわかりません。で、他の方の Vector の使い方を調べると *2、独自に型を定義してそれ用のメソッドを作ってあげることがどうやらセオリーのようです。うーん面倒くさい。 C# のジェネリクスのようなのが欲しいのですがー。
ビットの可変長配列を作るにはどうしたらよかったのだろう。今回は富豪的プログラミングということで IntVector を使った実装で済ましました。 (リファクタリング後、 int の配列になりました。) (さらにリファクタリングしたら無くなっちゃいました。)
関数のオーバーロードがない。意外。
演算子のオーバーロードがない。それゆえに独自構造体の == メソッドが定義できません。また、 Go の組み込み連想配列のキーは == が定義されていることが要求されています。三段論法でいうと、自分で定義した構造体は連想配列のキーには成り得ないことになります。
switch 文がフォールスルーしないというのは、 case をラベルと見立てると不自然なような気がします。 switch に関しては僕は C# の仕様が一番バランスしていると思います*3。
チャンネルは使ってないけど、今回の場合は使うと便利ってのはとくになさそう。
型が後置なのは慣れました。むしろこっちのほうが好き。
まだ自分にとって不透明な部分 (前述の interface { } など) が多く、サクサク書けるというのには至っていません。でも文法は C などよりスッキリしていていい感じです。