Goで不必要にメモリアロケーションの回数を増やさない方法 - Qiita
Goにはガベージコレクションがあるのでプログラマがメモリ管理を意識することは少ない。とはいえ無駄にメモリを割り当てまくるとそれだけメモリアロケータとガベージコレクタが走る回数が増えてプログラムが遅くなってしまう。効率の良いプログラムを書こうと思ったらある程度はどういうふうに値がメモリ上に確保されるのか意識することが必要だ。 メモリシステムへの負荷を下げるにはメモリの量だけではなく回数を減らすことが有効である。Goでは構造体のレイアウトは自分で制御できるし、interior pointer（オブジェクトの内部を指しているポインタ）を取得することもできるので、必要な値をまとめてメモリ上に確保することができる。具体的には次のように行う。 type encoder { buf []byte scratch [80]byte // その他のフィールド ... } func newEncoder()
定義されている関数のリストをリフレクションを使っても取得できない理由 - Qiita
Goのリフレクション（reflect）を使うと構造体のフィールドのリストやインターフェイスのメソッドセットを取得することができる。しかし定義されている関数のリストを取得することはできない。reflectはそういう機能を提供していないのである。 どうも、設定ファイルから関数名を読んで、その関数を呼び出すといったことをやりたいといったような話が定期的にあがってくるようだ。たしかにそういうことができれば便利かもしれないが、そういう機能を提供していないのにはきちんとした理由がある Goでは使われていない関数は最終的なバイナリには入らない。定義されているけどどこからも呼ばれていない関数というのは最初から書いていないのと同じだ。逆に言うと、コンパイラとリンカに関数を削除するという最適化を許すためには、関数一覧を取得するという機能があったりすると困るのである。 では実際に使われている関数だけの一覧を取得
Google グループ
Google グループでは、オンライン フォーラムやメール ベースのグループを作成したり、こうしたフォーラムやグループに参加したりすることで、大勢のユーザーと情報の共有やディスカッションを行うことができます。
Goでスレッド（goroutine）セーフなプログラムを書くために必ず注意しなければいけない点 - Qiita
Goは言語機能として並列実行をサポートしているけど、Goで書いたからといって自動的にデータ構造がスレッドセーフになるわけではないので、スレッド安全性を気にしなければならないはこれまでの言語と変わらない。どういうケースが良くてどういうケースがダメなのかを理解していないと安全なプログラムは書けない。それについて説明をしよう。 まず第一にEffective Goのこの一文は覚えておこう。 Do not communicate by sharing memory; instead, share memory by communicating. メモリを共有することで通信しようとしないこと。代わりに通信することでメモリを共有すること。 変数の値を変更したあとにチャネルなどを使わずに、おもむろに別のgoroutineからその変数の値を読み書きしてはいけない。そういうやり方だと読み書き操作の前後関係がき
Goでxxxのポインタを取っているプログラムはだいたい全部間違っている - Qiita
Goで、文字列、インターフェイス、チャネル、マップ、スライスのポインタを取っているプログラムは、書いた本人がきちんと自分がなにをしているのか理解しているのでなければ、ほぼ確実に間違っているといっていい。 Goではある種の型の値はそもそもポインタのようなものである。上記の型はどれも任意の大きさになり得るが、大きくなりうる実体のデータはヒープに確保されていて、値そのものが持っているのはそのヒープ上への値へのただのポインタ＋多少の付随的なデータにすぎない。こういった値を値渡しではなくポインタ渡しする必要はない。ポインタのデリファレンスのほうがポインタのコピーより高くつくし、余計な混乱を引き起こすだけだからだ。もしこういう値をポインタ渡ししているとしたら、そのコードはなにか深い意味があるのではなく、それを書いた人が大きな値がコピーされると勘違いしていて書いた可能性のほうがずっと高い。 文字列は2ワ
Goにatexitやグローバルなデストラクタがない理由 - Qiita
CやC++ではatexit関数で関数を登録しておくと、プログラムの終了時にその関数を自動的に走らせることができる。そういう機能はRubyやPythonにもある。 Goにはそういう機能はない。実装を忘れているのではなくて、意図的にそういう機能を持たせていないのだ。これについてIan Lance Taylorさんが大変説得力のある説明をしていた。 まず第一に、どんなプログラムでも任意の箇所でクラッシュしうるし、まったくバグのないプログラムでもいきなりkillで殺されたりマシンが電源断で落ちるということがある。従ってどんなプログラムも、突然終了させられたあとに、もう一度きちんと動くことができなければならない。つまりatexitはきれいに終了するための機能ということで、atexitが呼び出されないとうまく動かないプログラムというのはそもそも間違っているということになる。 大きなC++プログラムでは
欧米のYAPCの問題点とイベント運営について僕の考え : D-7 <altijd in beweging>
今年のYAPC::Asia Tokyo 2014は海外ゲストの方々と色々話す機会があったのでかなりの時間彼らと話していた。 特にスピーカーの方々とは「日本人に受けるためにはどういうアプローチがいいんだ」という相談をYAPC期間中に（今更！）聞かれて 「日本人は証拠として数値の提示を求める傾向があるから、数値をもっと盛り込め」とか「おまえらの会社日本だと全然知られてないんだからまずそこから変えろ」とか等々の助言をして大分彼らのトークの内容を微調整する業務があった。特にDBICのトークは（見てないけど）YAPC::EUでやったものと全く内容が違う、という報告をスピーカー本人にもらった。ははは、通訳の人たちに迷惑かけたかなーw ともあれ、その流れで海外のYAPCの話。今回話した人たち全員から 「なんでYAPC::Asiaはこんなに人が集まるんだ？」「どうしたら俺たちのYAPC（EUにしろNAにし
株式会社はてなに入社しました | おそらくはそれさえも平凡な日々
本日は9月1日。エイプリルフールではなくて、防災の日です。 勤務地は東京の表参道ですが、今日から2週間だけ京都で働くので、新幹線の中でこのエントリを書いています。YAPCのトークでも話しましたが、東京で僕と一緒に働いてくれるエンジニアを絶賛募集中です。 長くなるのでとりあえずwishlistを置いておきますね。 http://www.amazon.co.jp/gp/registry/wishlist/3L07LJZVYI89C/ FA宣言したら20数社から連絡を頂いたんですが、その中からはてなを選ぶことにしました。はい。Perlの会社ですね。とは言えPerlは書かない予定です。とか言いつつちょいちょい書いてしまうことでしょう。 「Perlで、日本語の会社じゃねーか！」というツッコミが飛んできそうですが、はてなが一番自分を必要としてくれたと感じたので、入社させてもらうことにしました。こういう
atom-shell情報 - Qiita
atom-shellとはどういうもので、どのようにすれば動かせるのかということを調べているので、その過程で得られた情報をまとめておく。 atom-shellでデスクトップアプリをつくれる GitHub製のAtomというエディタはatom-shellというライブラリを利用して実現されている。atom-shellはJavaScriptでデスクトップアプリケーションをつくるための便利なライブラリで、ネイティブAPIを実行するための実行環境を提供することでそれを実現させようとしている。Webサーバの代わりにデスクトップアプリケーションに特化したNode.jsの実行環境だと考えても良いだろう。 atom-shellには2つの側面がある Node.jsでWebアプリを書いたことがあれば分かるかもしれないが、JavaScriptのコードにはサーバサイドで動かすためのものとクライアントサイドで動かすための
ECMAScript 6: what’s next for JavaScript? (August 2014)
Video: https://www.youtube.com/watch?v=G21rdWfa_as
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
@ruiuのマイページ - Qiita