K.Maebashi's BBS

>X 3010：2003 (ISO/IEC 9899：1999)の「7.1.2 標準ヘッダ」から引用します。 >| 標準ヘッダはどのような順序で取り込んでもよい。各ヘッダは与えられた有効範囲内で >| 2回以上取り込んでもよいが，その効果は，<assert.h>の取込みの効果がNDEBUG の >| 定義に依存すること（7.2 参照）を除いて，1 回だけ取り込んだ場合と同じとする。 > >とのことなので、保証されています。(実現手段は問わないのでしょうが) ありがとうございます。 すみません、規格票は閲覧できるのだから、調べれば分かる質問をしてちゃいけませんね（反省）。

>標準ライブラリのヘッダファイルにインクルードガードが施されていることって、保証されているものなんでしょうか？ X 3010：2003 (ISO/IEC 9899：1999)の「7.1.2 標準ヘッダ」から引用します。 | 標準ヘッダはどのような順序で取り込んでもよい。各ヘッダは与えられた有効範囲内で | 2回以上取り込んでもよいが，その効果は，<assert.h>の取込みの効果がNDEBUG の | 定義に依存すること（7.2 参照）を除いて，1 回だけ取り込んだ場合と同じとする。 とのことなので、保証されています。(実現手段は問わないのでしょうが)

あの、今更こんなこと恥ずかしくて聞きづらいんですが…… 標準ライブラリのヘッダファイルにインクルードガードが施されていることって、保証されているものなんでしょうか？ そうじゃなきゃ使い物にならないことは分かるのですが。

おそらく3/27～3/28にかけて、本Webサイトkmaebashi.comが停止しておりました。 管理人である私が、忙しさにかまけてレンタルサーバの利用料金の振込みを失念していたのが原因です。3/28に振り込んで復旧していただきました。 利用者の皆様にはご迷惑をおかけしまして申しわけありませんでした。

>この書き方とは？ getchar()==(unsigned char)('a') っすか？ >俺ならここまで厳密に書くことは絶対にしない（お仕事コードでも）と思うですよ。 あわわ、ちゃいますgetchar() == 'a'のほうです、紛らわしい書き方ですいません(^^;) >俺が本を書くとしたら 貴重なご意見ありがとうございます。 原理に深入りするかどうかはともかく、getchar() == 'a' が意図したとおりに動くかどうかは、 基本文字集合以外は保証されない、基本文字集合なら保証される、 ということは伝えるべきなのでしょうねぇ。

この書き方とは？ getchar()==(unsigned char)('a') っすか？ 俺ならここまで厳密に書くことは絶対にしない（お仕事コードでも）と思うですよ。 俺が本を書くとしたら unsigned char の話には触れないです。 EOF は一般の意味での [文字] ではないため int が必要であるとは書きます。 int c=getchar(); switch (c) { case EOF: case 'a': } のように文字コードに関しては単純に 'a' と書くでしょう。んで、脚注にでも (†1) C はもともと英語圏で発展した言語なので、英語のアルファベットにない文字： ドイツ語のウムラウト文字とかエスツェットとか フランス語のアクサングラーブ文字とか 日本語の各種ひらがなカタカナ漢字とか は、C の初期からある標準関数ではうまく扱えないことがある。 たとえばこの例で case 'ｱ': と書いても動かない処理系のほうが多い。 (†2) そもそも日本語や中国語などの文字は多バイトで表現するので、 取り扱い方法がまったく変更になることが通例である。 とでもしておきますかね。もしかしたら脚注３で (†2) 標準関数で無理なく問題なく扱える文字の集合を基本実行文字集合と呼ぶ。 とするかもしれないです。

よく理解できました。 自分がコーディングするときはこの書き方を使い続けることになると思いますが、 初心者に指導する際はどうすればいいんでしょうかねぇ…… 例えば入門書を書く機会があればどうされますか>皆様

