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

array type in C (Re: new...)

18 views
Skip to first unread message

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

unread,
Jul 2, 1998, 3:00:00 AM7/2/98
to

久野です。

ueh...@po.ntts.co.jpさん:
> 「Cプログラム䞭に珟れるX型の配列倀は、X型を指すポむンタ倀に倉換される。
> そのポむンタ倀の実際の倀はその配列の先頭芁玠を指す。この時に配列の倀
> が倉曎されるわけではない。」

なるほど、それならいいような気がしたす。

> 以䞋を陀く状況です。
> ・sizeof挔算(配列のむンデックス蚈算のような暗黙のsizeof挔算も含む)の察象。
> ・&挔算の察象。

私は「倀」に察するsizeofや&はどのみち䞍可胜だからそういう「陀
く」は蚀うたでもないず思っおいたした。

> ただし䟋倖は関数の仮匕数宣蚀における䞀次元目の配列の宣蚀でこれ
> はいかなる意味でもポむンタず同じになりたす。

やっぱりこれが印象匷いんですよねヌ。

> そりは違いたす。そう理解すべきではないです。a自䜓は配列型です
> が、匏䞭に珟れる識別子aの参照により、(int*)ずいうポむンタ倀が
> 「生じる」のです。

だっおC蚀語で(宣蚀は別ずしお)匏䞭に珟われないaは存圚しないでしょ?

> このように理解するこずの利点は、「関数型」「関数ポむンタ型」の
> 仕組みず同様に理解できるずいうこずです。「Cテキスト䞭に珟れる
> 関数名は暗黙のうちに関数ポむンタ倀に倉換される」からこそ、

なるほど、こっちが原点なんですね。

> void func(){}
> void (*funcp)();

> の時にfuncp=funcもfuncp=&funcもfunc()もfuncp()も同様に正圓なのです。
> あ、これはANSI C/C++的な理解であっおK&Rは察象倖です:)。

> それずも、関数型ず関数ポむンタ型は同じ型ですか? ん。たあ別に
> 同じでもいいのか 。

ほヌらヌねヌ。趣味の問題かもよ。

> int * const aですか:P?

そうかも知れたせん。それに初期倀が蚭定されおる(プラス領域の確
保)だけず思っお䞍郜合がありたすか?

> そうですね。単玔に「同じ」だず思っおしたうず
> x.c:
> int a[100];
> x.h:
> extern int* a;
> なんおいうダメダメコヌドを曞いおしたう危険がありたす。

この宣蚀䞊の問題は悩たしいですよね。でも䞊のは定数、䞋のは倉数
だからダメずいう説明が可胜でしょ。

> > P.S. でも同じ型ですよ :-) (どっかで聞いたようなセリフ)

> 違うっお蚀うのにぃ

型は同じでもその蚘憶領域の割り圓たり方ずかは型ずは別の問題だか
ら、型は同じだず考えるこずは別に差し支えない。ずただ考えおいたす。

次の説埗お埅ちしおたす :-) 久野

OKUDA Tetsuya

unread,
Jul 2, 1998, 3:00:00 AM7/2/98
to

おくだず申したす。

らぶらぶムヌドのずころ←り゜暪合いから申し蚳ないのですが、

ueh...@po.ntts.co.jp wrote:
> In article <6ncoim$m...@utogw.gssm.otsuka.tsukuba.ac.jp> ku...@gssm.otsuka.tsukuba.ac.jp writes:
> > > CではX型の配列は、X型ぞのポむンタに倉換される、
> >
> > > CではX型の配列は、X型ぞのポむンタに倉換されるがために
> > > 䞡者はいく぀かの状況で同等に扱うこずができる。
> >
> > そもそも「X型の配列」を「倉換する」ず蚀うず、配列の䞭の倀たで
> > 操䜜されるかのような印象がありたせんですか? たた、「いく぀かの状
>
> んじゃあ泥瞄匏にこうしたす。


>
> 「Cプログラム䞭に珟れるX型の配列倀は、X型を指すポむンタ倀に倉換される。
> そのポむンタ倀の実際の倀はその配列の先頭芁玠を指す。この時に配列の倀
> が倉曎されるわけではない。」

ポむンタ倀ず蚀われるず、どうしおもポむンタずいう「アドレスのいれもの」が
思い浮かんでしたうので、

「Cのプログラムの䞭に珟れたX型の配列倉数は、
X型の配列が栌玍されおいるメモリの先頭アドレスず解釈されたす。」

ずいうのはどうでしょうか 同様にポむンタは、

「Cのプログラムの䞭に珟れたX型ぞのポむンタは、
X型のデヌタが栌玍されおいるメモリのアドレスず解釈されたす。」

ずいうこずになりたすが・・・。

--
ねこぞう

华っおややこしくなっただけかしら。

Dairyo Gokan

unread,
Jul 2, 1998, 3:00:00 AM7/2/98
to

ueh...@po.ntts.co.jp wrote:
> そうですね。単玔に「同じ」だず思っおしたうず
>
> x.c:
> int a[100];
> x.h:
> extern int* a;
>
> なんおいうダメダメコヌドを曞いおしたう危険がありたす。
>
> > P.S. でも同じ型ですよ :-) (どっかで聞いたようなセリフ)
>
> 違うっお蚀うのにぃ

　アセンブラレベルで考えれば、同じだず思いたす。

　C蚀語のいい加枛な所は、䟋えば「char code」ずいう匕数を関数に䞎えれば、
「code」の倀のコピヌがスタックに積たれおサブルヌチンが呌ばれるのに、
「char code_buf[100]」ずずいう匕数を関数に䞎おも「code_buf[100]」の
内容のコピヌがスタックに積たれるのではなく、実際にスタックに積たれる
のは配列の先頭アドレス「(char *)&code_buf[0]」です。　そういう意味では
匕数の型を「char *code_buf」ずした堎合ず䜕等倉わりたせん。　構造䜓や
共甚䜓の堎合も同様です。

　スタックに倀を積むず関数内で匕数を倉曎しおも、倉曎されるのはスタッ
ク䞊に䞀時的に䜜成された倀のコピヌで元の実䜓は倉曎されたせんが、配列
ぞのポむンタが積たれた堎合、そのポむンタを参照しお配列の内容を倉曎する
ず、配列の内容が盎接倉曎されたす。

　そういった意味で、「 char buf[100]」ずった衚蚘は他のデヌタ型の扱いず、
䞀貫性がなく、玛らわしい衚珟なので私は䜿わないようにしおいたす。

　もっずも、䜕でもスタックに積たれるのはそれはそれで困り物です。　6502
なんお、たった256バむトしかスタック領域ないからなぁ。

　たた、以䞋のいずれの宣蚀に぀いおも、アセンブラレベル(リンカが参照する
OBJファむル内の情報)でみれば同様に扱われおしたいたす。

(1) extern int a[100];
(2) extern int a[];
(3) extern int *a;

　本来「extern int a[100];」ず宣蚀した堎合、蚀語レベルでは配列の有効な
芁玠範囲のチェックをしおくれおもよさそうですが、C蚀語ではできたせん。

　盎接「a[101]」ずいう堎合ならコンパむル時にチェック可胜でしょうが、
「a[n]」あるいは「a[x*10+y]」ずいった可倉倀によるむンデックスでは、
配列のデヌタ型を倉曎しお、デヌタ内に芁玠数を含めおおくか、プログラム
をむンタプリタにしない限り無理だず思いたす。

+---------------------------------------------------------------------+
| From : Dairyo Gokan ( 埌神 倧陵 ) |
| Organization : Studio NAND Co., Ltd. ( スタゞオ・ナンド有限䌚瀟 ) |
| Adrs : 39-6-102, Nishi-Kameari 3 Katsushika-ku Tokyo, 125-0002 JPN |
| 〒125-0002 東京郜葛食区西亀有3䞁目39番6号パヌルホワむト102 |
| TEL:03-3838-0850 FAX:03-3838-0875 mailto:na...@can.bekkoame.ne.jp |
+---------------------------------------------------------------------+

keizi kounoike

unread,
Jul 2, 1998, 3:00:00 AM7/2/98
to

鎻池ずいいたす。
ku...@gssm.otsuka.tsukuba.ac.jp wrote in message
<6nesov$c...@utogw.gssm.otsuka.tsukuba.ac.jp>...

>> > P.S. でも同じ型ですよ :-) (どっかで聞いたようなセリフ)
>
>> 違うっお蚀うのにぃ
>
> 型は同じでもその蚘憶領域の割り圓たり方ずかは型ずは別の問題だか
>ら、型は同じだず考えるこずは別に差し支えない。ずただ考えおいたす。
>
> 次の説埗お埅ちしおたす :-) 久野

勉匷䞭でお二人の蚘事を面癜く読たせお貰っおいたす。
䞊原さんの配列ずポむンタの関係の説明は蚀語関係の曞籍でも芋かけるオヌ゜
ドックスな解釈だず思いたす。久野さんはそんなこずは癟も承知で䞊のようなこず
を蚀っおおられるず思いたすが話に぀いお行くのにちょっずお尋ねしたいこずがあ
りたす。
それはここで話題に䞊がっおいる型に぀いおですが型の定矩ず型が同䞀同じ
ずは䞀䜓どういう堎合を指すのかずいうこずです。
ここが自分にずっおはっきりしないため蚘事の内容が自分の䞭で混乱しはじめお
いたす。
面倒でなければちょっず説明しお頂けたら有り難いですが。


Kazuo Fox Dohzono

unread,
Jul 2, 1998, 3:00:00 AM7/2/98
to

In article <359B14...@can.bekkoame.ne.jp>
Dairyo Gokan <na...@can.bekkoame.ne.jp> writes:

> 　たた、以䞋のいずれの宣蚀に぀いおも、アセンブラレベル(リンカが参照する
> OBJファむル内の情報)でみれば同様に扱われおしたいたす。
>
> (1) extern int a[100];
> (2) extern int a[];
> (3) extern int *a;

本圓かな.

$ cat foo.c
int a[1];
$ cat bar.c
extern int a[]; /* ! */
main ()
{
printf ("%d\n", a[0]);
}
$ cc -o a.out foo.c bar.c
$ ./a.out
0
$ cat baz.c
extern int *a; /* ! */
main ()
{
printf ("%d\n", a[0]);
}
$ cc -o a.out foo.c baz.c
$ ./a.out
Segmentation fault (core dumped)

あれれ? :-)

# 違う型だっおあれだけ指摘されおるのになあ.
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp

[12],(6,8),0,0,2
(976/11574/24211)


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

unread,
Jul 2, 1998, 3:00:00 AM7/2/98
to

久野です。

koun...@naruto-u.ac.jpさん:
> それは,ここで話題に䞊がっおいる型に぀いおですが,型の定矩ず型が
> 同䞀(同じ)ずは䞀䜓どういう堎合を指すのかずいうこずです。

はい、私は、型ずはその型に察しお斜せる操䜜の集合およびその操䜜
が行うふるたいの党䜓に識別可胜な名前(シグニチャ?)を぀けたものだ
ず考えたす。そしお今回の堎合は、int *p; のpも int a[100]; のaも
(int*)ずいう共通の名前を持ち、埓っお同䞀の型だず考えるわけです。
䞊の定矩で分かるように、私は型に぀いお考えるずき右蟺倀ずしおのふ
るたいしか考えおたせんので、それで䞊原さんずの立堎の差が珟われる
のだず思いたす。

これでよろしいですか? 久野

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

unread,
Jul 2, 1998, 3:00:00 AM7/2/98
to

久野です。

私:
> はい、私は、型ずはその型に察しお斜せる操䜜の集合およびその操䜜

「その型を持぀倀」でした。

> が行うふるたいの党䜓に識別可胜な名前(シグニチャ?)を぀けたものだ
> ず考えたす。そしお今回の堎合は、int *p; のpも int a[100]; のaも
> (int*)ずいう共通の名前を持ち、埓っお同䞀の型だず考えるわけです。
> 䞊の定矩で分かるように、私は型に぀いお考えるずき右蟺倀ずしおのふ
> るたいしか考えおたせんので、それで䞊原さんずの立堎の差が珟われる
> のだず思いたす。

どもしいたせん。 久野

keizi kounoike

unread,
Jul 2, 1998, 3:00:00 AM7/2/98
to

鎻池です。
ku...@gssm.otsuka.tsukuba.ac.jp wrote in message
<6nfioi$g...@utogw.gssm.otsuka.tsukuba.ac.jp>...

>久野です。
>
>私:
>> はい、私は、型ずはその型に察しお斜せる操䜜の集合およびその操䜜
>
> 「その型を持぀倀」でした。
>
>> が行うふるたいの党䜓に識別可胜な名前(シグニチャ?)を぀けたものだ
>> ず考えたす。そしお今回の堎合は、int *p; のpも int a[100]; のaも


どうも有り難うございたす。しかしちょっず私には内容が難しいようでどの
郚分を眮き換えたら良いのかもよく分からなかったのですが䞋のような感
じで良いのでしょうか。

「型ずはその型を持぀倀に察しお斜せる操䜜の集合およびその操䜜が行う
ふるたいの党䜓に識別可胜な名前を぀けたもの。」

でこうだずしお䟋えばint a[100] 堎合その型を持぀倀ずはaの倀のこずを
指すのでしょうか。そしお斜せる操䜜の集合ずは&aずかsizeof(a)みたいな
ものを指すのでしょうか。その操䜜が行なうふるたいの党䜓に至っおは䜕
を指すのか思いも浮かびたせん。たぶんチンプンカンプンの解釈だず思
いたすが。

せっかく説明しお頂いたのに䜕も分からなくおすいたせん。


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

unread,
Jul 2, 1998, 3:00:00 AM7/2/98
to

久野です。

koun...@naruto-u.ac.jpさん:


> どうも有り難うございたす。しかしちょっず私には内容が難しいようでどの
> 郚分を眮き換えたら良いのかもよく分からなかったのですが䞋のような感
> じで良いのでしょうか。

> 「型ずはその型を持぀倀に察しお斜せる操䜜の集合およびその操䜜が
> 行うふるたいの党䜓に識別可胜な名前を぀けたもの。」

そうですね。

> でこうだずしお䟋えばint a[100] 堎合その型を持぀倀ずはaの倀
> のこずを指すのでしょうか。

はい。「a」ずいう匏が衚す倀、ずいう方が正確でしょう。

> そしお斜せる操䜜の集合ずは&aずかsizeof(a)みたいなものを指す
> のでしょうか。

Cでは&aは蚱されおいたせん。たたsizeof(a)はaずいう匏が衚す倀に
察する挔算ではなく、aずいう名前の配列の倧きさを衚す定数ですね。

> その操䜜が行なうふるたいの党䜓に至っおは䜕を指すのか思いも浮
> かびたせん。たぶんチンプンカンプンの解釈だず思いたすが。

a[10] ずかのこずです。もちろんこれは *(a+10)ず等䟡ですから、
a+10ずかが操䜜で、その意味するもののふるたいずいうのは、a+10ずい
うのはaのアドレスよりaの指す芁玠型の倧きさ10個ぶん先の芁玠を意味
しおいたすから、その芁玠のふるたい(倉数ずしおふるたう)、ずいうこ
ずかな。結構難しいですね。

> せっかく説明しお頂いたのに䜕も分からなくおすいたせん。

いえいえ、説明がムズカシくおすいたせん 久野


Kazuo Fox Dohzono

unread,
Jul 2, 1998, 3:00:00 AM7/2/98
to

堂園です.

In article <6nfveg$i...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:

> Cでは&aは蚱されおいたせん。

蚱されない぀いでに.

久野さんの考え方だず䟋えばメモリマップドレゞスタが (reg_t *) 0x10 から
連続しおあるずしお,

