C言語なら俺に聞け 151
■ このスレッドは過去ログ倉庫に格納されています
>>103 #include <stdio.h> int x, y; int main(void) { scanf("%d", &x); scanf("%d", &y); return 0; } 暗黙にxに書き込む関数とscanfは どっちが汎用性が高いか どっちが見通しがいいか 考えてみな >>105 おまえさんに解らせることはもう諦めた 放っといてくれ >>82 でイミフなこと言ってるなって思ったら単なる基地外やんw 結局「constを仮引数に使えないとき」というのがどんなときなのが全く分からず 「規格通りに書いてはならない」ケースが実在したのかしら いや 仕事で使ってませんから そもそも「毎回」っていうほど書いてませんし 何らかのツールで勝手に入るので「敢えて書く必要性がない」ということなのでしょうか それとも一律に「書くな」というルールが定着している組織が実在しているのでしょうか >>109 そうか、82がおまえさんはイミフなのか 悪いけど匙を投げるね >>104 にて scanf("%d", &x); と書かれているのですが、ターミナルから9を80字入力されたらどうなさるおつもりなのでしょうか また、signedともunsignedとも指定されておりませんが、その点はどのように汎用性を確保なさるのでしょうか >>114 俺に聞くな、規格票を嫁 http://kikakurui.com/x3/X3010-2003-01.html 104のコードが規格厳密合致プログラム(strictly conforming program)であることのみここに宣言する この命題を反証されたら、潔く敗北を認める では貴殿の返答を待つ intだけだったらsigned intになるっしょ。 近代的な環境なら、正しく書式を設定すればscanfはオーバーフローしない。 shortはsigned short、 longはsigned longだが、 charはコンパイラの設定によりsignedにもunsignedにもなる。普通はsignedだがな。 >>115 > 規格厳密合致プログラム 残念ながら、リンク先の日本語文章に定義が無く意味不明だったため これから英文を読むことにします 型の件含め、皆様の御教示に感謝します "shall" の訳文に、筆者の苦悩のようなものが見受けられました その点ふくめ、私は知らないことが非常に多いようで、ご迷惑をおかけしました >>65 >>56 struct S { int a[65536]; }; >>119 規格の中に現れる shall は十中八九「話者の意思」を示す 例文:You shall die. 超訳:「死ね!」 >>121 > 例文:You shall die. > 超訳:「死ね!」 さすがにそれは… 日本語の文章の方に "shall" は書かれてなかったもんで把握、と 示唆したつもりだったのですが、通じなかったようで、表現力につき反省する所しきりであります *'``・* 。 | `*。 ,。∩彡⌒ミ * みんなハゲにな〜れ + (´・ω・`) *。+゚ `*。 ヽ、 つ *゚* `・+。*・' ゚⊃ +゚ ☆ ∪~ 。*゚ `・+。*・ ゚ >>118 4. 規格合致性 規格厳密合致プログラム(strictly conforming program)は,この規格で規定する言語機能及びライブラリ だけを使用しなければならない(2)。さらに,いかなる未規定の動作,未定義の動作又は処理系定義の動作に依存する出力も生成してはならず,しかもどのような最低限の処理系限界も超えてはならない。 (2)規格厳密合致プログラムは,どの処理系でもサポートしているわけではない機能(附属書 F の中に例 がある。)を使うことができる。ただし,その機能を使うことができるのは,それが適切なマクロをもつ#ifdef 指令とそれに対応する#endif 指令とに囲まれている場合に限る。次に示すプログラム片がその例である。 #ifdef _ _STDC_IEC_559_ _ /* FE_UPWARD が定義されている */ /* ... */ fesetround(FE_UPWARD); /* ... */ #endif RFCなんかである要請の強度( MUST SHALL MAY ) みたいに使う用語の縛りはない? >>122 あくまで私見ですが、現代英語では will に単純に置き換えられるような shall の使い方はもうありえなく、 shall を使うのは shall を使う必然性があるから、だから、shall は辞書でいうところの「意志未来」であり、したがって shall を訳出しないのは不誠実な訳だとどうしても私は感じてしまいます… 「英文読解」の場ではなかったので控えていたのですが >>127 個人的には「こんなのを訳出させられた人は凄い」と思ってます 「原典は英語で日本語訳がある」もので「日本語訳が意味不明」の場合 原典で確認すると「訳出で明確ではない」部分が確認できるケースが多々あります "shall" をどのように訳出するかは個人差ありますし 今回の箇所が「以前同じ文言があったので単純にコピペした」ものかどうかは確認していません もちろん>>126 さんが仰るように「強度の要請で助動詞を変える」ものもありえますが C99の文書の場合は丁寧に "shall" の定義から書かれていますし、 何より "strictly conforming program" という表現は、明確に 4.5 での新情報です 昔の話。 若い頃K&Rの日本語版を買ってきて読み始めて、 間違いというか サンプルとしてよろしくない ところを見つけていた。 それが7年後に役立って 沢山仕事が入ってくるようになった。 本はキチンと読みましょう! >>129 面白そうな話の気もするが、抽象的すぎてよくさっぱりわからん。 せっかくだしもう少し詳しく教えて欲しい。 You shall die. 日本語の古語にすると分かりやすい 汝死すべし shallはべしに近い >>131 「べし」が二人称主語のときは「当然〜するべき」「義務」をあらわすことが多いですね ただしこの場合も、主観的な意見の場合・客観的な義務の場合の両方がありうるかもしれません shall=べき、べし、というのはいい線いっていると思います 日常会話や文学なら "You shall die." を「汝死すべし」と訳して 原文のもつ「お前死んだ方がいいよ」と「お前はいつか死ぬであろう」の 両方のニュアンス(他の解釈もあるかも)を残すってのはアリだと思うけど、 技術的な文章では、複数の意味に取れる書き方はしないでしょ。 翻訳の読者が欲しい情報も、原文がどちらを意図してるのか、だろうし。 ISO9001の要求事項とか見たことないのか? Shall: しなければいけない Should: した方が良い って訳すのは常識だぞ >>135 >>121 >>127 のとおり、shall は単純未来の可能性は捨て一律に意志未来に決め打ちしちゃっていいってことですね… 一年程度だが海外で仕事した経験のある俺にコメントさせてくれ。 shallにとくに意味はない。日本語に訳すのは難しいが方向性でいえば 汝死ぬ(shallなし) ↓ 汝はねぇ死ぬよ(shallあり) かな。 つまり特に意味はない。特に強調してるわけでもないけど、つまり断定か。 >>136 未来とか関係ない そうしないと規格に合致しねーぞって言うある意味条件だよ >>140 「意志未来」という言葉は辞書の言葉ですが、私の本意は >>121 つまり「規格」または「規格の書き手」が "You will die" という感情の含まれない淡白な表現を、それが実現するように強要する、それが "You shall die." いや、ほんとに意味はないんだよ。書き手がなんか気持ち悪いからshallつけてるだけでshall抜きでもかわらん。 willとかshouldに比べてshallどうとかじゃなくて、willとかshouldがなかったらどうかを考えるべき。 そもそも他言語を日本語で正確に訳せるってのは幻想でしかないから 規格でshallやshall notについて扱いが明記されてる(C11なら4.1〜4.2)以上それが全てでしょ >>141 だからお前さんの本意とかはどうでもいい 規格でのshall/shouldの解釈は > Shall: しなければいけない > Should: した方が良い って訳すのは常識って話 >>128 > 「英文読解」の場ではなかったので控えていたのですが (中略) > C99の文書の場合は丁寧に "shall" の定義から書かれています これ以上、「C言語のスレ」として、どんな話題あるんですか 「ANSI C(なりC90なり)」「C95」「C11」を持ち出すなら意味があるかも知れませんが? あと、そんなに辞書が好きならshallに「(法律・商業)〜(すべき)である, 〜(するもの)とする, 〜のこと」ってあるからそれが一番近いと思うよ >>144 その百人一首の上の句と下の句をつなげるように日本語と英語の一対一対応を増やしていくスタイルは、カルタが少ないうちはいいけれども腐るほど多くなったときに困りませんか? でも、最終的には慣れればなれるほど自動的に丸暗記になるのだろうから(私も「you shall die =死ね」状態なのは事実)、語学に理屈付けは不要なのかもしれませんね… C95って何? ああAMD1のことか、一瞬ぎくっとした しかしあの文脈では、それを言うならC99だろ C言語で、配列を渡すときは&付けなくていいとありましたが scanf("%c", &array[i][j]); このときに&つけなならんのはなんでですか cだとつけるのか二次元配列だとつけなきゃならないのか(根本的にわかってないかも) そこら変詳しくおしえてもらえませんか >>149 配列は、条件を満たしたとき (というより条件を満たす場合の方が多いのだが……) にその先頭要素を指すポインタに型変換されるという特殊ルールがあるから。 配列 array を単に array と書いた場合には、 &array[0] に読み替えられると考えてもいい。 配列 array に & を付けて &array と書いた場合は「配列を指すポインタ」であって、「配列の先頭要素を指すポインタ」ではないことにも注意が要る。 (型が違う) そのあたりのルールは歴史的経緯があってややこしいんだけど、この規則がないとそれはそれで記述がぐちゃぐちゃになるんでな……。 >>149 int array[2][2]と仮定すると、array[0][0]の型はint scanf()は渡されたアドレスを書き換える関数なので必要なのはint * >>149 []は、配列を、配列でなくす(要素にする)演算子だからだ 文字列(Cでは'\0'終端のchar配列)を格納できる変数 char s[SIZE]; に対して、 文字列を格納したい場合は scanf("%s", s); // 連続したメモリ領域 s[0], s[1], s[2] ... に格納 配列名 s は &s[0](配列の先頭要素へのポインタ)と、値と型が等しい 1文字だけ格納したい場合は scanf("%c%c", &[0], &s[1]); // s[0] と s[1] に1字ずつ格納 &s[0] は s と同じだが、 &s[1] との対応から &s[0] と書く方が分かりやすい 「配列名が暗黙に先頭要素へのポインタに変換される」話と、 「何を操作しているかをソースの書き方で明瞭に表現しようぜ」って話と、 整頓されずに混乱してるんじゃないかな。 「Cでは“文字列”とは何か」も絡んでるかも。 それに加えて、2次元配列という、これまたCではやや微妙な問題が噛んでるし。 char array[ROW][COLUMN]; // charの2次元配列 char *array[LINE]; // charへのポインタの1次元配列 >>149 の質問では二次元配列と明記されてるから本質じゃないけど、 説明を厳密にしようとすると、触れないのは片手落ちになっちゃうよね。 & 演算子でアドレスを得るときの内部的な処理の周辺。 &[0]なんて構文ねえよ よりにもよって、そんなとこtypoしちまったら致命傷だろうが ありゃ本当だ。&[0] は誤りだね。ご指摘ありがとう。 誤: scanf("%c%c", &[0], &s[1]); // s[0] と s[1] に1字ずつ格納 正: scanf("%c%c", &s[0], &s[1]); // s[0] と s[1] に1字ずつ格納 C言語ってarray[3]だけじゃなくて3[array]もできるんだね []が演算子って今更知った >>157 array[3] は *(array+3) と等しい、構文糖であるということになっているので結果的にそうなった。 かといってそんな書き方してるプログラムはサンプルプログラム以外では見たことがない。 >>157 コレ好き。たまーに混ぜ込んでおいてレビュー担当迷わせるの楽しい。 スキルの使い途を間違えているな 弱い者いじめではなく生産に使え チーム得点につながらない無駄なことをするやつを 上司は冷ややかに見ているぞ 初めて5[a]がOKなんだと知ったときの感動を思い出せ。そんな感動と興奮を仕事に散りばめてくれるエンターテイナーだよ。 Cに配列なんて概念なくて、 配列宣言っぽく見えるのはポインタ宣言とallocaの構文糖だという 言語だったらよかったのに。 いや、それは困る ポインタが指す先の実体は いつかどこかで配列になれなきゃ話が発散してしまう "0123456789abcdef"[n % 10] 忙しかったものですから、ウルトラ亀レスで申し訳ありません。 もちろんK&Rは良い本だとは思いますが、 よくないところがあると書きましたら、「それどこですか?」 のような質問がきていたのですが、仕事に忙殺されてレスが遅くなりました。 例えば、K&Rのハッシュ探索のプログラム。 ソースを見ればバグがあるとすぐわかるはずです。 K&Rのソースは単なるサンプルです。 仕事で実際に使えるわけではありませんし、 吐き出すハッシュ値をチェックしてみてください。 そのソースをF社の東大卒のプログラマがパッケージに組み込んでしまい、 大きなバグを引き起こしました。 で、俺が呼ばれてソースを見た瞬間に原因がわかって直しました。 K&Rを読んだときに気が付いていたからです。 K&Rを読んだときに、気が付く人はすぐ気が付いていると思います。 自分で考える人です。 本当のプログラマです。 >>173 自分で考えるのが良いってのは、プログラマに限らずなんでもそうだよね。 その上で本当のプログラマとやらにもとめられるのは、考えて理解することよりバグを出さないテストを行う能力だと思うね。 考えてもミスる時はミスるし。 場数を踏んだプログラマは、もちろんちゃんと考えるけど、その上で自分の理解やコードを信じない。 ちょっと話が違うかな。 >>173 それはK&Rのよくないところか? K&RはCとはどんな趣旨のものかを紹介する本で アルゴリズムを正確に教える本ではない 単にCの機能を説明するために例を挙げただけのナンチャッテコードを いきなり本番環境に持っていった東大卒とかぬかすやる気のねえクズと 大きな事故に至るまで欠陥を検出できない会社の検証ルールの問題だろうが 買ったもの、存在するものが四角い車輪だけだったとしてもか? 買ったもの、つまり売っているものは、自作したものよりも性能がいい Cできる人は(ここの住人のような)C++も当たり前にできるん? >>179 会社に今までC一筋20年くらいの人がC ++のプロジェクトに来たんだが使えなさすぎてクソワロタ もしかしてCのライブラリのソースコード全部読んでんの アホじゃね >>175 173です。 おっしゃるとおりです。 俺の言いたかったのは、まあそういう感じです。 K&Rの信奉者があまりに多いので どゆふうに指摘していいのか困惑している次第です。 つまり、言語の紹介本としては良い本だと思いますけど、 それ以上ではない。 現在、英語版のK&Rしか私の本棚に見つからないけど、 PREFACEの15行目からは、 This book is meant to help the reader learn how to program in C. と始まっています。 この部分、日本語版にはどのように翻訳されていたか失念しましたが、 まさに、そのとおりなのです。 しかし、ハッシュ値のところですけど、 あと数文字をコーディングするだけでまともなコードになるのに、 なぜしなかったのか?という疑問はあります。 プログラマなんて正常な判断ができないような過酷な状況に追いやられることなんてよくあるし、想像の余地はいろいろあるな。 >>179 Cを数年やってからC++を やりましたけど 最初は全くわかりませんでしたよ。 C++に慣れるまで1年ぐらいかかったかな? 全く別の言語と思ったほうが よろしいかと思います。 Cでインターフェース・抽象性を意識したプログラムを書いてたらそんなに変わらんと思う。 ただ現実としては委譲を使ってたところから無理して継承に適応するために混乱することはある。現場で待っているのは神クラス。 まるで別物と思うわ。 ただ仕事で使う分にはみなjavaと同程度の構文しか使ってないから、違いはさほどないと感じるかも 仕事以外でプログラミングすること自体がドMの極みw 34年間、ほぼ毎日プログラミングしてますよ! 定年になってもずっとやってると思います。 作りたいものが一杯有りすぎて体が2つ3つ欲しいです。 今、最も力を入れているのが人工知能です。 人類を滅ぼす悪魔のソフトを造るのが人生最大の目標です! >>191 >人類を滅ぼす悪魔のソフト これにはとても興味がありますね 「人類を滅ぼす悪のソフトウェア」 うーん、ぱっと思いつくところではテトリスとか… >>183 全然わかってねえじゃん あと数文字をコーディングすることが Cの機能を説明するサンプルとしては邪魔だったら その数文字をコーディングしねえのは当たり前だ サンプルってのはS/N比が大事なんだよ そこで伝えようとしていること以外のノイズは 徹底排除する必要があるんだ >>191 おまえ自分が作ったプログラムの敵が未来からタイムマシンで暗殺に来るぞ 脳波を検出して見たいVRを出してやるわ ==> 人類滅亡 >>193 初心者向きの本ですから真似する馬鹿もいるということを 想像すべきでしょうね。 おまえこそ馬鹿だな 想像力がゼロだ 笑えるぞ? 知ったかのクズだ 今どきCとか K&Rとかで 能書きこいて 馬鹿ジジイにも ほどがあるwww >>196 「初心者」という隠れ蓑に逃げる馬鹿って、自己紹介か? >>197 イラッとするのはわからんでもないが、ここはC言語スレだからそんなこというのは荒らしだぞ >>196 あの時代の初心者は今時の初心者と違って、大半はちゃんと自分で考えて自力で技術を習得していく姿勢があり、ただ教えてもらった通りにするだけのようなのは自然と落伍していったと思うよ。当時の想定する読者層にあった適切な内容だったろうと思う。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる