08/02/22 13:35:11
ああ、C++で(type)が参照型なのは除く。
101:デフォルトの名無しさん
08/02/22 13:36:16
ちなみにC++だと(char&)c = 1って書ける。
102:デフォルトの名無しさん
08/02/22 19:10:21
>>98
*(char*)c = 1; と同じになった気がする。
K&R C あたりではできると聞いた事があるような気がするが、
詳しい事は俺は知らん。
103:デフォルトの名無しさん
08/02/22 20:01:18
K&Rではできた。
104:デフォルトの名無しさん
08/03/08 01:50:20
Ｃでは符号なし整数をビットシフトすると論理シフト、符号有り整数をビットシフトすると算術シフトになるんですか？
105:デフォルトの名無しさん
08/03/08 01:53:58
右シフトはそのとおり。
左シフトは論理/算術の区別が無い。
106:デフォルトの名無しさん
08/03/08 01:54:59
わかりました。
早いレスありがとうございます。
107:デフォルトの名無しさん
08/03/08 01:55:53
符号あり整数をビットシフトして算術シフトになるかどうかは
C の規格では規定されていない。
ただ、実際問題そういう実装が多いだろうね。
108:デフォルトの名無しさん
08/03/08 01:57:02
unsignedは論理シフトになる
signedが算術シフトになるかどうかは処理系依存
109:デフォルトの名無しさん
08/03/08 02:59:55
規格見直したら、負の数を右シフトしたときは結果の値が処理系定義になるって
書いてあった。つまり、算術シフトとも論理シフトとも違う結果が得られてもおかしくない
わけだ。
あと、型が signed でも値が負じゃなければ unsigned と同じ動作って決められてた。
110:デフォルトの名無しさん
08/03/08 03:03:49
２の補数表現じゃない環境だと
算術シフトにならない実装になってるだろうね。
111:デフォルトの名無しさん
08/03/08 09:37:18
ただしどうなるかは(規格準拠の処理系なら)マニュアルに明記されていなければならない
112:デフォルトの名無しさん
08/03/08 20:29:31
明記されていればry
113:デフォルトの名無しさん
08/04/02 23:13:23
最近レスが無いので、ビットシフトについて質問してもいいですか？
114:デフォルトの名無しさん
08/04/03 00:24:28
負の数の右シフトが算術シフトになるか論理シフトになるかは処理系依存です。
115:デフォルトの名無しさん
08/04/03 00:29:04
負の数の左シフトは？
116:デフォルトの名無しさん
08/04/03 00:42:31
「場合によって未定義」でいいのかな？
URLﾘﾝｸ(f4.aaa.livedoor.jp)
のNo.27888がわかりやすく解説してくれてる。
117:デフォルトの名無しさん
08/04/03 02:34:20
>>116
リンク先読んだら、負の数は全部未定義としか読めない。
118:デフォルトの名無しさん
08/04/03 06:56:17
The behavior is undefined if the right operand is negative,
or greater than or equal to the length in bits of promoted left operand.
119:デフォルトの名無しさん
08/04/03 06:57:38
それはシフト数の方の話だった。
120:デフォルトの名無しさん
08/04/04 13:58:33
そろそろビットシフトの質問の出番ですか？
121:デフォルトの名無しさん
08/04/07 21:51:36
C言語をはじめたばかりであまりわからないのですが、
ビットシフトはなんの役に立つのでしょうか？
122:デフォルトの名無しさん
08/04/07 22:33:59
スレ違い
123:デフォルトの名無しさん
08/04/08 03:27:19
規格上未定義になってる処理を書いたら例外吐いて止まるコンパイラきぼう
いちいち覚えるの面倒
124:デフォルトの名無しさん
08/04/08 10:47:47
ベンダーに言え
125:デフォルトの名無しさん
08/04/08 12:31:00
もしさまざまなマシンでどのように実行されるか知らなければ、
知らないということが自分を守る助けとなるかもしれ ない
from K&R
126:デフォルトの名無しさん
08/04/09 00:45:45
例外吐かれるより警告がうれしいな・・・
127:デフォルトの名無しさん
08/04/09 20:48:04
エラーでいいよ。
どうせ警告も０にしてるんだし。
128:デフォルトの名無しさん
08/04/09 22:05:24
俺は信号を見ないけど車は俺をよけて通れよ！
なんて高らかに宣言しなくても・・・
129:デフォルトの名無しさん
08/04/10 17:31:25
エラーでも警告でもアラーとでもいいけど、
そこで止まられるのは、、ちょっとやだな。
130:デフォルトの名無しさん
08/04/10 17:49:13
過疎スレ
131:デフォルトの名無しさん
08/04/10 22:07:09
結構前に、アラーメッセージというのがあったな・・・
132:デフォルトの名無しさん
08/04/10 22:31:01
アッラーアクバル！
133:デフォルトの名無しさん
08/04/23 20:00:31
ｽﾚﾘﾝｸ(tech板:637番)
↑
の件なんですが、こういうことに出くわした場合、
コンパイラはどういう風に振舞わなければならないとなってるのでしょうか？
それとも未定義？
134:デフォルトの名無しさん
08/04/23 20:55:12
>>133
未定義
コンパイラの実装依存です
リンカのオプションでエラーにする設定もおそらくあります
src1.c と src2.c で変数 a の型が違ってたりすると悲惨です
135:デフォルトの名無しさん
08/04/23 21:01:07
C の仮定義ってファイルまたぐと適用外だっけ？
136:デフォルトの名無しさん
08/04/23 22:13:29
>>134
未定義と実装依存は違うし、そもそもコンパイラにとっては正しいソース
なので、
> コンパイラはどういう風に振舞わなければならないとなってるのでしょうか？
普通に振舞うだけ。
大抵の環境ではリンカでエラーになるはず。
(そのスレでは、エラーにならないと言い張ってるが。)
137:デフォルトの名無しさん
08/04/23 22:19:34
>>136
未定義なので実装依存と書けばいいの？
gcc なら警告無し
borland C++ compiler なら警告あり
大抵の環境って何が基準？
138:デフォルトの名無しさん
08/04/23 22:30:12
VC++2008でも警告無しだな
139:デフォルトの名無しさん
08/04/23 22:31:34
みんなあんまり適当な事言うなよ？
>>133
あまり知られていないが、これは 「仮定義（tentative definition）」 という仕様。
extern も static もついていない、初期化を伴わないグローバル変数の宣言は 「仮定義」 と見なされる。
対する、extern も static もついていない、初期化を伴うグローバル変数の宣言は 「外部定義（external definition）」 と見なされる。
外部定義は必ず実体定義を伴う。
外部定義が複数あると、二重定義となりエラーとなる。
しかし、仮定義は他に実体定義がなければ実体を定義し、
他に実体定義があれば実体定義を伴わない単なる宣言と見なされる。
複数の仮定義を書いた場合、実体は１つだけ定義され、それらの仮定義は実体を共有する。
つまり、>>133 は仕様。
140:デフォルトの名無しさん
08/04/23 22:35:35
ちなみにこの仕様は C++ で廃止された。
C++ では仮定義がなくなり、
extern も static もついていない、初期化を伴わないグローバル変数の宣言も
外部定義と見なされ、実体定義を伴う。
このあたりの違いの話は C++ の規格の付録に書いてある。
141:デフォルトの名無しさん
08/04/23 23:14:40
>>137
> 未定義なので実装依存と書けばいいの？
違う。
未定義は何が起っても文句を言うなと言うこと。
(実行したらＰＣが壊れるような実行ファイルを生成しても規格には違反しない。)
実装依存は何が起るかは環境によって違うけど、環境毎に何が起るかは決まってい
ると言うこと。
>>137, >>139-140
すまん、仮定義のことすっかり忘れてた。
142:デフォルトの名無しさん
08/04/23 23:23:02
未定義は規格は挙動を定義しないということで、
何が起こっても規格に反しないということではあるが、
処理系独自に挙動を定義することまでを禁止する物でもない。
もちろん、それに頼ったコードは通常移植性が低い訳だが。
処理系依存は処理系ごとに挙動を定義することが求められている。
未規定は未定義と似ているが、
正常なコードの中で挙動がきちんと定められていないものを言う。
関数の引数に書かれた式の評価順とか。
143:デフォルトの名無しさん
08/04/24 00:20:37
仮定義は初耳でした、勉強になりました
ありがとうございます
144:デフォルトの名無しさん
08/04/24 00:30:36
うげ、仮定義って翻訳単位跨いでも使えるのか。
知らなかった。
145:デフォルトの名無しさん
08/04/24 00:49:31
本当に翻訳定義またいで使えたっけ？
146:デフォルトの名無しさん
08/04/24 01:24:54
規格を見る限り、仮定義があると翻訳単位の一番下に = 0 で初期化された宣言があると見なされるようだ。
複数の翻訳単位がある場合は二重定義になりそう？
147:デフォルトの名無しさん
08/05/05 14:08:05
>>141-142
処理系依存・実装依存は処理系定義(implementation-defined)だけじゃない。
適当なこと言うなよ。
未定義・未規定・処理系定義
どれも処理系の実装に依存してるだろ。
148:デフォルトの名無しさん
08/05/05 14:20:11
処理系定義は実装には依存しないだろ。
149:デフォルトの名無しさん
08/05/05 14:22:21
実装によって挙動が違うことを規格が許している、ことを
実装に依存している、と言うのであって、
処理系定義は実装に依存していると思うが？
150:デフォルトの名無しさん
08/05/05 14:28:03
処理系定義は仕様としての表明であり、実装とは切り離されている。
具体的なモノとは分けて考えるべきだろう。
151:デフォルトの名無しさん
08/05/05 15:08:26
JISでは処理系と訳されてるけどimplementation definedだから「実装」だべ
152:デフォルトの名無しさん
08/05/05 15:18:25
その文脈で
>>147
>どれも処理系の実装に依存してるだろ。
の意味を説明できるのか？
153:デフォルトの名無しさん
08/05/05 15:28:53
>>147 おおむねこんな意味かい?
処理系定義: 動作も結果も保証しないがどうのような振る舞いを示すかは
処理系が保証しなければならない
未規定: 動作の保証はないし処理系の振る舞いによって何が起るかは
不明
未定義: 何が起っても文句は言えない.
処理系自体も振る舞いを規定する必要はない
154:デフォルトの名無しさん
08/05/05 15:31:09
そもそもX3010に～依存って言葉はあるんでしょうか？
155:デフォルトの名無しさん
08/05/05 15:36:43
>>153
未規定：規格が動作を明示することを求めいていない
例）関数の実引数は、どれから評価してもよいし、明示する必要もない。
156:デフォルトの名無しさん
08/05/05 15:37:40
ない。
一部の人間が勝手にimplementation definedと混同してるだけ。
>>136とか>>141とか>>142とか
157:デフォルトの名無しさん
08/05/05 16:07:28
「規格が明確に定義していない」には3種類あって、以下のように定義されている。
・処理系定義（implementation defined）の動作
どう動作するかを実装が選択する。そのプログラムがコンパイルできないというのは許されない。
（この構成概念を使ったプログラムは誤りというわけではない。）
（実装が）何を選んだかは（コンパイラの作者が）文書にしておかなければならない。
規格が合法な動作をいくつか用意していてそこから選ぶことができるかもしれないし、
必要条件をとくに課していないかもしれない。
・未規定（unspecified）の動作
処理系定義の動作に似ている。ただし、どういう動作を選んだかは文書にする必要がない。
・未定義（undefined）の動作
本当に何が起きても不思議はないことを意味する。規格は何の必要条件も課さない。
コンパイルできないかもしれないし、誤った動きをするかもしれないし
（クラッシュしたり黙って誤った結果を出したり）、
あるいはたまたまプログラマの意図したとおりの動きをするかもしれない。
以上、CFAQより抜粋
158:デフォルトの名無しさん
08/05/05 17:52:27
もうメタ議論くらいしかすることないのな
159:デフォルトの名無しさん
08/05/05 21:08:20
うん。
160:デフォルトの名無しさん
08/05/06 01:46:45
>154 >156
ただ、CFAQには「実装依存」を「処理系定義の動作」という意味で使っている場所がある。
正確ではないが、その言葉に出くわして意味を解釈する必要があるときは、そのように読むのが一般的であるかもしれない。
161:デフォルトの名無しさん
08/05/06 05:08:14
それはimplementation definedの正確でない訳だったりしないの?
162:>>136
08/05/06 11:07:05
一般的な機論において、特に混乱するわけでもないから「～依存」って
書いてるだけ。後出しで X3010 出してきて混同してるとか言われても、
「また KY 君かよ」としか思えない。
163:デフォルトの名無しさん
08/05/06 11:13:34
>>161
当たったところ、原文では implementation-defined と書いてあった。
ただそもそも日本語で実装依存といった場合におおよそ何を意味するかという話であるので
（だから正確でないのは承知の上であることは書いた）。
164:デフォルトの名無しさん
08/05/06 22:59:28
つまり
「実装依存」は場面によって指している物が違うから
implementation definedの訳としては使わないほうがよい。
ということだな。
165:デフォルトの名無しさん
08/05/07 00:01:21
implementationは普通に訳せば実装という意味だから処理系定義という訳もアレかもしれんがな
「実装依存」そのまんまの意味であるimplementation-dependentはかなり広く使われてるようだが特定の言語に限った話じゃないしね
166:デフォルトの名無しさん
08/05/07 01:26:51
一般の議論ではよく使われる「依存」だが、このスレでは非推奨の
用語ということにしたほうがよさそうだな。
このスレでは直訳した「実装定義」か、JIS用語の「処理系定義」、
「未規定」、「未定義」を使い分けるということで。
167:デフォルトの名無しさん
08/05/16 13:13:18
C++ が存在するのに新しい C 言語の仕様を策定するのは、C++ のコンパイラは
実装が難しいからですか?
168:デフォルトの名無しさん
08/05/16 13:32:46
C++はCの上位集合ではありませんが？
169:デフォルトの名無しさん
08/05/16 15:05:56
上位集合ではないが、ほとんどの場合ソースを変更する必要がないか、
少し変えれば両方で動くようになる。
C99 のように C++ との互換性に問題を作ってまで新しい仕様を作る
必要はないんじゃないか?
170:デフォルトの名無しさん
08/05/16 15:49:33
C++なんかどうでもよくね
171:デフォルトの名無しさん
08/05/16 20:03:05
C99なんて誰も必要としていない
172:デフォルトの名無しさん
08/05/16 23:16:34
inlineとか変数宣言のブロック先頭縛り廃止とかのC++追随と
vsnprintfにlong longなど有名どころの独自拡張の追認だけにしておけば、
もう少し広まった気がする。
173:デフォルトの名無しさん
08/05/16 23:21:10
Bjarne 先生に相談しないで仕様を決めてしまったのかな。
174:デフォルトの名無しさん
08/05/17 00:14:23
スレ違い
175:デフォルトの名無しさん
08/05/17 09:22:23
構造体の宣言と同時に初期化は有用
176:デフォルトの名無しさん
08/05/17 09:27:21
C++も0xで対応するんじゃなかったっけ
initializer_listとか
177:デフォルトの名無しさん
08/05/17 11:17:20
いちいち構造体のタグ名の前に struct を付けないといけないのは面倒くさい。
typedef しなくてもタグ名をそのまま型名として使えるようにしてほしい。
178:デフォルトの名無しさん
08/05/17 12:01:17
C++でもつかっとけ
179:デフォルトの名無しさん
08/05/17 13:19:14
コンストラクタはいらないがデストラクタが欲しい。
180:デフォルトの名無しさん
08/05/17 17:11:10
typedef すればいいから正直あまり困らないな ＞struct
181:デフォルトの名無しさん
08/05/17 23:03:42
自分へのポインタを持つ構造体宣言するときにちょっと書くワードが多いくらいだろう
大した問題じゃない
というか自分はC++でも typedef struct … しちゃうな、なんとなく気持ち悪くて
182:デフォルトの名無しさん
08/05/18 01:22:06
自分へのポインタを持つ構造体も、事前に typedef しとけば・・・
って、その typedef を書く必要があるから結局は面倒なんだが。
183:デフォルトの名無しさん
08/05/18 03:02:46
Cでstruct tagを自動でtypedefしないのは、名前空間の問題にひっかかるからかな？
184:デフォルトの名無しさん
08/05/18 03:08:40
特に理由はなかったんだろう。
何となく struct を付けた方がいいんじゃね？ と思って仕様を作った。
でも、実際には面倒臭かったので C++ では必須ではなくなった。
それだけのことなんだろう。
185:デフォルトの名無しさん
08/05/18 03:24:45
名前空間は、新規格で導入しない理由のひとつではあると思う。
構造体（共用体）タグが「通常の識別子」として扱われる改定がされた場合でも、
逆に従来の構造体タグ名前空間のままでtypedefされる改定となった場合でも、
もし過去にそうならないことに因って書かれたコードがあったらコンパイルできなくなる。
どちらでもない新しい名前空間を作るにしても、旧来のコンパイラを改良する手間は
名前空間の管理に手を入れる関係上、それなりの手間が必要になる。
そこまでして導入するほどの問題では絶対にない。と思う。気がする。
186:デフォルトの名無しさん
08/05/18 04:01:36
structってつけてくれた方が構文解析が楽だから、とかはさすがにないか。
187:デフォルトの名無しさん
08/05/18 11:01:15
多分そうだと思う。
変数がブロックの先頭でしか宣言できないのも抽象構文木の構造に自然に合うからだと思う。
現在の C から派生した言語はほとんどこういう制限はない。
188:デフォルトの名無しさん
08/05/18 11:37:50
昔はマシンが非力だったから
少しでも楽にしたかったのかもしれないね。
189:デフォルトの名無しさん
08/05/18 12:12:20
配列の境界検査をしない、という仕様がまさにそれ
190:デフォルトの名無しさん
08/05/18 12:13:10
しないと言い切るとこのスレ的には間違ってるか
境界検査をしなくてもよい、だな
191:デフォルトの名無しさん
08/05/18 12:41:11
C++ の std::vector も境界チェックを行う at と行わない operator[] を用意してるから
非力だったからやらない、というわけではないと思われ。
192:デフォルトの名無しさん
08/05/18 12:44:49
安全と効率を天秤に掛けて、効率を取る漢らしい言語なんです
193:デフォルトの名無しさん
08/05/18 12:46:03
[]で境界チェックしないのはCとの互換性のためだろ
未定義動作に互換性もへったくれもない気がするけど
194:デフォルトの名無しさん
08/05/18 12:46:22
可能な限り、安全は言語でサポートするものではなく
ライブラリでサポートするべき、って感じだな。
最大限の効率を約束する。
195:デフォルトの名無しさん
08/05/18 12:46:57
>>193
std::vector は C にないから
互換性なんてどうでもいいと思われるが。
196:デフォルトの名無しさん
08/05/18 13:10:54
VRAM直書きの時、境界検査されたらちょっとヤだな。
197:デフォルトの名無しさん
08/05/18 13:26:26
論理エラーまでチェックしていたら OS なんて書ける性能はでないよ。
198:デフォルトの名無しさん
08/05/18 15:06:53
>>195
メモリ配置の連続性要求はCとの互換性のため
199:デフォルトの名無しさん
08/05/18 15:08:34
>>198
連続性要求と境界チェックは別の話だっしょ。
200:デフォルトの名無しさん
08/05/18 15:30:03
境界チェックしてほしいなら /RTCs を付ければいいよ。VC 以外は知らない。
201:デフォルトの名無しさん
08/05/18 16:06:54
>>199
連続性要求と境界チェックは同じだとは言っていない。
「互換性なんてどうでもいい」なら連続性要求も必要ないはずだと言いたいだけ
202:デフォルトの名無しさん
08/05/18 16:12:50
俺のカンでは話がかみあってないな
203:>>136
08/05/18 16:13:31
>>196
VRAM サイズの配列を宣言して、VRAM のアドレスにマップできるようにすればいいだけ。
>>197
いつの時代だよ。
爺は早めに引退しとけ。
204:デフォルトの名無しさん
08/05/18 16:14:08
>>201
普通の配列の話じゃなくて std::vector の話なんだけどな。
普通の配列に関しては互換性も理由の１つだろう（それだけじゃないとは思うが）。
205:デフォルトの名無しさん
08/05/18 16:14:46
>>203
そうやってどんどん OS を重くしてるから
Vista みたいに叩かれるんだよ
206:デフォルトの名無しさん
08/05/18 16:33:09
>>204
配列じゃなくてstd::vectorに連続性要求があるんだけど
207:デフォルトの名無しさん
08/05/18 16:52:19
まぁ「レガシーAPIにstd::vector渡せますか？」
というのはC++のFAQだよな
次の規格ではstd::stringもそうなるんだっけ
208:デフォルトの名無しさん
08/05/18 16:57:42
std::string::c_str() があるのにそんな必要あるの?
209:デフォルトの名無しさん
08/05/18 17:07:54
現在のc_strはコピーが発生する可能性があってパフォーマンスに響くかもしれない。
210:デフォルトの名無しさん
08/05/18 17:10:49
どう考えても>193がおかしい
Cにはvectorが存在しないのだから互換性が問題になるはずがない
211:デフォルトの名無しさん
08/05/18 17:12:25
Cで書かれたライブラリとのバイナリ互換性とか
212:デフォルトの名無しさん
08/05/18 17:50:29
>>206
だから連続性要求の話なんて誰もやってないんだってば・・・。
境界チェックの話だ。
213:デフォルトの名無しさん
08/05/18 17:53:11
そもそもだなぁ
なんで std::string::c_str() な話がこのスレで出てくる？
214:デフォルトの名無しさん
08/05/18 18:11:46
もし境界チェックを行う必要が無いという仕様が
大昔はマシンパワーが弱かったからという問題で作られたのなら
C++ を作る時に std::vector で at でも operator[] でも境界チェックをすれば良かった。
でもそうしなかったということは、それだけの問題じゃないってことだろう。
という話。
215:デフォルトの名無しさん
08/05/18 18:16:35
だからCもC++も基本的に効率側に仕様を倒すんだよ
安全性はライブラリで頑張る方針
216:デフォルトの名無しさん
08/05/18 18:22:08
そういうこと。
昔マシンパワーが弱かったからじゃなくて、
マシンパワーに関わらず効率を取るってこった。
217:デフォルトの名無しさん
08/05/18 18:31:08
マシンパワーが高くなっても 10 分かかっている処理は速い言語で 5 分にしたいよ。
アプリにもよるけど。
218:デフォルトの名無しさん
08/05/18 18:32:57
>>215
> 効率側に仕様を倒す
ちゃう, 特に C に関しては高級言語だと思ってはいけない
freestanding な環境でも動作可能, つか, 標準ライブラリを使用せず
(libgcc とかは微妙だけど)に動作可能なバイナリを吐き出せる事も
求められている.
実際 crt.o を自前で書けば, 標準ライブラリを使わずに実行イメージを
作ることが可能(しつこいけど libgcc とかは微妙)
境界チェックに関しては微妙だけど...
219:デフォルトの名無しさん
08/05/18 18:34:22
>>212
だから境界チェックしてない理由(の1つ)に連続性要求と同じ理由は考えられないのかと
言ってるだけなんだが。
std::vectorがCにないから互換性の問題がないなら
operator[]で境界チェックをやることだって互換性の問題を起こさない
220:デフォルトの名無しさん
08/05/18 18:39:34
>>219
連続性要求は C++98 ではなく C++03 で導入された。
221:デフォルトの名無しさん
08/05/18 19:19:52
>>203
世の中Cで書いたプログラムのターゲットは3GHzクラスばかりじゃないんだよ。
222:デフォルトの名無しさん
08/05/18 19:37:35
>193は自分のレスをもう一回冷静に読み直せ
>191はvectorの境界チェックのみの話しかしていない
だからそもそも互換性や連続性の話は関係ない
お前が勝手にoperator[]全般の話を持ち出したから話がかみ合ってないだけだ
223:デフォルトの名無しさん
08/05/18 19:43:16
これは俺のカンだけど
>>193はoperator[]はあらゆるオブジェクトで同じもんだと思ってるね
でなきゃ互換性なんてセリフ出るはずがない
224:デフォルトの名無しさん
08/05/18 19:48:39
>>219
vectorの連続性要求の理由はそのほうが直感的かつ便利だからであってCとの互換性からではない。
なぜならvectorはCに存在しないから。C++にしか存在しないものがCとC++の間での互換性で問題になる は ず が な い 。
225:デフォルトの名無しさん
08/05/18 19:50:43
>>224 だったらスレタイ読んで出直してこい
226:デフォルトの名無しさん
08/05/18 19:53:11
>>225
お前はレスの流れを読むべきだな
227:デフォルトの名無しさん
08/05/18 21:48:21
>>221
で、それがどうかしたのか？
非常にタイトな部分には、チェックをはずせるようにしとけばいいだけだろ。
しょぼい環境の奴は、頭もしょぼいのか？ (w
228:デフォルトの名無しさん
08/05/18 21:52:24
仕様と処理系の区別もつかないくらい耄碌してるのか。
229:デフォルトの名無しさん
08/05/18 23:26:28
「ディフォルトは検査するが、指定した部分の検査をしなくてもいいように指示できる」
と言う言語仕様にすればいいだけ。
どこに処理系の話が出てくるんだ？
# 耄碌爺って他人を耄碌してると思いたがるよな。(w
230:デフォルトの名無しさん
08/05/18 23:33:09
C言語の仕様は
「チェックなんて効率の悪い事はデフォルトではしない。検査は各々自己責任でやれ」
というスタンスなんだよ
231:デフォルトの名無しさん
08/05/19 00:14:36
耄碌してんじゃなくて若くて無知なだけだったか。
232:デフォルトの名無しさん
08/05/19 00:21:52
>>230-231
はぁ？ いまごろ何言ってんの？
そんなこと >>192 に書いてある。
耄碌爺はちょっと前のレスすら覚えてないらしいな。
病院に行った方がいいぞ。
233:デフォルトの名無しさん
08/05/19 01:14:18
話の整理
197 「Cぐらい男らしい言語じゃないとOSなんて組めないよねー」
↑ 偏見というほどでもないがたぶん誇張
203 「そんなことはない、今のマシンのスペックなら（他の言語でも）十分いけるよ」
↑ 正しいとは言い切れないが間違いではない
221 「そんな高スペックの環境ばかりじゃないんだよ」
↑ ここがずれてる 203はそんな環境でCでない（チェックの厳しい）言語を使えとは言ってない
227 「低スペックな環境なら（その言語の機能で）チェック外すようにできればいいだろ」
↑ まあ正論
230 「Cはそういう言語じゃないんだよ」
↑ Cでない言語の話をCの話と勘違いしている
というわけで話の理は203にある
だが煽るのはやめろ
234:デフォルトの名無しさん
08/05/19 02:40:18
自演乙、と言えばいいのか？
235:デフォルトの名無しさん
08/05/19 05:16:42
すっかり違う言語にかわっちゃうような機能を、オプションでつけはずし？
配列とポインタが交換可能なのはC言語の特徴ですよ。
ポインタが配列を指してるかどうかのチェックからするんですか？
236:デフォルトの名無しさん
08/05/19 05:47:52
ああ、そうか、>>203は最初からC言語の話なんかしてないのか。
>>233 解説ありがとう。
ということで、スレ違いだな。
237:デフォルトの名無しさん
08/05/19 12:44:06
C言語は最適化のヒントを与える機能を追加すれば後は拡張しなくていいよ。
C言語の役割はある程度ポータビリティーがあって可能な限り性能を出すこと。
どんなに CPU の性能が上がってもこの需要はなくならない。
238:デフォルトの名無しさん
08/05/19 15:40:22
できることが増えるスピードよりやりたいことが増えるほうが速いからな
239:デフォルトの名無しさん
08/05/19 22:33:30
>>235
相変わらず、頭固いネェ。
> 配列とポインタが交換可能なのはC言語の特徴ですよ。
未だに配列アクセスよりポインタアクセスの方が常に速いとか
思ってるんだろうな...。
240:デフォルトの名無しさん
08/05/20 06:08:38
頭の固い人間 VS 論点がズレている人間
の対決はいつ見ても不毛
241:デフォルトの名無しさん
08/05/20 10:01:59
>>239
君の脳内言語の話はスレ違いだ。
242:デフォルトの名無しさん
08/05/20 22:05:48
C言語をはじめたばかりであまりわからないのですが、
ビットシフトはなんの役に立つのでしょうか？
243:デフォルトの名無しさん
08/05/20 22:23:18
>>242
それなんてコピペ？
こんな感じでよろしいか？
244:デフォルトの名無しさん
08/05/20 22:27:14
おｋ
245:デフォルトの名無しさん
08/05/21 00:41:16
>>241
反論できなくなったら、脳内言語ときたか。
だったら、>>221 あたりでそう書きゃいいと思うが、
しょせん耄碌爺には無理か。(w
246:デフォルトの名無しさん
08/05/21 01:18:38
煽るな
247:デフォルトの名無しさん
08/05/21 01:38:16
>>245
>>233 >>236
248:デフォルトの名無しさん
08/05/21 10:51:11
>>245
つまりこういう事だな。
「脳内言語だって気が付くのが遅せーんだｙｐ」
249:デフォルトの名無しさん
08/05/21 23:45:16
昔の知識で煽ったら、反撃くらって撃沈しただけだろ。
250:デフォルトの名無しさん
08/05/22 01:22:46
俺言語の話なんかする奴が悪いな
251:デフォルトの名無しさん
08/05/22 04:36:43
俺言語君の知識は、最近のCPUは速いって事だけだったからな。
反論する余地は無いな、たしかに。
252:デフォルトの名無しさん
08/05/22 07:42:58
お前らも煽るな
253:デフォルトの名無しさん
08/05/22 10:44:54
大勢のフリした一人だろ。煽っているのは。
254:デフォルトの名無しさん
08/05/22 11:51:11
おやそくの一言が出ました。
255:デフォルトの名無しさん
08/05/22 11:55:57
お夜食？
256:デフォルトの名無しさん
08/05/22 12:18:30
↓ タイプミスをプギャーして勝ち誇るAAをどーぞ
257:デフォルトの名無しさん
08/05/22 12:19:49
m9（＾д＾）
258:デフォルトの名無しさん
08/05/22 17:41:00
ぐぐってもプギャーの意味分からなかった。
259:デフォルトの名無しさん
08/05/22 22:44:05
> 俺言語君の知識は、最近のCPUは速いって事だけだったからな。
> 反論する余地は無いな、たしかに。
にもかかわらず反論してた爺は哀れだな。(w
260:デフォルトの名無しさん
08/05/23 05:38:05
いつまでも爺爺言ってる奴が根に持ちすぎてて怖い
将来犯罪起こしそうだな
261:デフォルトの名無しさん
08/05/23 07:38:27
脳内言語だと解ってからは、だれも反論なんかしちゃいないのにな。
262:デフォルトの名無しさん
08/05/23 23:57:40
>>261
> 脳内言語だと解ってからは、だれも反論なんかしちゃいないのにな。
>> 反論してた
爺は日本語も不自由らしい。(w
263:デフォルトの名無しさん
08/05/24 01:01:27
俺言語の話してるのに、C言語の話だと思って反論してやんのプギャー
こうですね、よくわかります。
264:デフォルトの名無しさん
08/05/24 01:50:10
ひっかかった、くやしいムキー。
こうですね、よくわかります。
265:デフォルトの名無しさん
08/05/24 02:09:10
いつまでやってんの！
266:デフォルトの名無しさん
08/05/24 02:26:07
ケンカはやめて（＞＜）
267:デフォルトの名無しさん
08/05/24 11:46:20
爺で検索すればいいからわかりやすいな
268:デフォルトの名無しさん
08/05/24 17:49:54
C89 との違いのみを完全に全て列挙したような資料ってありますか？
269:デフォルトの名無しさん
08/05/24 17:51:43
C89 と C99 との違い・・・です。
270:デフォルトの名無しさん
08/05/24 18:03:32
完全かどうかは知らないけど
URLﾘﾝｸ(seclan.dll.jp)
とか
271:デフォルトの名無しさん
08/05/26 17:40:59
!0の値は1ですか？不定ですか？
272:デフォルトの名無しさん
08/05/26 17:42:57
1です
273:デフォルトの名無しさん
08/05/26 17:49:09
ありがとう
274:デフォルトの名無しさん
08/05/26 19:06:31
>>270
結構詳しいですが、完全なんですかね・・・。
何か漏れがあるとかいう話はないんでしょうか。
275:デフォルトの名無しさん
08/05/28 22:52:00
究極的にはC99の規格票買ってきて突き合わせるしかないだろ
276:デフォルトの名無しさん
08/06/01 12:22:33
意味情報を利用しても、C (C89) の文法はLALR(2)ではないかという
疑問がありますので質問です。
構文規則はK&Rのものしか参照できないので、もしかしたら仕様書の
ものと違うかもしれないのですが、
compound-statement:
{ declaration-list_opt statement-list_opt }
という構文規則で、
int foo;
typedef int foo; /* 型名とグローバル変数の名前空間は独立 */
void bar(void)
{
foo ?? /* ?? を読むまで、fooは宣言の一部であるとしてシフトするか、
文の一部であるとして、宣言を空にリダイレクションするか、決められない */
と思うのですが、間違いがどこかにありますでしょうか？
277:デフォルトの名無しさん
08/06/01 12:30:47
>型名とグローバル変数の名前空間は独立
この仮定が間違ってる。
278:デフォルトの名無しさん
08/06/01 12:57:24
型名も変数名も全て「一般の識別子」だよ
違うのは構造体タグだろ
279:デフォルトの名無しさん
08/06/01 15:10:44
識別子と言うことと、名前空間の管理は全然別の話だよ。
280:デフォルトの名無しさん
08/06/01 16:14:06
Cの名前空間は4種類。
・ラベル
・タグ
・メンバ
・その他すべて（typedefした型名や一般の変数の名前を含む）
つまり二つのfooは同じ名前空間を持つ。
これを同じスコープ（この場合ファイルスコープ）で使ったら当然衝突する。
スコープが異なるなら識別子の優先順位と隠蔽によってまったく問題なく処理できる。
281:デフォルトの名無しさん
08/06/01 17:07:45
Ｃ言語 名前空間 でググルとほとんどどんぴしゃの内容が...
URLﾘﾝｸ(uyota.asablo.jp)
282:デフォルトの名無しさん
08/06/01 17:11:45
>>281
まちがってるなぁ
そこでa a;が許されるのはスコープが違うからであって名前空間が違うからじゃない
283:デフォルトの名無しさん
08/06/01 20:47:48
グローバルな型名はローカル変数名でシャドウされる？
284:デフォルトの名無しさん
08/06/01 21:40:28
されるよ。
285:284
08/06/01 21:43:56
たとえば、
typedef int a;
a main(){
a a;
a b; // error
return 0;
}
286:デフォルトの名無しさん
08/06/02 05:48:23
型を宣言するとき
defineではなくtypedefを使わないといけない明確な理由って
なんですか？
今まで普通に使ってきたけど、新人にどう説明すればいいか
悩んでいます。
287:デフォルトの名無しさん
08/06/02 06:04:08
>>286
typedef char * pchar;
pchar a, b;
sizeof(b)=?
#define pchar char *
pchar a, b;
sizeof(b)=?
288:デフォルトの名無しさん
08/06/02 06:38:47
>>286
あと、たとえば型size_tを要求する関数があったとして、
#define size_t int
とかやると、size_tの変数を渡してもintで宣言した変数渡しても、コンパイラには区別がつかない。
289:デフォルトの名無しさん
08/06/02 07:12:47
>>286
typedef char *pchar;
const pchar a; → a が const
#define pchar char *
const pchar a; → *a が const
主にポインタ関連で困ったことになる。
290:デフォルトの名無しさん
08/06/02 13:46:28
>>288
もともとCのtypedefは弱いtypedefだから区別ないけどね
291:デフォルトの名無しさん
08/06/02 13:48:33
>>286
関数ポインタ形とか配列型だと、構文の都合上で#defineではできないってのもあるね。
292:デフォルトの名無しさん
08/06/02 21:08:43
defineじゃデバッグ時にこまるじゃん
293:デフォルトの名無しさん
08/06/02 23:22:48
typedefにはスコープがある。
defineには無い。
294:デフォルトの名無しさん
08/06/03 21:24:03
typedefにはスープがある。
defineには無い。
295:デフォルトの名無しさん
08/06/04 01:19:44
define には名前空間がない。
296:デフォルトの名無しさん
08/06/04 07:28:02
typedefにも名前空間はない
297:デフォルトの名無しさん
08/06/04 07:44:55
我輩には名前がない。
298:デフォルトの名無しさん
08/06/04 10:16:06
うちの女房にゃひげがある
299:デフォルトの名無しさん
08/06/04 17:02:02
さぁみんな、微妙に勘違いする仕事に戻るんだ！
300:デフォルトの名無しさん
08/06/04 21:50:30
C言語をはじめたばかりであまりわからないのですが、
ビットシフトはなんの役に立つのでしょうか？
こうですね、わかります
301:デフォルトの名無しさん
08/06/05 21:54:55
全てのビットが0のポインタを得るにはどうすればいいでしょうか。
次のようなのを考えましたがなんかイマイチ。
void *p;
p = (void*)(1-1);
p = (void*)!1;
p = (char*)1-1;
memset(&p, 0, sizeof p);
302:デフォルトの名無しさん
08/06/05 22:00:00
この中では memset(&p, 0, sizeof p); が最も確実。
上の2つはもしかしたら上手くいかないかもしれない。
3つ目は明らかに間違い。
303:デフォルトの名無しさん
08/06/05 22:21:41
いや、3つ目もいいんじゃないか？
304:デフォルトの名無しさん
08/06/05 22:27:52
一番下以外は未定義動作
305:デフォルトの名無しさん
08/06/05 23:23:38
こういうのは？
p = (void*)(int)0;
306:デフォルトの名無しさん
08/06/05 23:27:42
整数をポインタにキャストした場合の動作は定義されない。
307:デフォルトの名無しさん
08/06/05 23:58:57
>>306 んなこたーない。
308:デフォルトの名無しさん
08/06/06 00:40:19
ポインタ型は、(何らかの)整数型と情報を失わずに相互変換できる。
309:デフォルトの名無しさん
08/06/06 00:41:02
別に0というリテラルがヌルポインタとして使えると定義されてるわけじゃないぞ。
コンパイル時に0になると決定できる定数式は全部ヌルポインタとして使える。
だから
p = (void*)(1-1);
p = (void*)!1;
はヌルポインタ。
310:デフォルトの名無しさん
08/06/06 11:28:03
>>309
だから、NULLポインタは全ビット0とは限らない、って話だろうが
311:デフォルトの名無しさん
08/06/06 11:38:15
だから上二つは上手くいく保証がないってことだろ
312:デフォルトの名無しさん
08/06/06 20:05:28
上3つでねーの
313:デフォルトの名無しさん
08/06/06 22:02:13
memset() の第2引数が定数の0だと本当にビットパターンが0になるの?
bzero() がもともとそういう仕様だから確実じゃない?
314:デフォルトの名無しさん
08/06/06 22:09:41
>>313
もちろん。関数の引数は常に値渡しだ。
ということは memset() が受け取った値0は必ず変数に代入されて処理される。
変数0がヌルポインタに変換されることは絶対にない。
315:デフォルトの名無しさん
08/06/06 22:25:46
> void *memset(void *s, int c, size_t n);
> memset() は s で示されるメモリ領域の先頭から n バイトを c で埋める。
man にはこれくらいしか書いていないけど、c が int だと意味が分かりにくい。
一旦 c が char に変換されてから n バイト書き込むということか?
316:デフォルトの名無しさん
08/06/06 22:42:53
1の補数表現を許しているから
"0"が"+0"や"-0"という場合があって
それで(charにして)埋めた場合にどうか、という話だろうな。
俺は知らん。
317:デフォルトの名無しさん
08/06/06 23:38:36
>>316
考えにくいけど、もし通常の定数0が-0だったとしても、
ヌル文字が全ビットゼロであることが保証されているから、
少なくとも文字定数\0は全ビット0のはずだね
というわけでmemsetでゼロクリアするときは\0を使おう
318:デフォルトの名無しさん
08/06/06 23:43:20
なんでわざわざ難しく考えるんだ？
実際、仕事でプログラムを作るときは仕様などを考えることに
時間を割くのに、お前達はコーディングに時間を割きそうだな。
319:デフォルトの名無しさん
08/06/06 23:48:20
プログラム板で仕様を語ってどうするよ
ここはガチ規格スレだぜ
320:デフォルトの名無しさん
08/06/07 00:54:09
糞仕様書のせいでコーディングに時間を割かなければいけないことならよくあります。
321:デフォルトの名無しさん
08/06/07 13:04:29
>>311
違う。
上手くいかない保証があるってことだ。
322:デフォルトの名無しさん
08/06/07 13:06:28
>>317
通常の整数定数0の全ビットが0であることも保証されていると記憶しているが。
323:デフォルトの名無しさん
08/06/07 13:11:35
定数の全ビットが0でもメモリに記憶されたときもそうなるの?
324:デフォルトの名無しさん
08/06/07 14:10:15
>>321
上手くいかない保証って...、なんだそりゃ。
325:デフォルトの名無しさん
08/06/07 17:28:14
>>323
ならなかったらビット演算で死ねるだろ
326:デフォルトの名無しさん
08/06/07 18:22:05
メモリ上でどうなっていても演算の結果が正しければいいんだよ。
327:デフォルトの名無しさん
08/06/07 21:29:54
C で言う所のメモリ上のビット配列ってのは
整数型の変数でビット演算によって参照できる値だっしょ。
328:デフォルトの名無しさん
08/06/08 14:47:38
C89で、名前は同じで引数の有無や個数が異なるマクロを複数定義することって認められてたっけ？
つまり、
#define A 0
#define A(x) x
329:デフォルトの名無しさん
08/06/08 14:52:31
前スレで話が出て、できるってことだったような
330:デフォルトの名無しさん
08/06/08 15:12:28
gcc でエラーになるけど。
331:デフォルトの名無しさん
08/06/08 15:14:47
>>329
情報㌧
前スレ見てきたところ、同じ名前のマクロを同時に複数定義することはできないと書いてあったわ。
332:デフォルトの名無しさん
08/06/08 15:53:16
>>331
ごめん完璧まちがって記憶してたわ
333:デフォルトの名無しさん
08/06/08 16:17:14
ここにいる人って、アプリ屋？それともファーム屋？
なんか、話だけを見ると、アプリ屋のほうが多いような気が・・・
334:デフォルトの名無しさん
08/06/08 16:20:07
>>333 その区別に何の意味がある？区別のしかたもよくわからんしな。
335:デフォルトの名無しさん
08/06/08 17:53:26
まるでファーム屋が多くて然るべきだと言いたげに読めるのは、俺の日本語力が弱いせいですか？
336:デフォルトの名無しさん
08/06/08 18:12:04
スレ違いだと思う
337:デフォルトの名無しさん
08/06/08 19:18:53
ファーム屋(笑)
338:デフォルトの名無しさん
08/06/08 19:21:21
マ板でやれ
339:デフォルトの名無しさん
08/06/08 19:42:49
俺はいわゆるファーム屋だが、
アプリ屋＞＞＞＞＞ファーム屋
という印象がある。
はっきりいって、組込みソフト開発者はC言語と少しのハードウェア知識があれば、
あとは、仕様理解で仕事ができる。
様々な新しい技術を吸収し、開発しているアプリ屋のほうが技術は高い。
340:デフォルトの名無しさん
08/06/08 20:34:39
組み込み系のスレあたりを見てる印象だと、
組み込み屋には実装至上主義で、仕様ナニソレ、という雰囲気がある。
このスレにいるのは、なんちゃってであっても自分で処理系を書いたり
したことがあるような、アプリよりはシステム寄りの人が多いんでは？
341:デフォルトの名無しさん
08/06/08 21:19:06
そりゃ偏見だ。
アプリ屋だろうがファーム屋だろうが底辺を見ればやっぱり底辺。
上をみればちゃんとしたひとも居る。
ただ、ちゃんとしたアプリ屋がシステム方面に行ってしまうのと同様に
ちゃんとしたファーム屋はハードに行っちゃう事が多い。
342:デフォルトの名無しさん
08/06/08 21:33:49
最近組み込みは年々ハードが高性能化、開発サイクルの短期化で、
少人数の職人的な開発者での開発は限界に来てますよ
これからはアプリに近い開発方法論でやっていこうという欧米の流れ
343:デフォルトの名無しさん
08/06/08 22:49:36
>>339
> 様々な新しい技術を吸収し、開発しているアプリ屋のほうが技術は高い。
新しい技術って Ajax とか Web 2.0 とかのこと？
まあ、そう言う新しい言葉を理解するのも技術力のひとつではあるが。
344:デフォルトの名無しさん
08/06/08 23:12:15
…(^^;;
345:デフォルトの名無しさん
08/06/08 23:54:00
>様々な新しい技術を吸収し、
訳：新しくリリースされたアプリの使い方を覚えて、
346:デフォルトの名無しさん
08/07/02 21:38:00
アプリ屋の俺から言わせてもらえば、
アプリ屋→頭ゆるゆるで使えない奴が多い
ファーム屋→頭かたすぎて使えない奴が多い
347:デフォルトの名無しさん
08/07/02 22:09:04
自称技術者の93.2%は使えないから、そんなもんｈだろう。
348:デフォルトの名無しさん
08/08/06 14:15:43
int a = 3; { int a = a; printf( "%d", a ); }
このとき表示される数字は 3 ですか？それとも不定ですか？
JIS X 3010-1993 を少し読んだんですが分かりませんでした。
349:デフォルトの名無しさん
08/08/06 14:22:43
>>348
規格を見ずに gcc でテストしてみたところ
2147344384
と出力された
350:デフォルトの名無しさん
08/08/06 14:47:43
>>349
規格的には不定だよ. {} の中では新たなスコープが有効になるので
{} 内の a が 宣言された瞬間に {} 外の a は shadow される
# 言い方が厳密じゃないんだけど、言いたいこと分かってね
Lisp 系言語の
(let ((a 3)) (let ((a a)) (???? a))) ==> (let ((a 3)) (lambda (a) (??? a)) a)
みたいな物を, 求めてはいけない
351:349 (>>348 じゃないよ)
08/08/06 14:56:08
>>350
こういうのはOKですか？
int a = 3; { int b = a; int a = b; printf( "a=%d b=%d", a, b ); }
352:デフォルトの名無しさん
08/08/06 15:01:52
>>351 いや、だから…
言い方が悪かったのかorz
{} 外の名前が {} 内で宣言されたら shadow される
処理系によっては「{} 外の a」が意味をなす場合もあるかも知れないが
可搬なプログラムを書こうと思ったら、その事実に依存してはならない
353:349
08/08/06 15:07:08
>>352
規格では変数の宣言順序に関係なく
同一スコープ内で同名の変数が現れた場合には
外側の変数は見えなくなる
だから >>351 は次のようにしないと動作の保証ができないということですね
int a = 3; { int b = a; { int a = b; printf( "a=%d b=%d", a, b ); } }
354:デフォルトの名無しさん
08/08/06 16:13:40
JIS X 3010-1993 には以下のように書いてあるけどこれからは判断できなかった。
6.1.2.1 識別子の有効範囲
識別子は、有効範囲(scope)と呼ぶプログラムテキストの範囲にあるときだけ、可視(visible)
(すなわち、使用可能)とする。有効範囲は、関数、ファイル、ブロック、及び関数原型の4種類とする。
識別子を宣言する宣言子又は型指定子がブロック内又は関数定義の仮引数宣言子の並びに現れる場合、
その識別子はブロック有効範囲(block scope)をもち、その範囲は対応するブロックを閉じる}によって
終了する。
字句的に同一な識別子のより外側の宣言が同一の名前空間にある場合、外側の宣言は現在の
有効範囲が終了するまで不可視となり、その後再び可視となる。
二つの識別子は、有効範囲が同じ場所で終わる場合、そしてその場合に限り同じ有効範囲を持つ。
355:デフォルトの名無しさん
08/08/06 16:48:27
そうか？
はっきり書いてあると思うんだが。
356:349
08/08/06 23:17:37
>>354 を読んで解釈のひとつとして
int a, *p=&a; // これは OK
int *q=&b, b; // これは NG
ということは有効範囲とは変数の宣言順序によって変化するのではないか？
>>351 の int b=a; の時点ではブロック内で変数 a が未定義であるため
外側の a が可視だから動作が保障されるのでは？
357:デフォルトの名無しさん
08/08/06 23:58:57
いや、shadowされているが未定義である状態。
358:349
08/08/07 00:23:41
>>357
>>354 のこの部分
＞識別子を宣言する宣言子又は型指定子がブロック内又は関数定義の仮引数宣言子の並びに現れる場合、
＞その識別子はブロック有効範囲(block scope)をもち、その範囲は対応するブロックを閉じる}によって
＞終了する。
これは有効範囲の終わりについてのみ言及しており、
変数自体は変数宣言以降から有効になるのではないの？
359:デフォルトの名無しさん
08/08/07 00:29:19
だからそういっているんだが。
360:349
08/08/07 00:52:52
shadow されるのは
１．同一変数名の定義されているブロックの開始部分からなのか
２．それとも同一変数名が宣言された後なのか
というところで ２ で解釈可能では？
ちなみに下記のコードで gcc および Borland C++ Compiler では、警告も無し
// 出力結果は a=2.000000 *p=3 が保障される？
#include<stdio.h>
int main(){
int a=3;
{
int *p=&a;
double a=2.0;
printf("a=%f *p=%d\n", a, *p);
}
return 0;
}
361:349
08/08/07 01:15:04
>>360 の
int *p=&a;
の行が規格としては
１．エラーになるべきか
２．未定義（実装依存、鼻から悪魔）か
が知りたいのですが
>>357 さんは ２ ということでしょうか？
362:349
08/08/07 01:16:35
>>361 に追記
３．定義済み （>>360 のコードは規格に沿っている）
363:デフォルトの名無しさん
08/08/07 01:17:28
ISO の、ダウンロードできるドラフトでは >354 が引用した部分の直後にスコープの開始位置に
ついての説明があった。それによると、変数名のスコープが始まるのは変数宣言内の変数名の
直後。
ってことで >351 は OK 。
364:349
08/08/07 01:20:49
>>363
ありがとうございます
スッキリしました
これでゆっくり眠れます