((reg_t []) 0x10) [REGn]; -(a)

ずいったキャストも acceptable なのでしょうか (もちろん珟行の C では駄
目ですけど). 倚分, この堎合がちょうど

((reg_t * const) 0x10) [REGn]; -(b)

ず察応する久野さんの考え方だず思うのですが, 誀解しおいたすか? ぀たり,
通垞の配列 int a[N]; などずいうのはリンカが a を 0x10 なりなんなりの定
数に眮き換えるだけで, その実は (a) であり, (b) であるず.

もっず噛み砕いお蚀うず int *a; の持぀属性は (int *) ずいう郚分ず倉数で
あるずいう郚分ずに分けお考えるこずができお, 倉数か定数かは違うけれども
(int *) ずいう属性は等䟡であるず.

# ぀たり別蚘事で私が瀺した䟋では“倉数ず定数ずのアクセス方法の違い”を
# 瀺したに過ぎない :-)

するず今床は (reg_t []) の芁玠数を属性ずしお持぀型が思い付きたすね. 関
数匕数の二次元以降がちょうどこれに圓るかな.

--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp

[12],(6,8),0,0,2
(1003/11912/24981)


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

unread,
Jul 2, 1998, 3:00:00 AM7/2/98
to

久野です。

so...@sra.co.jpさん:
> それっお、説明になっおないず思いたす。

そうですか。

> int a[100];
> int *b;
> で、
> &a の型: (int (*)[100])
> &b の型: (int **)
> ずいう違いは、どう説明するのでしょう

えヌすいたせん。&a っお今のC蚀語で曞けるんですか。もし曞けるの
なら、私の知っおいるCから倉わっおるので、䞻匵をすべお取り消しお
修行しなおしたす。 ^_^;

> もし、久野さんず同じ説明をしおいる C 蚀語の教科曞を芋たら、決
> しお、その教科曞を人に勧めるこずはないず思いたす。(いや、そう
> いう本は、困ったこずに、結構あるんですけどね。)

もちろん、自分の考えにあった本を勧めるこずは圓然だず思いたす。

で、&aっおい぀から曞けるように??? 久野

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

unread,
Jul 2, 1998, 3:00:00 AM7/2/98
to

久野です。

doh...@hf.rim.or.jpさん:


> 久野さんの考え方だず䟋えばメモリマップドレゞスタが (reg_t *)
> 0x10 から 連続しおあるずしお,

うううう 

> ((reg_t []) 0x10) [REGn]; -(a)

> ずいったキャストも acceptable なのでしょうか (もちろん珟行の C
> では駄目ですけど). 倚分, この堎合がちょうど

Cのキャストは型ず関係なくできちゃいたすから、キャストした埌䜕
ができる、ずいうのは型システムの論拠にならないず思うんです。

> ((reg_t * const) 0x10) [REGn]; -(b)

> ず察応する久野さんの考え方だず思うのですが, 誀解しおいたすか? ぀たり,
> 通垞の配列 int a[N]; などずいうのはリンカが a を 0x10 なりなんなりの定
> 数に眮き換えるだけで, その実は (a) であり, (b) であるず.

すいたせん、んなこず考えたこずはなかったな。でも「぀たり、」以
䞋はそれでいい気がしたす。

> もっず噛み砕いお蚀うず int *a; の持぀属性は (int *) ずいう郚分ず倉数で
> あるずいう郚分ずに分けお考えるこずができお, 倉数か定数かは違うけれども
> (int *) ずいう属性は等䟡であるず.

あ、それそれ、私が思っおるのはそういうこずです。

> # ぀たり別蚘事で私が瀺した䟋では“倉数ず定数ずのアクセス方法の違い”を
> # 瀺したに過ぎない :-)

> するず今床は (reg_t []) の芁玠数を属性ずしお持぀型が思い付きたすね. 関
> 数匕数の二次元以降がちょうどこれに圓るかな.

うううう  久野

Noriyuki Soda

unread,
Jul 3, 1998, 3:00:00 AM7/3/98
to

䞊原さんの意芋に賛成です。

ku...@gssm.otsuka.tsukuba.ac.jp writes:
> > そうですね。単玔に「同じ」だず思っおしたうず
> > x.c:
> > int a[100];
> > x.h:
> > extern int* a;
> > なんおいうダメダメコヌドを曞いおしたう危険がありたす。
>

> この宣蚀䞊の問題は悩たしいですよね。でも䞊のは定数、䞋のは倉数
> だからダメずいう説明が可胜でしょ。

それっお、説明になっおないず思いたす。

> > > P.S. でも同じ型ですよ :-) (どっかで聞いたようなセリフ)
>
> > 違うっお蚀うのにぃ
>
> 型は同じでもその蚘憶領域の割り圓たり方ずかは型ずは別の問題だか
> ら、型は同じだず考えるこずは別に差し支えない。ずただ考えおいたす。

int a[100];


int *b;
で、
&a の型: (int (*)[100])
&b の型: (int **)
ずいう違いは、どう説明するのでしょう

もしも a の型が (int *) なら、&a は、圓然 (int **) になるのでは
a ず b の型の違いを理解しおいないず、C 蚀語で倚次元配列を扱う時に、
決しお正しい理解に至らないず思いたす。

もし、久野さんず同じ説明をしおいる C 蚀語の教科曞を芋たら、決しお、そ
の教科曞を人に勧めるこずはないず思いたす。(いや、そういう本は、困った
こずに、結構あるんですけどね。)

--
so...@sra.co.jp　　Software Research Associates, Inc.　曜田哲之 (Soda Noriyuki)

Dairyo Gokan

unread,
Jul 3, 1998, 3:00:00 AM7/3/98
to

Kazuo Fox Dohzono wrote:
> Dairyo Gokan <na...@can.bekkoame.ne.jp> writes:
> > 　たた、以䞋のいずれの宣蚀に぀いおも、アセンブラレベル(リンカが参照する
> > OBJファむル内の情報)でみれば同様に扱われおしたいたす。
> >
> > (1) extern int a[100];
> > (2) extern int a[];
> > (3) extern int *a;
>
> 本圓かな.
>
> << äž­ç•¥ >>
>
> あれれ? :-)
>
> # 違う型だっおあれだけ指摘されおるのになあ.

　gccが実際にどのような型コヌドを出力しおいるか芋おみないず刀断できた
せんが、おそらく「int *a」宣蚀に察しお、「a[0]」を正垞に扱えおいない
ためでしょう。 「baz.c」を以䞋のように曞き換えれば動くず思いたす。

extern int *a; /* ! */
main ()
{

printf ("%d¥n", *a);

Dairyo Gokan

unread,
Jul 3, 1998, 3:00:00 AM7/3/98
to

ku...@gssm.otsuka.tsukuba.ac.jp wrote:
> えヌすいたせん。&a っお今のC蚀語で曞けるんですか。もし曞けるの
> なら、私の知っおいるCから倉わっおるので、䞻匵をすべお取り消しお
> 修行しなおしたす。 ^_^;
> で、&aっおい぀から曞けるように??? 久野

　昔は曞けなかったのかどうか知りたせんが、DOS版の「Microsoft C」
では、倉数配列「䟋:int a[100];」に察しお「&a」ず曞くず、゚ラヌ
レベル䞊げおるず『配列に&はいらぞんけん無芖するで(かなり意蚳)』
みたいなワヌニング出したすが、゚ラヌにはなりたせん。　結果ずしお
は「&a[0]」ず同様にみなされたす。

　ポむンタ型倉数「䟋:int *b;」の倉数の栌玍アドレスを取埗するため
に「&b」ず曞くのぱラヌでもなんでもないず思いたす。

keizi kounoike

unread,
Jul 3, 1998, 3:00:00 AM7/3/98
to

鎻池です。

お手数をお掛け臎したす。
ku...@gssm.otsuka.tsukuba.ac.jp wrote in message
<6nfveg$i...@utogw.gssm.otsuka.tsukuba.ac.jp>...
>久野です。


>> 「型ずはその型を持぀倀に察しお斜せる操䜜の集合およびその操䜜が
>> 行うふるたいの党䜓に識別可胜な名前を぀けたもの。」
>
> そうですね。

>
>> そしお斜せる操䜜の集合ずは&aずかsizeof(a)みたいなものを指す
>> のでしょうか。
>
> Cでは&aは蚱されおいたせん。たたsizeof(a)はaずいう匏が衚す倀に
>察する挔算ではなく、aずいう名前の配列の倧きさを衚す定数ですね。
>


そうですか。私の䜿甚しおいるgccでは&aず&a[0]はコンパむルが通り同じ
倀を指すのでいいのかなず今たで思っおいたした。ずころでsizeofは挔算子
ではないのでしょうか。カニハンのプログラム蚀語の挔算子の䞀芧衚の
䞭にあるので今たでは挔算子ず思っおいたのですが。

>> その操䜜が行なうふるたいの党䜓に至っおは䜕を指すのか思いも浮
>> かびたせん。たぶんチンプンカンプンの解釈だず思いたすが。
>
> a[10] ずかのこずです。もちろんこれは *(a+10)ず等䟡ですから、
>a+10ずかが操䜜で、その意味するもののふるたいずいうのは、a+10ずい
>うのはaのアドレスよりaの指す芁玠型の倧きさ10個ぶん先の芁玠を意味
>しおいたすから、その芁玠のふるたい(倉数ずしおふるたう)、ずいうこ
>ずかな。結構難しいですね。
>

なんずなく分かりたした。でも型の定矩が䞊のようだずしお操䜜ずか操䜜
が行なうふるたいずかがコンパむラを通るずいう条件を぀けるのであれば
䟋えば int a[10] であれば操䜜が行うふるたいの党䜓ずはa[0]から a[9]
になるず思いたす。䞀方 *pの堎合はp[0]からp[n]たで可胜でふるたい
党䜓の倧きさが異なるこずになるず思いたす。で型の定矩から異なる型ず
いうこずになるような気がしたすけど。こういう解釈じゃないのかなぁ。
特定の芁玠数をもった配列じゃなくお配列党䜓のふるたいず比范するのか
なぁ。それなら同じような気もするけど。でも操䜜の集合でa++ずかp++
が芁玠ずしお認められるなら操䜜の集合の倧きさが異なるし。
なんかやっぱり基本が分かっおいないから難しいですね。


keizi kounoike

unread,
Jul 3, 1998, 3:00:00 AM7/3/98
to

鎻池です。
ueh...@po.ntts.co.jp wrote in message ...
>In article <6nhbbf$kvh$1...@news.naruto-u.ac.jp> "keizi kounoike"
<koun...@naruto-u.ac.jp> writes:

>
>Cの仕様では、a[-1]でもa[100]でもいっこうに構いたせん。
>(実行時゚ラヌチェッカのPurifyずか䜿っおないですよね)。
>

はい勘違いでその通りです。なんかの時配列の範囲倖を参照したずき゚ラヌ
メッセヌゞを芋たような蚘憶があったのでそう思い蟌んでいたした。
あれはじゃなくおの時だったのかな

> >こういう解釈じゃないのかなぁ。
> > 特定の芁玠数をもった配列じゃなくお配列党䜓のふるたいず比范するのか
> > なぁ。それなら同じような気もするけど。でも操䜜の集合でa++ずかp++
> > が芁玠ずしお認められるなら操䜜の集合の倧きさが異なるし。
>

>それはint *const aに察しおできないのず同じ理由からできたせん
>(ず久野さんは蚀うず思いたす)。
>
あのここはそういう意味で曞いたのではなく蚀語で芏定されおいる党おの
操䜜に察しおint a[10]ずint *pずいう型があったずしおその型に斜せる操䜜
の集合を考えた堎合a++は操䜜ずしお斜せないけどp++は操䜜ずしお斜せる
ので操䜜の集合ずしおaのも぀集合ずpのも぀集合の倧きさは違うのではず
いう意味なんですが。これもなんか倉な解釈

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

unread,
Jul 3, 1998, 3:00:00 AM7/3/98
to

久野です。

na...@can.bekkoame.ne.jpさん:


> 　昔は曞けなかったのかどうか知りたせんが、DOS版の「Microsoft C」
> では、倉数配列「䟋:int a[100];」に察しお「&a」ず曞くず、゚ラヌ
> レベル䞊げおるず『配列に&はいらぞんけん無芖するで(かなり意蚳)』
> みたいなワヌニング出したすが、゚ラヌにはなりたせん。　結果ずしお
> は「&a[0]」ず同様にみなされたす。

そりゃコンパむラがひどいよ。蚀語仕様を改倉しおるじゃん。

> 　ポむンタ型倉数「䟋:int *b;」の倉数の栌玍アドレスを取埗するため
> に「&b」ず曞くのぱラヌでもなんでもないず思いたす。

それは圓然ね 久野

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

unread,
Jul 3, 1998, 3:00:00 AM7/3/98
to

久野です。

koun...@naruto-u.ac.jpさん:


> あのここはそういう意味で曞いたのではなく蚀語で芏定されお
> いる党おの操䜜に察しおint a[10]ずint *pずいう型があったずし
> おその型に斜せる操䜜の集合を考えた堎合a++は操䜜ずしお斜せ

> ないけどp++は操䜜ずしお斜せるので操䜜の集合ずしおaのも぀集
> 合ずpのも぀集合の倧きさは違うのではずいう意味なんですが。
> これもなんか倉な解釈

で、その理由は「a」ずいう匏が定数匏だから、ずいうのが私の解釈
なんですけど。䞊原さんの蚘事にも曞きたしたが、定数かどうかずいう
のも型の䞀郚であるずお考えならそれはそれで結構なんです。逆に蚀え
ば、䜕が型かはおいずいお、aずpずいう衚蚘の違いは定数かそうでない
かの違いだけだず思うのですよね。それを私は(定数かどうかは型の䞀
郚でないず考えおいるから)「同じ型だ」ず衚珟しおおりたす。

それで&aは芏栌䞊蚱されるの? 久野

P.S. 既に曞いおいる通り、&aが芏栌䞊蚱されるのならaは定数でないか
ら匕っこみたす。

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

unread,
Jul 3, 1998, 3:00:00 AM7/3/98
to

久野です。

ueh...@po.ntts.co.jpさん:
> 久野さんの埡意芋は理解したした。結局、ある蚀語に察しお、その蚀語の意味
> 解釈、実行モデルの理解ずいうのは実は䞀通りではなく、たずえ実装がどう凊
> 理しおいようず、たずえ蚀語の蚭蚈者がどう意図しおいようず、あるいは蚀語
> 仕様がどう芏定しおいようずも(!)、ある意味自由なわけです。

ですね。しかしANSI Cの蚀語仕様では型に぀いおどういうふうに説明
しおるんですか? それも興味ありたす。

> で、やっぱり、配列ずポむンタは違う型です^^;

はいはい、結構です。

> 定数も操䜜でしょう。定数の結果を返す操䜜だず蚀っおも良いし。たたコンパ
> むル時に行われるか実行時に行われるかで区別するのもやらしいです。もっず
> 蚀えば宣蚀だっお(コンパむル時の倀前駆䜓(䜕だ?)に察する)操䜜だず蚀えたす。

定数性/倉数性(?)が型の䞀郚だずいうこずでしたら、それは別に結構
なんですっお。私は定数性/倉数性(?)ず型は盎亀しおるず思うのが自然
だず考えるわけです。だからC++のconstが嫌いずいうか 

> &に぀いおは、仮に&aができないずしたら、構造䜓に&ができるのに同様の集成
> 䜓である配列にできないのは䞍自然だしそれを理由に操䜜ではないずするのも、
> ちょっず嫌です(なぜなら「䞍可胜な操䜜」ずしお抂念的に存圚するから)。

で、蚀語仕様では&aはできるのですか、できないのですか?

> だいたいCでは配列の地䜍は䞍圓に貶められおるのですよね。
> 匕数に枡したりたるごず代入もできないし。

その通り。これはCの蚭蚈ミス(䞀芋かっこいいけど実は倱敗)だず思
いたす。そのおかげで私はこうしお皆様ず論争せねばならないし :-)

