gprofを使いこなす - minus9d's diary
C/C++のコードの速度を改善するときに有効な方法は、処理時間を多く消費する関数を見極めて、その関数を改善することである。どの関数が(1)どれだけ処理時間を消費するか、(2)何度呼ばれているか、(3)どの関数を呼んでいる/どの関数に呼ばれているか、などを測定する行為をプロファイリングといい、その手助けをするツールをプロファイラと呼ぶ。今回はC/C++のプロファイラとして有名なgprofの使い方を紹介する。 プログラムの例 GNUプロファイラーによるコード処理速度の向上 のコードを参考にして作成した以下のコードをgprofでプロファイリングしてみよう。main()はa()とb()を100000回呼ぶ。b()はa()の約4倍時間を消費する。またmain()自身も、a()とb()を呼び出してその結果を待つ以外に、a()の約1/3の時間を消費する。 // main.cpp #include <cs
PNGファイル（２） PNG操作の手順
PNG配布ファイルにある説明があまりに冗長で的を得ないので、なんとかまとめて書き出しました。 ほとんど libpng.txt からの流用なんですが、正直 libpng.txt を真っ向から読むのはだるいので、 とりあえず下記の文を読んで予備知識を積んでからlibpng.txtを読むといいんじゃないかな～と思います。
C言語でOpaqueポインタを使って構造体のメンバを隠蔽する - minus9d's diary
C言語で、自作の構造体のメンバをユーザに開示しないテクニックとして、Opaqueポインタというものが知られています。今回は、書籍「C++のためのAPIデザイン」の3.1.6節を参考に、Opaqueポインタを使う簡単なサンプルを紹介します。 Opaqueポインタを使わない場合 人に関するデータを集めた構造体Personと、その構造体を使ったライブラリを作成することを考えます。以下にPerson.hのコードを示します。 #pragma once typedef struct _Person { int age; } Person; // 以下、Person構造体に関するAPI Person* createPerson(int age); // Person構造体のオブジェクトを生成 void printPerson(Person* ptr); // Person構造体を使った操作（メンバのプリ
Ｃプログラミング診断室／これでもプロ／構造的欠陥
■構造的欠陥とは■ 「構造的欠陥」といっているのは、多数のソースファイルの全体におよぶ欠陥のことです。ここ では特に、プログラム全体から使われるため、たった１つのヘッダーファイルの善し悪しがプログ ラム全体に与える甚大な影響について説明します。ヘッダーファイル(.h)を作る時の常識を知らな かったために涙ぐましい苦労をしてバグを入れてしまうという欠陥です。 元のプログラムでは、先頭で標準以外のヘッダーファイルも使っていますが、さらにいくつかの 変数が別にわざわざextern宣言されています。さらにグローバルな変数の宣言も行なわれています。 大きなプログラムでは、プログラム全体で共通に使うような変数、配列、マクロなどが多数必要 になります。これをいかにちゃんとするかが、プログラムの「生死」を決めてしまいます。 抽象的説明で、理解しにくいでしょうね。 ■具体例■ では、変数 Cursor がど
PIE (位置独立実行形式) を作成する - bkブログ
PIE (位置独立実行形式) を作成する 通常、PIC (位置独立コード) は共有ライブラリに用いられますが、Linux 上で最近の GCC, Glibc および GNU Binutils を使うと、実行ファイルも位置独立にすることができます。本記事では PIE (位置独立実行形式) を作成する方法と特徴を紹介します。 PIE の基本 それでは例を見てみましょう。次のようなファイル foo.c があるとします。 #include <stdio.h> void foo() { printf("hello\n"); } int main() { foo(); return 0; } このファイルを -fPIE というオプションをつけてコンパイルし、 -pie というオプションをつけてリンクすれば PIE を作成できます。出来上がったファイルは普通に実行できます。 % gcc -c -fPIE
C99の仕様
長い歴史を持ちながら、依然として人気の高いC言語。その最新仕様の情報にキャッチアップするための連載スタート。今回は1999年に策定された「C99」を取り上げる。 連載 INDEX 次回 → C言語（以降、単にC）はDennis Ritchieによって1969～1973年の間にベル研にて開発されたプログラミング言語である。長い歴史を持つと共に非常にポピュラーな言語で、プログラマーでCを知らない人はまずいないと言っていいだろう。プログラミング言語のシェアを調査しているTIOBEでも、ここ最近は常に1、2位を占めている。 Cの言語仕様は今から25年近く前である1989年に初めて規格化され、これは一般に「ANSI-C」と呼ばれている。ANSI-Cは長らくCの言語仕様のスタンダードの位置を占め、世の中の大半のプログラマーは、このANSI-Cに慣れ親しんでいることだろう。しかし、実はCの言語仕様はその
ERR06-C. assert() と abort() の終了動作を理解する
ERR06-C. assert() と abort() の終了動作を理解する C言語仕様のセクション 7.2.1.1 は、assert() の動作を次のように規定している [ISO/IEC 9899:2011]。 assert マクロは、プログラム中に診断機能を付け加える。assert マクロは、ボイド式に展開する。assert マクロを実行するとき、expression（スカラ型をもたなければならない。）が偽（すなわち、0と等しい）である場合、assert マクロは、偽の値をもたらした特定の呼出しに関する情報（情報の中には、実引数のテキスト、ソースファイル名、ソース行番号およびその assert マクロの呼び出しを字句的に囲んでいる関数の名前を含む。後の3つはそれぞれ __FILE__ および __LINE__ の値ならびに識別子 __func__) の値とする）を処理系定義の書式で標準
Success is a Journey, not a Destination: 全てのCプログラマが未定義な振る舞いについて知っておくべきこと #1/3
[What Every C Programmer Should Know About Undefined Behavior #1/3 の翻訳です。] LLVMでコンパイルしたコードは、最適化を有効にしているとたまにSIGTRAPシグナルを生成するのはなぜなのか、と聞かれることがある。いろいろ調べたあと、(X86での話だが) Clangは "ud2" インストラクションを生成していたことがわかった。"ud2" は__builtin_trap()が生成するインストラクションと同じものだ。[訳注: #UD例外を発生させる命令。ソフトウェアが#UD例外をハンドルできているかテストするために使われる。つまり、ソースコードが未定義な振る舞いを使っていたから、LLVMはud2インストラクションを生成したのであって、LLVMのバグではない、ということ] こういう問題は幾つかあって、すべて、Cの未定義な振る
Valgrind : 4. Memcheck: a memory error detector
Memcheck is a memory error detector. It can detect the following problems that are common in C and C++ programs. Accessing memory you shouldn't, e.g. overrunning and underrunning heap blocks, overrunning the top of the stack, and accessing memory after it has been freed. Using undefined values, i.e. values that have not been initialised, or that have been derived from other undefined values. Incor
Mitzyuki's Blog :: C 中級者が意外と陥りやすいワナ
C 中級者が意外と陥りやすいワナ ある程度プログラミングにも慣れてきて 言語仕様もそこそこ理解した中級者にとって 意外と陥りやすくセキュリティホールの温床になりがちなワナ。 勿論オンラインマニュアルにも仕様として明記してあるのだが、 直感とは反する仕様のなので特に中級者にこれらのミスが多い気がする。 strncpy(3) は ``\0'' 終端してくれない場合がある strcpy(3) はバッファオーバーフローの危険性があるから strncpy(3) を利用する様によく言われるが、 ここにワナが潜んでいる。 strncpy(dst, src, len); とした時に 文字列 src の長さが len バイト未満の場合は dst は ``\0'' で終端される。 終端どころか dst の残り領域は何故か 全て ``\0'' が詰められるという 無駄とも思われる謎仕様。 ところが文字列 src
メモリーリークの検出：mtrace , valgrind：プログラマー社長のブログ：オルタナティブ・ブログ
以前の記事にもLinuxでのメモリーリークの検出に関する事を書いたのですが、もう少し一般的なやり方を紹介しましょう（というより、自分で毎回忘れるので備忘録として・・・）。 【mtraceを使う方法】 まず、mtraceを使う方法です。リークのテストを開始したい場所でmtrace()をコールし、終了したい場所でmuntrace()をコールするようにします。 #include <stdio.h> #include <stdlib.h> char *test() { char *test=malloc(10); return(test); } int main() { char *ptr; mtrace(); ptr=test(); //*(ptr+10)='\0'; //free(ptr); muntrace(); return(0); } -gつきでコ
MPFRについて：任意精度数値計算ライブラリ
以前、１億桁のπの計算のためGMPを使いました。しかし、これには四則演算しか存在していなくて、通常の科学計算にはとても使えませんでした。 その後、調べていたらGMPを元に三角関数等をできるようにした、MPFR、MPCがありました。これら３つのライブラリは何とgccをビルドするのに必要なパッケージだとかで（何に使ってるんだ？）、最新のgccを使いたければインストールしておかないといけません。依存関係があり、GMP←MPFR←MPCという感じになるので、その順番にインストールしていかないといけません。大雑把に概要をいうと、以下のようになります。 ・GMP 任意精度算術演算ライブラリ ・MPFR こちらも任意精度の浮動小数点数演算ライブラリ（各種関数あり） ・MPC 複素数演算ライブラリ MPFRの簡単なサンプルを以下に示します。（これらのライブラリはCなのに注意） /* mpfrの使い方を調べ
任意精度計算ライブラリ(GMP)の使い方 - pyopyopyo - Linuxとかプログラミングの覚え書き -
プログラミング時に注意すべき点の一つに，計算精度の問題があります． たとえばC/C++だと，doubleで計算しても有効桁数は15桁程度(10進数で)しかありません．その結果，以下のような状況で間違った計算結果が出てしまいます． 取り扱う数値が15桁を越える場合 取り扱う数値が7桁を越える場合 たとえば8桁同士の掛け算が行われるとその結果は最大16桁になります．double型の変数には15桁程度の情報しか保存できないので，下位1桁の情報は棄てられます． 取り扱う数値の最大値と最小値に，15桁の以上の差がある場合 たとえばC言語のdouble型で(1.0 + 1e-16)を計算すると結果は 1.0 になります． これら計算精度の問題を避ける方法の一つにGMPというライブラリを使う方法があります。以下ポイントをまとめます。 GMPとは GMP(GNU Multiple Precision li
Pthread - Mutexでプロセス間排他制御を行う - s-kita’s blog
使用するシステムコール、API Mutex関連 #include <pthread.h> int pthread_mutex_init( pthread_mutex_t *mutex, const pthread_mutexattr_t *attr); int pthread_mutex_lock(pthread_mutex_t *mutex); int pthread_mutex_unlock(pthread_mutex_t *mutex); int pthread_mutex_destroy(pthread_mutex_t *mutex); Mutex属性関連 #include <pthread.h> int pthread_mutexattr_init(pthread_mutexattr_t *attr); int pthread_mutexattr_destroy(pthread_
Worse Is Better
Lisp: Good News, Bad News, How to Win BigLisp: 良い知らせ、悪い知らせ、大成功への提言 Richard P. GabrielRichard P. Gabriel Lucid, IncLucid, Inc (Original article: Lisp: Good News, Bad News, How to Win Big. Japanese translation by Hisashi Morita.) This article was originally published in 1991.この記事は当初1991年に公表された。 Abstract要約 Lisp has done quite well over the last ten years: becoming nearly standardized, forming the bas
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
stdout thread-safe in C on Linux?
Quick test using epoll to wait on GPIO events
Using the GNU Compiler Collection (GCC)
Man page of MSYNC
RL78での可変引数の実装について - Forum - RL78 MCU - Renesas Community