C言語なら俺に聞け 147

**デフォルトの名無しさん** · 2018/08/16(木) 23:36:02.22

C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

前
C言語なら俺に聞け 146
https://mevius.5ch.net/test/read.cgi/tech/1525031257/

**デフォルトの名無しさん** · 2018/08/17(金) 02:03:10.65

>>1
乙なんだな

**デフォルトの名無しさん** · 2018/08/17(金) 04:59:04.13

>>1
乙ってんね

**デフォルトの名無しさん** · 2018/08/17(金) 07:32:18.55

前スレ992
https://mevius.5ch.net/test/read.cgi/tech/1525031257/992

ちょっと何言ってるかわからん
983はナマポと何の関係があるのかと聞いているんだが？？

**デフォルトの名無しさん** · 2018/08/17(金) 09:26:07.17

>>1
おC

**デフォルトの名無しさん** · 2018/08/17(金) 10:07:35.20

>>1
乙curry

**デフォルトの名無しさん** · 2018/08/17(金) 20:50:45.41

>>4
ちょっとはググって言え。

使い道のないはずのイテレータをC++ではどう活用してるのか、
何故そんなことになるのか、考えてみろ。

**デフォルトの名無しさん** · 2018/08/17(金) 20:54:30.35

というかこのスレワッチョイ外されているんだな。
最近この手の荒らし多いな。

俺はワッチョイ無しのスレは気に入らないから、
>>4の疑問について、ワッチョイ無しのスレ（＝このスレ）では答えないことにする。
まあもうヒントは十分に与えたし、馬鹿でなければ辿り着けるはずだが。

**デフォルトの名無しさん** · 2018/08/17(金) 21:23:33.04

イテレータへのこだわりは確かに謎。結局ローレベルな話なんだよね。
foreachという切り口だとイキるのが難しいということか。

**デフォルトの名無しさん** · 2018/08/17(金) 21:26:26.11

ナマポとプログラム言語の関係性はさっぱりわからない

**デフォルトの名無しさん** · 2018/08/17(金) 21:41:35.78

アホ？　list<T>::iteratorがナマポ撲滅のためとか本気で言ってるのか？

**デフォルトの名無しさん** · 2018/08/18(土) 00:42:04.17

改めて明解C読んだけどどう考えても入門者向けじゃねえなこれ
これ最初に読んだせいで挫折した人多そう

**デフォルトの名無しさん** · 2018/08/18(土) 01:38:53.00

その教科書は教師を再生産するための商品
独学でどうにかするアイテムじゃあない

教科書の肝心のところに教師から教えてもらうフェイズがひっそりとしのばせてある
だから教師の関与が深い
補助の人間が必要な物品だよ
教科書を誰が買うかっていうと、先生がより先生っぽい演技・活躍を出来るアイテムを買うだろ
だから教師の再生産をするためのアイテムを教師が生徒に買わせるんだよ

教科書は生徒が買うんじゃなくて先生が買う、
そのフェイズでは教師の介在があってはじめて理解できるようなひっかけがなくちゃあならない、
だから「入門者向けじゃねえ」になる

**デフォルトの名無しさん** · 2018/08/19(日) 16:42:31.78

C言語の入門書を読み終えて文法をある程度理解したところなんですけどこの次はどうしたらいいんでしょうか・・・

**デフォルトの名無しさん** · 2018/08/19(日) 16:48:10.98

何かを作って見る
何を作るかは自分で決める
決められないときは、みんなに相談してみる

**デフォルトの名無しさん** · 2018/08/19(日) 16:58:14.33

>>14
アルゴリズムとデータ構造の本を一冊買って勉強しとけ
もちろんコードを書くんだ
コードを書かないならそんな本は買わなくてよろしい

**デフォルトの名無しさん** · 2018/08/19(日) 17:25:20.88

>>14
標準ライブラリの関数の仕様を調べつつ、自分で実装してみる

**デフォルトの名無しさん** · 2018/08/19(日) 18:06:47.62

printf と scanf のフォーマット処理は勘弁してください

**デフォルトの名無しさん** · 2018/08/19(日) 18:41:28.69

ありがとうございますとりあえずアルゴリズムとやらの本を買います

**デフォルトの名無しさん** · 2018/08/19(日) 21:04:33.17

これどう？初心者だとちょっと難しいかも知れないが。

［改訂新版］C言語による標準アルゴリズム事典 Software Technology https://www.amazon.co.jp/dp/B07CG4RMT5/ref=cm_sw_r_cp_taa_xEvEBbAEA1JNT

**デフォルトの名無しさん** · 2018/08/19(日) 21:44:56.14

だめでしょ。
アルゴリズムイントロダクションがいいよ

**デフォルトの名無しさん** · 2018/08/19(日) 22:58:10.05

事典は事典。最小限の解説読んであぁなるほどねって思える人用。

**デフォルトの名無しさん** · 2018/08/19(日) 23:13:09.55

詳説 Cポインタ、2013、オライリー・ジャパン

ポインターだけで1冊、本が書けるw

**デフォルトの名無しさん** · 2018/08/19(日) 23:22:19.21

引数に配列をとるとき
f(int* data)とf(int data[])の両方が有りだということは分かったのですが、基本的に後者の書き方をしてるコードはほとんど無くて大体前者な気がします。
これはなんででしょうか。後者の方がはっきり配列だとわかります。前者は配列を求められているのかただのint型のポインターを求められてるのか判断つかないと思うんです

**デフォルトの名無しさん** · 2018/08/19(日) 23:23:37.77

ポインターってそんなに難しかったっけ？

**デフォルトの名無しさん** · 2018/08/19(日) 23:26:29.60

ポインタ本ならこっちの方がいい

新・標準プログラマーズライブラリ
C言語ポインタ完全制覇大型本
前橋和弥 (著)　2017/12/7

