サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
都知事選
qiita.com/ruiu
GoのIO関係の関数は、読んだデータの長さとエラーの両方を同時に返す。もしデータの長さが0でなければ、エラーがあったとしても、読んだぶんはきちんと処理しなければいけない。たとえば次のようなコードは間違いだ。
Goroutineを複数使って並列で処理を行って、それがすべて完了したら次に進みたいとしよう。Goroutineの完了はそれを生成したgoroutineに通知されるわけではないので、メインのgoroutineは何らかのメカニズムを使って全員が完了するまで待って、全員が完了したら実行を再開する必要がある。 sync.WaitGroupは複数のgoroutineの完了を待つための値だ(Javaを知っていれば、java.util.concurrent.CountDownLatchによく似ている)。WaitGroupの値に対してメソッドWaitを呼ぶと、WaitGroupが0になるまでWaitはブロックされる(待たされる)。従って、やりたい処理の数だけWaitGroupの値をインクリメントしておいて、処理完了時にデクリメントすれば、Waitを呼んで処理完了を待っているメインのgoroutineは、
Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up
Goのフルスライス式を使うと、スライシングするときにキャパシティを指定することができる。 普通のスライス式ではスライスした範囲を超えて配列の値にアクセスしたり変更することができる。 a := make([]int, 100) // 長さ100の配列 s := a[0:10] // 長さ10のスライスsを切り出す t := s[0:100] // sからsより長いスライスtを切り出す 上のようにすると、短いスライスから長いスライスを切り出して、元の配列の本来触れてほしくなかったところもアクセスできてしまう。組み込み関数のappendはキャパシティがある限り元の配列を上書きすることになっているので、appendとサブスライスを使っていると知らない間にオーバーランしてしまっていることもありえる。 フルスライス式を使うとそのようなことを防止できる。
Goroutineには内部的にIDが振られているけど、そのIDをGoから取得するAPIは提供されていない。一般に複数のgoroutineが走っている時、今どのgoroutineから実行されているのかを実行時に知る方法はない。 これが不便だという話がたまに出てくるようだ。こないだはデバグ時などに使うためにgoroutineに名前をつけられるようにしようという提案がgolang-devに投げられていた。 これはリジェクトされたのだが、なぜかというと、そういう機能は確かに便利でもあるだろうけど、それを提供するとgoroutineの状態に依存したコードを書くのにも使われてしまうから。 Goroutineにローカルな状態に依存したコードは安全ではない(1つのgoroutineからしか呼べない)。たとえば「UIのAPIはメインスレッドから呼んでください」というふうな感じになる。これはgoroutine
いわゆる主流のオブジェクト指向言語しか知らない人からみると、クラスに相当するものはGoでは構造体で、メソッドに相当するのは構造体の型に対して定義されたメソッド、というように見えると思う。Goでコードを書いている時に、クラスという存在しない概念について考えても無意味なのだけど、頭のなかでそういうイメージで理解している場合、構造体以外の型にメソッドが定義できる意味がわからないと思う。 そこで、そういう人には多少目から鱗のような話かもしれないが、構造体以外にメソッドを定義して便利なケースをいくつか紹介したい。 カウンタ 単純なカウンタを設計しているとしよう。カウンタが持つメソッドはaddとdecの2つだけで、それらのメソッドはカウンタ値を変更して、新しい値を返すものとしよう。カウンタを構造体を使って実装するとこういうふうになる。 type counter struct { v int } fun
Goには三項演算子?:は存在しない。Cの派生言語(C++とかJava)だと三項演算子はわりと頻繁に使われるものだと思う。三項演算子を使いたいところでGoではどう書けばいいのか戸惑うことがあると思うので、三項演算子の代わりの書き方を紹介したい。 上記のコードはx := condition ? 1 : 0と同じだ。デフォルトの値がリテラルの数値や文字列などの計算にコストがかからないものであれば、上のパターンを使うのが普通だと思う。 もしデフォルトの値が関数呼び出しの結果などで、その値を得るコストが高い場合、デフォルト値を得てから再度上書きするのは無駄が多い。そういう場合には下のように書くしかない。
Goでは文字列は不変(immutable)なので、文字列への文字の追加は常に新しい文字列をアロケートすることになる。ランタイムはまず新しい文字列のためのメモリを割り当てて、そこに既存の文字列の内容をコピーし、新しい文字を最後に足すということを行う。 従って、文字列に+=演算子で文字列を追加していく操作は大変効率が悪い。Javaの文字列も同じだからJavaプログラマにとっては馴染みのある話だろうと思う。 文字列を構築する必要がある場合、[]byte型の値を作ってそれに文字列を追加していって、最後に値を文字列に変換するのがよい。 // サイズ0、内部バッファの長さ10の[]byteの値を割り当てる b := make([]byte, 0, 10) // bに文字列を追加 b = append(b, "foo"...) // ...が必要 b = append(b, "bar"...) retu
Goでは言語組み込みの並行処理のサポートがあるから、一定の周期で何らかの処理を行うのは簡単だ。その処理のためのgoroutineを作って、それを一定の間隔で目覚させて実際の処理を行わせるようにすれば良い。 Sleep 一番簡単な方法は無限ループを回して、ループの最後にtime.Sleepで一定時間休むという方法だろう。 go func() { for { // ここでなにかを行う time.Sleep(3 * time.Second) // 3秒休む } }() この方法は手っ取り早いけど、Sleepを途中で中断することはできない。たとえばこのgoroutineがいらなくなったときにそれをチャネルで通知してgoroutineを終了させるとか、あるいは早めに目覚めさせてループの先頭に復帰させるとか、そういったことはSleepが返ってくるまで行うことができない。 Ticker 「多重化できない
以前に8ccというCコンパイラをゼロからひとりで開発していたときのログです。40日でセルフコンパイルできるところまで到達しています。日付はすべて2012年です。コードとヒストリはすべてGitHubで見れます。 3月4日 というわけでコンパイラを作っているわけだけど、1000行くらい書いたらそれなりに動き始めてきた。こんなのも動くし: int a = 1; a + 2; // => 3 こういうのも通る。 int a = 61; int *b = &a; *b; // => 61 文字列は文字の配列として扱っていて、配列をポインタに成り下げる振る舞いも実装しているので、こういうのも通る。関数呼び出しもある。 char *c= "ab" + 1; printf("%c", *c); // => b 前回もこのあたりはがんばって実装したからここまで作るのはわりと単純作業かも。二回目だから配列とか
構造体を定義して、それに対してメソッドを定義して、最後にその構造体をアロケートして初期化するNewなんとかという関数を用意する、というのを何の疑問も持たずに行っているならちょっと考えものだ。途中まではよいが、Newなんとかみたいなのは別に必須ではない。 メソッドとゼロ値 Goでは新しい値は「ゼロ値」で自動的に初期化される。ゼロ値は型ごとに違うが、数値なら0、文字列なら空文字列、ポインタやインターフェイスならnil、といった具合の値だ。構造体ならそれぞれのフィールドがゼロ値で初期化される。 メソッドはそのレシーバーの値のゼロ値に対して問題なく動くように書くほうがよい。構造体Tを割り当てて初期化する関数としてNewTみたいな関数を用意するのは、本当に初期化が必要なとき以外はやらないほうがよい。 なぜか、というといくつか理由がある。 NewTの代わりにnew(T)を使うようにすると、エクスポート
Goを書いていてrecoverを使うことはまずほとんどない。頻繁にrecoverを書いているとしたらなにかが間違っているのでプログラミングスタイルを見直すこと。 Goでのエラーハンドリング Effective Goなどで説明されているように、Goではエラーは関数の返り値として返される。たとえばio.ReaderのRead関数は、読み込んだバイト数と、(nilかもしれない)エラーの2つの値を返す。Goでは基本的に、エラーは常にこういう通常の値としてハンドルするべきで、エラーの時のための特別な制御構造(try 〜 catch)のようなものを使うのは、利点より害のほうが多いという考え方をとっている。 (同じような考えで例外を使用禁止にしている大規模C++プログラムはいくつもある。たとえばChromiumなどはそうだ。LLVM/Clangもパフォーマンス上の問題で例外を使っていない。C++コンパイ
Goでキューを実装するのには特別なデータ構造は必要がない。ただのスライスを使って、キューに加えるにはappend、キューから取り出すにはスライシングを使えば十分だ。キューが空かどうかはlenが0かどうかを調べれば良い。 // int型のキューを作成 q := make([]int, 0) // キューに1, 2, 3を追加 q = append(q, 1) q = append(q, 2) q = append(q, 3) // 最初の値を取得 v1 := q[0] q = q[1:] // 次の値を取得 v2 := q[0] q = q[1:] つまりスライスqの指している場所をqの内部配列の右側にどんどんずらしていくようなイメージだ。内部配列は必要に応じて再割り当てされるのでキューがあふれることはないし、再割り当ての際に左側の参照されていない領域は捨てられる(コピーされない)のでメモリ
Goにはガベージコレクションがあるのでプログラマがメモリ管理を意識することは少ない。とはいえ無駄にメモリを割り当てまくるとそれだけメモリアロケータとガベージコレクタが走る回数が増えてプログラムが遅くなってしまう。効率の良いプログラムを書こうと思ったらある程度はどういうふうに値がメモリ上に確保されるのか意識することが必要だ。 メモリシステムへの負荷を下げるにはメモリの量だけではなく回数を減らすことが有効である。Goでは構造体のレイアウトは自分で制御できるし、interior pointer(オブジェクトの内部を指しているポインタ)を取得することもできるので、必要な値をまとめてメモリ上に確保することができる。具体的には次のように行う。 type encoder { buf []byte scratch [80]byte // その他のフィールド ... } func newEncoder()
Goのリフレクション(reflect)を使うと構造体のフィールドのリストやインターフェイスのメソッドセットを取得することができる。しかし定義されている関数のリストを取得することはできない。reflectはそういう機能を提供していないのである。 どうも、設定ファイルから関数名を読んで、その関数を呼び出すといったことをやりたいといったような話が定期的にあがってくるようだ。たしかにそういうことができれば便利かもしれないが、そういう機能を提供していないのにはきちんとした理由がある Goでは使われていない関数は最終的なバイナリには入らない。定義されているけどどこからも呼ばれていない関数というのは最初から書いていないのと同じだ。逆に言うと、コンパイラとリンカに関数を削除するという最適化を許すためには、関数一覧を取得するという機能があったりすると困るのである。 では実際に使われている関数だけの一覧を取得
posted articles:Go:91%C:3%プログラミング:3%compiler:3%testing:3%
Goで複数の仕事があるとして、goroutineを新たに作成してそれに1つ1つの仕事を任せるのは普通のやり方だと思う。たとえばクライアントからの接続を待っているサーバをGoで書いているとして、クライアントからのリクエストごとにgoroutineを起動してその後のやりとりを任せるといったようなパターンは普通だ。 そういったパターンでリクエストが多いと、どんどんgoroutineが起動してしまってメモリが足りなくなることがある。そういった場合に、goroutineの起動を待たせて、最大でもある一定数以上はgoroutineが並行して走っていないようにしたいことはよくあるのだが、そのためにはどうしたらよいだろうか? 一般的なやり方はチャネルを「残りいくつのgoroutineを起動してよいか」という値(セマフォ)として使う方法である。 チャネルを作成するときにチャネルのバッファサイズを決めることが
Goのtimeパッケージのフォーマットは独特だ。普通のUnixのstrftimeとかだとフォーマット文字列は%Yとか%mといった文字列なのだけど、Goの場合はそのかわりにある種の「サンプル文字列」を与えるという仕組みになっている。 たとえば次の文字列はGoでは時刻の正しいフォーマット文字列だ。 %Y(年)の代わりに"2006"、%b(月の名前)の代わりに"Jan"と書くといったルールになっている。"%Y-%m-%d"の代わりに"2006-01-02"と書くのは見た目にわかりやすいといえばわかりやすいが、"2006年1月2日15時04分05秒"以外の時刻は正しいフォーマット文字列としては認識されない。2006の代わりに2007とか書いても意味がない。 では一体この2006年1月2日という特別な日は、なんの日なのか? 最初は1970年1月1日(エポック)から特定の時間が経過した日だとか、あるい
チャネルに何かの値を送信したいけど、チャネルのバッファがすでに一杯ならそれ以上は送りたくない(送信待ちでブロックしたくない)という状況がある。 たとえば設定の再読み込みの責任を担っているgoroutineがいるとしよう。そのgoroutineは普段はあるチャネルで何か値が送られてくるのを待っていて、値が送られてくると動作を再開して、設定をどこかから読み込む(そのあとロックを獲得してグローバルな設定データを更新するというのが普通だが、それはここでは関係がない)。 さて、そういうgoroutineでは複数回連続して動作するのは通常特に意味がない。従って、設定再読み込みリクエストは1個でも2個でもどちらでもよくて、むしろ複数個連続してチャネルに値が送信されても1個しかキューされないようにしたいだろう。 そういうふうな動作を実現するには下のコードのようにすれば良い。 // バッファサイズ1のチャネ
Goの正規表現はRuss Coxさんの書いたre2が元になっている。re2はよくできた正規表現エンジンなのだけど、一つほかの正規表現エンジンに見られる機能が欠けている。バックリファレンスがないのだ。 ほかの正規表現エンジンではカッコでキャプチャした文字列を番号を指定して正規表現中でもう一度使うことができて、/(\w+) \1/というようなパターンを書くことができる。このパターンは(\w+)にマッチするもの(たとえば単語)に続いて空白文字列があって、さらに()の内容と同じ文字列があること、という条件になる。たとえばこれは"foo foo"はこのパターンにマッチするけど(最初の"foo"が繰り返しているので)、"foo bar"はマッチしない("foo"と"bar"は違うので)というわけだ。 バックリファレンスがないのは欠点に思えるが(実際に不便なときもないわけではないが)、しかしこれはGoの
Goでは一応エスケープ解析をしていて、小さな値はnewで割り当ててもリテラルの構造体として書いても、スタックに割り付けることが可能ならスタックに割り付けることになっている。 スタックは関数呼び出しがリターンすると捨てられる(ゴミ扱いになる)領域なので、値をそこに割り当てるのは、ヒープに割り当てるのに比べて大変効率が良い。割り当てるのも速いし、GCがあとで回収する手間もかからない。 (ただしそういう値が関数からリターンした後に参照されては困るので、そういう値へのポインタなどが関数から逃げ出さないことをコンパイル時に静的に検証している ―― それがエスケープ解析。) しかし大きな値(数百バイト〜)は、エスケープしないとしてもヒープに割り当てられてしまう。そうでなければスタックが成長しすぎて、それはそれでまた問題になるからだ。 頻繁に呼び出される関数で大きな値をテンポラリに使っていると、GCで回
Goではintのサイズはアーキテクチャによって異なり、32ビットか64ビットのどちらかということになっている。32ビットのx86では32ビットだし、x86-64では64ビットだ。ときどきビット演算などでintのサイズがどちらなのかを知りたいことがある。そういうときにはどうすればいいだろうか? 結論から先に言うと次の式を使うとintSizeはアーキテクチャに応じて32か64のどちらかになる。 uintとintは最上位ビットが符号ビットとみなされるかどうかという違いがあるだけで、同じサイズであることが保証されている。uint(0)は型なしの定数0をuintに型変換しているので、その値は32ビットか64ビットのどちらかの符号なし整数0になる。^は単項演算子のXORなので、ビットが反転されて、^uint(0)は32ビットか64ビットのすべてのビットが1の値ということになる。これを63ビット右にシフ
CやC++ではatexit関数で関数を登録しておくと、プログラムの終了時にその関数を自動的に走らせることができる。そういう機能はRubyやPythonにもある。 Goにはそういう機能はない。実装を忘れているのではなくて、意図的にそういう機能を持たせていないのだ。これについてIan Lance Taylorさんが大変説得力のある説明をしていた。 まず第一に、どんなプログラムでも任意の箇所でクラッシュしうるし、まったくバグのないプログラムでもいきなりkillで殺されたりマシンが電源断で落ちるということがある。従ってどんなプログラムも、突然終了させられたあとに、もう一度きちんと動くことができなければならない。つまりatexitはきれいに終了するための機能ということで、atexitが呼び出されないとうまく動かないプログラムというのはそもそも間違っているということになる。 大きなC++プログラムでは
Goは言語機能として並列実行をサポートしているけど、Goで書いたからといって自動的にデータ構造がスレッドセーフになるわけではないので、スレッド安全性を気にしなければならないはこれまでの言語と変わらない。どういうケースが良くてどういうケースがダメなのかを理解していないと安全なプログラムは書けない。それについて説明をしよう。 まず第一にEffective Goのこの一文は覚えておこう。 Do not communicate by sharing memory; instead, share memory by communicating. メモリを共有することで通信しようとしないこと。代わりに通信することでメモリを共有すること。 変数の値を変更したあとにチャネルなどを使わずに、おもむろに別のgoroutineからその変数の値を読み書きしてはいけない。そういうやり方だと読み書き操作の前後関係がき
Goで、文字列、インターフェイス、チャネル、マップ、スライスのポインタを取っているプログラムは、書いた本人がきちんと自分がなにをしているのか理解しているのでなければ、ほぼ確実に間違っているといっていい。 Goではある種の型の値はそもそもポインタのようなものである。上記の型はどれも任意の大きさになり得るが、大きくなりうる実体のデータはヒープに確保されていて、値そのものが持っているのはそのヒープ上への値へのただのポインタ+多少の付随的なデータにすぎない。こういった値を値渡しではなくポインタ渡しする必要はない。ポインタのデリファレンスのほうがポインタのコピーより高くつくし、余計な混乱を引き起こすだけだからだ。もしこういう値をポインタ渡ししているとしたら、そのコードはなにか深い意味があるのではなく、それを書いた人が大きな値がコピーされると勘違いしていて書いた可能性のほうがずっと高い。 文字列は2ワ
このページを最初にブックマークしてみませんか?
『@ruiuのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く