2014年9月7日日曜日

Golang Cafe #45を開催しました。

Golang Cafe #45を開催しました。

今回も、3人での開催になりました。

内容は、急にqiitaに投稿された記事が気になったので、3人で読み進めてみました。
タイトルが「Goでxxxのポインタを取っているプログラムはだいたい全部間違っている」という、結構攻めた感じのタイトルだったので、食いついてしまいました。

内容としては、ポインタを使うのは良いが「自分が何をしているのか理解していない」のであれば、ポインタを使う意味がないということでした。
少し補足をすると、文字列、interface、channel、Map、sliceは「元からポインタ」なので、ポインタを使うと、「ポインタのポインタ」になってしまって、「直接参照すればいいのに何してるの?」ということになってしまう。ということです。

例えば、Mapだと、 +Takanobu Haginoさんのサンプルコードで確認すると、Mapは引数にポインタを渡さなくても、呼び出し先でMapに値を追加することができ、当然、呼び出し元でも追加されたものは反映されます。(=元からポインタということ)

fmt.Println()で書きだしてみると、channelもアドレスが出力されるのでやっぱりポインタだということがわかります。

従って、ポインタを使う時というのがどういう意図があるのかを明確にして使いましょう。ということでした。

次に、@lestrratさんの資料を読みました。
ここで議論になったのが、「intのバイト数が変わる」ということについて。

昔は、intという型はなく、int8、int16、int32、int64とビット数をつけた型だけがありました。(当然、byteもない。昔はint8と宣言していたけど、いつの間にかbyteを使うようになってしまった。これは大きさが変わらないので大丈夫。)

実際、intは”same size as uint"ということで、(個人的にはint32のaliasだと思っていたけど)uintと同じサイズの整数型という定義になります。
そこで、uintのサイズは何かというと、32bit or 64bitなので、goのコンパイラのビルド時に決まる。ということでしょうね。
(C言語のintと変わらず、どちらになるかわからないということ)

したがって、intのサイズが変わることでハマるよ。ということですから、明確にサイズが影響するなら、int32やint64の変数の型を使うようにするべきだろう。という結論になりました。(と私は理解している)

最後に、 +Takanobu Haginoさんのtextream解析ツールのソースコードを読みました。
非常にシンプルだったので、特に何か言わなければならないというものはなかったように思います。
構成としては、バックエンドでサイトの情報を取得して、フロントはgorillaを使ったWebサーバという構成で作られています。
いろんな便利なライブラリも使われていて、「実戦向き」のプログラムで非常に楽しく読ませていただきました。

最近、qiitaにGoogle Apps Scriptの記事を2個書いてましたが、Goに興味がないわけではなく、必要になった要求を簡単に満たせるのがGASだったということで、要求を満たしやすい言語を選ぶのがいいんだろうと思ったりしています。

次回(後2時間後)は、また最近話題になった記事とかソースコードレビューとか、何か作る時間にしたいと思います。