C言語なら俺に聞け 140 [無断転載禁止]©2ch.net

2017/05/11(木) 22:20:03.99

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/

前
http://echo.2ch.net/test/read.cgi/tech/1487757355/
http://www.geocities.jp/c_cpp_cs/about_c/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2017/07/15(土) 17:16:20.81

>>881
聞いたことのあるセリフだなあ？
何だっけ？
北斗の拳？

2017/07/15(土) 17:16:23.73

これだからなスクリプタは
スクリプタがプログラマ気取るなよと
トホホ

2017/07/15(土) 17:27:16.03

>>885
アホなの？
size_t x;
って宣言されててもどっちの解釈もできるだろ
って話だぞ

2017/07/15(土) 17:42:18.56

大元の話で . 演算をポインタに対して適用したら ->とみなすという仕様なら矛盾はないと思うが、
>>843で「左辺が」とか書いたんで話がおかしくなっている気がする。

2017/07/15(土) 17:57:08.70

>>889
違うね。
>>888は「右辺を評価する際、 . を . とみなすか -> とみなすか区別できない。なぜならば結果が同じだからだｷﾘｯ」
という論理らしいが、そもそもそんな仕様の言語なんて無い。スクリプト言語ですらも。
そもそも着想の仕方がおかしいだろ。エアプだからだよ。

エアプはマジで死ね。

2017/07/15(土) 18:03:19.98

ドットに統一した場合、コードレビューでNULLチェックを見逃す可能性がある
こっちの問題の方が大きいかもしれんな

2017/07/15(土) 18:56:38.12

諸先輩方ご意見ありがとうございました
とりあえずその場所場所でのコーディングスタイルに合わせることが大事なのはわかりました

2017/07/15(土) 19:20:07.01

>>890
> そもそもそんな仕様の言語なんて無い。
そりゃアホの子の>>843がない知恵絞って考えた言語仕様だし
今更何を言ってるんだよって話だが w

2017/07/15(土) 20:28:46.13

>>891
-> を廃止して . に統一するのならその手の型チェックは緩くなる。
これは結局のところ、他言語でもなされている議論と同じで、
「静的チェックのための記述をどこまで許容するか」でしかない。
俺はCなら厳しい方が似合っていると思うが。

それはさておき、具体的にそのケースならnull許容型、って奴だろう。
他言語でも死ぬほど議論されているからググれ。

2017/07/15(土) 22:24:26.68

>>886
画像検索汁

2017/07/16(日) 00:35:41.14

>>894
C言語とは水準が違いすぎる話なのでナンセンスというのが結論だろう
NULL許容で書けたところで、実行時にはNULLチェックするわけだから

2017/07/16(日) 01:49:05.19

>>896
> NULL許容で書けたところで、実行時にはNULLチェックするわけだから
いや、そうじゃない。
というかそっちの議論も多いようだから、誤解するのも分かるんだが。
以下を読むのがいいだろう。
> null許容参照型
> http://www.buildinsider.net/column/iwanaga-nobuyuki/012

Cに対して導入するとしたら以下か。
1. 「null非許容のポインタ」を文法的に用意する。
2. 「null非許容のポインタ」にはNULLは代入できない。（SyntaxError)
3. 「null非許容のポインタ」に「従来のポインタ」の値を代入するには明示的なキャストが必要。
これでヌルポを静的に検出できるようになる。
「null非許容のポインタ」に関しては実行時のNULLチェックは必要ない。

問題は3で、C++ならdynamic_castのみとして例外を投げればいいのだが、
Cの場合これは無理なので、
・リンター等でキャスト直前にNULLチェックしているかを検出する
・明示的キャストをマクロ等でNULLチェックのインライン関数等に置き換える
等の対策が必要にはなるが、
それでもNULLに対してクリーン/ダーティな区画を文法的に分離できるようになるので、
今よりはだいぶマシにはなる。

とはいえこれはbetterCとしてC++を使うのなら現行のC++でも似たようなことは十分できる。
だからわざわざ新文法が必要か？というのと、他と同様に、
静的チェック「だけ」のための新文法を導入する価値があるのか？
という話にはなる。
そして . と -> の話に戻すなら、
「『null非許容型の』struct* から *structへの暗黙的キャストを認める」
という仕様なら、そちらの危惧している部分については回避できることになる。

2017/07/16(日) 07:21:30.62

>>889
だから . 演算子を適用した結果がポインタならどうするんだ？
って指摘されてるだろ
ID:4RmHy8z30 はレスできなくなって
> エアプはマジで死ね。
とか恥ずかしい捨て台詞で逃げてるけど w

2017/07/16(日) 07:28:16.81

