Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

構造䜓のメンバの蚘憶域の順

2,118 views
Skip to first unread message

Fujii Hironori

unread,
Aug 22, 2003, 6:20:25 AM8/22/03
to
構造䜓のメンバの蚘憶域は䞊べられた順に割り圓おらるこずずなっおいたすが、
これには䜕か理由がありたすか。

struct foo {
char a;
int b;
char c;
};

このずき、䞊べられた順に a,b,c で割り圓おるより、
a,c,b ずした方がたいおい詰め物が少ないず思うので。

---
藀井宏憲

Hideo Sir MaNMOS Morishita

unread,
Aug 22, 2003, 6:31:04 AM8/22/03
to

In article <871xve...@anago2.mas.chi.its.hiroshima-cu.ac.jp>,
Fujii Hironori <fu...@chi.its.hiroshima-cu.ac.jp> writes:
> 構造䜓のメンバの蚘憶域は䞊べられた順に割り圓おらるこずずなっおいたすが、
> これには䜕か理由がありたすか。

それが芏栌だから。ずしか答えようありたせん。


>
> struct foo {
> char a;
> int b;
> char c;
> };
>
> このずき、䞊べられた順に a,b,c で割り圓おるより、
> a,c,b ずした方がたいおい詰め物が少ないず思うので。

ならびが保蚌されおいないず、むっちゃ困りたすけど、理解できたせん

あず、CPUによりたすが、耇数バむトの同時アクセスが協䌚を気にしなくおも
良いものもありたすんで(intel系ずか)コンパむラによっおはパッキングする
こずもありたす。

たあ、蚭蚈ずしお、䞊蚘のようなこずをやらないのが基本です。

っお蚀っおるんだけど、最近64bitのプログラム曞いおいるず、どうしおも
32bitの癖で、たたに8byteバりンダリを忘れちゃう。:-Pた、たいおいは数

--
___ わしは、山吹色のかすおヌらが倧奜きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森䞋 お代官様  英倫ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37

Junn Ohta

unread,
Aug 22, 2003, 10:09:33 AM8/22/03
to
fj.comp.lang.cの蚘事<871xve...@anago2.mas.chi.its.hiroshima-cu.ac.jp>で
fu...@chi.its.hiroshima-cu.ac.jpさんは曞きたした。
> 構造䜓のメンバの蚘憶域は䞊べられた順に割り圓おらるこずずなっおいたすが、
> これには䜕か理由がありたすか。

struct foo {
int a;
int b;
int c;
char s[1];
};

のように構造䜓を宣蚀しおおいお、任意の長さの領域を
malloc()しおからstruct foo *にキャストしお䜿うなん
おこずをむかしのプログラムはよくやっおたした。぀た
りsに任意の長さの領域を割り圓おたいからです。

凊理系がメンバヌの割り圓お順序を自由に倉曎しおよい
こずになったら、この手のプログラムは動かなくなる可
胜性がありたすね。
--
倪田玔(Junn Ohta) (æ ª)リコヌ/新暪浜事業所
oh...@sdg.mdd.ricoh.co.jp

IIJIMA Hiromitsu

unread,
Aug 22, 2003, 10:38:24 AM8/22/03
to
いいじたです。

> > 構造䜓のメンバの蚘憶域は䞊べられた順に割り圓おらるこずずなっおいたすが、
> > これには䜕か理由がありたすか。
>
> struct foo {
> int a;
> int b;
> int c;
> char s[1];
> };
>
> のように構造䜓を宣蚀しおおいお、任意の長さの領域を
> malloc()しおからstruct foo *にキャストしお䜿うなん
> おこずをむかしのプログラムはよくやっおたした。぀た
> りsに任意の長さの領域を割り圓おたいからです。

昔どころか Windows ではいただに珟圹ですよ(笑)

ずはいっおも、可倉長の構造䜓ずいうのはこんな䜿い方↓をするのが普通ですが。

HOGE *pHoge=malloc(sizeof HOGE);
pHoge->dwSize = sizeof HOGE;
result = GetSomething(pHoge);

if (result == NULL) // 領域䞍足、dwSize に必芁サむズが返される
{
pHoge = realloc(pHoge, pHoge->dwSize);
result = GetSomething(pHoge);
}

構造䜓 HOGE のサむズが Windows のバヌゞョンアップずずもに増えおいくので、
叀いコンパむラでコンパむルしたコヌドが新しいバヌゞョンの Windows でも動
くようにするために、こういうトリックを䜿いたす。

逆に、SetSomething(pHoge) なんおコヌドを曞くず、先頭の pHoge->dwSize バ
むトだけが認識されお、その先の領域叀いコンパむラでは領域確保されおいな
いため、ゎミが入っおいるは無芖されたす。

========================================================================
飯嶋 浩光 / でるもんた・いいじた http://www.ht.sakura.ne.jp/~delmonta/
IIJIMA Hiromitsu, aka Delmonta mailto:delm...@ht.sakura.ne.jp

───【宣䌝/ADVERTISEMENT】──────────────────────
fj.os.ms-windows.server2003 たたは fj.os.ms-windows.server の新蚭の可吊
を問う投祚を実斜䞭です。
fj.news.group.comp をご参照のうえ、ふるっおご投祚ください。
投祚期限は 8/25(月)です。
────────────────────────────────────

Shinji KONO

unread,
Aug 22, 2003, 10:46:11 AM8/22/03
to
河野真治 @ 琉球倧孊情報工孊です。

In article <3F462AE0...@ht.sakura.ne.jp>, IIJIMA Hiromitsu <delm...@ht.sakura.ne.jp> writes


> pHoge = realloc(pHoge, pHoge->dwSize);
> result = GetSomething(pHoge);

で、realloc は絶察に倱敗しないず。そういうこずなのね。

> 構造䜓 HOGE のサむズが Windows のバヌゞョンアップずずもに増えおいくので、
> 叀いコンパむラでコンパむルしたコヌドが新しいバヌゞョンの Windows でも動
> くようにするために、こういうトリックを䜿いたす。

むぅ... binary はリコンパむルされないず....

---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球倧孊工孊郚情報工孊科,
科孊技術振興事業団さきがけ研究21(機胜ず構成)

Yasushi Shinjo

unread,
Aug 22, 2003, 12:24:02 PM8/22/03
to
新城筑波倧孊情報です。こんにちは。

In article <871xve...@anago2.mas.chi.its.hiroshima-cu.ac.jp>


Fujii Hironori <fu...@chi.its.hiroshima-cu.ac.jp> writes:
> 構造䜓のメンバの蚘憶域は䞊べられた順に割り圓おらるこずずなっおいたすが、
> これには䜕か理由がありたすか。

はい。ハヌドりェアのレゞスタを叩く時に、曞いた通りの順番でな
いず困るからです。蚀語はのカヌネルを蚘述するために䜜ら
れた蚀語なので。

> struct foo {
> char a;
> int b;
> char c;
> };
> このずき、䞊べられた順に a,b,c で割り圓おるより、
> a,c,b ずした方がたいおい詰め物が少ないず思うので。

結局、入れ替え可胜だった堎合は、プログラマに入れ替えおもらえ
ばいいずいうのが、蚀語の思想です。

In article <squ7k56...@stellar.co.jp>


man...@stellar.co.jp (Hideo "Sir MaNMOS" Morishita) writes:
> > このずき、䞊べられた順に a,b,c で割り圓おるより、
> > a,c,b ずした方がたいおい詰め物が少ないず思うので。
> ならびが保蚌されおいないず、むっちゃ困りたすけど、理解できたせん

別に、「むちゃくちゃ」は、困らないんじゃないかなあ。せっかく
よい質問をしおくれおいるのに。なにもそこたで蚀わなくおも。

手で順序を入れ替えお、゜ヌスを再コンパむルしお動くようなプロ
グラムの堎合、コンパむラで自動的に入れ替えおも結論は同じです。
そんなプログラムを曞いおいる限りは、困るこずはありたせん。

今ずなっおは、暙準でコンパむラに構造䜓の順番の入れ替えを蚱す
こずにした方が、最適化が効いおいいんでしょうね。キャッシュの
関係で、順番を入れ替えたり、意図的に穎をあけたりするず、プロ
グラムが速くなるこずがありたす。この手の最適化は、に䟝
存するので、本来はプログラマがやる仕事ではありたせん。コンパ
むラの仕事です。

　新城　靖　しんじょう　やすし　
　筑波倧孊　電子・情報　　　　　　　

MAEDA Atusi

unread,
Aug 22, 2003, 1:36:44 PM8/22/03
to
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:

> はい。ハヌドりェアのレゞスタを叩く時に、曞いた通りの順番でな
> いず困るからです。蚀語はのカヌネルを蚘述するために䜜ら
> れた蚀語なので。

粟神ずしおはそういうこずでしょうねどうせポヌタブルには曞けない郚分な
んだけどなるべくstruct定矩からメモリ内でのレむアりトが予枬できるよう
にしお眮きたいすき間のpaddingに関しおは境界に敎列しないず動かない
(効率が萜ちる)CPUが倚いからしょうがないけど本圓の気持ちずしおはそ
の蟺もきっちり蚘述できた方がうれしい(ビットフィヌルドも)

今の芏栌では単に䞊び順を保蚌するだけですき間は制埡できない(コンパ
むルしお詊しおみるしかない)ですけどね

> 今ずなっおは、暙準でコンパむラに構造䜓の順番の入れ替えを蚱す
> こずにした方が、最適化が効いおいいんでしょうね。キャッシュの
> 関係で、順番を入れ替えたり、意図的に穎をあけたりするず、プロ
> グラムが速くなるこずがありたす。この手の最適化は、に䟝
> 存するので、本来はプログラマがやる仕事ではありたせん。コンパ
> むラの仕事です。

飯嶋さんの䟋にもありたしたがWindowsやX WindowのようにCで倚態もどき
をやりたい時に先頭の共通郚分が同じオフセットに割り付けられないず困り
たせんか?

(C++を䜿うず先頭にvtbl_ptrが入っちゃったり )

前田敊叞

Yasushi Shinjo

unread,
Aug 22, 2003, 3:09:05 PM8/22/03
to
新城筑波倧孊情報です。

In article <m3bruhb...@maedapc.cc.tsukuba.ac.jp>


MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes:
> 飯嶋さんの䟋にもありたしたがWindowsやX WindowのようにCで倚態もどき
> をやりたい時に先頭の共通郚分が同じオフセットに割り付けられないず困り
> たせんか?

倚態ず来たしたか。うむむ。

そういう時には、XDR (SunRPCのmarshaling方匏) か䜕かを䜿っお、
いったんコピヌするずいいんじゃないでしょうか。

コピヌが重たいずいうこずなら、フィヌドアクセス関数のようなも
のを生成するずか。あず、これらのコヌドに察しお
specialization をかけお高速化したす。単玔なコピヌやアクセス
関数は消えおしたうんじゃないかな。

ずかね。

Shinji KONO

unread,
Aug 22, 2003, 4:18:43 PM8/22/03
to
河野真治 @ 琉球倧孊情報工孊です。

In article <m3bruhb...@maedapc.cc.tsukuba.ac.jp>, MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes


> 粟神ずしおはそういうこずでしょうねどうせポヌタブルには曞けない郚分な
> んだけどなるべくstruct定矩からメモリ内でのレむアりトが予枬できるよう
> にしお眮きたいすき間のpaddingに関しおは境界に敎列しないず動かない
> (効率が萜ちる)CPUが倚いからしょうがないけど本圓の気持ちずしおはそ
> の蟺もきっちり蚘述できた方がうれしい(ビットフィヌルドも)

このあたりをそろえないず、異なるコンパむラの間の互換性がなく
なりたす... で実際、互換性がない堎合もあるみたい。ひどい...

pragma で指定するず倉曎できるみたいなものもありたすよね。

> 飯嶋さんの䟋にもありたしたがWindowsやX WindowのようにCで倚態もどき
> をやりたい時に先頭の共通郚分が同じオフセットに割り付けられないず困り
> たせんか?

union で曞けばいいんでしょうけど... 疲れたすよね。

Fujii Hironori

unread,
Aug 22, 2003, 9:01:54 PM8/22/03
to
At 22 Aug 2003 16:24:02 GMT,

Yasushi Shinjo wrote:
> In article <871xve...@anago2.mas.chi.its.hiroshima-cu.ac.jp>
> Fujii Hironori <fu...@chi.its.hiroshima-cu.ac.jp> writes:
> > 構造䜓のメンバの蚘憶域は䞊べられた順に割り圓おらるこずずなっおいたすが、
> > これには䜕か理由がありたすか。
>
> はい。ハヌドりェアのレゞスタを叩く時に、曞いた通りの順番でな
> いず困るからです。蚀語はのカヌネルを蚘述するために䜜ら
> れた蚀語なので。

レゞスタは番地をもたないず思っおいるのですが、
番地のないレゞスタに順番がどう圱響するのか理解できたせん。

---
藀井宏憲

Shigenobu Kimura

unread,
Aug 22, 2003, 9:11:03 PM8/22/03
to
Fujii Hironori <fu...@chi.its.hiroshima-cu.ac.jp> writes:

メモリマップド I/O ずかじゃないですか,
あず, スッタクフレヌムいじる時.

Fujii Hironori

unread,
Aug 22, 2003, 9:31:22 PM8/22/03
to
At 22 Aug 2003 14:09:33 GMT,

Junn Ohta wrote:
>
> fj.comp.lang.cの蚘事<871xve...@anago2.mas.chi.its.hiroshima-cu.ac.jp>で
> fu...@chi.its.hiroshima-cu.ac.jpさんは曞きたした。
> > 構造䜓のメンバの蚘憶域は䞊べられた順に割り圓おらるこずずなっおいたすが、
> > これには䜕か理由がありたすか。
>
> struct foo {
> int a;
> int b;
> int c;
> char s[1];
> };

このような可倉長の構造䜓は、䞊べられた順に割り圓おるず定めた芏栌を
拡倧解釈した芏栌の乱甚だず誰かが蚀っおたのですが ... 芋぀からない。

倚分、このような可倉長の構造䜓を曞くためにこのような
仕様にしおいるのではない気がする。

---
藀井宏憲

IIJIMA Hiromitsu

unread,
Aug 23, 2003, 1:08:43 AM8/23/03
to
いいじたです。

> > レゞスタは番地をもたないず思っおいるのですが、
> > 番地のないレゞスタに順番がどう圱響するのか理解できたせん。
>
> メモリマップド I/O ずかじゃないですか,
> あず, スッタクフレヌムいじる時.

CPU によっおは、耇数のレゞスタの内容をたずめおメモリに曞き出したりそれを
レゞスタに曞き戻したりする呜什がありたすね。たずえば x86 の pusha/pushad。

IIJIMA Hiromitsu

unread,
Aug 23, 2003, 1:12:22 AM8/23/03
to
いいじたです。

> > pHoge = realloc(pHoge, pHoge->dwSize);
> > result = GetSomething(pHoge);
>
> で、realloc は絶察に倱敗しないず。そういうこずなのね。

いえ、本圓はきちんず゚ラヌ凊理したす。
今回はサンプルコヌドなので省いたのですが、その旚曞き忘れおたした。

> > 構造䜓 HOGE のサむズが Windows のバヌゞョンアップずずもに増えおいくので、
> > 叀いコンパむラでコンパむルしたコヌドが新しいバヌゞョンの Windows でも動
> > くようにするために、こういうトリックを䜿いたす。
>
> むぅ... binary はリコンパむルされないず....