> ちなみに芏栌解釈の話では、&の察象は
>
> ANSI C仕様 3.3.3.2 Address and indirection operators
> Constraints
> The operand of the unary & operator shall be either a function designator
> or an lvalue that designates an object that is not a bit-field and is not
> declared with the register storage-class specifier.
>
> なので、非ビットフィヌルドではなくregister宣蚀されおいないオブゞェクトを
> 指定しおいるlvalueならいいのです。んでarray typeがlvalueか?ずいえば
>
> ANSI C仕様 3.2.2.1 Lvalues and function designators
> An lvalue is an expression (with an object type or an incomplete type
> other than void ) that designates an object.
>
> 配列はオブゞェクトなので(^o^)、lvalueです。
> #K&Rは知りたせん

じゃあ &a は蚀語仕様䞊蚱される、ずいうこずですね? 久野

P.S. じゃあなんでaず&aの䞡方の曞き方が蚱されるんだ? 本圓にANSI C
がこれを蚱すのなら倱敗を繕おうずしおど぀がにはたっおいるず
いう気がしたす。

Yukihiro Matsumoto

unread,
Jul 3, 1998, 3:00:00 AM7/3/98
to

た぀もず ゆきひろです

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


|久野です。

|na...@can.bekkoame.ne.jpさん:
|> 　昔は曞けなかったのかどうか知りたせんが、DOS版の「Microsoft C」
|> では、倉数配列「䟋:int a[100];」に察しお「&a」ず曞くず、゚ラヌ
|> レベル䞊げおるず『配列に&はいらぞんけん無芖するで(かなり意蚳)』
|> みたいなワヌニング出したすが、゚ラヌにはなりたせん。　結果ずしお
|> は「&a[0]」ず同様にみなされたす。
|
| そりゃコンパむラがひどいよ。蚀語仕様を改倉しおるじゃん。

うヌむ酷くないずはもうしたせんが蚘憶によればpccの頃から
そうだったような気がしたす少なくずもANSI以前にはできないC
コンパむラはなかったんじゃないかな

keizi kounoike

unread,
Jul 3, 1998, 3:00:00 AM7/3/98
to

鎻池です。
ku...@gssm.otsuka.tsukuba.ac.jp wrote in message
<6ni2v1$8...@utogw.gssm.otsuka.tsukuba.ac.jp>...
>久野です。

>
䞊原さんの蚘事にも曞きたしたが、定数かどうかずいう
>のも型の䞀郚であるずお考えならそれはそれで結構なんです。逆に蚀え
>ば、䜕が型かはおいずいお、aずpずいう衚蚘の違いは定数かそうでない
>かの違いだけだず思うのですよね。それを私は(定数かどうかは型の䞀
>郚でないず考えおいるから)「同じ型だ」ず衚珟しおおりたす。
>
> それで&aは芏栌䞊蚱されるの? 久野
>
やっず久野さんの仰りたいこずが分かりかけおきたような気がしたす。
他のずころでも盛んに”それで&aは芏栌䞊蚱されるの?” ず問いかけお
いたすがなんでそんなにこの郚分にこだわるのか党く理解できたせん
でした。蚱されおいるこずは圓然だず思っおいたしたので。
䞊原さんの蚘事の抜粋によるず

ueh...@po.ntts.co.jp wrote in message ...
>NTT゜フトりェアの䞊原です。

>ANSI C仕様 3.3.3.2 Address and indirection operators
> Constraints
> The operand of the unary & operator shall be either a function designator
> or an lvalue that designates an object that is not a bit-field and is not
> declared with the register storage-class specifier.
>

>ANSI C仕様 3.2.2.1 Lvalues and function designators


> An lvalue is an expression (with an object type or an incomplete type
> other than void ) that designates an object.
>
>配列はオブゞェクトなので(^o^)、lvalueです。

ANSI C仕様 3.2.2.1 では
巊蟺倀 lvalue はオブシェクトを指し瀺す匏 オブシェクト型又はvoid以倖の
䞍完党型を持った。である。ずいうこずになるず思いたすがint　a[10]のような
堎合のaが巊蟺倀ずいえるかどうかが問題ですがそれは䞊原さんの抜粋の䞭
だけでははっきりず断定できないからです。with an object type or an
incomplete
type other than void が明確でないからなのずこれが坂本さんの型の分類ず同
じものを指すず考えおも配列は含たれおいないような気がするからです。
以䞋は坂本さんの蚘事の抜粋です。
------------------------------------------------------------------
スカラ型:
算術型, ポむンタ型

集成䜓型:
配列䜓型, 構造䜓型 (共甚䜓型は集成䜓型ではない)

オブゞェクト型:
スカラ型, 集成䜓型, 共甚䜓型

䞍完党型:
倧きさの分からない配列型, 内容の分からない構造䜓型たたは共甚䜓型
-------------------------------------------------------------------
ですからん集成䜓型の䞭の配列䜓型っお配列型のこずなんですか。だったら
配列名は巊蟺倀になるのかな
ANSI C仕様の䞭にはっきりず配列は巊蟺倀ず曞かれおない限り&は芏栌䞊蚱され
ないこずになりたす。なくおもコンパむル可胜ずいうこずなら暗黙の了解ずいうこ
ずに
なるのでしょうか。
で本題の型なんですがいたたでのいろいろな人の蚘事を読んでわたしが思った
こずは蚀語における型ずは識別子に察する可胜な操䜜で芏定される匏挔算
子の皮類及びその操䜜の挙動を完党に決定づけるものず解釈したした。぀たり
識別子に察する操䜜に関しおは型が決たればあずは䜕も必芁ないずいうこずです。
しかし久野さんの解釈では識別子に察する操䜜に぀いおは型ずあず䜕かのものを
぀け加えないず完党に決定するこずはできないのではず思いたす。
自分が䜕かずんでもない間違った解釈をしおいないのかどうか指摘しお頂くために
長々ず勝手な解釈を曞かせお頂きたした。

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

unread,
Jul 3, 1998, 3:00:00 AM7/3/98
to

久野です。

so...@sra.co.jp
> いいえ。叀い C でも、(int (*)[100]) が必芁なこずはありたす。そ
> の堎合、&a ず曞けないコンパむラでは、(int (*)[100])a のような
> キャストが必芁でした。問題があったのは叀いコンパむラの方であり、
> ANSI C ではありたせん。

おお、なるほど、ようやく分かりたした。そのキャストは汚いですよ
ね。぀たりK&RのCは配列型ずいうのを持たせずに枈たそうずしたのです
が、1次元はいいずしおも2次元以䞊になったずたんその2次元目以降の
倧きさを保持するべき型情報がないずいう問題に遭遇するわけですね。
それでANSI Cでは配列型をきちんず扱うようになったけど、K&Rからの
互換性が必芁だから䞊原さんのおっしゃっおる汚さが生じおいるずいう
こずでしょうか。

ずいうわけで、玍埗したので匕っ蟌みたす 久野

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

unread,
Jul 3, 1998, 3:00:00 AM7/3/98
to

久野です。

koun...@naruto-u.ac.jpさん:
> やっず久野さんの仰りたいこずが,分かりかけおきたような気がした
> す。他のずころでも,盛んに"それで&aは芏栌䞊蚱されるの?" ず問い
> かけおいたすが,なんでそんなにこの郚分にこだわるのか党く理解で
> きたせんでした。(蚱されおいるこずは圓然だず思っおいたしたので。)

どうもわかりにくくおすいたせん、それで、私の立堎はこういうこず
です。

「aずいう識別子は巊蟺倀の型は(int*)、右蟺倀の型はint[size]だ」

しかも配列の堎合、配列代入ができたせんから、右蟺倀の型が問題にな
るのは&を取る時だけですよね(レコヌドの䞀郚ずしお代入が起きるこず
はありたす。それで、K&RのCは&aがありたせんから、䞊蚘の代わりに

「aずいう識別子は(int*)だ」

だけで枈みたす。こう教えられれば極めお簡朔です。&aがあるず、䞊蚘
のように長くなりたすから、&aがない方が正しいずずっず思っおいたし
た。

しかしそださんに指摘されお「2次元配列」が問題になるこずを党然
忘れおいたこずが分かりたした。1次元配列だけであれば、&aずいうの
は䞍芁ですよね。ですから&aはない方がいいし、ないべきだ ず蚀いた
かったのですが、それは*党く*間違っおいたした。どうもお隒がせしお
すいたせん。_o_

> で,本題の型なんですが,いたたでのいろいろな人の蚘事を読んで,わ
> たしが思ったこずは,C蚀語における型ずは識別子に察する可胜な操䜜
> (Cで芏定される匏,挔算子)の皮類及びその操䜜の挙動を完党に決定づ
> けるものず解釈したした。぀たり,識別子に察する操䜜に関しおは,型
> が決たればあずは䜕も必芁ないずいうこずです。しかし,久野さんの
> 解釈では,識別子に察する操䜜に぀いおは型ずあず䜕かのものを぀け
> 加えないず完党に決定するこずはできないのではず思いたす。

はい、そうです。それはですから、私が型の属性ずしお考えるのは
「識別子ぞの操䜜」でなく「倀ぞの操䜜」であり、倀のみを扱うのだか
ら「倉数かどうか」「定数かどうか」ずいう情報を萜ずしお考えおいる、
ずいうこずです。

䜕をもっお型ずするかずいう定矩は人によっお違いがあるわけで(ず
思う)、私は型ずいうのを䞊蚘のように考えおいる、ずいうこずです。
それがCの芏栌曞の定矩ず違うずいうのはそうなんでしょう。

2次元配列党然䜿わないもんで ^_^; 久野

P.S. ずころでCの芏栌ではconstずかstaticずかも型の情報の䞀郚なん
でしょうか?

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

unread,
Jul 3, 1998, 3:00:00 AM7/3/98
to

久野です。

ma...@crape.mj.imasy.or.jpさん:
> ぀たり、配列に察する「&a」ずいうのは「&a[0]」ず同様ず蚀うわけ
> ではないのだず思いたす。配列党䜓をさしたポむンタず蚀う事かず。

そうですね。にも関わらず、配列aの倀を党䜓ずしお操䜜するこずは
できない、ずいうのが気持ち悪いずころです。それで新理論 :-) ずし
お「C蚀語では配列aの巊蟺倀は&を取る時だけしか䜿われない」ずいう
のを考えたのですが 

どうでしょ :-) 久野


Iwao Watanabe

unread,
Jul 4, 1998, 3:00:00 AM7/4/98
to

uehara wrote
in article <UEHARA.98...@gate.po.ntts.co.jp>

>> |　たた、以䞋のいずれの宣蚀に぀いおも、アセンブラレベル(リンカが参照する
>> |OBJファむル内の情報)でみれば同様に扱われおしたいたす。
>> |
>> | (1) extern int a[100];
>> | (2) extern int a[];
>> | (3) extern int *a;
>>

>> 「り゜を蚀うなあヌッ」ず思いたす。
>> a単独では「ラベル」ずいう意味ではいっしょでも
>> aに察する操䜜は(3)ずそれ以倖では異りたす。

たぶん元蚘事の人がいうずころのアセンブリ レベルでも、
䞀次参照ず二次参照ずいう意味で違うでしょう。

(1),(2)はaのオフセットから盎接参照される(䞀次参照)のに察しお
(3)はaのオフセットに栌玍されおいるアドレス情報が瀺す先を
参照する(二次参照)機械語コヌドが生成されるこずになりたす。


Dairyo Gokan

unread,
Jul 4, 1998, 3:00:00 AM7/4/98
to

Iwao Watanabe wrote:
> >> | (1) extern int a[100];
> >> | (2) extern int a[];
> >> | (3) extern int *a;
>
> たぶん元蚘事の人がいうずころのアセンブリ レベルでも、
> 䞀次参照ず二次参照ずいう意味で違うでしょう。
>
> (1),(2)はaのオフセットから盎接参照される(䞀次参照)のに察しお
> (3)はaのオフセットに栌玍されおいるアドレス情報が瀺す先を
> 参照する(二次参照)機械語コヌドが生成されるこずになりたす。

　残念ながらそうはなりたせん。　䞀般にコンパむラの出力するアセンブラ
コヌド(䟋は16bit凊理系のx86の堎合)は以䞋のように同じ結果になるはず
です。

　32bitの凊理系でも「WORD」が「DWORD」に倉わるだけで基本的に倉わり
たせん。　CPUが異なっおもニヌモニックが倉わるだけで、x86系だけが
特別扱いされるようなものでもありたせん。

//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
// a.c

int a[100];

;-----------------------------------------------
; a.asm(asm source generated from a.c)

PUBLIC _a

_a WORD 100 DUP (?)

END
;-----------------------------------------------

//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
// src_1.c

extern int a[100];

a[0]=1234;

//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
// src_2.c

extern int a[];

a[0]=1234; // int型配列aの芁玠[0]に倀(1234)を代入

//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
// src_3.c

extern int *a;

*a=1234; // ポむンタaの指すint型倉数に倀(1234)を代入

　生成されるアセンブラコヌドは党お、以䞋のようになるはずです。

;-----------------------------------------------

EXTRN _a:WORD

MOV BX,OFFSET _a
MOV WORD PTR [BX],1234

END
;-----------------------------------------------

　BXレゞスタにアドレスをロヌドしおから、8086ではメモリに盎接倀を曞き
蟌む呜什がサポヌトされおいないからです。　80186以降の拡匵呜什を䜿う
ようにコンパむラオプションを指定すれば、以䞋のようなコヌドを生成可胜
ですが、䞀般にBXレゞスタ経由にしたほうが速床が速いので、速床優先の
最適化オプションを䜵甚した堎合は䜿われたせん。

MOV WORD PTR _a,1234

　もし、(3)はaのオフセットに栌玍されおいるアドレス情報が瀺す先を参照
する(二次参照)機械語コヌドが生成されるこずになるなら以䞋のようなコヌ
ドになるはずですが、実際にはそうはなりたせん。　むろん、このコヌド
自䜓は冗長ですが゚ラヌではありたせん。

;-----------------------------------------------
; indirect addressing code sample

EXTRN _a:WORD

_a_ptr WORD OFFSET _a ; _aのアドレスを栌玍した内郚倉数
; (自動生成)

MOV BX,_a_ptr
MOV WORD PTR [BX],1234

END
;-----------------------------------------------

　「int *a;」ず曞くず刀りにくいですが、「int* a;」ず曞けば理解
しやすい(意味は同じ)

Iwao Watanabe

unread,
Jul 4, 1998, 3:00:00 AM7/4/98
to

Dairyo Gokan
in article <359DB3...@can.bekkoame.ne.jp>

>>Iwao Watanabe wrote:
>> たぶん元蚘事の人がいうずころのアセンブリ レベルでも、
>>> 䞀次参照ず二次参照ずいう意味で違うでしょう。
>>>
>>> (1),(2)はaのオフセットから盎接参照される(䞀次参照)のに察しお
>>> (3)はaのオフセットに栌玍されおいるアドレス情報が瀺す先を
>>> 参照する(二次参照)機械語コヌドが生成されるこずになりたす。
>>
>>　残念ながらそうはなりたせん。　䞀般にコンパむラの出力する
>>アセンブラコヌド(䟋は16bit凊理系のx86の堎合)は
>>以䞋のように同じ結果になるはずです。

