[B! C] oinumeのブックマーク

わずか500行のCソースコードで作られたCコンパイラ「CC500」 | ソフトアンテナ

Cコンパイラといえばとてつもなく複雑なプログラムというイメージがあります。ところが、このCコンパイラを(サブセットとはいえ)わずか500行ほどのCのソースコードで実現した「CC500」名付けられたプログラムが公開されています。ソースコードは可読性を維持するためにつけられた空行やコメントを含めると、実際は750行ほどになるそうですが、それでもこれだけコンパクトなソースコードで実行可能なELFバイナリ(Linux用のバイナリ)を生成できるのは興味深いのではないでしょうか。以下実際にLinuxでコンパイルしてみました。自己コンパイルできるこのコンパイラはC言語のサブセットで、自分自身のソースコードをコンパイルできるところがおもしろいところです。まず「cc500_1」という実行ファイルを生成します。 gcc cc500.c -o cc500_1 生成された実行ファイル「cc500_1」を使

oinume 2014/11/17

C

リンク

いやなブログ: Linux の共有ライブラリを作るとき PIC でコンパイルするのはなぜか

Linux の共有ライブラリを作るとき PIC でコンパイルするのはなぜか通常、Linux の共有ライブラリを作るときは各 .c ファイルを PIC (Position Independent Code) となるようコンパイルします。しかし、実は PIC でコンパイルしなくても共有ライブラリは作れます。それでは PIC にする意味はあるのでしょうか。さっそく実験してみます。 int func () { printf(""); printf(""); printf(""); } PIC でコンパイルするには gcc に -fpic または -fPIC を渡します。-fpic の方が小さく高速なコードを生成する可能性がありますが、プロセッサによっては -fpic で生成できる GOT (Global Offset Table) のサイズに制限があります。一方、-fPIC はどのプロセッサで

oinume 2013/10/21

C

リンク

各種マップ実装の性能比較 - mixi engineer blog

今回は小ネタのmikioです。key/valueのレコードを高速に格納・参照・削除する仕組みが連想配列とかマップとか呼ばれて親しまれていますが、Tokyo Cabinetのオンメモリマップの性能をC++の各種実装と比較してみました。以下の実装を対象として、100万レコードの格納と検索にかかる時間を計測します。キーと値は各8バイトの文字列とします。 Tokyo Cabientのオンメモリマップ（TCMAP） STL（C++の標準テンプレートライブラリ）のmapとmulti mapとset GNU拡張テンプレートのハッシュマップ Googleのdense hashおよびsparse hash テストコードはこちらに挙げておきます。具体的な操作としては、マップオブジェクトを生成し、バケット配列の要素数をレコード数と同じにチューニングし、ループを回してレコード群を格納します。なお、STLのマップ

oinume 2008/10/31

STLって遅いんだなぁ...

c

リンク

google-perftools(tcmalloc)の使い方 - moratorium

google-perftools(tcmalloc)の使い方 2007-12-17 (Mon) 22:59 Google OSS PFIでは毎週１人適当な話題で発表しているのですが、この間「GooglePerfToolsの使い方」という軽いお題で発表した資料を公開してみます。メモリ周りの問題は大変ですよね…。 google-perftools - Fast, multi-threaded malloc() and nifty performance analysis tools 肥え続けるTomcatと胃を痛めるトラブルハッカーローテクなメモリ使用量監視方法特にC++で長期運用中のメモリリークに苦しんでおられる方には役立つかと思います。基本的にドキュメントの日本語訳ですが。SlideShareだとなぜか図がずれるので、元ファイルをこちらに置いておきます。 | View | Upload

oinume 2007/12/22

リンク

Cで実現する「ぷちオブジェクト指向」：CodeZine

はじめに　CodeZineではお初にお目にかかります、επιστημη（エピステーメー）です。最初のアーティクルはクラシックなCのお話。　昨今のアプリケーションはオブジェクト指向言語による実装が主流と言ってもいいでしょう。C++、Java、VB.NETさらにはRubyやPythonといったスクリプト言語まで、オブジェクト指向でない言語を探すのに苦労するくらいです。　本記事では、今なお現役バリバリで活躍している手続き型言語の代表格（？）Cによる、オブジェクト指向のマネゴト（オブジェクト指向風味のCコーディングスタイル）を試みます。対象読者　もっぱらCを主な開発言語として使ってはいるけども、オブジェクト指向に興味と憧れを抱いている方。抽象データ型　手始めにオブジェクト指向の特徴の1つ、「抽象データ型（ADT：Abstract Data Type）」をCで実現してみます。抽象データ型とは、データ

oinume 2007/02/14

c
oop

リンク

RAIIもどき in C attribute((cleanup(fn)))

gccの__attribute__((cleanup(fn))) が便利すぎる件について。 C++でコードを書くときは、RAIIとか呼ばれているイディオムを使えば、ご存じの通り、ロックしたmutexを手動で開放する必要もないですし、newしたオブジェクトを手動でdeleteする必要もないです。 void Baz::boo() const { boost::mutex::scoped_lock lock(mutex); // ... return; // lock変数のデストラクタで自動開放。手動での開放不要 }でもC言語だと、当然ながら手動で開放しないといけません。複数箇所でreturnしている場合など、タイプが面倒臭すぎ。 int foo() { pthread_mutex_lock(&mutex); // ... if (hogehoge) { pthread_mutex_unlock