まあついでに言うと getchar()=='ｱ' も getchar()=='a' も「本質的には」間違っているわけで。 getchar() は [unsigned char 型として取り込み] [int 型に変換] なので、 返却される文字の値は char 型としての値ではなく unsigned char 型としての値となるため getchar()==(unsigned char)('ｱ') や getchar()==(unsigned char)('a') としておかないと 言語仕様と不一致になってしまう、と判断すべきでしょう。 これではあまりにもウザイので =='a' のような判断を許すべく 多く使われる基本文字については非負と決めているのだと思われますです。 非負ならば (unsigned char) にキャストしても、しなくても、値が同じなので。

処理系依存にならないよう、基本文字は [後半] にできないことになっているようですね。 #1806 基本文字は非負、の文言は C にもありました。

>>この「非負の」に相当する文言がCの方にはないように思えるんですよね。 >俺が探した範囲でも無いっすね。 C++ で追記されたと読むべきでしょう。 あった。 JIS X 3010:2003 6.2.5 型 型 char として宣言されたオブジェクトは、実行基本文字集合の任意の要素を格納するのに十分な大きさを持つ。 基本実行文字集合の任意の要素を char 型のオブジェクトに格納した場合、その値は非負であることを保証する。 その他の文字を char 型のオブジェクトに格納した場合、その結果の値は処理系定義とするが、 その型で表現可能な値の範囲に含まれなければならない。 ってことは EBCDIC では char 型の内部表現は unsigned char と同じにならざるを得ないってことか？

kitさん、ありがとうございます。 >いや、それは勘違いです。与れますよ。 >ファイルからコード 255 のバイトを getchar() で読むと、-1 ではなく 255 を返しますから。 あちゃ、まだ完全に分かってませんでした。 getc系の関数はストリームから得た文字をunsigned char型の値として解釈して、それをint型に変換するのでした。 つまり、「ｱ」の文字コードが 0xB1のとき、 文字定数'ｱ'の値がデフォルトcharによって異なる（signedならint型の-79、unsignedならint型の177になる）のに対し、 getcの戻り値は必ずint型の177になるのですね。 バイナリエディタで0xB1を書き込んだファイルを使って実験すると、 手元のVCでは 'ｱ' == getc() が偽になります。 はっきり言って「文字定数」と「getc系関数の戻り値」とは、ぜんっぜん違う！ということですね。 どちらも最終的にint型になるが、【値を解釈するときに】デフォルトcharに合わせるか、unsigned char固定か。 あれ？ということは、 int hoge = getchar(); if(hoge == 'a'){ /* ...... */ } のほうが（C++ではなくCでは）処理系依存ということになるのですか？ 「a」が「後半の」文字かもしれないことを考えると。

>>EOFは-1とは限らない(負でさえあればよい)ので回避のしようはありますね。 > >そうですね。 > >手元のVCだと無印charはデフォルトでsigned、EOFの値は-1になっていて、 >回避できるにも関わらず回避していない。 多くのUNIX系プラットフォームでもそうです。 (powerpc なんかは char のデフォルトが unsigned だったような気もしますが) >getchar()などの戻り値をintで受ける理由は言わずと知れたFAQですが、 >上記のような処理系では、せっかくの「文字コードの空間の外でEOFを扱えるように」という恩恵に与れないことになりますよね。 >（というか、そういう処理系がほとんどのような気がします。） いや、それは勘違いです。与れますよ。 ファイルからコード 255 のバイトを getchar() で読むと、-1 ではなく 255 を返しますから。

774RRさん、C++の情報ありがとうございます。 私の理解の変遷： 文字定数は本来はchar型だが、汎整数拡張されてint型になると理解していた →プギャー、規格に「int型を持つ」って明記されてるぅ！ （汎整数拡張が抑止されるはずのsizeofでもint型のサイズが返ってくる） →じゃあcharに一旦入れちゃったら、表現しきれない値は壊れるかもしれないのか？ →「charの符号の扱いに合わせた」int値になるから大丈夫だよん ということですね。 「なんでcharの符号は処理系定義なのにめったに困ることがないのか」という疑問が晴れたように思います。 ヘンにsigned/unsignedを指定して文字コードを扱ってしまった場合にこそバグるんですね。