(snip)

32bitのx86のコヌドが読めるのなら、぀ぎの䟋を読み取っお䞋さい。
単玔なので、手元にgccがあるのなら 自分で詊されおみおもよいでしょう。

----- 怜蚌に䜿う゜ヌス
main()
{
extern int *a,b[];

*a = 10;
*b = 10;
}

----- コンパむル䟋 (gcc-2.7.2 on Linux Slackware)
% gcc -S foo.c

----- 生成されるアセンブリコヌド

.file "foo.c"
.version "01.01"
gcc2_compiled.:
.text
.align 16
.globl main
.type main,@function
main:
pushl %ebp
movl %esp,%ebp
movl a,%eax
movl $10,(%eax)
movl $10,b
.L1:
movl %ebp,%esp
popl %ebp
ret
.Lfe1:
.size main,.Lfe1-main
.ident "GCC: (GNU) 2.7.2"

----- ここたで

泚目すべきなのは、

movl a,%eax
movl $10,(%eax) <-- ここがポむンタaに察する凊理

movl $10,b <-- ここが配列bに察する凊理
の郚分です。

先の蚘事で私が瀺したこずが確認できたす。


Akinori Kawai

unread,
Jul 4, 1998, 3:00:00 AM7/4/98
to

河合ず申したす。

Dairyo Gokan wrote in message <359DB3...@can.bekkoame.ne.jp>...
>Iwao Watanabe wrote:
>　残念ながらそうはなりたせん。　䞀般にコンパむラの出力するアセンブラ
>コヌド(䟋は16bit凊理系のx86の堎合)は以䞋のように同じ結果になるはず
>です。


「なるはず」ずいうこずは、実際には結果を確認されおないのですね。

--------------------------------------
extern int a[];
extern int *b;

void foo ()
{
a[0]=1234;
*b=1234;
}
---------------------------------------
ずいう゜ヌスをBC++5.01でコンパむルするず、以䞋のようなコヌドになりたす。
---------------------------------------
; void foo ()
; {

; a[0]=1234;
mov dword ptr [_a],1234

; *b=1234;
mov eax,dword ptr [_b]
mov dword ptr [eax],1234

; }
ret
---------------------------------------
ずいうこずで、a[]ず*bの違いは明癜です。
*bのほうは明らかに二次参照になっおたすね。

// 河合章玀Languor kaw...@mti.biglobe.ne.jp

ueh...@po.ntts.co.jp

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to

NTT゜フトりェアの䞊原です。

In article <6niq4t$4...@utogw.gssm.otsuka.tsukuba.ac.jp> ku...@gssm.otsuka.tsukuba.ac.jp writes:
> はい、そうです。それはですから、私が型の属性ずしお考えるのは
> 「識別子ぞの操䜜」でなく「倀ぞの操䜜」であり、倀のみを扱うのだか
> ら「倉数かどうか」「定数かどうか」ずいう情報を萜ずしお考えおいる、
> ずいうこずです。

過去のCにおいおfloat型は巊蟺倀ずしおは存圚したすが右蟺倀ずしおは垞に
doubleに倉換されお凊理されおいたので、(floatに察する&がなければ)
「doubleずfloatは同じ型」でありえたのでしょうか。あるいはたた、Cにおい
おはenumは垞にintのsyntax sugarで代入互換なので「enumずintは同じ型」な
のでしょうか。

それはやっぱりちょっず違うのであっお、プログラマにずっおは「型」ずいう
抂念に぀いお、ある皋床巊蟺倀ずしおの意味も、静的な意味をも含めたものを
把握するべきなのではないでしょうか。たあstaticやconstは型には含めたく
はないですけれども。

ちなみに以䞋がANSI仕様における型の蚘述です。

ANSI C仕様 3.1.2.5 Types

The meaning of a value stored in an object or returned by a function is
determined by the type of the expression used to access it. (An identifier
declared to be an object is the simplest such expression; the type is
specified in the declaration of the identifier.) Types are partitioned into
object types (types that describe objects), function types (types that
describe functions), and incomplete types (types that describe objects but
lack information needed to determine their sizes).
...

--
§ NTTS○FT 技術開発郚゚レクトロニックコマヌス技術センタヌ 䞊原 最二 §

NAKAMURA Takahiro

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to

<xqrra03...@srapc342.sra.co.jp>の蚘事においお
so...@sra.co.jpさんは曞きたした。
>>
>> 久野さんの方法で、
>> int c[10][100];
>> の c の型、c[10] の型が、正しく説明できたすか
>> int a[100];
>> で a の型が (int *) であるなら、圓然 c[10] の型も (int *) になるわけで
>> すよね ずするず、c の型は (int **) になっおしたいたす。これはたった
>> くの誀りです。c を右蟺倀ずしお解釈した堎合の型は、(int (*)[100]) です
>> から。
>>
>> 正しくは、a の型は (int [100])、c[10] の型も (int [100])、c の型は、
>> (int [10][100]) です。埓っお c を右蟺倀ずしお解釈するず (int (*)[100])
>> ずなり、正しい答が埗られたす。
>>

䞀぀疑問に思ったのですが、

int c[10][100];

においお「c[10]の型」ずいうのは普通の考え方なのでしょうか
私は今たでc[10][100]はあくたでも「2次元の配列」ずしか
捉えられなかったのですが。

なにしろc[10][100]ず宣蚀した堎合、「c[10]ずいう配列の100個の配列」
ずいうのをメモリ䞊に確保する凊理系を芋たこずがなかったので。

--
NAKAMURA Takahiro

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

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to

久野です。

ueh...@po.ntts.co.jpさん:
> 過去のCにおいおfloat型は巊蟺倀ずしおは存圚したすが右蟺倀ずしお
> は垞にdoubleに倉換されお凊理されおいたので、(floatに察する&が
> なければ)「doubleずfloatは同じ型」でありえたのでしょうか。ある
> いはたた、Cにおいおはenumは垞にintのsyntax sugarで代入互換なの
> で「enumずintは同じ型」なのでしょうか。

そうですねえ、この倉はキタナむずころです。

䞊原さんが指摘されおたように、私は自分の勝手な :-) 蚀語モデル
にあおはめお理解しおたしたので、floatは右蟺倀はあるけれど挔算の
瞬間にdoubleに倉換される、ず理解したす。ずきに䞊原さんのその
floatに関する解釈(右蟺倀が存圚しない)は

f1 = f2;

みたいに代入挔算でもそうだずお考えですか? enumはたったくintず同
じ型だず思いたす。残念ですが。

> それはやっぱりちょっず違うのであっお、プログラマにずっおは「型」
> ずいう抂念に぀いお、ある皋床巊蟺倀ずしおの意味も、静的な意味を
> も含めたものを把握するべきなのではないでしょうか。たあstaticや
> constは型には含めたくはないですけれども。

そうか、staticやconstは含めたくないのですね。そこは䞀臎したす。:-)

巊蟺倀の型ず右蟺倀の型の双方に぀いお考える。それはそれでよいで
す。(自分の趣味じゃないですが蚀語がそうだから考えざるを埗ないで
すね。)

> ちなみに以䞋がANSI仕様における型の蚘述です。
> ANSI C仕様 3.1.2.5 Types
>
> The meaning of a value stored in an object or returned by a function is
> determined by the type of the expression used to access it. (An identifier
> declared to be an object is the simplest such expression; the type is
> specified in the declaration of the identifier.) Types are partitioned into
> object types (types that describe objects), function types (types that
> describe functions), and incomplete types (types that describe objects but
> lack information needed to determine their sizes).
> ...

これを私が読んでも「倉数そのもの」が型であるようには読めないん
ですよねヌ。たあ私の先入芳ずいうこずでしょうけど。

それで䞊原さんの以前の蚘事の内容ですが。

䞊原さん:
> 「Cプログラム䞭に珟れるX型の配列倀は、X型を指すポむンタ倀に倉
> 換される。そのポむンタ倀の実際の倀はその配列の先頭芁玠を指す。
> この時に配列の倀が倉曎されるわけではない。」

぀たり「配列倀は仮想的には存圚するが、垞に存圚した盎埌にポむン
タ倀に倉換されるから実際に具珟するこずはない」ずいうこずですね。
なんか䞊のfloatの解釈に䌌おたりしお :-)

> 以䞋を陀く状況です。
> ・sizeof挔算(配列のむンデックス蚈算のような暗黙のsizeof挔算も含む)の察象。
> ・&挔算の察象。
> ただし䟋倖は関数の仮匕数宣蚀における䞀次元目の配列の宣蚀でこれはいかな
> る意味でもポむンタず同じになりたす。

ずいうふうに考えるより、「配列名称である識別子の巊蟺倀は配列だ
が、右蟺倀は垞にポむンタ」ず考えた方が明解なように私には思えるわ
けです。もちろん、sizeofや&は配列の巊蟺倀が問題になる数少ない堎
合に盞圓したすよね。

自己流勝手解釈ですいたせんね 久野

KATAYAMA Yoshio

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to

片山です。

In article <lv3ecjw...@picachu.netlab.co.jp>,
Yukihiro Matsumoto <ma...@netlab.co.jp> writes:

>|na...@can.bekkoame.ne.jpさん:
>|> 　昔は曞けなかったのかどうか知りたせんが、DOS版の「Microsoft C」
>|> では、倉数配列「䟋:int a[100];」に察しお「&a」ず曞くず、゚ラヌ
>|> レベル䞊げおるず『配列に&はいらぞんけん無芖するで(かなり意蚳)』
>|> みたいなワヌニング出したすが、゚ラヌにはなりたせん。　結果ずしお
>|> は「&a[0]」ず同様にみなされたす。
>|
>| そりゃコンパむラがひどいよ。蚀語仕様を改倉しおるじゃん。

これは pcc の実装を、そのたた持っおきたみたいな実装ですね。

>うヌむ酷くないずはもうしたせんが蚘憶によればpccの頃から
>そうだったような気がしたす少なくずもANSI以前にはできないC
>コンパむラはなかったんじゃないかな

UNIX V7 の cc では、K&R 第1版の蚘述通り、配列に & を付けるこずは
できたせんでした。しかし、圓時から pcc では、譊告扱いで、この &
を無芖しおいたした。

 pcc は K&R の文法を誀解しおいる所が幟぀かありたしたから、、、

“int a[100];”に察しお“&a”が (int (*)[100]) 型になるようになっ
た配列に察しお & を䜿えるようになったのは ANSI C からです。

ずいうわけで、

In article <6nh5dk$n...@utogw.gssm.otsuka.tsukuba.ac.jp>,
ku...@gssm.otsuka.tsukuba.ac.jp writes:

> えヌすいたせん。&a っお今のC蚀語で曞けるんですか。もし曞けるの
>なら、私の知っおいるCから倉わっおるので、䞻匵をすべお取り消しお
>修行しなおしたす。 ^_^;

修行しなおしおください。(^_^)

こんなこずを曞いおいいのだろうか(^_^;
--
片山

ueh...@po.ntts.co.jp

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to

NTT゜フトりェアの䞊原です。

In article <6npiq0$6...@utogw.gssm.otsuka.tsukuba.ac.jp>


ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 䞊原さんが指摘されおたように、私は自分の勝手な :-) 蚀語モデル
> にあおはめお理解しおたしたので、floatは右蟺倀はあるけれど挔算の
> 瞬間にdoubleに倉換される、ず理解したす。ずきに䞊原さんのその
> floatに関する解釈(右蟺倀が存圚しない)は
>
> f1 = f2;
>
> みたいに代入挔算でもそうだずお考えですか?

K&Rずかの話なのでたったく自信はありたせんが、「f1 = f2 + f3」の堎合を
考え䞀般化するず、

> f1 = f2;

の字句通りの意味は、f2の右蟺倀がdoubleに倉換され、f1の巊蟺倀が瀺す領域
に栌玍され、その時にdouble→floatの倉換が起きるのでしょう。ただ最適化
によりビット単䜍のコピヌになる可胜性はあるのかなず。

> enumはたったくintず同じ型だず思いたす。残念ですが。

うヌん。

> そうか、staticやconstは含めたくないのですね。そこは䞀臎したす。:-)

Cではそうです。C++になるずやや意芋がぐら぀きたす。C++ではconstはメ゜ッ
ド遞択ずかで実質的に型のような働きをしたすからねえ。

> 巊蟺倀の型ず右蟺倀の型の双方に぀いお考える。それはそれでよいで
> す。(自分の趣味じゃないですが蚀語がそうだから考えざるを埗ないで
> すね。)

lispなどの動的蚀語では久野さんのおっしゃられおいるこずはピンずきたすし
たた私の趣味でもありたす。

> これを私が読んでも「倉数そのもの」が型であるようには読めないん
> ですよねヌ。たあ私の先入芳ずいうこずでしょうけど。

私も必ずしもCの「型[*1]」が倉数に察する属性だずは思わないです。しかし
「倀」だけに属するずも思いたせん。静的に型づけを行う蚀語であるCにおい
おは「型抂念」はコンパむル時の型チェックや代入性にかかわるものであり、
静的な偎面で重芁な圹割を果たしおいるはずです。それにはenumによる可読性
向䞊ずか、constなどのアクセス制埡機構も絡んでいるのではないでしょうか。
぀たり、型かそうじゃないかは、定矩はどうあれ、明確な境界線の無いうすが
んやりずしたグレヌゟヌンの䞭にあるのではないかず考えるようになりたした
(私の頭ががんやりしおるだけかもしれたせんが)。

[*1] もちろん、ここで蚀う「型」はC仕様においお定められおる型、
じゃなくお私の考える所の型の話です。念のため。

> > 「Cプログラム䞭に珟れるX型の配列倀は、X型を指すポむンタ倀に倉
> > 換される。そのポむンタ倀の実際の倀はその配列の先頭芁玠を指す。
> > この時に配列の倀が倉曎されるわけではない。」
>
> ぀たり「配列倀は仮想的には存圚するが、垞に存圚した盎埌にポむン
> タ倀に倉換されるから実際に具珟するこずはない」ずいうこずですね。
> なんか䞊のfloatの解釈に䌌おたりしお :-)

そうですね。栌䞊げずか暗黙の倉換ずいわれる正芏化機構が、Cの裏で黙々ず
動いおいたす。

> ずいうふうに考えるより、「配列名称である識別子の巊蟺倀は配列だ
> が、右蟺倀は垞にポむンタ」ず考えた方が明解なように私には思えるわ
> けです。もちろん、sizeofや&は配列の巊蟺倀が問題になる数少ない堎
> 合に盞圓したすよね。

私ずしおは、むしろ配列に正々堂々ず右蟺倀をもっお欲しいず感じたす。
配列たるごず代入/枡し/返しは今でも゚ラヌだから、それを蚱可した䞊で、

> > ただし䟋倖は関数の仮匕数宣蚀における䞀次元目の配列の宣蚀でこれはいかな
> > る意味でもポむンタず同じになりたす。

ずいう䟋倖さえ削陀し可倉長配列をきちんず実装すれば玠盎な姿になるず思う
のです。もちろん埡指摘の通り互換性の問題がありたす。぀たり、main(int,
char*[])は旧来のcrt0から呌び出せなくなり、かならずmain(int, char**)ず
曞かなければいけなくなりたす。でもそれはそれでいいじゃないですか(駄目?)。

なにしろ、「関数の仮匕数宣蚀における䞀次元目の配列の宣蚀はいかなる意味
でもポむンタず同じ」ずいう芏則はあきらかに確信犯的で、配列ずポむンタを
混同させようずしたCの蚭蚈者の意図に基づくものです。぀たりCを正しく理解
するには、蚭蚈者の意図にだたされずに本圓のこずを芋抜かなければなければ
ならない、ずいう 。(なんちゅヌ蚀語じゃ)

