[過去ﾛｸﾞ] C言語なら俺に聞け 151 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
46: (ﾜｯﾁｮｲ 6969-p3R9) 2019/04/09(火)16:29 ID:obpichI70(1)調 AAS
C11 以降か…
47(1): (ｽｯｯﾌﾟ Sda2-JThg) 2019/04/09(火)18:39 ID:AXiDgdzZd(4/6)調 AAS
>>43
ググってヒットした件数的にこんなん使えませんわ。
48: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ c63e-k8NZ) 2019/04/09(火)19:07 ID:jYkGM3GN0(4/5)調 AAS
>>47
件数じゃなくて、用途に対する妥当性で考えてよ
49: (ｽｯｯﾌﾟ Sda2-JThg) 2019/04/09(火)21:04 ID:AXiDgdzZd(5/6)調 AAS
質問スレっぽいスレタイなのにそこまで考えさせられるのかよw
あんまり使われてないっぽいものは使わないってスタンスは崩さないよ、俺は。
50: (ﾜｯﾁｮｲ 5152-iMOx) 2019/04/09(火)21:11 ID:e3amBytd0(1)調 AAS
使われてないものは使わない
つまりC言語自体・・・(ﾎﾞｿｯ
51: (ｽｯｯﾌﾟ Sda2-JThg) 2019/04/09(火)21:27 ID:AXiDgdzZd(6/6)調 AAS
言語を自分で選べるほど偉くないんですよ
52: ◆QZaw55cn4c (ﾜｯﾁｮｲ 6247-BZhk) 2019/04/09(火)21:47 ID:ssMdw0XF0(1/3)調 AAS
>>35
ほえ〜
Annex K は確かにみじんも記憶に残っていません…でした
ご教示いただき感謝いたします
53: ◆QZaw55cn4c (ﾜｯﾁｮｲ 6247-BZhk) 2019/04/09(火)21:52 ID:ssMdw0XF0(2/3)調 AAS
>>33
実は K&R2 のみが正義、K&R2 こそ必要にしてかつ十分、という立場なので、そんな私が C99 を推挙した時点で、すでにして大幅に compromise しているつもりなのでした…
54(2): (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/09(火)21:55 ID:EB2iO7oh0(2/2)調 AAS
K&R2って妥協の産物だろ
K&R1こそ原理主義者の拠り所だ
55: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ c63e-k8NZ) 2019/04/09(火)22:05 ID:jYkGM3GN0(5/5)調 AAS
でもまあ JIS の最新は C99 相当だしな。
英語を読むのはしんどいし、
日本語の資料があるなら日本語の方がいいわ。
56(4): ◆QZaw55cn4c (ﾜｯﾁｮｲ 6247-BZhk) 2019/04/09(火)22:25 ID:ssMdw0XF0(3/3)調 AAS
>>54
＞K&R2って妥協の産物
それも理解できます
K&R2 の最大の改悪部分は「構造体の実体渡しができること」
配列の実体を丸まま関数に渡せないくせに、構造体では出来るって意味わかんない
もしかして
struct S {
int a[65536];
｝;
とかいう構造体があったら、それを全部スタックに載せるつもりなのか？そういうことをする奴が現れる可能性を考えたのか？と小一時間問い詰めたい気分になりました…
57: (ﾜｯﾁｮｲ ee8f-hWz0) 2019/04/09(火)22:31 ID:lax+sHP30(2/2)調 AAS
struct S {
long long ago0[1048576*1048576];
long long ago1[1048576*1048576];
long long ago2[1048576*1048576];
long long ago3[1048576*1048576];
};
58(2): (ｱｳｱｳｴｰ Sa8a-f9KT) 2019/04/09(火)22:32 ID:KCu43/3wa(1)調 AAS
>>56
それは、配列の方が悪いんでしょうに
構造体はコピーを渡すのが全然正しいじゃないの
59: (ﾜｯﾁｮｲ ee63-k8NZ) 2019/04/09(火)22:45 ID:A5vZx8Gh0(2/3)調 AAS
>>54
K&R1原理主義って、素敵?
60: (ﾜｯﾁｮｲ 2e12-bgjH) 2019/04/09(火)22:48 ID:PvJWb3nJ0(1)調 AAS
in a galaxy far,
far away...
61: (ﾜｯﾁｮｲ ee63-k8NZ) 2019/04/09(火)23:05 ID:A5vZx8Gh0(3/3)調 AAS
/* not reach here outside the universe */
62: (ﾜｯﾁｮｲ 5152-iMOx) 2019/04/10(水)01:12 ID:sw3hAH5+0(1)調 AAS
jedi = get_force();
63(1): ◆QZaw55cn4c (ﾜｯﾁｮｲ 6247-BZhk) 2019/04/10(水)01:49 ID:57hoitEO0(1/3)調 AAS
>>58
構造体といえどもアドレスを渡すのが真に正しく、配列なら言語仕様でそれを強要される、なぜ構造体には甘い顔を見せる必要があるのか？
64: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ c63e-k8NZ) 2019/04/10(水)04:59 ID:mOo8C1VR0(1)調 AAS
>>56
極端なことが「できてしまう」のが問題ということですか？ そもそも C なんてそんなものでしょう。
状況を見て適当に使い分けるべきで、駄目な使い方をしたら何だって駄目ですよ。
65(1): (ﾜｯﾁｮｲ ee8f-hWz0) 2019/04/10(水)06:18 ID:qyNiIlQC0(1/9)調 AAS
>>63
ド素人の勝手な推測だけれども
「配列だとマジでサイズどんだけか分かったもんじゃないじゃん」
「構造体のメンバ」に配列が来る場合はあるけど、そのサイズは多寡が知れてるじゃん」
という考えかもアリかもしんない
66: (ﾄﾞｺｸﾞﾛ MM4a-xk87) 2019/04/10(水)06:47 ID:bjp/36w+M(1/2)調 AAS
むしろ勝手にアドレス渡しになる配列が甘やかされすぎ
文字列がcharの配列だからしょうがないけど
67: (ｱｰｸｾｰ Sx91-L3CR) 2019/04/10(水)07:49 ID:PtgOSD4Jx(1)調 AAS
配列の実引数をポインタ仮引数で受けれるという仕様上、配列のサイズ情報が失われコンパイラは何バイトコピーすれば良いか分からないから致し方ない。
68: (ｱｳｱｳｳｰ Sac5-T5wd) 2019/04/10(水)09:42 ID:G/tPYfHxa(1/2)調 AAS
>>56
昔々初心者の頃にやっちゃって物凄く遅くなって気づいた事があったw
69: (ｱｳｱｳｳｰ Sac5-T5wd) 2019/04/10(水)09:49 ID:G/tPYfHxa(2/2)調 AAS
構造体も const で渡されたらこっそりポインタ使って読むだけのアクセスするコード作っちゃっても良いのにな。
マルチスレッドで動くプログラムの時に死ぬかも知れんが。
70(1): (ｱｳｱｳｶｰ Sa09-f9KT) 2019/04/10(水)10:06 ID:QqefTxrga(1)調 AAS
そもそも[]が無ければ誤解も減ったと思うよ
いい年した大人が、引数で渡ってきた配列の sizeof 取ろうとするの良く見るぜ
71: (ﾜｯﾁｮｲ 02a5-lO4n) 2019/04/10(水)10:42 ID:ryP68qDF0(1)調 AAS
現代教えられてる言語で60年代中期の古さを引きずってる言語だからだ
配列に対してsize適用すれば長さを取れるのは現代じゃあ普通で、
取れないC言語のほうがおかしい、
これ、誤解でも何でもないからな
72: (ﾜｯﾁｮｲ a278-l+U4) 2019/04/10(水)10:46 ID:Y6MOlOQR0(1)調 AAS
sizeofで取れるのは要素数じゃないけどな
73(2): (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)11:14 ID:9YALwuYf0(1/17)調 AAS
>>58
事実上、構造体はほとんどの場合ポインタで渡すよな
実体で渡すという特殊なケースがデフォになってて
ポインタで渡すという主要な使い方でアドレス演算子が必須って
おかしくね？
74: (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)11:16 ID:9YALwuYf0(2/17)調 AAS
>>70
だよな
[]こそ諸悪の根元
自動変数と仮引数と外部宣言でみんな意味違うとか
気が狂ってるとしか思えない
75: (ｱｳｱｳｳｰ Sac5-T5wd) 2019/04/10(水)11:23 ID:7gi5m8N9a(1)調 AAS
そして「C言語はおかしい」と満場一致で結論が出て、また新たな言語が作られるのであった。
完
76: (ﾜｯﾁｮｲ 7d02-w1lf) 2019/04/10(水)11:25 ID:lv7m7vwC0(1)調 AAS
ここが変だよC言語って本が昔売られてたな。。。
77(2): (ｱｳｱｳｴｰ Sa8a-f9KT) 2019/04/10(水)12:05 ID:JKE/90g3a(1)調 AAS
>>73
俺は安全のために実体渡すし返すよ、割と
78(1): (ﾄﾞｺｸﾞﾛ MM4a-xk87) 2019/04/10(水)12:29 ID:bjp/36w+M(2/2)調 AAS
>>73
たまから、構造体はint, doubleとかの変数と同じく値渡しで一貫してる
配列がおかしいだけ
79: (ﾜｯﾁｮｲ 7e7c-k8NZ) 2019/04/10(水)14:02 ID:pgm3XBSH0(1)調 AAS
不定と未定義がある限り、C言語はおかしくあり続けるのだ。
80(1): (ﾜｯﾁｮｲ ee8f-hWz0) 2019/04/10(水)14:28 ID:qyNiIlQC0(2/9)調 AAS
>>77
仮引数にconstはダメ？
81: (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)14:46 ID:9YALwuYf0(3/17)調 AAS
>>77
const使わんの？ ・・・て、先に誰か言ってるな
82(1): (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)14:49 ID:9YALwuYf0(4/17)調 AAS
>>78
intが値渡しと決められた理由は理解してるか？
配列みたいに暗黙のアドレス演算子にもやればできた話で
そのほうがおまえさんの主張する一貫性にも叶うわけだが
83: (ﾜｯﾁｮｲ 6969-p3R9) 2019/04/10(水)14:51 ID:hStfijf/0(1)調 AAS
by val と by ref でうあぁぁぁ
84(2): (ｱｳｱｳｴｰ Sa8a-f9KT) 2019/04/10(水)15:21 ID:Y9aQW1ZLa(1/10)調 AAS
>>80
そりゃ、付けられるときは基本いつでもconstですよ
だからなに
85: (ﾜｯﾁｮｲ ee8f-hWz0) 2019/04/10(水)15:49 ID:qyNiIlQC0(3/9)調 AAS
>>84
付けられないときってどんなときでしょう
86(1): (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)15:56 ID:9YALwuYf0(5/17)調 AAS
>>84
77で「安全のために」って言っているのを
誤って変更してしまうのを防ぐためと読んでいたが
これがそもそも違うのか？
87(1): (ｱｳｱｳｴｰ Sa8a-f9KT) 2019/04/10(水)16:15 ID:Y9aQW1ZLa(2/10)調 AAS
>>86
変更しようがしまいが、意図があろうがなかろうが、コンテクストを分けるためですよ。
88(1): (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)16:36 ID:9YALwuYf0(6/17)調 AAS
>>87
へー、じゃあ関数を呼び出すたびごとにプロセス生成とかすんの？
89(1): (ｱｳｱｳｴｰ Sa8a-f9KT) 2019/04/10(水)16:51 ID:Y9aQW1ZLa(3/10)調 AAS
>>88
なんで？
チミは頻繁にグローバル変数を使うってこと？やめたほうがええよ
90(1): (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)16:58 ID:9YALwuYf0(7/17)調 AAS
>>89
なんでグローバル変数を使っちゃいかんのだ？
スタックにしまえば安全だと思っているならおめでたいやつよ
91(1): (ｱｳｱｳｴｰ Sa8a-f9KT) 2019/04/10(水)17:08 ID:Y9aQW1ZLa(4/10)調 AAS
>>90
グローバル変数だめでしょ。
スタックってなんのこと？まさか関数呼び出しとスタックがセットだと思ってる？
92(1): (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)17:12 ID:9YALwuYf0(8/17)調 AAS
>>91
なんでと聞いている
答えてくれ
93(1): (ｱｳｱｳｴｰ Sa8a-f9KT) 2019/04/10(水)17:16 ID:Y9aQW1ZLa(5/10)調 AAS
>>92
そんなもん、密結合・低凝集を実現する目的でしか役に立たんからですよ。
94(1): (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)17:18 ID:9YALwuYf0(9/17)調 AAS
>>93
仮引数と自動変数が置かれるスタックもグローバルなんだが
そのせいで密結合・低凝集になったりしているか？
95: (ﾜｯﾁｮｲ ee8f-hWz0) 2019/04/10(水)17:20 ID:qyNiIlQC0(4/9)調 AAS
記憶領域確保に失敗したとき
落ちないように頑張ってくれるのと
即落ちるのと
どっちがどうだったか忘れた
最近読んだどっかに書いてあった筈だけど思い出せん…
x86 限定で良いので挙動とコーディングの関係に心当たりのある方御教示ねがいます。。。
96: (ﾜｯﾁｮｲ 9dca-iMOx) 2019/04/10(水)17:34 ID:VhJLBw5p0(1)調 AAS
こんな便所みたいなところでばっちばちでワロタ
97(1): (ｱｳｱｳｴｰ Sa8a-f9KT) 2019/04/10(水)17:36 ID:Y9aQW1ZLa(6/10)調 AAS
>>94
そうそう、だからポインタを使わないのがいいね
98(1): (ｱｳｱｳｴｰ Sa8a-f9KT) 2019/04/10(水)17:39 ID:Y9aQW1ZLa(7/10)調 AAS
構造体に限った話でもないが、グローバル変数のポインタが引数として渡され、更にそういう関数が多段に続いたコードとか地獄だよ。
誰かが止めねばならんよ。
99: (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)17:44 ID:9YALwuYf0(10/17)調 AAS
>>97
あ、おまえさんそっち系か
・・・なんでCなんか使うの？
100(1): (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)17:46 ID:9YALwuYf0(11/17)調 AAS
>>98
グローバル変数をポインタ渡しは意味あるでしょ
スコープを指定する、的なやつ
101(1): (ｱｳｱｳｴｰ Sa8a-f9KT) 2019/04/10(水)17:48 ID:Y9aQW1ZLa(8/10)調 AAS
>>100
マジ意味わからん
102(1): (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)17:52 ID:9YALwuYf0(12/17)調 AAS
>>101=97
二度も言わなくていいよ
103(1): (ｱｳｱｳｶｰ Sa09-f9KT) 2019/04/10(水)18:00 ID:9QKNNv28a(1)調 AAS
>>102
いや、100の解説してくれや
104(2): (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)18:05 ID:9YALwuYf0(13/17)調 AAS
>>103
#include <stdio.h>
int x, y;
int main(void)
{
scanf("%d", &x);
scanf("%d", &y);
return 0;
}
暗黙にxに書き込む関数とscanfは
どっちが汎用性が高いか
どっちが見通しがいいか
考えてみな
105(1): (ｱｳｱｳｴｰ Sa8a-f9KT) 2019/04/10(水)18:07 ID:Y9aQW1ZLa(9/10)調 AAS
>>104
xとyを比較したらええんか？
106: (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)18:09 ID:9YALwuYf0(14/17)調 AAS
>>105
おまえさんに解らせることはもう諦めた
放っといてくれ
107: (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)18:17 ID:9YALwuYf0(15/17)調 AAS
俺はいま103に説明しているんだ
108: (ｱｳｱｳｶｰ Sa09-f9KT) 2019/04/10(水)18:41 ID:BTPtEuL0a(1)調 AAS
いや、同一人物だぞ
109(1): (ﾜｯﾁｮｲ 8201-xk87) 2019/04/10(水)19:37 ID:WZ2DAnxG0(1)調 AAS
>>82でイミフなこと言ってるなって思ったら単なる基地外やんw
110(1): (ﾜｯﾁｮｲ ee8f-hWz0) 2019/04/10(水)20:25 ID:qyNiIlQC0(5/9)調 AAS
結局「constを仮引数に使えないとき」というのがどんなときなのが全く分からず
「規格通りに書いてはならない」ケースが実在したのかしら
111: (ｱｳｱｳｴｰ Sa8a-f9KT) 2019/04/10(水)20:33 ID:Y9aQW1ZLa(10/10)調 AAS
>>110
え、毎回書いてるの？
112: (ﾜｯﾁｮｲ ee8f-hWz0) 2019/04/10(水)21:26 ID:qyNiIlQC0(6/9)調 AAS
いや
仕事で使ってませんから
そもそも「毎回」っていうほど書いてませんし
何らかのツールで勝手に入るので「敢えて書く必要性がない」ということなのでしょうか
それとも一律に「書くな」というルールが定着している組織が実在しているのでしょうか
113: (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)21:33 ID:9YALwuYf0(16/17)調 AAS
>>109
そうか、82がおまえさんはイミフなのか
悪いけど匙を投げるね
114(1): (ﾜｯﾁｮｲ ee8f-hWz0) 2019/04/10(水)21:37 ID:qyNiIlQC0(7/9)調 AAS
>>104 にて
scanf("%d", &x);
と書かれているのですが、ターミナルから9を80字入力されたらどうなさるおつもりなのでしょうか
また、signedともunsignedとも指定されておりませんが、その点はどのように汎用性を確保なさるのでしょうか
115(1): (ﾜｯﾁｮｲ 912d-iMOx) 2019/04/10(水)21:55 ID:9YALwuYf0(17/17)調 AAS
>>114
俺に聞くな、規格票を嫁
http://kikakurui.com/x3/X3010-2003-01.html
104のコードが規格厳密合致プログラム（strictly conforming program）であることのみここに宣言する
この命題を反証されたら、潔く敗北を認める
では貴殿の返答を待つ
116: さまよえる蟻人間◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ b901-6gO7) 2019/04/10(水)21:59 ID:QzOhMry80(1/2)調 AAS
intだけだったらsigned intになるっしょ。
近代的な環境なら、正しく書式を設定すればscanfはオーバーフローしない。
117: さまよえる蟻人間◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ b901-6gO7) 2019/04/10(水)22:19 ID:QzOhMry80(2/2)調 AAS
shortはsigned short、
longはsigned longだが、
charはコンパイラの設定によりsignedにもunsignedにもなる。普通はsignedだがな。
118(1): (ﾜｯﾁｮｲ ee8f-hWz0) 2019/04/10(水)23:14 ID:qyNiIlQC0(8/9)調 AAS
>>115
> 規格厳密合致プログラム
残念ながら、リンク先の日本語文章に定義が無く意味不明だったため
これから英文を読むことにします
型の件含め、皆様の御教示に感謝します
119(1): (ﾜｯﾁｮｲ ee8f-hWz0) 2019/04/10(水)23:41 ID:qyNiIlQC0(9/9)調 AAS
"shall" の訳文に、筆者の苦悩のようなものが見受けられました
その点ふくめ、私は知らないことが非常に多いようで、ご迷惑をおかけしました
120: ◆QZaw55cn4c (ﾜｯﾁｮｲ 6247-BZhk) 2019/04/10(水)23:46 ID:57hoitEO0(2/3)調 AAS
>>65
>>56
struct S {
int a[65536];
｝;
121(3): ◆QZaw55cn4c (ﾜｯﾁｮｲ 6247-BZhk) 2019/04/10(水)23:49 ID:57hoitEO0(3/3)調 AAS
>>119
規格の中に現れる shall は十中八九「話者の意思」を示す
例文：You shall die.
超訳：「死ね！」
122(1): (ﾜｯﾁｮｲ 8b8f-ofH2) 2019/04/11(木)00:04 ID:SPJO7XdY0(1/2)調 AAS
>>121
> 例文：You shall die.
> 超訳：「死ね！」
さすがにそれは…
日本語の文章の方に "shall" は書かれてなかったもんで把握、と
示唆したつもりだったのですが、通じなかったようで、表現力につき反省する所しきりであります
123: (ﾜｯﾁｮｲ d901-LJPv) 2019/04/11(木)00:44 ID:Nah1Abkj0(1)調 AAS
I shall return 0.
124: (ﾜｯﾁｮｲ fb02-XGqV) 2019/04/11(木)01:53 ID:5ienNbe20(1)調 AAS
*'``・* 。
| `*。
,｡∩彡⌒ミ * みんなハゲにな〜れ
+ (´･ω･`) *｡+ﾟ
`*｡ ヽ、 つ *ﾟ*
`・+｡*・' ﾟ⊃ +ﾟ
☆ ∪~ ｡*ﾟ
`・+｡*・ ﾟ
125: (ﾜｯﾁｮｲ 392d-XGqV) 2019/04/11(木)07:54 ID:YCq7KtVA0(1)調 AAS
>>118
4. 規格合致性
規格厳密合致プログラム（strictly conforming program）は，この規格で規定する言語機能及びライブラリ
だけを使用しなければならない(2)。さらに，いかなる未規定の動作，未定義の動作又は処理系定義の動作に依存する出力も生成してはならず，しかもどのような最低限の処理系限界も超えてはならない。
(2)規格厳密合致プログラムは，どの処理系でもサポートしているわけではない機能（附属書 F の中に例
がある。）を使うことができる。ただし，その機能を使うことができるのは，それが適切なマクロをもつ#ifdef 指令とそれに対応する#endif 指令とに囲まれている場合に限る。次に示すプログラム片がその例である。
#ifdef _ _STDC_IEC_559_ _ /* FE_UPWARD
が定義されている */
/* ... */
fesetround(FE_UPWARD);
/*
... */
#endif
126(1): (ﾜｯﾁｮｲ 2969-5LTE) 2019/04/11(木)09:09 ID:AbBe4c020(1)調 AAS
RFCなんかである要請の強度( MUST SHALL MAY ) みたいに使う用語の縛りはない？
127(2): ◆QZaw55cn4c (ﾜｯﾁｮｲ d347-yqpC) 2019/04/11(木)20:58 ID:mnND5pqz0(1)調 AAS
>>122
あくまで私見ですが、現代英語では will に単純に置き換えられるような shall の使い方はもうありえなく、
shall を使うのは shall を使う必然性があるから、だから、shall は辞書でいうところの「意志未来」であり、したがって shall を訳出しないのは不誠実な訳だとどうしても私は感じてしまいます…
128(1): (ﾜｯﾁｮｲ 8b8f-ofH2) 2019/04/11(木)21:23 ID:SPJO7XdY0(2/2)調 AAS
「英文読解」の場ではなかったので控えていたのですが
>>127
個人的には「こんなのを訳出させられた人は凄い」と思ってます
「原典は英語で日本語訳がある」もので「日本語訳が意味不明」の場合
原典で確認すると「訳出で明確ではない」部分が確認できるケースが多々あります
"shall" をどのように訳出するかは個人差ありますし
今回の箇所が「以前同じ文言があったので単純にコピペした」ものかどうかは確認していません
もちろん>>126さんが仰るように「強度の要請で助動詞を変える」ものもありえますが
C99の文書の場合は丁寧に "shall" の定義から書かれていますし、
何より "strictly conforming program" という表現は、明確に 4.5 での新情報です
129(1): (ﾄﾝﾓｰ MM4d-Ouf2) 2019/04/13(土)04:36 ID:/Uq84pFNM(1)調 AAS
昔の話。
若い頃K&Rの日本語版を買ってきて読み始めて、
間違いというか
サンプルとしてよろしくない
ところを見つけていた。
それが7年後に役立って
沢山仕事が入ってくるようになった。
本はキチンと読みましょう！
130: (ﾜｯﾁｮｲ 298f-Glgm) 2019/04/13(土)12:55 ID:hvrKDDfY0(1)調 AAS
>>129
面白そうな話の気もするが、抽象的すぎてよくさっぱりわからん。
せっかくだしもう少し詳しく教えて欲しい。
131(1): (ｻｻｸｯﾃﾛ Sp85-Sq8Y) 2019/04/14(日)04:54 ID:jIyXk5jhp(1)調 AAS
You shall die.
日本語の古語にすると分かりやすい
汝死すべし
shallはべしに近い
132: ◆QZaw55cn4c (ﾜｯﾁｮｲ d347-yqpC) 2019/04/14(日)05:55 ID:AVvjfIV70(1/4)調 AAS
>>131
「べし」が二人称主語のときは「当然〜するべき」「義務」をあらわすことが多いですね
ただしこの場合も、主観的な意見の場合・客観的な義務の場合の両方がありうるかもしれません
shall=べき、べし、というのはいい線いっていると思います
133: (ﾜｯﾁｮｲ 597b-/1Ht) 2019/04/14(日)06:22 ID:JgI3yl/w0(1)調 AAS
日常会話や文学なら "You shall die." を「汝死すべし」と訳して
原文のもつ「お前死んだ方がいいよ」と「お前はいつか死ぬであろう」の
両方のニュアンス(他の解釈もあるかも)を残すってのはアリだと思うけど、
技術的な文章では、複数の意味に取れる書き方はしないでしょ。
翻訳の読者が欲しい情報も、原文がどちらを意図してるのか、だろうし。
134: (ﾜｯﾁｮｲ 39ab-FipA) 2019/04/14(日)06:41 ID:Sc1FWDft0(1)調 AAS
shall
〜するものとする。
135(1): (ﾜｯﾁｮｲ 1301-EjgJ) 2019/04/14(日)08:56 ID:/sR0LrTu0(1/2)調 AAS
ISO9001の要求事項とか見たことないのか？
Shall： しなければいけない
Should： した方が良い
って訳すのは常識だぞ
136(1): ◆QZaw55cn4c (ﾜｯﾁｮｲ d347-yqpC) 2019/04/14(日)09:36 ID:AVvjfIV70(2/4)調 AAS
>>135
>>121 >>127 のとおり、shall は単純未来の可能性は捨て一律に意志未来に決め打ちしちゃっていいってことですね…
137: (ﾜｯﾁｮｲ b952-XGqV) 2019/04/14(日)09:43 ID:zcg/ytHt0(1/2)調 AAS
英会話スレ
138: (ﾜｯﾁｮｲ 298f-Glgm) 2019/04/14(日)09:54 ID:/V8zrPr00(1/2)調 AAS
一年程度だが海外で仕事した経験のある俺にコメントさせてくれ。
shallにとくに意味はない。日本語に訳すのは難しいが方向性でいえば
汝死ぬ(shallなし)
↓
汝はねぇ死ぬよ(shallあり)
かな。
つまり特に意味はない。特に強調してるわけでもないけど、つまり断定か。
139: (ﾜｯﾁｮｲ b952-XGqV) 2019/04/14(日)10:09 ID:zcg/ytHt0(2/2)調 AAS
余計分かりにくい
140(1): (ﾜｯﾁｮｲ 1301-EjgJ) 2019/04/14(日)10:38 ID:/sR0LrTu0(2/2)調 AAS
>>136
未来とか関係ない
そうしないと規格に合致しねーぞって言うある意味条件だよ
141(1): ◆QZaw55cn4c (ﾜｯﾁｮｲ d347-yqpC) 2019/04/14(日)10:50 ID:AVvjfIV70(3/4)調 AAS
>>140
「意志未来」という言葉は辞書の言葉ですが、私の本意は >>121
つまり「規格」または「規格の書き手」が "You will die" という感情の含まれない淡白な表現を、それが実現するように強要する、それが "You shall die."
142: (ﾜｯﾁｮｲ 298f-Glgm) 2019/04/14(日)11:15 ID:/V8zrPr00(2/2)調 AAS
いや、ほんとに意味はないんだよ。書き手がなんか気持ち悪いからshallつけてるだけでshall抜きでもかわらん。
willとかshouldに比べてshallどうとかじゃなくて、willとかshouldがなかったらどうかを考えるべき。
143: (ﾜｯﾁｮｲ 695f-26O/) 2019/04/14(日)11:36 ID:xBNIHV910(1/2)調 AAS
そもそも他言語を日本語で正確に訳せるってのは幻想でしかないから
規格でshallやshall notについて扱いが明記されてる（C11なら4.1〜4.2）以上それが全てでしょ
144(1): (ﾄﾞｺｸﾞﾛ MMbd-EjgJ) 2019/04/14(日)11:56 ID:CLAWTkIiM(1)調 AAS
>>141
だからお前さんの本意とかはどうでもいい
規格でのshall/shouldの解釈は
> Shall： しなければいけない
> Should： した方が良い
って訳すのは常識って話
145: (ﾜｯﾁｮｲ 818f-ofH2) 2019/04/14(日)12:01 ID:El+pt49w0(1)調 AAS
>>128
> 「英文読解」の場ではなかったので控えていたのですが
（中略）
> C99の文書の場合は丁寧に "shall" の定義から書かれています
これ以上、「C言語のスレ」として、どんな話題あるんですか
「ANSI C（なりC90なり）」「C95」「C11」を持ち出すなら意味があるかも知れませんが？
上下前次1-新書関写板覧索設栞歴
あと 857 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.022s