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/14(金) 00:35:26.21

>>852
いやみりゃ分かるが 851=849で、俺もそれは否定しない。
ただ、確かに851は間違いだったわ。
確保時の文法が異なっていて、それで十分だから、その後は区別する必要はないね。

見た目、直接か間接か分かるようにしろってことだろ。

2017/07/14(金) 05:37:38.18

ポインタなら(*foo).member と書くべきのところ->で書けるようにしたってことだけじゃないの？
糖衣構文的なオプションだろう

つうか、どちらもドット演算子に統一した場合、
ポインタなのにデリファレンスしないで値にアクセスできる仕様はCの文法としておかしくね？

2017/07/14(金) 05:52:17.16

逆にドット演算子の意味を考えてみると、これ変数からのオフセットだろ

2017/07/14(金) 06:19:15.44

デリファレンスしてもしなくても意味が同じという仕様にした場合、
構造体のポインタのポインタだともっとおかしなことになる
やっぱりダメなんだよw

2017/07/14(金) 06:56:35.87

その反論じゃダメージゼロだ

2017/07/14(金) 07:00:49.03

>>843
struct s { int *a; };
void f(struct s *sp){
int b = 1;
sp.a = &b; /* 今の文法なら sp->a = &b; */
x = sp.a;
って書かれたら x には b へのポインタが入るの？
それとも 1 が入るの？
まさか右辺の型に依存して変わるとか？

2017/07/14(金) 07:45:04.78

最初Cのソース見たとき -> って記述がなんのジョークかと思ったわ。

2017/07/14(金) 07:47:03.66

>>857
構造体Fooのポインタをメンバーに持つ構造体Fooのポインタで考えてみ
ドットでアクセスするのはどっちのメンバー？

2017/07/14(金) 07:52:21.63

いや問題はそこじゃないな

2017/07/14(金) 08:05:49.17

>>854が最後にいいこと言った
>>856の指摘が読めてない>>857はIQで30くらい差があるんだろうな

2017/07/14(金) 08:06:19.82

(*pa).m と a->m
(*pa+i) と a[i]

お好きな方をどうぞ

2017/07/14(金) 09:01:40.73

>>854
関数へのポインタは(*func)()とデリファレンスしなければいけないのに
func()と書けるようにしたのでおかしくはない

2017/07/14(金) 10:09:02.17

>>863
ミスってるぞ

>>864
sizeof func != sizeof *func

2017/07/14(金) 10:36:06.28

字下げスタイルについて質問です
現在職業訓練校で習っているのですがそこの先生が
「プロはみんなこっち（K&R）だから。最近の教科書はこういうの（オールマン）増えてるけど、初心者向けの本書いてる人はそもそもプログラマじゃないから……」と。
自分がオールマン好きなのと、本を書いてくれる人たちをばかにするような言い方でちょっとむっとしたのですが、実際にK&Rばかりなんでしょうか

**デフォルトの名無しさん** (JP 0H99-QjT/) · 2017/07/14(金) 10:58:17.61

>>866
自分一人で書くならプロだろうが何だろうが自分の好みを貫けばいい。
チームならそのチームのスタイルに合わせるのがプロ。
多数派は多分K&R。俺の好みもそう。

**デフォルトの名無しさん** (JP 0H99-QjT/) · 2017/07/14(金) 11:03:48.20

>>862
IQ180のお前さんならコード例一瞬で出せそうだからよろしく。

2017/07/14(金) 12:28:17.80

>>865
コンパイラが忖度してデリファレンスしてくれるって事じゃん

2017/07/14(金) 13:06:11.17

>>866
今は他言語含めてK&Rが主流。昔の初心者本にオールマンスタイルで書かれてるのがあって
自分も最初は括弧の対応が分かりやすいからそれを使ってたけど
今は使わなくなった。括弧の対応なんて見れば分かるので重要じゃなくなる

2017/07/14(金) 13:16:54.77

sizeof 関数　って何ぞ？

2017/07/14(金) 14:28:28.54

>>869
void (**f)();
f(); //error

2017/07/14(金) 15:00:47.41

>>864
C FAQ 4.12
http://www.kouno.jp/home/c_faq/c4.html#12

配列名と関数名が特殊なのは、ポインタに成り下がるからなんだそうだ
構造体はどうだろうか？

2017/07/14(金) 15:04:40.25

>>866
その「先生」もプログラマじゃなさそうに聞こえる
どこのチームに入っても「こいつのクセうぜえ」と思われたらあかん
K&Rだのオールマンだのと言うが純粋なK&Rや純粋なオールマンはむしろ少数派で
たいていなにがしか方言があり、それを無視して原理主義に走ると
標準語を使っているはずの自分のほうが訛っていることにされてしまう
保護色ができないやつがプログラマの世間を知っているのか疑わしい
もしくは、元プログラマでも引退してからずいぶん長いとかな

プログラマ以外の世間でも「前の会社では」が口癖の新入りが干されるのと同じで
狭い世界の狭い正義にとらわれたスッパマンに居場所はない

2017/07/14(金) 15:11:15.53

そこのコーディング規約に従うまで

ただ、古典だけあってK&Rスタイルに近くなると話が早くなる

2017/07/14(金) 15:54:44.39

c#はオールマンだし、どっちでもいいな

2017/07/14(金) 18:24:36.67

え？C#はオールマンなの？

2017/07/14(金) 19:07:42.77

コーディングスタイルなんて、GNUスタイルとかいう汚物じゃなければ何でもいいわ

2017/07/14(金) 19:09:37.89

あなたの色に染まります！

2017/07/14(金) 19:46:42.57

>>877
そうらしい

C#
マイクロソフトはC# のコーディング規則を発表しており、これは、BSD/オールマンのスタイルに基づいている。
https://ja.m.wikipedia.org/wiki/%E5%AD%97%E4%B8%8B%E3%81%92%E3%82%B9%E3%82%BF%E3%82%A4%E3%83%AB

2017/07/14(金) 21:40:14.77

汚物は消毒だ～！！

2017/07/15(土) 15:35:51.02

clangにはソースコードを解析してコードを補完する機能がありますけど
gccにはこういう機能はないのでしょうか？

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

>>858
> x には b へのポインタが入るの？
> それとも 1 が入るの？
その仕様にした場合は、 x の型によって決まる。
多分、結局のところは、float->doubleのような暗黙のキャスト、
structPtr* -> *structPtr　を許すかどうかだろう。
許しても大した問題はないように思えるが。

ポインタを使える最近の言語はGoとRustか？
詳しい奴がいれば聞いてみればいいのではないかな。
C言語で問題だった点は当然改修されているだろうし。

2017/07/15(土) 16:57:34.95

>>883
> その仕様にした場合は、 x の型によって決まる
struct s { size_t *a; size_t *b; };
void f(struct s *sp){
size_t c[] = {1, 2};
sp.a = &c[0];
sp.b = &c[1];
x = sp.b - sp.a;
ってされたらどうするおつもり？
デリファレンスしてもしなくても結果は size_t だよ

2017/07/15(土) 17:11:06.39

>>884
だからxの宣言によって決まるだろ。
Cにはvarはないんだよアホ。
お前根本的に型を分かってないだろ。

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)で回していて、子プロセスで入力を受け取るのですが、ある入力が来たときだけ、プログラムを終了(子プロセス親プロセス両方共終了)させたいです