配列の芁玠参照挔算子「[]」も配列に察するものではなくポむンタをオペラン
ドであるずか、Cは良く考えるず実にナニヌクな蚀語ですよね。

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

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to

修行䞭の久野です。

ka...@pfu.co.jpさん:
> const は型の䞀郚型修食子ですが、static は蚘憶クラスです。

やっぱりそうなんですね。䞀般にすべおの型に぀いお察応するconst
があるず思っおよいのでしょうか。

あんたり型にいろいろ盛り蟌むのは奜きくない 久野


Nakamura Takahiro

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to

<6npj7r$6...@utogw.gssm.otsuka.tsukuba.ac.jp>の蚘事においお
ku...@gssm.otsuka.tsukuba.ac.jpさんは曞きたした。
>>
>> なんか読み返すずがろがろですね。すいたせん。
>>

いえ、私の読解力の無さによるものです。

>> naka...@video.yaita.sharp.co.jpさん:


>> > 䞀぀疑問に思ったのですが、
>> > int c[10][100];
>> > においお「c[10]の型」ずいうのは普通の考え方なのでしょうか
>>

>> 「c[10]の」ずいうのは倉でしたが、「c[i]」(i = 0..9)には型があっ
>> お、それは倧きさ100の敎数の配列だず思いたすです。
>>

あぁ、玍埗したした。私が蚘事を読み間違っおいたようです。

>>
>> > なにしろc[10][100]ず宣蚀した堎合、「c[10]ずいう配列の100個の配列」
>> > ずいうのをメモリ䞊に確保する凊理系を芋たこずがなかったので。
>>

>> 別にメモリ䞊に連続しお配眮しおるんだからいいず思うのですが、倉
>> でしょうか?
>>

ええず、c[10][100]に぀いお、「c[10]の型」ずいう蚀葉が出お来たずきに、
「c[10]ずいうオブゞェクトの100個分の配列」を考えおいるのかなず
思っおいたわけです。

でも、実際のハンドリングではどちらかずいうず「c[100]ずいうオブゞェクトの
10個分の配列」ずいうふうなハンドリングをしおいるので「あれ」ず
思った次第です。

勝手に勘違いしおいたようですみたせん。


--
NAKAMURA Takahiro

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

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to

久野です。

ueh...@po.ntts.co.jpさん:
> Cではそうです。C++になるずやや意芋がぐら぀きたす。C++ではconst
> はメ゜ッド遞択ずかで実質的に型のような働きをしたすからねえ。

メ゜ッド遞択に関䞎するのならそうですね。しかし倉数かどうかず
定数かどうかで型に含めたいかどうかが倉わるんですね。たあどっかに
線匕きしないずいけないんですけど。

> 私も必ずしもCの「型[*1]」が倉数に察する属性だずは思わないです。
> しかし「倀」だけに属するずも思いたせん。静的に型づけを行う蚀語
> であるCにおいおは「型抂念」はコンパむル時の型チェックや代入性
> にかかわるものであり、静的な偎面で重芁な圹割を果たしおいるはず
> です。

それはそうです。それをすべお「型」だず思いたいか、私みたく「型」
ずそれ以倖の属性が合わさったものだず思いたいか、の違いだず思うの
ですよね。たずえばregister属性が぀くず&が取れなくなりたすが、そ
れが型の䞀郚かず蚀われるず ずか。

> それにはenumによる可読性向䞊ずか、constなどのアクセス制埡機構
> も絡んでいるのではないでしょうか。぀たり、型かそうじゃないかは、
> 定矩はどうあれ、明確な境界線の無いうすがんやりずしたグレヌゟヌ
> ンの䞭にあるのではないかず考えるようになりたした(私の頭ががん
> やりしおるだけかもしれたせんが)。

やっぱり自分で考える堎合には明確な境界はないんだ。

> [*1] もちろん、ここで蚀う「型」はC仕様においお定められおる型、
> じゃなくお私の考える所の型の話です。念のため。

そうですね。私に぀いおいえば、自分が考えたりする蚀語がオブゞェ
クト指向だず、型は倀だけだず思いたくなるんですよ。

: ぀たり「配列倀は仮想的には存圚するが、垞に存圚した盎埌にポむン
: タ倀に倉換されるから実際に具珟するこずはない」ずいうこずですね。
: なんか䞊のfloatの解釈に䌌おたりしお :-)

> そうですね。栌䞊げずか暗黙の倉換ずいわれる正芏化機構が、Cの裏
> で黙々ず動いおいたす。

それはどっちかずいうず実行時っぜいむメヌゞですか? いえ、それは
どちらでもよいです。そういえば私が「暗黙の倉換嫌い」なのもこの件
に圱響しおるんです。

↓※
: ずいうふうに考えるより、「配列名称である識別子の巊蟺倀は配列だ


: が、右蟺倀は垞にポむンタ」ず考えた方が明解なように私には思えるわ
: けです。もちろん、sizeofや&は配列の巊蟺倀が問題になる数少ない堎
: 合に盞圓したすよね。

> 私ずしおは、むしろ配列に正々堂々ず右蟺倀をもっお欲しいず感じたす。

もちろんですよ!!! 最初にRitcheがそうしなかっためにこういう隒ぎ
(っおほどでもないですが :-)になっおるし迷惑しおる人は䞀杯いるん
だず思いたす。

> 配列たるごず代入/枡し/返しは今でも゚ラヌだから、それを蚱可した䞊で、
...


> ずいう䟋倖さえ削陀し可倉長配列をきちんず実装すれば玠盎な姿になるず思う
> のです。もちろん埡指摘の通り互換性の問題がありたす。぀たり、main(int,
> char*[])は旧来のcrt0から呌び出せなくなり、かならずmain(int, char**)ず
> 曞かなければいけなくなりたす。でもそれはそれでいいじゃないですか(駄目?)。

いえ、もちろんOKです。私はそれがANSIになったずきの正しいあり方
だったのでは、ず思っおいたすが。

> なにしろ、「関数の仮匕数宣蚀における䞀次元目の配列の宣蚀はいか
> なる意味でもポむンタず同じ」ずいう芏則はあきらかに確信犯的で、
> 配列ずポむンタを混同させようずしたCの蚭蚈者の意図に基づくもの

> です。぀たりCを正しく理解するには、蚭蚈者の意図にだたされずに
> 本圓のこずを芋抜かなければなければならない、ずいう 。(なんちゅヌ
> 蚀語じゃ)

そうそう。それで私は1次元の配列しか䜿わずそれも単なるmallocさ
れた領域の先頭であるかのようにプログラミングする習慣が぀いおるの
ですよね。その方が芋やすいんだもの たあ倚次元配列が来るず砎綻す
るのはなんずなく分かっおたした 

> 配列の芁玠参照挔算子「[]」も配列に察するものではなくポむンタを
> オペランドであるずか、Cは良く考えるず実にナニヌクな蚀語ですよね。

ですから前にも曞きたしたけど、「こうしたらかっこいいじゃん!」
ず思っおその時はそれなりによさそうだったけど、結局は倱敗だった技
術的遞択の䟋なんでしょう。

それで※はやっぱりバツでしょうか? (し぀こい) 久野


Shinji Kono

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to

河野 真治@琉球倧情報工孊です。

In article <6nq09c$8...@utogw.gssm.otsuka.tsukuba.ac.jp> ,
ku...@gssm.otsuka.tsukuba.ac.jp writes

>> 私ずしおは、むしろ配列に正々堂々ず右蟺倀をもっお欲しいず感じたす。
> もちろんですよ!!! 最初にRitcheがそうしなかっためにこういう隒ぎ
>(っおほどでもないですが :-)になっおるし迷惑しおる人は䞀杯いるん
>だず思いたす。

なるほど。右蟺倀を持たない配列を䜜りたければ、
int (const a)[100];
ずか曞けばいいわけですね。ずいうか、
int a[100];
const a;
ず分けお曞いた方がいいのかな? そうすれば、const a のない堎合は、
int a[];
int *b;
は、たったく同じになっおなかなか矎しいかも知れない。いや、これだず、
b の行き先がずられないずいう差があるか...

> それはどっちかずいうず実行時っぜいむメヌゞですか? いえ、それは
>どちらでもよいです。そういえば私が「暗黙の倉換嫌い」なのもこの件
>に圱響しおるんです。

僕は割ず奜きです。ただ、どう倉換されるかわからないずか、倀によっお
倉換されかたが違うずかいうず困るけど。

---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球倧孊工孊郚情報工孊科

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

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to

久野です。

naka...@video.yaita.sharp.co.jpさん:


> ええず、c[10][100]に぀いお、「c[10]の型」ずいう蚀葉が出お来た

> ずきに、「c[10]ずいうオブゞェクトの100個分の配列」を考えおいる
> のかなず思っおいたわけです。

なるほど、でもcは2次元配列なので、c[10]ずいうオブゞェクトは敎
数が10個の配列じゃないような たあこういうこずを蚀い出すずどうに
も終わらないのでやめおおきたしょう ^_^;

たずえばPascalだず c: array[1..10] of integer; ずかのように、
定矩される倉数偎は単独で、型を別に曞きたすよね。ずころがCの宣蚀
子は int c[10]; ですからあたかも匏の䞭に出お来るかのような曞き方
に芋えお、それでこういう議論をやるず宣蚀を曞いおいるのか参照する
匏を曞いおいるのか混乱する、ずいうのが元凶なんだず思いたす。

しかし c: (*int[])[100]; なんおのもいたいち  久野

P.S. デタラメで曞いたのですが正しい型指定になっおたす? 党然わか
らない 

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

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to

久野です。

koun...@naruto-u.ac.jpさん:
> 坂本さんから指摘を含めメヌルを頂いたので玹介させお頂きたす。

力䜜ですねヌ。

> ここの説明にあるように,はじめは巊蟺倀=代入可胜ず思っおいたした。
> ずいうのもカ-ニハンのプログラミング蚀語Cには"巊蟺倀"ずいう名前
> は,代入匏E1=E2からきおいる。ずいう説明があり,なら代入可胜ずだ
> なず考えおたした。(ややこしい名前を぀けるなず蚀いたい。)

そうですよね。私は逆に、配列には代入できないから巊蟺倀がない
(べきだ)ず思っおたした。

> ずころで,配列型は倉曎可胜な巊蟺倀ではないずありたすが,配列の芁
> 玠は倉曎可胜な巊蟺倀ず考えおよいのでしょうか。

Cの芏栌曞は分かりたせんが、䞀般の甚語はpがポむンタのずき*pは倉
曎可胜な巊蟺倀ですよね。そもそも倉曎可胜でない巊蟺倀なんお甚語は
今はじめお聞きたした。それもconstず配列ずでは事情が違いたすよね。
constは倀が倉化したせんが、配列は党䜓ずしおの代入ができないだけ
で、個々の芁玠は倉化できたすし。

>>> ぀たり識別子に察する操䜜に関しおは型が決たればあずは䜕も必芁ない
>>> ずいうこずです。しかし久野さんの解釈では識別子に察する操䜜に぀い
>>> おは型ずあず䜕かのものを぀け加えないず完党に決定するこずはできないの
>>> ではず思いたす。自分が䜕かずんでもない間違った解釈をしおいないのかど
>>> うか指摘しお頂くために長々ず勝手な解釈を曞かせお頂きたした。

だれの蚘事の匕甚か分からなくなりたしたが、ずもかく私ずしおは、
型が識別子に察するすべおの操䜜を説明する、ずいう芁望は分かりたす
けどやりすぎずいうかあたり奜きじゃないです。たあここは奜みの問題
ずいうこずで(芏栌曞の蚀う意味の型だったら私の蚀う型ずは違うずい
うのはその通りです)。

> なるほど簡単にはいかないものなんですね。ずころで䞊のi+3な
> んおのは”巊蟺倀でない->&が出来ないアドレスが取れない。->
> オブシェクトでない。”ずなりそうな気がしたすが䞊原さんのANCI
> C仕様3.1.2.5　Typesの玹介によれば型の皮類は倧きく分けるずオ
> ブゞェクト型関数型䞍完党型に分類されるようですがこの倧分
> 類のどこに入るものなんでしょうか。

私も聞きたいです。だから倀ず蚘憶域や定数は分けたいずいうか 

>> たた、識別子はオブゞェクトを衚す以倖に、関数、構造䜓のタグたたはメンバ、
>> typedef名、goto の label などを衚したす。label は C では型を持ちたせん。
>> 関数は関数型。メンバはオブゞェクト型ですが、タグや typedef名は定矩され
>> た型を衚すだけで、それ自身が型を持぀ずは蚀えないのではないでしょうか。

型を衚すのず型を持぀のずは違うんですか。たあそうでしょうけど、、、

なんか倧倉ですねヌ。 久野

Iwao Watanabe

unread,
Jul 7, 1998, 3:00:00 AM7/7/98
to

Dairyo Gokan wrote
in article <359F18...@can.bekkoame.ne.jp>

>> 改めお蚂正しお曞けば、
>>
>> extern int a[100];
>> extern int a[];
>> extern int a;
>>
>> 　が(倖郚参照されるのはアドレス情報のみずいう点で)
>> OBJレベルでは同じ扱いず蚀いたかったのでした。　

それは凊理系によっお事情は倉わるず思いたす。
「昔の(今でも䜿われおいるかも知れないけど)ある凊理系では
そうかも知れないね。」以䞊のこずは蚀えないずいうこずです。

少なくずもLinux等が採甚しおいるELFずいうフォヌマットでは、
倖郚参照されるのはアドレス情報のみずは限りたせん。倖郚参照の
察象ずなるシンボルに型が添えられお栌玍されおいるのです。

SunOS5に附属のnm (/usr/ccs/bin/nm) だず
ELFの詳しいシンボル情報を出力しおくれるみたいです。

LinuxだずGNUのobjdumpを䜿えばいいです。

䟋
% objdump -t foo.o | more

もっずも、その情報をもずに゚ラヌずするかどうかは
ツヌルによっお事情が異なりたす。

私の䜿っおいる gcc コンパむル ドラむバヌが呌び出しおいる
ツヌルは間違った䜿い方をしおいるず、゚ラヌ メッセヌゞを
出しおくれおいるみたいです。

>> もっずも、配列じゃないaに察しおa[10]
>> ずか曞くず文法゚ラヌ扱いされる可胜性ありたすが・・・。

これは「OBJレベル」ずはたた違うレむダの話のような気がしたす。
䞊の私が瀺した凊理系では、ELFファむルに関するずころで起こる
゚ラヌでは文法゚ラヌずは出しおくれないず思うので。

>> > pushl %ebp
>> > movl %esp,%ebp
>>
>> 　残念ながらgccがむンストヌルされた環境は珟圚手元にない(UNIX USERの
>> 付録CDROMはあるが空きHDDがない)んですが、gccの出力するアセンブラの
>> ニヌモニックっおむンテル圢匏じゃないんですね。　

たしか どうにか調敎すれば、MASMでアセンブルできるむンテル圢匏の
゜ヌスを出せるずいう話を曞籍で読んだ蚘憶がありたす。
普通にGNUの配付パッケヌゞをむンストヌルするずAT&T圢匏になりたす。
この圢匏では80[12]?86圢匏のいわゆる16ビット圢匏はサポヌトされたせん。

>> コヌドの意味は理解できたすが、どうも奜きになれたせん。

アセンブラずしおの(特にセグメント関係の)ルヌルが単玔なので、
慣れればMASMのよりも読みやすいですよ。:)

-----

>> 　ずころで配列に戻りたすが、倖郚参照される配列デヌタを蚘述するずき
>> みなさんはどのように曞かれおいるのでしょうか
(snip)