>>897
> 問題は3で、C++ならdynamic_castのみとして例外を投げればいいのだが、
> Cの場合これは無理なので、
> ・リンター等でキャスト直前にNULLチェックしているかを検出する
> ・明示的キャストをマクロ等でNULLチェックのインライン関数等に置き換える
> 等の対策が必要にはなるが、
そんなアホな対策は要らんわ
キャストまでしてNULL非許容の変数にNULL入れる奴はわかってやってるんだからそのまま入れてくれればいい
それに起因するエラーはプログラマの責任
C言語ってそう言う言語だろ

2017/07/16(日) 07:41:24.58

>>898
>だから . 演算子を適用した結果がポインタならどうするんだ？

. 演算の対象がポインタかそうでないかで分かれるだけで、演算の結果は
それがポインタならポインタとして扱えばいいだけだろ。何か問題あるのか？

2017/07/16(日) 08:14:36.33

>>900
なら>>858のケースで値が欲しいときはどうするんだい？
まあ新しい演算子を追加するのか？

2017/07/16(日) 08:28:51.97

*sp.aで取れるじゃん

2017/07/16(日) 08:32:10.19

>>858で x に入るのはbへのポインタとしか解釈しようがないと思うが、値とはどれのことを言っている？
bの値の1が欲しいなら普通に x = *sp.a; でいいだろ。

2017/07/16(日) 09:37:42.33

>>902-903
要するに構造体へのポインタに対する . 演算子は今の -> 演算子と見なせってことね
>>883みたいな奴がいるから念のために確認しただけ
仕様として矛盾はないと思うけど
struct s sl;
struct s *sp;
x = *sl.a;
x = *sp.a;
と統一的に書けるから便利と思うか
x = *sl.a;
x = *sp->a;
とたいして変わらんと思うかは人それぞれだと思う

2017/07/16(日) 09:51:29.40

要するにも何も、>>889でそう書いているんだが。
で、>>898が「念のために確認しただけ」なわけ？

2017/07/16(日) 09:59:26.34

要するに、(*p).m を p.m と書けるということ
つまりデリファレンスの階層を一個省略しようってことで、
格段便利ってわけでもないし、かえってややこしいかもなw

これ、ポインタが何段になっても p.m って書いて整合性取れるかい？

2017/07/16(日) 10:06:14.91

>>902-903
だからエアプなんだって。話の通じなさ具合がおかしいだろ。

>>899もそうだ。
> キャストまでしてNULL非許容の変数にNULL入れる奴はわかってやってるんだからそのまま入れてくれればいい
Cの場合はmallocの失敗がNULLになるんだから、これとかありえないだろ。
Cはnullありき、キャストありきで世界が構築されているから、
ヌルポ対策を静的にやりたいのならキャストも含めないと使い物にならない。
しかしエアプだからこれが分からない。マジでウザいから死ね。

> C言語ってそう言う言語だろ
これも違う。
C言語は静的な対策を拒否してない。動的な対策は全面拒否だが。
つっても通じないとは思うが。

>>904
> struct s sl;
> x = *sl.a;
エアプマジ死ねよ

というか、エアプがここに来る意味が俺には分からないのだが。
こいつらどの種のキチガイなの？

2017/07/16(日) 10:11:57.19

>>905
だからアホがいるから蒸し返されないように念のための確認してるんだよ
匿名掲示板だから>>890みたいな奴すらいるんだぞ

2017/07/16(日) 10:12:48.56

って書いてるそばから現れたわ w

2017/07/16(日) 10:14:08.60

>>906
> これ、ポインタが何段になっても p.m って書いて整合性取れるかい？
それは大丈夫だと思う

2017/07/16(日) 10:21:16.17

>>910
俺はまだそこがちょっとひっかかるんだよな
デリファレンスが一個ずれるだけなら意味ないと思うしね
時間ができたら検証してみるよ

2017/07/16(日) 10:33:31.23

>>906
> これ、ポインタが何段になっても p.m って書いて整合性取れるかい？
実体になるまでデリファレンスしろ、というだけだから、出来なくはないと思うが。

> 格段便利ってわけでもないし、かえってややこしいかもなw
まあCがほぼ完成しているからな。導入する価値があるか微妙というのは同意。
> Cが見事にこなしていることは、全く"出来るだけシンプルにせよ、
> しかし、それ以上シンプルにするな"をしていることだ。
> そして、そのことがCを素晴らしいものにしている。言語はパワフルでありながら、ほぼ最小である。
> by Linus Torvalds
> https://srad.jp/~taro-nishino/journal/509450/

