いやなブログ: Linux の共有ライブラリを作るとき PIC でコンパイルするのはなぜか
Linux の共有ライブラリを作るとき PIC でコンパイルするのはなぜか 通常、Linux の共有ライブラリを作るときは各 .c ファイルを PIC (Position Independent Code) となるようコンパイルします。しかし、実は PIC でコンパイルしなくても共有ライブラリは作れます。それでは PIC にする意味はあるのでしょうか。 さっそく実験してみます。 int func () { printf(""); printf(""); printf(""); } PIC でコンパイルするには gcc に -fpic または -fPIC を渡します。-fpic の方が小さく高速なコードを生成する可能性がありますが、プロセッサによっては -fpic で生成できる GOT (Global Offset Table) のサイズに制限があります。一方、-fPIC はどのプロセッサで
問題を再現させる - 学校では教えてくれないバッドノウハウ英語 #5 - bkブログ
問題を再現させる - 学校では教えてくれないバッドノウハウ英語 #5 学校では教えてくれないバッドノウハウ英語の5回は、"reproduce" と "reproducible" を取り上げたいと思います。バグ報告のやり取りの際に役立つ表現です。 エラーを再現させる、という意味での「再現させる」は英語では "reproduce" という動詞を使います。問題を再現させることはデバッグの基本ですが、報告を受けたバグが手元では再現しないことはよくあります。そのようなときは "I can't reproduce the error" (そのエラー再現できんかったよ) と相手に伝えるといいでしょう。 例) I tried the same configuration you used, but couldn't reproduce it. お前と同じ設定を試してみたけど、再現しなかったよ。 A way
バッドシグナル通信 - バッドなコーディング
最終更新日: 2010-01-10 WEB+DB PRESS Vol. 55 に向けて書いた記事の元の原稿です。 ソフトウェア開発における危険信号「バッドシグナル」についての本連載、最終回の今回はコーディングをバッドなものにする要因について検討してみたいと思います。 三度の飯よりコーディングが好き！という人でも、気乗りのしないコーディングというものもあると思います。コードを書くという作業自体はそれほど変わらないはずなのに、何が原因で退屈だったり苦痛だったりするバッドな作業になってしまうのでしょうか。 何をバッドと感じるかは個人差があると思いますが、ここでは私がバッドと感じる要因を見ていきたいと思います。プロジェクトがそもそも好きじゃない、メンテナと仲が悪いといった人間的な要因は今回は除外しました。 待ち時間長過ぎ 待ち時間の長いコーディングはいやなものです。たとえばビルドに何十分もかかるよ
Unicode の雪だるま - bkブログ
Unicode の雪だるま Unicode Snowman for You というサイトを知りました。Unicode の雪だるま (U+2603 SNOWMAN ☃) が表示されるだけのサイトです。が、ソースを見ると font-face で EOT 形式のウェブフォントが使われていることに気づきました。 この EOT (Embedded Open Type) 形式のウェブフォントは IE しか対応していないようです。IE で表示するとこのような雪だるまが表示されました。これはおそらく Arial Unicode MS の雪だるまです。ちょっとこわいような。。 一方、他のブラウザで表示すると、このような雪だるまが表示されました。これは私がデフォルトのフォントに設定しているメイリオの雪だるまです。これはかわいい。意外なところにも力が入っています。
研究と研究マネジメント - bkブログ
研究と研究マネジメント 以前、情報系の教授全般について次のような疑問を感じていたことがある。昔はばりばりの研究者・ハッカーだったはずなのに、なぜ教授になる頃には自分で手を動かして研究しなくなるのだろうか。この疑問は、ときが経つにつれていつのまにか解消されていった。 先日、ある大学生と話していたときに、同じような疑問を感じていることがわかったので、自分の疑問が解消された理由を話した。ひとつの見方に過ぎないが、ここにまとめてみたい。 ここでは 2人の人物を設定する。30歳の研究者 A と 50 歳の研究者B がいる。2人は年功ベースで給与が決まる大学に所属している。そのため、年の開きに応じて、B は A の2倍の給料をもらっている。単純化のために大ざっぱに言えば、B は Aより 2倍の給料をもらっている以上、2倍の価値を出す必要がある。 もし 2人を純粋に研究者として評価するなら、B は A
ある程度の年齢を迎えたプログラマが抱える悩み - bkブログ
ある程度の年齢を迎えたプログラマが抱える悩み ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。 この問題のひとつの解決策は、プログラマ以外の仕事のポジション（たとえば管理職など）に移ることですが、他のポジションには向いていない、まだまだ現役でプログラマをやりたいという場合にどんな戦略があるか考えてみました。なお、後述するように、以下に挙げた戦略は相反するものではなく、組み合わせが可能です。 エキスパート戦略 この分野ではトップクラス、というレベルの専門性を身につけ、その分野に特化してキャリアを築くという戦略です。たとえば、ネットワークやセキュリティといった分野で一流と認められる専門
いやなブログ - スクリプト言語用のデバッガの使い方 - Ruby, Python, Perl
スクリプト言語用のデバッガの使い方 - Ruby, Python, Perl スクリプト言語用の CUIのデバッガの使い方を簡単にまとめました。対象言語は Ruby, Python, Perl です。 私は C, C++ でプログラムを書いているときはデバッガ (主に GNU/Linux 上の gdb) を頻繁に利用します。しかし、スクリプト言語ではそれほどでもありません。これはおそらく次のような理由によります。 ビルドが不要なので printf デバッグが容易 (ある程度大きい C++ のプログラムではビルド時間が長いので printf の挿入はしんどい) 異常終了時にスタックトレースが表示される (Ruby, Python なら自動、Perl の場合は use Carp; $SIG{__DIE__} = \&Carp::confess; など) オブジェクトのインスペクトが簡単 (Ru
いやなブログ - 文字列操作の比較表: Ruby, Python, JavaScript, P...
文字列操作の比較表: Ruby, Python, JavaScript, Perl, C++ Ruby, Python, JavaScript, Perl, C++ の文字列操作の比較表を作りました。配列操作の比較表の続編です。間違いなどがあったらご指摘いただけると助かります。 Ruby (String) Python (str) JavaScript (String) Perl C++ (std::string)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
