★　ANSI Cでいこうよ　★

■掲示板に戻る■ ■過去ログ倉庫めにゅーに戻る■

1 名前： 標準なおんなのこ 投稿日： 2001/07/11(水) 23:33: 　　　　　　　_ -――-,-―- 、
　　　　_／　　　　　　　　　　ヽ＿
　　／　　,　,　　　　　　　　ヽヽX ７ヽ、
　　i' /　// /　/　 |　ヽヾ. 　､ヽヽX X ゝ
　/|　|　| |　|_⊥｣| || | |.|｣⊥_ |　 iミﾐ､X /
　　V|　| || i|_⊥、W./ヽ|,|⊥_||ヽ|≡= x/
　　ヽNヽ| ,|し.j 　　　 _|し.jl|｀　|T Τ7　　　／￣￣￣￣￣￣￣
　　　 |　|.{　￣　 .'_,　　￣ ||　 | |　||+ヽ　＜　あははー、ANSI Cでプログラムしませんか？
　　　 |　| i＼　　　　　　 .１ |　 | |　|| +|　　＼＿＿＿＿＿＿＿
　　　|　 | | 　i　: エエ :´ : | |　 | |　||++|
　　　| _ | | 　|´ ￣只￣ヽ|　|　 |_|　||++|
　　　/　||　　|　ノ || ヾ　 |　|　 | ヽ| |++|
　　　|　||　　|- ´ i | | i ｀ｰ|　 |　 |　 | ||++|
　　　|　|　　 |　　| | .| |　　|　 |　|　　| ||￣

標準規格限定です。
標準ライブラリ、STLなどなど

MFC,VCLなどは禁止です
2 名前： デフォルトの名無しさん 投稿日： 2001/07/11(水) 23:34: C99ってまるで話題にならんな
3 名前： デフォルトの名無しさん 投稿日： 2001/07/11(水) 23:37: >>1
葉鍵板に逝け。
それから、数式プログラムを組むときはだいたいＣのみで書くよ
4 名前： デフォルトの名無しさん 投稿日： 2001/07/11(水) 23:40: >>3
むしろ葉鍵版からきたと思うが・・。
5 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 00:05: 1のＡＡかわいいね。
これって何のキャラ？
6 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 00:07: むしろ一切ライブラリなしの
「Plain C」限定でプログラムしま（？
7 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 00:40: さゆりん☆
8 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 00:43: >>6
システムコールは使ってもヨィですか？
9 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 00:49: >>6
インラインアセンブラもつかっていいの？
10 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 01:00: MMX拡張命令を使ってもヨロシイですか？
11 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 01:02: ほよよよ。困った。６は無視して。ごめん。
12 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 01:29: C系スレ立てすぎ。
13 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 02:40: 6は絶対無理だろ。
Cでそれをやると、なんぼ処理をしても
(その処理自体もロクなのが書けないだろうが)
その情報を入出力する手段が
いっさい無いことになるぞ。
君のディスプレイは真っ黒なままだ。
見た目、なにも動いていないのと等価だ。
それをプログラムと呼ぶのは完全に自己満足。
なにせ誰にも動いていることが「わからない」のだから。
14 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 09:38: 最後にコアダンプさせます。
15 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 10:24: void main(void)
{
　printf( "はろーわーく\n" );
}
16 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 11:56: >>13 絶対か？
plain Cで次のはできるんだろ？

int (*sys)() = (int *)0x00hogehoge;
17 名前： しつもんしつもーん！ 投稿日： 2001/07/12(木) 21:39: ＡＮＣＩ-Ｃの本家マニュアルってどこにあるか知ってるひといますか？
18 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 21:46: >>17
JISハンドブックを読め。
無理してANSIの規格書を読んでも無意味。JIS X3010は2nd Edition（C99）には対応
してないけど、それ以外なら日本語で読める。それに日本ではJISこそが標準であって、
ANSIなどどうでもよい。
19 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 21:52: >>16
無知（>>13）は相手にするな。
入出力などplain Cですべて書ける。一番厄介なのは、ブート時のスタック
ポインタの設定とか、割り込みベクタの記述とかだろ。
これを処理系に依存しない規格合致プログラムとして書くことはまず不可能。
20 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 22:04: >>19
それって、入出力はライブラリを使わなくても、環境依存しないで
かけるってこと？
21 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 22:10: >>20
どっかでやってた話だな・・・結論から言うと、
環境に依存するものならライブラリ使わなくても書ける。
22 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 22:12: >>21
じゃ、19は無知ってことで。
23 名前： 17＞18 投稿日： 2001/07/12(木) 22:53: 兄貴、どうもです。
24 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 23:13: >>22
いや、そんなことはないよ。
環境に依存するもの＝移植性の低いもの
ならライブラリを使わなくてもプレーンで書ける
って感じ（大爆笑）
25 名前： デフォルトの名無しさん 投稿日： 2001/07/13(金) 00:02: http://www.lysator.liu.se/c/

ISO Cって言え
26 名前： 17 投稿日： 2001/07/13(金) 00:29: む？＞25
27 名前： デフォルトの名無しさん 投稿日： 2001/07/13(金) 05:45: さゆりあげ
28 名前： デフォルトの名無しさん 投稿日： 2001/07/13(金) 06:15: ウザ。
29 名前： デフォルトの名無しさん 投稿日： 2001/07/13(金) 07:23: age
30 名前： デフォルトの名無しさん 投稿日： 2001/07/13(金) 11:53: そう言えば、CってISOにもJISにもなってるのに
誰も「ISO C」とか「JIS C」なんて言わないよね。
31 名前： デフォルトの名無しさん 投稿日： 2001/07/13(金) 11:55: 事実上標準になっていないから
32 名前： デフォルトの名無しさん 投稿日： 2001/07/13(金) 13:23: >>24
入出力に割り込み命令使わなきゃいけない環境とかはどうするの？
33 名前： デフォルトの名無しさん 投稿日： 2001/07/13(金) 13:45: >>32
なんとでもなるだろ
34 名前： 32 投稿日： 2001/07/13(金) 15:16: >>33
インラインアセンブラ使わずに、しかもライブラリなしでだよ？
35 名前： デフォルトの名無しさん 投稿日： 2001/07/13(金) 15:18: >>34
インラインアセンブラはいるかもね。
なくてもいけそうな気はするけど。
ライブラリはなくてもいいだろ。
36 名前： デフォルトの名無しさん 投稿日： 2001/07/13(金) 15:38: もはやＡＮＳＩの領域とは思えず
37 名前： ＞３６ 投稿日： 2001/07/13(金) 20:50: なんの領域といえばいいでしょう
38 名前： デフォルトの名無しさん 投稿日： 2001/07/13(金) 20:52: >>37
神・・・そう、神の領域
39 名前：ﾜﾗ投稿日： 2001/07/13(金) 21:05: 　
40 名前： デフォルトの名無しさん 投稿日： 2001/07/13(金) 21:47: >>31 ISOもJISもANSIと一緒だからじゃないの？ANSIが一番最初だからでしょ。
41 名前： デフォルトの名無しさん 投稿日： 2001/07/14(土) 15:17: >>35
unsigned char foo[] = {
0x80, 0x3f, 0x00, /* foo: cmp byte ptr [bx],0 */
0x74,0x06, /* jz done */
0x80,0x07,0x20, /* add byte ptr [bx],32 */
0x43, /* inc bx */
....
}

int (*sys)() = (int *)foo;

ってな感じでやればインラインアセンブラいらんぞ。
機種依存だがＡＮＳＩは満たしているだろ？
割り込みベクタの設定も、割り込みルーチンも
この中で設定すればよろしい。
42 名前： デフォルトの名無しさん 投稿日： 2001/07/14(土) 15:44: 満たしてねーよバカ！
43 名前： デフォルトの名無しさん 投稿日： 2001/07/14(土) 16:11: >>42
アホみたいな疑問ですまないんだけど、どこが満たしてない？
単なるバッファを関数とみなして呼び出しているから？
それって違反事項なんだっけ？
いけないという記述が見当たらないので。
44 名前： ４２じゃないが、 投稿日： 2001/07/14(土) 21:12: 処理系に依存する機能を前提にプログラムすることは
ＡＮＳＩを満たしているといえるのだろうか？
45 名前： デフォルトの名無しさん 投稿日： 2001/07/14(土) 21:50: もちろんいえる
というかANSIはそんなことを規定しない

*(*int)0 = 0
だってもちろん合法
46 名前： デフォルトの名無しさん 投稿日： 2001/07/14(土) 22:40: >>41
>int (*sys)() = (int *)foo;

もちっと関数へのポインタを勉強したほうがいい。
47 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 00:26: 初心者でごめんなさい。
>>45の
*(*int)0 = 0
が全くわかりません。教えてください。
48 名前： 45じゃないけど 投稿日： 2001/07/15(日) 00:31: *(int*)0 = 0;
多分こうしたかったんだろう>47

int *p = 0;
*p = 0;
と同じ事
49 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 01:22: >>46
確かに>>41は関数ポインタを勉強した方がいいが、エラーではない。
50 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 02:17: 現在使用しているソケットが通信可能であるかどうかを
判断するための関数は、Selectでよいのでしようか？
また、UNIXソケットのselectと、WinSockのSelectの使い方
は同じでよいのでしようか？
51 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 02:22: >>50
どちらもselectで良い。
使い方は両方ともほぼ同じ。
windowsの場合、非ブロッキングI/Oを使ったより効率の良い
方法があるけど、ロジックが面倒になるので知るのは後回しで良い。
後はsocket selectで検索。
52 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 02:24: 誤爆ですか? こっちで聞けや
http://piza.2ch.net/test/read.cgi?bbs=tech&key=970344582&ls=100
53 名前： 標準なおんなのこ 投稿日： 2001/07/15(日) 04:16: 激しく脱線してるんですけど、この話題だめですかー？
いまMFCでプログラム作っても２・３年後位にゴミになりそうで欝なんですっっ（涙

長く使える技術を習得しよう！
54 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 04:32: MSの本やMFCベタなプログラムは２年後には燃えないゴミです。
55 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 04:38: プログラムはともかく、本は燃えるんじゃない？>54
56 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 04:50: 上質紙はリサイクルできます　ご協力下さい
57 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 05:18: MSの本やMFCベタなプログラムは現時点でも萌えないゴミです。
58 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 05:42: >>52
スマン。誤爆。
>>51
誤爆のに教えていただいてありがとうございました。
59 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 06:01: ANSI Cのいい本ってない？
あとSTLの勉強もしたい
60 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 06:05: ASSERTの説明がある本に良書が多いのは気のせい？
61 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 08:39: >>60
もしかしてassertのこと？
Visual C++のASSERTなら論外。
62 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 12:57: 厨房 >>42 はANSIを満たしているかどうかを判断できず
ただ吠えたかったのか　藁
63 名前： いまいちassertの使い方がわからない名無し 投稿日： 2001/07/15(日) 13:19: >>61
なんで？
ドキュンなんでassertとASSERTの違いを知りません。教えてください。
64 名前： デフォルトの名無しさん 投稿日： 2001/07/15(日) 14:32: >>62
でも大切なことに気付かせてくれた上に
その疑問も後の応答で解決したので
こういうボケも2chでは大切なのかも。
65 名前： 61 投稿日： 2001/07/15(日) 22:09: >>63
まず、ASSERTはassertと違って標準Cの規格外だということ（Microsoftの独自拡張）。
実用面では、assertは評価式が出力されるけど、ASSERTはファイル名と行番号しか出力
されない。
ASSERTについてしか触れていない本は、大抵MFCを対象としたものばかりで、その段階で
良書は少なくなる。
66 名前： 44 投稿日： 2001/07/16(月) 02:12: >>45
ANSI準拠のコードは可搬性があるとは言えないという結論でよいのか？
67 名前： デフォルトの名無しさん 投稿日： 2001/07/16(月) 02:35: >>66
あたりまえだけど、
ANSI準拠でも処理系に依存したコードを書くと移植性はなくなります。
68 名前： デフォルトの名無しさん 投稿日： 2001/07/16(月) 08:59: ＡＮＳＩ・ＩＳＯ・ＪＩＳの規格と、Microsoft等企業の独自拡張でまぎらわしいのって多い？
69 名前： デフォルトの名無しさん 投稿日： 2001/07/16(月) 10:55: >>68
かなりあるよ。
知っている範囲で最も紛らわしいのは、tmpnamと_tempnam関数。
名前も仕様も非常に紛らわしい。
POSIX規格とMicrosoftの独自拡張の間はさらに紛らわしい。
あと、C++ならISO規格のexportとMicrosoftの__exportとか。名前は似て
いるけど、用途は全く異なる。（現在は__declspecを使うから少しましかな）
70 名前： デフォルトの名無しさん 投稿日： 2001/07/16(月) 11:07: >>49
今更だけど、>>41はエラーだよ。
71 名前： 69 投稿日： 2001/07/16(月) 12:20: よく考えたらtempnamはPOSIXの関数だった。
それに、最も紛らわしいのはswprintf関数だった。

ISO規格: int swprintf(wchar_t*, size_t, const wchar_t*, ...);
Microsoft: int swprintf(wchar_t*, const wchar_t*, ...);
72 名前： デフォルトの名無しさん 投稿日： 2001/07/16(月) 13:14: >>70
warningは出てもstrict-ansiでコンパイルできるぞ？
73 名前： デフォルトの名無しさん 投稿日： 2001/07/16(月) 13:14: >>71
これはMicrosoftの方が自然だと思う
snprintfがある処理系って結構あるし
74 名前： デフォルトの名無しさん 投稿日： 2001/07/16(月) 14:40: >>72
オブジェクト型のポインタと関数型のポインタにはそもそも互換性が全く
ない。
どんな処理系を使ったのか知らないが、規格合致処理系であれば、確実に
エラーになる。
どうしてもオブジェクト型のポインタから関数型のポインタにキャストし
たいのなら、

int (*sys)() = (int(*)())(int)foo;

のような感じで、いったん整数型を介さないといけない。
75 名前： 71 投稿日： 2001/07/16(月) 15:22: >>72
自然かどうかより、sprintfの問題点（バッファのサイズを指定できない）を
持ち越さないために、Amendment1で追加されたswprintfはsize_t型の引数を
渡すようにしたはず。
それをchar文字列版に適用したsnprintfがC99で追加された。
つまり、安全面からすれば、Microsoftの仕様はsprintfと同じ問題点を持って
いることになる。しかも非標準。
もっとも、Microsoftのwchar.hは、C++でしかコンパイルできないし、
__STDC_VERSION__マクロが定義されないことからしても、Amendment1に対応し
ていないと見るべきなのかもしれない。
76 名前： デフォルトの名無しさん 投稿日： 2001/07/16(月) 15:58: >>1 てめぇ犯すぞゴルァ
77 名前： デフォルトの名無しさん 投稿日： 2001/07/16(月) 17:00: >>74
ANSI CとC++を勘違いしてないか？
78 名前： 71 投稿日： 2001/07/16(月) 17:24: >>75
Microsoftのライブラリには、swprintfも_snwprintfもあるよ
size_tを受け取るsnprintfが標準仕様に追加されたのなら、
swprintfがsize_tを受け取るのは明らかに変だと思うのだが
79 名前： 71 投稿日： 2001/07/16(月) 18:01: >>78
Microsoftの処理系を使っていると、wsprintfや_stprintfからの類推で
あたかもswprintfがsprintfと対応する関数のような錯覚を起こしがち。
実際に対応するのはswprintfとsnprintfであって、sprintfワイド文字列
版は存在しない。sprintfは前述のような問題点があるので、過去のコード
との互換性のためだけに今後は存続すると見た方がよいのでは。

それから、紛らわしいので、人の名前を勝手に名乗らないように。
80 名前： デフォルトの名無しさん 投稿日： 2001/07/17(火) 00:22: なんだぁＡＮＳＩってこんなに方言ＯＫ仕様なのか。
結局ＡＮＳＩもＫ＆Ｒと同じ穴の狢だったか。
81 名前： デフォルトの名無しさん 投稿日： 2001/07/17(火) 07:55: >>ALL
どうでも良いが、処理系依存のコードを書くのに、
ANSIに準拠したコードを書く意味はあるのか？

>>41
>インラインアセンブラいらんぞ。
アドレスの参照が、限りなく面倒。
mov ebx,dword ptr [_table] ;等々
それでも、それをやった場合、コンパイラを使う意味は何処にある？
よって、インラインアセンブラは必要。
82 名前： デフォルトの名無しさん 投稿日： 2001/07/17(火) 09:34: >>81
>どうでも良いが、処理系依存のコードを書くのに、
>ANSIに準拠したコードを書く意味はあるのか？
禿げしく同意。
しかし、完全な合致プログラムは命がけ！
83 名前： 78 投稿日： 2001/07/17(火) 09:52: >>79
別にそれを使う使わないの問題じゃなくて
標準仕様の方が変じゃない？って言ってるだけ
だって、類推すると、snwprintfになるわけでしょ？

確かにsprintf自体がgetsと似た問題をはらんでる
わけだし、それ自体を変えたいのかなとも思うけど。
だからと言って、wsprintf->snprintfのワイド版
ってのは誤解を招く結果になるだけじゃないかな？

ｽﾏｿ…ﾊﾞﾝｺﾞｳﾏﾁｶﾞｴﾀ…ｲｯﾃｷﾏｽ
84 名前： デフォルトの名無しさん 投稿日： 2001/07/17(火) 10:39: _snprintf()
_snwprintf()
wsprintf()
等はＡＮＳＩ以外のところで勝手に作られた関数。
話がややこしくなるので持ち出すのはやめよう。
85 名前： 関数名無しエラーさん 投稿日： 2001/07/19(木) 10:57: ANSIを満たしたすべての処理系で正常に動作するプログラム
ってことでいいのかな？>1は。

ところで、gccやmsｖｃやbccとか、
最近？の処理系って皆対応してると考えていいの？

まあ、細かい所は色々解釈の違いがあるのかな？
86 名前： デフォルトの名無しさん 投稿日： 2001/07/19(木) 17:19: >まあ、細かい所は色々解釈の違いがあるのかな？
ANSIって
解釈の違い＝処理系に依存していること
どうコンパイルすべきか決められない事態＝未定義の仕様
って感じのごまかし方だったような…
87 名前： デフォルトの名無しさん 投稿日： 2001/07/19(木) 19:12: >>86 実質整数型しか持たないＫ＆Ｒにプロトタイプで色づけして
普通の言語っぽくしたところはＡＮＳＩの功績だと思うけど、
Ｋ＆Ｒ互換を残したのが結果としてユーザーの不利益になった
と思う。C++程度の型の強さをあの時点で導入していたら
（ＯＯじゃなくてね）ずいぶん世の中見とおしがよかったと
思うんだけどな。
88 名前： デフォルトの名無しさん 投稿日： 2001/07/19(木) 21:28: sprintfとwsprintfの違いってなに？
あんましsprintf使ってないからわからん。
89 名前： デフォルトの名無しさん 投稿日： 2001/07/19(木) 21:45: >>88
wsprintfはWindowsでしか使えないのと、対象となる型がTCHAR配列。
sprintfはホスト環境規格合致処理系なら必ず使えて、対象となる型が
char配列。
細かなことを言えば、wsprintfはエラーが発生したときにGetLastError
で原因を調べられるとか、C99に処理系が対応した場合には、sprintfを
使わないとlong long型を扱えなくなるとか。
90 名前： デフォルトの名無しさん 投稿日： 2001/07/19(木) 23:16: ホスト環境規格合致ってナニ？
91 名前： デフォルトの名無しさん 投稿日： 2001/07/19(木) 23:41: ホストの環境の規格が合致してる処理系のこと。
92 名前： 89 投稿日： 2001/07/20(金) 08:20: >>90
一口に規格合致処理系といっても、フリースタンディング環境もあるから、明示的に
ホスト環境といっているだけ。要は、パソコンやワークステーションのようなフル
セットのOS上で実行させるような環境がホスト環境。組み込み機器のようにOSなしで
実行させるような環境がフリースタンディング環境。
フリースタンディング環境では、stddef.hやlimit.hなどいくつかのヘッダはあるも
のの、ライブラリ関数は標準では一切サポートされない。
93 名前： デフォルトの名無しさん 投稿日： 2001/07/20(金) 13:30: ホスト環境規格合致=ANSI規格合致ってことっすね。

しかし、合致プログラミングってやればやるほどキリがないよ。
例えば１バイトが８ビットじゃないかもしれないって規格書には書いてあるよ。
そんな、殆どありえないような環境まで面倒みきれないのが現実。

合致レベルを設けてどこまでやるかの線引きをするか、
カテゴリ分けをしてカテゴリ間の互換性に制限を付けるか
して欲しいよ。
94 名前： デフォルトの名無しさん 投稿日： 2001/07/20(金) 15:19: >>93
ACOS-6だと恐らく９ビット下手したら６ビットだよ。
ありえないなんてことなく現実にそれなりに使われているマシンで
そういうことがある。
だから「その処理系でもっとも効率の良い語をintにする」なんて
言語で互換性うんぬんするのがそもそも間違いではなのか？
95 名前： デフォルトの名無しさん 投稿日： 2001/07/20(金) 17:39: POSIXにまで限定してもなお非互換が山のように残る。
これだからJavaが流行るんだよな。
96 名前： デフォルトの名無しさん 投稿日： 2001/07/20(金) 18:03: >>93
>ホスト環境規格合致=ANSI規格合致ってことっすね。
これは違う。ANSI規格合致処理系には、ホスト環境規格合致処理系と、
フリースタンディング環境規格合致処理系の２種類があるということ。

>>94
CHAR_BITは8以上と定められているので、1バイト=6ビットの処理系は
非標準。
最も効率の良い型をintにするのは、特に互換性の妨げにはならない。
最低限の範囲が-32767～+32767と規定されているので、その範囲内で
使えばよいだけのこと。
どうしてもサイズに依存するときは、stdint.hで定義されるint32_t
とかを使えばよい。
97 名前： デフォルトの名無しさん 投稿日： 2001/07/21(土) 12:10: >>96 互換性を逸脱する利用時に警告を出すなりの処理系がなければ
その範囲内で使えというのは現実問題として無理だろ。
実質互換性がないことの反証にはならないぞ。
98 名前： 96 投稿日： 2001/07/21(土) 13:59: >>97
それは単なるスキル不足。
99 名前： デフォルトの名無しさん 投稿日： 2001/07/21(土) 14:26: >>98
分かっていないな、個人のスキルに依存する方法で
互換性を保つという方法論そのものがだめだっていってるんだよ。
世の中に出まわっているソフトを>>96の言うような整数の範囲に
変更できるか？
100 名前： 96 投稿日： 2001/07/21(土) 15:50: >>99
移植性のあるコードを書くのは、そもそも相応のスキルが要求されるはず。
元々スキルの低い人間の手によるものや、移植性を考慮していないもの、
非標準の処理系を用いて作成されたものを、後から変更することなどは、
対象にしていない。

どんなにスキルの低い人間がプログラムしても互換性を保てるような言語
は、所詮大したことはできないよ。
101 名前： デフォルトの名無しさん 投稿日： 2001/07/21(土) 16:36: >最低限の範囲が-32767～+32767
そもそもこれ自体現実的な制約ではないから、スキルがあれば
ＯＫとはならないんだよ。整数をこの範囲に保ってコードを
書いてあるプログラムがどれだけあるのか。
非現実な範囲でしか移植性のない言語は言語仕様に問題がある。
102 名前： 96 投稿日： 2001/07/21(土) 18:12: >>101
現実的な制約でないというと、ほとんどの環境では負値に２の補数を使う
からということかな？
その場合でも、-(-32767-1)は-32768になってしまって正しい動作が期待
できないから、やはりそんな値を使うこと自体が間違っている。論理演算
なら問題ないだろうけど、その場合には16ビットの範囲を守ることはたや
すいからね。
もし、-2147483648～+2147483647が一般的な範囲だと思っているなら、
それはとんでもない間違いだよ。
103 名前： デフォルトの名無しさん 投稿日： 2001/07/21(土) 23:13: >>102
昔の16bit時代からやってる人なら、ちょっと大きな数がでてきそうな
ときには int ではなく long と書くのが普通。

でも最近の人はわかんないよ。int = long あたりまえと思ってる人が
多い。あと long = 32bit と仮定してるクソコードもたくさんあって、
Linux-AXP なんかで困る。
104 名前： デフォルトの名無しさん 投稿日： 2001/07/21(土) 23:24: Linuxのアプリケーションは、アドレスの表現に
unsigned long 使う風習があるんだけど
これってどう思う？
アドレス幅といっしょなのって、大抵intの方じゃない？
勘違いならごめんよ
105 名前： デフォルトの名無しさん 投稿日： 2001/07/21(土) 23:41: linux,win32,BeOSでとりあえず動くプログラム組んだけど
2の補数とワードのビット数をそろえるように設定するのは必須ですな。
完全 ISO-C じゃ非常に冗長なコードになるから
1の補数とかの環境は初めから捨てました。あとライブラリ関数が
かなり使えないのが苦しい。汎用性のある ISO-C のコードって
printf("hello"); くらいじゃないかな。(藁
まー、あまり期待はしてないけど K&R 時代よりは多少マシって
具合ですな。基本構造式まで処理系依存では逝ってしまいますので…。（藁
106 名前： 105 投稿日： 2001/07/21(土) 23:45: あ、でも型変換とか処理系依存が激しいんだよね…。
これが適切に決まっていればもっと良いコードが書けるんだけど
これも１の補数と２の補数の両方の存在を見とめているためだ…。
ちとむかつく。（藁
107 名前： デフォルトの名無しさん 投稿日： 2001/07/22(日) 05:31: >>104
そもそもポインタ＝数値という前提でプログラムすること自体が規格外
108 名前： デフォルトの名無しさん 投稿日： 2001/07/22(日) 08:32: >>107
そんなことないよ。intptr_tを使えばいいだけのこと。
109 名前： デフォルトの名無しさん 投稿日： 2001/07/22(日) 09:08: >>105-106
Linux, Win32, BeOSなんて、比較的よく似たプラットフォームだからそんな
ことを言っていられるんだと思うよ。
8ビット～64ビットCPUを対象にした組み込み用の汎用ライブラリを実装する
場合には、２の補数はともかく、算術型のサイズを特定することなど不可能。
それに、汎用性のあるISO Cのコードがprintf("hello");ぐらいというのは
まったく意味不明。

型変換が処理系依存って、有符合整数と無符合整数の間の型変換のこと？
そんなのはどちらでも正の値と分かっている場合以外、型変換すること自体
が間違っているよ。そもそも両者を混在させる必要なんてそうそうないはず。
110 名前： デフォルトの名無しさん 投稿日： 2001/07/22(日) 12:41: 109はド素人だな。放置。
111 名前： デフォルトの名無しさん 投稿日： 2001/07/22(日) 13:36: >>104 intは演算レジスタでは？
112 名前： 104 投稿日： 2001/07/22(日) 15:55: >>107
そう。規格外のことだと思う。
でもカーネル読んでるとそういうの多くてさ・・・

>>111
大抵、アドレスバスとデータバスの幅は同じだよね。視野狭い？
113 名前： デフォルトの名無しさん 投稿日： 2001/07/22(日) 17:20: 暗視？
114 名前： デフォルトの名無しさん 投稿日： 2001/07/22(日) 23:42: malloc()で領域を確保していないポインタに対して
freeをしたらどうなりますか？
怖くてできません。
115 名前： デフォルトの名無しさん 投稿日： 2001/07/22(日) 23:50: >>114
http://www.linux.or.jp/JM/html/LDP_man-pages/man3/free.3.html
116 名前： デフォルトの名無しさん 投稿日： 2001/07/23(月) 04:39: C++は、もう破滅寸前。
ここらでSTLに挫折した、全体の９５％相当のプログラマが
不買運動を起こし、消滅します。

ありがとうC言語！そしてC++さようなら！（^_^)また会えるといいね！

http://piza.2ch.net/test/read.cgi?bbs=tech&key=995820118&ls=100
117 名前： デフォルトの名無しさん 投稿日： 2001/07/23(月) 17:12: C89/C99 ANSI Cの両規格の話が混ざっているので話が
すれ違う。

>>112 64bit環境では通常（ＭＳ以外）sizeof(int)=4 sizeof(int *)=8
118 名前： デフォルトの名無しさん 投稿日： 2001/07/23(月) 17:28: >>112
Pentium以降のデータバスって64bitじゃなかった？

>>117
ちと意味が違うのでは？

64bit環境でintが32bitなのは、intも64bitにすると必然的に
longも64bitになって、charとshortだけじゃ16bitの型あたり
を切り捨てなきゃならないからでしょ？

既に、intがCPUのワード幅であるって前提は崩れてるよ
119 名前： デフォルトの名無しさん 投稿日： 2001/07/23(月) 18:17: ポインタのサイズが問題になるケースってどんなときなんでしょうか？
先月からCやりだしたのでいまいちよく分かりません。
120 名前： デフォルトの名無しさん 投稿日： 2001/07/23(月) 18:22: >>119
ポインタのサイズはすべて一定です。。
short a;
int b = 100;
a = &b;
とかすれば問題だが．．．
121 名前： デフォルトの名無しさん 投稿日： 2001/07/23(月) 18:29: >>120
ANSI Cってポインタのサイズは同一であるとみとめてたっけ・・・。
コード領域を指すためのポインタとデータを指すためのポインタのサイズが違うことは多々ある
122 名前： 120 投稿日： 2001/07/23(月) 18:33: >>121
そーだったんですか。はずかシー。
123 名前： デフォルトの名無しさん 投稿日： 2001/07/23(月) 19:57: >>118 >>104 == >>112 だから>>112は sizeof(int) == sizeof(int *)
と思っているってこと。
124 名前： デフォルトの名無しさん 投稿日： 2001/07/24(火) 03:30: >>122
でないとコンパクトモデルやミディアムモデルのMS-DOSの処理系が
規格準拠になりえないだろ
125 名前： デフォルトの名無しさん 投稿日： 2001/07/24(火) 09:44: コンパクトモデルはセグメント関係ないので、
全てのポインタは同じ幅(=16bit)と考えていいのでは？
（みであむは知らない）