俺が思うに、Cに必要なのは階層（≒関数内関数)だよ。一部拡張されているようではあるが。
最近別言語だがCスタイルの記述（グローバル+関数、非オブジェクト指向)を読んだことがあって、
22K行のコードだが初見で簡単に目的のコードを探し当てられて、軽く衝撃だった。
Cが読みにくいのは100-500行のファイルで細切れになっているからであって、
あれ、設計者が分かりやすい順にcatしてくれていれば衝撃的に読みやすいことに気づいた。

2017/07/16(日) 10:47:18.34

あと、前方宣言必須というのも糞だ。
というか、今だにあれを放置している理由がよく分からない。

あれが無ければトップダウンで記述できるのでさらさら読める。
あれのおかげで下から構築しないといけないので、(include等つかって擬似的に回避できるが)
詳細まで確認する必要が無いときにも読まなくてもいい関数を読まされる事になる。

元々「世界の全てを把握して、絶対神として振舞え」という言語ではあるから、
「読みたくも無い関数を読まされたくねー」オブジェクト指向感性とは合わないが、
今更全てを把握できるほど世界は小さくないし、その必要が無いことも多い。
色々手抜きできる言語があることを知ってしまってからは、もっと手抜きさせてくれよーとは思う。

◆QZaw55cn4c (ﾜｯﾁｮｲ 466d-RG79) · 2017/07/16(日) 12:56:07.96

>>913
前方参照は確かにどうかと思うが、前方参照の制限が解消されたからといって読みやすさが改善するとは思えないね
現状でも底から読んでいけばいいだけなのではないか？
読みやすさは…識別子を日本語で書くのがよさそうだが

2017/07/16(日) 18:30:50.90

typedet struct
{
　　　　void ( *reset_func )( void );
　　　　unsigned long initial_stack;
　　　　void ( *divide_by_zero )( void );
　　　　・・・
}　　　 intvec_t;

#define INTVEC　　( *( intvec_t* )0 )

2017/07/16(日) 21:14:38.36

> 要するに、(*p).m を p.m と書けるということ

これ、できるできない以前に、初心者にきついな。
ルールを覚えるのは楽だけれど、例外事項が増えてくると、結局暗記になっちゃうからなあ。

2017/07/16(日) 21:46:19.69

2017/07/16(日) 23:15:41.79

>>913
プロトタイプ宣言というのがあってだね、それを宣言すればトップダウンで書ける。

2017/07/17(月) 03:39:18.28

>>918
だよな
トップダウンなだけでなく
関数の一覧ができているという点でも
>>913が書いていそうな糞コードのDBL_MAX倍マシ

2017/07/17(月) 05:22:39.76

>>918
>>913はそれを知らないで書いてたのか？とするとかなりの初心者ということになるが。

2017/07/17(月) 05:32:30.17

まあしかし俺は同じファイル内にあるにも関わらずプロトタイプ宣言入れないと
わかってくれないのが嫌で使われる個所よりも上に書いちゃうけどな。
同じファイル内なんだからわかって欲しいものではある。

そういや PASCAL なんかも前方参照しかなかったような気がするな。
あの当時の言語はこういうの当たり前だったのかな。
PASCALなんかだとわざわざそういう思想で作られたって感じもするが。
Cだと手抜いただけのように見える。w

2017/07/17(月) 06:51:56.93

うん、Cのバヤイは確信的な手抜きだな

2017/07/17(月) 07:49:13.30

ほー PASCALが前方参照しかないとか初めて聞いたわ

ID:kT8dsikx0とID:6JtF0HSC0の次の活躍に期待だな

2017/07/17(月) 07:57:41.59

何時、前後を覚えるのかな？

2017/07/17(月) 08:01:01.05

>>921
Pascal は　LL(1)言語としてつくってあり、ワンパスでパースできる、その意地があるんだね

2017/07/17(月) 08:11:52.63

Cもワンパスのため前方宣言必須ということのようだが、
一回舐めて拾うだけでいいんだし、今時こだわる必要も無いだろう
ヘッダに出した公開インターフェースは先、モジュール内プライベートはその下がわかりやすいよな

2017/07/17(月) 08:13:23.74

>>926
C はプリプロを除いてもワンパスにはならないと思う

2017/07/17(月) 08:53:08.22

>>918
>>913がプロトタイプ宣言知ってるかどうかは知らんけど同じ情報を二ヵ所に書かないといけないのはいかがなものかと思う
言語仕様を決めた当時はI/Oも遅いので高々数回のパースでコンパイルする必要あったからしょうがないとは思うが

>>921
Pascalは1-Passでビルドできるように言語仕様を決めていた
なので当初はモジュールみたいな概念もなかった

2017/07/17(月) 08:57:46.36

>>920
さすがに知っているぞ。
俺は君と同様それはほぼ使わないというだけで。
というか、あの「事前に分かってないと使えない」事は正確には何と言うんだ？
「前方宣言必須」というのはどうも「前方宣言」自体が別の用語らしいのでまずかったようだ。