>この「非負の」に相当する文言がCの方にはないように思えるんですよね。 俺が探した範囲でも無いっすね。 C++ で追記されたと読むべきでしょう。 # 最初 [基本] を見落としていて 負数のcharは一切ダメ？ と思ったのは内緒。 >しかし、EBCDICのC++処理系があるものかどうか (^^; あって、自由に使ってよければ是非試してみたいところです。

すみません、この投稿を見落としていました。 >2.2 - 3 基本実行文字集合 >基本実行文字集合において、それぞれの文字は非負の互いに異なる値をもっていなければならない。 この「非負の」に相当する文言がCの方にはないように思えるんですよね。探したのですが。 >char オブジェクトが負の値をもてるか否かは、処理系定義とする >EBCDIC およびその派生な文字セットの場合 'A'=h'C1, '0'=h'F0 なので、 >[基本文字集合は非負の値] からいくと「単なる char は符号なし」しかダメなんだろう。 なのだろうと思います。しかし、EBCDICのC++処理系があるものかどうか (^^;

>EOFは-1とは限らない(負でさえあればよい)ので回避のしようはありますね。 そうですね。 手元のVCだと無印charはデフォルトでsigned、EOFの値は-1になっていて、 回避できるにも関わらず回避していない。 getchar()などの戻り値をintで受ける理由は言わずと知れたFAQですが、 上記のような処理系では、せっかくの「文字コードの空間の外でEOFを扱えるように」という恩恵に与れないことになりますよね。 （というか、そういう処理系がほとんどのような気がします。） ただ「0xFFに文字が割り当てられることは滅多にない」という「実情」に依存しているような……。 >(いつものことですが)私も勉強させていただいております。 こちらこそ、いつも本当にありがとうございます。

出遅れ気味... C++ の場合は仕様書の文言が若干違うようです。 以下 ISO/IEC 14882:1998 ならびに JIS X3014:2003 から 2.2 - 3 基本実行文字集合 基本実行文字集合において、それぞれの文字は非負の互いに異なる値をもっていなければならない。 実行文字集合は、基本実行文字集合をその部分集合とする集合とする。 実行文字集合における文字の値は、処理系定義とする。 俺：この文言は [基本文字集合は非負の値] [基本でない文字集合は負でもよい] と読むべきなのだろう・・・ 2.13.2 文字リテラル 文字リテラルは型 char をもち、実行文字集合での符号数値に等しい値を持つ。 俺：C の 6.4.4.4 の例のような文言は無いな・・・ 3.9.1 基本型 char として宣言されたオブジェクトの大きさは、処理系定義である実行文字集合のすべての要素を 格納するのに十分なだけ大きくなければならない。 char オブジェクトが負の値をもてるか否かは、処理系定義とする EBCDIC およびその派生な文字セットの場合 'A'=h'C1, '0'=h'F0 なので、 [基本文字集合は非負の値] からいくと「単なる char は符号なし」しかダメなんだろう。 ただ、実処理系で確認しようにもいろいろ微妙かも。 すぐ使える場所に EBCDIC な処理系は無いし printf("%d\n", '\xF0'); とすると [汎整数拡張] 後の int 型の値確認にしかならないし cout << '\xF0'; だと[文字表記]になって[文字の値]ではないし cout << int('\F0'); だと同 int の確認だし

># でもEOFとかち合ったりしないのかなぁ…… ここだけ見て、規格にこっそり「charがsignedな処理系では1バイト文字定数は0xFFになってはいけない」みたいなことが書いてないかなあと見てみたのですが書いてなく、それどころか上記引用部には堂々と0xFFのケースが書いてあるわけですが、EOFは-1とは限らない(負でさえあればよい)ので回避のしようはありますね。 (いつものことですが)私も勉強させていただいております。

すみません、たぶん自己解決しました。 JIS X3010:2003 6.4.4.4 文字定数 | |意味規則　単純文字定数は、型intをもつ。 |（中略） |単純文字定数が単一の文字又は逆斜線表記を含む場合、その値はその単一の文字又は逆斜線表記の値をもつ |char型のオブジェクトをint型に変換したときの結果の値とする。 |（中略） |例2. 整数に対し2の補数表現を用い、型charをもつオブジェクトに対して8ビットを用いる処理系を考える。 |型charがsigned charと同じ範囲の値をもつ処理系では、単純文字定数'\xFF'は値-1をもつ。型charが |unsigned charと同じ範囲の値をもつ場合、'\xFF'は値+255をもつ。 この例2を見ると、文字定数の値が、「charがsignedかunsignedか」に連動して定まることになりますね。つまり、int型のモノが「char型に対する扱い」に依存するんですね。知りませんでした。 ということは、無印のcharがsignedの処理系であろうとunsignedの処理系であろうと、文字定数を代入して値が変わってしまう心配はない、と。 一番気になっていたのは、「等しいはずの文字を比較したのに『等しくない』と判定されてしまうかも」ということだったのですが、これで心配はなくなりました。 # でもEOFとかち合ったりしないのかなぁ……

ありがとうございます。 >これが > >>char hoge[] = {'ｱ', 'ｲ', 'ｳ', '\0'}; > >だったら間違いなく違和感があると思うのですが。 なるほど、考えてみれば半角カナで実験してみればよかったですね。 #include <stdio.h> int main(void){ printf("%d\n", 'ｱ'); return 0; } VCでコンパイルして実行すると -79 あり？どうなってるんだ・・・

どうもです。 >「A」の文字コードは決まっていないし、charがsignedになるかunsignedになるかは処理系によるので、結局この代入自体が処理系定義になるわけですよね。 確かにそうなりそうに思うのですが…… >よくchar配列の初期化の例で、 > >char hoge[] = "ABC"; > >は > >char hoge[] = {'A', 'B', 'C', '\0'}; こういう説明は私もしていますし、でも確かに処理系定義だと思います。 これが >char hoge[] = {'ｱ', 'ｲ', 'ｳ', '\0'}; だったら間違いなく違和感があると思うのですが。 まあ、'A'がunsigned char側に割り当てられるような処理系はまずないだろうという前提を、たいていのCの入門書著者は置いてしまっているのだと思います。私も含めて。

（ぱ）さん、ありがとうございます。 「A」の文字コードは決まっていないし、charがsignedになるかunsignedになるかは処理系によるので、結局この代入自体が処理系定義になるわけですよね。 よくchar配列の初期化の例で、 char hoge[] = "ABC"; は char hoge[] = {'A', 'B', 'C', '\0'}; の略であって……といった説明になるわけですが、この場合も同様だとすると、 あれれ？そんな処理系定義な例で説明がなされているのか？と疑問に思ってしまったわけです。 （すみません、もの凄くアホな勘違いをしているかもしれません。）

すみません、しばらくここを放置してしまいました。 >C言語において、文字定数は1バイトの表現に収まることが保証されていますが、 >たとえば'A'が200のような値をとっていけないことはないですよね。 >すると、charがsignedな処理系で char hoge = 'A'; と書くと、未定義動作になるのでしょうか？ 'A'自体の型はintですので、普通にintからsigned charへの型変換と考えると、 X 3010：2003の6.3.1.3によれば >そうでない場合，すなわち，新しい型が符号付き整数型であって，値がその型で表現できない場合は， >結果が処理系定義の値となるか，又は処理系定義のシグナルを生成するかのいずれかとする。 なので、処理系定義ですかね。

C言語において、文字定数は1バイトの表現に収まることが保証されていますが、 たとえば'A'が200のような値をとっていけないことはないですよね。 すると、charがsignedな処理系で char hoge = 'A'; と書くと、未定義動作になるのでしょうか？

fd

test

ｃｖｇｃｇｄｇｈｄｇおっぱ

ああああなんあなん

tinkoとmankoを合体させよう

おppai