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

時事ネタ いや、「今、fj.comp.lang.cが熱い!」という話は ちょっと前から聞き及んではいたのですが、 流量が尋常じゃないらしいので、 忙しさもあって読むのを控えていたんですけど、 先日、大筋を拾い読みしてみました。 確かに熱いですねえ。 いったん収束するかなあ、と思ったら、なんかまた泥沼の気配が(^^; fjを読んでない人のために説明すると(って、 私も普段はあんまり読んでないんですが)、 「malloc()で確保した領域は、必ずfree()で解放しなきゃいけないか?」という 話題でして、「exit()する時には、OSが解放してくれるんだから 別にfree()しなくてもいいじゃん」という主張と、 「いや、malloc()には常に対になるfree()があるべきだ」という主張があって、 議論を呼んでいたのでした。 んで、私がどう思うかなんですが、 私は面倒臭がりなので、free()

第1章 総論 ツールの利用 セキュリティ対策の各場面でツールの利用が有効である。例えば、ソースコードを記述する場面では、対策されたランタイムライブラリの利用、ソースコード中の脆弱性が疑われる箇所を指摘してくれる静的検査ツール、ヒープのハンドリングの誤りを指摘してくれる動的検査ツール等がある。また、運用環境においても防御機能が利用できる場合がある。 ツールを利用する場面 ツールを使用する場面として、次の4つの場面が想定できる。 ソースコード記述時 脆弱性を生じにくいソースコード記述の支援 ソースコード記述後 記述したソースコードからの脆弱性の検出 デバッグ時 スタックやヒープにおける領域あふれの検出 運用時 運用環境に組み込まれている防御策の利用 ソースコード記述時に利用できるツール 脆弱性を生じにくいソースコードを記述しようとする際、従来のランタイムライブラリの代わりに「対策されたランタイ

「C/C++ 関数・マクロ集」というタイトルですが， そのうちのいくつかはＣ専用だったりします．(苦笑) 2007/06/24(日) 追記 高木さんより， Ｃの規格上移植性に問題がある点をご指摘いただいたので， 現在修正中です． (たくさんあります…．orz) とはいってもその多くは， めったにお目にかかれないような珍しい処理系とか， 「そんなの実在するの？」という処理系に移植する場合の話なので， 実用上ほとんどの場合は問題ないと思います． (一部そうとはいえないものもありますが．) Ｃの規格に照らして完全に「処理系・OS 非依存」 にするのは困難な場合もあり， 完璧な移植性にこだわるあまりプログラムが書けなくなっては本末転倒なので， タイトルに「ほぼ？」を入れました．orz 2007/06/21(木) 追記 このページを含め，私が C/C++ 関連記事を書くに当たりたびたび参考に＆リンク

プログラムを製作する環境とは違った環境で使うことを前提としたプログラムは、移植に関していろいろな問題が発生します。移植の問題を回避したいのであれば、まず Java が使えないか考えてみてください。Java は高い移植性を持っていて、ここで紹介している移植問題のほとんどをクリアしています。 Windows で製作したプログラムを UNIX で使おうと思うと、たとえ ANSI C に準拠したプログラムを製作しても環境の違いによってさまざまな問題が発生してきます。このような移植を前提としたプログラムを作ると言う事は、二つの異なる環境でプログラムを作ると言う事で、両方の環境に付いてよく知っておかなければなりません。 プログラム移植の最初の問題は、移植先のコンパイラでコンパイルできるかどうかと言う事です。純粋に ANSI C で定義されている機能しか使用していなければこれはクリアできるでしょう。しか

ANSI/ISO 9899-1990 準拠 規格について 用語解説 ここでは、ANSI C規格で定義されている関数の働きを調べることができる。 また、関数でなくとも、規格でヘッダーファイルに定義されている識別子は載せてある。 ここに載っていなくとも、"_"で始まり二文字目が英大文字か"_"の識別子は使ってはいけないことに注意せよ。 なお、宣言自体はコンパイラに付属のヘッダーファイルに書いてあるので、必要なら参照するべし。 アルファベット順に探すならこちら。 関数一覧 常に定義されるマクロ __LINE__ __FILE__ __DATE__ __TIME__ __STDC__ <errno.h> エラー処理 EDOM ERANGE errno <float.h> 浮動小数点演算の限界 FLT_ROUNDS DBL_DIG DBL_MANT_DIG DBL_MAX_10_EXP DBL_M

はじめに プログラマには、ドキュメント、とくにプログラムの内部仕様書を書くのが苦手、 という人が多い。 その理由は明らかであって、そもそも、ソースコードに (バグも含めて)*1 すべての仕様が子細もらさず書かれているのに、なぜ、さらにそれと独立した仕様書が必要なのかと、 (半ば本気で) 思ってしまうからである。 ソースコードと独立にメンテナンスをしなければならないような仕様書は、 いずれソースコードと整合性が取れなくなって、無意味ならまだしも、 かえって害をなす存在となり果てることもある、ということを、 彼らは経験的に理解しているのである。 (*1) Ruby の作者である、まつもとゆきひろ氏は、 その著者『オブジェクト指向スクリプト言語 Ruby』の中の「付録C Ruby 用語集」で、 次のように書いている: ドキュメント まつもとの苦手なもの。彼は普段から「ソースがドキュメントだ。

角のページへ戻る STL(Standard Template Library) C++の標準テンプレートライブラリ、STLのページです。 2003/6/7 コンテナ全ページ標準に合わせて修正 目次(と予定) 更新履歴 はじめに STLとは? '99 11/07 作成 その前にC++で知っておかなければならないこと 馴染みがない(かもしれない)単語 '99 9/23 わずかに修正 テンプレート(template<>) 2001 1/31 更新 環境 '99 2/20 VCでSGI_STLを使う、BeOS、egcs等 使い方 イテレータ(反復子)の使い方 '99 6/19 更新 関数オブジェクトの使い方 '99 7/4 mem_fun()の使い方追加 早見表 STLで使う主なクラス '99 6/13 各クラスの説明、ヘッダをまとめた STLで使われる名前 '99 6/13 微妙に更

#include<stdio.h> double f1( double x ) { return x+1.0; } int main( void ) { double (*p)(double) = f1; /* 関数を指すポインタpに関数のアドレスf1をセット */ double ans = p( 5.0 ); /* 関数を指すポインタpに格納されているアドレスの関数を指定されたパラメータで呼び出す */ printf( "p(5.0)=%g\n", ans ); return 0; }