明らかに前者の方が速いだろうと思っていたがコンパイラをなめていたようだ。 g++ (Ubuntu 4.3.3-5ubuntu4) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSEon model name : Intel(R) Xeon(R) CPU W3520 @ 2.67GHzで、次のコードを試してみた。 #include <iostream> #include <vector> #include <utility> #includ
http://lwn.net/Articles/343608/rss 新しいgccで、GPLv2のプログラムをコンパイルすると再配布不可能になるよ。という話。よく知られているように、gccはコンパイル時に(勝手に)libgccをリンクする。これは除算のサポート等が含まれている。うろ覚えだけどC++の例外の補助コード等もここ。 んで、勝手にリンクされる都合上、あんまりきつい制約に出来ないのでGPLなんだけど、特別免除としてプロプラなライセンスとリンクしてもOKということにしてあげるよ。ということになっている。 で、このGCC runtimeのライセンスが、gcc 4.4からGPLv3になった。で、プロプラなライセンスは従来の特赦条項で救われるのでOKだけど、GPLv2は再配布時にライセンス変更しちゃダメ条項があり、かつ、GPLv2とGPLv3はincompatibleなので、自動的にライセン
#If 0ってC,C++では、#endifまで問答無用でコメントにしますが、 これを使ったハックがすごく便利。 元ネタ http://gpwiki.org/index.php/SDL:Tutorial:Using_SDL_net #if 0 #!/bin/sh gcc -o a a.c exit #endif int main( void ) { printf( "Hello\n"); return 1; } これを保存して、実行属性をつけてから(chmod 755とか) ターミナルで、 # ./a.c と打ち込むと、 aという実行ファイルが生成される。 んで、./aと打ち込むと Helloと表示される。 今までは、Makefileか直接、gcc -o a a.cとかやっていた作業が、 ソースコード+Makefileの代わりになるわけ。 なぜこんな事ができるかってーと、 shのシェルスクリ
ライブラリの外に公開するシンボルを制限する C言語にはファイル内 (コンパイル単位) からしかアクセスできない static 関数と、別のファイルからもアクセスできる非static 関数があります。しかし、ライブラリを作成する上では、この2つのスコープだけでは不十分なときがあります。 本記事では GNUの開発環境において、ライブラリの外に公開するシンボルを制限する方法を紹介します。 次のような例を考えてみます。 % cat a.c // foo() は libfoo の主役の関数なので公開したい void foo() { bar(); } % cat b.c // bar() はライブラリの中だけで使われるべきなので本当は公開 // したくない。しかし別のファイルに含まれる foo() から使われ // ているので、非staticにせざるをえない void bar() { } このようなコ
C++ のシンボルをデマングルする C++ コンパイラはシンボルが一意の名前を持つように名前マングル (name mangling) と呼ばれる処理を行います。本記事では GNU の開発環境で C++ のシンボルをデマングル (demangle) する方法を紹介します。 マングルの方法はコンパイラ依存です。同じコンパイラでもバージョンによってマングルの方法が異なることがあります。たとえば GCC 3.x では int foo(int) を _Z3fooi に、 int foo(const char*) を _Z3fooPKc のようにマングルしますが、 GCC 2.95 ではそれぞれ foo__FPCc, foo__Fi となります。 コマンドラインからデマングル C++ のオブジェクトファイルに nm をかけると、デフォルトではマングルされた読みづらい形式でシンボルが出力されます。 %
3. 共有ライブラリ共有ライブラリは、プログラム起動時にロードされるライブラリです。 共有ライブラリが適切にインストールされると、その後に起動される全てのプログラムは、自動的にその新しい共有ライブラリを使うことになります。 実際には、これよりもはるかに柔軟で洗練されています。なぜなら、Linux における共有ライブラリの実現方法のおかげで、次のことが可能となるからです。 ライブラリを更新しながらも、そのライブラリの古くて後方互換性のないバージョンを使いたいというプログラムを、引き続きサポートすることができる特定のプログラムを実行するとき、特定のライブラリ、もしくはライブラリ内の特定の関数でさえもオーバーライドすることができる既存のライブラリを使用してプログラムが動いている間にも、これら全てをおこなうことができる 3.1. 約束ごとこれらの望ましい特性すべてを共有ライブラリがサポートするため
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く