>>921
Cの場合、1パスコンパイルするためのものだ。
Cは紙テープ時代からある。
Wikiによると10文字/秒らしいので、1KBのファイルなら読み取りに1分40秒かかる。
これで2パスされると死ねるから、1パスでいけるように、
あらかじめ人間が順番を整えとけ（＝機械に人間が合わせろ）というものだ。
どう考えても今はそんな時代じゃないだろ。
2パスに変更して「後方参照」（という用語でいいのか？）出来るようにすればいいだけだ。
紙テープの時代なら時代の要請だが、HDDの時代にこれを大事に守る理由は無い。
だから新しい全ての言語はこの制限は無い。必要ないからだ。
(ただしPythonを除く。この点だけでもPythonは糞だと断定できる)

ところがな、>>919みたいな老害は、
できる理由を見つけてきて頑なに現状維持しようとするものだ。
Cの場合は、確かに下から構築していけばプロトタイプ宣言は通常全く使わずに構築できる。
だからそれが作法になってしまってるだろ。
Pythonの場合はおそらくこれ、つまり、下からの構築を強制させるためにあえて採用してないのだと思う。

しかしな、他人のコードを一から読むとき、下から読む必要はなく、上から読んだほうが楽だ。
（正確には中レベルから。一番上のレベルも読む必要ないから）
お前らがそれに気づけてないのだとしたら、お前らはCしか読んでないからだ。
というか俺も最近までそうだったのだが。

2017/07/17(月) 08:58:08.57

既に書いたが、Cの読みにくさは、ファイルが細切れになっていることもある。
これはOOPも別の意味で同罪で、「で、その処理は具体的にはどこに書いてあるんですかね？」は常だ。
だからそんなものだと思っているのだと思う。

ところが最近、後方参照できる言語でCスタイルで書かれているコードを読んで戦慄した。
圧倒的に読みやすいのだ。（OOPよりも）
上からスクロールしていくだけで、読み飛ばしていいか、そうでないか、はっきりと分かった。
ところが肝心のCにはこの類のソースコードは存在しないんだよ。後方参照禁止だから。

後方参照が出来るようになれば、設計者が自由に関数を配置できるようになる。
当然、一番分かりやすいように並べることになる。
今のCにはその自由度が無いんだよ。人間が機械に合わせる仕様だから。
「プロトタイプ宣言」とかいう二度手間をやらないと、最もわかりやすい順に並べられない。
だから今のCソースは基本的に「分かりにくい」。
少なくとも後方参照できればもっとわかりやすくなる方向でしかない。
だからいまだにそれを放置しているのはマジで糞だって事。
老害的には「下から構築しろ」という教育効果を主張するのだろうが、そんなのは要らない。

2017/07/17(月) 08:59:15.27

>>927
シングルパスでダメな構文あったっけ？

2017/07/17(月) 09:03:20.21

ここで議論している人の　前方宣言　後方参照　の定義が一致しているのか気になる。

2017/07/17(月) 09:07:49.80

>>929
> (ただしPythonを除く。この点だけでもPythonは糞だと断定できる)
Python の def が「実行文」であることも知らんのだろうな w

2017/07/17(月) 09:11:05.59

>>932
というか今更その辺の用語は無いんだよ。理由は他言語では必要ないから。
「後方参照」も正規表現でしか使われてないし、
しかもあれって「後方」よりも「バッファ」と言え、という類のものであるし。

とりあえず俺の定義は、
前方宣言必須：どうやらこれは俺の誤用だったすまん。「事前に宣言しておかないと使えない」の意で使ってた
後方参照：後で定義されている関数を使うこと
だね。これが適切かは分からんが、Cやってる奴ならあーはいはい程度には通じるとは思う。

2017/07/17(月) 09:14:46.40

>>933
知らんね。
つかあれ、そうなのか。だとすると動的に構築するから致し方なし、って奴か。
JavaScriptが糞な点と同じだな。

まあどの道2パスすれば回避できるだけのことを、なぜやらん？ってのはある。
Pythonは聞けば聞くほど糞なので、俺はやってない。

2017/07/17(月) 09:19:12.83

>>927,931
たとえばgotoのラベルは下でもいいよね
たかだか関数内限定ではあるけど

>>932,934
今話してる文脈は「Cの前方宣言必須について」でいいんじゃないの？

2017/07/17(月) 09:39:52.04

引数が無い宣言のこと特別に「前方宣言」と言うのか
知らんかったわw
http://wisdom.sak ura.ne.jp/programming/c/c27.html

2017/07/17(月) 09:50:00.72