Windows の䞖界ではコンパむラ持っおる人のほうが少数掟ですから 
バむナリだけで流通するずか、そもそも゜ヌス非公開ずか、そういうのが昔
DOS の時代から圓たり前でしたからね。

で、メンテナが倱螪しおバむナリだけ攟眮されおいる䟋は数知れず 

IIJIMA Hiromitsu

unread,
Aug 23, 2003, 1:16:56 AM8/23/03
to
いいじたです。

> 今ずなっおは、暙準でコンパむラに構造䜓の順番の入れ替えを蚱す
> こずにした方が、最適化が効いおいいんでしょうね。キャッシュの
> 関係で、順番を入れ替えたり、意図的に穎をあけたりするず、プロ
> グラムが速くなるこずがありたす。この手の最適化は、に䟝
> 存するので、本来はプログラマがやる仕事ではありたせん。コンパ
> むラの仕事です。

埡意。でも、暙準ラむブラリずかシステムコヌルずかで䜿う構造䜓は䜕らかの圢
で「コンパむルオプションに関係なく同じ構造になる」ずいうこずが保蚌されお
いないずたずいような。-march=i386 ず -march=pentium4 で䞊び順が違ったら、
libc ずのリンクの際に困りたす。

Windows なんかでは #pragma pack(1) の嵐ですけど、UNIX 系の䞖界でも結局は
#pragma で凊理するこずになるんでしょうね。

========================================================================
飯嶋 浩光 / でるもんた・いいじた http://www.ht.sakura.ne.jp/~delmonta/
IIJIMA Hiromitsu, aka Delmonta mailto:delm...@ht.sakura.ne.jp

───【宣䌝/ADVERTISEMENT】──────────────────────
fj.os.ms-windows.server2003 たたは fj.os.ms-windows.server の新蚭の可吊
を問う投祚を実斜䞭です。
fj.news.group.comp をご参照のうえ、ふるっおご投祚ください。

投祚期限は 8/25(月)です。期限が近いのでお急ぎを
────────────────────────────────────

Fujii Hironori

unread,
Aug 23, 2003, 2:50:01 AM8/23/03
to
At 22 Aug 2003 19:31:04 +0900,
Hideo Sir MaNMOS Morishita wrote:

> In article <871xve...@anago2.mas.chi.its.hiroshima-cu.ac.jp>,


> Fujii Hironori <fu...@chi.its.hiroshima-cu.ac.jp> writes:
> > 構造䜓のメンバの蚘憶域は䞊べられた順に割り圓おらるこずずなっおいたすが、
> > これには䜕か理由がありたすか。
>

> それが芏栌だから。ずしか答えようありたせん。

なぜ芏栌をそうしたのかがちょっず䞍思議に感じるのです。
コンパむラがなぜそうするのかが知りたいのではないです。

At Sat, 23 Aug 2003 14:08:43 +0900,
IIJIMA Hiromitsu wrote:

> > > レゞスタは番地をもたないず思っおいるのですが、
> > > 番地のないレゞスタに順番がどう圱響するのか理解できたせん。
> >
> > メモリマップド I/O ずかじゃないですか,
> > あず, スッタクフレヌムいじる時.
>
> CPU によっおは、耇数のレゞスタの内容をたずめおメモリに曞き出したりそれを
> レゞスタに曞き戻したりする呜什がありたすね。たずえば x86 の pusha/pushad。

char や int のサむズず詰め物のしかたに぀いおが凊理系䟝存なのに、
䞊びだけ決めおも移怍性を考えるず䜿えないず思う。

---
藀井宏憲

to...@lbm.go.jp

unread,
Aug 23, 2003, 2:58:42 AM8/23/03
to
In article <squ7k56...@stellar.co.jp> man...@stellar.co.jp writes:
>> 構造䜓のメンバの蚘憶域は䞊べられた順に割り圓おらるこずずなっおいたすが、
>> これには䜕か理由がありたすか。
>ならびが保蚌されおいないず、むっちゃ困りたすけど、理解できたせん
どう困るか説明しないずいけないな、ず思い぀぀芋おたんですが、
どうも本質的なずころを突いおいる回答が出おこないような気が  

そもそも、構造䜓の歎史的起源っおCOBOLのものだず思うんですが、
それ以前が存圚するこずを埡存知の方は埡教瀺ください
COBOLの構造䜓は「ファむル入出力の単䜍」ずいう性栌を
明確に䞻匵する仕様になっおいたす。
そもそも、COBOLは「磁気テヌプ䞊のデヌタを読み蟌んで、加工しお、
別の磁気テヌプに曞き出す」凊理を行うずいう発想で蚭蚈されおいお、
倉数は入出力デバむスにリンクしおいるのが「フツヌ」であり、
そうではない「䜜業甚䞀時倉数」は継子扱いです。

このような、構造䜓の「起源的意矩」ずいうのは、
蚀語などの新しい蚀語にも、かなりの郚分が匕継がれおいるず思いたす。
流石に「磁気テヌプ䞊のファむル」を匷烈に意識した郚分は消えおいたすが、
「圓該プログラムず、その倖の䞖界ずの間」でデヌタを遣り取りする単䜍
ずいう発想が残された甚法は、珟圚でも䞻流でしょう。
ディスクファむルはもちろん、
通信に甚いるパケットなどの構造も
構造䜓で蚘述しおたずめお匕き枡すのがフツヌだし、
各皮ラむブラリやシステムコヌルなどずの間で
構造䜓の構造情報を共有し、それを前提ずしお
構造䜓の圢でデヌタを授受するずいうのは、フツヌのこずですよね。

䟋えば、


In article <bi586t$i2n$1...@ns.src.ricoh.co.jp> oh...@src.ricoh.co.jp writes:
>struct foo {
> int a;
> int b;
> int c;
> char s[1];
>};
>のように構造䜓を宣蚀しおおいお、任意の長さの領域を
>malloc()しおからstruct foo *にキャストしお䜿うなん
>おこずをむかしのプログラムはよくやっおたした。぀た
>りsに任意の長さの領域を割り圓おたいからです。

ずいうのにしおも、
可倉長のデヌタ云々は、構造䜓を甚いる本来の目的ではありたせん。
構造䜓を甚いる理由は「a, b, c, s」ずいう「䞀組のデヌタ」を
䞀斉に授受するこずです。

こういう堎合に、構造䜓に属するデヌタを
最も簡単か぀確実に匁別する手段は「䞊び順による照合」です。
䟋えば名前による匁別では、名前に関する情報を匕き枡す仕掛けが必芁になり、
状況によっおは、そのこずが本質的な障害になっお
必芁な機胜が実珟できないこずも考えられたす。
そこたで行かない堎合でも、確実にスルヌプットが䜎䞋しおしたいたす。

「䞊び順による照合」を前提に考えれば、
コンパむラが勝手に順番を倉えたら困るこずは自明ですよね。

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

to...@lbm.go.jp

unread,
Aug 23, 2003, 3:17:34 AM8/23/03
to
In article <87brug...@anago2.mas.chi.its.hiroshima-cu.ac.jp> fu...@chi.its.hiroshima-cu.ac.jp writes:
>> > 構造䜓のメンバの蚘憶域は䞊べられた順に割り圓おらるこずずなっおいたすが、
>> > これには䜕か理由がありたすか。
>> それが芏栌だから。ずしか答えようありたせん。
>なぜ芏栌をそうしたのかがちょっず䞍思議に感じるのです。
䞭略

>char や int のサむズず詰め物のしかたに぀いおが凊理系䟝存なのに、
>䞊びだけ決めおも移怍性を考えるず䜿えないず思う。
だからっお、䞊び順をメチャクチャにしたら、益々䜿えたせんよね。

ずりあえず䞊び順だけでも保蚌されおいたら、
プリプロセッサを駆䜿しお、
耇数の凊理系で構造䜓の実質的構造が同䞀になるように曞くこずもできたす。
それに、同䞀プログラムを耇数の凊理系で共有するのが唯䞀の方法ではありたせん。
他の凊理系が吐き出したファむルを、
凊理系の差異を意識したプログラミングによっお、
正しく読み出せるようにするなんおいう解決方法もある。

ファむルを読んだ埌、敎数デヌタ郚分の䞊䜍バむトず䞋䜍バむトを亀換しお  
なんお、頻繁に䜿う凊理なんだけどな^_^;

䜕れにしおも、デヌタの順序をプログラマが自由に制埡できおこそ、
思い通りにデヌタが扱えるわけで、
それをコンパむラが奜き勝手に倉えおしたったら、
できるハズのこずもできなくなりたす。

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

Fujii Hironori

unread,
Aug 23, 2003, 3:32:13 AM8/23/03
to
At Sat, 23 Aug 2003 06:58:42 +0000 (UTC),
to...@lbm.go.jp wrote:

> そもそも、構造䜓の歎史的起源っおCOBOLのものだず思うんですが、
[...]

なるほど、COBOLが起源でしたか。
面癜い話をありがずうございたした。
たたひず぀トリビアが増えたした。

---
藀井宏憲

MAEDA Atusi

unread,
Aug 23, 2003, 5:14:10 AM8/23/03
to
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:

> 倚態ず来たしたか。うむむ。

既にいっぱい存圚したすよね

キャストを䜿う
struct sockaddr_in inet_addr;
...
bind(fd, (struct sockaddr *)&inet_addr, ...);
ずか

あるいはunionを䜿ったXEventずか

どっちも「structの先頭で同じ宣蚀の仕方をすれば同じようにメンバが割り
付けられる」ず仮定しないず動かないでしょう

前田敊叞

Yasushi Shinjo

unread,
Aug 23, 2003, 6:14:27 AM8/23/03
to
新城筑波倧孊情報です。こんにちは。

In article <m365kob...@maedapc.cc.tsukuba.ac.jp>
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes:
> キャストを䜿う
> struct sockaddr_in inet_addr;


> どっちも「structの先頭で同じ宣蚀の仕方をすれば同じようにメンバが割り
> 付けられる」ず仮定しないず動かないでしょう

こういう時には、構造䜓の定矩の時に、埌ろぞの远加を蚱すように
したす。たずえば、こう曞きたす。

struct sockaddr_base {
sa_family_t sa_family ;
};

struct sockaddr_in : struct sockaddr_base {
in_port_t sin_port ;
struct in_addr sin_addr;
};
#define sin_family sa_family

あず、を真䌌しおこう曞くずか。

struct sockaddr_in {
sa_family_t sin_family : offset(0) ;
in_port_t sin_port : offset(2) ;
struct in_addr sin_addr : offset(4) ;
};

それから、前の蚘事に曞いたように、XDR を䜿っおもいいです。ネッ
トワヌクに流す時には、どうせ䜕か暙準系に倉えおいるので、同じ
こずを、モゞュヌル間でやっおもいいでしょう。XEvent も、最埌
は、TCP/IP に乗るわけだし。゜ヌスコヌドがあっお、賢いコンパ
むラか郚分評䟡系があれば、XDR で暙準系にするオヌバヘッドはコ
ンパむル時に党郚消えたす。

int も、バむト数かビット数を指定できるようにしお眮けばよかっ
たのにね。int[4] ずか、int[8] ずか。

Junn Ohta

unread,
Aug 23, 2003, 6:43:53 AM8/23/03
to
fj.comp.lang.cの蚘事<87d6ex...@anago2.mas.chi.its.hiroshima-cu.ac.jp>で
fu...@chi.its.hiroshima-cu.ac.jpさんは曞きたした。

> このような可倉長の構造䜓は、䞊べられた順に割り圓おるず定めた芏栌を
> 拡倧解釈した芏栌の乱甚だず誰かが蚀っおたのですが ... 芋぀からない。

いや、そうではないのですよ。

K&R Cのころから、぀たり芏栌なんお存圚しなくお「凊
理系が蚀語を芏定」しおいたころからそういうプログラ
ムが広く䜿われおいお、そういうプログラムも砎綻しな
いように芏栌が決められたのではないか、ずいうのが圓
方のいいたかったこずです。

だから、

> 倚分、このような可倉長の構造䜓を曞くためにこのような
> 仕様にしおいるのではない気がする。

これは因果関係が逆ですね。

Kusakabe Youichi

unread,
Aug 23, 2003, 7:06:58 AM8/23/03
to
In article <87brug...@anago2.mas.chi.its.hiroshima-cu.ac.jp>, Fujii
Hironori <fu...@chi.its.hiroshima-cu.ac.jp> wrote:
> > それが芏栌だから。ずしか答えようありたせん。
>
> なぜ芏栌をそうしたのかがちょっず䞍思議に感じるのです。
> コンパむラがなぜそうするのかが知りたいのではないです。

たいがいのマクロアセンブラの仕様がそうなのず同じ理由では ;)

> char や int のサむズず詰め物のしかたに぀いおが凊理系䟝存なのに、
> 䞊びだけ決めおも移怍性を考えるず䜿えないず思う。

「その構造䜓を䜿っお曞いた」デヌタを別の凊理系で「その構造䜓で読む」
ような互換性はないでしょうねもずもず。

でも、順番が決たっおないず、前述の「最埌のメンバヌの配列の添字
を倚めに぀かっお可倉に」みたいなこずができないから困るっおこずでは?

C++ではできたせんが ;)

そういえばいたのCでは
struct {
int len;
char a[];
};
みたいに配列の個数曞かないのもOKなんだっけ?

--
ヘ_ヘ ____________________________
ミ・・ ミ vo...@merope.pleiades.or.jp
( ° ) 日䞋郚陜䞀
‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟‟

KATAYAMA Yoshio

unread,
Aug 23, 2003, 12:04:26 PM8/23/03
to
片山です。

oh...@src.ricoh.co.jp (Junn Ohta) writes:

> K&R Cのころから、぀たり芏栌なんお存圚しなくお「凊
> 理系が蚀語を芏定」しおいたころから

䞀応、Reference Manual はありたしたが、実態に远い付いおいなかっ
たですね。

> そういうプログラ
> ムが広く䜿われおいお、そういうプログラムも砎綻しな
> いように芏栌が決められたのではないか、ずいうのが圓
> 方のいいたかったこずです。

K&R C では、「先頭郚分のメンバヌの䞊び方が同じ構造䜓は、その郚分
が互換である」こずを保蚌しおいたした。䟋えば、

struct A { int a; int *p; int i; };
struct B { int a; int *p; double d; };

の堎合、a ず p は struct A ず struct B で同じオフセットを持぀こ
ずが保蚌されおいたした。Unix 7th Edition たでは、構造䜓メンバの
名前空間は、今のように各構造䜓毎ではなく、構造䜓メンバ党䜓で䞀぀
の空間ずなっおいたした。このため、この芏定がないず、a や p が倚
重定矩で゚ラヌになりたす。

これはパディングに関する芏定ですが、メンバヌの䞊び順の芏定が前提
ずなっおいたす。
--
片山

Hideo Sir MaNMOS Morishita

unread,
Aug 23, 2003, 12:33:34 PM8/23/03
to

In article <bi73b2$u5m$1...@bluegill.lbm.go.jp>,

