February 2000
Su Mo Tu We Th Fr Sa
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29
#include <iostream>
class Hello {
public:
void hello() {
std::cout << "Hello, World!!" >> std::endl;
}
} hello;
typedef void (Hello::*method)();
int main(int argc, char *argv[])
{
Hello *obj = &hello;
method m = &Hello::hello;
hello.hello();
(hello.*m)();
(obj->*m)();
return 0;
}
C++ではメンバ関数は、オブジェクトではなくクラスに従属する。「method m = &(hello.hello);」という記述が不可能なところからも明らかです。ぼんやりと、こういう設計になっているのは多重継承の際の扱いのためなのかな〜等と考える。
Unable to handle kernel paging request at virtual address c28306c8
current->tss.cr3 = 017ac000, %cr3 = 017ac000
*pde = 00002063
*pte = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c01c0a19>]
EFLAGS: 00010202
eax: c28306c4 ebx: c282a700 ecx: c282a700 edx: c282a6c4
esi: c282e000 edi: 00000000 ebp: c1763ebc esp: c1763ddc
ds: 0018 es: 0018 ss: 0018
Process insmod (pid: 316, process nr: 38, stackpage=c1763000)
Stack: 00000000 c1763ebc 00000000 c1763ebc c0108ca8 c28296af c282a6c4 c282e000
00000080 c282a700 c1763ebc 00000000 00000018 c2828860 00000000 c2828788
00000010 00000a83 00000000 00000003 c282ab40 c011b5c0 c027d680 c1d18700
Call Trace: [<c0108ca8>] [<c28296af>] [<c282a6c4>] [<c282e000>] [<c282a700>] [<c2828860>] [<c2828788>]
[<c282ab40>] [<c011b5c0>] [<c282a700>] [<c282a700>] [<c0112964>] [<c0112a9d>] [<c282ab40>] [<c28291d4>]
[<c2829dab>] [<c282ab40>] [<c282504f>] [<c2825048>] [<c282ab40>] [<c2825000>] [<c2825000>] [<c2829841>]
[<c282ab40>] [<c282504f>] [<c2825048>] [<c2825000>] [<c282504f>] [<c2825048>] [<c0114c3b>] [<c2825000>]
[<c281c000>] [<c2825048>] [<c0107b8d>] [<c0107a54>] [<c2825000>]
Code: 8b 40 04 39 42 04 7e 3e 89 15 ec 7d 1f c0 eb 36 8d 76 00 c7
・・・ちょっとびっくり。それでもカーネルがお亡くなりにならなくて良かったな〜
FreePascalでgtkを使うソースをコンパイルしようとするとみんなリンク時に
/usr/local/lib/libgtk.so: undefined reference to `dgettext' /usr/local/lib/libgtk.so: undefined reference to `bindtextdomain'
と言われてしまってコンパイルできない。原因は解っていて
deborah:~% nm /usr/local/lib/libgtk.so | grep dgettext
U dgettext
deborah:~% nm /usr/local/lib/libgtk.so | grep bindtextdomain
U bindtextdomain
と言うことだ。さてどうしたものか。何とかしてlibintl.aをリンクしてやれば良いとは思うのだが・・・つーか、自分のシンボルぐらい自分で解決出来んでどうする? > DLL
libintl.aはスタティックライブラリにも関わらずDLLのlibgtk.soにリンクされていないのがそもそもの邪悪な部分だけどこれは出来ない相談。何故かって? そうしたら、libgtk.soがlibintlのインターフェースも提供することになっちゃうもん。それって思いっきり都合が悪いのよ。他のDLLだってlibintlの機能が必要なのはたくさんあるんだから、それらすべてにlibintlをリンクしちゃうとシンボルが衝突してまうでないの。(Week Symbolとかで何とかなる?) それで、libgtk.soのユーザーにlibintl.aをリンクする責任を負わせているんだろうと思う。ゲー、UNIXって超最悪〜 まるで旧石器時代。オブジェクト指向とは無縁の世界です。つうか、libgtkはlibintlの機能を内部的に使うだけで、libgtkの提供するインターフェース自体はlibintlには依存していないので、libgtk.soにはlibintlをスタティックリンクするがlibintlのシンボルをエクスポートしないというのがまともな解決策。でもそのための機能と言うのはどこにも見当たらない。(もしあったら是非教えて下さい。やるならWindowsのようにDEFファイル的な物を使うと言うのが素直な発想だと思う。) その点、WindowsのDLLのモデルはインターフェースの堅牢性という点で非常に優れていた。
libintlがDLLになってない僕の環境がそもそも問題と言う話もある。だって、どうやったらいいか解んないんだも〜ん。
・・・自分で改造できるだけの能力が無いのが悲しいのでした。機能については良くできていると思いましたが、レスポンスが少し気になりました。というのは、多数のファイルを含むディレクトリを開くとしばらく止まってしまう点です。ディレクトリ構成の取得はスレッドを使ってバックグラウンドで行なうのが定石だとおもうので、将来のリリースでは絶対そうした方がいいと思います。UNIXのGUIのファイルマネージャは私の知る限り皆レスポンスが悪いので、この点を改善できれば大きなアドバンテージになるのではないかと思いますし。
/bin/sh ../../libtool --mode=link gcc -g -O2 -Wall -o faxg3 faxg3.o g3.o run_tbl.o ../../libgimp/libgimp.la -L/usr/local/lib -lglibなどと言われてしまった。調べると原因は簡単で、FreePascalの時と同じようにlibintlがリンクされないこと。というのは、「-lintl」オプションが「GTK_LIBS」にセットされていて、gtkを使わないでglibだけを使うプラグインにはlibintlがリンクされなくなっていたのでした。解決法としては、Makefileで「INTLLIBS」に「-lintl」をセットするのが無難かと。
gcc -g -O2 -Wall -o .libs/faxg3 faxg3.o g3.o run_tbl.o ../../libgimp/.libs/libgimp.so -L/usr/local/lib -lglib -lm -L/usr/local/lib -lglib -Wl,--rpath -Wl,/usr/local/lib
faxg3.o: In function `query':
/home/susho/src/gimp-1.1.16/plug-ins/faxg3/faxg3.c:88: undefined reference to `bindtextdomain'
/home/susho/src/gimp-1.1.16/plug-ins/faxg3/faxg3.c:88: undefined reference to `bindtextdomain'
/home/susho/src/gimp-1.1.16/plug-ins/faxg3/faxg3.c:88: undefined reference to `textdomain'
faxg3.o: In function `run':
/home/susho/src/gimp-1.1.16/plug-ins/faxg3/faxg3.c:123: undefined reference to `bindtextdomain'
/home/susho/src/gimp-1.1.16/plug-ins/faxg3/faxg3.c:123: undefined reference to `bindtextdomain'
/home/susho/src/gimp-1.1.16/plug-ins/faxg3/faxg3.c:123: undefined reference to `textdomain'
faxg3.o: In function `load_image':
/home/susho/src/gimp-1.1.16/plug-ins/faxg3/faxg3.c:191: undefined reference to `gettext'
faxg3.o: In function `emitgimp':
/home/susho/src/gimp-1.1.16/plug-ins/faxg3/faxg3.c:443: undefined reference to `gettext'
../../libgimp/.libs/libgimp.so: undefined reference to `dgettext'
collect2: ld returned 1 exit status
make: *** [faxg3] Error 1
ctype = setlocale (LC_CTYPE, NULL);
if (!strcmp(ctype, "C")) {
old_ctype = g_strdup (getenv ("LC_CTYPE"));
putenv ("LC_CTYPE=en_US");
ctype_set = TRUE;
} else
ctype_set = FALSE;
論理学の命題はトートロジーによって、数学の命題は等式によって、それぞれの世界の――事実を語るのではなく――形式を示すのである。それゆえ、論理も数学も、その外部から語るメタ理論を持つことができない。世界の形式が語りえないのは、それを免れた言語を必要とするが、そのような言語はありえないからである。」と例の「ウィトゲンシュタイン入門」にありました。深いですね、不完全性定理にも通じるのかな、とちょっと考える。
taking the address of a non-static member function to form a pointer to member function, say `&PaneOptions::toggleResize'」等と言われてしまう。僕の使っているgcc-2.95.2では、名前空間をサポートするなど随分と標準にしたがっているのでチェックが厳しくなっているのかも知れない。言われた通りにしたらコンパイルが通った。開発版を持って来ようか。
「純粋理性の二律背反」と「ラプラスの悪魔」を関係付けて論じてみたら面白かろうに、と思った。』と昨日書いたが、これに刑法の情状酌量とかみたいなもっと実際的な見地を加えてみたらもっと面白そうだ。
#include <iostream>
#include <locale>
int main(int argc, char** argv)
{
ctype<char> fac = new ctype_by_name<char>("ja_JP.ujis");
std::cout.imbue(locale(std::cin.getloc(), &fac));
std::cout << "hello world!" << std::endl;
std::cout << ios::hex << 12345 << std::endl;
std::cout << false << std::endl;
}
あ、それは多分COMMAND.COMが貧弱なせいだと思います。 あんまり使ったこと無いですが、あれはシェルとしてはかなりキてます。 UNIXのシェルが持っている当り前の機能が幾つも欠けているんです。 具体的には、行編集機能が無いので、間違いを直す時など、 そこまで消して戻らなくちゃいけないんで、困ります。 ヒストリー機能も無いですね。以前に実行した行を呼び出して、 行編集して実行する、というのが出来ないのはかなり痛い。 そして、これが最大の欠点なんですが、補完(Completion)機能が無い。 補完と言うのは、使ったことが無い人には説明しにくいんですが、 その名前の通り、ユーザーの操作(具体的にはコマンド名やファイル名の入力)を 補ってくれます。 例えば、コマンドを途中まで入力して補完用のキー(大抵はTAB)を押すと、 ユーザーの入力した文字列で名前が始まるコマンドが一つしかなければそれを、 そうでなければ、一意に決定できるところまでを入力してくれます。 (そこで、もう一回TABを押すと、候補の一覧を表示してくれたりする。) ファイル名やその他についても同様です。 更に、「Z Shell」のような超強力なシェルでは、 「cd」の後には、ディレクトリのみしか補完しないとか、 コマンドのオプションを補完したりとか、至れりつくせりです。 というわけでWindowsでも、僕はbashというシェルのWindows版 (Cygwinのパッケージに入っていた)を使っていました。 とは言え、補完もCUIの占有物というわけでもなくて、最近のソフトでは 「ファイル選択」のダイアログボックスなんかでも補完が使えることが多いかな。 コマンド(というか実行ファイル)は、僕のLinuxでも1311個ほどあったので。 (Windowsでいうところの)スタートメニューとかに全部登録とかしたら死にそうです。 emacsの関数だと1828個もありました。 良く使うものは当然、キーにアサインしたり、メニューに登録したりしていますが、 これもすべてメニューやらに置くのはかなり絶望的です。 GUIの大きなメリットととして一覧性がありますが、 対象が多すぎると破綻しますね。 (ずらーと100個くらい並んだメニューからアイテムを選ぶのは悪夢。) 実際にはどっちも不可欠だと思うんですが、CUIもそう悪くないよってことで。