>>935
知らないなら黙ってりゃいいのに
知ったかはこれだから...

2017/07/17(月) 09:54:21.13

>>936
Pascalはラベルに数値が（と言うか数値しか）使えないこととコンパイラを単純にするためにlabel文で宣言が要るけど、コンパイラの実装としては必須じゃないでしょ
goto文の飛び先はラベル見つけた時点で入れればいいだけだし

2017/07/17(月) 10:26:39.93

K&Rの時代じゃあるまいし、前方宣言を原型形式でない関数宣言子と捉える奴なんていねーだろ
プロトタイプ宣言とか言い出した>>918は例外として

2017/07/17(月) 10:42:28.15

>>938
お前はPython信者なのか？ならばもう一度言ってやるよ。Pythonはそこも糞だ。

Pythonはdefで関数宣言を行い、それがそのままオブジェクトになる仕様らしい。
つまりそこで暗黙の代入があるから、後方参照できないとの理由だ。まさに糞だ。

JavaScriptの場合は、これらの宣言を分けている。つまり、
function func0(){console.log('func0');} // (A) console.logはCでいうprintf
var func1 = function(){console.log('func1');}; // (B)
ここでfunc0は後方参照できる。つまりスコープに入っていればいつでも使える。
func1は関数ポインタであり、代入以降でしか使えない。
これが妥当な仕様だ。
関数ポインタは再代入可能だから、順に処理する必要があるからだ。

Cの場合、関数ポインタへの代入は自前で行うわけだから、
コンパイラの努力だけで後方参照できないという制限を解除することが出来る。
いまだにやってないのはただの手抜きというよりも確信犯だろうが。

なおJavaScriptでもPythonと同様に関数はオブジェクトになるのだが、
要するに「スコープ内で先に処理して再代入禁止にしておくべきfunction(A)」と
「順に処理するべき関数ポインタ(B)」を明示的に分離して記述できるだけだ。
みたところPythoｎには(A)しかなさそうなので、技術的に出来ない理由は無い。
この点についてはCも同様に糞だが、時代の要請があったという理由はある。
Pythoｎは本当に何の意味も無く制限をつけている、ただの糞だ。

2017/07/17(月) 10:49:45.35

知ったかが慌ててググって的はずれの長文乙
Python 関数ポインタ
辺りでググる程度の知恵もないのが残念だが w

2017/07/17(月) 10:50:54.11

>>937,940
俺もそれを知らんかった。
そしてそのページでそれを確認し、K&Rみたら確かに「プロトタイプ」となっている。
だからどうやら俺の誤用だった、とした。

ただまあ、その意味での「前方宣言」なんて見たことないんだけどね。

2017/07/17(月) 10:55:39.50

Pythonはファイルの最後に
if __name__ == 'main':
main()

ってやる関係で、結局実行は最後になるからdefの順番とかで困ることはまずないな
せいぜい関数内関数定義で先に書くか後で書くかくらいか？
一体どんなコード書いてりゃそんなどうでもいいところで引っかかるんだ

2017/07/17(月) 10:57:04.61

>>942
Pythonのdefは941で言う(A)なんだよ。
だから後方参照できない技術的理由は無い、という見解だ。
お前には通じないようだが。

それとは別に(B)の記述はPythonでも出来る。
というかこれが出来ない新しい言語なんて無い（ただしJavaを除く）

2017/07/17(月) 11:02:44.43

>>941
> みたところPythoｎには(A)しかなさそう

>>945
> それとは別に(B)の記述はPythonでも出来る。

バカの上塗り w
そもそも>>944が言うように前方参照の話ですらないのに何を必死になってるんだか

2017/07/17(月) 11:55:17.77

>>929
あーそう、「ほぼ使わない」のか
チームメイトが（いれば）お気の毒だね

正規表現の「後方参照」はここでの話と全然関係ないぞ
コンパイラにとって初見の識別子があとで宣言されることを
MASMでは前方参照と言っていたが、
Cでは「undeclared identifier: 宣言されていない識別子」
となっているだけだ（もち violation of the syntax）
ちなみにISO/IEC9899には全然違う意味の
「forward declaration: 前方参照」という用語がある

老害を小馬鹿にしたいようだが、脇が甘すぎだぜおまえ

2017/07/17(月) 12:33:21.67

>>947
脇が甘いもなんも、お前も全員が妥当だと思う用語を持って来れないだろ。
だったらお前も俺と同レベルなんだが。
913の時点で「『宣言されていない識別子』は禁止」では何を言っているのか通じないだろ。
(「前方宣言必須」は厳密には間違っているが、C使いには意図は100%通じてるだろ)