**デフォルトの名無しさん** · 2018/08/19(日) 23:55:12.29

>>24
[ ] は、サイズが変わらない

* は、単なる先頭アドレスで、サイズが変わるかも知れない

**デフォルトの名無しさん** · 2018/08/20(月) 00:01:28.25

>>24
配列表記はアドレス表記のエイリアスだから区別するという発想がそもそもない
配列アクセスするコードならアドレスと配列のサイズを引数で渡す

**デフォルトの名無しさん** · 2018/08/20(月) 00:03:41.14

関数の引数としては配列であろうがポインタであろうが、ただのアドレスとしての意味しかない

**デフォルトの名無しさん** · 2018/08/20(月) 00:12:09.78

>>29
配列でもポインタでも同じってことは分かってるでしょ
それでも元が配列なら配列で受けたほうが分かりやすいのでは？
という疑問だと思う

>>24
ぶっちゃけ、Cに慣れてくるとどっちでもたいして変わらない
配列で受けたいのならそうすればいい。
実際のところ、両方それなりに使われてる。
例えば、main() は int *argv[] にすることが多いんじゃないかな
多分だけど

**デフォルトの名無しさん** · 2018/08/20(月) 00:19:11.88

>>24
配列っぽい表記に惑わされて、sizeofして長さを求めようとしたというバグを何度か見ました。

**デフォルトの名無しさん** · 2018/08/20(月) 00:26:25.44

　
f(int data[100]) なんて渡し方だと、どう？

**デフォルトの名無しさん** · 2018/08/20(月) 01:02:08.56

そんな文法はない。
宣言としては有効かな。でも意味はないだろうね。ただのポインタ。

**デフォルトの名無しさん** · 2018/08/20(月) 01:20:33.12

>>33
じゃあ、これをポインタ表記に置き換えて見てください、お願い

**デフォルトの名無しさん** · 2018/08/20(月) 03:08:45.92

>>24
なるほど、じゃあ君は
void swap_int(int lhs[], int rhs[]);
と書いてもらえれば判断つきやすいんだな

**デフォルトの名無しさん** · 2018/08/20(月) 04:14:23.20

なんというか、Cならではの問題かな。
Javaもちょっと似てるか。

**デフォルトの名無しさん** · 2018/08/20(月) 06:23:59.34

下のようなコードを書くとコンパイルエラーになるでしょ。
int ary[100];
int val;
val = ary++;
このaryは配列だから、ary自体の値を変化させる操作は出来ない。
それの類推で関数の仮引数はポインタで受けるんじゃないかな。
関数の中でポインタ風に使う変数はポインタの形で宣言。

関数内で値を変化させず [] によるインデクスだけでアクセスするなら
仮引数を配列の形で宣言するのも分かりやすい書き方かも。

後は歴史的な事情。
配列風に書くとインデクス計算に掛け算を使われて遅かった名残り。

>>30 俺はmainの引数は main(int argc, char *argv[]) だな。
保守的だけど、こんな場面で独自色出すことないしね。

**デフォルトの名無しさん** · 2018/08/20(月) 07:23:53.30

