関数呼出しはgoto文である
■ このスレッドは過去ログ倉庫に格納されています
関数fがあったからfを読んでみたらfのなかに関数gがあった。
gを読んでみたら関数hがあった。
これはgoto文だと思った。
しかし、関数に切り出すのは構造化プログラミングだと言われている。
gotoがダメだから構造化プログラミングにパラダイムシフトしたのに
所詮はgotoなのである。 >>45
三つ編み眼鏡っ娘の先生というのが気になってしかたないのですが…
どこかに画像ありますか? >関数fがあったからfを読んでみたらfのなかに関数gがあった。
関数の中に関数を定義できるのか?
少なくともCではないな。 >>106
頭の暖かい連中が gcc に実装してる。 C++だったら余裕
int main(void) {
class Hoge {
void operator () (int n) { /* ほげほげ */}
};
...
}
Cでも配列の中にマシンコード直打ちすればあるいは・・・ このスレッドは110を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。 Pascalも関数内に関数定義できた気が。
そんな狭いスコープの関数で何がうれしいのか俺にはよくわからんが。 使い捨てみたいなその場限りの用途なのに
いちいち関数の名前を考えるのがメンドウやろ 使い捨てなら関数化するなよって気が。
俺にはよくわからんが。 人間がいちいち入力するのでなくて、関数を自動生成して
それを使い捨てするという用途なら有り得るな。 使い捨ての関数なんて、関数型プログラミングをやれば、いくらでも
使うものだということがわかる。 >>119
喩えは悪いけど、関数を無名で作りたいってのはforループに一一名前をつけるのが面倒ってのと同じようなレベル? 同じようなテンポラリ関数をたくさん作る必要があるときに命名が面倒くさいんだよね。
例えば長さを返す関数が複数あったとして
len1() {}
len2() {}
len3() {}
len4() {}
みたいな。 ヘタに名前を付けちゃうとコードの再利用がしにくい。
もっとも、コピペコーディングの温床になる両刃の剣だが 非同期プログラムはgotoと同じくらい読みにくいけど現代では使用を避けられない 名前の無い関数は、いわゆる関数ではなく、1まとまりの手続きでなのであーる。 >>1
その考え方だと関数呼び出しはgoto文かもしれないけど
関数呼び出しが終わった後に自動的にもとの場所まで戻ってくれるでしょ
これってgoto文でまたもとのところに戻ってるってことだよね
関数呼び出し1回書くだけでgoto文を2回自動的に呼び出してくれるということだから
親切だと思う
単なるgoto文とは違う
すげえ遅レスだしスレも読んでないけど >>126
名前のない関数というと局所関数?
ローカル変数のスコープを小さくできるとい面でメリットがあるんじゃないの
forループ中で変数を宣言できるのと同じメリットがあるのでは? 親関数が所持しているデェタ
を参照した子関数を書きたいこ
とがあるでしょう。
例えば、qsortを使って、そえじ配列i
がx[i[1]]<=x[i[2]]<=...となるように整列
したいとき、比較関数をどう書けばよいか
を考えると、内部関数の必要性がわかるはず。
goto文なんてもう古い
これからはcomefrom文を使うべき >>131
> goto文なんてもう古い
> これからはcomefrom文を使うべき
恐ろしく古いネタだな LABEL1:
for ( ; ; ) {
for ( ; ; ) {
for ( ; ; ) {
for ( ; ; ) {
for ( ; ; ) {
何かの処理
if (何かの条件) break LABEL1;
何かの処理
}
}
}
}
} まあ、調教されたgotoと、されてないgotoで良いんじゃ無いかな
>>1
お前が言っているのは、包丁も人を殺せるから作っちゃいかんと同程度。
goto以外の制御構文は、入り口と出口が決まっている。例えば、returnは、
必ず関数の呼び出し元に戻る。continueはループブロックの末尾に落ちる。
gotoはネストを完全に無視して出入り口の概念が無いジャンプを書けてしまう。
goto label1:
label2:
goto label3
label1:
goto: label2
label3:
こんなどっから入ってどこに出るか解らんコードが
散らばってたら読んでられるかっ。
>>126
pointLambda = Line(0,0,10,10);
point[0] = pointLambda(0);
point[1] = pointLambda(1);
point[2] = pointLambda(2);
point[3] = pointLambda(3);
はたしてこれがただの手続きと言えるか? >>136 は継続について勉強するといいと思うよ
ついてけないならプログラマに向いてないだけだから >>137
で、君は継続をバリバリ使ってるプログラムを日常的に書いてるのかな? >>137
別に継続だろうが、gotoだろうが、出口がはっきりしてりゃいいんだよ解る?
お前は継続で>>136のようなコードを意図的に書くのかよ。deleteしたポインタを
コンパイルエラーにならないからってさらにdeleteするぐらいアホだな。 そもそも、ダイクストラの言った構造化の要点は、gotoを禁止しろじゃないからな。
入り口と出口をはっきりしろってのが要点。誰もがgotoを使って入り口と出口がはっきり
したコードを書くのなら別に、breakやreturnじゃなくgotoでもいい。
熟練したプログラマが書いたアセンブリコードだって構造化されてる。
問題とされるのは、入り口と出口がはっきりせず、あるルーチンの中に飛び込んで、
また別のルーチンにとんでいって返ってこない>>136のようなコード。 良く言われるスパゲティコードというやつだな
プログラムを格納する領域にすら困る時代にはそういうのも実用になることがあったが
今はコードを削るほどメモリに困ることはあまり無いからね
…って、組み込み機器の分野ではどうなんだろう?
今もスパゲティが散見されたりするんだろうか
それともむしろ、止まったら困るから昔から意外ときちんと書いてた? 普通にオブジェクト指向プログラミングしてるだけなのに、
「クラス使うな。スパゲッティコードになるだろ!」
っていうレベル低いプログラマに囲まれて欝。
自分が抽象化されたコードを読み解けないのを、「スパゲッティコード」だと
こちらに押し付けてきやがる。
ラムダとか継続以前に継承も多態もわかんねえ奴らはほんと消えて欲しい。
スパゲティかどうかは別として、メソッドの呼び出し地点を探しづれぇってのはある。
メソッドの引数追加するはめになったときは特に悲惨。 実際に走らせて試すことができるコードなら例外使ってスタックトレース取得とか
やったことありますねJavaで 継承は個人個人が書くコードレベルで書くとスパゲティだと思うけどね
ライブラリの継承や、全体設計者の何らかの法則にしたがって継承していくのはあり
Aクラスでも使う、Bクラスでも使う、関数を、
「自分でかいたCクラス」に定義して、AとBに継承とかはスパゲティだと思ってる 読む気を無くす そういう場合、殆どの場面において、AとBクラスは ちゃんとリファクタリングすれば統一できるか、あるいはCがライブラリになるか、設計そのものに組み込まれて
自分でかいたクラスを自分でかいたクラスに継承する。なんていう例外的な継承は必要なくなるはず 継承を>>146みたいに使うのは根本的に誤解しているが、>>147程度の理解で
「スパゲッティだと思ってる(キリッ」
ってヤツが多いから欝なんだよ…
しょせん、他人が書いた「俺ライブラリ・俺クラス」はすべてスパゲッティ。
書いた本人が自分にわかりやすいように書いただけであり
他人には理解不能。 >>146
親クラスの増築版として子クラス書くなよバカ。
増築するくらいなら、親に当たるクラスのオブジェクトを内包させて、
Getter,Setterで操作できるようにした方が実装が固定されなくて遥かにまし。
親クラスを利用(参照)しているクラスを子で利用するために書くんだろうが。 これ ; デリミタっていうんだけどさ、これをつけなきゃエラーになるような
そんな言語使ってる奴ってどうみてもゴミだと思うんだけど
もしかして「;」これ打ち忘れてコンパイルエラー出すのが楽しいの?
そうか、二度と話かけんなよ
ほんっとに自覚のないゴミだな 10 *MAIN
20 GOSUB *F
30 END
40 RETURN
100 *F
110 GOSUB *G
120 GOTO *R
200 *G
210 GOSUB *H
220 GOTO *R
300 *H
310 GOTO *R アセンブラとbasicしか使ってなかったころ、よくやってた事
# 関数定義部分
func_wrapper:
c = a + b #引数として指定されたa と b を足してcを構築
func:
# ここから関数の本体
# c を利用して複雑な演算を行う
c = ....
return
#関数利用部分その1
a = 1
b = 2
gosub func_wrapper
#関数利用部分その2
c = 10
gosub func
何を言いたいかと言うと、サブルーチンの入り口がfunc と func_wrapperの2つあり、
引数の加工前、加工後のどちらでも共通して同じ関数が利用できるという事。
上記の例の場合、aとbを初期化してfunc_wrapperを呼ぶことができるが、計算過程で
必要なcがすでに完成しているなら、funcを呼んでも良い。という事になる。
これで、出口どころか入口さえ決まっていない関数(サブルーチン)が出来上がるわけだ。
当時は便利だと思ってたんだけどね。
えっと、そいうのはC++とかでも普通だったりしますが・・・
放射能にやられた? 最初にそれを言い出したのはwhileもまともなifも無かったFORTRANが主力だった時代。
それを勘違いして教条的に扱った奴がアホ Cだが、最近はgotoも使い方次第って風潮だな
多重ループ抜けに余分な変数作らなくていいし、便利 近頃の若いもんはgotoの正しい使い方も知らんのか
いったい学校では何を教えてるんだか gotoって内部的にはどうやってんの?
コンパイルしたら行番号もなにもなくない?
小4の頃にWindowsのバッチで使った時あるだけだが >>168
basicのgotoもラベルにジャンプできる。
Cのgotoはラベルにジャンプする。
それはさて、それらのgotoに限らずforやwhileも
コンパイルされた実行オブジェクト内ではCPUの分岐命令になっている。
そのジャンプ先は大抵、前後に何バイト離れたところと言う風に指定される。 No such file or directory 我輩はgoto文である
名前はまだない
いやgotoだった名前ワリィ かんすいおよびダシは五等分である。
(これをラーメン構文という) goto有害論のマトモな説明が流通しないのはなぜなんだろう >>179
ラーメンを4等分するドリフのコントを思い出した。 関数呼び出しはgotoであるって粒度が違うよね
人間は原子であるというくらいおかしい > goto有害論のマトモな説明
Knuthの"Structured Programming with go to Statements"がベストだと思うが、
あれ読んで理解できる奴はそもそも読まなくても分かってる、っていうw 構造化を学ばなくてもわかってるやつってみたことない
構造化を取り込んだ言語とgoto使うなという標語からそれっぽく書いてるだけで 箸は手で使っているので所詮は手であると言うようなもの。
この手のアホは結構多い。
一番多いのはツールは所詮人間が使っているのでツールのパワーは重要ではなく所詮は人力であるという奴。 >>187
言語の力をツールに含めないアホなら見たことある。
言語で差は無いとか言うアホ。 >>188
使える技術はなんでも使ったほうがいいよな。
なぜか標準関数だけで作ろうとするあのバカ。
ライブラリ使えよ。 信頼出来るかどうかの見極めがまず第一
車輪の再発明とか言ってよく批判されるが
水平方向じゃなくて垂直方向すなわち
ハシゴを登る時は自作したほうが良い AとBの値を入れ替える、このようなしょうもない手続きを一々関数に切り出してるからダメなんだよ
ブロック化は1つの手続きを別けるのではなく、完結したオブジェクトであるべきだろ 自分の命を預けるものを再発明してなにがわるい
おまいらはOpenSSLでも使ってろ >>1はgotoがなぜ悪いのかを理解してないんだろうな >>196
お前の発明力と、それを支える技術力が確かなものであるなら、別にそれでもいいよ?
車輪にしたってあれ、かなり正確な円を作れないと、使う時にいろいろ余計な不具合が出るもんだけど。
荷重計算も当然やってなきゃいけない。
場合によってはタイヤやサスペンションやブレーキなどのアクセサリも必要になるかも知れない。
少なくともWikipediaの車輪のページに書かれてる程度の事は自力で思い付けるくらいじゃないと、再発明なんて危なっかしくてさせられないんだけど。
再発明して何が悪いと主張する人たちに、これができる人はほとんど居ないんだよねえ。
梯子もまた然りで、構造はすごく単純そうにだし、実際そうだけど、あれ自力で考えて作るのすごく大変だよ?
ただのオンボロに見える杉材製農業用梯子に、危険を回避するためにどれだけの対策が必要か、現に施されているか、分析できてる? 車輪の再発明って火縄銃を分解して国産で作りあげてしまう日本人にしてみれば
実はピンと来ない言葉なんだよな。
分解作りなおすとか当然だろみたいな所あるじゃん。
「少なくともWikipediaの車輪のページに書かれてる程度の事は自力で思い付ける」
のはまさに再発見でありこれは100%意味が無いね
発想しなくても分解して学べばいいわけよ > 火縄銃を分解して国産で作りあげてしまう
そんなことを知っている日本人はごくわずか。
勝手にピンと来ないことにするなよ。
馬鹿じゃねーの? >>201
火縄銃の伝来は日本史上かなり有名な話だと思うが… ■ このスレッドは過去ログ倉庫に格納されています