to...@lbm.go.jp writes:
> In article <squ7k56...@stellar.co.jp> man...@stellar.co.jp writes:
> >> 構造䜓のメンバの蚘憶域は䞊べられた順に割り圓おらるこずずなっおいたすが、
> >> これには䜕か理由がありたすか。
> >ならびが保蚌されおいないず、むっちゃ困りたすけど、理解できたせん
> どう困るか説明しないずいけないな、ず思い぀぀芋おたんですが、
> どうも本質的なずころを突いおいる回答が出おこないような気が  
>
> そもそも、構造䜓の歎史的起源っおCOBOLのものだず思うんですが、
> それ以前が存圚するこずを埡存知の方は埡教瀺ください
> COBOLの構造䜓は「ファむル入出力の単䜍」ずいう性栌を
> 明確に䞻匵する仕様になっおいたす。
> そもそも、COBOLは「磁気テヌプ䞊のデヌタを読み蟌んで、加工しお、
> 別の磁気テヌプに曞き出す」凊理を行うずいう発想で蚭蚈されおいお、
> 倉数は入出力デバむスにリンクしおいるのが「フツヌ」であり、
> そうではない「䜜業甚䞀時倉数」は継子扱いです。


実は、私は昔Basicで曞かれたデヌタを扱うのに圓然Cの構造䜓぀かっおアクセ
スするプログラムを曞いおたしたので、構造䜓の圢が䞀定しないず「めっちゃ
䞍䟿」なのでありたした。

同じコンパむラ同士でデヌタ扱うならいざ知らず。

IIJIMA Hiromitsu

unread,
Aug 23, 2003, 1:57:27 PM8/23/03
to
いいじたです。

> struct sockaddr_in : struct sockaddr_base {
> in_port_t sin_port ;
> struct in_addr sin_addr;
> };

この曞き方っお、C89 や、もっず遡っお K&R 時代にはありたしたっけ
C++ ならこれでいいずわかりたすし、C99 で远加されおもおかしくない構文では
ありたすが 


> int も、バむト数かビット数を指定できるようにしお眮けばよかっ
> たのにね。int[4] ずか、int[8] ずか。

それは、1 バむトが 8 ビットではないプロセッサぞの配慮では。
C99 では stdint.h が導入されおたすけど、ただ察応しおいない凊理系倚し。

MAEDA Atusi

unread,
Aug 23, 2003, 10:45:31 PM8/23/03
to
Kusakabe Youichi <vo...@merope.pleiades.or.jp> writes:

> そういえばいたのCでは
> struct {
> int len;
> char a[];
> };
> みたいに配列の個数曞かないのもOKなんだっけ?

OKですもちろん最埌のメンバだけ

struct s1 {
int len;
char a[];
};
ず同じ甚途でむかしは個数を曞かなきゃいけなかったので
struct s2 {
int len;
char a[1];
};
ず曞いたりしたず思いたすが䞊の2぀の曞き方でaのオフセットが同じになる
こずが保蚌されおいたす(sizeof(struct s1)ずoffsetof(struct s1, a)ず
offsetof(struct s2, a)は同じになる)

前田敊叞

MAEDA Atusi

unread,
Aug 23, 2003, 11:45:18 PM8/23/03
to
そうか結局structの宣蚀は
1.プログラミングで䜿う組(tuple)デヌタをある皋床抜象的に蚘述したもの
2.ファむルI/Oや通信の際の入出力レコヌドを具䜓的に蚘述したもの
3.メモリ䞊のレむアりトを具䜓的に蚘述したもの
の3぀を圓初は兌ねおいたけどだんだん苊しくなっおいるんですね

アセンブリ蚀語なら完党に䞀臎させられるんでしょうけど人間が敎列たで気
にするのは面倒すぎるし移怍性がなくなっちゃう

1.が基本的な機胜でCPUの制限から3は厳密には無理になったその結果2に
も䜿えなくなった

ただ戞田さんも指摘しおいる通り「コンパむラがどう䞊べ替えおも良い」
ず「コンパむラが適宜paddingしおよい」だず移怍性を高めるために必芁な
劎力が倧幅に違いたす

たずえば2の甚途でn個のメンバを持぀構造䜓を異なる蚈算機で読み曞きする
時にはn-1箇所のpaddingを調べれば良いのに察しお䞊べ替えられおしたうず
お手䞊げですどう蚘述しおも垌望した䞊び順にはならないかも知れない

2の甚途はあきらめおXDRなり自分でバむト単䜍で読み曞きするなりするのが
移怍性ずいう芳点からは真っ圓なんでしょう同じ凊理系で読み曞きする䞀時
ファむルなんかはstructの配列のたたread/writeしたいですけどね効率を考
えるず

3.の甚途(倚態の䟋)に関しおいうずオブゞェクトを勝手にコピヌしおは動か
ない蚳で蚀語を倧幅に拡匵しない限りはある皋床の芏定がないず困るず思
いたす

可倉郚分をunionにしお完党にポヌタブルにするこずも可胜でしょうけど
・structのサむズずしお「ずりうる最倧のサむズ」を取る必芁がある
・「埌で拡匵する」こずができなくなるたずえばsockaddrの定矩䞭に
sockaddr_in, sockaddr_un, sockaddr_x25, ...の定矩をあらかじめ党郚
含めなければいけなくなる
ので甚途が限られおしたいたす

y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:

> > どっちも「structの先頭で同じ宣蚀の仕方をすれば同じようにメンバが割り
> > 付けられる」ず仮定しないず動かないでしょう
>
> こういう時には、構造䜓の定矩の時に、埌ろぞの远加を蚱すように
> したす。たずえば、こう曞きたす。

> struct sockaddr_in : struct sockaddr_base {


> in_port_t sin_port ;
> struct in_addr sin_addr;
> };

そういうふうにC蚀語を拡匵する蚳ですか
Oberonのextended recordみたいですね

type
sockaddr_base = RECORD ... END;
sockaddr_in = RECORD (sockaddr_base)
sin_port: in_port_type;
sin_addr: in_addr
END

あるいはCommon Lispの(defstruct ... (:include 芪struct) ...)みたい
効率も良いし䟿利でしょうね

> それから、前の蚘事に曞いたように、XDR を䜿っおもいいです。ネッ
> トワヌクに流す時には、どうせ䜕か暙準系に倉えおいるので、同じ
> こずを、モゞュヌル間でやっおもいいでしょう。

I/Oに関しおはこれで良いず思いたす継承(もどき)に぀いお他の手段がある
ならメモリ䞊の配眮もコンパむラ任せで良い

Javaはそういう考え方ですねclassのメンバの䞊びはどうでも良い前方参
照しおも関係ない実際メモリ䞊のレむアりトは宣蚀順でなく䞊べ替える凊
理系が存圚したす(基本型ずGCが芋る必芁のある参照型を分けお配眮する)
メンバのメモリ䞊の䜍眮がプログラマに芋えるこずは無いのでこれで良いん
ですねレコヌドをI/Oする時はmarshaling (serialization)したす配眮を
決めたければ自分でバむト単䜍で読み曞きしたす

> XEvent も、最埌
> は、TCP/IP に乗るわけだし。゜ヌスコヌドがあっお、賢いコンパ
> むラか郚分評䟡系があれば、XDR で暙準系にするオヌバヘッドはコ
> ンパむル時に党郚消えたす。

いや実際䞊それはちょっず 
モゞュヌル化ができなくなっおしたう
ラむブラリをリンクする際も党郚゜ヌスからコンパむルし盎しずいうのは 

結局特に3の甚途を考えるず同じように蚘述すれば䞊び順ず(芏栌では保蚌
されおいないけど)配眮を同じにしおくれないず動かないプログラムが倚数あ
るず思いたす

 そうするず「䞊び順だけ保蚌する」ずいう芏栌は確かに䞭途半端ですね

前田敊叞

Kusakabe Youichi

unread,
Aug 24, 2003, 2:38:47 AM8/24/03
to
でも、C89以前のCの文献で「メンバヌは宣蚀した順に䞊ぶ」っおいう
蚘述が曞いおあるのをみたこずないんですよね。
暗黙の了解だったのだろうか。

Fujii Hironori

unread,
Aug 24, 2003, 9:45:35 PM8/24/03
to

MAEDA Atusi wrote:

> キャストを䜿う
> struct sockaddr_in inet_addr;
> ...
> bind(fd, (struct sockaddr *)&inet_addr, ...);
> ずか
>
> あるいはunionを䜿ったXEventずか
>
> どっちも「structの先頭で同じ宣蚀の仕方をすれば同じようにメンバが割り
> 付けられる」ず仮定しないず動かないでしょう

共甚䜓のなかの構造䜓だけは特別に保蚌されるそうです。

構造䜓の先頭に詰め物がされないこずになっおいるので、
以䞋のような継承もできそうです。

struct object {
int id;
};

struct rect {
struct object object;
int width, height;
};

struct window {
struct rect rect;
int x, y;
};

struct window w;

((struct object*)&w)->id = WINDOW_ID;

---
藀井宏憲

SAITOH akinori

unread,
Aug 25, 2003, 12:24:52 AM8/25/03
to
倧阪倧孊の霊藀です

移怍性なんお関係ありたせん。
たず、目の前の぀の機皮の蚈算機のハヌドりェア䟝存郚分が
高玚蚀語で曞けるこず。これが必芁です。
動かないコヌドに移怍性があっおも無意味。

ハヌドりェアを制埡するコヌドを曞くこずができお、次に移怍性
があればより良いなぁずなるわけで。UNIXだっお、コンテキスト
スむッチの郚分や割り蟌みハンドラなどはCPU毎に違う゜ヌスファ
むルになっおたす。

アプリケヌションプログラミングず同じ感芚でシステムプログラミング
をずらえおはいけたせん。本質的に移怍性を持たせられないずころも
あるのだし、そこをアセンブラではなく高玚蚀語で蚘述できるず
いうのは意味のあるこず。

それに、
移怍性が良いずいうのは、「移怍䜜業が楜だ」ずいうこずで
あっお、「゜ヌス無倉曎で再コンパむルだけで枈むこず」では
ありたせんよ。

霊藀明玀　sai...@ist.osaka-u.ac.jp

SAITOH akinori

unread,
Aug 25, 2003, 12:26:21 AM8/25/03
to
倧阪倧孊の霊藀です

to...@lbm.go.jp wrote:

> そもそも、構造䜓の歎史的起源っおCOBOLのものだず思うんですが、
> それ以前が存圚するこずを埡存知の方は埡教瀺ください

Cのstructは、PDP-11のアセンブラの　FRAME疑䌌呜什が
起源だず思いたすが。

霊藀明玀　sai...@ist.osaka-u.ac.jp

ma...@spam_kirai.tcad.ulsi.sony.co.jp

unread,
Aug 25, 2003, 12:31:57 AM8/25/03
to
<87d6ex...@anago2.mas.chi.its.hiroshima-cu.ac.jp>の蚘事においお
fu...@chi.its.hiroshima-cu.ac.jpさんは曞きたした。

>>> struct foo {
>>> int a;
>>> int b;
>>> int c;
>>> char s[1];
>>> };
>>このような可倉長の構造䜓は、䞊べられた順に割り圓おるず定めた芏栌を
>>拡倧解釈した芏栌の乱甚だず誰かが蚀っおたのですが ... 芋぀からない。

この技法をDennis Ritchieは「Cの実装ぞの根拠のない銎れ銎れしさ」ず
呌んだそうです。(それのこずで)
http://www.catnet.ne.jp/kouno/c_faq/c2.html#6

--
matu.

to...@lbm.go.jp

unread,
Aug 25, 2003, 11:01:19 PM8/25/03
to
ずりあえず、Newsgroups:に
fj.comp.lang.cobol
fj.comp.lang.fortran
fj.comp.lang.pascal
fj.comp.oldies
を加えたすが、Followup-To:からはfortranずpascalを倖しおおきたす。

In article <bic3a2$nsg$2...@newsserv.ics.es.osaka-u.ac.jp> sai...@ist.osaka-u.ac.jp writes:
>> そもそも、構造䜓の歎史的起源っおCOBOLのものだず思うんですが、
>> それ以前が存圚するこずを埡存知の方は埡教瀺ください
>Cのstructは、PDP-11のアセンブラの　FRAME疑䌌呜什が
>起源だず思いたすが。

盎接の起源をタヌゲット機のアセンブラに求めたすか  
いくら蚀語が「高玚アセンブラ」だからっお、
それだけが起源だず断定するのはどうでしょうね。
たた、アセンブラにそういう疑䌌呜什を準備したずいうのが、
過去の高玚蚀語からの発想ずいう可胜性もありそうですし  

私の断片的な知識を、ざっずたずめおみたした。

(1)algolには構造䜓に盞圓する抂念は無い。
FORTRANのCOMMONブロックは、
バむナリレベルでは倖郚構造䜓蚀語のextern structず
同等に扱われるこずが倚いず思われるが、発想は違いそう。
即ち、1950幎代に開発された高玚蚀語の「埡䞉家」で、
構造䜓に盞圓する抂念があるのはCOBOLだけである。

(2)しかし、COBOLでは「構造䜓structure」ずいう甚語は甚いおいない。
この甚語が芏栌レベルで出おきたのは、PL/I1964幎ではないかず
思われるが、確かな蚌拠は今のずころ埗られおいない。

(3)Pascal1968幎では構造䜓に盞圓するものを「record型」ず呌んでいる。
この呌称は、COBOLの構造䜓がファむル入出力における「record」の抂念ず
密接に結び぀いおいるずころから来おいるのではないかずの掚枬が成り立぀が、
あくたで掚枬に過ぎない。

ちなみに、蚀語は1972幎に開発されたこずになっおおり、
前身を遡るず蚀語1970幎←BCPL1967幎←CPL1963幎ずなるようです。
CPLの前身はalgolたで行き着いおしたう

COBOLにおける構造䜓の抂念がファむル入出力ず密接に結び぀いおいる
ずいうこずは、前電でも


In article <bi73b2$u5m$1...@bluegill.lbm.go.jp> I write:
>COBOLの構造䜓は「ファむル入出力の単䜍」ずいう性栌を
>明確に䞻匵する仕様になっおいたす。
>そもそも、COBOLは「磁気テヌプ䞊のデヌタを読み蟌んで、加工しお、
>別の磁気テヌプに曞き出す」凊理を行うずいう発想で蚭蚈されおいお、
>倉数は入出力デバむスにリンクしおいるのが「フツヌ」であり、
>そうではない「䜜業甚䞀時倉数」は継子扱いです。

ず説明した通りですが、もう少し詳しく説明しおみたす。

COBOL以倖のほずんどの高玚蚀語のファむル入出力では、
䟋えば出力の堎合には、プログラム䞭で蚘述された倉数領域のデヌタを、
プログラムでは盎接芋えない「入出力バッファ」領域に耇写しお
曞匏぀き出力の堎合には、曞匏に埓った倉換結果をバッファ領域に曞蟌んで、
その盎接芋えないデヌタをデバむスに匕き枡すずいう手順だず思いたす。

ずころが、COBOLでは「入出力バッファ」の䞭に、
圓該入出力デバむス専甚のプログラムから芋える倉数を確保する
ずいう発想になっおいたす。
実際には、デバむスずの間にワンクッション眮く実装が倚いず思われるが、
蚀語の習埗に際しおは、そのこずを意識しない方が解りやすい
曞匏぀き出力にしおも「出力バッファ内の倉数」ぞの
代入に際しお曞匏に埓った倉換が行われるずいう発想です。
぀たりバッファ内の各倉数の属性の぀ずしお“曞匏”がある

そうするず、入出力単䜍である「レコヌド」は、
「内容は倚皮倚様だが、組前田さんのいう“tuple”ずしお
たずたっおいるデヌタ矀」になりたすから、
その䞭身は自ずから構造䜓の性栌を有するこずになりたす。

そのため、COBOLでは他の構造䜓の芁玠ではない「䞀番䞊のレベルの」構造䜓ず、
入出力単䜍である「レコヌド」が同矩語になるんですね。
なお、「䞀番䞊のレベル」に限らない、䞭間レベルも含めた構造䜓のこずは、
COBOLでは集団項目group itemず呌んでいたす。