>>24
あんたの感覚は正しいと思う
同じだと言ってる奴もいるけど
foo(int a[]){
a = … /* エラー */
とか微妙に違う
ただそこまで気にする人があまりいないだけ

**デフォルトの名無しさん** · 2018/08/20(月) 07:29:22.22

関数の引数では配列の要素数は無視されるだけ
変数としての配列とポインタは別物だけど、関数の引数では全く同じもの

**デフォルトの名無しさん** · 2018/08/20(月) 08:10:21.73

理由は既出だけど、C言語では配列とポインタは明確に違うよ。
相互変換可能なだけ。

**デフォルトの名無しさん** · 2018/08/20(月) 09:01:16.78

ぶっちゃけ、相互変換可能ならその二つは同じじゃねえか？
数学的に

**デフォルトの名無しさん** · 2018/08/20(月) 09:09:43.44

同じ点もあるし違う点もある
同じ点を強調したいときに「同じ」
違う点を強調したいときに「違う」
と言うだけ

具体的に語らないと何の意味もない

**デフォルトの名無しさん** · 2018/08/20(月) 09:30:29.85

>>38
そのコード片、エラーになるかな?
仮引数のa(intへのポインタ)に
関数内で値を代入することは許されるはずだけど。

**デフォルトの名無しさん** · 2018/08/20(月) 10:24:22.53

代入ではエラーにならんと思うよ。
lvalueとして使えると思う。配列っぽく書けるがあくまでポインタ。

**デフォルトの名無しさん** · 2018/08/20(月) 10:37:33.39

>>43-44
すまん、お前らの言う通りだ
なんか勘違いしていたみたい

**デフォルトの名無しさん** · 2018/08/20(月) 11:31:29.94

>>20
パクリで儲かる成功例

**デフォルトの名無しさん** · 2018/08/20(月) 11:46:22.27

引数の配列がホンモノだとすると、非NULLが保証されてないとあかん。
というか構造体渡しと同様の配列渡しが必要だな。まあ使わんか。

**デフォルトの名無しさん** · 2018/08/20(月) 13:08:43.61

>>37
その例は
void func(int ary[100])
{
int val;
val = ary++;
}
との違いを示そうとしているのだとしたら
int *val; じゃないとおかしいだろ

>>37
[]で書くべきと主張するんなら
char argv[][]にしなきゃねえ
もちエラーだけどｗ

**デフォルトの名無しさん** · 2018/08/20(月) 13:28:58.98

>>47
ま、必要なら構造体の中に入れて渡すと。

**デフォルトの名無しさん** · 2018/08/20(月) 16:12:09.36

配列をパラメータにするのは
サイズが決まってる時にそれを明示したい場合くらいだな

ポインタの方が汎用性が高いから

**デフォルトの名無しさん** · 2018/08/20(月) 16:14:24.46

構造体みたいに
値渡しやコピーもあると(たまには)便利

**デフォルトの名無しさん** · 2018/08/21(火) 07:18:10.26

>>50
void func(int ary[100]); これと
void func(int *ary); これが
意味が違うと思っているのか？

**デフォルトの名無しさん** · 2018/08/21(火) 07:20:36.44

設計意図を示すコメント的な意味ならあると思う
中身は同じだけど

**デフォルトの名無しさん** · 2018/08/21(火) 07:38:47.67

初心者に対して誤解を与えるだけじゃね？
必ずそのサイズで呼ばれると保証されるわけでもないし。

**デフォルトの名無しさん** · 2018/08/21(火) 08:20:07.94

>>52
意味は違うね

要素が100個以外の時に前者を使ってるコードを見たら気持ち悪いだろ？
そういうこと

コンパイラによってはary[1000]にアクセスすれば警告が出る

**デフォルトの名無しさん** · 2018/08/21(火) 08:40:04.69

ほんとに警告出るのか？
サイズ指定に意味がないというのが規格だし、コメント程度の役割しか持たせたらあかんという気が

**デフォルトの名無しさん** · 2018/08/21(火) 08:48:21.68

gcc8でもclang6でも警告でなかったょ…

**デフォルトの名無しさん** · 2018/08/21(火) 09:13:57.61

お高い静的解析ツールだと警告出るかもね。
やってないから知らんけど。

そういう環境で開発できるならコメント以上の意味はあるかも。
仮定で申し訳ない。

**デフォルトの名無しさん** · 2018/08/21(火) 09:28:29.44

>>55
おまえの主観は聞いてない
プログラムの実行結果が違ってくる例を示せ

**デフォルトの名無しさん** · 2018/08/21(火) 09:30:24.31

>>59
屁理屈乙

**デフォルトの名無しさん** · 2018/08/21(火) 09:31:42.61

>>48
多次元配列なら
void func(int ary{}[100])
{
}
とか
void func(int (*ary){}[100])
{
}

**デフォルトの名無しさん** · 2018/08/21(火) 09:35:21.28

>>61
間違えた

void func(int ary[][100])
{
}
とか
void func(int (*ary)[100])
{
}

**デフォルトの名無しさん** · 2018/08/21(火) 10:40:22.58

>>60
もう一度言う、おまえの主観は聞いてない
正論か屁理屈かはおまえの主観だ
客観的事実を示せ、理屈はそれからだ

**デフォルトの名無しさん** · 2018/08/21(火) 10:57:00.63

>>63
だれも機械の解釈の違いには言及してない定期

**デフォルトの名無しさん** · 2018/08/21(火) 10:59:30.05

>>62
void func(int ary[][100]); これはできるのに
int func(void)[][100] これはできない
{
int ary[][100]; これもできない
ary = 0;
return ary;
}
extern int ary[][100]; と
extern int (*ary)[100]; は意味が違う
結局、[]で書くべきなんて主張は
通用しないところが多すぎる戯れ言だ

**デフォルトの名無しさん** · 2018/08/21(火) 11:01:09.20

>>64
プログラム言語は機械に解釈させるためのものだ
自明なことを誰も言ってないなんてことこそ屁理屈そのものだろうが

**デフォルトの名無しさん** · 2018/08/21(火) 11:01:29.60

>>66
糖衣構文

**デフォルトの名無しさん** · 2018/08/21(火) 11:02:23.89

>>67
全然関係ねえぜ
暑さで気が触れたか？

**デフォルトの名無しさん** · 2018/08/21(火) 11:05:05.84

>>68
機械の解釈が同じでも人間には違う意味に見えるのはあるよな？

**デフォルトの名無しさん** · 2018/08/21(火) 11:55:44.43

>>69
void func(int ary[100]); これのどこが
void func(int *ary); これの構文糖衣なんだ？
書いた奴の頭を疑わせる以外にどんな意味があるんだよ

**デフォルトの名無しさん** · 2018/08/21(火) 11:56:39.26

サイズが100でなければならない関数なら
void func(int (*ary)[100]); こう書いて
int ary[100];
func(&ary); こう渡せよボンクラ

**デフォルトの名無しさん** · 2018/08/21(火) 12:10:27.14

まあ多次元配列を引数にするのは良くないと思うわ

**デフォルトの名無しさん** · 2018/08/21(火) 12:28:57.33

>>71
どうした？
コードレビューで上司にボコボコにされた腹いせか？
こんなとこでイキっても虚しいだけやで。

**デフォルトの名無しさん** · 2018/08/21(火) 12:29:15.96

>>71
どうした？
コードレビューで上司にボコボコにされた腹いせか？
こんなとこでイキっても虚しいだけやで。

**デフォルトの名無しさん** · 2018/08/21(火) 12:47:09.71

>>72
なぜ？

**デフォルトの名無しさん** · 2018/08/21(火) 12:53:55.98

>>73
ここがム板ってことを忘れたか？
技術的な話で来い

**デフォルトの名無しさん** · 2018/08/21(火) 12:54:14.69

多次元配列の型は typedef で型名作っておけば楽なのでは？

**デフォルトの名無しさん** · 2018/08/21(火) 12:56:41.15

>>68
>>76
この書き込みのどこが技術的な話なんだw
単にイキってるだけじゃん。

**デフォルトの名無しさん** · 2018/08/21(火) 13:04:39.72

>>78
構文糖衣の話をしたんだが
構文糖衣と書いてないと読めないオツムなのか？
アホｗ　バカｗｗｗ

**デフォルトの名無しさん** · 2018/08/21(火) 13:05:57.10

さて、買い物に行くぜ
妻子の夕飯を作らにゃならん

**デフォルトの名無しさん** · 2018/08/21(火) 13:09:48.25

>>75
そりゃわかりにくいからだよ。
引数にするとCの多次元配列の嘘くささがよく表れるわ。
せめて構造体で包むとかして名前を付けた方がいいね。

**デフォルトの名無しさん** · 2018/08/21(火) 13:09:58.77

>>71
無駄なコスト

**デフォルトの名無しさん** · 2018/08/21(火) 13:10:23.54

>>70
それを糖衣構文というかどうかどうでもいいけど
だれも機械の解釈の違いには言及してない定期

>>50➡>>52
明示とは機械に対してではなく人間に対してのことを言ってるからこの返信は意味がずれてる

**デフォルトの名無しさん** · 2018/08/21(火) 14:09:26.92

超初心者です。
シミュレーターで動かしながら独学で学んでいるのですが、
scanfが動かない（スルーされる）ので困っています。scanfが動くシミュレーターってあります？

**デフォルトの名無しさん** · 2018/08/21(火) 14:13:40.03

今はpaiza.ioを使っています

**デフォルトの名無しさん** · 2018/08/21(火) 14:16:15.27

下の入力欄が空白じゃないの？

**デフォルトの名無しさん** · 2018/08/21(火) 14:27:50.04

解決しました。ありがとうございました。

**デフォルトの名無しさん** · 2018/08/21(火) 20:15:22.43

for文でこんなのを発見したのです。
for(;;)
ご覧のとおりセミコロンがカッコ内に2つあるだけ。
これはどういうfor文でしょうか。
ググり方も分からないです。

**デフォルトの名無しさん** · 2018/08/21(火) 20:17:35.28

無限ループ

**デフォルトの名無しさん** · 2018/08/21(火) 20:22:25.64

昔からその書き方の無限ループを好む人は多い
俺が知ってる範囲だとカーニハンもその書き方を好んでいた

88 · 2018/08/21(火) 20:22:27.49

>>89
(*´Д｀)ありがとうございました。

**デフォルトの名無しさん** · 2018/08/21(火) 20:27:12.52

無限ループって言っても
大概は何かの条件で脱出するわけだから
while (条件) が一番わかりやすいと思う
あ、好みだろうから、反論は不要です

**デフォルトの名無しさん** · 2018/08/21(火) 20:34:59.42

>>92
俺も無限ループはwhile(TRUE)派だな。
静的解析で怒られるから使うなって人もいるけど。
これも個人の好みなので反論不要です。

**デフォルトの名無しさん** · 2018/08/21(火) 20:45:15.49

無限ループには
for(;;)
while(1)
while(true)
などがあるようですが、驚いたことにfor(;;)がC言語の伝統的スタイルなんだそうで。

**デフォルトの名無しさん** · 2018/08/21(火) 20:50:55.87

goto 笑

**デフォルトの名無しさん** · 2018/08/21(火) 21:07:06.74

do {
} while (true);

だな

**デフォルトの名無しさん** · 2018/08/21(火) 21:12:46.13

true って新しいCだと使えるの？

**デフォルトの名無しさん** · 2018/08/21(火) 21:15:49.80

_Bool

**デフォルトの名無しさん** · 2018/08/21(火) 21:18:05.52

while (1==1)
なんて

**デフォルトの名無しさん** · 2018/08/21(火) 21:21:39.51

for(;;)は無条件であることを的確に表現してる
条件が書いてないのはこれだけ

**デフォルトの名無しさん** · 2018/08/21(火) 21:30:40.05

そういややったことないけど while () はできないのかな？
できたらできたでなんか怖いがw

**デフォルトの名無しさん** · 2018/08/21(火) 21:35:16.36

>>100
冷静に考えると、何でfor(;;)の真ん中の条件式のとこ空欄でも正しい構文になるんだろうね。
for以外に条件式省略できる構文ってないよね？

**デフォルトの名無しさん** · 2018/08/21(火) 21:39:06.78

if () ができたらなんか嫌だな

**デフォルトの名無しさん** · 2018/08/21(火) 22:56:19.30

>>102
確かに…

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/08/21(火) 23:14:00.83

左右の式が省略できるから、ついでに真ん中の式も省略可能にしたんだろう。

**デフォルトの名無しさん** · 2018/08/21(火) 23:18:17.02

二つのセミコロンも省略して良いことにしようｗ

**デフォルトの名無しさん** · 2018/08/22(水) 01:03:40.03

ループの話でふと思い出したんだけど、この書き方キモいと思う？

LOCK();
while (条件) {
　　UNLOCK();
　　LOCK();
}
UNLOCK();

**デフォルトの名無しさん** · 2018/08/22(水) 01:07:46.55

きもいけどきもいだけだから必要ならそうする
Cだしね

**デフォルトの名無しさん** · 2018/08/22(水) 01:11:58.05

condwaitみたいなの、たまに書くと混乱するわ

**デフォルトの名無しさん** · 2018/08/22(水) 01:18:33.81

LOCKして、何かして、UNLOCKして解放する
わけではないんだ？

**デフォルトの名無しさん** · 2018/08/22(水) 02:53:55.25

for (＼(^o^)／)

**デフォルトの名無しさん** · 2018/08/22(水) 06:53:07.59

>>108
while (条件) で統一したいと思いつつ、この手の場合LOCK, UNLOCKのインデントがズレててキモいなといつも気になってしまう
まあどーでも良すぎていつも放置するが

>>110
アトミックな条件チェックの話

**デフォルトの名無しさん** · 2018/08/22(水) 07:33:35.95

>>112
手動でインライン展開する必要がなければ、普通は、

while (check_func()) {
}

bool check_func(){
LOCK();
bool retval = XXX; // check something here
UNLOCK();
return retval;
}

とする。
C++なら inline を付ければインライン展開時（元のコード）と似たようなオブジェクトコードが出ることになっている。

**デフォルトの名無しさん** · 2018/08/22(水) 09:35:21.99

>>107
do {
LOCK();
UNLOCK();
} while (条件);

**114** · 2018/08/22(水) 09:36:42.99

ごめん、ちがた

**デフォルトの名無しさん** · 2018/08/22(水) 09:52:30.97

>>107
条件を判断するためだけにLOCK/UNLOCKを行うコードだとしたら最悪のコードだ

do {
LOCK
判断
UNLOCK
if (!判断結果)break;
} while (1);

素直にこうしなさい

**デフォルトの名無しさん** · 2018/08/22(水) 11:11:08.70

条件判断が目的じゃないと思うぞ

**デフォルトの名無しさん** · 2018/08/22(水) 11:35:04.81

どこが素直なんだ
締め切りが迫ってバグが取れず
なりふり構ってらんなくなったやつが書く
イカレたコードでしかない

**デフォルトの名無しさん** · 2018/08/22(水) 11:58:31.90

>>116
これは酷いw

**デフォルトの名無しさん** · 2018/08/22(水) 12:04:07.83

イカれたコードを紹介するぜ

**デフォルトの名無しさん** · 2018/08/22(水) 12:27:28.23

ん？
一番素直だろうが
条件判断の為だけにLOCKしてるという前提で

判断を関数に分ける？
分けるかどうかはこんなちっぽけな理由で判断するべきじゃないよ
判断の度に関数にしてたら意味不明な関数で溢れるぞ

もちろん意味が明瞭で他にも同じ判断を使う可能性があるのであれば
関数やマクロでパッキングすべきだが

**デフォルトの名無しさん** · 2018/08/22(水) 12:36:44.83

LOCK
判断
UNLOCK
というアトミックなシーケンスを関数にする理由はちっぽけじゃない
LOCK/UNLOCKが必要な具体的な場面を想定しての発言には見えない

**デフォルトの名無しさん** · 2018/08/22(水) 12:50:05.96

どういう場面かなんて>>107では判断不能だし
分けるべきか分けないべきかも>>107では判断不能

判断出来ないのに
「わざわざ関数構成を変えるべき」
なんて主張をすべきじゃない

**デフォルトの名無しさん** · 2018/08/22(水) 13:02:48.20

>>123
いやー、わからんのはあなたに実務もしくは勉強の経験がないからよ

**デフォルトの名無しさん** · 2018/08/22(水) 13:14:18.16

昨日のvoid func(int ary[100]);にしても
ary[1000]を警告する処理系の具体的な例が挙がってないしな

**デフォルトの名無しさん** · 2018/08/22(水) 13:39:37.67

>>124
わからんねえ
エスパーじゃないんだから

経験が少なくて
分けないべき場面が思い浮かばないんだろうねえ

**デフォルトの名無しさん** · 2018/08/22(水) 14:01:43.77

間違いない、昨日のバカだ
NGIDっと

**デフォルトの名無しさん** · 2018/08/22(水) 14:12:07.92

>>127
そういうあなたは昨日のイキってた方の人？

**デフォルトの名無しさん** · 2018/08/22(水) 14:15:28.00

パッと見て何をしているか分からないソースって
後の人が取っても苦労するし、気の毒

**デフォルトの名無しさん** · 2018/08/22(水) 14:19:13.21

多分書いた人の意図は　
while文内の判定時に
LOCKしたいのかとは思うが

**デフォルトの名無しさん** · 2018/08/22(水) 14:26:31.81

while ( ＾∀＾)

**デフォルトの名無しさん** · 2018/08/22(水) 15:10:17.96

check_func()というアドホックっぽい関数名が誤解のもとかな
get条件atomically()にすれば意図が明白

**デフォルトの名無しさん** · 2018/08/22(水) 15:19:38.80

atomicallyって文言いるかねえ
いちいち全部につけて回るより
LOCK/UNLOCKしてることは
忘れたフリができるほうがいいと思うが

**デフォルトの名無しさん** · 2018/08/22(水) 16:17:52.89

英語圏の人には for (;;) をまとめて熟語的に "forever" と読めて
座りがいいのかも知れん。
カーニハンとパイクの『プログラミング作法』に
それに近いようなことが書いてあった。

**デフォルトの名無しさん** · 2018/08/22(水) 16:25:37.12

>>133
条件取得の関数がすでにあってそれがアトミックでないケースも想定

**デフォルトの名無しさん** · 2018/08/22(水) 16:31:28.34

>>134
なるほどforeverか
そういう風にも読めるな

**デフォルトの名無しさん** · 2018/08/22(水) 16:44:34.35

>>134
そう言われると確かに座りが良いかもしれんが、(;;)をeverと読むのか。。。
今の時代では顔文字の失敗作にしか見えんなw

**デフォルトの名無しさん** · 2018/08/22(水) 16:54:07.40

>>134
#define ever (;;)
とかやんの？

だったら
#define forever for (;;)
のほうがマシだと思う

>>135
空想論なら付き合ってらんねえぜ

**134** · 2018/08/22(水) 17:01:35.42

「その部分のループ、終了条件が色々なんでとりあえず for (;;) で回して」
みたいな口答でのやりとりで for (;;) を forever と読めば手っ取り早いでしょ。
while (1) で…よりも言いやすいんじゃないかと。

これは空想論だけどね。

**デフォルトの名無しさん** · 2018/08/22(水) 17:28:26.65

無限ループで済むことを
forの第2式を空欄で
なんて回りくどい言い方しねえよ

**デフォルトの名無しさん** · 2018/08/22(水) 17:52:35.43

>>140
別に回りくどくないし
良く見るコードだよ

いろんな人のコードを見たりしないの？
みんないろんなポリシーでいろんなコードを書くから

いろんな書き方を知っていた方が良いよ

**デフォルトの名無しさん** · 2018/08/22(水) 17:59:10.07

while (条件)
でしかループが組めないのはちょっとさみしい

無理やりこの形にするために
>>107みたいな意味不明なコードになる

**デフォルトの名無しさん** · 2018/08/22(水) 18:07:38.93

>>141
口頭でのやり取りつってんだろ
流れを読めよ

**デフォルトの名無しさん** · 2018/08/22(水) 18:22:36.66

マウント取りたくて必死なアスペだから仕方ない

**デフォルトの名無しさん** · 2018/08/22(水) 18:30:03.99

口頭で
forの第2式を空欄で
なんて発想は出て来なかった

**デフォルトの名無しさん** · 2018/08/22(水) 20:52:31.01

for ( ；∀；)

**デフォルトの名無しさん** · 2018/08/22(水) 21:21:35.96

> while (条件)でしかループが組めないのはちょっとさみしい

ここは同意
while(1) であろうが for(;;) であろうが同じこと
どっちかが好みで他方で書かれたからって可読性が落ちたとか騒ぐ
救いようのないドアホには付き合ってらんね
それだけだ

**デフォルトの名無しさん** · 2018/08/22(水) 21:23:43.06

>>116を認めないお前も同じようなものかと

**デフォルトの名無しさん** · 2018/08/22(水) 21:26:52.07

whileで無限ループする場合、0じゃなければ1以外を
使ってもいいわけだがどうする？
電話番号とか使えばオシャレかもしれないよ

**デフォルトの名無しさん** · 2018/08/22(水) 21:27:18.15

とりあえず、おかしなのに絡まれた >>134 に同情を禁じ得ない。

**デフォルトの名無しさん** · 2018/08/22(水) 21:28:19.40

別にiocccのコードが読めろとか言ってない
int *aryがint ary[100]じゃなきゃ読めないとかぬかしたり
while(1)がfor(;;)じゃなきゃ読めないとかぬかす
想像を絶するアホには付き合ってらんねつってるだけ
lock/doit/unlockを関数化する必要性がわからないアホも含まれる

**デフォルトの名無しさん** · 2018/08/22(水) 21:33:30.14

>>151
「じゃなきゃ読めない」ってどこかに書いてたっけ？
そんな気はしてたが、やっぱり日本語不自由な人だったらしい。

**デフォルトの名無しさん** · 2018/08/22(水) 21:42:00.39

じゃあ喚くのやめろ
うるせえんだよ

**デフォルトの名無しさん** · 2018/08/22(水) 21:43:08.30

>>153
やっぱり日本語不自由な人なんだw

**デフォルトの名無しさん** · 2018/08/22(水) 21:51:19.93

何がじゃあなのかわからない
思考がbool値しかないのか

**デフォルトの名無しさん** · 2018/08/22(水) 21:51:23.19

アトミックな操作の意味がわかってたらああはならんのですよ

**デフォルトの名無しさん** · 2018/08/22(水) 21:52:48.42

世の糞コードのほとんどはコミュニケーションの失敗により発生する

**デフォルトの名無しさん** · 2018/08/22(水) 21:54:35.09

C言語以前に日本語もちゃんと理解できない人と議論が噛み合うわけない。
相手しただけ損したわ、アホらしい。

**デフォルトの名無しさん** · 2018/08/22(水) 22:02:56.29

勝手に損してろ
誰にも賠償請求できない
泣き寝入りだな
アホｗ　バカｗｗｗ

**デフォルトの名無しさん** · 2018/08/22(水) 22:05:01.83

はいはい、ちゃんとにほんごをべんきょうしてりかいできるようになってから、かきこんでくださいね。

**デフォルトの名無しさん** · 2018/08/22(水) 22:13:51.56

まあ概ね ID:yJL450CM が言っていることは正しい。

>>107のコードは、かなり特殊で、普通はあり得ない。
キモイかと問われれば、キモイと答えるのが正しい。
(必要ならやればいいが)

>>116
それはdo-whileの標準的使い方とは異なるので、混乱を招く。

>>132
check_func()は、107を書き直した場所がすぐに分かる名前にしただけ。
実際、問題なく伝わってるだろ。
本番コードでこの名前はあり得ない。名前が被るから。

ただ、正直、こんなどうでもいいところで拘るのは止めた方がいい。上達しなくなる。
どれでもいいから自分が好きなのを選び、グダグダ言わずにどんどん書いた方がいい。
なお、Goにはwhileが無い。廃止されて、forだけになっている。

ちなみに、俺は
固定長ループ（単純ループ）： for … for (int i=0;i<num;i++) 程度の簡単な場合は常にこれ
可変長ループ(複雑なループ）： while
無限ループ： while (1)
do-while：使わない
にしているが、正直、ここら辺は好みだし、自分がどう決めるかだけ。（上記は標準的だとも思っているが）
それよりは、自分の中で統一するほうが重要だ。
(少なくとも自分が書いたコードを読むときに混乱しなくなる)

業務なら、グダグダ言わずコーディングルールに従えばいい。
場所によってはwhileとforのどちらかが禁止とかもある。（どっちかは忘れた）
理由はバグって無限ループにしてしまったときにコード上から判定しづらいとかだったはず。

**107** · 2018/08/22(水) 22:19:27.48

非常にくだらない質問にレス付けてくれてサンクス
なんか荒れる原因つくってスマンかった

やっぱりあの書き方きめえよなあ・・・

**デフォルトの名無しさん** · 2018/08/22(水) 22:57:41.03

>>112
> LOCK, UNLOCKのインデントがズレててキモい
これは諦めろ。
酷い話、インデントがぴったり合ってないと駄目な奴はプログラマに向いてない。
どうやってもずれるからだ。
googleのコーディングルールにも昔は
・インデントを揃える努力は、キリがないしやるだけ無駄だから諦めろ
と書いてあったはず。（今見る限りないが）

ちなみにキモイ理由は、インデントではなくて、完全に入れ子になっていないからだ。
最近はこの「入れ子」の厳密さも増していて、XML(HTML等）では入れ子しか文法的に認めないだろ。
例えば、

<while>
</while>

ならありだが、

<lock>
<while>
</lock>
</while>

は駄目で、

<while>
<lock>
</lock>
</while>

にしなければならない。

**デフォルトの名無しさん** · 2018/08/23(木) 00:15:44.74

>>161
do while の標準的な使い方？
無限ループも標準的な使い方ですよ

do whileはforやwhileに比べてパフォーマンスが良いことがあるので
使える時には積極的に使う人もいます

do whileを一切使わない人もいますが

**デフォルトの名無しさん** · 2018/08/23(木) 00:29:51.18

>>107
対称性保たれてるし、よくあるコードだぞ。
俺はキモイと思わん。

**デフォルトの名無しさん** · 2018/08/23(木) 00:38:41.07

ロックしたい対象がわかりづらい
同じ用途のロック/アンロックが2箇所ずつある

**デフォルトの名無しさん** · 2018/08/23(木) 00:40:13.64

C++の場合だと
無駄にロック期間が長くなる可能性がある

**デフォルトの名無しさん** · 2018/08/23(木) 00:53:05.68

>>167
なんで？

**デフォルトの名無しさん** · 2018/08/23(木) 00:59:32.58

頭が良い人ならすぐに意図がくみ取れるけど
メンテする人が必ずしも頭が良いとは限らない
コメント書いてもバグではまって始めて読まれたりするからね
ワザと作られた落とし穴なんて受けとられる危険もありそう

バカでも分かるような書き方をする方が安全かなと思う

**デフォルトの名無しさん** · 2018/08/23(木) 01:59:34.18

>>164
>>116のコードは、while (1) で開始しても同じだし、（=do-whileを使う意味がない）
そもそも>>113に比べてメリットもないだろ。
そこで do-while 使う奴なんて皆無だと思うぞ。

まあそれでもやりたければやればいい。
個人開発ではメチャやって、その失敗を業務に生かした方がいい。

ただ、上達したければ、ある程度普通のコーディングルールで組んだ方がいい。（世間に合わせる）
自分と相手のルールが一致してたら、相手のコードも読みやすく、
結果、同じ時間、同じ努力でも読める量に違いが出てくるから。

あと、初心者はよく
・色々文法を知ってて、様々な書き方が出来る奴が偉い
と勘違いしがちのようだが、これは明確な間違いだ。（これは他言語では本当に酷い）
こんな糞どうでもいいところを様々な書き方をしているような奴は雑魚だ。
上手い奴は、そいつが決めたやり方に従って、一定の書き方で書く。
だから、後で読み直すときも楽だってこと。
自分の手書き文字なら相当汚くても読めるだろ。それに近い。

基本的には意味のない手動インライン展開は止めた方がいい。
それは無駄に関数を大きくする。
関数呼び出しのコストが気になるなら、C++なら inline が用意されてる。
そもそもロックなんて糞遅いから、そこでCPU命令数個ケチる意味もないはずだが。

可読性を上げる為に最初にやるべきなのは、関数を分割して小さくすることだ。
呼び出しコストは考えず、分割しまくった方がいい。
結果、抽象度が上がり、読みやすくなる。（全体を読まなくても済むようになる）

**デフォルトの名無しさん** · 2018/08/23(木) 03:30:32.78

あくまで、プログラマが初心者の場合の話だけど。

いろいろなソースを見てきたけど。
仕事としてやるなら、初心者は、なるべく関数化してほしくないかな。
練習としてなら、いいけどね。

関数化する等して、抽象化した方が見やすいソースになるかというと、
間違いじゃないけど、正しくもない。

有能なプログラマーが書いたソースは素晴らしいし、可読性も申し分ない、うん。
でも、クソなコードは、関数化しちゃいけないものが、関数化されているなどが原因で、
追跡が難くなるんだな。
オブジェクト指向を謳う言語のソースなんか、C以上にプログラマーの手腕によって、
可読性の差が生じてしまう。関数だけでなく、クラスの設計が腐ってて、どうしもないとかね。
そうゆうソースの追跡は辛いわ。

Cの場合、ぐちょくちょなソースの場合、関数化されていない方が、
コードのメンテ等で、強引に追跡する際は苦労が少ない、そんな感じ。

**デフォルトの名無しさん** · 2018/08/23(木) 04:08:27.50

そんなこたねえよ
関数を作った方がいいしファイルを分けた方がいい
ネストは浅い方がいい

**デフォルトの名無しさん** · 2018/08/23(木) 05:49:50.39

>>116
なぜわざわざbreakなんて使うんだ？
素直にこれでいいでしょ
do {
LOCK
判断結果 = 判断
UNLOCK
} while(判断結果)

**デフォルトの名無しさん** · 2018/08/23(木) 06:27:06.53

>>173
breakしないと条件が偽の時にも処理が動いてしまうからでは
きっとループの中になんらかの処理があるはず

**デフォルトの名無しさん** · 2018/08/23(木) 06:33:10.57

>>174
> きっとループの中になんらかの処理があるはず
書いてもないものが見える謎の病気w

**デフォルトの名無しさん** · 2018/08/23(木) 07:24:39.71

>>172
分割しすぎも考えものだけどな。
>>113も視点移動が増える書き方で、可読性やメンテナンス性が悪いという人もいる。

**デフォルトの名無しさん** · 2018/08/23(木) 07:52:07.91

>>170
do while のが軽い場合がある
って常識だと思ったが

>>175
私も当然他の処理があると思った
無いとするとビジーループか？
これだと気持ち悪いとかいう以前の問題になる

**デフォルトの名無しさん** · 2018/08/23(木) 08:12:35.84

>>172
行数やファイルの数で値段が決まる業界の人？

**デフォルトの名無しさん** · 2018/08/23(木) 08:16:18.32

全てのLOCK/UNLOCKのペアはそれだけで関数にする
2重ループやループ内のswitch caseは使わないで関数に分ける

いろんな人がいるね
自分では本当に例外なく実践してるんだろうか

**デフォルトの名無しさん** · 2018/08/23(木) 08:31:20.08

宗教の例

gotoは使ってはいけない
2重ループは使ってはいけない
3項演算子は使ってはいけない
インデントは全て揃える
全てのリテラルは別途定義する
変数名に型情報を埋め込む
関数の途中でreturnしてはいけない
関数は小さいほど良い
条件分の中に関数コールや副作用のある文を書いてはいけない
インクルードファイルをネストしてはいけない
コメントは全て /* */ で (// や #if 0 を使ってはいけない)
全ての演算子のネストに対して ( ) をつける
全てのロック、アンロックのペアは関数に分けなければいけない

**デフォルトの名無しさん** · 2018/08/23(木) 08:38:21.29

>>180
宗教の集大成がMISRAだな。
ほとんどがルールにあるわ。

**デフォルトの名無しさん** · 2018/08/23(木) 08:41:48.74

switch caseはは無駄にカラムを消費する。から嫌い。

**デフォルトの名無しさん** · 2018/08/23(木) 09:21:50.49

>>176
視点移動になるのは下手な関数化だ
サブルーチン呼び出しを1命令と読めるようにするのが
構造化プログラミングの本質

**デフォルトの名無しさん** · 2018/08/23(木) 09:48:06.49

>>183
ある程度の規模の関数になると結局その1命令に見えるはずの処理が正確に何してるかを理解するためには関数内を覗くはめになっちゃう。
覗かないですむほど関数仕様を単純化すると今度は関数が増えて管理の手間が増える矛盾。
後者のほうが正解なんだろうけど、なかなか理想通りには行かないよね。

**デフォルトの名無しさん** · 2018/08/23(木) 09:52:28.00

その方向性の行き着く先がオブジェクト指向

**デフォルトの名無しさん** · 2018/08/23(木) 09:52:54.19

>>184
ある程度の規模ってLOCK/UNLOCKの話だぜ？

**デフォルトの名無しさん** · 2018/08/23(木) 10:01:30.20

>>186
あ、そなの？
一般論かと思ってた。

**デフォルトの名無しさん** · 2018/08/23(木) 10:11:39.46

>>178
ファイル数とか初めて聞いたよ。
疎結合高凝集は大抵の場面で正義だよ。トータル1000行のソースだったら好きにすればいいが。
あと関数にもファイルにも「意味のある名前をつける」
ある意味大変難しいんだがこれができれば保守性が全然違う。

**デフォルトの名無しさん** · 2018/08/23(木) 10:34:14.06

規模は覗かないとわからんよ

1個の関数からしか呼ばれないたった3行の、
ただ単に特定のループの終了条件を示す為の関数
結局両方見ないと意味不明

こんな関数が山ほどあるプロジェクトは悪夢だ

**デフォルトの名無しさん** · 2018/08/23(木) 10:36:26.67

エディタが悪いんじゃないか？

**デフォルトの名無しさん** · 2018/08/23(木) 10:40:50.31

たった3行の為に
関数名を考え
関数ヘッダを作成し
プロファイリングや静的解析ツールやMAPの項目も増える

大きく依存した関数なのに
グローバル関数とローカル関数を分けて書くという宗教を理由に
全然別の場所に書く

最悪ですねえ

こういう人は
ifなども含め、複数文からなる全ての条件判断を関数にするんでしょうか
あり得ないですね

もちろん単なる1個のループの終了条件ではなくて
その条件に意味があって
他でも使う可能性があるなら関数に分けるべきですが

**デフォルトの名無しさん** · 2018/08/23(木) 11:09:24.18

>>187
改めて一般論をしても構わんが

**デフォルトの名無しさん** · 2018/08/23(木) 11:29:56.84

プロファイリングのときってstaticな関数も同列に扱うもんなの？

**デフォルトの名無しさん** · 2018/08/23(木) 11:40:17.42

ある程度の規模、って
サイトによって違うんだし
一般化はできないんじゃ

**デフォルトの名無しさん** · 2018/08/23(木) 12:10:32.95

>>194
地雷臭がするから煽るのやめとけってw

**デフォルトの名無しさん** · 2018/08/23(木) 12:48:09.07

>>177
> 私も当然他の処理があると思った
> 無いとするとビジーループか？
> これだと気持ち悪いとかいう以前の問題になる
君のレベルが低いだけ
最近のプロセッサはロック/アンロックをハードウェアレベルで行うようになってるけどビジーループ自体は使われてる
スピンロックでググれ

**デフォルトの名無しさん** · 2018/08/23(木) 15:13:34.14

>>195
アリガトス、鼻の敏感なお方

**デフォルトの名無しさん** · 2018/08/23(木) 15:40:21.02

>>191
行数の問題じゃないんだよなあ

**デフォルトの名無しさん** · 2018/08/23(木) 16:15:45.18

「長いから分割する」という発想で関数作ってる人は割といるんだよ。
そうするとまあコンテクストが広い範囲に分散してつらい。

**デフォルトの名無しさん** · 2018/08/23(木) 16:28:54.58

そういえば昔客とソースレビューしてて、
引数チェックのための早期returnしてたら、

客「途中returnはやめてください」
俺「そうするとネストが深くなりすぎますよ？」
客「それなら関数に分けて下さい」
俺「分けた関数の先でも引数チェックするので同じですよ？」
客「それならその先の関数も別の関数に分けて下さい」
俺「…(反論するのめんどくせえ、言うとおりに作ってしまえ)」

結果、思い出すのも恐ろしい意味不明な関数ばかりのコードが出来上がったわ。