inforno :: Goのインタフェースがパフォーマンスに及ぼす影響
Go Advent Calendar 2015 その3 11日目です。その3まであるなんてGo大人気ですね。 Gopherというのはいろいろな人がいてLLからGoへ、という方も多いかと思います。 LLではそもそも全てがオブジェクトだったりで話題になりませんが、よりマシンに近く変態的に速度を重視される方が多いC++では例えば仮想関数や実行時キャストのコストが議論になります。 Goにおいてこういう多態性はインタフェースで表現されます。結論からいうと、 Goのインタフェースにもそれなりのコストがあります。 なので極限までパフォーマンスを要求される場合には 例えばインターフェースを使わない というも選択肢に入ってくるのではないかと思います。 Go言語におけるインタフェースの内部表現 さて、Goはブートストラップ化(言語処理系をその言語自身で実装する)を進めており、1.5ではGoのコンパイラ、ランタ
Goへの誤解について
よくGoで誤解されるポイントについて個人的な見解を書いておきます。 今回の記事はGoアドベントカレンダー2017 その3の20日目の記事です。 使ってないパッケージがコンパイルエラーって面倒じゃね？ さっさとgoimportsかgoreturnsを保存時に自動実行するエディタ環境を使いましょう。 gofmtも一緒に実行されていいことずくめですよ！ インターフェースがnil判定出来ないパターンがあるのダメじゃん？ 最初は私もそう思いました。しかし、typed-nilがnilリテラルと比較できなくなったのは 「nil判定サボったままinterface型に変換した」からでサボらなければ全く問題にならないのです。 map,sliceが不便？ map,sliceはメソッドが一切ありません。 極論をいうとGoのプリミティブ型みたいなものなのです。 ユーザーが欲しいものはmapやsliceを駆使して各自
nil だと思ってやつが nil じゃなかった - Go
Go の nil で完全に嵌ったのでメモ。 嵌りポイント 例えば、Revel の validator.go の中にこんな関数がいる。 func (r Required) IsSatisfied(obj interface{}) bool { if obj == nil { return false } if str, ok := obj.(string); ok { return len(str) > 0 } if b, ok := obj.(bool); ok { return b } if i, ok := obj.(int); ok { return i != 0 } if t, ok := obj.(time.Time); ok { return !t.IsZero() } v := reflect.ValueOf(obj) if v.Kind() == reflect.Slice
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