というかお前は老害ではなく若いのか？その突っかかり方はガキっぽい。
2chは言葉の定義にやたらこだわる奴が多いが、それはただのクソガキで、
仕事してりゃ分かるはずだが、実は社内方言ってのはものすごく多くて、
社外だと全く通用しないことすら自覚できてない場合が殆どだ。
だからすれ違いを感じたら>>932のように確認するのが常で、
俺はそれを受けて>>934と応じた。
ここら辺は仕事をしたことがあればよく見かける光景ではあるはず。
もちろん方言ではなく共通語を使う努力をすべきなのは言うまでもないが、
問題は方言を使っている奴は方言だと認識してないことなんだよ。

だから俺が方言を使っていれば、お前が正しい共通語を示せばいいだけの話であって、
今現在は(需要が既に無いから)共通語自体が存在しない状態だろ。
それをいちいち勝った負けたされても知らんがな。

で、まあ、話を戻すと、
(俺はPython使いではないから間違っているかもしれんが)
俺の理解では、Pythonは「プロトタイプ宣言が出来ないC」だ。
この理解が正しければ、糞だということで割と賛同を得られると思うが。
>>944は糞を量産していることに気づいてないだけだ。

ただそれとは別に、プロトタイプ宣言は無くても通常は構築可能で、
Cはそれが作法になってるだろ。
例えばファイルの先頭でファイル内全関数をプロトタイプ宣言してるソースなんて見たことないだろ。
（コーディングルールとしてこれをやっている所があってもおかしくないが、誰か知ってるか？）
ただ、Cはこの手間をかければ順序は自由にはなるが、Pythonはそれすら認めてないだろ。
この辺、Pythonは無駄に教育的で実践的ではないんだよ。

2017/07/17(月) 12:54:14.08

そうそう普通PL/Mだよね

2017/07/17(月) 13:28:45.97

俺が糞を量産しているというのは穏やかではないな
if __name__ == '__main__'が糞といいたいのか？
ちょっとPythonスレで議論しようよ

2017/07/17(月) 13:37:29.75

夏だな

2017/07/17(月) 14:40:04.91

forkで子プロセスから、子プロセスを終了させたあとに親プロセスを終了させる方法無いですかね？

親プロセスはwhile(1)で回していて、子プロセスで入力を受け取るのですが、ある入力が来たときだけ、プログラムを終了(子プロセス親プロセス両方共終了)させたいです

2017/07/17(月) 14:45:33.81

親プロセスでwaitpidして子プロセス終了してたら自分も終了すれば良いじゃん

2017/07/17(月) 14:54:49.57

>>953
子プロセスは自動で死ぬこともあるんです
だから、子プロセスが自発的に親プロセスを終了させよつとしない限りは親プロセスは行き続けて欲しいです

2017/07/17(月) 14:58:31.67

終了ステータス変えるとか、共有メモリで適当なフラグもっとくとか、事前に適当なシグナル送るとか、いくらでもやりようあるだろ

2017/07/17(月) 15:09:00.52

>>950
行かんよ。俺はPythonの文法もろくに知らないし、使う気もないし。
ただ、俺の理解
> Pythonは「プロトタイプ宣言が出来ないC」だ。
が間違っているのなら、指摘してくれよ。
これが間違いでないのなら、このスレの過半数は糞認定すると思うぞ。

上記が正しいとして、君が糞を量産していることを自覚できていないのは、
C専読者と同じで、Cスタイルで「上位から」書かれているコードを見たことがないからだ。
というか俺もつい先日までそうだったんだが。

とりあえず簡単に確認する方法として、循環参照がある。
例えばCなら、以下になる。

viod say_hello(count){
if (--count<0) return;
printf("hello");
say_world(count);
}
void say_world(count){
printf(" world!\n");
say_hello(count);
}

後方参照できるJavaScriptなら、これはベタで書いてそのまま動作する。
Cだとプロトタイプ宣言が必要だが、実体は上記の通りで動作する。
Pythonは余分な方法を使わないとこれが出来ないんだろ？

これとは別に、そもそも循環参照コードなんて書くなというのはあって、
これを教条的に強制しているのがPythonだろ。
下位からの記述を強制されている場合に、上位から読みたければファイル末尾から読め、
でしかないというのも事実だから、そんなに致命的でもないんだが。

2017/07/17(月) 15:25:01.26

>>956
> Pythonは余分な方法を使わないとこれが出来ないんだろ？
普通になにもしなくてもできる
必要なのは>>944のが書いてる
> Pythonはファイルの最後に
> if __name__ == 'main':
> main()
だけ
て言うかPython知らないなららPython云々で語るなよ
アホの戯れ言をいちいち訂正するのが面倒すぎる

2017/07/17(月) 15:29:13.95