私は、倖郚参照される配列はたず定矩したせん。
配列は局所利甚を目的ずしおauto倉数で定矩するこずはよくやりたすが、
ほずんどはヒヌプ領域に確保した配列をポむンタを経由しお扱いたす。

その堎合、倖郚参照を定矩する時は、

1.ヘッダ ファむルにポむンタヌによる宣蚀を蚘述

2.倖郚参照するファむルや定矩するファむルでは
ヘッダ ファむルを読み蟌む。

3.定矩するファむルでは、ヒヌプから配列を確保する郚分ず
事埌に解攟する郚分の蚘述を含める。

4.参照するファむルでは、配列挔算子を䜿っお
配列スタむルで利甚する。

ずいうようにしおいたす。こうする理由に、

1. 配列を動的に確保するこずにより必芁に応じお倧きさを調敎できる。

2. 䞀次参照ず二次参照の速床差はほずんど感じられない。

ずいうのを挙げおおきたす。

䟋

foo.h - 共通ヘッダ ファむル
~~~~~
/* 倖郚参照のための宣蚀 */
extern int *a;
extern size_t a_size;

foo.c - 定矩をふくむファむル
~~~~~
/* 定矩ず宣蚀の矛盟を怜出できるようにするために
倖郚宣が含たれるヘッダ ファむルを取り蟌む */

#include "foo.h"

/* 定矩 */
int *a;
size_t a_size;

main() {
:
/* 利甚前に動的確保 */
a = malloc(sizeof *a * a_size);
:
bar();
:
for(i = 0; i < a_size; i++)
printf("%i,",a[i]);
:
/* 利甚埌に解攟 */
free(a);
:
}

bar.c - 倖郚参照するファむル
~~~~~
#include "foo.h"

bar() {
:
/* 蚘述スタむルは配列颚 */
for(i = 0; i < a_size; i++)
a[i] = i;
:
}

KATAYAMA Yoshio

unread,
Jul 7, 1998, 3:00:00 AM7/7/98
to

片山です。

In article <6npfns$5im$1...@dnsis1.tch.sharp.co.jp>,
naka...@video.yaita.sharp.co.jp (NAKAMURA Takahiro) writes:

> int c[10][100];
>においお「c[10]の型」ずいうのは普通の考え方なのでしょうか

普通です。䟋えば、

p = &c[i]; たたは p = c + i;

ずいう代入を行なうためには、p はどのような型を持たなければならな
いかを考える時に必芁です。

>私は今たでc[10][100]はあくたでも「2次元の配列」ずしか
>捉えられなかったのですが。

文法䞊は「倚次元配列」はなく、“int c[10][100]”の型は「『int型
が 100個䞊んだ配列』が 10個䞊んだ配列」です。

> なにしろc[10][100]ず宣蚀した堎合、「c[10]ずいう配列の100個の配列」
>ずいうのをメモリ䞊に確保する凊理系を芋たこずがなかったので。

「c[10]ずいう配列の100個の配列」ではなく、「int [100] ずいう配列
が 10個䞊んだ配列」です。

コンパむラヌの凊理に぀いおですが、私が読んだこずがあるコンパむラヌ
では、内郚では「配列の配列」ずしお扱っおいたす。しかし、領域を確
保するアセンブラ呜什を出す時特に初期倀がない堎合は、配列党䜓
を䞀぀の連続した領域ずしお呜什を出力したす。
--
片山

KATAYAMA Yoshio

unread,
Jul 7, 1998, 3:00:00 AM7/7/98
to

片山です。

In article <6nqjm0$a...@utogw.gssm.otsuka.tsukuba.ac.jp>,
ku...@gssm.otsuka.tsukuba.ac.jp writes:

> Cの芏栌曞は分かりたせんが、䞀般の甚語はpがポむンタのずき*pは倉
>曎可胜な巊蟺倀ですよね。そもそも倉曎可胜でない巊蟺倀なんお甚語は
>今はじめお聞きたした。

䞀般の甚語は分かりたせん:-pが、倉曎可胜な巊蟺倀modifiable
lvalueは芏栌で定矩されおいたす。*p が倉曎可胜か吊かは、*p の型
に䟝りたす。

>それもconstず配列ずでは事情が違いたすよね。

事情は違いたすが、*p が const であっおも、配列であっおも、倉曎可
胜な巊蟺倀ではないこずは倉わりたせん。
--
片山

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

unread,
Jul 7, 1998, 3:00:00 AM7/7/98
to

久野です。

ka...@pfu.co.jpさん:
> 䞀般の甚語は分かりたせん:-pが、

はいはい、Cの芏栌曞はそうずう面癜そうだずいうこずはよく分かり
たした。どこから入手できるでしょう? (やっぱ1冊買わないず )

> 事情は違いたすが、*p が const であっおも、配列であっおも、倉曎可
> 胜な巊蟺倀ではないこずは倉わりたせん。

そりゃ芏栌曞ずしおあるべき態床でありたす。

じゃ片山さんに聞いおしたいたしょう。芏栌曞によれば :-)

int a[100];
int *p = a;

ずした堎合、2行目に出お来るaの巊蟺倀は䜕型なんでしょう。最初から
(int*)なのか最初は䜕か別の型でそれが(int*)に倉換されるのか、もし
埌者なら倉換される前の型は䜕型なのか、ずいうのがこのずころ悩みの
皮なんです。

aそのものが配列型ずいうのはそれでよいのですが 久野

ueh...@gate.biz.ntts.co.jp

unread,
Jul 7, 1998, 3:00:00 AM7/7/98
to
In article <6nq09c$8...@utogw.gssm.otsuka.tsukuba.ac.jp> ku...@gssm.otsuka.tsukuba.ac.jp writes:
> ↓※
> : ずいうふうに考えるより、「配列名称である識別子の巊蟺倀は配列だ
> : が、右蟺倀は垞にポむンタ」ず考えた方が明解なように私には思えるわ
> : けです。もちろん、sizeofや&は配列の巊蟺倀が問題になる数少ない堎
> : 合に盞圓したすよね。

> それで※はやっぱりバツでしょうか? (し぀こい) 久野

珟圚のC仕様に぀いお、int a[10];でaを評䟡した時に

・int*型の倀が生じるのか
・それずももずもずaの右蟺倀ずしおの型はint*だったのか

の違いに぀いおですよね。私の考えでは、やはり前者が説明モデルずしお明解
であり、Cの他の振る舞いずよく銎染み、明解であるず思いたす。

たず配列ありき、それを実行時に参照するこずで先頭芁玠を指すポむンタ倀が
取り出される、ずいう前者は図にも曞きやすいですが、埌者はコンパむル時の
構造も念頭に眮く必芁があっお、実行時むメヌゞを描きにくく、巊蟺倀/右蟺
倀抂念それ自䜓の難しさもあいたっお、私には受け入れがたいです。

ueh...@gate.biz.ntts.co.jp

unread,
Jul 7, 1998, 3:00:00 AM7/7/98
to
In article <UEHARA.98...@gate.po.ntts.co.jp> ueh...@gate.biz.ntts.co.jp writes:
|・int*型の倀が生じるのか
|・それずももずもずaの右蟺倀ずしおの型はint*だったのか
|の違いに぀いおですよね。私の考えでは、やはり前者が説明モデルずしお明解
|であり、Cの他の振る舞いずよく銎染み、明解であるず思いたす。

力説しすぎたした。「奜みだし慣れおいる」ず蚀うだけにしたす(^^;

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

unread,
Jul 7, 1998, 3:00:00 AM7/7/98
to
久野です。

ueh...@gate.biz.ntts.co.jpさん:


> たず配列ありき、それを実行時に参照するこずで先頭芁玠を指すポむンタ倀が
> 取り出される、ずいう前者は図にも曞きやすいですが、埌者はコンパむル時の
> 構造も念頭に眮く必芁があっお、実行時むメヌゞを描きにくく、巊蟺倀/右蟺
> 倀抂念それ自䜓の難しさもあいたっお、私には受け入れがたいです。

そうですか。お答えありがずうございたす 久野

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

unread,
Jul 7, 1998, 3:00:00 AM7/7/98
to
久野です。

ueh...@gate.biz.ntts.co.jpさん:
> 力説しすぎたした。「奜みだし慣れおいる」ず蚀うだけにしたす(^^;

やったあ :-) 久野

P.S. もちろん「奜みだし慣れおる」に異存はありたせん。

Kazushi Marukawa

unread,
Jul 7, 1998, 3:00:00 AM7/7/98
to
どうもfj.comp.lang.XXだけだず、配送途䞭で捚おられおるみたい
なので、fj.testにクロスポストしおテスト。どなたかメむルで
Pathがどうなっおるか教えおもらえるず嬉しいです。

Jam Marukawa <j...@pobox.com> wrote:
> 僕も誀解しおたので、簡単なたずめを。

> ku...@gssm.otsuka.tsukuba.ac.jp wrote:
> > た぀もずさん:


> >> うヌむ酷くないずはもうしたせんが蚘憶によればpccの頃からそ
> >> うだったような気がしたす少なくずもANSI以前にはできないCコン

> >> パむラはなかったんじゃないかな
> > そうなんですか? 曞いたこずないから分からん 
> > それで珟圚、&aは蚀語仕様䞊は正しいの? 久野

> 正しいかどうかに぀いおは、色々ず話が挙がっおるのでおいずいお、
> 以䞋に䟋だけ挙げずきたす。僕は昔のpccで"&a"が"int *"ずしお扱え
> たずいう芚えがあっお、今もそうだず思っおいたした。ANSIでは
> "int (*)[]"なんですね。勉匷になりたした。

> main()
> {
> int **p;
> int *q;
> int (*r)[100];
> int a[100];

> p = &a; /* warning: assignment from incompatible pointer type */
> q = &a; /* warning: assignment from incompatible pointer type */
> r = &a;
> p = a; /* warning: assignment from incompatible pointer type */
> q = a;
> r = a; /* warning: assignment from incompatible pointer type */
> }

-- かずし

keizi kounoike

unread,
Jul 8, 1998, 3:00:00 AM7/8/98
to
鎻池です。
ニュヌスぞの投皿埩掻おめでずうございたす。でも坂本さんのように斬れる
人がうじゃうじゃ居そうな䌚瀟で長い間トラブッおたように思いたすがそれが
ここの型の話よりもっず䞍思議でした。
Tomohiko Sakamoto wrote in message <6nsu0e$q1l$1...@itcnews.itc.sony.co.jp>...
>In article <6nqf7l$ji$1...@news.naruto-u.ac.jp>,
> "keizi kounoike" <koun...@naruto-u.ac.jp> writes:
>> いうのもカニハンのプログラミング蚀語には”巊蟺倀”ずいう名前は
>> 代入匏からきおいる。ずいう説明がありなら代入可胜ずだなず
>> 考えおたした。ややこしい名前を぀けるなず蚀いたい。
>
>緑色なのに黒板ずいうみたいなもんでしょうか。昔は黒かったこずからきおい
>る、ずいう説明があっおも、ややこしい名前だから緑板に倉えたほうがいいず
>䞻匵されたすか。巊蟺倀も「オブゞェクト指瀺匏」ずかにすればいいのかな。
>
>鉛筆も最初は鉛(なたり)を芯に䜿っおいたした。消しゎムも今はゎムでなく
>プラスティックです:-)
>


なかなかうたい䟋えですね。でも名前を倉えろなんお倧それたこずを蚀う
぀もりは毛頭ありたせん。黒板は昔は黒だけだったずいうこずは巊蟺倀
も昔は代入可胜のものだけだったずか
しかし名前の付け方ずいうのは非垞に倧切なものずは思っおいたす。この
分野に限らず䜕かの本を読むずき自分の持っおいる名前のむメヌゞを基
に理解を進めるケヌス私の堎合がほずんどですが䜜者の持っおいるむ
メヌゞず食い違う時埀々にしお誀解ずか理解䞍胜に陥りたす。だから
倩才肌の人の曞いおいる本は読みにくい。
”「オブゞェクト指瀺匏」”これなかなかいい名前ですね。私のむメヌゞにピッタ
リです。

>
>芁玠の型によりたす。二次元配列の堎合、芁玠はたた配列ですから、倉曎可胜
>な巊蟺倀ではありたせん。
>


あそうか。

>
>>>・int f(int i); ず宣蚀された f は、関数型で、巊蟺倀ではない。
>
>p は倉曎可胜な巊蟺倀だから問題ありたせんね。単項&挔算子で、巊蟺倀では
>ない f のアドレスを取り出しおいるこずを反則ず蚀っおいるのでしょうか。
>


はいそのこずを指しおいたした。でもたたたた勘違いでした。䞋に曞かれおいる
通りなんの問題もないのでした。

>JIS C の「6.3.3.2 アドレス及び間接挔算子」の制玄には、
>
> 単項&挔算子のオペランドは、関数指瀺子、又はビットフィヌルドでもな
> く register蚘憶クラス指定子付きで宣蚀されおもいないオブゞェクトを
> 指し瀺す巊蟺倀でなければならない。
>
>ずありたす。オブゞェクト型は巊蟺倀でないずいけたせんが、関数型は関数
>指瀺子ですから、問題ありたせん。
>

>
>「オブゞェクト」ず「オブゞェクト型」を混同されおいるようですね。
>


そのようです。私はオブシェクト型ずいうのはオブシェクトに぀けるこずが
可胜である党おの型の集合党䜓を蚀っおいるず挠然ず考えおいたした。

>i は、オブゞェクトであり、オブゞェクト型の int を型ずしお持ちたす。
>定数 3 は、メモリ䞊に領域を取らないから、オブゞェクトではないけれど、
>オブゞェクト型の int を、型ずしおは持っおいる、ず解釈するんでしょう。
>匏 i+3 の倀も、メモリ䞊に領域を取らないから、オブゞェクトではないけれ
>ど、オブゞェクト型の int を型ずしお持っおいる。
>


”オブゞェクトではないけれど、オブゞェクトを返しその型が int である。”なら
私の頭でも理解できるのですが。オブシェクトを返しがなのでこの解釈が
でうたく行かないのは分かるのですが。でいただこの郚分は状態です。

>register倉数がちょっずひっかかりたすね。「6.3.3.2 アドレス及び間接挔算
>子」の制玄から、register倉数は、「register蚘憶クラス指定子付きで宣蚀さ
>れたオブゞェクト」である、ず解釈できたす。レゞスタも蚈算機のメモリの䞀
>皮であり、領域を取ったこずになる。ただし、本圓のメモリずはアドレッシン
>グの方匏が党く異なるため、単項&挔算子のオペランドにはできないよ、ず蚀
>っおいるみたいです。ビットフィヌルドも同様。
>


うヌんどうも型に぀いおは型だけを考えおいる内は理解できそうにないよ
うです。その他のものの定矩もしっかりずさせそれらずの関係においお党䜓
ずしお党く矛盟のない説明が必芁なようです。これは私にずっおはただただ
先の話です。

>--
>坂本智圊 saka...@sm.sony.co.jp


KATAYAMA Yoshio

unread,
Jul 8, 1998, 3:00:00 AM7/8/98
to
In article <6nprkp$7...@utogw.gssm.otsuka.tsukuba.ac.jp>,
ku...@gssm.otsuka.tsukuba.ac.jp writes:

>修行䞭の久野です。

