Cでのポインタの読み方
Cでのポインタの読み方 Cのポインタの読み方は、ルールを知らないと摩訶不思議です。 ルールを覚えれば、 int (*p[5])[3]; char (*(*fp)(void))(int); なんてのも解読する事ができます。 大事な前程 ポインタを読む際には、「英語で読む」必要があります。 「え～、英語～」 と思う方もいるかもしれませんが、逆に日本語で読む方が大変です。 基本ルール ルール 後置演算子が優先。 関数の() 配列の[] 前置はあとで。 要は、「後ろに何かあったら、後ろが優先」です。 演算子の英語での読み方 * pointer to ... () function returning ... [] array of ... Lesson 1 まず、演算子が単独で出てくる場合です。 Lesson 1-1 pointer to ... int *p; これは、まずpを見ましょう。 i
Xcode 4 でデフォルトになった LLVM って何?
こんにちは。開発担当の金内です。 Xcode 4 は UI もすっかり変わりましたが、ビルドの要であるコンパイラもデフォルトが変更されています。その新しいコンパイラのキーワードが「LLVM」です。いまいち聞き慣れない方もいると思うので、今回はその LLVM について簡単にご紹介します。 ざっくりとした結論から言ってしまえば、Xcode における LLVM は従来のデフォルトコンパイラである GCC を置き換えるものです。LLVM には次のような特徴があります。 ・コンパイルが速い ・コンパイルされたコードが速い ・エラーメッセージがわかりやすい ・他のツールと連携しやすい いいことばかりですね。 しかし、コンパイラは要となる重要なコンポーネントなので、互換性などへの配慮から、Apple は GCC からの移行を少しずつ段階的に進めています。 実際、Xcode 4.0 でのデフォルトは完全に
ライブラリ
スタティックライブラリの作成 1. はじめに 共通の関数を複数のプログラムで使い回すとき、ライブラリにした方が楽。 ということで挑戦。 2. 次に とりあえず腕ならし。簡単な関数をつくってみる。 あっさりできてしまった。 ソースは下。必要最低限しか書いていないから、見れば分かるでしょう。 Makefile error.c error.h util.c util.h main.c lib.tar.gz‥上のファイル全部 3. 一応説明 error.c、util.cからライブラリをつくり、名前はlibutil.aとする。 そして、それとmain.cをいっしょにコンパイルする。それだけ。 手でコンパイルするとすると、以下のようになる。 % gcc -c error.c % gcc -c util.c % ar r libutil.a error.o util.o % ranlib libutil
Deep C
Programming is hard. Programming correct C and C++ is particularly hard. Indeed, both in C and certainly in C++, it is uncommon to see a screenful containing only well defined and conforming code.Why do professional programmers write code like this? Because most programmers do not have a deep understanding of the language they are using.While they sometimes know that certain things are undefined o
やさしいＣプログラミング
この本は，これからプログラミングを学ぼうとする初心者のために， 基本的な事柄について解説しています．本書の目的は，プログラムの よい書き方（プログラミング書法またはプログラミングスタイルと 呼ばれる）を身につけるきっかけを提供することです．読者には， コンピュータやプログラミングについての特別な知識は期待して いません．本書で使用するコンピュータ言語は，Ｃよりはプログ ラミングの教育に適したModula-2風の疑似言語です．この言語は Ｃ言語が持つ文字列を置き換える機能（マクロ定義）を使って見 かけを変えているだけで，Ｃ言語そのものです．初心者がModula-2風Ｃ を用いることの利点は， プログラムを読みやすく，文法を覚えやすくする， Ｃ言語特有のわかりにくさを緩和する， Ｃ言語特有の起こしやすいエラーを未然に防ぐ， Ｃ言語特有の落し穴をふさぐ， Ｃ言語特有の曖昧な制御構造を避ける， 等
gccを用いたCの共有ライブラリの作り方 - シリコンの谷のゾンビ
ゆとりなもので，ついこないだまで動的リンクと静的リンクの違いがわかっていなかった．動的リンクというのが理解できた頃，そっかユーティリティライブラリは自分で共有ライブラリ作ってしまえばいいんだ，というごく当たり前のことが理解できた． UNIXをさわりはじめていた初期の頃，mecab.soのシンボリックが〜〜という用なハマりがあったのだけれど，あれは要するに実行時に共有ファイルへのパスを指定してあげればよかっただけのこと． わかると当たり前だけれど，わからないと「何がわからないのかわからない」状態に落ち込むなぁ，と改めて思いました． （幸いなことに，僕の周りには「ゆとり乙ｗｗ」と指導してくれる方々がいるので認識できるようになるのですが，少なくとも大学（院）時代はそうでなかったわけで，ゆとりスパイラルの恐ろしさを体感した気がしています．） というわけで自分用共有ライブラリの作り方をきちんと理解で
CUnitによるテスト駆動開発
はじめに CodeZineでの僕のデビュー記事『Cで実現する「ぷちオブジェクト指向」』、おかげさまでなかなか好評だったようです。まだまだCは現役だと実感しました。 前回に引き続きCのお話です。テストをよりどころに実装をすすめ、信頼できるコードを書くためのプラクティス「テスト駆動開発」（TDD:Test Driven Development）を、Visual C++ 2005 Express EditionとUnit Test Framework: CUnitで行います。 対象読者 そこそこのコードは書けるようになったけれど、どうも詰めが甘い/くだらないバグに出くわす/あっちを直すとこっちが壊れ、ぐだぐだになってしまう…そんな症状に悩まされている脱ビギナを目指すプログラマ。 テスト、してますか? 「プログラムは思ったとおりには動かない、作ったとおりに動く」 思ったとおりに作ってないと思ったと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - udonchan/prog2
サービス終了のお知らせ