>>955
ありがとうございます
出来ました

2017/07/17(月) 15:32:56.88

すまん、>>956は間違いのようで、Pythonでも関数間の参照自体は出来るらしい。
> 再帰関数の前方参照
> http://www.isc.meiji.ac.jp/~mizutani/python/recursive_call.html
だから関数定義を全部先にしてしまえばいいということになる。
それが見易いとは思わないが。

しかしCは関数内関数が無いのでそれ以前だ。
GCC拡張を利用するなら、
関数内関数を全部「頭」に配置しないといけないのがPython、
どこに配置しても自由に呼び出せるのがJavaScriptということになる。
GCCの場合はCと同様プロトタイプ宣言とかも関数内に使えて配置も同様、ということなのかな？

>>957
ああ悪い、こっちも確認した。上記の通り。
というかPythonの話は止めよう。俺はそっちには興味ない。

話を戻すと、俺が思うCに足りないのは「階層」と「後方参照」だ。
これら2つがあれば、今現在細切れになっているファイルを1つに束ね、
一番読みやすい順にソートできる。
お前らがピンと来ないのは、多分俺と同じで、見たことがないからだ。
後方参照できる言語でCスタイルで書かれた大規模コードを一度見れば分かると思うよ。

2017/07/17(月) 16:45:34.15

俺ってばこんなこんなに何も分かってない奴に「糞コード量産してる」とか言われてたん？
失礼な奴だな本当に

2017/07/17(月) 16:53:25.99

ctagsとか、タグジャンプつかおうな？

上から下にならべてあるから読みやすいですとか、眺めてるだけですと、宣言してるようなものだ。

トレースする気がないべ？

2017/07/17(月) 17:26:09.82

>>960
いや事実だぞ。

君は都合が悪い部分には回答しないようだが、プロトタイプ宣言が無いのは事実だろ。
それは下位関数も含めて全部上側で記述することを強制する。
C言語でプロトタイプ宣言が無い場合に似ている。
ただし関数内から別関数への参照は「動的」に行われるのでCより制約は緩くなるが、
本質的にはあまり変わらない。
そもそも、下位関数なんて名前を見たら実装なんて見ずとも結果が分かるべきものだし、
それがオブジェクト指向の思想だろ。下位関数は読む必要なんてないんだよ。

俺は「『君が無能だから』糞コードを量産している」と言っているわけではない。
Pythonの仕様が糞だから、「Pythonでは糞コードしか書けない」と俺は言っている。
そこを君は勘違いしている。

それはそうと、Pythonのスレ試しに見てみたが、相当酷いな。あれじゃマ板だよ。

>>961
IDEに使って本格的に読めばその辺も含めて改善するのだろうが、
設計者が分かりやすいようにソート済みなのと、
コンパイラに都合がいいようにソート済みなのでは、全然違うんだよ。
そしてCは「ファイル」を階層として使っているのだが、これがもう古い。
タグとか使って一発で飛べるのなら余計に1つのファイルにまとめてあったほうが好都合だろ。
（もっともタグ使えば複数ファイルでも飛べるのだとは思うが）

ただ、俺が求めている階層は関数内関数で十分で、
GCCで採用されているのでいいんだが、アレは何で標準にならないんだ？

2017/07/17(月) 17:45:56.64

トランポリンコード必須なGCCの関数内関数が標準に入るわけないだろ

2017/07/17(月) 17:52:48.13

>>952
親プロセス while (1) で回してるって、その while (1) の中でやってる処理はなんだ?
wait() してないのか? wait() してるならそれで子プロセス側の exit() のステータス
受け取れるからそれで親側で判別すればいいんじゃない?

てか、これCはCでもUNIX系OS固有の話だよな。ここだとスレチにならんか?

2017/07/17(月) 17:54:48.33

あ、もう解決済みだったか。すまん。

2017/07/17(月) 17:54:54.48

ならんと思うし、解決済みだぞ

2017/07/17(月) 18:06:17.25

>>959
まあそれで見やすくなるだろうから、そういうCを拡張した新しい言語作れば良い。
しかし、問題はC(あるいはそこからちょっとしか拡張されていないような言語)を
人間が直接使う機会はおそらく減り続けることにある。今でもほとんどOSや
デバイスドライバを記述するアセンブラ代わり

2017/07/17(月) 18:07:19.84

>>962
お前のいうことは完全に間違い。Pythonスレでならちゃんと答えてやる
興味がないならこれ以上その浅はかな知識をひけらかすな

2017/07/17(月) 18:07:38.79

あ、ごめん。途中で送信しちゃった。
つづき。
↓

に使われてるしね。

2017/07/17(月) 18:40:56.88