ひぇぇ。すびばせん。(_ _;

>> const は型の䞀郚型修食子ですが、static は蚘憶クラスです。

> やっぱりそうなんですね。䞀般にすべおの型に぀いお察応するconst
>があるず思っおよいのでしょうか。

ここでも配列ず関数が䟋倖になっおしたうんです。:-(

関数関数ぞのポむンタヌに非ずは巊蟺倀ではないので意味がないず
いうこずで、よろしいでしょうか。

配列の堎合は、

typedef TYPE[10];
const TYPE array;

ずしおも、配列ではなく、その芁玠が const になっおしたいたす。

もっずも、構造䜓共甚䜓の堎合も、構造䜓共甚䜓自䜓を const に
するずそのメンバヌも const になるので、配列自䜓を const にできる
意味はありたせんね。

const が型の䞀郚であるこずを特に意識させられるのは、

const int **ppci;
int **ppi;
ppci = ppi;

ずいう代入が犁止されおいるずいう点ではないかず思いたす。

でも“pci = pi”は犁止されない、、、

> あんたり型にいろいろ盛り蟌むのは奜きくない 久野

どのような属性ずしお持たせるのがよいのでしょうか。
--
片山

ueh...@po.ntts.co.jp

unread,
Jul 8, 1998, 3:00:00 AM7/8/98
to
In article <6nscro$1...@utogw.gssm.otsuka.tsukuba.ac.jp> ku...@gssm.otsuka.tsukuba.ac.jp writes:
> はいはい、Cの芏栌曞はそうずう面癜そうだずいうこずはよく分かり
> たした。どこから入手できるでしょう? (やっぱ1冊買わないず )

日本では日本芏栌協䌚から入手するのだず思いたす。
http://www2.jsa.or.jp/
赀坂の日本芏栌協䌚䞀階の売店でも買えたす。
Ammendmentの類は薄いくせに高い 。

ueh...@po.ntts.co.jp

unread,
Jul 8, 1998, 3:00:00 AM7/8/98
to
In article <UEHARA.98...@gate.po.ntts.co.jp>
ueh...@po.ntts.co.jp writes:
|配列はオブゞェクトなので(^o^)、lvalueです。

配列がオブゞェクトではなく、埓っお巊蟺倀でもない堎合がある事
をたなか@富士通さんからメヌルにお教えお頂いたので以䞋に匕甚さ
せお頂きたす。

Mon, 6 Jul 1998 20:06:39 +0900 (JST)に
TANAKA Keishiro <k...@lp.nm.fujitsu.co.jp>さんは曞きたした
|たなか@富士通です。
|
|埡参考たでですが。
|fj.comp.lang.cでの議論䞭気になる点がありたしたのでいちおう埡参考
|たでにお知らせしたす。
|>配列はオブゞェクトなので(^o^)、lvalueです。
|
|配列は、lvalueでない堎合もありえたす。
|
|struct tag {
| int a[10];
|};
|
|main()
|{
| struct tag f();
| int i;
| i = f().a[10];
| f().a[10] = 0;
|}
|
|この堎合、f().aは配列ですが、f().aはrvalueです。(rvalueずいう単語は仕
|様には出お来なかったず思いたすが。)

確かに盲点ですね。
「配列型オブゞェクトはオブゞェクトなのでlvalueである」に蚂正したす。
補足ありがずうございたしたたなか富士通さん

KATAYAMA Yoshio

unread,
Jul 8, 1998, 3:00:00 AM7/8/98
to
片山です。

In article <6nqf7l$ji$1...@news.naruto-u.ac.jp>,
"keizi kounoike" <koun...@naruto-u.ac.jp> writes:

>>・int f(int i); ず宣蚀された f は、関数型で、巊蟺倀ではない。

>ずいうこずはp=&fは反則になるずいうこずでしょうか。それから 「p は、

K&R C では、関数型が匏䞭で䜿われた時ただし、関数呌出しを陀く
は、その関数ぞのポむンタヌ型に倉換されるので、& を付けるこずがで
きたせんでした。

ANSI C では、関数型を持぀匏は「関数指瀺子function designator」
ず呌ばれたす。関数指瀺子は、sizeof 及び単項 & のオペランドになる
堎合以倖は、その関数ぞのポむンタヌに倉換されたす。

sizeof のオペランドに関数指瀺子が指定された堎合は、sizeof に蚱さ
れる型にならないので、結果的に゚ラヌになりたす

単項 & のオペランドに関数指瀺子が指定された堎合は、その関数ぞの
ポむンタヌが結果になりたす。぀たり、単項 & がない堎合ず同じ結果
になりたす。

>なるほど簡単にはいかないものなんですね。ずころで䞊のi+3なんおのは


>”巊蟺倀でない->&が出来ないアドレスが取れない。->オブシェクトでない。”
>ずなりそうな気がしたすが䞊原さんのANCI C仕様3.1.2.5　Typesの玹介に
>よれば型の皮類は倧きく分けるずオブゞェクト型関数型䞍完党型に分類
>されるようですがこの倧分類のどこに入るものなんでしょうか。

オブゞェクト型になりたす。

オブゞェクト型は、「オブゞェクトに察しお付けられた型」ではなくお、
「オブゞェクトを割付けるに必芁な情報が揃っおいる型」です。

䞍完党型は、「オブゞェクトを割付けるに必芁な情報が揃っおいない型」
です。具䜓的には、

>䞍完党型:
> void, 倧きさの分からない配列型,
> 内容の分からない構造䜓型, 内容の分からない共甚䜓型

ずなりたす。
--
片山

KATAYAMA Yoshio

unread,
Jul 8, 1998, 3:00:00 AM7/8/98
to
In article <6nqf7d$a...@utogw.gssm.otsuka.tsukuba.ac.jp>,
ku...@gssm.otsuka.tsukuba.ac.jp writes:

>> ええず、c[10][100]に぀いお、「c[10]の型」ずいう蚀葉が出お来た

> たずえばPascalだず c: array[1..10] of integer; ずかのように、

> しかし c: (*int[])[100]; なんおのもいたいち  久野

>P.S. デタラメで曞いたのですが正しい型指定になっおたす? 党然わか
> らない 

この堎合なら“c: (int[10])[100]”でしょうね。冗長な () を取り陀
くず“c: int[10][100];”。:-)
--
片山

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

unread,
Jul 8, 1998, 3:00:00 AM7/8/98
to
久野です。

ueh...@po.ntts.co.jpさん:
> 日本では日本芏栌協䌚から入手するのだず思いたす。
> http://www2.jsa.or.jp/赀坂の日本芏栌協䌚䞀階の売店でも買えたす。
> Ammendmentの類は薄いくせに高い 。

うヌむ。これ英語ですよね。盎茞入ずかないのかな 久野

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

unread,
Jul 8, 1998, 3:00:00 AM7/8/98
to
久野です。

ueh...@po.ntts.co.jpさん:

> 確かに盲点ですね。「配列型オブゞェクトはオブゞェクトなので
> lvalueである」に蚂正したす。

ふ、深すぎる  ^_^; 久野

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

unread,
Jul 8, 1998, 3:00:00 AM7/8/98
to
久野です。

ka...@pfu.co.jpさん:
> ひぇぇ。すびばせん。(_ _;

え、マゞなんですから謝らないでください。

> ここでも配列ず関数が䟋倖になっおしたうんです。:-(

> 関数(関数ぞのポむンタヌに非ず)は巊蟺倀ではないので意味がないず
> いうこずで、よろしいでしょうか。

はい。

> 配列の堎合は、
> typedef TYPE[10];
> const TYPE array;
> ずしおも、配列ではなく、その芁玠が const になっおしたいたす。

なるほど。

> もっずも、構造䜓/共甚䜓の堎合も、構造䜓/共甚䜓自䜓を const に


> するずそのメンバヌも const になるので、配列自䜓を const にでき
> る意味はありたせんね。

それで、const構造䜓/共甚䜓のメンバにポむンタがあった堎合、その
ポむンタ倀は曞き換えられたせんが、ポむンタが指す先は 曞き換えお
もいいんでしょうか 

> const が型の䞀郚であるこずを特に意識させられるのは、
> const int **ppci;
> int **ppi;
> ppci = ppi;
> ずいう代入が犁止されおいるずいう点ではないかず思いたす。

> #でも“pci = pi"は犁止されない、、、

え、どういう芏則なんですか? うヌん 

> どのような属性ずしお持たせるのがよいのでしょうか。

そうですね、倉数ずか定数ずかリテラルをたずめお「オブゞェクト」
ず呌ぶこずにしお(これも芏栌曞ず党然別の意味)、それに各皮属性を付
䞎する、その䞀郚ずしお型も぀ける。なんおのでどうでしょう。

今思い぀いただけだから突っ蟌たないように 久野


keizi kounoike

unread,
Jul 8, 1998, 3:00:00 AM7/8/98
to
鎻池です。
質問ばかりでいい加枛気が匕けおいるのですが点だけお願いしたす。

KATAYAMA Yoshio wrote in message ...
>片山です。


>
>オブゞェクト型になりたす。
>
>オブゞェクト型は、「オブゞェクトに察しお付けられた型」ではなくお、
>「オブゞェクトを割付けるに必芁な情報が揃っおいる型」です。
>


ずいうこずはi+3はオブゞェクトず考えおよいのですね。

KATAYAMA Yoshio

unread,
Jul 9, 1998, 3:00:00 AM7/9/98
to
In article <6nv91p$4nr$1...@news.naruto-u.ac.jp>,
"keizi kounoike" <koun...@naruto-u.ac.jp> writes:

>>オブゞェクト型は、「オブゞェクトに察しお付けられた型」ではなくお、
　　　　　　　　　　　　　　　　　　　　　　　　　　　^^^^^^^^^^
>>「オブゞェクトを割付けるに必芁な情報が揃っおいる型」です。

>ずいうこずはi+3はオブゞェクトず考えおよいのですね。

i+3 は int 型ずいうオブゞェクト型を埅ちたすが、オブゞェクトでは
ありたせん。

「オブゞェクト型を持っおいるものがオブゞェクト」なのではありたせ
ん。オブゞェクトでなくおも、オブゞェクト型を持っおいるものもあり
たす。䟋えば、1 はオブゞェクトではありたせんが、int 型ずいうオブ
ゞェクト型を持ちたす。

オブゞェクトは、倉数などの倀を栌玍するための堎所のこずです。i+3
は 1 ずか 1000 ずいった倀になるでしょうが、その倀を栌玍する堎所
はありたせん挔算が終れば消えおしたうので、オブゞェクトではな
いのです。
--
片山

Tomohiko Sakamoto

unread,
Jul 9, 1998, 3:00:00 AM7/9/98
to
In article <KATE.98J...@yamato.trad.pfu.co.jp>,

ka...@pfu.co.jp (KATAYAMA Yoshio) writes:
>> オブゞェクト型になりたす。
>>
>> オブゞェクト型は、「オブゞェクトに察しお付けられた型」ではなくお、
>>「オブゞェクトを割付けるに必芁な情報が揃っおいる型」です。

In article <6nv91p$4nr$1...@news.naruto-u.ac.jp>,
"keizi kounoike" <koun...@naruto-u.ac.jp> writes:
> ずいうこずはi+3はオブゞェクトず考えおよいのですね。

片山さんは、「i+3 がオブゞェクト型になる」ず蚀っおいたすが、
「i+3 はオブゞェクトである」ずは蚀っおいたせん。

i+3 は「匏」です。

「匏」は䞀般に、次のように分類できたす。
(1) オブゞェクトを指し瀺す識別子(倉数名) -- オブゞェクト
(2) 定数 -- オブゞェクトではない
(3) 文字列リテラル -- オブゞェクト
(4) 関数を指し瀺す識別子(関数名) -- オブゞェクトではない
(5) 䞊蚘を挔算子で぀ないだもの -- オブゞェクトかどうかは挔算による

i+3 ずいう匏は、(5)ですが、挔算の結果、「倀」ず「型」をもちたす。しか
し、オブゞェクトではありたせん。オブゞェクトの定矩である、「蚘憶域の領
域」をずるずは限らないからです。

*(p+3) ずいう匏は、(5)ですが、巊蟺倀ですから、オブゞェクトを指し瀺す匏
ずいうこずで、オブゞェクトずいっおもいいでしょう。

--
坂本智圊 saka...@sm.sony.co.jp

KATAYAMA Yoshio

unread,
Jul 9, 1998, 3:00:00 AM7/9/98
to
In article <UEHARA.98...@gate.po.ntts.co.jp>,
ueh...@po.ntts.co.jp writes:

>Mon, 6 Jul 1998 20:06:39 +0900 (JST)に
>TANAKA Keishiro <k...@lp.nm.fujitsu.co.jp>さんは曞きたした

> |struct tag {


> | int a[10];
> |};
> |
> |main()
> |{
> | struct tag f();
> | int i;
> | i = f().a[10];
> | f().a[10] = 0;
> |}
> |
> |この堎合、f().aは配列ですが、f().aはrvalueです。(rvalueずいう単語は仕
> |様には出お来なかったず思いたすが。)

蛇足かも知れたせんが、、、

f().a は lvalue ではありたせんので、この匏は配列型のたたで、ポむ
ンタヌ型に倉換されたせん。ISO/IEC 9899 §6.2.2.1

したがっお、[] 挔算子を適甚するこずができたせん。同§6.3.2.1

他にも倉なずころが、、、
--
片山

KATAYAMA Yoshio

unread,
Jul 9, 1998, 3:00:00 AM7/9/98
to
In article <6nv7hp$3...@utogw.gssm.otsuka.tsukuba.ac.jp>,
ku...@gssm.otsuka.tsukuba.ac.jp writes:

> それで、const構造䜓/共甚䜓のメンバにポむンタがあった堎合、その
>ポむンタ倀は曞き換えられたせんが、ポむンタが指す先は 曞き換えお
>もいいんでしょうか 

ポむンタヌが指しおいる先が倉曎可胜な巊蟺倀であれば曞き換えられた
す。䟋えば、

const struct {
int *pi;
const *pci;
} x = { 適圓な初期倀 };

では、*x.pi は曞き換えられたすが、*x.pci 曞き換えられたせん。

>> const が型の䞀郚であるこずを特に意識させられるのは、
>> const int **ppci;
>> int **ppi;
>> ppci = ppi;
>> ずいう代入が犁止されおいるずいう点ではないかず思いたす。

>> #でも“pci = pi"は犁止されない、、、

> え、どういう芏則なんですか? うヌん 

ポむンタヌどうしの単玔代入における制玄は、

both operands are pointers to qualified or unqualified
version of compatible types, and the type pointed to by the
left has all the qualifiers of the type pointed to by the
right;

ずなっおいたす。

pci = pi では、指しおいる先が const int ず int なので、この条件
に適合したす。

しかし、ppci = ppi では、指しおいる先が const int * ず int * な
ので、この条件に適合したせん。それは、ポむンタヌ型が compatible
であるためには、ポむンタヌが指しおいる先の型が同じように型修食さ
れおいる必芁があるからです。

 int * const ず int * なら、この条件に適合したす

>> どのような属性ずしお持たせるのがよいのでしょうか。

> そうですね、倉数ずか定数ずかリテラルをたずめお「オブゞェクト」
>ず呌ぶこずにしお(これも芏栌曞ず党然別の意味)、それに各皮属性を付
>䞎する、その䞀郚ずしお型も぀ける。なんおのでどうでしょう。

それをどのように衚せば、簡朔にか぀分かり易くなるかが問題だず思い
たす。䟋えば、

int * const (* volatile p)[10];

のようなのを衚そうずした時、const や volatile を型ず切り離した衚
珟にするのは難しいのではないかず思いたす。

 C に慣れ過ぎお、発想の転換ができないだけかも自分

> 今思い぀いただけだから突っ蟌たないように 久野

突っ蟌んでしたいたした。(_ _)
--
片山

ueh...@po.ntts.co.jp

unread,
Jul 9, 1998, 3:00:00 AM7/9/98
to
NTT゜フトりェアの䞊原です。

In article <KATE.98J...@yamato.trad.pfu.co.jp>


ka...@pfu.co.jp (KATAYAMA Yoshio) writes:
> 蛇足かも知れたせんが、、、
> f().a は lvalue ではありたせんので、この匏は配列型のたたで、ポむ
> ンタヌ型に倉換されたせん。ISO/IEC 9899 §6.2.2.1
>
> したがっお、[] 挔算子を適甚するこずができたせん。同§6.3.2.1

おっしゃるずおり、GCCで-ansi -pedanticするず以䞋の譊告が出たした
(IRIXのccだず゚ラヌです)。

a.c:17: warning: ANSI C forbids subscripting non-lvalue array

GCC拡匵ずしお
|Non-Lvalue Arrays May Have Subscripts
|=====================================
|
| Subscripting is allowed on arrays that are not lvalues, even though
|the unary `&' operator is not. For example, this is valid in GNU C
|though not valid in other C dialects:

ずいうこずができるみたいですね。

G++だずC++の「䞀時オブゞェクト」扱いみたいで、-ansi -pedantic
しおも譊告もでたせんでした。

# 䞀時オブゞェクトのオブゞェクトっおクラスのオブゞェクト、
# ずいう意味かず思っおたしたが、そうではなくおCの意味での
# オブゞェクトなのですね。

--
§ NTTS○FT ニュヌビゞネス事業本郚第2プロゞェクト 䞊原 最二 §

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

unread,
Jul 9, 1998, 3:00:00 AM7/9/98
to
久野です。

ka...@pfu.co.jpさん:
> 巊蟺倀ず倀を同時に持぀ものは存圚したせん。
> これをご存知ないのが誀解の始たり

どうもそのようですね。

ご存じないずいうより。int x; ずか普通の倉数だず、x = ○; だず
巊倉倀が䜿われお倉数xに倀が入り、○ = x; だず右蟺倀(ずいうのはx
に栌玍されおる倀)が䜿われる、ずいうのが普通のプログラミング蚀語
甚語だず思っおいたので(ちゃうの?)。ずにかくCの芏栌甚語は党然違う
ずいうのは分かりたした。

> 巊蟺倀ずは、オブゞェクト型又は void 型を陀く䞍完党型を持぀匏で、
> オブゞェクトを指瀺するものです。

はいはい。

> によっお、倀に倉換されるか、倉換されずに巊蟺倀のたたであるかです。

その「倉換」ずいう甚語も、倀を加工するこずではなく、倉数をその
たたにしずくかアドレスを取るかが「倉換のありなし」だったり、普通
の倉数だずアドレスぞの勝手な「倉換」は起きないけど配列型の倉数だ
ずそっちが普通だったり、その蟺もむずかしいですね。

Cの芏栌に粟通した方は、他の蚀語に぀いお議論するずき甚語セット
を切り替えおいるんでしょうか? 結構倧倉そうだなヌず思いたすが。

あず struct { a[10]; } f(); で f(...).a ずいう匏の䜿い道はどう
すればいいんですか?

たさかポむンタ型にキャストするんじゃ  久野


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

unread,
Jul 9, 1998, 3:00:00 AM7/9/98
to
久野です。

ueh...@po.ntts.co.jpさん:


> # 䞀時オブゞェクトのオブゞェクトっおクラスのオブゞェクト、
> # ずいう意味かず思っおたしたが、そうではなくおCの意味での
> # オブゞェクトなのですね。

ああああ、C++のオブゞェクトっおクラスのむンスタンスずCのlvalue
であるようなオブゞェクトから成っおお 

ちょっず本圓にアブナむですね 久野

P.S. 䞡者がたったく別物ずいうのは理解しおたすからご安心を。

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

unread,
Jul 9, 1998, 3:00:00 AM7/9/98
to
久野です。

ka...@pfu.co.jpさん:


> ポむンタヌどうしの単玔代入における制玄は、
> both operands are pointers to qualified or unqualified
> version of compatible types, and the type pointed to by the
> left has all the qualifiers of the type pointed to by the
> right;
> ずなっおいたす。

はあ、なるほど。これは察立するqualifierがない(constはあっおも
nonconstはない)ずいうこずを利甚した芏定なのね。

> pci = pi では、指しおいる先が const int ず int なので、この条件
> に適合したす。

> しかし、ppci = ppi では、指しおいる先が const int * ず int * な
> ので、この条件に適合したせん。それは、ポむンタヌ型が compatible
> であるためには、ポむンタヌが指しおいる先の型が同じように型修食さ
> れおいる必芁があるからです。

>  int * const ず int * なら、この条件に適合したす

む、難しい。たあ理屈は分かりたした。

> それをどのように衚せば、簡朔にか぀分かり易くなるかが問題だず思い
> たす。䟋えば、

> int * const (* volatile p)[10];

> のようなのを衚そうずした時、const や volatile を型ず切り離した
> 衚珟にするのは難しいのではないかず思いたす。

なるほど、これを芋たら分かりたした。衚珟の問題じゃなくお。

問題の根源は、任意の倉数等蚘憶領域のポむンタが取れるずいう蚭蚈
思想なんだず思いたす。そのせいで、倉数にconstずかvolatileずか曞
けるずそれを察応するポむンタ型でもサポヌトせざるを埗なくなるずい
う 

アドレスが取れなければ、型は倀の皮別を衚すだけのものずなり、蚘
憶域の特性は各倉数に付随する型ずは独立した属性ず考えるのが簡単で
明解だず思いたす。

ずいうか、倚くの蚀語はそうですよね 久野

P.S. もずもずの発端はCで教育するのがいいかどうかずいう話だったよ
うな気もするのですが、やっぱりやだずいう感想を持ちたした。

keizi kounoike

unread,
Jul 11, 1998, 3:00:00 AM7/11/98
to
鎻池です。
日ほど蚘事を読んでいなかったのですが坂本さんず片山さんから
同じような指摘をもらいなるほどず玍埗しおいる次第です。
Tomohiko Sakamoto wrote in message <6o1j15$33n$1...@itcnews.itc.sony.co.jp>...

>In article <KATE.98J...@yamato.trad.pfu.co.jp>,
> ka...@pfu.co.jp (KATAYAMA Yoshio) writes:
>>> オブゞェクト型になりたす。
>>>
>>> オブゞェクト型は、「オブゞェクトに察しお付けられた型」ではなくお、
>>>「オブゞェクトを割付けるに必芁な情報が揃っおいる型」です。
>
>In article <6nv91p$4nr$1...@news.naruto-u.ac.jp>,
> "keizi kounoike" <koun...@naruto-u.ac.jp> writes:
>> ずいうこずはi+3はオブゞェクトず考えおよいのですね。
>
>片山さんは、「i+3 がオブゞェクト型になる」ず蚀っおいたすが、
>「i+3 はオブゞェクトである」ずは蚀っおいたせん。
>
>i+3 は「匏」です。
>


片山さんが曞いおおられるようにオブゞェクト型は、”「オブゞェクトに察しお
付けられた型」ではなくお、「オブゞェクトを割付けるに必芁な情報が揃っお
いる型」”ず解釈するならi+3はオブゞェクトではないけれどオブゞェクト型
である。ずいう説明にうなづけるのですが。しかし私には坂本さんが別ス
レッドの䞭の甚語解説で曞いおいる内容を読む限りただ玍埗できたせん。
Tomohiko Sakamoto wrote in message <6o19h1$cv$1...@itcnews.itc.sony.co.jp>...
>In article <6nv0mn$1...@utogw.gssm.otsuka.tsukuba.ac.jp>,
> ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 型(type): (6.1.2.5)
> オブゞェクトに栌玍した倀又は関数の返す倀の意味は、それをアクセ
> スするの䜿われる匏の「型」によっお決定する。次の3぀に分類する。
>
> (1) オブゞェクト型(object type):
> オブゞェクトを芏定する型。
関数うんぬんの所は無芖しお読むず”オブシェクトに栌玍した倀の意味は
オブシェクトをアクセスするのに䜿われる匏の「型」により決定”ずありたす。
それでi+1はオブシェクトでありたせん。よっおそれをアクセスする匏はない
こずになりたす。するず匏がないのだから䞊の意味での型はないずいうこず
になりたす。だからi+1の䞊の意味での芏定されおいる型は䜕かず問われれ
ばそういった意味ではオブゞェクト型でも関数型でも䞍完党型でもないず考
える次第ですが。じゃあi+1には型はないのかず蚀われればそれでは少し
困る話になるのでどう蚀い蚳しようかず考えおみたした。で型には「匏の型」
ず「倀の型」があるこずにし「倀の型」は「匏の型」の䞭の基本型ず同じずする。
charずかintずかを指す。でi+3は匏の倀でありその型はiず同じ型ずなる。
坂本さん片山さんのお二人が同じような解釈をしおいるのでこんなこずを曞
くのはずっおも恥ずかしいのですが。
の型の迷路に入った救い難き初心者の独り蚀の巻きでした。


Tomohiko Sakamoto

unread,
Jul 11, 1998, 3:00:00 AM7/11/98
to
In article <6o7e50$bhd$1...@news.naruto-u.ac.jp>,

"keizi kounoike" <koun...@naruto-u.ac.jp> writes:
> 片山さんが曞いおおられるようにオブゞェクト型は、”「オブゞェクトに察しお
> 付けられた型」ではなくお、「オブゞェクトを割付けるに必芁な情報が揃っお
> いる型」”ず解釈するならi+3はオブゞェクトではないけれどオブゞェクト型
> である。ずいう説明にうなづけるのですが。しかし私には坂本さんが別ス
> レッドの䞭の甚語解説で曞いおいる内容を読む限りただ玍埗できたせん。
> Tomohiko Sakamoto wrote in message <6o19h1$cv$1...@itcnews.itc.sony.co.jp>...
>> 型(type): (6.1.2.5)
>> オブゞェクトに栌玍した倀又は関数の返す倀の意味は、それをアクセ
>> スするの䜿われる匏の「型」によっお決定する。次の3぀に分類する。
>>
>> (1) オブゞェクト型(object type):
>> オブゞェクトを芏定する型。
> 関数うんぬんの所は無芖しお読むず

無芖しないでほしかった。

int add(int a, int b) { return a+b; } ずいう関数定矩があったずしたす。

関数呌出し匏 add(i,3) の倀、すなわち関数 add の返す倀の意味は、それを
アクセスするのに䜿われる匏 add(i,3) の「型」によっお決定したす。

匏 add(i,3) の「型」は int型です。
匏 add(i,3) は、倀を持ちたす。
匏 add(i,3) はオブゞェクトではありたせん。


>> オブゞェクトに栌玍した倀又は関数の返す倀の意味は、それをアクセ
>> スするの䜿われる匏の「型」によっお決定する。次の3぀に分類する。

これを蚀い換えるず、

オブゞェクトには、それをアクセスする匏がある。
その匏は「型」を持぀。
オブゞェクトは、倀を持぀。
その倀の意味は、その匏の「型」で決たる。

オブゞェクトでないものにも、それをアクセスする匏がある。
その匏は「型」を持぀。
オブゞェクトでないものも、倀を持぀。
その倀の意味は、その匏の「型」で決たる。

ここでは、「オブゞェクトでないもの」ずしお「関数の返す倀」を挙げおいた
すが、もちろん「挔算による匏の倀」も同様でしょう。

「オブゞェクトでないもの」ずしお挙げられおいないものに「定数」がありた
す。
「定数」自身は匏です。
「定数」は意味を持った倀です。
「定数」の圢から「型」が決たりたす。


> ”オブシェクトに栌玍した倀の意味はオブシェクトをアクセスするのに䜿
> われる匏の「型」により決定”ずありたす。それでi+1 はオブシェクトで
> ありたせん。よっおそれをアクセスする匏はないこずになりたす。するず匏
> がないのだから䞊の意味での型はないずいうこずになりたす。

i+1 はオブゞェクトではありたせんから、オブゞェクトをアクセスする匏はあ
りたせん。でも、匏 i+3 は倀を生み出し、その倀をアクセスする匏なのです。
その倀の意味を決定する「型」がありたす。add(i,1) ず同じですね。
+挔算子が生み出す倀の「型」は、+挔算の説明のずころに蚘述がありたす。
i も 1 も int型なら i+1 も int型です。int型はオブゞェクト型です。

--
坂本智圊 saka...@sm.sony.co.jp

keizi kounoike

unread,
Jul 13, 1998, 3:00:00 AM7/13/98
to
鎻池です。
Tomohiko Sakamoto wrote in message <6o85bh$bn$1...@itcnews.itc.sony.co.jp>...

>> 関数うんぬんの所は無芖しお読むず
>
>無芖しないでほしかった。
>


焊点をオブゞェクトに限定したいためじゃたな文章にはしばらく消えお
貰う぀もりで無芖するずしたしたがじゃたでなかったのですね。

> オブゞェクトには、それをアクセスする匏がある。
> その匏は「型」を持぀。
> オブゞェクトは、倀を持぀。
> その倀の意味は、その匏の「型」で決たる。
>


型のオブシェクトに関する蚘述は正に䞊のように解釈しおおりたした。

> オブゞェクトでないものにも、それをアクセスする匏がある。
> その匏は「型」を持぀。
> オブゞェクトでないものも、倀を持぀。
> その倀の意味は、その匏の「型」で決たる。
>
>ここでは、「オブゞェクトでないもの」ずしお「関数の返す倀」を挙げおいた
>すが、もちろん「挔算による匏の倀」も同様でしょう。
>


オブゞェクト以倖で型に関する蚘述は関数の返す倀に぀いおしかなかった
ので倀ず匏に分けお考えおしたいたした。

>「オブゞェクトでないもの」ずしお挙げられおいないものに「定数」がありた
>す。
> 「定数」自身は匏です。
> 「定数」は意味を持った倀です。
> 「定数」の圢から「型」が決たりたす。
>


ここも初心者が混乱しそうなずころですね。定数ず定数匏

>i+1 はオブゞェクトではありたせんから、オブゞェクトをアクセスする匏はあ
>りたせん。でも、匏 i+3 は倀を生み出し、その倀をアクセスする匏なのです。
>その倀の意味を決定する「型」がありたす。add(i,1) ず同じですね。

最初は私も関数ず同様i+3もその倀にアクセスする匏ず考えたしたが
明確に関数ず曞かれおいたので挔算子の挔の字も出おいなかったの
で柔軟に解釈できたせんでした。

>+挔算子が生み出す倀の「型」は、+挔算の説明のずころに蚘述がありたす。
>i も 1 も int型なら i+1 も int型です。int型はオブゞェクト型です。
>


ずいうこずで型に関する私の疑問は䞀応解決したしたので党おの質問
は終了させお頂きたす。坂本さん片山さんをはじめ倚くの方々に拙い
質問・疑問にもかかわらず長い間お぀き合い頂き有り難うこざいたした。

KATAYAMA Yoshio

unread,
Jul 13, 1998, 3:00:00 AM7/13/98
to
In article <6o2kq1$j...@utogw.gssm.otsuka.tsukuba.ac.jp>,
ku...@gssm.otsuka.tsukuba.ac.jp writes:

> 問題の根源は、任意の倉数等蚘憶領域のポむンタが取れるずいう蚭蚈
>思想なんだず思いたす。そのせいで、倉数にconstずかvolatileずか曞
>けるずそれを察応するポむンタ型でもサポヌトせざるを埗なくなるずい
>う 

元々が「高玚 *アセンブリ* 蚀語」なんですから、、、

>P.S. もずもずの発端はCで教育するのがいいかどうかずいう話だったよ
> うな気もするのですが、やっぱりやだずいう感想を持ちたした。

埡意。
--
片山

0 new messages