トップページ⇒tech
125コメント40KB

★　ANSI Cでいこうよ　★

■ このスレッドは過去ログ倉庫に格納されています
0001標準なおんなのこNGNG
　　　　　　　_ -――-,-―- 、
　 　 　　_／　　　　　　　　　　ヽ ＿
　 　 ／　　,　,　　　　　　 　　ヽ ヽX ７ヽ、
　　i' /　// /　/　 |　ヽヾ. 　 ､ ヽ ヽX X ゝ
　/|　|　| |　|_⊥｣| || | |.|｣⊥_ |　 iミﾐ､X /
　　V|　| || i|_⊥、W./ヽ|,|⊥_||ヽ|≡= x/
　 　 ヽNヽ| ,|し.j 　　　 _|し.jl|｀　|T Τ7　　　／￣￣￣￣￣￣￣
　 　　 |　|.{　￣　 .'_,　　 ￣ ||　 | |　||+ヽ　＜　あははー、ANSI Cでプログラムしませんか？
　 　　 |　| i＼　　　　 　　 .１ |　 | |　|| +|　　＼＿＿＿＿＿＿＿
　 　　|　 | | 　i　: エ エ :´ : | |　 | |　||++|
　 　　| _ | | 　|´ ￣只￣ ヽ|　|　 |_|　||++|
　 　　/　||　　|　 ノ || ヾ 　 |　|　 | ヽ| |++|
　 　　|　||　　|- ´ i | | i ｀ｰ|　 |　 |　 | ||++|
　 　　|　|　　 |　　| | .| |　　|　 |　|　　| ||￣

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

MFC,VCLなどは禁止です
0002デフォルトの名無しさんNGNG
C99ってまるで話題にならんな
0003デフォルトの名無しさんNGNG
>>1
葉鍵板に逝け。
それから、数式プログラムを組むときはだいたいＣのみで書くよ
0004デフォルトの名無しさんNGNG
>>3
むしろ葉鍵版からきたと思うが・・。
0005デフォルトの名無しさんNGNG
1のＡＡかわいいね。
これって何のキャラ？
0006デフォルトの名無しさんNGNG
むしろ一切ライブラリなしの
「Plain C」限定でプログラムしま（？
0007デフォルトの名無しさんNGNG
さゆりん☆
0008デフォルトの名無しさんNGNG
>>6
システムコールは使ってもヨィですか？
0009デフォルトの名無しさんNGNG
>>6
インラインアセンブラもつかっていいの？
0010デフォルトの名無しさんNGNG
MMX拡張命令を使ってもヨロシイですか？
0011デフォルトの名無しさんNGNG
ほよよよ。困った。６は無視して。ごめん。
0012デフォルトの名無しさんNGNG
C系スレ立てすぎ。
0013デフォルトの名無しさんNGNG
6は絶対無理だろ。
Cでそれをやると、なんぼ処理をしても
(その処理自体もロクなのが書けないだろうが)
その情報を入出力する手段が
いっさい無いことになるぞ。
君のディスプレイは真っ黒なままだ。
見た目、なにも動いていないのと等価だ。
それをプログラムと呼ぶのは完全に自己満足。
なにせ誰にも動いていることが「わからない」のだから。
0014デフォルトの名無しさんNGNG
最後にコアダンプさせます。
0015デフォルトの名無しさんNGNG
void main(void)
{
　printf( "はろーわーく\n" );
}
0016デフォルトの名無しさんNGNG
>>13 絶対か？
plain Cで次のはできるんだろ？

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

ISO Cって言え
002617NGNG
む？＞25
0027デフォルトの名無しさんNGNG
さゆりあげ
0028デフォルトの名無しさんNGNG
ウザ。
0029デフォルトの名無しさんNGNG
age
0030デフォルトの名無しさんNGNG
そう言えば、CってISOにもJISにもなってるのに
誰も「ISO C」とか「JIS C」なんて言わないよね。
0031デフォルトの名無しさんNGNG
事実上標準になっていないから
0032デフォルトの名無しさんNGNG
>>24
入出力に割り込み命令使わなきゃいけない環境とかはどうするの？
0033デフォルトの名無しさんNGNG
>>32
なんとでもなるだろ
003432NGNG
>>33
インラインアセンブラ使わずに、しかもライブラリなしでだよ？
0035デフォルトの名無しさんNGNG
>>34
インラインアセンブラはいるかもね。
なくてもいけそうな気はするけど。
ライブラリはなくてもいいだろ。
0036デフォルトの名無しさんNGNG
もはやＡＮＳＩの領域とは思えず
0037＞３６NGNG
なんの領域といえばいいでしょう
0038デフォルトの名無しさんNGNG
>>37
神・・・そう、神の領域
0039ﾜﾗNGNG
　
0040デフォルトの名無しさんNGNG
>>31 ISOもJISもANSIと一緒だからじゃないの？ANSIが一番最初だからでしょ。
0041デフォルトの名無しさんNGNG
>>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;

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

*(*int)0 = 0
だってもちろん合法
0046デフォルトの名無しさんNGNG
>>41
>int (*sys)() = (int *)foo;

もちっと関数へのポインタを勉強したほうがいい。
0047デフォルトの名無しさんNGNG
初心者でごめんなさい。
>>45の
*(*int)0 = 0
が全くわかりません。教えてください。
004845じゃないけどNGNG
*(int*)0 = 0;
多分こうしたかったんだろう>47

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

長く使える技術を習得しよう！
0054デフォルトの名無しさんNGNG
MSの本やMFCベタなプログラムは２年後には燃えないゴミです。
0055デフォルトの名無しさんNGNG
プログラムはともかく、本は燃えるんじゃない？>54
0056デフォルトの名無しさんNGNG
上質紙はリサイクルできます　ご協力下さい
0057デフォルトの名無しさんNGNG
MSの本やMFCベタなプログラムは現時点でも萌えないゴミです。
0058デフォルトの名無しさんNGNG
>>52
スマン。誤爆。
>>51
誤爆のに教えていただいてありがとうございました。
0059デフォルトの名無しさんNGNG
ANSI Cのいい本ってない？
あとSTLの勉強もしたい
0060デフォルトの名無しさんNGNG
ASSERTの説明がある本に良書が多いのは気のせい？
0061デフォルトの名無しさんNGNG
>>60
もしかしてassertのこと？
Visual C++のASSERTなら論外。
0062デフォルトの名無しさんNGNG
厨房 >>42 はANSIを満たしているかどうかを判断できず
ただ吠えたかったのか　藁
0063いまいちassertの使い方がわからない名無しNGNG
>>61
なんで？
ドキュンなんでassertとASSERTの違いを知りません。教えてください。
0064デフォルトの名無しさんNGNG
>>62
でも大切なことに気付かせてくれた上に
その疑問も後の応答で解決したので
こういうボケも2chでは大切なのかも。
006561NGNG
>>63
まず、ASSERTはassertと違って標準Cの規格外だということ（Microsoftの独自拡張）。
実用面では、assertは評価式が出力されるけど、ASSERTはファイル名と行番号しか出力
されない。
ASSERTについてしか触れていない本は、大抵MFCを対象としたものばかりで、その段階で
良書は少なくなる。
006644NGNG
>>45
ANSI準拠のコードは可搬性があるとは言えないという結論でよいのか？
0067デフォルトの名無しさんNGNG
>>66
あたりまえだけど、
ANSI準拠でも処理系に依存したコードを書くと移植性はなくなります。
0068デフォルトの名無しさんNGNG
ＡＮＳＩ・ＩＳＯ・ＪＩＳの規格と、Microsoft等企業の独自拡張でまぎらわしいのって多い？
0069デフォルトの名無しさんNGNG
>>68
かなりあるよ。
知っている範囲で最も紛らわしいのは、tmpnamと_tempnam関数。
名前も仕様も非常に紛らわしい。
POSIX規格とMicrosoftの独自拡張の間はさらに紛らわしい。
あと、C++ならISO規格のexportとMicrosoftの__exportとか。名前は似て
いるけど、用途は全く異なる。（現在は__declspecを使うから少しましかな）
0070デフォルトの名無しさんNGNG
>>49
今更だけど、>>41はエラーだよ。
007169NGNG
よく考えたらtempnamはPOSIXの関数だった。
それに、最も紛らわしいのはswprintf関数だった。

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

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

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

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

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

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

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

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

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

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

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

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

どんなにスキルの低い人間がプログラムしても互換性を保てるような言語
は、所詮大したことはできないよ。
0101デフォルトの名無しさんNGNG
>最低限の範囲が-32767〜+32767
そもそもこれ自体現実的な制約ではないから、スキルがあれば
ＯＫとはならないんだよ。整数をこの範囲に保ってコードを
書いてあるプログラムがどれだけあるのか。
非現実な範囲でしか移植性のない言語は言語仕様に問題がある。
■ このスレッドは過去ログ倉庫に格納されています