LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #1/3 LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #2/3 LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #3/3 コンパイラ基盤 LLVM のブログで、未定義の動作という C 言語のダークサイドについての記事が3回シリーズで公開されている。 C 言語で未定義の動作を実行したら、「鼻から悪魔が飛び出しても文句が言えない」というジョークは有名で……いや、そんなのを知ってるのは年寄りくらいか（参考：nasa
Top 10 C Language resources that will turn you into a better programmer - C and C++ Programming Resources 今更 C 言語かと言われそうだが、Linux カーネルだって、我々が利用している LL 言語の多くだってこの言語で書かれているのである。ワタシ自身は未だどの言語よりCを愛している。 以下に C 言語に関してウェブに公開されている代表的なリソースを挙げていく。さすがに更新が長らく止まっているものが多いが、それでも有用な情報源には違いない。ネタ元は Hacker News。 C Programming Notes Programming in C - UNIX System Calls and Subroutines using C. C Lesson by Chris Sawtell
G7氏のコメントより、「Schemeの実装におけるスタックフレーム(Draft)」について。サブルーチン呼び出し時の呼び出す側と呼び出される側との情報のやり取りを仲介する、スタックフレームのお話。 C言語の関数呼び出しでは、引数でも返り値でも扱えるものは値渡しのみである(Cにはポインタ渡しというものがあるが、これはプログラマが変数の位置情報を明示的にポインタに変換してから値として渡すものなので、処理系から見れば値渡しの一種である)。受け渡し時に扱うものが値渡しだけなので、スタックフレームも値渡し以上のことはできなくても良い構成になっている。「やりたきゃプログラマ自身の手で明示的にポインタ渡ししてね」というスタンスだ。 でもこのスタンスは、例えばクロージャのように値渡しだけでは実現できない機能には不十分だ。処理系がいちいち変数ごとに暗黙にポインタ渡しで置き換えればどうにか動くものを実現できる
今月、私の下に初めての部下がつくことになりました。ただし、日本語は「コニチワ」レベル、英語は何とかしゃべれる東南アジアからの留学生です。やることはC言語によるコード書きとバグ修正で、彼（留学生）はプログラムの基礎（ロジック・構造）は他の言語で既習で、C言語の鬼門であるポインタについては昨週1週間かけた講義で理解できたようです。ちなみに私の英語力は「ゆっくりなら読める・書ける・リアルタイムにしゃべるのは苦手」の典型的日本人英語です。(コミュニケーションは互いの片言以上会話以下の英会話(w)かe-mailで） 今後、コード書きをさせるのに「そこはstrtok使って。使い方はテキスト・関数辞典見て調べて」等の指示で仕事をまわしたいのですが、その『テキスト』を何にするかで躓きました。いままで私がC言語を学んだのは日本語で書かれたテキスト・関数辞典でした。これらは留学生の彼には参考になりません。英語
Cog VM は、VisualWorks用の超高速 Smalltalk VM を手がけた Eliot Miranda 氏による Squeak Smalltalk 向けの新しい高性能 VM 。 Teleplace社（旧 Qwaq社）の製品である同名の仮想空間共有ソフトのベースである Croquet用に開発されたものですが、同社の厚意によりオープンソースとして公開され、Squeak のユーザーも利用可能になりました。 Squeak - Dev - Teleplace Cog VMs are now available Cog Blog :: Eliot Miranda Win 向けのバイナリも公開されていたので、さっそく恒例のフィボナッチベンチ（39番目のフィボナッチ数 63245986 の再帰的な算出にかかる時間を計測。実装はナイーブなものにして、メモ化や遅延評価は使用しない）で人気のスクリ
はじめに 昔お世話になったC Magazineの「プログラミングの禁じ手Web版 C言語編」というサイトを、後輩に教えてあげようとしたら、C Magazineの休刊後にドメインが失効してしまったようで、見る事が出来ませんでした。 幸い、InternetArchive(http://www.archive.org/web/web.php) に当時のデータがほぼ残っていたので、無許可ではありますがサルベージして転載させてもらいました。 「C MAGAZINE - プログラミングの禁じ手Web版 C言語編」 元のアドレスはこちら。 http://www.cmagazine.jp/src/kinjite/c/index.html InternetArchive http://web.archive.org/web/20070113222026/http://www.cmagazine.jp/src
バグを生まないためのルール 以下に、このコーディング規則のいくつかの例を紹介する。これらのルールは、バグの発生件数の削減に役立つだろう。 ●ルール1 if文、else句、switch文、while文、do文、for文に続くコード・ブロックを、常に中括弧「{ }」でくくる。これらの文や句に続くコードが1文だったり、何もなかったりした場合でも、中括弧でくくるべきである（図1）。 理由は、次の通りである。例えば、if文に記述した条件が成立したときに処理すべき内容が、当初は「A」という1文で記述できていたとしても、その後改変を加えて「A」と「B」の2文になったとする。このとき、最初の「A」を中括弧でくくっていなければ、「B」を追加すると同時に中括弧の記述を忘れると、後から加えた「B」という処理が、if文の条件が成立するか否かにかかわらず常に実行されてしまう。つまり、新たなバグを生み出し
特集 Ｃプログラミングの秘訣 最終更新: 2006-03-28 このテキストはC MAGAZINE 1992年4月号に掲載された原稿のオリジナルテキストを元にしてHTMLに変換したものです。掲載文章と細部が異なっていると思われます。また、気付いた個所をいくつか修正してあります。 当時はまだWindows 95もないような時代で、現在の状況から見ると違和感のある内容も結構あるかもしれませんが、時代背景を想像しながら補正しつつ読んでいただければ幸いです。 ※2006年3月28日追記: 何が原因か知りませんがこのページのアクセスが増えているそうなので、 HTML のおかしなところを修正しました。 文章の変更はありません。 なお、このサイト(表ページ)は現在休眠状態ですが、 裏ページ や 裏の裏ページ の方を、細々と更新していたりします。 目次 Part1 よいプログラムを書く条件 Part2 明
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く