cgoを使ったCとGoのリンクの裏側 (1) - Qiita
cgoを用いるとCのライブラリをGoバイナリにリンクしたり、Goパッケージの一部をCで書いたりできる。更にGo 1.5以降では、GoのパッケージをC用の静的ライブラリまたは動的ライブラリにまとめておいて、Cからリンクすることもできる。 これらの機能はすべてgo buildコマンドに統合されているので、普段は特にcgoを使っていることを意識することは少ない。しかし、pure goのコードのビルドにしたところでその裏側ではコンパイラ、アセンブラ、リンカが走っているわけである。ではcgoの場合をこの水準で見るとどのような処理が行われているのだろうか。 要は、gcc(1)の裏ではcc1, as, collect2なんかが走ってるよね、cgoではどうなってるの? という話が本稿の話題である。 なお、Goのオブジェクトファイルがプラットフォーム独立な(ELFとかではない)フォーマットであることや、Go
初心者エンジニアにおすすめしたい「進捗どうなった？」と言われないための仕事の進め方 - Qiita
はじめに 初心者エンジニアのあなたは、 **先輩エンジニアに「進捗どうなった？」や「なんでこの作業にこんな時間かかってるの？」**といったことを言われたことはありませんか？ また、 作業見積もりやタスク分解をちゃんと行なわないで、いきなりコードを書き始めているということはありませんか？ 勝手にコードを書き始めて、ほとんど手戻りになって1からコードを書き直しになるという経験もあるかと思います。 僕は徹底的に仕事のやり方を叩きこまれましたが、周りの話を聞いていると、こういったことができていない人もいるのかなと思い書こうと思った次第です。 またエンジニア向けには書いていますが、どんな仕事にも普遍的に使える考え方だと思っているので参考になれば幸いです。 アジェンダ 以下のとおりです。どこから読んでもらっても大丈夫ですが、上から読んでいったほうが流れが分かりやすいと思います。 ツールはGithub,
汎用的なコードの依存関係の抽出ツール rexdep を作りました！ ― 正規表現で依存関係を大雑把に抽出しよう！ - プログラムモグモグ
あらすじ ソフトウェアの中の依存関係について 正規表現で抽出できることとその限界 コードの依存関係を抽出するツール rexdep を作りました ソフトウェアの構造を概観するには あなたは、大きなソフトウェアを目にした時、何をしますか？ ファイルが何十、何百もある時、どこから読みますか？ ソフトウェアが巨大になると、そのコードの構造を把握するのは難しくなります。 特にプロジェクトに入りたての人にとって巨大なコードベースを一目で理解することは難しく、細かなタスクをこなしていく中で徐々に「どこに何が書いてあるか」を理解していくしかありません。 ソフトウェアによってはモデルとコントローラ、データベースとビューと言った具合にコードが分かれており、これくらいの分類はディレクトリ名を見れば理解できるかもしれません。 しかしそのようなざっくりとしたコードの分類が分かったところで、ソフトウェアの構造を理解し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.north-geek.com/entry/programming-rookie
