新城＠筑波大学情報です。こんにちは。
よいまとめが出てしまうと、続けにくいんだけれど、

In article <m3wud3afch.fsf@maedapc.cc.tsukuba.ac.jp>
        MAEDA Atusi <maeda@cc.tsukuba.ac.jp> writes:
> そうか．結局structの宣言は，
> 1.プログラミングで使う組(tuple)データをある程度抽象的に記述したもの
> 2.ファイルI/Oや通信の際の入出力レコードを具体的に記述したもの
> 3.メモリ上のレイアウトを具体的に記述したもの
> の3つを，当初は兼ねていたけど，だんだん苦しくなっているんですね．

あと何年くらい、持ちますかね。

１だけでいいなら、Ｃを使うなという話はあります。構造体のせい
ではないと思いますが、ＣよりＪａｖａの方がずっと高い生産性を
あげる人がいます。両方できる人はそんなに生産性は変らないのか
もしれないけれど、Ｃだといつまでたってもできないのに、Ｊａｖａ
ならプログラムが完成するという例はあります。

で、Javaで、2., 3. を書こうとすると、終ってしまうんですよね。

> Javaはそういう考え方ですね．classのメンバの並びはどうでも良い．前方参
> 照しても関係ない．実際，メモリ上のレイアウトは宣言順でなく並べ替える処
> 理系が存在します(基本型と，GCが見る必要のある参照型を分けて配置する)．
> メンバのメモリ上の位置がプログラマに見えることは無いので，これで良いん
> ですね．レコードをI/Oする時はmarshaling (serialization)します．配置を
> 決めたければ，自分でバイト単位で読み書きします．

具体的に、Java から SunRPC (XDR) で提供されているサービスを
使いたいと思った時に、実際どの程度の難しさでできるのでしょうか。

> 可変部分をunionにして完全にポータブルにすることも可能でしょうけど，
> ・structのサイズとして，「とりうる最大のサイズ」を取る必要がある．
> ・「後で拡張する」ことができなくなる．たとえば，sockaddrの定義中に
>   sockaddr_in, sockaddr_un, sockaddr_x25, ...の定義をあらかじめ全部
>   含めなければいけなくなる．
> ので，用途が限られてしまいます．

Linux のカーネルで、VFS 層のinode の定義がこんな感じの巨大な 
union になっていたと思いました。

> いや，実際上それはちょっと…
> モジュール化ができなくなってしまう．
> ライブラリをリンクする際も全部ソースからコンパイルし直しというのは…

ソースがあれば、速いけれど、ソースがなくても普通に XDR をす
ればいいので、RPC すると思えば、今の CPU で問題ない速度が出
ると思います。

＼＼　新城　靖　（しんじょう　やすし）　＼＼
＼＼　筑波大学　電子・情報　　　　　　　＼＼