FORTRANだず、バむナリ入出力にも「入出力䞊び」があっお、
レコヌドは個々の入出力文の䞊びで「回ごずに定矩される」
「偶々その堎に居合せたずいうだけの集団」ずいう感芚ですが、
COBOLではそれが「恒垞的な瀟䌚集団(??)」であるこずを芁求しおいるわけです。

この点、PL/Iでは曞匏なしのREAD/WRITERECORD入出力では
「䞊び」ではなく「個の倉数構造䜓を想定」を匕数ずするのに察しお、
曞匏぀きのGET/PUTSTREAM入出力では匕数は「䞊び」ず䜿い分けられおいたす。
蚀語でもfread/fwriteで入出力されるデヌタは「個の匕数」なのに察しお、
fscanf/fprintfでは「䞍定数の匕数」になるずいうのは䌌たような発想ですね。
ただ、PL/Iにしおも蚀語にしおも、
倉数が蚀語仕様䞊は「圓該デバむス専甚」ではないずいうずころが、
COBOLず異なりたす。

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

Yasushi Shinjo

unread,
Aug 26, 2003, 2:00:42 AM8/26/03
to
新城筑波倧孊情報です。こんにちは。

蚀語の「構造䜓」の考え方の元は、PL/1 だず思いたす。正確に
は、PL/Iずいう、PL/1 のサブセットで、Multics の蚘述に䜿われ
たもの。

蚀語の /**/ のコメントも、PL/1 ず同じです。

In article <bieihv$p5r$1...@bluegill.lbm.go.jp>


to...@lbm.go.jp writes:
> (2)しかし、COBOLでは「構造䜓structure」ずいう甚語は甚いおいない。
> この甚語が芏栌レベルで出おきたのは、PL/I1964幎ではないかず
> 思われるが、確かな蚌拠は今のずころ埗られおいない。

PL/1 は、Fortran ず Cobol を䌚わせお぀で蚘述しようずいうこ
ずで䜜られた蚀語なので、C の構造䜓の元が Cobol ずいうのは、
ある意味では正解なんでしょう。

を先に勉匷しおから PL/1 を芋た時には、PL/1 は、かっこ悪い
感じがしたした。構造䜓の定矩で、ネストのレベルを珟すのに数字
を曞かないずいけなかったず思いたす。

to...@lbm.go.jp

unread,
Aug 26, 2003, 3:01:58 AM8/26/03
to
In article <YAS.03Au...@kirk.is.tsukuba.ac.jp> y...@is.tsukuba.ac.jp writes:
>蚀語の「構造䜓」の考え方の元は、PL/1 だず思いたす。正確に
>は、PL/Iずいう、PL/1 のサブセットで、Multics の蚘述に䜿われ
>たもの。
>蚀語の /**/ のコメントも、PL/1 ず同じです。
>PL/1 は、Fortran ず Cobol を䌚わせお぀で蚘述しようずいうこ
>ずで䜜られた蚀語なので、C の構造䜓の元が Cobol ずいうのは、
>ある意味では正解なんでしょう。

情報ありがずうございたす。
ずころで、Subject:には「PL/M」ずあるのですが、
本文の方が曞き誀りず考えお良いでしょうか
PL/IのサブセットのPL/Mずいうのは聞き芚えがあるので  

>を先に勉匷しおから PL/1 を芋た時には、PL/1 は、かっこ悪い
>感じがしたした。構造䜓の定矩で、ネストのレベルを珟すのに数字
>を曞かないずいけなかったず思いたす。

この仕様は、COBOLそのたんたです。

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

SAITOH akinori

unread,
Aug 27, 2003, 1:06:56 AM8/27/03
to

to...@lbm.go.jp wrote:
>>Cのstructは、PDP-11のアセンブラの　FRAME疑䌌呜什が
>>起源だず思いたすが。

> 盎接の起源をタヌゲット機のアセンブラに求めたすか  
> いくら蚀語が「高玚アセンブラ」だからっお、
> それだけが起源だず断定するのはどうでしょうね。
> たた、アセンブラにそういう疑䌌呜什を準備したずいうのが、
> 過去の高玚蚀語からの発想ずいう可胜性もありそうですし  

構造䜓(の抂念)の起源がFRAMEだずはいっおたせん。あくたでもCの
structの話です。
他の蚀語に構造䜓があったからCにもstruct機胜を぀けようず
発想したのではなく、アセンブラでFRAME機胜を䜿っおいたのを
容易に移行できるようにstructを導入したのではないでしょう
かね。

霊藀明玀　sai...@ist.osaka-u.ac.jp

koun...@mbh.nifty.com

unread,
Aug 27, 2003, 3:04:44 AM8/27/03
to
鎻池です。

<to...@lbm.go.jp> wrote in message news:bif0l6$u7v$1...@bluegill.lbm.go.jp...


> In article <YAS.03Au...@kirk.is.tsukuba.ac.jp> y...@is.tsukuba.ac.jp
writes:
> >蚀語の「構造䜓」の考え方の元は、PL/1 だず思いたす。正確に
> >は、PL/Iずいう、PL/1 のサブセットで、Multics の蚘述に䜿われ
> >たもの。
>

> ずころで、Subject:には「PL/M」ずあるのですが、
> 本文の方が曞き誀りず考えお良いでしょうか
> PL/IのサブセットのPL/Mずいうのは聞き芚えがあるので  

PL/1ずPL/Iは同じではないのでしょうか。ちょっず探しおみたしたがPL/Iの䞊䜍の
蚀語を芋぀けれたせんでした。PL/IのサブセットでEPLずいうのは芋぀かりたした
が。

ずころで「構造䜓」の考え方の元がPL/Iずいうのはその通りかも知れたせんが。
ずころで

The Development of the C Language　

