(まとめ) CとJavaのリテラルの表現法の違い

Javaの基礎を勉強している人に付きあって、C言語とJava言語について
リテラルの表現法の違いをまとめる。
特に、Cで \x は使えるのに \X がダメなことが分かった。
(もしかすると忘れてしまっていたのかも)
CではdoubleにDをつけるのもダメ。
--------------------
(A) 共通

●整数型
通常は 10進
0... なら 8進
0x... または 0X... なら 16進
接尾文字 l または L で long

●浮動小数点型
通常は double
接尾文字 f または F で float

●文字型
\t, \n, \f 等のエスケープ
\...(8進数。最大3桁) によるエスケープ


(B) Javaのみ

●浮動小数点型
接尾文字 d または D で double

●文字型
\u....(16進数。最大4桁) によるエスケープ(Unicode指定)
【補足】 \uu.... や \uuuuuuu.... のように u を何個連続させてもよい!!
【注意】 \U.... ではエスケープできない。

(C) Cのみ (C99 は未調査。拡張があると思われる)

●整数型
接尾文字 u または U で unsigned (符号なし) 指定

●文字型
\x..(16進数。桁数制限なし) によるエスケープ。
【注意】 \X.. ではエスケープできない。
--------------------

Fedora Core 2のアップデートはLegacyへ

Fedora Core 2のアップデートが前から(おそらく4,5月頃から)
Fedora Legacy Project に移っていた。
今日気づき、やっと切り替えた。
かなりの数のアップデートがあった。
危ない、危ない。

XHTML 1.1 文書のIE 6.0での表示

XHTML 1.1 文書をIE 6.0で表示させると、
DTD中の解析でエラーになって表示されないことがわかった。
昨年くらいまではそんなこと無かったと思うのだが...
どうもIE側とW3C側の両方に色々問題があるためらしい。
ややこしそうなので、今後調べてみたいが、当座どうするか
考えている。

Xeon×2マシンでJava

64ビットLinuxを入れたXeon × 2マシンにJavaを入れてみた。
残念ながらXeon(Nocona)のEM64Tアーキテクチャに対応したJava VM
は、少なくともSunのフリー配布にはない模様。
しょうがないので、32ビットx86版をインストールして
性能を調べてみたが、簡単な1スレッドのベンチマークでは
同程度のクロックのPentium IVより劣っている結果となった。
まあ、マルチスレッドならいい結果が出るんじゃないかな...

64ビット環境

Intel(R) Xeon(TM) CPU 2.80GHz × 2 搭載のマシンが来て、
x86_64のCentOS 4.1をインストールした。
ちなみに Xeon は「ジーオン」と読むらしい。
Xeonはハイパースレッディングのため、smpカーネル(2.6.9-11.ELsmp)では2個分
見え、見かけの上では都合 2 × 2 = 4 個の CPU が動いている。
これで、自分も64ビット環境に初めて触れることになった。

歴史は繰り返す で触れたWebページにあるサンプルプログラムを少し修正して実行したところ、

sizeof(char) = 1
sizeof(short) = 2
sizeof(int) = 4
sizeof(long) = 8
sizeof(void*) = 8
sizeof(void(*)) = 8 /* 関数ポインタ */
sizeof(float) = 4
sizeof(double) = 8
sizeof(long double) = 16

で、データモデルは LP64 となった。(gcc 3.4.3 のデフォルトでコンパイル)
int < long = ポインタ の環境となった。
データのポインタと関数ポインタは同じ大きさ。

何か Java 環境と似た感じになっている。(char は違うし、long double は無いが)