C言語なら俺に聞け 151
■ このスレッドは過去ログ倉庫に格納されています
そして「C言語はおかしい」と満場一致で結論が出て、また新たな言語が作られるのであった。
完 >>73
たまから、構造体はint, doubleとかの変数と同じく値渡しで一貫してる
配列がおかしいだけ 不定と未定義がある限り、C言語はおかしくあり続けるのだ。 >>77
const使わんの? ・・・て、先に誰か言ってるな >>78
intが値渡しと決められた理由は理解してるか?
配列みたいに暗黙のアドレス演算子にもやればできた話で
そのほうがおまえさんの主張する一貫性にも叶うわけだが >>80
そりゃ、付けられるときは基本いつでもconstですよ
だからなに >>84
77で「安全のために」って言っているのを
誤って変更してしまうのを防ぐためと読んでいたが
これがそもそも違うのか? >>86
変更しようがしまいが、意図があろうがなかろうが、コンテクストを分けるためですよ。 >>87
へー、じゃあ関数を呼び出すたびごとにプロセス生成とかすんの? >>88
なんで?
チミは頻繁にグローバル変数を使うってこと?やめたほうがええよ >>89
なんでグローバル変数を使っちゃいかんのだ?
スタックにしまえば安全だと思っているならおめでたいやつよ >>90
グローバル変数だめでしょ。
スタックってなんのこと?まさか関数呼び出しとスタックがセットだと思ってる? >>92
そんなもん、密結合・低凝集を実現する目的でしか役に立たんからですよ。 >>93
仮引数と自動変数が置かれるスタックもグローバルなんだが
そのせいで密結合・低凝集になったりしているか? 記憶領域確保に失敗したとき
落ちないように頑張ってくれるのと
即落ちるのと
どっちがどうだったか忘れた
最近読んだどっかに書いてあった筈だけど思い出せん…
x86 限定で良いので挙動とコーディングの関係に心当たりのある方御教示ねがいます。。。 >>94
そうそう、だからポインタを使わないのがいいね 構造体に限った話でもないが、グローバル変数のポインタが引数として渡され、更にそういう関数が多段に続いたコードとか地獄だよ。
誰かが止めねばならんよ。 >>97
あ、おまえさんそっち系か
・・・なんでCなんか使うの? >>98
グローバル変数をポインタ渡しは意味あるでしょ
スコープを指定する、的なやつ >>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
自分で考えるのが良いってのは、プログラマに限らずなんでもそうだよね。
その上で本当のプログラマとやらにもとめられるのは、考えて理解することよりバグを出さないテストを行う能力だと思うね。
考えてもミスる時はミスるし。
場数を踏んだプログラマは、もちろんちゃんと考えるけど、その上で自分の理解やコードを信じない。
ちょっと話が違うかな。 ■ このスレッドは過去ログ倉庫に格納されています