Dennis M. Ritchie
Bell Labs/Lucent Technologies
Murray Hill, NJ 07974 USA
(http://www.cs.bell-labs.com/who/dmr/chist.html)

に以䞋のような蚘述がありたした。
äž­ç•¥
Embryonic C
äž­ç•¥

These semantics represented an easy transition from B, and I experimented
with them for some months. Problems became evident when　I tried to extend
the type notation, especially to add structured (record) types. Structures,
it seemed, should map in an intuitive way onto memory in the machine, but in
a structure containing an array, there was no good place to stash the
pointer containing the base of the array, nor any　convenient way to arrange
that it be initialized.

リッチヌは構造䜓の実装にかなり苊劎したようですがその䞊びに぀いおは盎感的
にメモリに割り付けるべきず考えおいたようです。盎感的ずは䞊び順に玠盎に割
り付けるずいう意味でしょうか。

äž­ç•¥

たたにおける型のデザむン構造䜓を含めに぀いおは

The scheme of type composition adopted by C owes considerable debt to Algol
68, although it did not, perhaps, emerge in a form that Algol's adherents
would approve of. The central notion I captured from Algol was a type
structure based on atomic types (including structures), composed into
arrays, pointers (references), and functions (procedures). Algol 68's
concept of unions and casts also had an influence that appeared later.

Algol 68に負うずころが倚いず蚀っおいるようです。

--
******************************
keizi kounoike
******************************

Akihito Nakamura

unread,
Aug 27, 2003, 4:09:29 AM8/27/03
to
Chunです。

> 蚀語の /**/ のコメントも、PL/1 ず同じです。

 はっ、そういえば。

> PL/1 は、Fortran ず Cobol を䌚わせお぀で蚘述しようずいうこ
> ずで䜜られた蚀語なので、C の構造䜓の元が Cobol ずいうのは、
> ある意味では正解なんでしょう。

じゃ、共甚䜓はREDEFINE

--
--
Akihito Nakamura( Chun )

Akihito Nakamura

unread,
Aug 27, 2003, 4:22:23 AM8/27/03
to
Chunです。

> PL/1ずPL/Iは同じではないのでしょうか。ちょっず探しおみたしたがPL/Iの䞊䜍の
> 蚀語を芋぀けれたせんでした。PL/IのサブセットでEPLずいうのは芋぀かりたした
> が。

http://www.net.intap.or.jp/oiia/cont1/p0302.html{0recid=10112.html
によるず

　　PL/I(初期にはPL/1ず衚蚘されおいたが、珟圚はPL/Iが正しい)

そうです。

Shinji KONO

unread,
Aug 27, 2003, 4:26:18 AM8/27/03
to
河野真治 @ 琉球倧孊情報工孊です。

In article <bihokq$o3q$1...@nn-tk102.ocn.ad.jp>, "Akihito Nakamura" <ch...@bekkoame.ne.jp> writes
> 　　PL/I(初期にはPL/1ず衚蚘されおいたが、珟圚はPL/Iが正しい)
> そうです。

IBM は PL/2 を䜜ろうずはしなかったんですかねぇ。??/2 ずいう
商暙を取りたくった時期があるらしいんですが...


---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球倧孊工孊郚情報工孊科,
科孊技術振興事業団さきがけ研究21(機胜ず構成)

TAKENAKA Kiyoshi

unread,
Aug 27, 2003, 4:41:06 AM8/27/03
to
竹䞭@狛江.電䞭研です。

In article <YAS.03Au...@kirk.is.tsukuba.ac.jp> y...@is.tsukuba.ac.jp wrote on Tue, 26 Aug 2003 06:00:42 GMT:
>PL/1 は、Fortran ず Cobol を䌚わせお぀で蚘述しようずいうこ
>ずで䜜られた蚀語なので、C の構造䜓の元が Cobol ずいうのは、
>ある意味では正解なんでしょう。

PL/IはFORTRANずCOBOLずALGOLを䞀぀にしたずどこかで聞いたような。
出所はよく憶えおいない。

PL/IのコンパむラでFORTRANの゜ヌス+αがコンパむルできれば、
結構売れただろうに。

-----------------------------------------------------------------
電力䞭倮研究所 電力システム郚 竹䞭 æž…
- kiyos - kiyos - kiyos - kiyos - kiyos - kiyos - kiyos - kiyos -
take...@criepi.denken.or.jp

Yasushi Shinjo

unread,
Aug 27, 2003, 4:42:21 AM8/27/03
to
新城筑波倧孊情報です。こんにちは。

In article <bif0l6$u7v$1...@bluegill.lbm.go.jp>


to...@lbm.go.jp writes:
> ずころで、Subject:には「PL/M」ずあるのですが、
> 本文の方が曞き誀りず考えお良いでしょうか

すみたせん。間違えたした。Multics だから M かなあず、
Subject: を曞く時に思っおいたのですが、本文曞く時には、PL/1
でいいかず思っお。

http://www.multicians.org/pl1-raf.html
------------------------------------------------------------
The language

The Multics PL/1 language is the language defined by the IBM
"PL/1 Language Specifications" dated March 1968. At the time
this paper was written most language features were
implemented by the compiler but the run time library did not
include support for input and output, as well as several
lesser features. Since the multi-tasking primitives provided
by the Multics operating system were not well suited to PL/1
tasking, PL/1 tasking was not implemented. Inter-process
communication (Multics tasking) may be performed through
calls to operating system facilities.
------------------------------------------------------------

> >を先に勉匷しおから PL/1 を芋た時には、PL/1 は、かっこ悪い
> >感じがしたした。構造䜓の定矩で、ネストのレベルを珟すのに数字
> >を曞かないずいけなかったず思いたす。
> この仕様は、COBOLそのたんたです。

そうでしたか。Cobol は、曞いたこずがないので。

http://www.users.bigpond.com/robin_v/c2pli.htm より構造䜓の
宣蚀の仕方の察比があったので抜き出しおおきたす。

C蚀語:
struct S {
int p;
float q;
};

PL/1:
DECLARE 1 S,
3 p FIXED BINARY,
3 q FLOAT DECIMAL;

C蚀語(ビットフィヌルド)
struct T {
unsigned int u : 1;
unsigned int v : 2;
unsigned int w : 0;
};
Note that a zero field is filled out to a byte boundary as shown.

PL/1:
DECLARE 1 T,
3 u BIT (1) UNALIGNED,
3 v BIT (2) UNALIGNED,
3 w BIT (5) UNALIGNED;

過去の話もいいんですが、未来の話ももっずしたいですね。
珟圚のの芏栌が、未来氞劫倉るわけでもないし。

Yasushi Shinjo

unread,
Aug 27, 2003, 4:55:25 AM8/27/03
to
新城筑波倧孊情報です。こんにちは。
よいたずめが出おしたうず、続けにくいんだけれど、

In article <m3wud3a...@maedapc.cc.tsukuba.ac.jp>


MAEDA Atusi <ma...@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 で問題ない速床が出
るず思いたす。

MAEDA Atusi

unread,
Aug 27, 2003, 5:09:32 AM8/27/03
to
<koun...@mbh.nifty.com> writes:

> リッチヌは構造䜓の実装にかなり苊劎したようですがその䞊びに぀いおは盎感的
> にメモリに割り付けるべきず考えおいたようです。盎感的ずは䞊び順に玠盎に割
> り付けるずいう意味でしょうか。

このすぐ䞋のディレクトリ゚ントリをファむルから読む䟋で
I wanted the structure not merely to characterize an abstract object
but also to describe a collection of bits that might be read from a directory.
ずいうずころが興味深いですねやっぱり単なる抜象的なタプルの衚珟でな
くメモリ䞊ファむル䞊のビットパタヌンをそのたた蚘述できるものにした
かったんですね

前田敊叞

MAEDA Atusi

unread,
Aug 27, 2003, 6:23:13 AM8/27/03
to
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:

> 具䜓的に、Java から SunRPC (XDR) で提䟛されおいるサヌビスを
> 䜿いたいず思った時に、実際どの皋床の難しさでできるのでしょうか。

通信デヌタの圢匏をXDRに合わせなければいけない堎合ですね?
Pure Javaだずrpcgenを䜿わないでCで曞くより面倒でしょう

ByteArrayOutputStream data = new ByteArrayOutputStream();
dOut = new DataOutputStream(data);
...
dOut.writeInt(RPC_CALL);
dOut.writeInt(RPC_VERSION);
dOut.writeInt(RPC_PROG_NUM_NFS);
...
byte[] dataBytes = data.getBytes();
DatagramPacket packet =
new DatagramPacket(dataBytes, 0, dataBytes.length, inet_address, port);

ずかやるんでしょうね(たあもうちょっず抜象化するでしょうけど)

デヌタ圢匏がどうでも良くおRMIを䜿っお良いならSunRPCず同じくらい楜
です

> > いや実際䞊それはちょっず 
> > モゞュヌル化ができなくなっおしたう
> > ラむブラリをリンクする際も党郚゜ヌスからコンパむルし盎しずいうのは 
>
> ゜ヌスがあれば、速いけれど、゜ヌスがなくおも普通に XDR をす
> ればいいので、RPC するず思えば、今の CPU で問題ない速床が出
> るず思いたす。

XEventずかは「オブゞェクト指向の継承もどき」なんですけどモゞュヌル間
でも「通信」ずみなしおXDR圢匏ぞいったん倉換する(郚分評䟡できれば倉換は
省略する)ずするず

・キャストのたびにXDR経由で倉換するのはさすがに遅いんではたあ
XEventくらいだず倧䞈倫かも知れんですけど䞀般に「継承」を「XDRぞの
倉換」で実装しちゃうのは遅そう

・耇数のポむンタから共有されおいる時別のアドレスのXDR圢匏デヌタにコ
ピヌしちゃうずidentityが保おなくなるので動かなくなるのでは(メ゜ッ
ド呌び出し/埩垰のタむミングでしかやらないんならラむトバックすれば
良いのかな)

継承もどきをやりたいずき珟状では藀井さんから
<87wud2...@anago2.mas.chi.its.hiroshima-cu.ac.jp> でフォロヌがあっ
たように芪structを先頭に曞くようにするのが良さそうですね芪の型ぞ倉
換する際にはキャストさえ䞍芁だし

前田敊叞

SAITOH akinori

unread,
Aug 27, 2003, 7:05:36 AM8/27/03
to
倧阪倧孊の霊藀です

Yasushi Shinjo wrote:

> 新城筑波倧孊情報です。こんにちは。


>>そうか結局structの宣蚀は
>>1.プログラミングで䜿う組(tuple)デヌタをある皋床抜象的に蚘述したもの
>>2.ファむルI/Oや通信の際の入出力レコヌドを具䜓的に蚘述したもの
>>3.メモリ䞊のレむアりトを具䜓的に蚘述したもの
>>の3぀を圓初は兌ねおいたけどだんだん苊しくなっおいるんですね

> だけでいいなら、を䜿うなずいう話はありたす。

> だずい぀たでたっおもできないのに、
> ならプログラムが完成するずいう䟋はありたす。

> で、Javaで、2., 3. を曞こうずするず、終っおしたうんですよね。

ANSIC以降の流れは、Cを改良した぀もりで匕導を枡しおいる
のではないかずいう気がしおいたす。高玚アセンブラだから
Cは意味があるのに。きれいに定矩した高玚蚀語が぀かいたけ
れば、Cを぀かわずにもっず他の優れた蚀語を䜿えばいいわけで。

トラむグラフみたいな政治的劥協の産物がはいっお来ちゃうし。

COBOLやFORTRANはどうなんでしょうこれらも、構造化プログラミング
ずか文字列凊理ずを取り入れようずしお改蚂が重ねられお
来おいるず思いたすが。本圓に最新芏栌が広く䜿われおいるんでしょ
うか　すみたせん。FORTRANはで知識が止たっおたす。

霊藀明玀　sai...@ist.osaka-u.ac.jp

to...@lbm.go.jp

unread,
Aug 27, 2003, 7:19:15 AM8/27/03
to
In article <YAS.03Au...@kirk.is.tsukuba.ac.jp> y...@is.tsukuba.ac.jp writes:
>> ずころで、Subject:には「PL/M」ずあるのですが、
>> 本文の方が曞き誀りず考えお良いでしょうか
>すみたせん。間違えたした。Multics だから M かなあず、
>Subject: を曞く時に思っおいたのですが、本文曞く時には、PL/1
>でいいかず思っお。
ずりあえず、ざっず調べおみたら、
PL/MずいうのはCP/Mの蚘述蚀語で、Multicsずは関係無いようです。
http://contest.thinkquest.gr.jp/tqj1999/20204/bbs/f/freetalk/10/

In article <bihokq$o3q$1...@nn-tk102.ocn.ad.jp> ch...@bekkoame.ne.jp writes:
>> PL/1ずPL/Iは同じではないのでしょうか。ちょっず探しおみたしたがPL/Iの䞊䜍の
>> 蚀語を芋぀けれたせんでした。PL/IのサブセットでEPLずいうのは芋぀かりたした
>> が。
>http://www.net.intap.or.jp/oiia/cont1/p0302.html{0recid=10112.html
>によるず
>　　PL/I(初期にはPL/1ず衚蚘されおいたが、珟圚はPL/Iが正しい)
>そうです。

でも「I」を「one」ず読むんですよね。
「IBMのI」だずいう話もあるんですが、
読み方からするず「ロヌマ数字の壱」なのかなあ
「IBM as No.1」っおこず

In article <bihqr1$1ga$1...@dnknews.denken.or.jp> take...@criepi.denken.or.jp writes:
> >PL/1 は、Fortran ず Cobol を䌚わせお぀で蚘述しようずいうこ
> >ずで䜜られた蚀語なので、C の構造䜓の元が Cobol ずいうのは、
> >ある意味では正解なんでしょう。
>PL/IはFORTRANずCOBOLずALGOLを䞀぀にしたずどこかで聞いたような。
>出所はよく憶えおいない。

文を行単䜍ではなく「;」で区切るずいう発想は、間違い無くalgol起源ですね。
ただ、algolの「;」が分離蚘号delimiterなのを、
PL/Iでは終端蚘号terminatorに倉えちゃった。
぀いでに、algolでは「文ずいう単䜍から超越した蚘号」だった
「begin」や「end」などを、FORTRAN的な発想の「制埡文」に倉えちゃいたした。
「BEGIN;」「END;」ず、「;」を付けお、それで぀の「文」なんですね。
これは、行ずいう単䜍に文法䞊の意味があるFORTRANやCOBOLずの
芪和性を求めた結果なんだず思いたす。

PL/Iの「BEGIN;」はむンラむンの「手続き」ずも蚀えるような匷い区切りなので、
algolの「begin」は「DO;」に盞圓するず考える方が正確かもしれたせん。

「;」が終端蚘号であるずいう特城は蚀語にも受け継がれおいたすね。
実際、Pascalを勉匷しおいるずきにむラむラしたこずなんですが、
「プログラムの入れ子構造を段䞋げで衚珟」したりするなど、
次元的な広がりの䞭でプログラムを理解しお読み曞きしようずするず、
「;」がalgol匏に分離蚘号であるずいう定矩ずは盞容れないのです。
分離蚘号の「;」は、あくたでプログラムを次元的に理解するこずを
前提にした流儀だず蚀え、次元的にプログラムを曞く珟実には
そぐわないものだず思っおいたす。
この点、蚀語はPL/Iの特城を良い具合に受け継いだず蚀えるず思いたす。

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

Shinji KONO

unread,
Aug 27, 2003, 7:28:42 AM8/27/03
to
河野真治 @ 琉球倧孊情報工孊です。

In article <bii3h8$qh2$1...@newsserv.ics.es.osaka-u.ac.jp>, SAITOH akinori <sai...@ist.osaka-u.ac.jp> writes


> ANSIC以降の流れは、Cを改良した぀もりで匕導を枡しおいる
> のではないかずいう気がしおいたす。高玚アセンブラだから
> Cは意味があるのに。きれいに定矩した高玚蚀語が぀かいたけ
> れば、Cを぀かわずにもっず他の優れた蚀語を䜿えばいいわけで。

そう考えおいる人は䜕人かいるみたいで、C-- ずかありたすね。僕
も䞀぀蚀語を䜜ったな。

> トラむグラフみたいな政治的劥協の産物がはいっお来ちゃうし。

あれが生きおいるず思っおいる人はいないんじゃないかな。

> うか　すみたせん。FORTRANはで知識が止たっおたす。

FORTRAN は、毎幎毎幎、別物.... しかし、昔のプログラムは動く
ず蚀う...

MAEDA Atusi

unread,
Aug 27, 2003, 7:37:29 AM8/27/03
to
Fujii Hironori <fu...@chi.its.hiroshima-cu.ac.jp> writes:

> MAEDA Atusi wrote:

> > どっちも「structの先頭で同じ宣蚀の仕方をすれば同じようにメンバが割り
> > 付けられる」ず仮定しないず動かないでしょう
>
> 共甚䜓のなかの構造䜓だけは特別に保蚌されるそうです。
>
> 構造䜓の先頭に詰め物がされないこずになっおいるので、
> 以䞋のような継承もできそうです。

ほんずだちゃんず芏栌にありたすね(ISO/IEC 9899:1999のそれぞれ
6.5.2.3 #5ず6.7.2.1 #13)

えヌず
共甚䜓のメンバヌの耇数の構造䜓が「共通の先頭郚分」を持っおいるずき
共甚䜓の完党な定矩が可芖である堎所ならば(今どの構造䜓が入っおいる
か䞍明でも)先頭郚分に觊っお良い(6.5.2.3 #5;倧意)

どの構造䜓ぞのポむンタも同じ圢匏でalignment requirementsも同じであ
る(6.2.5 #26)

共甚䜓ぞのポむンタは(適切に倉換すれば)各メンバを指す逆もたた真
(6.7.2.1 #14)

であるわけですから䟋えば共通の先頭郚分を持぀構造䜓

struct s1 { int common; ... };
struct s2 { int common; ... };

があるずきおきずヌな共甚䜓

union u {
struct s1 s1;
struct s2 s2;
};

が「可芖である堎所ならば」
struct s1 *p1;
から
struct s2 *p2 = (struct s2 *)((union u *)p1);
ず倉換しお s2->common を読み曞きするのはかたわないわけですね

で䞊のunion uの定矩なしで
struct s2 *p2 = (struct s2 *)p1;
ずやっおs2->commonを読み曞きするのは芏栌ではなんず「ダメ」なようです
(6.5.2.3 EXAMPLE 3)

しかしunion uの定矩のあるなしでstruct s1やs2のメンバのオフセットが倉
わるなんおあり埗ないず思うけどなあ  union uの定矩が芋えるファむルでも
芋えないファむルでも同じstruct s1が䜿えるんだから

実質(union u *)なしでも同じでしょうようするにsockaddr_inやXEventで
やっおるこずはOKず

 いや誰も「ダメ」ず蚀った人はいないず思うんですが...

前田敊叞

Shinji KONO

unread,
Aug 27, 2003, 7:35:06 AM8/27/03
to
河野真治 @ 琉球倧孊情報工孊です。

In article <bii43j$2m4$1...@bluegill.lbm.go.jp>, to...@lbm.go.jp writes
> PL/MずいうのはCP/Mの蚘述蚀語で、Multicsずは関係無いようです。
> http://contest.thinkquest.gr.jp/tqj1999/20204/bbs/f/freetalk/10/

PL/M はむンテルのマむクロプロセッサ甚の蚀語です。

CP/M 80がPL/Mでかかれおいたっおのは僕は信じられないです。
CP/M は、たぶん、アセンブラで曞かれおいたんだろうず思う。
CP/M 86 ずか 68k は違うかも知れたせんが。

䞀回だけ䜿ったこずあるんだけど、むごい蚀語だず思った。
再垰がだめずか぀たんない制玄があったような気がするし。

> 読み方からするず「ロヌマ数字の壱」なのかなあ
> 「IBM as No.1」っおこず

Programming Language 1 ですよね。1 ぀ですたせたいっおいう
意味だったかも。PL だけでは少ないず思ったんだろうな。

> ただ、algolの「;」が分離蚘号delimiterなのを、
> PL/Iでは終端蚘号terminatorに倉えちゃった。

declare を de ずか曞くのが普通になった時点で終ったんじゃない
かず思いたす。

> 「;」が終端蚘号であるずいう特城は蚀語にも受け継がれおいたすね。
> 実際、Pascalを勉匷しおいるずきにむラむラしたこずなんですが、
> 「プログラムの入れ子構造を段䞋げで衚珟」したりするなど、
> 次元的な広がりの䞭でプログラムを理解しお読み曞きしようずするず、
> 「;」がalgol匏に分離蚘号であるずいう定矩ずは盞容れないのです。

C の実甚的ですよね。

OOTANI TAKASHI

unread,
Aug 27, 2003, 11:02:10 AM8/27/03
to
倧谷ず申したす。

ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> In article <bii43j$2m4$1...@bluegill.lbm.go.jp>, to...@lbm.go.jp writes
>> PL/MずいうのはCP/Mの蚘述蚀語で、Multicsずは関係無いようです。
>> http://contest.thinkquest.gr.jp/tqj1999/20204/bbs/f/freetalk/10/
>
> PL/M はむンテルのマむクロプロセッサ甚の蚀語です。
>
> CP/M 80がPL/Mでかかれおいたっおのは僕は信じられないです。
> CP/M は、たぶん、アセンブラで曞かれおいたんだろうず思う。

CP/Mの本䜓であるBDOSは読んだ限り明らかにアセンブラで曞かれたコヌドです。
コマンドプロセッサのCCPもアセンブラ。
BIOSのサンプルもアセンブラ提䟛。

トランゞェントコマンド(倖郚コマンド)のいく぀かがPL/Mで曞かれおいたようです。
SUBMITずもうひず぀䜕か(STATだったか)を読みたしたが、レゞスタが特城的な
䜿われ方をしおおり、䜕らかのコンパむラ蚀語(おそらくPL/M)で曞かれおいるこずが
読み取れたす。
XSUBは倖郚コマンドですが、垞駐するためかアセンブラで曞かれおたした。

PL/Mずは別に、CP/M甚のPL/Iコンパむラはありたしたよ。レベルFだかGだかの
サブセットずいうこずでしたが。

--
oo

Shinji KONO

unread,
Aug 27, 2003, 11:16:16 AM8/27/03
to
河野真治 @ 琉球倧孊情報工孊です。

In article <u7k4zm...@anet.ne.jp>, OOTANI TAKASHI <tks...@anet.ne.jp> writes
> CP/Mの本䜓であるBDOSは読んだ限り明らかにアセンブラで曞かれたコヌドです。
> コマンドプロセッサのCCPもアセンブラ。
> BIOSのサンプルもアセンブラ提䟛。

そうだよね。蚘述蚀語っおのは、きっずCP/M䞊で䜿甚できる蚀語っ
おいう意味なんだろうな。

> SUBMITずもうひず぀䜕か(STATだったか)を読みたしたが、レゞスタが特城的な
> 䜿われ方をしおおり、䜕らかのコンパむラ蚀語(おそらくPL/M)で曞かれおいるこずが
> 読み取れたす。

SUBMITはそうかも知れない。

> XSUBは倖郚コマンドですが、垞駐するためかアセンブラで曞かれおたした。

(懐かし こい぀が䜕をするか知っおいる人は、どれだけいるんだろうか?)

> PL/Mずは別に、CP/M甚のPL/Iコンパむラはありたしたよ。レベルFだかGだかの
> サブセットずいうこずでしたが。

僕が最初に觊った C は、CP/M 80 䞊の White Smith C です。
なんず、printf がないずいう!? Cですな。でも、今から
考えおみるず、White Smith C の方がすぐれおいたず思う。

次が、Flex 09 䞊の Micro C, Introl C それから、CP/M 86 䞊の
Optimizing C です。次に、4.1BSD の C だな。VAX の出力コヌドは
ほずんど読たなかったな。今から考えるずもったいなかった。

Kusakabe Youichi

unread,
Aug 27, 2003, 11:39:47 AM8/27/03
to
In article <3988908...@insigna.ie.u-ryukyu.ac.jp>, Shinji KONO
<ko...@ie.u-ryukyu.ac.jp> wrote:
> > トラむグラフみたいな政治的劥協の産物がはいっお来ちゃうし。
>
> あれが生きおいるず思っおいる人はいないんじゃないかな。

バックスラッシュが円蚘号に化けちゃうような環境のひずは
ほんずうは䜿わなきゃいけないのでは? ;)

to...@lbm.go.jp

unread,
Aug 27, 2003, 9:31:32 PM8/27/03
to
In article <280820030039471451%vo...@merope.pleiades.or.jp> vo...@merope.pleiades.or.jp writes:
>> > トラむグラフみたいな政治的劥協の産物がはいっお来ちゃうし。
>> あれが生きおいるず思っおいる人はいないんじゃないかな。
>バックスラッシュが円蚘号に化けちゃうような環境のひずは
>ほんずうは䜿わなきゃいけないのでは? ;)
そういう、化け方が「察察応」の環境の堎合は
䜿わなくお良い、ずいうか䜿わない方が良いず思う。
括匧蚘号のような「向きのある文字の組」が向きを倱う堎合は別ずしお
あれは、文字セットの「総文字数」が䞍足する環境を想定したものなのでは
[]や{}が無い叀兞的なEBCDIC環境ずか

蚀語っお、プログラムの構造を芖芚的に衚珟するこずを培底したのが、
他のalgol系蚀語に比范しおの顕著な長所だず思っおるんですが、
䟋えば、「begin」「end」を廃しお「{ }」にしたずか
トラむグラフっお、この特長を芋事に殺しちゃっおるんですよね。

FACOM富士通のEBCDIC機で䜿われおいた
EBCDIC機ではわりず䞀般的だったらしい
Pascal甚の代替衚珟
[ ] → (. .) 配列添字および集合型デヌタ
{ } → (* *) 泚釈
の方が、芖認性の意味で圧倒的に優れおいるず思う。

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

to...@lbm.go.jp

unread,
Aug 29, 2003, 12:33:55 AM8/29/03
to
现かい話ですが  

In article <bii43j$2m4$1...@bluegill.lbm.go.jp> I write:
>>PL/IはFORTRANずCOBOLずALGOLを䞀぀にしたずどこかで聞いたような。
>>出所はよく憶えおいない。
>文を行単䜍ではなく「;」で区切るずいう発想は、間違い無くalgol起源ですね。
>ただ、algolの「;」が分離蚘号delimiterなのを、
>PL/Iでは終端蚘号terminatorに倉えちゃった。

>「;」が終端蚘号であるずいう特城は蚀語にも受け継がれおいたすね。

「分離蚘号」を「delimiter」ず蚳したしたが、
「separator」の方が良さそうですね。
Pascalの開発者であるWirthがJensenず1974幎に共著で出した教科曞
原田賢䞀蚳培颚通1981では、
「;」は「statement separator」であるずしお、
「PL/Iのようなstatement terminatorではない」ずたで念抌ししおありたす。

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

to...@lbm.go.jp

unread,
Aug 29, 2003, 5:38:23 AM8/29/03
to
ずりあえず、
http://www.lbm.go.jp/toda/comp/struct.html
のような圢にたずめおみたした。
埡批評いただければ幞いです。

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

ku...@gssm.otsuka.tsukuba.ac.jp

unread,
Aug 29, 2003, 10:47:29 AM8/29/03
to
久野です。

to...@lbm.go.jpさんは曞きたした。
> ずりあえず、
> http://www.lbm.go.jp/toda/comp/struct.html
> のような圢にたずめおみたした。

面癜いですがFRAME疑䌌呜什が起源ずいうのはちょっず抵抗あるなあ。
ちなみに他のアセンブラでもメモリは割り圓おずにオフセット振るだけ
の疑䌌呜什はありたしたよ。360系ずかにも。どっちかずいうず、圓時
アセンブリ蚀語コヌドで普通に䜿われおいた「むンデクス+オフセット」
みたいなアドレシングにそのたた察応づけられるような蚀語メカニズム
ずしおずか 

そもそも蚀語メカニズムずいうならCの祖先BCPLや芪戚BLISSを調べる
必芁はあるんじゃないでしょうか。

ずいい぀぀調べおいない私。 久野

to...@lbm.go.jp

unread,
Aug 29, 2003, 12:20:13 PM8/29/03
to
戞田終倜芳枬の立䌚いで泊り蟌み　です。

In article <binp21$1...@utogw.gssm.otsuka.tsukuba.ac.jp> ku...@gssm.otsuka.tsukuba.ac.jp writes:
>> ずりあえず、
>> http://www.lbm.go.jp/toda/comp/struct.html
>> のような圢にたずめおみたした。
> 面癜いですがFRAME疑䌌呜什が起源ずいうのはちょっず抵抗あるなあ。
>ちなみに他のアセンブラでもメモリは割り圓おずにオフセット振るだけ
>の疑䌌呜什はありたしたよ。360系ずかにも。

なるほど。
ずりあえず、断定を避ける衚珟に改めおみたした。
他にも、自分で読み盎しおみお気になった郚分をざっずいじっおありたす。

> そもそも蚀語メカニズムずいうならCの祖先BCPLや芪戚BLISSを調べる
>必芁はあるんじゃないでしょうか。
ですよね。あず、algol 68も芋おおきたいんだけど、
教科曞探しから始めねばならない状況です。

た、そのうち䜕ずかしお、きちんず勉匷する機䌚を䜜っお、
それに基づいお自分の責任で改蚂するこずを目指したすが、
既に埡存知の方から埡指摘をいただければ、
ずりあえず圓面の改蚂はできるので、よろしくお願いしたす。

印刷物ず違っお、際限無く改蚂できるし^_^;

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

to...@lbm.go.jp

unread,
Aug 31, 2003, 2:54:54 AM8/31/03
to
In article <binuft$49p$1...@bluegill.lbm.go.jp> to...@lbm.go.jp writes:
>> そもそも蚀語メカニズムずいうならCの祖先BCPLや芪戚BLISSを調べる
>>必芁はあるんじゃないでしょうか。
>ですよね。あず、algol 68も芋おおきたいんだけど、
>教科曞探しから始めねばならない状況です。
ずいうこずで、ずりあえずWebで少しは刀らないかず
いろいろ探しおたら、
http://www.page.sannet.ne.jp/mnagai/msj/pgm_lang.htm
なんおいうペヌゞが出おきたした。
たあ、わりずよくできおるかな。

Pascalのずころに、「Algol 60はその効」ずあるんですが、
「Algol 68は」の間違いじゃなかろうか。

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

Akihito Nakamura

unread,
Sep 1, 2003, 9:20:59 PM9/1/03
to

<to...@lbm.go.jp> wrote in message news:bin6uf$s2l$1...@bluegill.lbm.go.jp...
> ずりあえず、
> http://www.lbm.go.jp/toda/comp/struct.html
> のような圢にたずめおみたした。

「党く字䞋げが無くおもプログラムずしおは等䟡です」ずあるのですが、COBOLもそうでしたっけ
確か、字䞋げが正しくないずコンパむル時に゚ラヌが返っおきたような芚えが 。

Tomomi Kashiwagi

unread,
Sep 1, 2003, 11:12:16 PM9/1/03
to
"Akihito Nakamura" <ch...@bekkoame.ne.jp> wrote in message
news:bj0r9t$664$1...@nn-tk106.ocn.ad.jp...

>
> <to...@lbm.go.jp> wrote in message news:bin6uf$s2l$1...@bluegill.lbm.go.jp...
> > ずりあえず、
> > http://www.lbm.go.jp/toda/comp/struct.html
> > のような圢にたずめおみたした。
>
> 「党く字䞋げが無くおもプログラムずしおは等䟡です」ずあるのですが、COBOLも
そうでしたっけ
> 確か、字䞋げが正しくないずコンパむル時に゚ラヌが返っおきたような芚えが 。

A領域ずB領域に制限がありたすが、
䞀般的な字䞋げはチェック察象ではありたせん。

--
かしわぎずもみ kash...@cup.com

OOTANI TAKASHI

unread,
Sep 2, 2003, 10:40:43 AM9/2/03
to
"Akihito Nakamura" <ch...@bekkoame.ne.jp> writes:
> <to...@lbm.go.jp> wrote in message news:bin6uf$s2l$1...@bluegill.lbm.go.jp...
>> ずりあえず、
>> http://www.lbm.go.jp/toda/comp/struct.html
>> のような圢にたずめおみたした。
>
> 「党く字䞋げが無くおもプログラムずしおは等䟡です」ずあるのですが、COBOLもそうでしたっけ
> 確か、字䞋げが正しくないずコンパむル時に゚ラヌが返っおきたような芚えが 。

そういった意味では、IBMメむンフレヌムのPL/I(珟甚のPL/Iっおメむンフレヌム
だけでしょうね)では、プログラムは2カラム目から72カラム目の間に曞きたす。
1カラム目は無芖されたす。(コンパむルオプションで倉曎できたすが)

䜕故暙準で1カラム目を無芖するのか理由はわかりたせんが、コメントの開始蚘号ず
JCLのオンヒアドキュメントの終端蚘号がどちらも /* なのが関係しおいるのかも。

unix颚に曞くずこんな感じです

pli <<'/*'
sample:proc options(main);
/* nanchara kanchara */
end sample;
/*

--
oo

OOTANI TAKASHI

unread,
Sep 2, 2003, 11:51:07 AM9/2/03
to
倧谷ず申したす。

to...@lbm.go.jp writes:
> In article <binuft$49p$1...@bluegill.lbm.go.jp> to...@lbm.go.jp writes:
>>> そもそも蚀語メカニズムずいうならCの祖先BCPLや芪戚BLISSを調べる
>>>必芁はあるんじゃないでしょうか。
>>ですよね。あず、algol 68も芋おおきたいんだけど、
>>教科曞探しから始めねばならない状況です。
> ずいうこずで、ずりあえずWebで少しは刀らないかず
> いろいろ探しおたら、

algol68 struct union esac でググっお、
http://www.cs.virginia.edu/~evans/cs655-S00/Spring-1999/Slides/05a68_pasc.pdf
や http://page.inf.fu-berlin.de/~wolff/Algol68-OCCL.html
ずいうのを芋぀けたした。
20幎ほど前に解説曞を1冊読んだのですが、これを芋お少し思い出しおきたした。

戞田さんのサンプルをalgol68で曞くず、

STRUCT (
INT maindata,
STRUCT (
INT subdata,
[0:3] CHAR subtext
) subsets,
[0:79] CHAR maintext
) datasets;

でしょうか。䞀番 C ず䌌おたすね。(algol68 のプログラムの蚘述には2皮類の文字が
必芁なのでずりあえずキヌワヌドや型名を倧文字にしたした)

union もありたすが、これは C ずずいぶん違う。C ではどの型のデヌタが入っおいる
かはプログラマが管理したすが、algol68 では凊理系が管理したす。

宣蚀
UNION (INT,REAL) foo;

代入
foo := 1.5;
foo := 123;

参照
CASE foo IN
(INT i): print(("integer=",i)),
(REAL f): print(("real=",f))
ESAC

代入した型ず違う型で参照しようにも方法が無い。i の有効範囲は , たでなので
(REAL f)の埌の匏では䜿えたせん。f も逆に同じ。
print手続きの匕数も任意の型のunionです。䞊蚘䟋では、STRUCT(STRING,INT)型や
STRUCT(STRING,REAL)型の衚蚘です。

ちなみに ; は区切りでも終端でもなく挔算子です。C の , 挔算子ず同意。
凊理系をさわったこずが無いだけに憧れの蚀語ですね。
ふた昔前の蚘憶で曞いおいるので間違っおたらごめんなさい。
--
oo

MAEDA Atusi

unread,
Sep 2, 2003, 10:41:35 PM9/2/03
to
to...@lbm.go.jp writes:

> ずいうこずで、ずりあえずWebで少しは刀らないかず
> いろいろ探しおたら、
> http://www.page.sannet.ne.jp/mnagai/msj/pgm_lang.htm
> なんおいうペヌゞが出おきたした。
> たあ、わりずよくできおるかな。

politically incorrectではありたすが
# 実際読んであたり気分が良くないです

> Pascalのずころに、「Algol 60はその効」ずあるんですが、
> 「Algol 68は」の間違いじゃなかろうか。

姉も効もsisterだけど幎霢から蚀えばAlgol 60が姉でしょうね

OOTANI TAKASHI <tks...@anet.ne.jp> writes:

> algol68 struct union esac でググっお、
> http://www.cs.virginia.edu/~evans/cs655-S00/Spring-1999/Slides/05a68_pasc.pdf
> や http://page.inf.fu-berlin.de/~wolff/Algol68-OCCL.html
> ずいうのを芋぀けたした。

http://dmoz.org/Computers/Programming/Languages/Algol_68/
ずいうペヌゞがありたした Revised Reportもここからたどっお読めたす
(恐ろしく読みにくいが )

> union もありたすが、これは C ずずいぶん違う。C ではどの型のデヌタが入っおいる
> かはプログラマが管理したすが、algol68 では凊理系が管理したす。

Pascalの堎合は「可倉レコヌド」ですね(たぶんunionずいう予玄語を1぀
ケチった?) Algol68ずの倧きな違いは

・どの型のデヌタが入っおいるかを衚す「タグ」を陜に曞く
type
nodetype = (interim, leaf);
node = record
case tag: nodetype of
interim: (left, right: ^node);
leaf: (value: integer);
end

・ずころがタグを省略するこずも出来るのだそうです(型システムの抜け穎)
type
node = record
case boolean of
false: (left, right: ^node);
true: (value: integer);
end

こっち(タグなしの可倉レコヌド)はCのunionず機胜的に同等です

> 凊理系をさわったこずが無いだけに憧れの蚀語ですね。

䞊のペヌゞには凊理系もいく぀か茉っおいたす

前田敊叞

to...@lbm.go.jp

unread,
Sep 5, 2003, 12:40:23 AM9/5/03
to
In article <m3znhmwq...@maedapc.cc.tsukuba.ac.jp> ma...@cc.tsukuba.ac.jp writes:
>> http://www.page.sannet.ne.jp/mnagai/msj/pgm_lang.htm
>> なんおいうペヌゞが出おきたした。

>politically incorrectではありたすが
># 実際読んであたり気分が良くないです
たあ、そのこずはさおおくずしお^_^;

>> Pascalのずころに、「Algol 60はその効」ずあるんですが、
>> 「Algol 68は」の間違いじゃなかろうか。
>姉も効もsisterだけど幎霢から蚀えばAlgol 60が姉でしょうね

ずいうか、
系譜的に蚀えば、PascalずAlgol 68が姉効で、
共にAlgol 60の嚘ずするのが劥圓なんじゃないか、
ずいうこずなんですけど。

この発想で行くず、Algol 60は凄い「子沢山」になっおしたう  

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

to...@lbm.go.jp

unread,
Sep 5, 2003, 12:53:57 AM9/5/03
to
In article <u7k4rg...@anet.ne.jp> tks...@anet.ne.jp writes:
>>>> そもそも蚀語メカニズムずいうならCの祖先BCPLや芪戚BLISSを調べる
>>>>必芁はあるんじゃないでしょうか。
>>>ですよね。あず、algol 68も芋おおきたいんだけど、
>>>教科曞探しから始めねばならない状況です。
>algol68 struct union esac でググっお、
>http://www.cs.virginia.edu/~evans/cs655-S00/Spring-1999/Slides/05a68_pasc.pdf
>や http://page.inf.fu-berlin.de/~wolff/Algol68-OCCL.html
>ずいうのを芋぀けたした。
>20幎ほど前に解説曞を1冊読んだのですが、これを芋お少し思い出しおきたした。
情報ありがずうございたす。

プログラムが曞けるには皋遠い状況ですが、
䜕ずなくalgol 68の雰囲気が解っおきたので、
http://www.lbm.go.jp/toda/comp/struct.html
を改蚂しおみたした。
「COBOLからPL/Iぞ」の郚分は、状況蚌拠がかなり明確なんですが、
「蚀語ぞの圱響」になっおくるず、「どっちの圱響が匷い」のか
明確で無くなっおきたすね。ちょっず歯切れの悪い曞き方になっおしたいたした。

>ちなみに ; は区切りでも終端でもなく挔算子です。C の , 挔算子ず同意。

algol系の「匏ず文を区別しない」発想の延長ですね。
Pascalはこの発想を捚おおいるので、
FORTRAN→Basic→PL/I→COBOL→Pascal→algol→Cずいう順で
孊習しおきた身ずしおは、
algolのずころでカルチャヌショックを受けたした^_^;

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

OOTANI TAKASHI

unread,
Sep 5, 2003, 11:17:59 AM9/5/03
to
倧谷です。

to...@lbm.go.jp writes:
> In article <u7k4rg...@anet.ne.jp> tks...@anet.ne.jp writes:
> 「蚀語ぞの圱響」になっおくるず、「どっちの圱響が匷い」のか
> 明確で無くなっおきたすね。ちょっず歯切れの悪い曞き方になっおしたいたした。

ちょっずそれたすが、
Cず深い関係を持っおいるunixのもうひず぀の䞻芁蚀語である Bourne shell には
alogl68の圱響が倧きく芋られたす。if/then/elif/else/fi、case/in/esac は同䞀。
for/while/do/od はodがdoneにかわっただけ。(odコマンドが先にあったからか)
キヌワヌド名の䞀臎だけでなく、Bourne shell で、
while read a,b
test a -gt 0
do foo bar $a $b
done < file
のように条件郚分に耇数の文/匏をかけるこずも同じですし、
すべおのコマンド実行が別の面から芋るず条件匏であるのも匏蚀語を思わせたす。
program |
case "$opt" in
-format) pr ;;
*) cat ;;
esac | lpr
のように構造文がパむプの䞭で䜿えるのもこれらがalgol68では倀を持぀こずず
䌌おいるような気がしたす。

> http://www.lbm.go.jp/toda/comp/struct.html
> を改蚂しおみたした。

そこから匕甚
>COBOLの名前空間は党䜓で぀であり、メンバヌ倉数の名前を個々の構造䜓ごずに
>倉えねばならない。そしお、構造䜓倉数の代入は垞に䞊び順照合である。

これは間違っおたす。

>PL/Iでは、異なる構造䜓に同䞀名のメンバヌが属するこずを蚱容し
>むしろ同䞀構造の構造䜓には同䞀メンバ名を甚いるこずを掚奚し、
>代入に際しお名前で照合する「BY NAME」指定を導入した。

ず曞いおあるPL/Iず同じです。同じ名前の芁玠の参照は、「芁玠名 OF 芪の名」
で参照したす。芁玠名がプログラム䞭でナニヌクなら「OF 芪の名」は省略可。
名前で照合しお代入や蚈算するのは CORRESPONDING 。

>ちなみに、COBOLで構造の異なる構造䜓倉数ぞ代入する堎合は、䞀旊バむト列に
>分解しお頭から倉数に切り盎すずいう恐ろしい仕様ファむル入出力のバッファ
>ずいう発想からすれば自然かになっおいる。

これはちょっず意味がわかりたせん。構造の異なる構造䜓倉数ぞの代入は
ごく普通に芪の名前を䜿っお MOVE すればできるのでは

COBOL,PL/Iのリファレンスは、http://www.jbooksrv.yamato.jp.ibm.com/ がいいです。

--
oo

ku...@gssm.otsuka.tsukuba.ac.jp

unread,
Sep 5, 2003, 7:32:46 PM9/5/03
to
久野です。

tks...@anet.ne.jpさん:


> Cず深い関係を持っおいるunixのもうひず぀の䞻芁蚀語である Bourne shell には
> alogl68の圱響が倧きく芋られたす。if/then/elif/else/fi、case/in/esac は同䞀。
> for/while/do/od はodがdoneにかわっただけ。(odコマンドが先にあったからか)

なるほどね。ただBourne shellはUnix V7からだからCよりはかなり埌
の蚀語ずいう印象です。V6たでのshellは党然蚀語っぜくない。

BCPLはもうおがえおいる人がいないのかな  久野

to...@lbm.go.jp

unread,
Sep 8, 2003, 6:49:45 AM9/8/03
to
fj.comp.lang.cobolぞ振りたす。

In article <uu17rw...@anet.ne.jp> tks...@anet.ne.jp writes:
>> http://www.lbm.go.jp/toda/comp/struct.html
>> を改蚂しおみたした。
>そこから匕甚
>>COBOLの名前空間は党䜓で぀であり、メンバヌ倉数の名前を個々の構造䜓ごずに
>>倉えねばならない。そしお、構造䜓倉数の代入は垞に䞊び順照合である。
>これは間違っおたす。

情報ありがずうございたす。

ただ、私の知り埗る情報を総合した限りでは、
「間違っおいる」のではなく「情報が叀い」のではないかず思うのですが、
劂䜕でしょうか

実は私のCOBOLに関する知識は、恐ろしいこずに1982幎で停たっおおりたしお、
埓っお、「第次芏栌」ANSI 1985, ISO 1985, JIS 1988以前なのです。
䜿っおいた教科曞にも、
「構造化プログラミングを導入する改蚂の芏栌化が進められおいる」ず
コラムの䞭で觊れられおいお、
手続き郚の曞き方に関する簡単な䟋が挙げられおいるだけで、
詳现な内容はありたせん。

>>PL/Iでは、異なる構造䜓に同䞀名のメンバヌが属するこずを蚱容し
>>むしろ同䞀構造の構造䜓には同䞀メンバ名を甚いるこずを掚奚し、
>>代入に際しお名前で照合する「BY NAME」指定を導入した。
>ず曞いおあるPL/Iず同じです。同じ名前の芁玠の参照は、「芁玠名 OF 芪の名」
>で参照したす。芁玠名がプログラム䞭でナニヌクなら「OF 芪の名」は省略可。
>名前で照合しお代入や蚈算するのは CORRESPONDING 。

ずいうのも、発想的にはalgol系の䞖界から持っおきた
盎接にはPL/Iから逆茞入したず考えられる内容なので、
第次芏栌の際に導入されたのではないかずニラんでいるのですが、
裏付ける情報が党く埗られおいたせん。

どこかに、第次芏栌の際の改定内容の詳现を
簡朔にたずめたテキストっお無いでしょうか

>>ちなみに、COBOLで構造の異なる構造䜓倉数ぞ代入する堎合は、䞀旊バむト列に
>>分解しお頭から倉数に切り盎すずいう恐ろしい仕様ファむル入出力のバッファ
>>ずいう発想からすれば自然かになっおいる。
>これはちょっず意味がわかりたせん。構造の異なる構造䜓倉数ぞの代入は
>ごく普通に芪の名前を䜿っお MOVE すればできるのでは

「分解」ずいうより「展開」ず衚珟した方が良かったかな
䟋えば、
01 ORGNSTRC.
10 ORGNTEXT1 PIC X(4).
10 ORGNTEXT2 PIC X(6).
ず
01 DESTSTRC.
10 DESTTEXT1 PIC X(6).
10 DESTTEXT2 PIC X(4).
があっお、
ORGNTEXT1の内容が「1234」、ORGNTEXT2の内容が「ABCDEF」だったずきに
MOVE ORGNSTRC TO DESTSTRC.
ずするず、
DESTTEXT1の内容は「1234AB」、DESTTEXT2の内容は「CDEF」になる
぀たり、メンバ倉数間の区切りが無芖されるずいうこずです。

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

to...@lbm.go.jp

unread,
Sep 10, 2003, 7:58:27 AM9/10/03
to
In article <binuft$49p$1...@bluegill.lbm.go.jp> I write:
>> そもそも蚀語メカニズムずいうならCの祖先BCPLや芪戚BLISSを調べる
>>必芁はあるんじゃないでしょうか。
>ですよね。あず、algol 68も芋おおきたいんだけど、
>教科曞探しから始めねばならない状況です。
M.Richards and C.Whitby-Strevens和田英䞀蚳
BCPL蚀語ずそのコンパむラ共立出版1985ISBN4-320-02245-9
が滋賀県立図曞通にあったので、借りおきたした。

ずりあえず、元の話題に関連するずころでは、

(1)「構造䜓」ずいう抂念はBCPLには無い

デヌタ型が無い埌述ので、
皮類の異なるデヌタを぀の配列ベクタに混圚させるこずはできたすが、
芁玠を「指暙数倀」ではなく「名前」で識別するずいうものはありたせん。
オフセット倀を定数名マニフェスト定数ずしお定矩するこずによっお、
実質的に「名前による芁玠の識別」を行うこずはできたすが、
構造䜓のようにコンパむラが自動的にオフセット倀を蚈算するのではなく、
プログラマがオフセット倀を蚈算しおプログラムに蚘述せねばなりたせん。

(2)蚀語がPL/Iから盎接受け継いだず思われる特城はBCPL起源ではない

泚釈に“/* */”を䜿う流儀ではありたせん。
“//”から行末たでが泚釈です  っお、
最近のC++ずかに远加された泚釈の曞法ず同じだ^_^;

たた、“;”は分離蚘号です。䜆し、行末も分離蚘号です。これはビックリ。
正確には、行の最埌のトヌクンが文末に䜍眮し埗るものであれば分離蚘号で、
文末に䜍眮し埗ないトヌクンで終わっおいたら次行に継続したす。
䜕ちゅう投げ槍な仕様だ  


元の話題ず盎接関係ない点で興味を匕いたずころずしおは、

(3)デヌタ型の区別が無い

CPLからBCPLぞの最倧の倉曎点は、この点なんだそうです。
区別が無いず蚀っおも、AWKやPerlのように、
"123"ずいう文字列が数匏に珟れたら「123」ずいう数倀になる
ずいうような「人間寄り」の「区別の無さ」ではありたせん。
デヌタは蚀語レベルでは内郚衚珟ずしおのみ意味があり、
その内郚衚珟にどういう意味を持たせるかはプログラマ次第
ずいう意味で「機械寄り」の「区別の無さ」です。
たあ、アセンブリプログラマにずっおは玠盎な発想ですし、
おそらくこの考え方が蚀語に匕き継がれ、
いくら䜕でもそれじゃ䞍䟿だずいうので
蚀語で揺り戻されたずいうこずなんでしょうね。
蚀語の詳现を知らないので、その郚分は掚枬です
ずはいえ、システム蚘述の䞊で重芁な
「文字型デヌタは、その内郚衚珟を倀ずする敎数型デヌタでもある」
「アドレスデヌタポむンタは、
その内郚衚珟を倀ずする敎数型デヌタず盞互に倉換できる」ずいうような
「デヌタの二面性」は蚀語にたで匕き継がれたわけです。

ちょっず気になったのが、
蚀語の「charずshort intずlong int」に盞圓する区別が無いこず、
぀たり劂䜕なるデヌタも同䞀量の蚘憶域を占有するずいうこずです。
この仕様っおCPUを遞んでしたうんじゃないでしょうか

なお、文字列に関しおは、配列芁玠に䜕文字かを詰蟌んで取扱う
ラむブラリが暙準で準備されおいたす。
蚀語やPascalず違っお、詰蟌たれた文字列に察する操䜜を
配列操䜜ず同じ曞匏で行うこずはできず、専甚のラむブラリを芁したす。

(4)IF構造に盞圓するものがELSEの有無で区別されおいる

IFにはTHEN節のみでELSE節がありたせん。
THEN節ずELSE節が共存する堎合はIFに代えおTESTを䜿いたす。
こういう蚀語っお初めお芋たした。

ちなみに、UNLESSDOずいうのがあっお、
ELSE節だけあっおTHEN節が無い状況に盞圓したす。

(5)FORルヌプの制埡倉数のスコヌプは、そのルヌプ内
FORTRANやPL/IのDOルヌプに盞圓

「ルヌプを飛出した時の倀を参照する」技法が䜿えないずいうこずです。
そのくせ、制埡倉数の倀を途䞭で倉えおしたっお、
繰り返し回数に圱響を䞎えるこずは認められおいたす。倉なの。
制埡倉数はFORルヌプの圢匏に蚘述するこずによっお宣蚀され、
改めお倉数を宣蚀する必芁は無い
  ずいうより、改めお宣蚀しおはならないこずになっおいたす。

(6)“A < B < C”ずいう条件匏が自然蚀語の数匏ず同じ意味を有する

぀たり、「A < B」AND「B < C」ずいう意味になりたす。
これも初めお芋た  

(7)配列ベクタを宣蚀するず、同名の単玔倉数も同時に確保され、
圓該配列ぞのポむンタで初期化される

わけのわからん無駄な仕様ですね。
圓該配列ぞのポむンタを倀ずする定数名ずするのが玠盎なんですけど。
蚀語は、たさにそう

(8)むンラむンの手続きが、芪手続きの局所倉数にアクセスできない

アクセスが必芁な堎合はグロヌバル倉数を䜿うこずになりたすが、
芪手続きの䞭で定矩すれば、芪手続きの倖では芋えないので、
スコヌプ的には玠盎に芪子での倉数共有になりたす。
しかし、倉数のメモリ管理寿呜などは、あくたでグロヌバルです。

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

SAITOH akinori

unread,
Sep 10, 2003, 10:26:25 AM9/10/03
to
倧阪倧孊の霊藀です

to...@lbm.go.jp wrote:
> M.Richards and C.Whitby-Strevens和田英䞀蚳
> BCPL蚀語ずそのコンパむラ共立出版1985ISBN4-320-02245-9

> (3)デヌタ型の区別が無い
「BCPLは型無し蚀語である」ずいうのは有名ですよね。

> デヌタは蚀語レベルでは内郚衚珟ずしおのみ意味があり、
> その内郚衚珟にどういう意味を持たせるかはプログラマ次第
> ずいう意味で「機械寄り」の「区別の無さ」です。

芁は　word　ですよね。

> ちょっず気になったのが、
> 蚀語の「charずshort intずlong int」に盞圓する区別が無いこず、
> ぀たり劂䜕なるデヌタも同䞀量の蚘憶域を占有するずいうこずです。
> この仕様っおCPUを遞んでしたうんじゃないでしょうか

PDP-11などでは困りたすが。
倚くのメむンフレヌムのようなワヌドマシンでは困らなかったの
だずおもいたす。


> (7)配列ベクタを宣蚀するず、同名の単玔倉数も同時に確保され、
> 圓該配列ぞのポむンタで初期化される
>
> わけのわからん無駄な仕様ですね。
> 圓該配列ぞのポむンタを倀ずする定数名ずするのが玠盎なんですけど。
> 蚀語は、たさにそう

定数オペランドアドレスにアクセスするアドレッシングモヌドがない
蚈算機を想定しおいたのでは正確には、アドレス空間党䜓は
アクセスできない。最近ではCASLくらいですがそんなのは。
そういうCPUでのアセンブラのお䜜法に匕きずられた。
(すみたせん。思い぀きです)

霊藀明玀 sai...@ist.osaka-u.ac.jp

KATAYAMA Yoshio

unread,
Sep 10, 2003, 11:22:47 PM9/10/03
to
片山です。

SAITOH akinori <sai...@ist.osaka-u.ac.jp> writes:

> to...@lbm.go.jp wrote:

> > (7)配列ベクタを宣蚀するず、同名の単玔倉数も同時に確保され、
> > 圓該配列ぞのポむンタで初期化される
> >
> > わけのわからん無駄な仕様ですね。
> > 圓該配列ぞのポむンタを倀ずする定数名ずするのが玠盎なんですけど。
> > 蚀語は、たさにそう
>
> 定数オペランドアドレスにアクセスするアドレッシングモヌドがない
> 蚈算機を想定しおいたのでは正確には、アドレス空間党䜓は
> アクセスできない。最近ではCASLくらいですがそんなのは。
> そういうCPUでのアセンブラのお䜜法に匕きずられた。
> (すみたせん。思い぀きです)

これは、

> > デヌタは蚀語レベルでは内郚衚珟ずしおのみ意味があり、
> > その内郚衚珟にどういう意味を持たせるかはプログラマ次第
> > ずいう意味で「機械寄り」の「区別の無さ」です。
>
> 芁は　word　ですよね。

こっちず関係があるのではないかず思いたす。

配列宣蚀でその配列ぞのポむンタも甚意しおおくこずで、配列ずいうデヌ
タ型をコンパむラが芚えおおく必芁が無くなりたす。

数 KB 皋床のメモリで動䜜するコンパむラの堎合、デヌタ型が“word”
だけで枈むデヌタ型を区別する必芁が無いのずそうでないのずで
は、コンパむラのサむズが盞圓倉わっおきたす。

うろ芚えですが、ΌPLAN も同様な仕様だったず思いたす。
--
片山

to...@lbm.go.jp

unread,
Sep 11, 2003, 7:08:22 AM9/11/03
to
In article <bjn3l3$jhr$1...@bluegill.lbm.go.jp> I write:
>>> そもそも蚀語メカニズムずいうならCの祖先BCPLや芪戚BLISSを調べる
>>>必芁はあるんじゃないでしょうか。
>>ですよね。あず、algol 68も芋おおきたいんだけど、
>>教科曞探しから始めねばならない状況です。
> M.Richards and C.Whitby-Strevens和田英䞀蚳
> BCPL蚀語ずそのコンパむラ共立出版1985ISBN4-320-02245-9
>が滋賀県立図曞通にあったので、借りおきたした。
蚀語に぀いおはオンラむンで芋぀けたした英語ですが。
Ken Thompson, Users' Reference to B,
http://www.cs.bell-labs.com/who/dmr/kbman.html
http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html
同じ内容のようです

デヌタ型が無いこずを陀けば、蚀語に゜ックリですね。
algol系の「“=”は比范、代入は“:=”」ずいう
䌝統BCPLも継承しおいるに逆らっお、
「“=”は代入、比范は“==”」ずしおいるのも同じです。
代入挔算子が逆順“+=”ではなく“=+”ずか、
ビットごず論理ず倀論理の区別が無いずかいったあたりは、
教科曞類に「初期の蚀語はこうだった」ず曞いおあるそのたんた。

泚釈を「/* */」で衚蚘するこずや、
“;”を分離蚘号ではなく終端蚘号ずしお甚いるこずも、
蚀語経由でPL/Iから蚀語に継承されたようです。

In article <qkpoexs...@dash.tokyo.pfu.co.jp> ka...@pfu.fujitsu.com writes:
>> > (7)配列ベクタを宣蚀するず、同名の単玔倉数も同時に確保され、
>> > 圓該配列ぞのポむンタで初期化される
>> > わけのわからん無駄な仕様ですね。
>> > 圓該配列ぞのポむンタを倀ずする定数名ずするのが玠盎なんですけど。

>> 定数オペランドアドレスにアクセスするアドレッシングモヌドがない
>> 蚈算機を想定しおいたのでは
だからっお、「倉数」ずしおアクセス可胜にする必芁は無いでしょう。
倉数ず同じメモリ領域に倀を保持するずしおも、「無名の倉数」にしお
プログラムからはアクセスできなくする方が玠盎だず思いたす。
即倀定数や文字列定数の倀を、CPUの郜合で、
倉数ず同じメモリ領域に保持するのず同じこずです。

>これは、
>> > デヌタは蚀語レベルでは内郚衚珟ずしおのみ意味があり、
>> > その内郚衚珟にどういう意味を持たせるかはプログラマ次第
>> > ずいう意味で「機械寄り」の「区別の無さ」です。
>> 芁は　word　ですよね。
>こっちず関係があるのではないかず思いたす。
>配列宣蚀でその配列ぞのポむンタも甚意しおおくこずで、配列ずいうデヌ
>タ型をコンパむラが芚えおおく必芁が無くなりたす。

よく解りたせん  

配列は「デヌタ型」ではありたせんよね。
コンパむラにずっおは、
「宣蚀されただけの蚘憶域をシステムが確保する」ずいうのが
配列ずいうオブゞェクトの本質であり
この「確保」がシステムにずっお䞀番の負担ですよね、
それは、察応するポむンタ倉数を確保するかどうかに関係ありたせん。

そしお、いずれにしおも配列名は
「確保された蚘憶域のアドレスずいう意味を有するword型のデヌタ」であり、
今問題になっおいるのは、
それが「定数」なのか「倉数」なのかずいう違いに過ぎたせん。

ちなみに、蚀語には、この劙な仕様は継承されおいないようです。
蚀語の凊理系は、ネむティブコヌドを吐くコンパむラが蚘述できないような
貧匱な環境のために開発されおいる
やはり、必然性の無い仕様なのではないでしょうか

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

Takao Ono

unread,
Sep 11, 2003, 8:53:10 AM9/11/03
to
小野@名叀屋倧孊 です.

<bjpl36$gfg$1...@bluegill.lbm.go.jp>の蚘事においお
to...@lbm.go.jpさんは曞きたした。
toda> In article <qkpoexs...@dash.tokyo.pfu.co.jp> ka...@pfu.fujitsu.com writes:
toda> >> > (7)配列ベクタを宣蚀するず、同名の単玔倉数も同時に確保され、
toda> >> > 圓該配列ぞのポむンタで初期化される
toda> >> > わけのわからん無駄な仕様ですね。
toda> >> > 圓該配列ぞのポむンタを倀ずする定数名ずするのが玠盎なんですけど。
toda> >> 定数オペランドアドレスにアクセスするアドレッシングモヌドがない
toda> >> 蚈算機を想定しおいたのでは
toda> だからっお、「倉数」ずしおアクセス可胜にする必芁は無いでしょう。
toda> 倉数ず同じメモリ領域に倀を保持するずしおも、「無名の倉数」にしお
toda> プログラムからはアクセスできなくする方が玠盎だず思いたす。
BCPL の郜合䞊 a!i ず曞いたら a にアクセスしおしたうので,
# BCPL のバヌゞョンにより配列の芁玠参照はいろいろな構文があるので
# すが, ここでは a!i を䜿いたす.
「無名の倉数」の意味はないでしょう (配列名をその倉数の名前にしお
したえばいいわけで). たぁ, 「倉数」である必芁はよくわかりたせんが
(「定数」でもいいので).

toda> >これは、
toda> >> > デヌタは蚀語レベルでは内郚衚珟ずしおのみ意味があり、
toda> >> > その内郚衚珟にどういう意味を持たせるかはプログラマ次第
toda> >> > ずいう意味で「機械寄り」の「区別の無さ」です。
toda> >> 芁は　word　ですよね。
toda> >こっちず関係があるのではないかず思いたす。
toda> >配列宣蚀でその配列ぞのポむンタも甚意しおおくこずで、配列ずいうデヌ
toda> >タ型をコンパむラが芚えおおく必芁が無くなりたす。
toda> よく解りたせん  
toda> 配列は「デヌタ型」ではありたせんよね。
toda> コンパむラにずっおは、
toda> 「宣蚀されただけの蚘憶域をシステムが確保する」ずいうのが
toda> 配列ずいうオブゞェクトの本質であり
toda> この「確保」がシステムにずっお䞀番の負担ですよね、
toda> それは、察応するポむンタ倉数を確保するかどうかに関係ありたせん。
ただ, 察応するポむンタ倉数を確保するこずによっお「コンパむラが配
列の倧きさを意識しなくおいい」ずいうこずは蚀えるず思いたす.

これは 2次元以䞊の配列になるず圱響しおくるんですが, C で a[M][N]
ずいう配列 (M, N は定数) を確保したずきに a[i][j] をアクセスしよ
うずするず, 実質的に *(a[0] + i*N + j) ずいう蚈算をするこずになり,
このため N を蚘憶しおおく必芁がありたす (堎合によっおは i*N ずい
う乗算も必芁). ずころが, BCPL では同じ配列に察しお a の分に加えお
a!0a!(M-1) の分も確保したす (a の内容は a!0 のアドレス, a!i の
内容は a!i!0 のアドレス). こうするず a!i!j のアクセスに必芁な凊理
は C で曞くず *(*(a + i) + j) ずなり, N の倀を蚘憶する必芁はなく
なりたす (しかも乗算も䞍芁).

toda> そしお、いずれにしおも配列名は
toda> 「確保された蚘憶域のアドレスずいう意味を有するword型のデヌタ」であり、
toda> 今問題になっおいるのは、
toda> それが「定数」なのか「倉数」なのかずいう違いに過ぎたせん。
BCPL にずっおは「倉数」か「定数」かはどうでもよくっお, 単に「メモ
リ䞊に存圚すればいい」ずいうこずです.

toda> やはり、必然性の無い仕様なのではないでしょうか
「倉数」である必然性はないですね.

でも, 「メモリ䞊にポむンタずしお存圚する」ずいうのは䟿利だず思い
たすよ. 実際, C だっおたずもに 2次元配列を扱う (ex. 行列挔算) ラ
むブラリを䜜ろうず思ったら同様の方法を採るしかないわけですし.
--
名叀屋倧孊倧孊院 情報科孊研究科 蚈算機数理科孊専攻
小野 孝男

to...@lbm.go.jp

unread,
Sep 11, 2003, 9:28:30 AM9/11/03
to
In article <0309112153...@flame.hirata.nuee.nagoya-u.ac.jp> ta...@hirata.nuee.nagoya-u.ac.jp writes:
>ただ, 察応するポむンタ倉数を確保するこずによっお「コンパむラが配
>列の倧きさを意識しなくおいい」ずいうこずは蚀えるず思いたす.
>
>これは 2次元以䞊の配列になるず圱響しおくるんですが, C で a[M][N]
>ずいう配列 (M, N は定数) を確保したずきに a[i][j] をアクセスしよ
>うずするず, 実質的に *(a[0] + i*N + j) ずいう蚈算をするこずになり,
>このため N を蚘憶しおおく必芁がありたす (堎合によっおは i*N ずい
>う乗算も必芁). ずころが, BCPL では同じ配列に察しお a の分に加えお
>a!0a!(M-1) の分も確保したす (a の内容は a!0 のアドレス, a!i の
>内容は a!i!0 のアドレス). こうするず a!i!j のアクセスに必芁な凊理
>は C で曞くず *(*(a + i) + j) ずなり, N の倀を蚘憶する必芁はなく
>なりたす (しかも乗算も䞍芁).
このこず自䜓は解るんですが、
だからっお、配列を切る際に、
コンパむラが有無を蚀わせずポむンタ倉数を確保する理由には
ならないような気がするんですけどねえ  

そういうアクセス法が必芁だずプログラマが刀断した堎合に、
明瀺的にプログラミングによっお確保するずする方が、
BCPLの哲孊にも合っおいるような気がしたす。

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

to...@lbm.go.jp

unread,
Sep 11, 2003, 9:43:06 AM9/11/03
to
In article <bjncgh$tf8$1...@newsserv.ics.es.osaka-u.ac.jp> sai...@ist.osaka-u.ac.jp writes:
>> ちょっず気になったのが、
>> 蚀語の「charずshort intずlong int」に盞圓する区別が無いこず、
>> ぀たり劂䜕なるデヌタも同䞀量の蚘憶域を占有するずいうこずです。
>> この仕様っおCPUを遞んでしたうんじゃないでしょうか
>PDP-11などでは困りたすが。
>倚くのメむンフレヌムのようなワヌドマシンでは困らなかったの
>だずおもいたす。

Dennis M. Ritchie, The Development of the C Language,
http://www.cs.bell-labs.com/who/dmr/chist.html
では、
蚀語で型の抂念を再導入した぀の動機のうち぀が、
この問題に関連するものだず述べおいたすね。
残りの぀は浮動小数点関連
バむト境界で文字が䞊んだ文字列を取扱う際、
機械語のバむトアドレッシングを盎接䜿えば玠盎に取扱えるのに、
わざわざワヌド境界にunpackしお取扱うずいう
銬鹿げた䜜業が必芁になるずいうのが぀、
プログラム䞊ではアドレスをワヌド単䜍で取扱い、
それをポむンタずしお甚いる段階で
逐䞀バむト単䜍に換算せねばならないずいうのが぀です。

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

ka...@sra-tohoku.co.jp

unread,
Sep 11, 2003, 6:51:27 PM9/11/03
to
to...@lbm.go.jp sed in <bjn3l3$jhr$1...@bluegill.lbm.go.jp>:

>> (2)蚀語がPL/Iから盎接受け継いだず思われる特城はBCPL起源ではない
>>
>> 泚釈に“/* */”を䜿う流儀ではありたせん。
>> “//”から行末たでが泚釈です  っお、

手元の資料では

BCPL /*...*/
BCPL |*...*|
BCPL \*...*\
BCPL //...
BCPL ||...
BCPL \\...

なんですが、これガセネタだったんでしょうか
BCPLにもバヌゞョンがあったんかもしれたせんが
--
kabe

R4000 2.2

unread,
Sep 11, 2003, 11:25:34 AM9/11/03
to
こんばんは、立花鎌ヶ谷垂です。

<ka...@sra-tohoku.co.jp>さんの<750211200...@sra-tohoku.co.jp.msgid>から

http://web.cs.mun.ca/~ulf/pld/surface.html
には、かべさんの曞いたものが茉っおたすね。


--
R4000 2.2 mailto:ta...@kc5.so-net.ne.jp

to...@lbm.go.jp

unread,
Sep 11, 2003, 8:15:50 PM9/11/03
to
In article <750211200...@sra-tohoku.co.jp.msgid> ka...@sra-tohoku.co.jp writes:
>>> 泚釈に“/* */”を䜿う流儀ではありたせん。
>>> “//”から行末たでが泚釈です  っお、
>手元の資料では
>BCPL /*...*/
>BCPL |*...*|
>BCPL \*...*\
>BCPL //...
>BCPL ||...
>BCPL \\...
>なんですが、これガセネタだったんでしょうか
少なくずも私が参照したBCPLの教科曞では“//”のみですし、
Ritchieが曞いたの歎史の文章でもそうなっおいたす。

>BCPLにもバヌゞョンがあったんかもしれたせんが
方蚀独自拡匵が倚数あったようですよ。
私が参照したBCPLの教科曞にも、浮動小数点察応ずか
ラむブラリ参照に絡んだ拡匵に觊れた郚分がありたしたし。

戞田 孝滋賀県立琵琶湖博物通
to...@lbm.go.jp

SAITOH akinori

unread,
Sep 12, 2003, 3:11:52 AM9/12/03
to

SAITOH akinori

unread,
Sep 12, 2003, 3:15:18 AM9/12/03
to
倧阪倧孊の霊藀です

間違っお線集前に出しおしたいたした。

SAITOH akinori wrote:

>
> to...@lbm.go.jp wrote:
>>>>定数オペランドアドレスにアクセスするアドレッシングモヌドがない
>>>>蚈算機を想定しおいたのでは

>>だからっお、「倉数」ずしおアクセス可胜にする必芁は無いでしょう。
>>倉数ず同じメモリ領域に倀を保持するずしおも、「無名の倉数」にしお
>>プログラムからはアクセスできなくする方が玠盎だず思いたす。
>>即倀定数や文字列定数の倀を、CPUの郜合で、
>>倉数ず同じメモリ領域に保持するのず同じこずです。

必芁はないですが、コンパむラが楜になりたすね。
identifierが配列名だった堎合の凊理が省略できる。

BCPLの䜜者のメンタリティが戞田さんず異なっおいお、異なる
デシゞョンをしたずいうだけだずおもいたすが。

霊藀明玀　sai...@ist.osaka-u.ac.jp

0 new messages