Goのメソッドは構造体以外にでも定義できるしそれが便利なこともよくある - Qiita
いわゆる主流のオブジェクト指向言語しか知らない人からみると、クラスに相当するものはGoでは構造体で、メソッドに相当するのは構造体の型に対して定義されたメソッド、というように見えると思う。Goでコードを書いている時に、クラスという存在しない概念について考えても無意味なのだけど、頭のなかでそういうイメージで理解している場合、構造体以外の型にメソッドが定義できる意味がわからないと思う。 そこで、そういう人には多少目から鱗のような話かもしれないが、構造体以外にメソッドを定義して便利なケースをいくつか紹介したい。 カウンタ 単純なカウンタを設計しているとしよう。カウンタが持つメソッドはaddとdecの2つだけで、それらのメソッドはカウンタ値を変更して、新しい値を返すものとしよう。カウンタを構造体を使って実装するとこういうふうになる。 type counter struct { v int } fun
Goでは文字列連結はコストの高い操作 - Qiita
Goでは文字列は不変（immutable）なので、文字列への文字の追加は常に新しい文字列をアロケートすることになる。ランタイムはまず新しい文字列のためのメモリを割り当てて、そこに既存の文字列の内容をコピーし、新しい文字を最後に足すということを行う。 従って、文字列に+=演算子で文字列を追加していく操作は大変効率が悪い。Javaの文字列も同じだからJavaプログラマにとっては馴染みのある話だろうと思う。 文字列を構築する必要がある場合、[]byte型の値を作ってそれに文字列を追加していって、最後に値を文字列に変換するのがよい。 // サイズ0、内部バッファの長さ10の[]byteの値を割り当てる b := make([]byte, 0, 10) // bに文字列を追加 b = append(b, "foo"...) // ...が必要 b = append(b, "bar"...) retu
Cコンパイラをスクラッチから開発してみた（日記）
以前に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 前回もこのあたりはがんばって実装したからここまで作るのはわりと単純作業かも。二回目だから配列とか
GoでNewなんとかのような関数を不必要に提供しないほうが良い理由 - Qiita
構造体を定義して、それに対してメソッドを定義して、最後にその構造体をアロケートして初期化するNewなんとかという関数を用意する、というのを何の疑問も持たずに行っているならちょっと考えものだ。途中まではよいが、Newなんとかみたいなのは別に必須ではない。 メソッドとゼロ値 Goでは新しい値は「ゼロ値」で自動的に初期化される。ゼロ値は型ごとに違うが、数値なら0、文字列なら空文字列、ポインタやインターフェイスならnil、といった具合の値だ。構造体ならそれぞれのフィールドがゼロ値で初期化される。 メソッドはそのレシーバーの値のゼロ値に対して問題なく動くように書くほうがよい。構造体Tを割り当てて初期化する関数としてNewTみたいな関数を用意するのは、本当に初期化が必要なとき以外はやらないほうがよい。 なぜか、というといくつか理由がある。 NewTの代わりにnew(T)を使うようにすると、エクスポート
panicはともかくrecoverに使いどころはほとんどない - Qiita
Goを書いていてrecoverを使うことはまずほとんどない。頻繁にrecoverを書いているとしたらなにかが間違っているのでプログラミングスタイルを見直すこと。 Goでのエラーハンドリング Effective Goなどで説明されているように、Goではエラーは関数の返り値として返される。たとえばio.ReaderのRead関数は、読み込んだバイト数と、（nilかもしれない）エラーの2つの値を返す。Goでは基本的に、エラーは常にこういう通常の値としてハンドルするべきで、エラーの時のための特別な制御構造（try 〜 catch）のようなものを使うのは、利点より害のほうが多いという考え方をとっている。 （同じような考えで例外を使用禁止にしている大規模C++プログラムはいくつもある。たとえばChromiumなどはそうだ。LLVM/Clangもパフォーマンス上の問題で例外を使っていない。C++コンパイ
Goでスレッド（goroutine）セーフなプログラムを書くために必ず注意しなければいけない点 - Qiita
Goは言語機能として並列実行をサポートしているけど、Goで書いたからといって自動的にデータ構造がスレッドセーフになるわけではないので、スレッド安全性を気にしなければならないはこれまでの言語と変わらない。どういうケースが良くてどういうケースがダメなのかを理解していないと安全なプログラムは書けない。それについて説明をしよう。 まず第一にEffective Goのこの一文は覚えておこう。 Do not communicate by sharing memory; instead, share memory by communicating. メモリを共有することで通信しようとしないこと。代わりに通信することでメモリを共有すること。 変数の値を変更したあとにチャネルなどを使わずに、おもむろに別のgoroutineからその変数の値を読み書きしてはいけない。そういうやり方だと読み書き操作の前後関係がき
Goのtimeパッケージのリファレンスタイム（2006年1月2日）は何の日？ - Qiita
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日（エポック）から特定の時間が経過した日だとか、あるい
Goで不必要にメモリアロケーションの回数を増やさない方法 - Qiita
Goにはガベージコレクションがあるのでプログラマがメモリ管理を意識することは少ない。とはいえ無駄にメモリを割り当てまくるとそれだけメモリアロケータとガベージコレクタが走る回数が増えてプログラムが遅くなってしまう。効率の良いプログラムを書こうと思ったらある程度はどういうふうに値がメモリ上に確保されるのか意識することが必要だ。 メモリシステムへの負荷を下げるにはメモリの量だけではなく回数を減らすことが有効である。Goでは構造体のレイアウトは自分で制御できるし、interior pointer（オブジェクトの内部を指しているポインタ）を取得することもできるので、必要な値をまとめてメモリ上に確保することができる。具体的には次のように行う。 type encoder { buf []byte scratch [80]byte // その他のフィールド ... } func newEncoder()
Goでxxxのポインタを取っているプログラムはだいたい全部間違っている - Qiita
Goで、文字列、インターフェイス、チャネル、マップ、スライスのポインタを取っているプログラムは、書いた本人がきちんと自分がなにをしているのか理解しているのでなければ、ほぼ確実に間違っているといっていい。 Goではある種の型の値はそもそもポインタのようなものである。上記の型はどれも任意の大きさになり得るが、大きくなりうる実体のデータはヒープに確保されていて、値そのものが持っているのはそのヒープ上への値へのただのポインタ＋多少の付随的なデータにすぎない。こういった値を値渡しではなくポインタ渡しする必要はない。ポインタのデリファレンスのほうがポインタのコピーより高くつくし、余計な混乱を引き起こすだけだからだ。もしこういう値をポインタ渡ししているとしたら、そのコードはなにか深い意味があるのではなく、それを書いた人が大きな値がコピーされると勘違いしていて書いた可能性のほうがずっと高い。 文字列は2ワ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Goの変数名が短い理由（あるいはGoがほかの言語と違う理由） - Qiita