Unix風OSの上でプログラムを書いていると,場合に応じてコンパイラを切り替えたいときや,違うUnix系OSで使いたい場合があるよね?例えば普段はgccを使っておいて,デバッグが済んだらiccを使いたいとか,普段はLinuxなんだけどときどきはIRIXを使いたいとかね. 石器時代 こんなとき,大昔のプログラマはシステムごとにMakefileを用意したんだ.これを石器時代Makefileと呼ぼう.例えばgreetingというプログラムを書いていて,ソースコードが greeting.c と message.c に分かれていたとしよう.そうすると,石器時代Makefileはこんな感じだよね.(サンプルは GNU make が使える場合のもの.)
アルファベットは大文字と小文字を区別するので,Windows や MS-DOS では使えませんね。 で,試験的に(というか思い付くままに)ちゃらっと,書いてみる(ちゃらっと書いたら間違えていたので,修正しました)。 #include <limits.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/types.h> #include <sha256.h> int main(int argc, char *argv[]) { const char charIndex[] = "0123456789" "abcdefghijklmnopqrstuvwxyz" "ABCDEFGHIJKLMNOPQRSTUVWXYZ" "-_"; char *strSHA = NULL; char buf[3];
ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。 ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか? 閑話休題。 ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようにな
思った JavaScript はすぐに実行してみましょう! ブラウザの URL 入力欄に javascript:(function() { /*実行したいコードを書く*/ })()FireBug を使ってる人は、コンソール開いて実行したいコードを書く。 たとえばこんなことができます。 これらの例は僕が日頃使っているものです。 グローバルで使える関数を列挙する(Firefox Only) FireBug用 for(var n in window) if(typeof window[n]=='function')console.log(n); URL用 javascript:(function(){var b='';for(var n in window)if(typeof window[n]=='function')b+=n+"\n";alert(b)})() Object.prototyp
● [Rails] DB勉強会 〜 大規模ソースコードの読み方 〜 内輪で集まってDB与太話をやるのかと勝手に想像していたら、ミラクル・リナックスのCTOの吉岡さん(参考1)がいらっしゃって軽く引いた(いい意味で)。前半は吉岡さんのプレゼンで「大規模ソースコードの読み方」。動的なソースコード解析で役立つ profiler や tracer の紹介が勉強になった。これらを使うと、ソースコードを全く読まないどころか、そのアプリケーションを初めて使った場合でもすぐにボトルネックを見つけ出すことができるらしい。実際、Ruby歴3時間の吉岡さんがgc.cのボトルネック解消パッチを作れたとか。(参考2)。素晴らしい。後半はDB周りの雑談から殆どがRailsネタに。吉岡さんすいません。 ● メモ printf デバッグは有益無害 基本は -g でコンパイルしてgdbで実際に実行しながらソースコードを追う
最近のwindowsは普通に使っている範囲ではブルースクリーンに出会うこともなくなりましたが(デフォルトでブルースクリーンを出さずに即再起動するようになっただけでしょうか)、ドライバのコードを書いているとすぐに遭遇します。ブルースクリーンで表示されている情報は、ブルースクリーンを出す原因となった事象のコードとその事象にまつわる付加的な情報(PCの値であるとか、参照したメモリアドレスであるとか)が表示されます。しかし、自分のコードの何行目が原因だったのかを知るのにはクラッシュダンプを読んでみないとわかりません。 WinDbgのインストール クラッシュダンプを読むにはまずWinDbgというデバッガが必要です。このデバッガはカーネルのデバッグができるようにリモートから接続できるようになっていたりしますが(そういえばそんなことはgdbだとふつうにできる)無償でダウンロードできます。 Install
最近、CSS の使いまわしなどを視野に入れ、一部で class名や id名の共有というテーマへの関心が徐々に高まりつつあるような印象です。microformats なんかも、その流れのひとつといえるでしょう。 Naming conventions table(And all that Malarkey) もう、class名やid名で悩まないんだからっ!!(CSS HappyLife) (X)HTML の id/class における命名規則(purprin さん CSS Flight プレゼンスライド) 名前の共有はコードの共有のための(複数人で同一コードを編集・転用する)重要なファクターのひとつですし、非常にいい傾向だとは思うんですけど、実際につけられている名前を見てみると、シブい顔をせざるを得ない事例が結構あるようです。 コード共有のためには避けたい命名事例 構造ではなく見栄えで命名して
はじめに 日本語サイトでデバイスドライバ作成を解説しているページがありません。どんなに探してもありません。そんなにデバイスドライバって需要ないのですか? そんなものですか? 個人的にはかなり興味あるんですが。ということで、今回はデバイスドライバ作成についてやっていきたいと思います。ここでひとつ断っておきますが、私はデバイスドライバに関してはほぼ知識ゼロです。全然知りません。全然分かりません。これは本当です。ちょっとテキストの誤植を大目にみてもらおう思って書いておく保険じゃありません。なので、「分かりやすく」や「内容に間違いなく」といったことが保障できません。またデバイスドライバはカーネルモードで動作するためWindowsに致命的なダメージを与える可能性があります。今回、私はWindowsXP + WinXPDDKで解説していますが、ブルースクリーンなんて当たり前です。日常茶飯事です。なので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く