08/01/24 14:52:45
このスレは標準C規格や規格に合致した移植性の高い記法・技法に関するスレです。
C言語初心者の初歩的な質問、GUIなどの標準Cではできない事の質問、
ソース丸投げ、宿題、書籍 などは専門の別スレッド↓があるのでそちらへ。
Ｃ言語なら俺に聞け（入門篇） Part 24
ｽﾚﾘﾝｸ(tech板)
【初心者歓迎】C/C++室 Ver.47【環境依存OK】
ｽﾚﾘﾝｸ(tech板)
C/C++の宿題を片付けます 103代目
ｽﾚﾘﾝｸ(tech板)
【書き込む前に】
・まず問題を冷静に吟味してCの話か否かをはっきりさせてから質問しましょう。
・質問する前には最低限検索を。
・エラー(警告含む)が起きたのならばエラーメッセージを書きましょう。
【参考文献】
C FAQ 日本語訳
URLﾘﾝｸ(www.kouno.jp)
Cプログラマ必読 ・プログラミング言語C(通称 K&R)
URLﾘﾝｸ(www.amazon.co.jp)
【このスレのログ】
前スレ：ｽﾚﾘﾝｸ(tech板)
他の過去ログ：URLﾘﾝｸ(nssearch.hp.infoseek.co.jp)
【このスレ住人としての心得】
わざとスレ違いあるいはごく低レベルな質問を繰り返して
流れを妨害する荒らしがいます。適当に誘導して放置してください。
2:デフォルトの名無しさん
08/01/24 15:02:44
＜｀∀´＞ニダニダ！
3:デフォルトの名無しさん
08/01/24 15:10:37
>>2
こりゃ低レベル
4:デフォルトの名無しさん
08/01/24 15:13:22
>>1市ね
5:デフォルトの名無しさん
08/01/24 15:22:05
＞前スレ1000
こりゃひどい
6:デフォルトの名無しさん
08/01/24 16:57:34
なんぞこのタイトル
7:デフォルトの名無しさん
08/01/24 17:07:59
スレタイが不適切だという指摘と
最近のスレの傾向を鑑みて
適切なスレタイを考えてるうちに
スレがつぶれそうになったので
とりあえず前に書いてあったタイトルを修正してつけた
もっといいのがあるなら次からそれにしてくれ
8:デフォルトの名無しさん
08/01/24 17:27:54
確かにこういうスレも必要かも知れん
…が、そのスレの次スレとして立てるのは如何なモノかと思うぞ。
9:デフォルトの名無しさん
08/01/24 17:32:23
JISのPDFダウンロードできるじゃん
ってダウンロードしたけど、全ページ黒塗りだった。
なんとかしてくんろ
10:デフォルトの名無しさん
08/01/24 18:53:16
いいスレタイだな。
これなら流石にスレチは減るだろう。
11:デフォルトの名無しさん
08/01/24 23:24:43
先生, 質問!
はじめて, MS の処理系で業務に使うものを作る事になりそうなんだけど
規格準拠してる?
最低限でも, stdint.h とか stddef.h が規格準拠しててほしいわけだが…
12:デフォルトの名無しさん
08/01/24 23:27:39
>>11
VSスレ辺りで聞いてみてはどうか。
13:デフォルトの名無しさん
08/01/24 23:33:42
>>12 そもそもVSスレって何？？？
まじで, Windows ほとんど触った事ねぇし
俺的には Windows == ユーザが要求してくる使いたくもない MS-word を書く
あるいはゲームをやるための環境なんだが
14:デフォルトの名無しさん
08/01/24 23:37:24
>>13
VisualStudio
15:デフォルトの名無しさん
08/01/25 00:41:47
前スレではＭＳのコンパイラは過去に準拠してなかった部分があるらしいという話は出ていた
現在ではざっと調べた限りでは準拠してると謳ってるようなので
問題起こったらMSのせい、でいいと思うが
16:デフォルトの名無しさん
08/01/25 00:55:40
C89では//コメントとかアウトだよね。
17:デフォルトの名無しさん
08/01/25 00:56:05
フリー、シェア含めて今一番ガチC言語の規格に沿ったコンパイラって何だろ？
C99用のコンパイラになるのか？
18:デフォルトの名無しさん
08/01/25 01:38:48
お前ら落ち着けよ
いまどきWindowsでC++じゃなくC？
ありえん
19:デフォルトの名無しさん
08/01/25 01:46:04
>>18
ゲイツに侵されすぎｗｗｗ
20:デフォルトの名無しさん
08/01/25 04:17:13
>>9
暗号化PDFを読めるリーダーを使え
21:デフォルトの名無しさん
08/01/25 20:56:36
エスパーしてみると、最新のFoxitReaderには黒塗りになるバグがある。
22:デフォルトの名無しさん
08/01/26 01:04:53
>>17
gcc -Wall -ansi -pedantic-errors
かな？C89だけど
23:デフォルトの名無しさん
08/01/27 17:30:20
C99激しくいらない
24:デフォルトの名無しさん
08/01/27 17:40:56
C++0x に導入されるような機能は欲しい。
C++0x に導入されないような機能はいらない。
25:デフォルトの名無しさん
08/01/28 07:17:37
C99って誰が望んだんだ？
26:デフォルトの名無しさん
08/01/28 10:21:02
C++あがりが望んだんじゃないの
27:デフォルトの名無しさん
08/01/28 11:08:58
誰もが望んでいたものもそれなりに入ったような気もするが？
28:デフォルトの名無しさん
08/01/28 14:35:15
望んでいたものの半分以上はC++にあるものの劣化版だったから困る
29:デフォルトの名無しさん
08/01/28 18:45:42
C99は糞
K&Rの第3版が出ないのが何よりの証拠
30:デフォルトの名無しさん
08/01/28 21:40:03
望んでいたというか有名どころの拡張を追認しただけというか
31:デフォルトの名無しさん
08/01/28 21:44:39
C++ との互換性が無いのは致命的だよな。
C で作った関数の中には C++ から呼べない物も・・・なんて嫌だわ。
32:デフォルトの名無しさん
08/01/29 02:00:41
>>22
-std=c99もつけてあげて
33:デフォルトの名無しさん
08/01/29 21:12:35
GCCはC99に準拠していない。
34:デフォルトの名無しさん
08/01/29 21:34:28
>>33
> GCCはC99に準拠していない。
具体的に。
35:デフォルトの名無しさん
08/01/29 21:39:25
ググレカス
36:デフォルトの名無しさん
08/01/29 23:01:18
準拠状況が書いてあるとこがあったな。
完全ではなかったのは覚えてる。
37:デフォルトの名無しさん
08/01/30 05:18:37
つーかC99完全準拠の環境なんてあるのか？現状
38:デフォルトの名無しさん
08/01/30 07:28:23
Comeau の準拠状況ってどうなんだろうか？
39:デフォルトの名無しさん
08/01/30 07:30:35
>>37
Intel C++は100％C99標準準拠だよ
40:デフォルトの名無しさん
08/01/31 13:02:51
C言語をはじめたばかりであまりわからないのですが、
ビットシフトはなんの役に立つのでしょうか？
41:デフォルトの名無しさん
08/01/31 13:03:31
>>40
スレタイ読め
42:デフォルトの名無しさん
08/01/31 13:26:45
>>41
ビットシフトはなんの役に立つのでしょうか
でぐぐれ
43:デフォルトの名無しさん
08/01/31 19:47:50
>>40 ビット単位でシフトしたい時に役に立つ
44:デフォルトの名無しさん
08/02/01 15:53:26
>>42
やっぱりこれテンプレにいれとかないとダメだな
45:デフォルトの名無しさん
08/02/01 20:16:45
ビットシフトはなんの役に立つのでしょうかでググれ に一致する日本語のページ 約 766 件
46:デフォルトの名無しさん
08/02/01 21:02:34
>>34
URLﾘﾝｸ(gcc.gnu.org)
47:デフォルトの名無しさん
08/02/02 17:48:40
ふと思ったんだが…
各種処理系のヘッダで NULL が以下のように宣言されているのはなぜ?
#if !defined(__cplusplus)
#define NULL ((void *)0)
#else
#if defined(__LP64__)
#define NULL (0L)
#else
#define NULL 0
#endif /* __LP64__ */
#endif /* !__cplusplus */
つか, C でも (void *)にキャストする必要はないと思われるんだが,
(void*)にキャストしておくとなんかご利益あったりする?
48:デフォルトの名無しさん
08/02/02 17:55:00
int p = NULL; がエラーになる。
49:デフォルトの名無しさん
08/02/02 17:58:48
NULLを'\0'と間違えて使うような馬鹿を摘発したりとか、型チェックの面でご利益がある。
50:デフォルトの名無しさん
08/02/02 19:01:20
#if defined(__LP64__)
#define NULL (0L)
これ処理系依存っぽくて鬱陶しいな
51:デフォルトの名無しさん
08/02/02 19:03:41
処理系自身がそう定義してるのなら
その処理系で大丈夫っつーことだから問題はないだろう
52:デフォルトの名無しさん
08/02/02 19:04:07
>>50
printf の可変長引数対策じゃないか？
53:デフォルトの名無しさん
08/02/02 19:06:36
つーかそういう処理系依存を覆い隠すためにヘッダがあるわけで
ヘッダの定義をのぞき見てあれこれ言っても
このスレ的に意味があるのか疑わしい
54:デフォルトの名無しさん
08/02/02 19:06:54
処理系定義であるポインタのサイズを、NULLの定義の形を借りて記述しているんだよ
55:デフォルトの名無しさん
08/02/02 20:16:17
ポインタのサイズが型ごとに異なったりする処理系もあるんじゃなかった？
56:デフォルトの名無しさん
08/02/02 20:58:41
MS-DOSのミディアムモデルやコンパクトモデルが典型的だな
57:デフォルトの名無しさん
08/02/02 21:18:16
型ごとにというかデータのポインタとコードのポインタのサイズが違う事はあるな
関数ポインタと通常のポインタに互換性がないのはそのため
58:デフォルトの名無しさん
08/02/03 00:51:14
pimpl パターンとか見てる分には
データ同士だとポインタのサイズはかわらないはずだとは思ってるが、
規格のどこに書いてあるかとかは知らんなあ。
59:デフォルトの名無しさん
08/02/03 01:46:52
pimplのどこに異種ポインタの変換が介在するのですかね。
60:デフォルトの名無しさん
08/02/03 02:53:14
スレ違い
61:デフォルトの名無しさん
08/02/03 02:57:46
変換は関係ないだろう。
構造体/クラスの中身が分からなくても
ポインタのサイズが決まるようじゃないと
pimpl パターンは使えないという話だ。
ただ、組み込み型との間でもサイズが等しいかどうかは分からんね。
これだけだと。
62:デフォルトの名無しさん
08/02/03 05:15:44
構造体/クラスの宣言(通常はヘッダファイル)があれば型が分かるから
中身見なくてもポインタのサイズは決まると思う
63:デフォルトの名無しさん
08/02/03 05:38:48
ポインタのサイズって32bitCPUなら4バイト固定だと思ってた
64:デフォルトの名無しさん
08/02/03 10:02:56
Intel + Windows で 16-bit アプリケーションなら 32-bit CPU でも
2 バイトのポインタが使われたりする
が 32-bit アプリケーションならポインタは 4 バイト固定
要するに CPU 依存でなくコンパイラ依存
void* と int* でサイズが違う処理系があるらしいが見てみたいな
65:デフォルトの名無しさん
08/02/03 11:06:04
void* (char*) と int* でアドレッシングが違う処理系があると聞いたが、
それの間違いではなくて？
66:デフォルトの名無しさん
08/02/03 11:11:12
規格ではポインタのサイズはどこまで規定されている？
構造体型を指すポインタのサイズはすべて等しい？
67:デフォルトの名無しさん
08/02/03 16:20:19
処理系依存ってことはつまり、ユーザープログラムより下にあるコンパイラからアーキテクチャから
すべてひっくるめて依存。データ型についてうるさいアーキテクチャもあるかもしれない。
(タグビットでデータ型を指定するような)
仕様では、6.3.2.3 で、任意のデータ型へのポインタから void * へ、
void * にしたものから元の型へ、という変換は保証されることになっている。
（関数へのポインタに関しては規定がない）
整数と任意のポインタ（関数へのポインタ含む）との変換は、処理系定義。
ポインタを入れることができる整数の型として intptr_t(uintptr_t) が 7.18.1.4 に。
68:デフォルトの名無しさん
08/02/03 17:46:07
>>66
> 構造体型を指すポインタのサイズはすべて等しい？
少なくとも、これは処理系によらず保証されている。
69:デフォルトの名無しさん
08/02/03 17:58:44
同サイズの整数型限定だっけ？ ＞整数/ポインタ キャスト
intptr_t はどのポインタと等しいサイズの整数型なんだろう。
それとも、全てのポインタ型のサイズが等しいと保証されているのか？
70:デフォルトの名無しさん
08/02/03 18:00:06
intptr_tはポインタを格納できればいいのであって、
ポインタと同じ大きさである必要は無いだろう。
71:デフォルトの名無しさん
08/02/03 18:04:23
>>69-70
(u)intptr_tに変換できるのはvoid*だけ。
int i = 42;
intptr_t p = (void*)&i;
int j = *(int*)(void*)p;
72:デフォルトの名無しさん
08/02/03 18:39:20
そしてobjectを指すポインタであればどれでも、voidへのポインタに変換後、元に戻せる。
つまり、voidへのポインタのサイズは少なくとも関数ポインタ以外のすべてのポインタ以上。
73:デフォルトの名無しさん
08/02/03 20:06:00
>>71
70に対する反論になっていない
74:デフォルトの名無しさん
08/02/03 20:28:45
反論したつもりはないよ。
75:デフォルトの名無しさん
08/02/03 20:54:06
なるほど。
基本型同士、あるいは基本型と構造体型との間で
ポインタのサイズが違ってても良さそうではあるな。
76:デフォルトの名無しさん
08/02/03 21:16:41
int *とunsigned int*みたいな、指示先型の符号の有無だけが異なる場合、ポインタのサイズは等しい。
77:デフォルトの名無しさん
08/02/03 21:18:39
>>74
じゃあ何で一見関係ありそうで全然関係ない話をしたの？
78:デフォルトの名無しさん
08/02/03 21:33:08
>>77
>>69
79:デフォルトの名無しさん
08/02/03 21:35:13
>>77
何でアンカー間違えただけでそんなに責められないといけないんですか＞＜
80:デフォルトの名無しさん
08/02/04 19:59:51
先に「間違えた」と言わないから。
81:デフォルトの名無しさん
08/02/04 21:58:01
>>79
条件の後出しはやめろと。
82:デフォルトの名無しさん
08/02/04 23:19:53
いじめが好きな人達が集まるスレ
83:デフォルトの名無しさん
08/02/04 23:56:02
といいつつ自分の非を棚に挙る人が責められるスレ
84:デフォルトの名無しさん
08/02/05 20:48:59
>>82-83
それはどのスレでもそう
85:デフォルトの名無しさん
08/02/18 15:22:26
ふと気になったんだけど
>50の、0Lをかっこでくくる必要あるの？
86:デフォルトの名無しさん
08/02/18 20:02:18
>>85
#include <stdio.h>
#define HOGE 0L
#define CAT2(a, b) a ## b
#define CAT1(a, b) CAT2(a, b)
#define CAT(a, b) CAT1(a, b)
#define STR2(a) # a
#define STR1(a) STR2(a)
#define STR(a) STR1(a)
int main() {
long double a = CAT(0., HOGE);
printf("%Lf\n", a);
printf("%s\n", STR(CAT(0., HOGE)));
return 0;
}
87:デフォルトの名無しさん
08/02/18 20:43:53
マクロNULLをトークン連結演算子に投げ込むような状況があるとは思えんが
88:デフォルトの名無しさん
08/02/18 20:45:36
そういう問題じゃない
89:デフォルトの名無しさん
08/02/18 20:50:11
あってもこまらないし
あればもしかしたら役に立つかもしれないから
一般的にはある必要はない
90:デフォルトの名無しさん
08/02/18 20:51:38
あってもこまらないし
あればもしかしたら役に立つかもしれないから
とりあえずつけておけ
91:デフォルトの名無しさん
08/02/19 23:04:55
超カメレスなんだが >>64
ワードアドレッシングのマシンの場合,
ワードアドレス + オフセット
ここで, ワードアドレス == レジスタサイズ
が, バイトポインタになり得ますが…
92:デフォルトの名無しさん
08/02/20 14:01:41
可変引数型の関数にいくつ引数が入力されたか、
数える方法はありますか？
93:デフォルトの名無しさん
08/02/20 14:09:30
標準では、ない
94:92
08/02/20 14:44:34
＞93
サンクス
95:デフォルトの名無しさん
08/02/21 23:25:37
そう言えばさぁ...
左辺がキャストできなくなったのは C89 からで ok ?
int c; (char)c = 1;
みらいやつ
96:デフォルトの名無しさん
08/02/22 02:33:43
*(char *)&c = 1;ならおｋ
ただしcharは必ず整合するけどもっと大きな型だとむやみなキャストは
境界に整合しなくなるおそれがある
97:デフォルトの名無しさん
08/02/22 07:32:26
それはキャストはしてるけど、
キャストした後の値に直接代入してる訳じゃないよね。
98:デフォルトの名無しさん
08/02/22 13:23:07
>>95
というかそれが出来た時期なんかあったのか
どういう処理になるの？
99:デフォルトの名無しさん
08/02/22 13:30:53
>>95
少なくとも現在より前に制定された規格で、
(type)variable を左辺値として認めたものは一つもない。
たしか、gcc, msvcともにラフなモードではコンパイルとおるけど、
結果が違うようになったと思う。
100:デフォルトの名無しさん
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
ありがとうございます
スッキリしました
これでゆっくり眠れます
365:デフォルトの名無しさん
08/10/16 08:59:54
真偽値は非ゼロとゼロ、というのは環境依存でしょうか
それとも規格上間違いなく非ゼロが真、ゼロが偽でしょうか
366:デフォルトの名無しさん
08/10/16 10:34:25
規格上決まってる
367:デフォルトの名無しさん
08/10/16 12:29:25
>366
ありがとうございます
368:デフォルトの名無しさん
08/11/16 23:28:03
ｽﾚﾘﾝｸ(tech板:951-番)
int main(){/* ... */}が標準準拠かどうか揉めてます
識者の見解をお願いします
369:デフォルトの名無しさん
08/11/17 00:03:47
>>368
X 3010：2003 (ISO/IEC 9899：1999)より抜粋
> 5.1.2.2.1 プログラム開始処理 プログラム開始処理において呼び出される関数の名前は，main とする。
> 処理系は，この関数に対して関数原型を宣言しない。この関数は，次の4 種類の方法のいずれかで定義し
> なければならない。
> － 返却値の型int をもち仮引数をもたない関数
> int main(void) { /* ... */ }
> － 二つの仮引数をもつ関数（仮引数は，これらが宣言された関数に対して局所的であるため，どのよう
> な名前を使用してもよいが，ここではargc 及びargv とする。）
> int main(int argc, char * argv[]) { /* ... */ }
> － 上に掲げた二つの方法のいずれかと等価な方法(9)
> － 上に掲げた三つの方法のいずれでもない処理系定義の方法
最後の処理系定義（文書化）が遵守されている処理系において厳密でないほうの規格合致プログラムだな
370:デフォルトの名無しさん
08/11/17 00:10:42
Cでは基本的に () と (void) は異なるが、
関数定義においては同じとされていたはず。
GCC ではそうなってなかった気はするが・・・。
371:デフォルトの名無しさん
08/11/17 00:40:22
そもそも組込みには必ずしもmain()はない・・・というのはここでは禁句かな？
しかし、いくらC言語の規格に準拠していても、MISRAに準拠していないと言うことで
プログラムの作りかえをさせられるのはウザイ・・・
逸脱手順を書くのもウザイ・・・
372:デフォルトの名無しさん
08/11/17 22:48:37
>>368
言いだしっぺです。
int main() が標準準拠かどうか？でもめているのではなく、（そういうことならいうまでもなく標準準拠に決まっています。）
int main(void) を標準としたのは馬鹿じゃないの？ということです。
昔 fj でもめたのを受け売りしただけですね、はい。
373:デフォルトの名無しさん
08/11/17 22:53:25
>>372
main() は K&R 準拠だろ
374:デフォルトの名無しさん
08/11/17 23:32:05
>>371
ホスト環境とスタンドなんとか環境ですね
375:デフォルトの名無しさん
08/11/19 03:21:32
>>372
int main(void) 以外の何を標準にするべきで、そうすると何がうれしいと思ってるの？
376:デフォルトの名無しさん
08/11/19 05:04:56
>>375
int main(void) は削除するのがいいでしょうね。
int main() という書き方が現在でも有効であるのに、なぜわざわざ int main(void) というセンスのない書き方をまかり通すのか理解に苦しみます。
そのこころは、つｽﾚﾘﾝｸ(tech板:962番)
377:デフォルトの名無しさん
08/11/19 08:41:44
こちらは将来的に削除される予定
> int main()
378:デフォルトの名無しさん
08/11/19 11:05:40
>>376
リンクされたスレは既に dat 落ちで見れない。
379:デフォルトの名無しさん
08/11/19 12:25:34
>>376
センスがないって、どのように？
380:デフォルトの名無しさん
08/11/19 18:55:51
(void)にセンスがないというのは理解できる。
空の()で引数がないことを表すことにしたC++の英断は素晴らしい。
381:デフォルトの名無しさん
08/11/19 18:58:42
Cの方は過去のしがらみもあったしな
382:デフォルトの名無しさん
08/11/19 20:11:19
くだらねぇぇぇぇ
383:デフォルトの名無しさん
08/11/19 20:17:17
引数チェックのない時代の名残だからな。
384:デフォルトの名無しさん
08/11/19 21:03:20
>>379
呼び出し側は引数の有無にかかわらず同じだったとしたら、呼び出し側の実際と違う宣言をなんの躊躇もなく記述するところ。
385:デフォルトの名無しさん
08/11/19 21:07:22
>>384
main の呼び出し側はスタートアップ関数であって、
スタートアップ関数はコンパイラが提供するものだろ・・・。
386:デフォルトの名無しさん
08/11/19 22:13:58
>>384
呼び出し側の実際の宣言は何だと思っている？
387:デフォルトの名無しさん
08/11/19 22:52:01
ソースコード側でC言語の管轄外の世界に勝手な仮定置いちゃダメだろ
標準的に考えて
388:デフォルトの名無しさん
08/11/19 23:08:45
>>387
プログラム開始処理（program startup）が main を呼ぶ事は
5.1.2.2.1 プログラム開始処理 に規定されている。
389:デフォルトの名無しさん
08/11/19 23:09:40
きっとOSが「いんとめいんかっことじかっこ…」とかコマンド打ち込んでると思ってるんだろう
390:デフォルトの名無しさん
08/11/19 23:14:16
>>388
プログラム開始処理がmainを呼ぶ時に引数をチェックしないなんて規定されてたっけ
391:デフォルトの名無しさん
08/11/19 23:18:19
>>390
多分お前の話したい奴は別の奴だ。
392:デフォルトの名無しさん
08/11/19 23:24:13
スタートアップ処理はコンパイラが用意するから
main がどうなっていようと良きに計らってくれるっしょ。
393:デフォルトの名無しさん
08/11/19 23:58:18
main関数の定義でint main()と書いてるんだから
引数なし以外ありえない。
関数宣言での引数省略と勘違いしてるんだろうね
394:デフォルトの名無しさん
08/11/20 00:07:12
>>385
スタートアップ関数は引数の有無にかかわらず同じだったとしたら、スタートアップ側の実際の違う宣言を躊躇なく記述することに疑問を感じています。
395:デフォルトの名無しさん
08/11/20 00:10:41
>>386
実際のところ、
int main(int argc, char **argv, char **env)
でしょうか。私のところの某処理系では環境変数がコンパイル時スタックをつぶしてしまうので可能なときは再コンパイルしていました。
これってヘッダをさわっただけではどうにもならなかったですよね。
396:デフォルトの名無しさん
08/11/20 00:11:12
>>387
だから int main() なのでは？
397:デフォルトの名無しさん
08/11/20 00:12:11
>>389
某処理系のfork()やexec*()の存在くらいは知っています。
398:デフォルトの名無しさん
08/11/20 00:12:42
>>392
それはそうですね。
399:デフォルトの名無しさん
08/11/20 00:14:51
>>393
それはそうですね。
コンパイラ側が勝手に stdcall をデフォルトとしている世界であれば、逆に int main(void) でないと困るのかもしれません。
んー ms-pascal？
400:デフォルトの名無しさん
08/11/20 00:29:00
>>390
プログラム開始処理が main() のために引数を整えている、と理解していますが、実際のところは誰がしているのでしょうか？
401:デフォルトの名無しさん
08/11/20 00:33:38
>>400
ご明察の通り、スタートアップルーチンがお膳立てします。
402:デフォルトの名無しさん
08/11/20 00:39:02
osとｃｒｔ
403:デフォルトの名無しさん
08/11/20 00:41:42
>>376
実は main は関係無くて、引数無しの関数の引数リストが void なのが不満なだけなのか？
404:デフォルトの名無しさん
08/11/20 00:42:51
不満なら書かなきゃいいだけの話では?
405:デフォルトの名無しさん
08/11/20 00:43:24
>>394
＞スタートアップ関数は引数の有無にかかわらず同じだったとしたら、
その仮定がおかしい
406:デフォルトの名無しさん
08/11/20 00:47:08
実際同じじゃね?
呼び出し側で積んだ引き数は、呼ばれた側が無視しても全く問題ないわけだし。
例えばint func() {return 0;}という関数を宣言なしでfunc(0)と呼ぶときと事情は変わらない。
407:デフォルトの名無しさん
08/11/20 00:51:44
>>402
os? shell ではないのですか？
というか shell と crt との役割分担は？あー ms-dos以外の場合で、てことで。
408:デフォルトの名無しさん
08/11/20 00:53:54
>>405
ん、たしかに stdcall がデフォルトのコンパイラがあったとしたら、その場合スタートアップ関数は int main(int c, char **v) と int main(void) とでは異なるでしょうね。
409:デフォルトの名無しさん
08/11/20 00:54:44
>>403
ん、そです。
410:デフォルトの名無しさん
08/11/20 00:55:48
>>409
すると、>406のようなfuncも気に入らないと。
>>408
>406
411:デフォルトの名無しさん
08/11/20 01:00:18
>>410
int func(void) {return 0;}と書いておきながら、func(0)と呼ぶのが気に入らないだけなんですが。
412:407
08/11/20 01:01:11
>>402
shell の末尾は exec*() でしたね。失礼しました。
413:デフォルトの名無しさん
08/11/20 01:06:17
>>409
古い（規格化以前？の） C では、引数リストが空の関数宣言は引数の数や個数を指定せずに
関数を宣言するものとなっていた。規格化にあたってそういった過去のコードを不正としないように
配慮した。そういうことだと思う。規格を決めた人が馬鹿だったわけじゃないでしょ。
414:デフォルトの名無しさん
08/11/20 01:30:17
>>413
そうではなくて、
func() に必要な引数はないけれども、func(0, 1, 2, 3 ... ) と呼び出さざるを得ない状況で
func() の宣言をどうするか？
という問題です。
このとき、int func(void) と宣言するのは、
すっごくやです。
415:デフォルトの名無しさん
08/11/20 01:41:31
int func(...);
416:デフォルトの名無しさん
08/11/20 01:45:50
>>415
%gcc test.c
test.c:3 error: ISO C requires a named argument before ...
417:408
08/11/20 02:18:24
>>410
＞ >>408
＞ >406
ん？stdcall はreturn時に呼び出され側でスタックを払うから、呼び出し側は呼び出され側の引数を完全無欠に知っておかなければならないかと。
418:デフォルトの名無しさん
08/11/20 02:53:28
＞すっごくやです。
し ら ね え よ
419:デフォルトの名無しさん
08/11/20 03:10:51
>>414
> func() に必要な引数はないけれども、func(0, 1, 2, 3 ... ) と呼び出さざるを得ない状況で
>416 のとおり、そういうことはできないことになっている。
420:デフォルトの名無しさん
08/11/20 03:14:04
>>418
論理的な思考の根源には、ある種の好き嫌いの視点からの判断が含まれることも多々あるのですが、
お気に召さないのであれば、いいなおしましょうか。
「int main(void)は、main() の呼び出し側に思いを馳せていない、という点で、規約としては問題があるかと思います。」
421:デフォルトの名無しさん
08/11/20 03:21:36
>>419
いいえ、>>416 は、
不定長引数の場合はすくなくとも一つの引数には名前がついていなければならない、と述べているにすぎません。
コンパイル単位が別であれば、
int func(void) { return 0; }
に対して、
func(0, 1, 2, 3, 4, 5, 6, 7)
を呼び出すことは可能です。リンカもエラーは吐きません。
422:デフォルトの名無しさん
08/11/20 03:30:19
>>420
なら、main(void)用とmain(int argc, char **argv)用のスタートアップルーチンを用意して、
プログラムに合うように選択する処理系があったらint main(void)でも構わないのか？
……自分で書いていて詭弁のガイドラインに抵触するような気がしてきた。
423:デフォルトの名無しさん
08/11/20 03:33:37
>>421
あるコンパイル単位では int func(int a, ...) と宣言して、別のコンパイル単位で
int func(void) で定義するってこと？
それなら未定義動作だよ。コンパイルできてもリンクできても議論に値しない。
424:デフォルトの名無しさん
08/11/20 04:03:29
>>423
正確には、あるコンパイル単位では int func(void) と定義しておいて、
別のコンパイル単位から func(0, 1, 2, 3) と呼び出します。
未定義であることの記述があれば教えてください。
というより、cdecl と stdcall の話は処理系依存といえますから、この手の話が規約に載ることもないでしょう。
でも stdcall ならば可変長引数は困難ですし、でも cdecl/stdcall の話が可変長引数に絡むし、そして可変長引数は定義されていますし、
実装によっては不可能な仕様というものでも定義されているのは、どういうことなのでしょうか？
それはそうと、ほとんどのコンパイラでは、スタートアップと main() とのリンクは、上述のようになっているのですが‥‥‥。
425:デフォルトの名無しさん
08/11/20 04:04:22
>>422
そういうことになります。お目にかかったことはありませんが、完全無欠のstdcall仕様のコンパイラがあれば。
426:デフォルトの名無しさん
08/11/20 04:12:55
>>424
「別のコンパイル単位」では宣言無しで呼び出すってことか。
どっちにしても未定義動作だけどな。
6.5.2.2 Function calls p6 より
> 6 If the expression that denotes the called function has a type that does not include a
> prototype, ...
(snip)
> If the number of arguments does not equal the number of parameters, the
> behavior is undefined. If the function is defined with a type that includes a prototype, and
> either the prototype ends with an ellipsis (, ...) or the types of the arguments after
> promotion are not compatible with the types of the parameters, the behavior is undefined.
ちなみに、スタートアップと main() とのリンクについては処理系ごとに好きにすればいい話で、
引数リストとかもう関係ない。
427:デフォルトの名無しさん
08/11/20 04:25:55
>>426
なるほど。
これを見る限り、可変長引数も「実は未定義」なんでしょうか？んー、prnitf() はどうなるのでしょうか？
＞スタートアップと main() とのリンクについては処理系ごとに好きにすればいい話
それでは、なおさら、int main(void) を標準的な記法として盛り込むの問題かと。int main(void) は現実から乖離しています。いらない子です。
428:デフォルトの名無しさん
08/11/20 04:35:26
>>427
可変長引数は ... を含むプロトタイプ付き関数として定義されている。
main() とのリンク方法が処理系依存でも、処理系に食わせるプログラム自体は
移植性を持つ必要がある。全然関係ない話。
main() の話がしたければ >>375 の質問に対して主観を排除した答えを出せ。
429:デフォルトの名無しさん
08/11/20 06:46:29
>>428
ん？引用された文章をみると、
> If the function is defined with a type that includes a prototype, and
> either the prototype ends with an ellipsis (, ...) or
(略)
> the behavior is undefined.
だから「... を含むプロトタイプ付き関数」すなわち可変長引数の振る舞いは "undefined" なのでは？
> 処理系に食わせるプログラム自体は移植性を持つ必要がある。
おっしゃる意味がよくわかりません。移植性をもたせることと int main(void) の表記とどのような関係があるのでしょうか？
>主観を排除した
ではｽﾚﾘﾝｸ(tech板:962番)を再掲します。
>> c でよく採用された実装では、呼び出され側のコードは、呼び出し側の引数の個数や種類に依存しない、というもの。....※
>> 個々の関数は翻訳単位を別にとることが可能ですよね。無論、呼び出し側・呼び出され側の引数のチェックがあればそれにこしたことはないのですが。
>> で、main() についても呼び出し側でなんらかの仮定があり、それに対応して main() 記述側で記述するわけです。
>> ※によりmain() 呼び出し側は main() の記述側で必要な引数がどうであれ、常に同じものがリンクされるといっていいと思います。
>> そうであれば、main(void) と書くのは、main() 呼び出し側の仮定と食い違う書き方をしているわけですね。
>主観を排除した
主観がふくまれていたからといって意見として劣るわけではありますまい。そもそも主観・客観ってなんですか？
430:デフォルトの名無しさん
08/11/20 06:49:01
>そもそも主観・客観ってなんですか？
バカじゃねぇの？
431:デフォルトの名無しさん
08/11/20 06:54:28
コンパイラは int main(void) を見つけたときと int main(int argc, char* argv[]) を見つけたときで
スタートアップルーチンを自由に変えることが可能。
432:デフォルトの名無しさん
08/11/20 06:57:56
>>429
君が略した部分を飛ばして読むとそう読めるね。
なんて都合のいい引用の仕方。ふう。
433:デフォルトの名無しさん
08/11/20 10:25:35
>>427
スレタイ読めないの？
初心者お断りだよ
434:デフォルトの名無しさん
08/11/20 10:59:56
main() の呼び出しが通常の関数呼び出しと同じだと思いこんでるのが間違いなんだな。
435:デフォルトの名無しさん
08/11/20 12:02:00
>>429
> 移植性をもたせることと int main(void) の表記とどのような関係があるのでしょうか？
main() の引数リストについて移植性を保証できる表記を定めることに意味があるということ。
スタートアップからの呼び出し方法が自由だからといって main() の引数リストについて
何の規定もおかないでいると、移植性を保証することができない。
そして引数無しと２引数のものが移植性を保証できるものとして選ばれた。引数無しの
ものの記法については >413 のとおり。
436:デフォルトの名無しさん
08/11/20 17:21:26
>>422
それが本当は正道なはずだな
437:デフォルトの名無しさん
08/11/20 18:47:05
test
438:デフォルトの名無しさん
08/11/20 19:17:09
>>434
全くだ。
そこは既にCの規格の範疇外の話だ。
439:デフォルトの名無しさん
08/11/20 21:22:24
>>431
確かにそのような手はあると思います。完全にstdcall なコンパイラならそうするしかないでしょう。
>> ｽﾚﾘﾝｸ(tech板:951番)
>>399 >>408
440:デフォルトの名無しさん
08/11/20 21:23:55
>>432
え？ether A or B の B を略しただけですが？
B を略するかしないかで大きく意味が変わる文章なんですか？
441:デフォルトの名無しさん
08/11/20 21:24:28
>>433
どこが初心者だと感じたのか、詳細を記述いただければ幸いです。
442:デフォルトの名無しさん
08/11/20 21:31:37
>>435
移植性を保障するためにある一定の枠組みを定めておくところについては同意いたします。しかし、
私見では、
int main(int, char **)
のみで十分と思われるのですが、あえて
int main(void)
を規定した意味については、どう考えておられるのでしょうか。
皆さんと私との意見の違いは、この部分にあると考えておりますので、差し支えなければ教えてください。
stdcall/cdecl あるいは別の呼び出し規約も視野にいれて規定されたのであれば、私としても依存はありません。
>>ｽﾚﾘﾝｸ(tech板:951番)
443:デフォルトの名無しさん
08/11/20 21:32:08
>>436
確かに同意いたします。
ｽﾚﾘﾝｸ(tech板:951番)
444:デフォルトの名無しさん
08/11/20 21:33:31
>>438
ん？main() といえども、他の関数と同じ、というのがもともとの心なのでは？
単にスタートアップコードから呼ばれる、というだけで。
＃main() を recursive call するのは、違反でしたっけ？
445:デフォルトの名無しさん
08/11/20 21:36:31
>>430
つURLﾘﾝｸ(ja.wikipedia.org)
446:デフォルトの名無しさん
08/11/20 21:44:05
>>400
are not compatible with the types of the parameters
を略するなよ。おまえ、構文が読み取れてないだろ。
447:デフォルトの名無しさん
08/11/20 21:52:52
>>444
再帰しようが、別にそのプログラム中でつじつまが合っていれば問題なかろう。
448:デフォルトの名無しさん
08/11/20 21:54:43
>>442
引数使わない時にまで引数書くのめんどくせーじゃん。
449:デフォルトの名無しさん
08/11/20 21:56:29
そもそも何で呼び出し規約が関係するんだよ・・・。
最悪スタートアップルーチンを main によって変えれば済むだけの話じゃん。
450:429
08/11/20 21:57:52
>>446
私は、元の引用文を
If
1) the function is defined with a type that includes a prototype, and
2) either 2.a) the prototype ends with an ellipsis (, ...)
or
2.b) the types of the arguments after promotion
are not compatible with the types of the parameters,
the behavior is undefined.
と考えましたが間違っているのでしょうか？
差し支えなければ、あなたの解釈を教えてください。
451:デフォルトの名無しさん
08/11/20 21:59:48
>>449
だからそれはすでに述べられ済み。
ｽﾚﾘﾝｸ(tech板:951番)
452:デフォルトの名無しさん
08/11/20 22:06:24
>>449
呼び出し規約、具体的には stdcall と cdecl とではスタックを払うのが呼び出し側か呼び出され側にあるか、という違いがあります。
すなわち、呼び出し側で仮定した引数と呼び出され側で仮定した引数とが異なってもよいか、それとも完全に一致しなければならないか、という違いを意味します。
スタートアップコードが main() を呼ぶときにスタックに積む引数と、main() がスタックに積んであると仮定している引数とが一致しなくてもいいのか、それとも一致しなければならないか、ということです。
stdcall では main() がスタックを払うので、両者は一致しなければなりません。
453:デフォルトの名無しさん
08/11/20 22:08:01
>>448
その論法でいけば、引数がないときには
int main()
とすれば、もっと楽ではないでしょうか。
454:デフォルトの名無しさん
08/11/20 22:25:32
どうでもいいけどおまえら２ｃｈのレスをソースにするなよｗｗｗ
455:デフォルトの名無しさん
08/11/20 22:32:51
一体何を問題に従ってるのかさっぱりわからん
456:デフォルトの名無しさん
08/11/20 22:33:42
読んでて混乱するから以前の自分の発言を話の前提にしたいならレス番を名前に入れろ
457:デフォルトの名無しさん
08/11/20 22:36:53
>>451
何度dat落ちしたスレのアドレスを張る気だ
458:デフォルトの名無しさん
08/11/20 22:47:16
頑張って読んだ
要するにお前の主張は
「int main(void)って書くの気持ち悪い！気持ち悪いよねお前らもそう思うだろ！！」
だな？
じゃあそれに対する答えは
「規格が許してるんだから書きたいやつが書いて何も問題ねえしお前の好みなんか知るかボケ」
だよ
459:デフォルトの名無しさん
08/11/20 23:00:06
呼び出し規約とか関係ねぇから
460:デフォルトの名無しさん
08/11/20 23:02:42
>>452
main を見てスタートアップコードを作るんだろ・・・。
何で先にスタートアップコードがあるんだよ。
バカかよ。
461:デフォルトの名無しさん
08/11/20 23:03:55
voidって空って意味だから、int main(void）って書いて
引数リストが空だってことを明示している方がわかりやすい。
int main()だと、引数リストがvoidなのかdon't careなのか不明確。
int main(void)が気持ち悪いってやつは英語のセンスがないんだろうね
462:デフォルトの名無しさん
08/11/20 23:05:03
>>453
規格上はそれで問題ない。
関数定義での () は (void) と規格上は等価だから
（関数原型ではもちろん () と (void) は別だが）。
でも、その規格に準拠していないコンパイラがあるから
已む無く (void) をつけているに過ぎない。
463:デフォルトの名無しさん
08/11/20 23:10:15
>>457
dat落ちしてるなら内容も貼って欲しいよね。
ｽﾚﾘﾝｸ(tech板:951番)
951 名前：デフォルトの名無しさん[sage] 投稿日：2008/11/16(日) 21:46:28
>>949
個人的には、int main(void); という書き方に不満があります。私なら int main(); とします。でも、cdecl でも stdcall でも通用するようにしたいのでしょうけれども。
464:デフォルトの名無しさん
08/11/20 23:11:25
では採決します。
int main(void)が気持ち悪いと思う人いますか？
465:デフォルトの名無しさん
08/11/20 23:12:16
気持ち悪くないが C++ やってると面倒くさいとは思う。
466:デフォルトの名無しさん
08/11/20 23:12:49
>>456
発言したが私であることを特に問題にはしていないのですけれども。
467:デフォルトの名無しさん
08/11/20 23:13:20
>>457
それはあなたの事情であって私の知ったことではありません。
468:デフォルトの名無しさん
08/11/20 23:15:45
>>466
単発のレス読んでると何が言いたいかﾜｶﾝﾈってんだよ
469:デフォルトの名無しさん
08/11/20 23:17:42
>>458
main() に与えられる引数を使用しない場合に int main(void) と特に規定したのはどういう理由だろうか？
という点です。その理由が基本的によくわからない（ある程度の推測はあるにしても）し、普通の関数ではそんなふうには書かないので、
これは問題ではないか、ということを問題にしています。
規格そのものを問題にしている以上、「規格が許しているんだから」は答えにならないのは自明なのですが。
470:デフォルトの名無しさん
08/11/20 23:17:53
>>468
あなたの理解力不足を人のせいにするのはやめてくれませんか？
471:デフォルトの名無しさん
08/11/20 23:19:14
>>469
普通の関数でも void 書くだろ・・・。
472:デフォルトの名無しさん
08/11/20 23:19:46
>>469
ダウト。
普通の関数でも引数リストでhoge(void)って使います。
473:デフォルトの名無しさん
08/11/20 23:20:14
>>460
いいえ、スタートアップコードがあって、main() がそれにリンクするのです。
スタートアップコードを使い分けるにしても、それは同じこと。
大体スタートアップコードを使い分けているコンパイラがありますか？
そんな処理系は printf() をはじめとする可変長引数の関数が一切使えないのではないかと。
474:デフォルトの名無しさん
08/11/20 23:20:19
>>469
,､‐ ''" ￣ ｀`'' ‐- 、
／イハ/レ:::/V＼∧ド＼
／::＾'´::::::::::::i､::::::::::::::::::::::::::::＼
‐'7::::::::::::::::::::::::ハ:ﾊ::|ヽ:::;､::::::::::::丶
／::::::::::::::/!i::/|/ ! ヾ ﾘハ:|;!､:::::::l
/´7::::::::::〃|!/_,,、 ,､==､､''`‐ly:::ﾄ
/|;ｨ:::::N,､‐'゛_,,.＼ !"r‐､ヽ !;Ｋ
! |ﾊﾄ〈 ,r''"゛ , ヽﾟ,シ ﾘｲ)|
`y't ヽ' ,,ｨｧ /／
! ぃ､ ト─=ニニ‐ノ 〃
｀'' へ｀`'ｰ─‐‐'´, .ｲ
`i;､ ／ l
〉 ` ‐ ´ l`ヽ
／ ! ﾚ' ヽ_
_,､‐7 i| i´ l ｀' ‐ ､_
,､-‐''"´ ﾉ,､-､ / ､,_ ,.､- {,ﾍ '､_ ｀ヽ､_
／ i ,､ｲ ∨ l.j__,,､..-‐::-:;」,ハ、 '､｀ ‐､_ ,`ヽ
/ l ,､‐'´ /／ ',／!:::::::::;､--ｧ' / ｀` ‐ ｀'7゛ ',
475:デフォルトの名無しさん
08/11/20 23:21:26
int foo(void)なんて喜んで書く人は、悪いけどプログラミングのセンスを疑いますよ
バカにしてるとさえ感じますね
コンパイラや保守者や、Cという言語に対しても
476:デフォルトの名無しさん
08/11/20 23:22:12
>>472
あなたとは仕事をしたくない
477:デフォルトの名無しさん
08/11/20 23:22:26
void 書かないと引数書き放題だろ・・・。
バカか、こいつ。
478:デフォルトの名無しさん
08/11/20 23:24:44
>>461
引数を指定するのに呼び出し側を考慮しないのはどうかと思います。
それに、スタートアップで引数をスタックに積んでいる以上、main（） の場合は do not care のほうが適当かと。
＞英語のセンスが
英語のセンスなど別にどうでもいいです。