関数内関数って要するに高階関数のことだろ
関数型言語または関数型のマルチパラダイムの言語でないと無理だろ

2017/07/17(月) 18:46:26.39

Objective-Cで全部可能ではある
C言語でもclangならblocks拡張（関数オブジェクト・クロージャ）が使える
関数内関数は単純に制御構造だと捉えれば、C言語でもgoto文で可能でしょう

2017/07/17(月) 18:54:16.64

Blocks拡張は有能なのは分かってるけど、Clang依存コードになるからちょいとハードル高いよなあ

2017/07/17(月) 18:59:20.24

>>948
いやコンパイラにとって初見の識別子があとで宣言される
という形になっているコードについて話しているのは
みんなわかってるのに、頓珍漢な言葉遊びに持ち込もうと
している邪魔な奴がおまえだ

> Cはそれが作法になってるだろ
はあ？　聞いたこともねえぜ、寝言は寝てぬかせ
横着しねえでちゃんとプロトタイプ宣言すんだよ
正直たまにサボることがあるのを恥もせずに
それがスタンダードとか居直るおまえの態度が鼻持ちならん

2017/07/17(月) 19:03:14.17

ヘッダにはプロトタイプ宣言を書くだろうに
なんでプロトタイプ宣言をなかったことにしたがるのだろうか？

2017/07/17(月) 19:03:27.54

>>972
俺も非依存性重視なので、拡張なしの標準的なCでやってるよ
プロトタイプ宣言とクロージャは諦めなきゃならないが
クロージャはコールバック関数のポインタを渡すという伝統的なやり方でできる

2017/07/17(月) 19:17:54.83

>>975
諦めなきゃならんのか出来るのかどっちだよｗ
いやblockなしでクロージャ出来るんなら割と真面目に知りたいんだけど

2017/07/17(月) 19:25:58.36

>>976
いやコールバック関数のポインタ渡しで代替だからw　別に関数書く必要はあるよ
blocksみたいに、同じスコープにコールバックの処理も書けちゃうっていう便利さは無い

環境のキャプチャもしたければ、値のコピーをヒープに確保してコールバック側でfreeとか、
工夫すればできるでしょう

2017/07/17(月) 19:43:36.29

うーむわかりた。やっぱ別に書いた関数を呼ぶのがせいぜいよなあ
せめて関数オブジェクトがあればなあとたまに思うわ

2017/07/17(月) 19:45:22.30

>>959
> というかPythonの話は止めよう。俺はそっちには興味ない。
はあ？
Python言い出したのはお前だぞ w

>>962
> Pythonの仕様が糞だから、「Pythonでは糞コードしか書けない」と俺は言っている。
だから知らないならPythonに触れるなよ
別にPythonサイコーって思ってる訳じゃないけどお前の指摘は全て的はずれすぎる
関数定義の順序に制限なんてない
あとローカル関数についてはJavascriptも似たようなもんだぞ

2017/07/17(月) 19:47:31.91

>>970
> 関数内関数って要するに高階関数のことだろ
全然違う

> 関数型言語または関数型のマルチパラダイムの言語でないと無理だろ
Pascalでも使えるのに何を知ったかしてるんだよ w

>>971
> 関数内関数は単純に制御構造だと捉えれば、C言語でもgoto文で可能でしょう
これはさすがにアホすぎる...

2017/07/17(月) 19:59:04.53

>>980
ちょっと関数内関数ってどういうものを言ってるか説明して
単純に言えば関数内で行ったり来たりするだけじゃないの？

2017/07/17(月) 20:24:44.55

関数の内部で関数を定義するようなイメージじゃないの？
C言語では不可能だけど
void functionA(void) {
　…
　void functionB(void) {
　　…
　　void functionC(void) {
　　　…
　　}
　｝
}

2017/07/17(月) 20:31:06.71

>>981
スコープが違うだけで普通の関数と同じだぞ
普通の関数をgotoだけで実装してみてよ

2017/07/17(月) 21:01:30.74

>>963
> トランポリンコード
なんだそりゃ？と思ったらこれか。
http://d.hatena.ne.jp/yupo5656/20040602/p1

なるほどGCCのは単なる階層ではなく、プチグローバル付きか。
この仕様なら上位階層（ファイル）を記述変更無しで取り込めるが、
これは確かに標準化には微妙だな。俺はGCCの仕様を詳しく知らんかった。すまんね。
しかしこれ、C++のメンバ関数ポインタみたいに、
普通の関数ポインタと相互運用することは諦めてしまっても良かった気もするが、
それだとレガシーとは相性が悪い。微妙なところだね。

2017/07/17(月) 21:03:30.21

>>983
俺が言ってるのは、Cでは同じようには書けないが同じ処理はできるってことだよ