いつまでバグを買わされるのか（ネ スト９段のプログラムを改造する時）
tabe
ＧＷも終わってしまって、
明日からまた、厳しい仕事です。
今回の質問は、
「ネスト９段のプログラムを改造する」はめになって、
改造でＩＦ文を追加する必要が出た時（つまりネスト１０段になる時）、
皆さんはどうされますか？
案１）
ＩＦ文の条件式を逆にして異常処理後、即RETURNにするとか、
別関数作るとかして、
ネストを浅くする
案２）
どうしょうも無いので、ネスト１０段にする。
案３）
別の仕事を作って、逃げる。
質問の背景：
いやー、大した理由は無いのですが、
fj.comp.lang.c と
fj.jokes ばかり読んでいたら、
fj.comp.misc が、凄い事になっているので
＃Outlook Expressでスクロールバーを
＃思いっきり右に引っ張らないと読めないくらい
＃凄い事になってるので、ネスト１０段を連想したまで。
＃質問に対する、万能な答えが無い事は承知。
＃ネスト１０段のプログラムは改造可能か？の実験的投稿です。
以下、雑感
（１） fj.comp.misc での、太田さんと、加藤さんの議論には、
決着は付かないだろうな。
加藤さん）宇宙の裏の裏まで見てやろうと努力を続けるのが技術者の心
意気
太田さん）宇宙の裏の裏は、見れるわけないので出来る範囲を明記する
のが技術者である
＃、と解釈したのは私であって、お二人はこんな事はどこにも書いてませ
ん。
＃裏の裏は表だろうの突っ込みは無しね。
＃裏は佐藤さんで、その裏は田中さん、その裏は鈴木さん、どこまでも続く
新興住宅地
（２） fj.comp.misc での、スレッドの推移は、
ダイヤモンド社
★★「いつまでバグを買わされるのか」★★
マーク・ミナシ著
植木不等式監訳
の、目次に酷似しているので、興味深いです。
興味のある人は一読あれ。
以下、しらいさんの私に対する幾つかの議題の回答
＃他の人が読んでもあまり面白くありません。
第０：
「共感が欲しくて投稿したのに思いのほか理解を示してもらえない。。。」
共感が欲しくて投稿て投稿したのではなく、
しらいさんが、すでに気づいている様に製品紹介のために、
投稿しています。
ガマの油売りでも、それなりにギャラリーは集まっていると思いますが、
もし、しらいさんがアカデミックな議題を欲しているのであれば、
そのようなスレッドをしらいさんが、立てれば良いだけと思います。
第１：
「前提や背景を全く示さずに。。。」
K&R2の１章を知っている人なら理解できる事を議題にしているつもりです。
でも、ま、ニュースグループをの読者は、多様なので、
２割位の人には私のスレッドの意味は通じないと思ってます。
その、２割の人から質問があれば、２～３回、回答しますが、
話が通じないと思ったら、
後は無視します。
＃それとも、しらいさんは古今東西の万人に理解可能な表現方法をご存知なので
すか？
第２：
「「べき」と言い切れるような定石など存在しない。。。」
カーニハン博士は「プログラム書法」の中で、
慣用表現を使用しなさいと述べています
慣用表現ってのは、定石なのではないでしょうか？
第３：
「殆ど無視して聞く気がない。。。」
const の使用方法の時、白旗を揚げた投稿をしてます。
＃あと、繰り返しですが、話が通じないと思ったら、無視します。
第４：
「自信過剰。。。」
これは、チャックを明けたままにしている
しらいさんに、
「鏡」とそれとなく教えてあげたのに、
全然気づかない様ですね。
第５：
「間違いをゼロにする努力を重ねるよりは、。。。。recover出来るシステムデ
ザインを。。」
ずいぶん、プログラマを馬鹿にした発言ですね。
もし、
failsafe とか、 foolproofといった
SE的発想だけで堅牢なシステムを構築できると
お考えならば、
しらいさんが、
FDクローンの開発の中で使用している
lint（＝C言語チェックツール＝プログラムの些細な毛羽立ちを指摘するツー
ル）
など、使わなければ良いのに。
--
以上
見て、勝手使って http://rec.ncos.co.jp
red brick
tabeさんの<ab664l$qs4$1...@bgsv5905.tk.mesh.ad.jp>から
>第５：
> 「間違いをゼロにする努力を重ねるよりは、。。。。recover出来るシステムデ
>ザインを。。」
>
> ずいぶん、プログラマを馬鹿にした発言ですね。
> もし、
> failsafe とか、 foolproofといった
> SE的発想だけで堅牢なシステムを構築できると
> お考えならば、
> しらいさんが、
> FDクローンの開発の中で使用している
> lint（＝C言語チェックツール＝プログラムの些細な毛羽立ちを指摘するツー
>ル）
> など、使わなければ良いのに。
こうやって堅牢なプログラマが構築されるわけですね。
--
赤煉瓦
Takashi SHIRAI
Newsgroups: はこのままにしますが、続くようなら適宜移動して
下さい。
In article <ab664l$qs4$1...@bgsv5905.tk.mesh.ad.jp>,
tabe <ta...@mug.biglobe.ne.jp> wrote:
>田部です。
>今回の質問は、
この質問がついでなのでしたら、本題とは別記事にした方が良か
ったかと思います。
> 共感が欲しくて投稿て投稿したのではなく、
> しらいさんが、すでに気づいている様に製品紹介のために、
> 投稿しています。
投稿目的が商用利用であったことをようやく明らかにしましたね。
fj の AUP では商用利用の投稿を禁じていますので、以降、この目
的のための投稿は絶対にしないで下さい。
BIGLOBE をお使いのようですので、provider 側で用意している
ガイドラインを挙げておきます。
http://support.biglobe.ne.jp/help/nn-guide.html
＃ 他の部分に関しては特に言うことはありません。私はここの読
＃者が馬鹿ばっかりだとは思っていませんので、何が正しいかは各
＃自で判断すればいいでしょう。
--
しらい たかし
Yoshiki Kataoka
news:ab664l$qs4$1...@bgsv5905.tk.mesh.ad.jp...
> 田部です。
> ＧＷも終わってしまって、
> 明日からまた、厳しい仕事です。
>
> 今回の質問は、
> 「ネスト９段のプログラムを改造する」はめになって、
> 改造でＩＦ文を追加する必要が出た時（つまりネスト１０段になる時）、
> 皆さんはどうされますか？
「普通に」追加します。
関数化すべきところを関数化します。
適宜、longjmp します。
内心で、教条主義的なgoto嫌悪を嘲笑します
以上
KANDA Toshihiro
news:ab664l$qs4$1...@bgsv5905.tk.mesh.ad.jp...
> 「ネスト９段のプログラムを改造する」はめになって、
> 改造でＩＦ文を追加する必要が出た時（つまりネスト１０段になる時）、
んー、
「ネスト」だったら「9 重」だろうし
「IF 文(て何?)」だったら、「インデント 10 段」だろうし
と、相も変わらず何かが満載ですが、
この田部氏ってもしかしてなまお??
# それとも針箱か?
神田敏広 <ca...@kgc.co.jp>
Takashi Yamamura
On Mon, 6 May 2002 23:59:00 +0900, in
<ab664l$qs4$1...@bgsv5905.tk.mesh.ad.jp>,
"tabe" <ta...@mug.biglobe.ne.jp> wrote:
> 「ネスト９段のプログラムを改造する」はめになって、
> 改造でＩＦ文を追加する必要が出た時（つまりネスト１０段になる時）、
> 皆さんはどうされますか？
「ネスト９段」ってループが9段になっているって意味?それともif-elseの
ネストがやたら深いという意味?
それはともかく、4番目の案として、「アルゴリズムから書き直す」という
方法もあります。
以前、私が遭遇した事例ですが、仕事で引き継いだコードの中に、if-elseの
ネストが深くてすぐにはちょっと理解できない関数がありました。根気よく
調べると、たまたまテーブル参照のアルゴリズムが使えるパターンだったので、
それを使って書き直したら、テーブル部分を含めて、(記憶では)1/3以下に
なったことがありました。で、実行コード本体はほんの数行。(笑)これ
だったらちょっとCをかじっていれば何をやっているのか一目瞭然ですよね。
# こんな 自明な例が「アルゴリズムの変更」に値するかは別として。
もちろん、case by case ではあります。
---------
山村 隆志 「debugは３歩後退、２歩前進、いつまでたっても終らない」
e-mail : vy...@janis.or.jp
WWW page : http://www.janis.or.jp/users/vyama/
tabe
"KANDA Toshihiro" <ca...@kgc.co.jp> wrote in message
news:s7fn0vc...@xxx.kgc.co.jp...
> "tabe" <ta...@mug.biglobe.ne.jp> wrote in message
> news:ab664l$qs4$1...@bgsv5905.tk.mesh.ad.jp...
>
> > 「ネスト９段のプログラムを改造する」はめになって、
> > 改造でＩＦ文を追加する必要が出た時（つまりネスト１０段になる時）、
>
> んー、
> 「ネスト」だったら「9 重」だろうし
> 「IF 文(て何?)」だったら、
（て何？）って何？
if文って小文字で書けって事？
> 「インデント 10 段」だろうし
駄目？
「ネストも９段あり」という表現が
http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.12.3.html
ここでも、されているので、一般的表現だと思いますが。
> と、相も変わらず何かが満載ですが、
> この田部氏ってもしかしてなまお??
> # それとも針箱か?
＃似てるね確かに。
―――――――――――――――――――
tabe
田部です。
"Yoshiki Kataoka" <kat...@ka2.so-net.ne.jp> wrote in message
news:ab8kun$m93$1...@news01bc.so-net.ne.jp...
> > 今回の質問は、
> > 「ネスト９段のプログラムを改造する」はめになって、
> 内心で、教条主義的なgoto嫌悪を嘲笑します
> 以上
変なフラグ変数いっぱい作って、
何がなんでも、
goto 絶対使わない人って、いますよね。
D.Miyasaka
> 改造でＩＦ文を追加する必要が出た時（つまりネスト１０段になる時）、
> 皆さんはどうされますか？
>
>案１）
> ＩＦ文の条件式を逆にして異常処理後、即RETURNにするとか、
> 別関数作るとかして、
> ネストを浅くする
>案２）
> どうしょうも無いので、ネスト１０段にする。
>案３）
> 別の仕事を作って、逃げる。
案４）
自分で新規に作り直す
ってのはダメですか？
以前に、すさまじくネストやループが入れこんだプログラムを見て
これを理解するには何ヶ月もかかりそうだが、作り直すなら１週間程度で
十分だと判断して、そうしたことがあるのですが。
>共感が欲しくて投稿したのに思いのほか理解を示してもらえない
醒めていると言われそうですが、NetNewsって「お友だちを作る場」じゃない
と私は思っています。そういうのを望むならリアル社会にいくらでもあります
ので、わざわざネットで求めなくても、って思うのですが。
--
D.Miyasaka <mailto:miya...@anet.ne.jp>
Shinji Ise
> 自分で新規に作り直す
>
> ってのはダメですか？
>
> 以前に、すさまじくネストやループが入れこんだプログラムを見て
> これを理解するには何ヶ月もかかりそうだが、作り直すなら１週間程度で
> 十分だと判断して、そうしたことがあるのですが。
新規に作れるというのは、かなり恵まれた環境ですよね。少なくとも、プロ
グラムのもともとの仕様がきちんとあるという意味で。
--
伊勢 shinj...@nifty.ne.jp
HT
>> 案４）
>> 自分で新規に作り直す
>
> 新規に作れるというのは、かなり恵まれた環境ですよね。少なくとも、プロ
>グラムのもともとの仕様がきちんとあるという意味で。
仕様が無いから作り直すというのもありかと。
（あ、そういうのは新規というのかな）
Shinobu Kumaoka
tabe wrote:
> 第１：
> 「前提や背景を全く示さずに。。。」
>
> K&R2の１章を知っている人なら理解できる事を議題にしているつもりです。
「前提や背景を全く示さずに。。。」ってのはそういうことじゃないと思うのですが、
結局、全然解ってなかったんですね。
--
cog...@sp.hudson.co.jp
株式会社ハドソン
コア・テクノロジー事業本部
システム部 ソフトウェア課
熊岡 忍(Kumaoka Shinobu)
tabe
田部です。
"D.Miyasaka" <miya...@anet.ne.jp> wrote in message
news:3CD8F0EF...@anet.ne.jp...
> 案４）
> 自分で新規に作り直す
> ってのはダメですか？
あり。
> 以前に、すさまじくネストやループが入れこんだプログラムを見て
> これを理解するには何ヶ月もかかりそうだが、作り直すなら１週間程度で
> 十分だと判断して、そうしたことがあるのですが。
私もやりました。
struct tag {
int mem1 ;
int mem2 ;
........
int mem1000 :
} R ;
R.mem1 = 0 ;
R.mem2 = 0 :
.....
R.mem1000 = 0 ;
の１０００行を、
memset(&R,0,sizeof(R)) ;
の１行にしちゃった。
＃ちょっと誇張。
＃カーニハン博士が、
＃処理速度が遅いのも、
＃汚いコードも、
＃書き直してしまえ！！みたいな事を文献の中でいってた。
＃プログラム作法か書法のどっちか。
１０段ネストは早めに、
修正しないと手が着けられなくなるね。
バオバブの木（星の王子様）みたいに。
tabe
Takashi Yamamura <vy...@janis.or.jp> wrote in message news:<ab99h4$1rs$1...@cobalt01.janis.or.jp>...
> 「ネスト９段」ってループが9段になっているって意味?それともif-elseの
> ネストがやたら深いという意味?
なんでもありです。
>
> それはともかく、4番目の案として、「アルゴリズムから書き直す」という
> 方法もあります。
賛成。
＃でも、若さと、実力と、十分なテストパッケージが必要。
>
> 以前、私が遭遇した事例ですが、仕事で引き継いだコードの中に、if-elseの
> ネストが深くてすぐにはちょっと理解できない関数がありました。根気よく
> 調べると、たまたまテーブル参照のアルゴリズムが使えるパターンだったので、
> それを使って書き直したら、テーブル部分を含めて、(記憶では)1/3以下に
> なったことがありました。で、実行コード本体はほんの数行。(笑)これ
> だったらちょっとCをかじっていれば何をやっているのか一目瞭然ですよね。
if文の条件を逆にして、
異常入力は即return するとネストが浅くなる場合が多いのですが
やっぱり、アルゴリズムの見直しが王道かな。
> # こんな 自明な例が「アルゴリズムの変更」に値するかは別として。
> もちろん、case by case ではあります。
ネスト９段は１０００行にもなる関数の場合が多いので、
明日の朝８時まで修正って時には、
やっぱり、ネスト１０段にしちゃうかな。。。。
＃自信なし。
Takashi SAKAMOTO
> R.mem1 = 0 ;
> R.mem2 = 0 :
> .....
> R.mem1000 = 0 ;
> の１０００行を、
> memset(&R,0,sizeof(R)) ;
> の１行にしちゃった。
素朴な疑問なんですけど、何で配列じゃないんですか？
いや、きっと memXX という単純なものではなかったんでしょうけど。
> ＃カーニハン博士が、
> ＃処理速度が遅いのも、
> ＃汚いコードも、
> ＃書き直してしまえ！！みたいな事を文献の中でいってた。
> ＃プログラム作法か書法のどっちか。
で、本題はこっちです。一体どこのページからの引用なのでしょうか？
プログラミング作法 P.227 の第7章 性能には「最適化の第1の原則は最
適化するな」だと書かれています。無条件に「書き直してしまえ!」とか書
かれていないと思うのですが。最適化を行うのは「問題が重要な場合と、
プログラムが純粋に遅すぎる場合と、正しさと堅牢性と明瞭性を維持しな
がら高速化を図れる見込みがある場合に限られる」と限定されています。
また Writing Solid Code の P.198 には「もしクリーンアップ
することがその製品の成功に重大にかかわらないなら、コードをクリーン
アップしてはならない」とあります。「汚いコードだから書き直してしま
え!!」という結論にすぐにはいたらない筈なんですが…。
# 再利用を考えると、アンチパターンのどれかにはまりそうなので
# 「再設計、再構想」になるんでしょうけど。上記のはそういう話です
# か？
--
---
Takashi SAKAMOTO (PXG0...@nifty.ne.jp)
Masamichi Takatsu
私なら、
> 案１）
> ＩＦ文の条件式を逆にして異常処理後、即RETURNにするとか、
> 別関数作るとかして、
> ネストを浅くする
これでしょうか。問題は、「異常処理」が多くなると、即RETURNというのが
結構見にくくなることでしょうか。
もうちょっと具体的な例ですが、
> 準備1;
> if (準備1が成功) {
> 準備2;
> if (準備2が成功) {
> 準備3;
> if (準備3が成功) {
> やらなあかん処理群
> }
> 準備3の後始末;
> }
> 準備2の後始末;
> }
> 準備1の後始末;
こんな感じの処理が必要になることがよくあります。複数回 malloc するとか、
複数のファイルを fopen するとかが多いでしょうか。
私は以前は、
> 準備1;
> if (準備1が失敗) {return;}
> 準備2;
> if (準備2が失敗) {準備1の後始末; return;}
> 準備3;
> if (準備3が失敗) {準備2の後始末; 準備1の後始末; return;}
> やらなあかん処理群;
> 準備3の後始末;
> 準備2の後始末;
> 準備1の後始末;
と書き換えてました。
この方法は後始末が複数ヶ所に分かれるのがいやなので、最近は
> 準備1;
> if (準備1が失敗) goto end;
> 準備2;
> if (準備2が失敗) goto end;
> 準備3;
> if (準備3が失敗) goto end;
> やらなあかん処理群;
> end:
> if (準備3が成功) 準備3の後始末;
> if (準備2が成功) 準備2の後始末;
> if (準備1が成功) 準備1の後始末;
とやってます。後始末のところで if がありますけど、malloc の場合は、ポインタを
NULL で初期化しておき、問答無用で free します。
こういう goto を使うことを許せない人には、「じゃあ break も使わないでね」
とか言いたくなりますね。break も return も continue も goto の一種なんだし。
PROJECT TEAM ＤｏＧＡ 高津正道 ta...@doga.jp
TBD0...@nifty.ne.jp
PROJECT TEAM DoGAのホームページ → http://doga.jp/
5月10日(金) 今日のマーフィーの法則 [オッペンハイマーの法則]
経験に即席は絶対にない。
NIDE Naoyuki
ta...@doga.jp writes:
> こういう goto を使うことを許せない人
には、
do {
準備1;
if (準備1が失敗) break;
準備2;
if (準備2が失敗) break;
準備3;
if (準備3が失敗) break;
やらなあかん処理群;
} while(0);
if (準備3が成功) 準備3の後始末;
if (準備2が成功) 準備2の後始末;
if (準備1が成功) 準備1の後始末;
…とか書き換えるとうなずいてもらえたりして…
ni...@ics.nara-wu.ac.jp
Sugihara Yoshimi
> > if (準備1が失敗) goto end;
> > 準備2;
> > if (準備2が失敗) goto end;
> > 準備3;
> > if (準備3が失敗) goto end;
> > やらなあかん処理群;
> > end:
> > if (準備3が成功) 準備3の後始末;
> > if (準備2が成功) 準備2の後始末;
> > if (準備1が成功) 準備1の後始末;
>
> とやってます。後始末のところで if がありますけど、malloc の場合は、ポイン
タを
> NULL で初期化しておき、問答無用で free します。
> こういう goto を使うことを許せない人には、「じゃあ break も使わないでね」
> とか言いたくなりますね。break も return も continue も goto の一種なんだ
し。
たぶん以下と同じコードのことだと思うんですが
BOOL b1=TRUE
BOOL b2=TRUE
BOOL b3=TRUE
if(b1 && b2 && b3){
準備1；
if (準備1が失敗) b1=FALSE;
}
if(b1 && b2 && b3){
準備2；
if (準備2が失敗) b2=FALSE;
}
if(b1 && b2 && b3){
準備3；
if (準備3が失敗) b3=FALSE;
}
if(b1) 準備3の後始末;
if(b2) 準備3の後始末;
if(b3) 準備3の後始末;
gotoつかわなくてもOKだと思います
red brick
>こういう goto を使うことを許せない人には、「じゃあ break も使わないでね」
>とか言いたくなりますね。break も return も continue も goto の一種なんだし。
switch も。
--
赤煉瓦
Sugihara Yoshimi
同じにするなら以下のコードですね
BOOL b1=FALSE
BOOL b2=FALSE
BOOL b3=FALSE
b1=TRUE;
準備1；
if (準備1が失敗) b1=FALSE;
if(b1){
b2=TRUE;
準備2；
if (準備2が失敗) b2=FALSE;
}
if(b1 && b2){
b3=TRUE;
Sugihara Yoshimi
"red brick" <f...@qc4.so-net.ne.jp> wrote in message
news:eOJC8.40$Zi1....@newsall.dti.ne.jp...
なぜにswitch ？
＃そのうち「if もね」とかいわれそうだな
Suzuki Chikashi
# joke...かな?
From article <abftrg$9s4$1...@news.kyosai.or.jp>
by "Sugihara Yoshimi" <sugi...@kyosai.or.jp>
そりゃたしかにプログラムの流れはそこで変りますが、gotoの場合、行き先の
ラベルを探さなければならないのです。
意味のある名前を使っているのならいいのですが。
L100:
L200:
L300:
なんてラベルでさらに番号が順番に並んでいない場合だと読む気がしなくなり
ます。
# 最近はこう書く人はそんなにいないかな...
# f2cの吐き出したcのソースを見ると時々悲しくなります(^^;)
「gotoを絶対に使うな」ではなく、使い方ですね。
--
鈴木 爾 (Suzuki Chikashi)
suz...@ma.kcom.ne.jp
red brick
>> switch も。
>
>なぜにswitch ？
条件付き goto 文ですよね。＜ switch
>＃そのうち「if もね」とかいわれそうだな
そんなこと言いませんのでご安心下さい。
--
赤煉瓦
Kazuo Fox Dohzono
suz...@ma.kcom.ne.jp (Suzuki Chikashi) writes:
> # f2cの吐き出したcのソースを見ると時々悲しくなります(^^;)
配列へのアクセスが undefined behavior な方法だから?
# とかボケようとして f2c.h を見て笑ってしまった.
#
# /** barf [ba:rf] 2. "He suggested using FORTRAN, and everybody barfed."
#
# - From The Shogakukan DICTIONARY OF NEW ENGLISH (Second edition) */
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp
tabe
田部です。
引用が雑でしたので、
ちょっと正確にします。
タネ本は、下記の２冊です。
プログラム書法：1976年初版
カーニハン＆Plauge 著 共立出版
＃古い本ですが、結構今でも通じます。
プログラム作法：2000年初版
カーニハン＆Rob Pike著 ASCII
"Takashi SAKAMOTO" <PXG0...@nifty.ne.jp> wrote in message
news:uit5xs...@nifty.ne.jp...
> "tabe" <ta...@mug.biglobe.ne.jp> writes:
> > R.mem1 = 0 ;
> > R.mem2 = 0 :
> > .....
> > R.mem1000 = 0 ;
> > の１０００行を、
> > memset(&R,0,sizeof(R)) ;
> > の１行にしちゃった。
>
> 素朴な疑問なんですけど、何で配列じゃないんですか？
> いや、きっと memXX という単純なものではなかったんでしょうけど。
そうです。ビットフィールドとか、配列とか有りの構造体。
プログラム書法
P14「ライブラリ関数を使おう」より。
> > ＃カーニハン博士が、
> > ＃処理速度が遅いのも、
> > ＃汚いコードも、
> > ＃書き直してしまえ！！みたいな事を文献の中でいってた。
> > ＃プログラム作法か書法のどっちか。
>
> で、本題はこっちです。一体どこのページからの引用なのでしょうか？
汚いコードについて、
プログラム書法：P102
「だめなプログラムを修正するのはやめて、全部書きなおそう」
プログラム作法：ｐ４６
「悪いコードにコメントをつけるな、書き直せ」
遅いコードについて
プログラム書法：P192
「速くしようとしてプログラムをひねくりまわすのはやめて
もっとよいアルゴリズムをみつけよう」
> プログラミング作法 P.227 の第7章 性能には「最適化の第1の原則は最
> 適化するな」だと書かれています。無条件に「書き直してしまえ!」とか書
> かれていないと思うのですが。最適化を行うのは「問題が重要な場合と、
> プログラムが純粋に遅すぎる場合と、正しさと堅牢性と明瞭性を維持しな
> がら高速化を図れる見込みがある場合に限られる」と限定されています。
そうですね、性能に関して、
無条件に「書き直してしまえ!」とは書かれていません。
僕の上げた例は、
性能面ではなくて、スタイルの例のつもりなので
プログラム作法：ｐ50
「第１章 スタイル／１．７ なぜ手間をかけるのか」
あたりの参照が適切でしょうか。
> また Writing Solid Code の P.198 には「もしクリーンアップ
> することがその製品の成功に重大にかかわらないなら、
> コードをクリーンアップしてはならない」とあります。
この本は、WEBで探すと
マイクロソフト社の開発手法を紹介した本の様ですね。
なるほど。。。。。
今日あたり、本屋にいってみます。
>「汚いコードだから書き直してしまえ!!」という結論に
>すぐにはいたらない筈なんですが…。
・動いている物をいじっちゃいかーん。
・動いている物を、時々虫干しして、もっと良く動かす
等、色々考えられますね。
>
> # 再利用を考えると、アンチパターンのどれかにはまりそうなので
> # 「再設計、再構想」になるんでしょうけど。上記のはそういう話です
> # か？
いやー、難しい話は苦手なので、
ネスト１０段大変だから、どうしましょう程度の話です。
T. Sugita
"NIDE Naoyuki" <ni...@ics.nara-wu.ac.jp> wrote ...
> do {
> 準備1;
> if (準備1が失敗) break;
～
> } while(0);
～
> …とか書き換えるとうなずいてもらえたりして…
去年、goto はだめとされた時に上記のようにしたら、
do {} while(0); もやっぱり気持ち悪いと言われて
しまいました。
# そのまま通してもらいましたけど。
tabe
田部です。
下記のコード、私なら却下します。
理由１：
私は鳥頭なので、３行前のコードを忘れる。
＃前の準備が成功したか、失敗したか覚えておきたくない。
理由２：
ｉｆ(準備1成功 && 準備2成功 && 準備3成功 && ......... 準備100成
功) {
私は猿頭なので、複雑なｉｆ文を理解できない。
}
理由３：
私はフラグが嫌いだ。
理由４：
私は変数が多いのが嫌いだ。
理由５：
私は処理速度が遅いのが嫌いだ。
goto 続き ；
"Sugihara Yoshimi" <sugi...@kyosai.or.jp> wrote in message
news:abfp32$9fq$1...@news.kyosai.or.jp...
> むぐ・・・ちょっと違うか・・
> 同じにするなら以下のコードですね
>
> BOOL b1=FALSE
> BOOL b2=FALSE
> BOOL b3=FALSE
>
> b1=TRUE;
> 準備1；
> if (準備1が失敗) b1=FALSE;
>
> if(b1){
> b2=TRUE;
> 準備2；
> if (準備2が失敗) b2=FALSE;
> }
> if(b1 && b2){
> b3=TRUE;
> 準備3；
> if (準備3が失敗) b3=FALSE;
> }
>
続き：
理由６：
私はＢＵＧが嫌いだ。
＃準備２、準備１の後始末は？？？？
> if(b1) 準備3の後始末;
> if(b2) 準備3の後始末;
> if(b3) 準備3の後始末;
--
Sugihara Yoshimi
> 下記のコード、私なら却下します。
> 理由１：
> 私は鳥頭なので、３行前のコードを忘れる。
> ＃前の準備が成功したか、失敗したか覚えておきたくない。
最後にある「準備ｎの後始末」をするには準備ｎが成功したかどうか
覚えてないとダメだと思うのですが？
準備が成功または失敗したかにかかわらず準備の後始末ができるのならば
また違ったコードになります
> 理由２：
> ｉｆ(準備1成功 && 準備2成功 && 準備3成功 && ......... 準備100
成
> 功) {
> 私は猿頭なので、複雑なｉｆ文を理解できない。
> }
これは言われると思いました。（笑
少し考えればこういうコードにはならないです。
> 理由３：
> 私はフラグが嫌いだ。
これは人によると思うのでコメントしかねます。
> 理由４：
> 私は変数が多いのが嫌いだ。
あう。。
変数つかっちゃダメですか・・
＃1個、2個、たくさん、じゃないですよね？
> 理由５：
> 私は処理速度が遅いのが嫌いだ。
最後はこれですか（＾＾；
コンパイラの最適化に負けないようにがんばってください
> 理由６：
> 私はＢＵＧが嫌いだ。
> ＃準備２、準備１の後始末は？？？？
>
> > if(b1) 準備3の後始末;
> > if(b2) 準備3の後始末;
> > if(b3) 準備3の後始末;
テヘ（汗
Junn Ohta
suz...@ma.kcom.ne.jpさんは書きました。
> そりゃたしかにプログラムの流れはそこで変りますが、gotoの場合、行き先の
> ラベルを探さなければならないのです。
gotoを使うのは異常処理が必要な場面がほとんどなので、
gotoが出てきた箇所では「ああ、どこか後始末するとこ
ろに飛ぶんだな」と思っておけばじゅうぶんです。その
時点で「行き先のラベル」を探す必要はなくて、そのラ
ベルが出てきたところで「どこから飛んで来ているか」
をチェックすればだいたいOK。
> 意味のある名前を使っているのならいいのですが。
> L100:
> L200:
> L300:
> なんてラベルでさらに番号が順番に並んでいない場合だと読む気がしなくなり
> ます。
これはまあそうだけど、プログラミングで使われるすべ
ての「名前」についていえることなので、ここでとりた
てていいたてる必要もないでしょう。
> 「gotoを絶対に使うな」ではなく、使い方ですね。
実際のところ「gotoを絶対に使うな」なんて制約のある
開発現場ってどれくらいあるのでしょうね? それがほと
んどないのならわざわざ力みかえって「gotoを絶対に使
うな」に反論する必要もないわけだし。
ちなみに、goto(returnやbreakを含めて)を使わずにす
ませるためにフラグ変数を導入するのには私は反対。有
効範囲がブロック全体に広がってしまうし、ブロック内
の名前空間がその種の異常処理のために汚染されるのも
うれしくないです。
私のコーディングスタイルは高津さんの「最近の」方法
に近いかな。
--
太田純(Junn Ohta) (株)リコー/新横浜事業所
oh...@sdg.mdd.ricoh.co.jp
Junn Ohta
ta...@mug.biglobe.ne.jpさんは書きました。
> 第３：
> 「殆ど無視して聞く気がない。。。」
> const の使用方法の時、白旗を揚げた投稿をしてます。
> ＃あと、繰り返しですが、話が通じないと思ったら、無視します。
私は田部さんが持ち出す実例にほとんど現実味が感じら
れないし、どういう現場を見たらそんな例が出てくるの
かお聞きしたと思うのですが、それに対する返事はもら
ってませんよね。
返事がないのはべつにそれでもかまわないのですが、こ
ちらからの質問には返事をせず、それにもかかわらず同
じように現実味のない例を持ち出して新しいスレッドで
議論を始める態度にはちょっとへきえきしています。
そういうことをするなら、その前に「自分の持ち出した
実例がどれだけ現実の世界で問題になっているか」を示
す根拠を見せていただけませんか?
ちなみに、「いつまでバグを買わされるのか」というサ
ブジェクトも、議論の内容にほとんど関係ありませんし、
いかにも商用目的の「あおり」に見えます。次からはこ
ういうサブジェクトはやめてください。
Sugihara Yoshimi
> ませるためにフラグ変数を導入するのには私は反対。有
> 効範囲がブロック全体に広がってしまうし、ブロック内
> の名前空間がその種の異常処理のために汚染されるのも
> うれしくないです。
高津さんのgoto使ったコードでも私が書いたgotoなしコードにあるフラグは
必要だとおもいますが？
Junn Ohta
sugi...@kyosai.or.jpさんは書きました。
> 高津さんのgoto使ったコードでも私が書いたgotoなしコードにあるフラグは
> 必要だとおもいますが？
はい、だからあのコードのままなら、あのフラグには反
対しません。
ただ、gotoの飛び先を変えることでフラグによる判定を
減らすというのはアリですね。
Kazuo Fox Dohzono
In article <abniau$jdu$1...@ns.src.ricoh.co.jp>
oh...@src.ricoh.co.jp (Junn Ohta) writes:
> gotoを使うのは異常処理が必要な場面がほとんど
C だとその言語構造から (多重ループからの脱出とか) 色々考えられると思い
ます (登場頻度もそれほど少なくないと思います).
ISO/IEC 9899:1999 の例:
/* ... */
goto first_time;
for (;;) {
// determine next operation
/* ... */
if (need to reinitialize) {
// reinitialize-only code
/* ... */
first_time:
// general initialization code
/* ... */
continue;
}
// handle other operations
/* ... */
}
ちなみに goto と同じく jump-statement に分類されているのは次の通り.
(6.8.6) jump-statement:
goto identifier ;
continue ;
break ;
return expression-opt ;
switch はまた別ですね.
selection-statement:
if ( expression ) statement
if ( expression ) statement else statement
switch ( expression ) statement
case/default はラベルと一緒ですけど.
(6.8.1) labeled-statement:
identifier : statement
case constant-expr : statement
default : statement
# ラベルの後ろに必ず一文必要って知らない人もいたりして….
Junn Ohta
doh...@hf.rim.or.jpさんは書きました。
> > gotoを使うのは異常処理が必要な場面がほとんど
> C だとその言語構造から (多重ループからの脱出とか) 色々考えられると思い
> ます (登場頻度もそれほど少なくないと思います).
おおざっぱですけど、多重ループからの脱出(※)なども
異常処理に含めてました．
※多重ループの途中から脱出するのって、ようするにル
ープでなめているデータ構造の構造不整合をそのまま
反映しているのですよね?
Kazuo Fox Dohzono
oh...@src.ricoh.co.jp (Junn Ohta) writes:
> おおざっぱですけど、多重ループからの脱出(※)なども
> 異常処理に含めてました．
>
> ※多重ループの途中から脱出するのって、ようするにル
> ープでなめているデータ構造の構造不整合をそのまま
> 反映しているのですよね?
逆もありますよね.
if (failed)
return -1;
...;
的なコーディングで
for (y = 0; y < Y; y++)
for (x = 0; x < X; x++)
if (success (p[y][x]))
goto found;
return -1;
found:
// success (p[y][x]) is guaranteed here.
...;
とか. いやもちろん
for (y = 0; y < Y; y++)
for (x = 0; x < X; x++)
if (success (p[y][x])) {
...;
return 0;
}
return -1;
というのも同じなんですけど, 通常処理コードが長い場合は前者の方がわかり
易い気がします (後者の方は不成立の分を気にしながら読み進めないといけな
いので).
# 「goto を用いた構造的プログラミング」の例はこの手の検索に関するもの
# が多かったような.
Junn Ohta
doh...@hf.rim.or.jpさんは書きました。
> 逆もありますよね.
> ...
> というのも同じなんですけど, 通常処理コードが長い場合は前者の方がわかり
> 易い気がします (後者の方は不成立の分を気にしながら読み進めないといけな
> いので).
なるほど、おっしゃるとおりです。
> # 「goto を用いた構造的プログラミング」の例はこの手の検索に関するもの
> # が多かったような.
私の言語遍歴は次のような感じでして、
構造化されていないBASIC
Z80アセンブラー
Fortran
Cobol
Pascal
C
Pascalのところでいったん、ほとんどgotoに頼らないプ
ログラムを書くことになれて、そのあとCでまたgotoを
使うようになってきてます。
というわけで、goto危険論にあまり引きずられることな
く、わりと自由にgotoを使うほうなのですが...。
tabe
田部です。
下記の件、回答します。
"Junn Ohta" <oh...@src.ricoh.co.jp> wrote in message
news:abnio6$jdu$2...@ns.src.ricoh.co.jp...
> fj.comp.lang.cの記事<ab664l$qs4$1...@bgsv5905.tk.mesh.ad.jp>で
> ta...@mug.biglobe.ne.jpさんは書きました。
> > 第３：
> > 「殆ど無視して聞く気がない。。。」
> > const の使用方法の時、白旗を揚げた投稿をしてます。
> > ＃あと、繰り返しですが、話が通じないと思ったら、無視します。
>
> 私は田部さんが持ち出す実例にほとんど現実味が感じら
> れないし、
fj.comp.lang.cの常連の太田さんなら、
現実味が感じられると思うのですが、
そうでもない様ですね。
> どういう現場を見たらそんな例が出てくるの
> かお聞きしたと思うのですが、それに対する返事はもら
> ってませんよね。
残念ですが、現場の情報公開は限界があります。
＃これは、どこでも一緒だと思いますが。
> 返事がないのはべつにそれでもかまわないのですが、こ
> ちらからの質問には返事をせず、
%grep static *.h
で答えたつもりでしたが、
確かに、太田さんの現場に対する答えにはなっていませんね。
でも、
田村さんや、
河野さんが、
ヘッダファイル中にstaticがあったと、言ってくれてる事から、
日本中で、
staticの意味を「知らない」で使用している事例は、
容易に想像が出来るのでは？
＃ゴキブリ一匹見つかればなんとやらで、
> それにもかかわらず同 じように現実味のない例を
> 持ち出して新しいスレッドで
> 議論を始める態度にはちょっとへきえきしています。
じゃ、もう少し事例を出しましょう。
今回のスレッドの「 ネスト９段のプログラム 」ですが、
(1) goto 文を絶対禁止としている所がある事は
太田さんなら想像できるでしょう。
＃欧州の自動車産業界のＣ言語プログラムルールである、
ミセラルール（だったかな）でも goto には否定的です。
(2)で、goto を使用しただけで、受入拒否としている所ががある事は
太田さんなら想像できるでしょう。
＃goto を使用すると、ミセラルール遵守でなくなってしまう、等など。
(3) goto文を禁止されると、プログラマは
・ネストを深くするか、
・フラグの多用と、ｉｆ文を煩雑にするか
の二者択一を迫られる。
で、 ネストが異常に深くなる場合がある。
ほかにも、
藤原さんのプログラミング診断室の事例：
http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.12.3.html
と言うわけで、
ネスト9段、10段は日本中に幾らでもあります。
ＷＥＢで探すと他にも見つかりますが、
直リンクすると、色々問題になりそうなのでやめときます。
> そういうことをするなら、その前に「自分の持ち出した
> 実例がどれだけ現実の世界で問題になっているか」を示
> す根拠を見せていただけませんか?
＃ネスト9段、10段は問題ではないと、
＃言われると絶句してしまいますが。
> ちなみに、「いつまでバグを買わされるのか」というサ
> ブジェクトも、議論の内容にほとんど関係ありませんし、
> いかにも商用目的の「あおり」に見えます。次からはこ
> ういうサブジェクトはやめてください。
ここは、素直に先輩の指摘に従いましょう。
> --
> 太田純(Junn Ohta) (株)リコー/新横浜事業所
> oh...@sdg.mdd.ricoh.co.jp
--
Takashi Yamamura
なんか話がずれて申し訳ないのと、別の発言にfollowすべきなのかも
しれませんが…ということで迷ったのですが、適宜subjectなどを変えて
いただければ幸いです。<(_ _)>
On 13 May 2002 09:27:42 GMT, in <abo0ue$nij$1...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:
>私の言語遍歴は次のような感じでして、
>
> 構造化されていないBASIC
> Z80アセンブラー
> Fortran
> Cobol
> Pascal
> C
さすがにCOBOLはやったことがないや。^_^;その他は計算機学科の人間
じゃないのに、6809アセンブラとか、Modula-2とかを学生時代にやって
ました。あ、あとBASIC-09とか。(笑)今から考えると当時は実力不足で
(今でも実力不足だけど)ゴミのようなプログラムしか書けなかったの
ですが、懐かしいなぁ。
私自身は「goto拒否症候群」みたいな問答無用の拒絶反応はあまりないと
思います。ただ、「プログラム書法」に悪い例として載っているような
if と goto でループを作るようなヤツは止めてほしいなとは思います。
例外処理に使うんだったら、まあいいんじゃないと思います。
実は、自分で作ったコーディング規約(あんまり批准されてないですけど)
では一応禁止したんですが、codeが分かりやすくなると確信出来る
くらいの熟練者があえて goto を使いたい局面というのがあるのは理解
出来ます。最近はもっぱら C++ なので使うことはありませんけど、
実際私も C だったら使うのが適切だなと思うことはありました。
で、コーディング規約を作る立場からすると、「goto は例外処理以外に
使うな」とか書いても、誤読というかへんてこな解釈をする奴はいる訳で、
そんな奴は goto 乱発のコードになってしまう可能性がある。そうすると
「goto 乱発コード」か「flag 乱発コード」の二者択一という低レベルの
争いになるんですが(T_T)、「goto
乱発コード」の方がループ構造が見えにくい
のではないかということで、あえてそのコーディング規約では
「goto 禁止」にしました。
まあ、「ここは、こんな風にしたらいいんじゃない?」程度の強制力の規約
だったのと、私以上のスキルを持った人には「goto 使うな」とまでは
言っていないという私の意図を汲んでくれたらしい(ちゃんと分かってない
なら使うな、という程度の意図だったこと)のとがあって、あまり混乱は
なかったのですが。
# せっかく作ったコーディング規約、作った本人も含めて、だ～れも守る
# 気がないから、摩擦が起きなかったという説もある。(核爆)
---------
山村 隆志 「debugは３歩後退、２歩前進、いつまでたっても終らない」
e-mail : vy...@janis.or.jp
WWW page : http://www.janis.or.jp/users/vyama/
Shinji Nishimoto
> fj.comp.lang.cの記事<abo008$2obv$1...@news2.rim.or.jp>で
> doh...@hf.rim.or.jpさんは書きました。
> というわけで、goto危険論にあまり引きずられることな
> く、わりと自由にgotoを使うほうなのですが...。
C99 の仕様が加わると多少事情が変わるかもしれません。例えば次のようなコー
ドの場合、
int i = 0;
goto skip;
int j = 1;
skip:
goto ではジャンプはできませんし、警告を出さないコンパイラがあった場合
危険を伴う可能性があります。
また最近の C++ においては goto によって後始末をするような処理を書いた
場合、例外に対して安全性を保証できなくなる可能性があります。
C++ はちょっと本題からずれますが、新しい状況を見越した上で goto を使わ
ないように習慣付けるようにするのはそう悪くはないと思うのですが…。
いかがでしょう？
--
Shinji Nishimoto (西元 真司)
mailto: nis...@osb.att.ne.jp
Kazuo Fox Dohzono
"Shinji Nishimoto" <nis...@osb.att.ne.jp> writes:
> C99 の仕様が加わると多少事情が変わるかもしれません。例えば次のようなコー
> ドの場合、
>
> int i = 0;
> goto skip;
> int j = 1;
> skip:
int i = 0;
;
int j = 1;
でも駄目だと思うんですけど.
(6.8.2) block-item:
declaration
statement
C99 絡みで goto が使えないのは可変長配列 (VLA) などを使ったときですね.
[#4] EXAMPLE 2 A goto statement is not allowed to jump past
any declarations of objects with variably modified types. A
jump within the scope, however, is permitted.
goto lab3; // invalid: going INTO scope of VLA.
{
double a[n];
a[j] = 4.4;
lab3:
a[j] = 3.3;
goto lab4; // valid: going WITHIN scope of VLA.
a[j] = 5.5;
lab4:
a[j] = 6.6;
}
goto lab4; // invalid: going INTO scope of VLA.
Narita Takaoki
<abosmm$dkj$1...@cobalt01.janis.or.jp>の記事において
vy...@janis.or.jpさんは書きました。
> On 13 May 2002 09:27:42 GMT, in <abo0ue$nij$1...@ns.src.ricoh.co.jp>,
> oh...@src.ricoh.co.jp (Junn Ohta) wrote:
>
> >私の言語遍歴は次のような感じでして、
:
> 私自身は「goto拒否症候群」みたいな問答無用の拒絶反応はあまりないと
> 思います。ただ、「プログラム書法」に悪い例として載っているような
> if と goto でループを作るようなヤツは止めてほしいなとは思います。
> 例外処理に使うんだったら、まあいいんじゃないと思います。
私は「goto 拒否症候群」ではないですが、自分ではまず goto を書かな
いですねぇ。書くにしても、まさしく書く前から明らかに goto を使っ
た方が分かりやすくなることが自明な状況でもない限り使わないです。
でも大抵は、まず最初の発想時点で goto はきれいに抜け落ちているこ
とが大半。
例えば、既に出ていた例(see: <abfch9$4f7$1...@narans.cc.nara-wu.ac.jp>)
だと
void preparation1() {
準備1;
if (準備1失敗) {
return;
}
preparation2();
後始末1;
}
void preparation2() {
準備2;
if (準備2失敗) {
return;
}
preparation3();
後始末2;
}
void preparation3() {
準備3;
if (準備3失敗) {
return;
}
do(); /* やらないかん処理 */
後始末3;
}
って方向におそらく頭が行っちゃう。もちろん、各準備や後始末がそれ
ぞれわずかなら goto とか使ったりとかいう方向に行っちゃうとは思い
ますが、それなりに文量があると恐らく上記のような方向に思考が指向
(嗜好か？^^;)しちゃうと思うです。
# LISP をいじるようになって以降は、余計にこの傾向が強くなっている
# 気もする。(^^;
> で、コーディング規約を作る立場からすると、「goto は例外処理以外に
> 使うな」とか書いても、誤読というかへんてこな解釈をする奴はいる訳で、
> そんな奴は goto 乱発のコードになってしまう可能性がある。そうすると
> 「goto 乱発コード」か「flag 乱発コード」の二者択一という低レベルの
> 争いになるんですが(T_T)、「goto 乱発コード」の方がループ構造が見え
> にくいのではないかということで、あえてそのコーディング規約では
> 「goto 禁止」にしました。
goto を使う事の得失を論じ得ないなら使うなって方針は、間違っていは
いないのではないでしょうか。で、論じ得る人であれば、恐らくその規
約の強制度も計り得るはずで、その結果使った方が得であると思えば、
臨機応変に規約破りに走るような。(^^;
> # せっかく作ったコーディング規約、作った本人も含めて、だ～れも守る
> # 気がないから、摩擦が起きなかったという説もある。(核爆)
私の場合は、存在しているのは知ってはいたけれど、破る必要を感じた
ら破る事をためらわないし、それで非難でもされない限りは、自分から
仕掛けて摩擦を起こす必要も感じていないし。(^^;;;
# まぁ、上記したように普段から goto が思考から抜け落ちているので、
# その点では破りようがないのだけれど。
--
成田 隆興 ＠ エー・アイ・ソフト株式会社ソリューシュン開発部
E-mail tak...@aisoft.co.jp
『十分間で決断し、短い理由を添えよ。』
Kazuo Fox Dohzono
"tabe" <ta...@mug.biglobe.ne.jp> writes:
> %grep static *.h
> で答えたつもりでしたが、
inline 展開されることを期待して作成された関数群がヒットするんですが
それがどういう意味を持つんでしょうか.
Narita Takaoki
# 自己フォローの形になっちまいますが。
大元の「ネストが云々」の場合でしたら、もう「状況依存」としか答え
ようがないです。
コードを渡されて改造を依頼され、そんな汚い代物を渡された意趣返し
をする余裕があるなら、１０段どころかもっとワケワカラン代物に改造
してみたりして。
# 冗談だよお。(^^;;;
斯くの如く、将しく状況依存でやる事は変る。
Junn Ohta
tak...@aisoft.co.jpさんは書きました。
> でも大抵は、まず最初の発想時点で goto はきれいに抜け落ちているこ
> とが大半。
> 例えば、既に出ていた例(see: <abfch9$4f7$1...@narans.cc.nara-wu.ac.jp>)
> だと
> って方向におそらく頭が行っちゃう。
うーん、私はこれはやらないな。(^^;
というか、少なくとも
preparation1()
preparation2()
preparation3()
do()
という関数が並んでたら、praparation...()が終わって
からdo()を実行するというふうに読んじゃう。
逆のいいかたをすれば、そういうふうに(逐次的に)実行
するのでなければ、自分では関数にこういう命名はしな
いと思います。
また、
> void preparation1() {
> 準備1;
> if (準備1失敗) {
> return;
> }
> preparation2();
> 後始末1;
> }
この関数だけを眺めた場合、純粋に構造化プログラミン
グ(入口出口ともに1)の原則をつらぬくとしたら、こう
ではなくて
void preparation1() {
準備1;
if (準備1成功) {
preparation2();
後始末1;
}
}
となるはずですよね。それをしないのなら成田さんが書
かれたような関数のネストを使う方法も、風通しを少し
よくするcosmeticにすぎないわけで、私はgotoを使わん、
と声を大にして叫ぶほどのものではないのでしょう。
でも私もやはり
void preparation1() {
準備1;
if (準備1失敗) {
return;
}
preparation2();
後始末1;
}
と書きたい。なぜかといえば、
準備1;
preparation2();
後始末1;
は正常ルートでは逐次実行されるものだから。だからイ
ンデントレベルも同じにしたいという気持ちがあるんで
すよね。
同じ理由で、
準備1;
...
err = TRUE;
preparation2();
if (err)
後始末1;
よりも
準備1;
...
goto err;
preparation2();
err:
後始末1;
のほうが私にとっては見通しがよかったりします。
Narita Takaoki
# 言い訳記事 (^^;
<abq51b$e5g$1...@ns.src.ricoh.co.jp>の記事において
oh...@src.ricoh.co.jpさんは書きました。
> というか、少なくとも
> preparation1()
> preparation2()
> preparation3()
> do()
> という関数が並んでたら、praparation...()が終わって
> からdo()を実行するというふうに読んじゃう。
>
> 逆のいいかたをすれば、そういうふうに(逐次的に)実行
> するのでなければ、自分では関数にこういう命名はしな
> いと思います。
逐次性云々はおいても、私も実際には関数名はそうはしないでしょう。
今回は「準備」とか書かれていたから、それにつれてこう(preparation)
書いただけで、実際だったら「準備[1-3]」の内容に従った関数名を考え
て付けるですね。
# もしかしたら、preparation(), subpreparation(), subsubpreparation()
# だったり。(^^; こっちの方が、逐次性は感じないけれど。
# 全部書くと preparation_and_disposition()...とかだろうけれど、さ
# すがにねぇ……まぁ、こんな状況依存な命名に関する話をしてもこの
# 場ではせんない。
> この関数だけを眺めた場合、純粋に構造化プログラミン
> グ(入口出口ともに1)の原則をつらぬくとしたら、こう
> ではなくて
>
> void preparation1() {
> 準備1;
> if (準備1成功) {
> preparation2();
> 後始末1;
> }
> }
>
> となるはずですよね。
そうです。実は、記事を書いた際の第一稿ではそうなっていましたが、
> でも私もやはり
>
> void preparation1() {
> 準備1;
> if (準備1失敗) {
> return;
> }
> preparation2();
> 後始末1;
> }
>
> と書きたい。なぜかといえば、
>
> 準備1;
> preparation2();
> 後始末1;
>
> は正常ルートでは逐次実行されるものだから。だからイ
> ンデントレベルも同じにしたいという気持ちがあるんで
> すよね。
やはり同様な思考課程を経て件のコードに直しました。
Junn Ohta
vy...@janis.or.jpさんは書きました。
> さすがにCOBOLはやったことがないや。^_^;その他は計算機学科の人間
> じゃないのに、6809アセンブラとか、Modula-2とかを学生時代にやって
> ました。あ、あとBASIC-09とか。
遊びでちょっと書いてみる程度ならPL/IやAdaや考古学
的LispやPrologもやりました。いま書けといわれたら書
けませんが。:-)
> で、コーディング規約を作る立場からすると、「goto は例外処理以外に
> 使うな」とか書いても、誤読というかへんてこな解釈をする奴はいる訳で、
> そんな奴は goto 乱発のコードになってしまう可能性がある。そうすると
> 「goto 乱発コード」か「flag 乱発コード」の二者択一という低レベルの
> 争いになるんですが(T_T)、「goto乱発コード」の方がループ構造が見えにくい
> のではないかということで、あえてそのコーディング規約では
> 「goto 禁止」にしました。
そういう考えもあるでしょうね。でも「誤読というかへ
んてこな解釈」ってどれぐらいあります? 私はあまり思
いつかないな。
私が「例外処理」と書いたものの中には、ほかの人から
みたら「例外処理じゃないじゃん」なものも含まれてい
るかもしれません。ようするに、正常なデータについて
は本来の制御構造で処理し、そのルートから外れたもの
を扱うときにはgotoでシンクロさせてもかまわない、と
いう考えです。入力の構造がおかしいときに
goto again;
で手戻りさせるとかですね。
逆に私が「これはやってはいけないな」と思うのは、複
雑な入力構造を扱うときに、その構造を明快な制御構造
に反映できず、gotoを使ってつぎはぎの処理をしようと
しているもの。「このgotoは何をするgoto?」と聞いて
みて、単純でない答えが返ってきたら、そういうgotoで
ある可能性が高いです。:-)
コーディング規約にも「そういうgotoは禁止」と書いて
おけばすむと思うのだけど、だめかな? :-)
Kazuo Fox Dohzono
oh...@src.ricoh.co.jp (Junn Ohta) writes:
> 「このgotoは何をするgoto?」と聞いてみて、単純でない答えが返ってきた
> ら、そういうgotoである可能性が高いです。:-)
「単純じゃないね」と言うと「えー? 単純じゃないですか」と答えるスゴイ人
だったり… :-)
Junn Ohta
ta...@mug.biglobe.ne.jpさんは書きました。
> > 私は田部さんが持ち出す実例にほとんど現実味が感じら
> > れないし、
> fj.comp.lang.cの常連の太田さんなら、
> 現実味が感じられると思うのですが、
> そうでもない様ですね。
ええとですね、たとえば今回、田部さんは「ネスト9段
のプログラム」を持ち出したわけですけど、そのプログ
ラムがどうしてそのように作られていたのかについては
何も説明されていないわけです。
その「ネスト9段」が、それなりの意味があってそうな
っているのなら、私なら何のためらいもなくもう1段追
加するところです。逆に、よくないコーディングのせい
で「ネスト9段」になっているのなら、処理を追加する
しないに関係なく構造に手を入れたくなるでしょう。
つまり、現状に対して「それがどうしてそうなっている
のか」を説明せずに「あなたならどうしますか?」と聞
かれても、そんなものに現実味はないし、答えようもな
いのですよ。
# だから私は具体例をお伺いするのだし、どういう現場
# でそういうものが作られているのかについても示して
# ほしいと要求するわけ。しらいさんや熊岡さんが「前
# 提や背景を全く示さずに」とおっしゃるのも同じ不満
# があるからでしょう。
察するに、田部さんは「ネスト9段のプログラム」など
というものは、その存在自体が間違っている、という単
純な価値観をお持ちなのではないかと思います。これま
でのすべての実例についてもそう。だから、その手の例
が現実にどれくらい問題になっているのかを前提として
示そうという考えが出てこない。
また、田部さんはわりとよい参考書を引いてご自分の方
針が正しいことを示そうとされますが、それらの参考書
でどうしてそういうことが書かれたか(背景)についての
配慮がすっぽり抜け落ちている。
前提も背景もなしに悪いコードは悪いコードである、と
いえれば、そういうコードをあぶり出すReview-Cのよう
なツールの宣伝にもなるわけですが、まあ私は田部さん
が宣伝効果を考えて次々にこういう例を出しているとは
思っていません。逆に、田部さんご自身がそういう単純
な価値観をお持ちだからこそ、Review-Cのようなツール
を作ったり宣伝したりしたくなるのだと考えます。
というわけで田部さんには、他人がどういうことを考え
て議論しているのかについて、もう少し突っ込んで考え
ることをおすすめしておきます。
Junn Ohta
nis...@osb.att.ne.jpさんは書きました。
> C++ はちょっと本題からずれますが、新しい状況を見越した上で goto を使わ
> ないように習慣付けるようにするのはそう悪くはないと思うのですが…。
> いかがでしょう？
C99やC++については考えていなかったので、そういう問
題はあるのかもしれませんが、「gotoを使わないように
習慣付ける」ことによって無条件にデメリットが入り込
むのはやっぱりうれしくありません。
やっぱり「状況による」ですね。:-)
Junn Ohta
ta...@mug.biglobe.ne.jpさんは書きました。
> でも、
> 田村さんや、
> 河野さんが、
> ヘッダファイル中にstaticがあったと、言ってくれてる事から、
これはおそらく、田部さんが指摘しているような無知に
よる例ではないだろうと私は考えています。ので、
> 日本中で、
> staticの意味を「知らない」で使用している事例は、
> 容易に想像が出来るのでは？
こちらはちっとも想像できません。
> 今回のスレッドの「 ネスト９段のプログラム 」ですが、
> (1) goto 文を絶対禁止としている所がある事は
> 太田さんなら想像できるでしょう。
> ＃欧州の自動車産業界のＣ言語プログラムルールである、
> ミセラルール（だったかな）でも goto には否定的です。
「ミセラルール」というのは知りませんし、検索しても
見つかりませんでした。まあ「goto絶対禁止」の現場が
存在するだろうということは想像できます。
> (2)で、goto を使用しただけで、受入拒否としている所ががある事は
> 太田さんなら想像できるでしょう。
> ＃goto を使用すると、ミセラルール遵守でなくなってしまう、等など。
これもまあ想像はできる。
> (3) goto文を禁止されると、プログラマは
> ・ネストを深くするか、
> ・フラグの多用と、ｉｆ文を煩雑にするか
> の二者択一を迫られる。
> で、 ネストが異常に深くなる場合がある。
ネストが「異常に」深いのなら正常に直せばよいのです。
理由があって深いのならそれはそれでかまわないでしょ
うし、それはgotoが禁止されているかどうかとは無関係
に発生することです。
> ＃ネスト9段、10段は問題ではないと、
> ＃言われると絶句してしまいますが。
じゃあそのまま絶句していてください。:-)
Takashi Yamamura
On 14 May 2002 02:58:22 GMT, in <abpuge$g9b$1...@news01.highway.ne.jp>,
tak...@aisoft.co.jp (Narita Takaoki) wrote:
>でも大抵は、まず最初の発想時点で goto はきれいに抜け落ちているこ
>とが大半。
struct foo {
int * TableHeight;
int * TableWidth;
<snip>
};
みたいな感じで、沢山fieldが並んでいる構造体を設定するような関数で、
各々のfieldの差す場所をmallocとかでメモリ確保したいなんて場合が
ありませんか?で、関数の最初でそれらのfieldを、一旦NULLで初期化して
おいて、途中でメモリ確保に失敗したら、goto で
error:
free(TableHeight);
free(TableWidth);
<snip>
return NOT_SUCCESS;
みたいな場所に飛ばすとかって、私はよくやっていそうな気がするんで、
「最初の発想時点で goto はきれいに抜け落ち」るってことはないような
気がします。
# 初期設定関数が長くなるようだったら、もっと細かい関数に分割すると
# 思うけど、基本戦略は同じ。
Cだと結構ありがちな状況のような気がするんですが、私の感覚がおかしい
のかな。(最近はほとんどC++なんでthrowして終わり…)
JAVAだと、構造体foo型の変数tmpみたいなのに、newで確保した結果を代入
しておいて、全部確保出来たら、その構造体をコピーして終わり、確保出来
なかったら、tmpを破棄すれば、確保したメモリも適当な直に破棄される。
(という理解であってます?)そんな仕組みなら確かに楽ですよね。
>約の強制度も計り得るはずで、その結果使った方が得であると思えば、
>臨機応変に規約破りに走るような。(^^;
で、その規約を書いた本人が上記のような状況でgotoを使っていたりするん
です。私の書いた規約と、そのコードの両方を読んだ人はどんな感想を
持ったんでしょうね。^_^;もっとも私の書いたコーディング規約はそんな強制度の
評価をできない人向けの一定の指針になるように書いたつもりでした。社員全員に
強制するとなると、変数名のつけ方だけでも大論争になりそう…。
>それで非難でもされない限りは、
反抗するのは「コーディング規約に従ってはいる」けど「理不尽な非難」でしょ。^_-
相手に理があるんだったら、私としては説得されてほしいなぁ。^_^;という意味
不明な事をこんな公の場で言ってみたりする。:-)
Shinji Nishimoto
"Kazuo Fox Dohzono" <doh...@hf.rim.or.jp> wrote in message
news:abpsmh$m6v$1...@news2.rim.or.jp...
> In article <abov4l$lkl$1...@newsflood.osaka.att.ne.jp>
> "Shinji Nishimoto" <nis...@osb.att.ne.jp> writes:
>
> > C99 の仕様が加わると多少事情が変わるかもしれません。例えば次のようなコー
> > ドの場合、
> >
> > int i = 0;
> > goto skip;
> > int j = 1;
> > skip:
>
> int i = 0;
> ;
> int j = 1;
>
> でも駄目だと思うんですけど.
>
> (6.8.2) block-item:
> declaration
> statement
申し訳ありません。「ジャンプできない」と書いたのは行き過ぎでした。
文法上記述可能であることは知っていましたが、この宣言を跨いだ goto が合
法であるのか非合法なのかは知りませんでした。
身近にある C++ コンパイラではこのような記述は許されないようなのですが、
C99 と C++ において宣言を跨いだ goto の扱いに違いがあるということも考
えられるんでしょうか。
この辺りの事、ご存じでしたらお教え頂けたらと思います。
tabe
田部で。
下記の件、
http://news.dinf.ne.jp/news/fj/comp/lang/c/msg00027.html
http://news.dinf.ne.jp/news/fj/comp/lang/c/msg00037.html
http://news.dinf.ne.jp/news/fj/comp/lang/c/msg00071.html
あたりを、参照下さい。
--
以上
見て、勝手使って http://rec.ncos.co.jp
"Kazuo Fox Dohzono" <doh...@hf.rim.or.jp> wrote in message
news:abq1m1$oqp$2...@news2.rim.or.jp...
tabe
田部です。
"Junn Ohta" <oh...@src.ricoh.co.jp> wrote in message
news:abq9je$fdf$1...@ns.src.ricoh.co.jp...
> fj.comp.lang.cの記事<abol0d$ahc$1...@bgsv5906.tk.mesh.ad.jp>で
> ta...@mug.biglobe.ne.jpさんは書きました。
> > > 私は田部さんが持ち出す実例にほとんど現実味が感じら
> > > れないし、
> > fj.comp.lang.cの常連の太田さんなら、
> > 現実味が感じられると思うのですが、
> > そうでもない様ですね。
>
> ええとですね、たとえば今回、田部さんは「ネスト9段
> のプログラム」を持ち出したわけですけど、そのプログ
> ラムがどうしてそのように作られていたのかについては
> 何も説明されていないわけです。
じつはですね、
僕も知らないんですよ。
だから、ネスト9段、10段まで成長してしまう過程に
興味があるのですが。
> その「ネスト9段」が、それなりの意味があってそうな
> っているのなら、私なら何のためらいもなくもう1段追
> 加するところです。
例えば、
ｇｃｃなんかの中でも、
ネスト５～６段はざらにあります。
知っててやってる場合は、どうでも良いのです。
> つまり、現状に対して「それがどうしてそうなっている
> のか」を説明せずに「あなたならどうしますか?」と聞
> かれても、そんなものに現実味はないし、答えようもな
> いのですよ。
「現状ネスト１０段の物がある。
なぜネスト１０段にもなったのだろう？
あなたならどうしますか?
あなたならどうしましたか？」
と言う質問は、現実味がありませんか？
> 逆に、よくないコーディングのせい
> で「ネスト9段」になっているのなら、処理を追加する
> しないに関係なく構造に手を入れたくなるでしょう。
で、「手を入れたくな」っても
やってはいけない。と言う考えがある事を、
SAKAMOTO さんの答えで得ました。
http://news.dinf.ne.jp/news/fj/comp/lang/c/msg00281.html
> # だから私は具体例をお伺いするのだし、どういう現場
> # でそういうものが作られているのかについても示して
> # ほしいと要求するわけ。しらいさんや熊岡さんが「前
> # 提や背景を全く示さずに」とおっしゃるのも同じ不満
> # があるからでしょう。
ふむ。
間違いを犯すのは、固有の現場とお考えでしょうか？
私は、
どこの現場でも、
同じ様な間違いを、
同じ様に犯すと考えているのですが。
で、
同じ様な間違いを、
同じ様に犯す過程に興味があるのです。
> 察するに、田部さんは「ネスト9段のプログラム」など
> というものは、その存在自体が間違っている、という単
> 純な価値観をお持ちなのではないかと思います。
はい、単純です。
「ネスト9段のプログラム」など嫌いです。
＃大抵はただの、汚いソースコードだから。
出来れば、その存在も消したい。
> これまでのすべての実例についてもそう。だから、その手の例
> が現実にどれくらい問題になっているのかを前提として
> 示そうという考えが出てこない。
ここが、太田さんと僕の違いですね。
太田説
田部が示す例は特異な例である。故に背景説明がいる。
田部説
田部が示す例は特異な例ではない。故に背景説明はいらない。
> また、田部さんはわりとよい参考書を引いてご自分の方
> 針が正しいことを示そうとされますが、それらの参考書
> でどうしてそういうことが書かれたか(背景)についての
> 配慮がすっぽり抜け落ちている。
興味のある人がその本買って読めば、
背景書いてますから。
> 前提も背景もなしに悪いコードは悪いコードである、と
> いえれば、そういうコードをあぶり出すReview-Cのよう
> なツールの宣伝にもなるわけですが、
> まあ私は田部さん
> が宣伝効果を考えて次々にこういう例を出しているとは
> 思っていません。
> 逆に、田部さんご自身がそういう単純
> な価値観をお持ちだからこそ、Review-Cのようなツール
> を作ったり宣伝したりしたくなるのだと考えます。
そうですね。単純です。
あと、次々にこういう例を出を理由の一つに、
と学会の人が、
「とんでも本」を紹介する心理に
似た物があります。
＃と発会をご存知なけらば、本屋さんにあります。
> というわけで田部さんには、他人がどういうことを考え
> て議論しているのかについて、もう少し突っ込んで考え
> ることをおすすめしておきます。
僕は議論好きではありません。
「こんなのがありますよ、皆さんの所はどう？」
程度の投稿です。
KANDA Toshihiro
> また、田部さんはわりとよい参考書を引いてご自分の方
> 針が正しいことを示そうとされますが、それらの参考書
> でどうしてそういうことが書かれたか(背景)についての
> 配慮がすっぽり抜け落ちている。
このあたりが針箱と似てるんですよね。
本質的な理解なしに、教条・スローガンを字面だけ信じちゃってるという……
信じちゃってるのみならず、撒き散らしてると。
神田敏広 <ca...@kgc.co.jp>
red brick
>> ええとですね、たとえば今回、田部さんは「ネスト9段
>> のプログラム」を持ち出したわけですけど、そのプログ
>> ラムがどうしてそのように作られていたのかについては
>> 何も説明されていないわけです。
>
>じつはですね、
> 僕も知らないんですよ。
> だから、ネスト9段、10段まで成長してしまう過程に
> 興味があるのですが。
設計に問題があるのでは。というか、設計せずに製作しているのでは。
--
赤煉瓦
Shinobu Kumaoka
tabe wrote:
> 田部が示す例は特異な例ではない。故に背景説明はいらない。
特異な例であろうがなかろうが、それなりに背景説明をするのは
基本的なマナーです。
--
cog...@sp.hudson.co.jp
株式会社ハドソン
コア・テクノロジー事業本部
システム部 ソフトウェア課
熊岡 忍(Kumaoka Shinobu)
Hoshi Takanori
In article <abs5md$dte$1...@bgsv5906.tk.mesh.ad.jp>
"tabe" <ta...@mug.biglobe.ne.jp> writes:
> じつはですね、
> 僕も知らないんですよ。
> だから、ネスト9段、10段まで成長してしまう過程に
> 興味があるのですが。
つまり、ここで実例を集めて、それを商売のネタにしようと
してらっしゃるのでしょうか？
> 見て、勝手使って http://rec.ncos.co.jp
相変わらず fj の AUP に違反した宣伝のための投稿のようですね。
ほし
Sugihara Yoshimi
"KANDA Toshihiro" <ca...@kgc.co.jp> wrote in message
news:s7fsn4u...@xxx.kgc.co.jp...
教条やスローガンを本質的な理解なしに撒き散らすことはないのでは？
逆に教条やスローガンを書いた過去の偉大な人に共感したからこそ
重要だと感じて撒き散らすと思うんですけど？
Hoshi Takanori
In article <abrkfv$p57$1...@newsflood.osaka.att.ne.jp>
"Shinji Nishimoto" <nis...@osb.att.ne.jp> writes:
> > int i = 0;
> > ;
> > int j = 1;
> >
> > でも駄目だと思うんですけど.
> >
> > (6.8.2) block-item:
> > declaration
> > statement
これ、どう「駄目」なんでしょう？
C99 (ANSI+ISO+IEC+9899-1999.pdf) の Foreword の第 5 項には、
C90 からの変更点のひとつとして、
- mixed declarations and code
ってのがあげられてますけど。
＊＊
> 身近にある C++ コンパイラではこのような記述は許されないようなのですが、
> C99 と C++ において宣言を跨いだ goto の扱いに違いがあるということも考
> えられるんでしょうか。
C++ (ISO+IEC+14882-1998.pdf) の場合、6.7 Declaration statement
の第 3 項に、
It is possible to transfer into a block, but not in a way
that bypasses declarations with initialization. A program
that jumps from a point where a local variable with automatic
storage duration is not in scope to a point where it is in
scope is ill-formed unless the variable has POD type (3.9)
and is declared without an initializer (8.5).
というわけで、C++ でまたげるのは POD かつ初期値を持たないもの
だけです。
つまり、C++ では、
int i = 0;
はまたげないけど、
int i;
i = 0;
はまたげます。C99 なら両方またげます。
ほし
Kazuo Fox Dohzono
> ＃ネスト9段、10段は問題ではないと、
> ＃言われると絶句してしまいますが。
今仕事で書いているプログラムをざっと調べたらこういうのがあったんですが,
{ // function entry
for ()
{
{ // block
switch ()
{
while ()
{
if ()
{
if ()
{
while ()
{
if ()
{
for ()
{
while ()
{
if ()
;
}}}}}}}}}}} // 一応閉じておこう :-)
何か問題があるんでしょうか.
# ちなみにトータル 2 万行程度の組み込み系で, このモジュールは 150 行程
# 度です.
Junn Ohta
ta...@mug.biglobe.ne.jpさんは書きました。
> じつはですね、
> 僕も知らないんですよ。
> だから、ネスト9段、10段まで成長してしまう過程に
> 興味があるのですが。
その「ネスト9段、10段」のプログラムが適切なものな
らそれでよいのだし、「成長してしまう過程」なんても
のを持ち出しても意味がないわけです。逆に、そのプロ
グラムがひどいプログラムなら、「ネスト9段、10段」
かどうかにまったくかかわらず、やはりひどいプログラ
ムであるわけ。
したがって、前提や背景を考慮することなくそういうこ
とに興味をもつというのは、議論として浅い、というか、
私からみれば不健全です。
田部さんが「ネスト9段、10段」を何らかの指標として
有効であるとお考えなのでしたら、その根拠を示してか
ら議論を始めたほうがよいですね。
> 「現状ネスト１０段の物がある。
> なぜネスト１０段にもなったのだろう？
> あなたならどうしますか?
> あなたならどうしましたか？」
> と言う質問は、現実味がありませんか？
具体例があれば現実味もあるでしょう。
> ふむ。
> 間違いを犯すのは、固有の現場とお考えでしょうか？
おおざっぱにいえば、そうです。
> 私は、
> どこの現場でも、
> 同じ様な間違いを、
> 同じ様に犯すと考えているのですが。
それならば、もう少し現実の開発現場で具体例を収集す
ることから始められたらいかがでしょう?
> ここが、太田さんと僕の違いですね。
> 太田説
> 田部が示す例は特異な例である。故に背景説明がいる。
> 田部説
> 田部が示す例は特異な例ではない。故に背景説明はいらない。
特異な例であろうがなかろうが、その「ネスト9段、10
段」のプログラムそのものを見ないかぎり、議論するに
値するほどのことはいえないのです。まあ田部さんは議
論がお好きでないとのことですから、そのあたりはどう
でもいいのかもしれませんが。
> 僕は議論好きではありません。
> 「こんなのがありますよ、皆さんの所はどう？」
> 程度の投稿です。
それは自分の文章を読んでくれる他人に失礼だと思うな。
それくらいの目的しかないのなら投稿をやめてください。
Kazuo Fox Dohzono
ho...@sra.co.jp (Hoshi Takanori) writes:
> これ、どう「駄目」なんでしょう？
すみません, 惚けていて or なのを順序が意味を持つと思ってしまいました.
(6.8.2) block-item:
declaration
statement
次の順でプログラム書け, なんてあるはず無いのに….
(6.8) statement:
labeled-statement
compound-statement
expression-statement
selection-statement
iteration-statement
jump-statement
Hisao Aoyama
> 下記の件、
> http://news.dinf.ne.jp/news/fj/comp/lang/c/msg00027.html
> http://news.dinf.ne.jp/news/fj/comp/lang/c/msg00037.html
> http://news.dinf.ne.jp/news/fj/comp/lang/c/msg00071.html
>
> あたりを、参照下さい。
これを見ても，static が見つかったらどうという意味は必ずしも
わかりませんが(田部さんが言いたかったことは想像できなくはない
ですが，この記事はそれに該当しないですよね)，それはさておき...
自分のところで見てみると，
1. 他社が書いたコードで，static な関数がヘッダーファイル
内で*定義*されているものが1つだけありました．
本当の意図はわかりませんが
- encrypt/decrypt に係わるコードで
- 複数の箇所で同じアルゴリズムを使うことを保証したい
- しかし，リンク可能な形式で外部に出すので，この関数を
直接呼ばれたくない
といった理由が想像できます．
なんでマクロにしなかったのかと聞かれても，私には答えられ
ません．
2. 生成されたヘッダーファイルに static な関数の*宣言*が含
まれるものが多数．
そのうちの一部は，私が変更した ASN.1 コンパイラのアウトプ
ットで，関数が使われる(呼ばれる)前に必ず宣言されていること
を保証したいため，.c ファイルの先頭で include される .h
に出力することにしたと思います．元は C++ のソースを出力す
るものだったので，その影響を引き摺っている面もあるかもしれ
ません．
他のジェネレーターのアウトプットの場合も，宣言を先頭にまと
める簡単な方法だからという理由が想像できます．
2'. 小さなイメージデータ(ビットマップ)など
これは，どこで include されるかわからないから，エディターの
出力だから画一的になっている，といった理由でしょう．
3. 変数を宣言するマクロの一部
#define DECLARE_PAGE_KEY(KEY_STR) static unsigned long key_##KEY_STR
4. C++ のパーサー部分では，変数名，関数名の一部に static
という文字列が入っていたり，コメントの中にあったり...
/*
...
local variables, allocated at function scope. Example:
void f()
{
int i = 0;
static int j = i; // case 1
Y y(X()); // case 2
...
Here j's initializer involves the local variable i, and y's initializer
...
*/
----
Hisao Aoyama 青山 尚夫
ASTEC Products, Inc. （株）アステック・プロダクツ
aoy...@astec.co.jp
Narita Takaoki
<abrbdo$4au$1...@cobalt01.janis.or.jp>の記事において
vy...@janis.or.jpさんは書きました。
> struct foo {
> int * TableHeight;
> int * TableWidth;
> <snip>
> };
>
> みたいな感じで、沢山fieldが並んでいる構造体を設定するような関数で、
> 各々のfieldの差す場所をmallocとかでメモリ確保したいなんて場合が
> ありませんか?で、関数の最初でそれらのfieldを、一旦NULLで初期化して
> おいて、途中でメモリ確保に失敗したら、goto で
>
> error:
> free(TableHeight);
> free(TableWidth);
> <snip>
> return NOT_SUCCESS;
>
> みたいな場所に飛ばすとかって、私はよくやっていそうな気がするんで、
> 「最初の発想時点で goto はきれいに抜け落ち」るってことはないような
> 気がします。
私だったらまずそうしないでしょう。まず大抵、その構造体の設定関数
に対応して解放する関数も作ると思うので、メモリ確保の失敗で例外処
理に突入し、そこまで確保したメモリも開放するなら、その構造体解放
用の関数を呼んでしまうと思います。
「goto は抜け落ちている」というより「goto の存在を忘れている」が
近いか？だから設計段階から goto を使うときは、かなり意識的にそう
いう方向に向かっていないと、逆に使えない。効率化の果てに goto に
行き着く場合は別ですが、この場合は通常のアプリの場合は最近はまず
ないですし。
# goto を最初から考えるのは、「今日は goto 使うぞ」とか「OS の
# kernel (or stdlib類)をいじるぞ」とかいうときだろうか。(^^;
> Cだと結構ありがちな状況のような気がするんですが、私の感覚がおかしい
> のかな。(最近はほとんどC++なんでthrowして終わり…)
いや、恐らく私が変なんだと思う気もしないでもないです。でも、goto
は忘れてもやっていけるです。
Kazuo Fox Dohzono
> じつはですね、
> 僕も知らないんですよ。
> だから、ネスト9段、10段まで成長してしまう過程に
> 興味があるのですが。
<abslik$23m4$2...@news2.rim.or.jp> に書いた構造ですが, これはモデムによる
単純な通信のタスクで, およそ以下のような処理になります.
{ // function entry
for (無限ループ)
{
// ここでタスク起動メッセージを受け取る
{
// モデムのセマフォ取得
switch (起動種別)
{
// 種別にはモデムの電源 on/off と RI による起動があります.
// 以下は RI の処理
case ...:
while (! (RI 確定タイムアウト))
{
if (RI 認識)
{
if (RING の accept ("ata") がうまくいった)
{
while (電文受信)
{
if (返事を要するものだった)
{
for (リトライ)
{
// 送信
while (キャリアがある)
{
if (送信バッファが空)
break;
}
if (キャリアがない)
break;
if (送信の返事を受け取った)
break;
}
}
}
}
// モデム切断
break;
}
}
break;
}
// モデムのセマフォ解放
}
}
}
# 通信の仕様は私が定めた訳ではありませんんので念の為.
まあ確かにいくつかの部分で条件を引っくり返せば浅くはなるでしょうけど,
サブルーチンを作ってまで浅くする必要もないと思います (これで 50 行程度
だし, 全体で 150 行程度ってのは既にまとまってる方だと思うし).
Narita Takaoki
<absvs1$28jn$1...@news2.rim.or.jp>の記事において
doh...@hf.rim.or.jpさんは書きました。
> <abslik$23m4$2...@news2.rim.or.jp> に書いた構造ですが, これはモデムによる
> 単純な通信のタスクで, およそ以下のような処理になります.
:
> まあ確かにいくつかの部分で条件を引っくり返せば浅くはなるでしょうけど,
> サブルーチンを作ってまで浅くする必要もないと思います (これで 50 行程度
> だし, 全体で 150 行程度ってのは既にまとまってる方だと思うし).
MS-Windows のアプリの GUI のハンドリングをする様な部分だと、これ
に近いやつが出来てくることがあるです。例えば、いくつかの複合条件
により、出すメニューやら、その項目やらを入れ換えたり何だりする様
なやつの場合は、これに似た感じになるです(同様にサブルーチンを作っ
てまで浅くする必要も無いような場合)。
で、これで困るのは、仕様の変更や追加が頻繁で、複合条件が複雑怪奇
になっちゃったときでして、それにつれ当然この制御構造も複雑怪奇で
グロテスクな代物になっちまう事で、でもまあそれは大抵既にどう書き
直しても理解し難い状況だから、それで即悪と決めつけられもせんわけ
でして。
# そういう理解を拒みたくなるようなグロな複合条件を押しつける奴と
# いうか、状況というかがイカンと言いますか。(^^;;;
Sugihara Yoshimi
> サブルーチンを作ってまで浅くする必要もないと思います (これで 50 行程度
> だし, 全体で 150 行程度ってのは既にまとまってる方だと思うし).
行数勝負ですか・・
私だったら処理の流れ的にもう少し何とか見やすくならないかなぁとか思うかな。
そこかしこにbreakがはいってるし
＃行数よりは見易さ重視の意見
Narita Takaoki
<abt1td$j2f$1...@news.kyosai.or.jp>の記事において
sugi...@kyosai.or.jpさんは書きました。
> 私だったら処理の流れ的にもう少し何とか見やすくならないかなぁとか思うかな。
> そこかしこにbreakがはいってるし
確かに、いくつかの break は行き先見定めるのが面倒といえば面倒です
ね。これこそ goto の出番？(^^;
# コメント付いてりゃ、それで私は許しちゃうかもしれないけれど。
AOKI Tomoyoshi
<abqe42$g8f$2...@ns.src.ricoh.co.jp>の記事において、
oh...@src.ricoh.co.jpさんは書きました。
> > 今回のスレッドの「 ネスト９段のプログラム 」ですが、
> > (1) goto 文を絶対禁止としている所がある事は
> > 太田さんなら想像できるでしょう。
> > ＃欧州の自動車産業界のＣ言語プログラムルールである、
> > ミセラルール（だったかな）でも goto には否定的です。
>
> 「ミセラルール」というのは知りませんし、検索しても
> 見つかりませんでした。まあ「goto絶対禁止」の現場が
> 存在するだろうということは想像できます。
「ミセラルール」ってのは、たぶん MISRA の C でのプログラミング
ガイドライン MISRA C のことだと思います。MISRA ってのは
The Motor Industry Software Reliability Association で
ホームページは http://www.misra.org.uk/ です。
なんらかのルールに縛られるのと、プログラムが美しくないのは
別ですよねぇ・・・。そもそも現場のルールなんてメリットの方が
大きいから採用されてるんだし。もしかすると自動車関係はほとんど
goto の必要性がないのかもしれないですね。
--
青木 友好
Kazuo Fox Dohzono
tak...@aisoft.co.jp (Narita Takaoki) writes:
> > 私だったら処理の流れ的にもう少し何とか見やすくならないかなぁとか思うかな。
> > そこかしこにbreakがはいってるし
>
> 確かに、いくつかの break は行き先見定めるのが面倒といえば面倒です
> ね。
$GCC/gcc/tradcpp.c の rescan() とかに比べれば数百倍わかり易いと思うん
ですが….
> これこそ goto の出番？(^^;
そっちには goto も多数登場してます.
# 私の方にも一モジュールに 10 個くらい登場するのがあった. これは全部エ
# ラー処理.
mucha
"Sugihara Yoshimi" <sugi...@kyosai.or.jp> wrote in message
news:absjt1$hrd$1...@news.kyosai.or.jp...
> 教条やスローガンを本質的な理解なしに撒き散らすことはないのでは？
> 逆に教条やスローガンを書いた過去の偉大な人に共感したからこそ
> 重要だと感じて撒き散らすと思うんですけど？
>
一般論的に、「教条やスローガンを書いた過去の偉大な人」を尊敬するあまり、
盲目的に「偉大な人」に従い、本質的な理解なしで撒き散らす事はあると思います。
神田さんのおっしゃってるのはそんな例なのでは？
--
e-mail: a...@stg.co.jp
D.Miyasaka
>> のプログラム」を持ち出したわけですけど、そのプログ
>> ラムがどうしてそのように作られていたのかについては
>> 何も説明されていないわけです。
>
>じつはですね、
> 僕も知らないんですよ。
> だから、ネスト9段、10段まで成長してしまう過程に
> 興味があるのですが。
そもそも「ネスト9段、10段はダメ」ということを誰も教えていない
とか、教えられていても「でも面倒だし、ま、いいか」となってる
とか、そういうつまらない理由じゃないかと私は思っているのですが。
あるいは「ネスト9段、10段はかっこいい」だったりして（笑）。
どなたかが紹介していた藤原さんの書籍では、ある会社では
上司や先輩がネストが何段にもなっているのを新人が真似してしまう
という事例が書かれていましたね。
--
D.Miyasaka <mailto:miya...@anet.ne.jp>
sy...@pb.ctt.ne.jp
最初の投稿時から一貫していると思います。
皆さんの議論は少しずれ過ぎているような気がするのですが。
「説明がない」や、「自分の周りでは見られない」等というのは、的を得ている
とは思えません。
（失礼を省みないで言えば、書いてないことを読むのも大事な能力です。）
田部さんの推奨製品を、ＮＥＣの関連会社が販売すること自体、田部さんが主張
するような、低いレベルのプログラマが、日本で問題になっていることの証明に
なっていると思います。
（ＮＥＣは、企業や公共機関の基幹業務で大きなシェアを持っています。
自社系列のプロジェクトに売り込むのでしょう。）
しかしながら、田部さんの論点は、このグループの本旨とは一致しないと思い
ますので、田部さんは別の適当なグループへ投稿すべきだと思います。
＃「失われた１０年」は、容易に「失われた５０年」になってしまいます。
Junn Ohta
sy...@pb.ctt.ne.jpさんは書きました。
> 「日本のプログラマのレベルは低いのではないか」という、田部さんの論点は、
> 最初の投稿時から一貫していると思います。
> 皆さんの議論は少しずれ過ぎているような気がするのですが。
田部さんの論点は最初から一貫して「商売がらみ」「危
機感のあおり」だと思います。なので、そこにハマらな
いように皆さん気をつけて議論されているのではないか
と思うのですが、いかがでしょう。
# 「日本の」という限定はあったかな?
> 「説明がない」や、「自分の周りでは見られない」等というのは、的を得ている
> とは思えません。
「説明がない」というのは、実体のないところに狼が来
たと騒いでしまう可能性を排除するためです。説明があ
れば田部さんの発言の説得力も高まるわけですし、議論
に参加している全員にとってメリットがあります。
「自分の周りでは見られない」も、田部さんの想定され
ているスキルレベルが低すぎるのではないかという指摘
の一部です。それが妥当ではないのなら、田部さんのほ
うが具体例を挙げればすむのです。
# 老婆心ながら、的は「射る」ものですよ。
> 田部さんの推奨製品を、ＮＥＣの関連会社が販売すること自体、田部さんが主張
> するような、低いレベルのプログラマが、日本で問題になっていることの証明に
> なっていると思います。
もちろん、この業界の中にはそういうレベルの低い開発
現場もあるでしょうし、そういうものがあればかなりの
問題になるでしょう。だからこういう製品が出てきても
不思議はないし、まったく売れないとは私も思いません。
問題はそれがどれだけ普遍的なのか、です。
# 「日本で」という限定はあったかな?
> （ＮＥＣは、企業や公共機関の基幹業務で大きなシェアを持っています。
> 自社系列のプロジェクトに売り込むのでしょう。）
なるほど。
sy...@pb.ctt.ne.jp
>
> 田部さんの論点は最初から一貫して「商売がらみ」「危
> 機感のあおり」だと思います。なので、そこにハマらな
> いように皆さん気をつけて議論されているのではないか
> と思うのですが、いかがでしょう。
田部さんの論点を離れ、自由に議論されている方は確かに
たくさんいらっしゃいます。
> # 「日本の」という限定はあったかな?
田部さんがソフトを売り込むのは日本なので、
田部さんは日本を想定しています。
> 「説明がない」というのは、実体のないところに狼が来
> たと騒いでしまう可能性を排除するためです。説明があ
> れば田部さんの発言の説得力も高まるわけですし、議論
> に参加している全員にとってメリットがあります。
>
> 「自分の周りでは見られない」も、田部さんの想定され
> ているスキルレベルが低すぎるのではないかという指摘
> の一部です。それが妥当ではないのなら、田部さんのほ
> うが具体例を挙げればすむのです。
確かにそうではあります。
>> 田部さんの推奨製品を、ＮＥＣの関連会社が販売すること自体、田部さんが主張
>> するような、低いレベルのプログラマが、日本で問題になっていることの証明に
>> なっていると思います。
> もちろん、この業界の中にはそういうレベルの低い開発
> 現場もあるでしょうし、そういうものがあればかなりの
> 問題になるでしょう。だからこういう製品が出てきても
> 不思議はないし、まったく売れないとは私も思いません。
> 問題はそれがどれだけ普遍的なのか、です。
ソフトウェアも今は少しずつ海外へ外注され始めました。
人件費の格差だけの理由ならば良いのですが、それだけ
ではないでしょう。
最初からスキルレベルの高い人はいませんが、意識のない
人は、どれだけ経験してもスキルは上がりません。
日本でこのような製品ができたということは、日本の状況を
端的に示していると思います。
あおりはあおりとして、危機感はもったほうが良いのでは
ないでしょうか。
＃ （他業種でもそうかもしれませんが）
Ｃ言語以前の教育が必要になっているのではないか
と思います。
Takashi Yamamura
On 14 May 2002 05:20:48 GMT, in <abq6rg$enn$1...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:
>そういう考えもあるでしょうね。でも「誤読というかへ
>んてこな解釈」ってどれぐらいあります? 私はあまり思
>いつかないな。
いや、目の前にいる人たちに説得するならまだ簡単ですけど、一度そう
いう規約(もどき)を作っちゃうと、社内の人たちでなく、これから入社
する人たち全員この文書を目にする訳ですよね。私も「へんてこな解釈」
って思いつかないけど、こっちが想像を絶することをされた時に、どう
するかなというを考えていたんです。まあ新入社員だったら2chで活躍
している人みたいなのが来ることもあるだろうなと。
# 実際には指導者裁量みたいな形で処理するんでしょうが。
>コーディング規約にも「そういうgotoは禁止」と書いて
>おけばすむと思うのだけど、だめかな? :-)
「いくらでも馬鹿げた事を考えつく人間がいる」という前提に立つと
「こっちの想定した以外のgotoは禁止」って言っても「誰もが想定
しなかったgoto利用の発明」をやっちゃう新入社員/普通の社員がいる
というのに一票。^_^;
で、普通何かの手段なり手法なりを憶える時は、「使うことを憶える」
「使わないことを憶える」「適切な時に使うことを憶える」みたいな
段階があるんじゃないかと思うんですが、gotoなんかの劇薬の場合は、
自由奔放に使った時の副作用がすごすぎて、「使わないことを憶える」
方が先なんじゃないか。ある程度経験を積まなきゃ扱えない毒だと思
うんです。(毒も使い様で便利なことがあるけど、経験のない人が
思いっきり使ったら危険。)
で、逆に普通の方法だとエレガントに表現出来なくて困っちゃったとか
相談された時みたいに、本当にgotoの使い方を教える絶好の機会なんてのは
あるんではないかとも思います。で、プログラミングなんて単なる仕事、
エレガントなんか、関係ないよね、という人にはgoto使ってほしくない
なぁ…なんてのはダメ?^_^;
話を元に戻すと「バカは何を考えつくか分かんない」立場に立てば、
そいつが「いや、それはそんなgotoじゃない」とか抗弁しだせば泥沼に
なる訳で、そういうのはCodeing規約を作る立場から避けたいんです。
もっとも幸い私の会社ではそんなことはありませんでしたけど。
# 私の作ったCodeing規約に従う人がほとんどいなかったから
# バカは多いのに抗弁する人がいないという説もあり。(大苦笑)
---------
山村 隆志 「debugは３歩後退、２歩前進、いつまでたっても終らない」
e-mail : vy...@janis.or.jp
WWW page : http://www.janis.or.jp/users/vyama/
Sugihara Yoshimi
> 相談された時みたいに、本当にgotoの使い方を教える絶好の機会なんてのは
> あるんではないかとも思います。で、プログラミングなんて単なる仕事、
> エレガントなんか、関係ないよね、という人にはgoto使ってほしくない
> なぁ…なんてのはダメ?^_^;
なにがエレガントなのかは人によってさまざまですから
goto使えばエレガントになるってのもどうかと思います。
私的にはgotoが書いてあるプログラムって大抵処理が
追っかけにくい気がするかな。
＃考え方や趣味の問題でしょうけど。
Kazuo Fox Dohzono
"Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:
> goto使えばエレガントになるってのもどうかと思います。
> 私的にはgotoが書いてあるプログラムって大抵処理が
> 追っかけにくい気がするかな。
この手の話題で真っ先に思い付く例.
# ビットシフト数が 1 のみで加減算回数を極力減らすなど, 多倍長演算向け
# にカスタマイズしてあります. 大文字の変数が多倍長数です.
/* assume that 0 <= X < 0x40000000 */
int
isqrt (int X)
{
unsigned y1 = 0x40000000, y2 = 0x80000000;
unsigned yr = 0x8000;
int XX = 0, RET = 0;
for (;;)
{
plus_loop:
XX |= y1;
if ((X -= XX) < 0)
goto minus_loop;
RET |= yr;
yr >>= 1;
if (!yr)
return RET;
XX |= y2;
XX &= ~y1;
X <<= 1;
y1 >>= 1;
y2 >>= 1;
}
for (;;)
{
int y3;
minus_loop:
yr >>= 1;
if (!yr)
return RET;
y3 = y1;
X <<= 1;
y1 >>= 1;
XX |= y1;
y2 >>= 1;
if (0 <= (X += XX))
{
XX &= ~y3;
XX |= y2;
RET |= yr;
goto plus_loop;
}
XX &= ~y3;
Yoshiki Kataoka
> ＃そのうち「if もね」とかいわれそうだな
同感。
・・・と思ったら、返事がない
そういう返事もありでしょうな
# 彼の受け答えのスタイルの縮図ですな
Yoshiki Kataoka
> 条件付き goto 文ですよね。＜ switch
その「goto」は、モジュール構造の何を不明瞭にするのですか？
> >＃そのうち「if もね」とかいわれそうだな
>
> そんなこと言いませんのでご安心下さい。
ほう。 それはすごい
Yoshiki Kataoka
Junn Ohta
sy...@pb.ctt.ne.jpさんは書きました。
> ソフトウェアも今は少しずつ海外へ外注され始めました。
> 人件費の格差だけの理由ならば良いのですが、それだけ
> ではないでしょう。
それだけではない、のかな? これはよくわかりません。
> 最初からスキルレベルの高い人はいませんが、意識のない
> 人は、どれだけ経験してもスキルは上がりません。
「スキルが上がらない人」のためにこういう製品を用意
しよう、というのは私には後ろ向きの解決方法であるよ
うに思えます。私なら意識向上を可能にするような教育
やツールの整備を目指したいところですね。もちろんそ
れが簡単なことでないことはわかってますが...。
> 日本でこのような製品ができたということは、日本の状況を
> 端的に示していると思います。
> あおりはあおりとして、危機感はもったほうが良いのでは
> ないでしょうか。
「こんな製品が役に立つようではダメだ」という意味で
の危機感はもってます。:-)
# でもそんなにひどいか、日本?
Junn Ohta
vy...@janis.or.jpさんは書きました。
> 話を元に戻すと「バカは何を考えつくか分かんない」立場に立てば、
> そいつが「いや、それはそんなgotoじゃない」とか抗弁しだせば泥沼に
> なる訳で、そういうのはCodeing規約を作る立場から避けたいんです。
ということは、コーディングスタイルや品質について会
社側からのコントロールが効かないのですか?
新人というかOJT期間の社員については、書いたコード
を誰かがわりとまじめにチェックするでしょう? そのと
きに「こういうコードは書いてはダメ」と教育するのが
私としては本筋のような気がするわけです。
「へんなgotoを使うなよ」というのは、コーディング規
約のようながんじがらめの規則より、もっとゆるい品質
基準として用意すべきだ、という感覚かな。
MAEDA Atusi
> この手の話題で真っ先に思い付く例.
私は、
struct list {
struct list *next;
int value;
};
struct list *p;
for (p = l; p != NULL; p = p->next) {
if (key == p->value) {
見つかった時の処理;
goto found;
}
}
見つからなかった時の処理;
found:
なんてのを良く書きますけども。他の人はリストや配列に関する検索を必ず独
立した関数にするのかな? それともフラグを使う?
;;; 筑波大学 電子・情報工学系(学術情報処理センター)
;;; 前田敦司 (MAEDA Atusi) ma...@cc.tsukuba.ac.jp
BABA Akinori
>
> 私は、
> struct list {
> struct list *next;
> int value;
> };
>
> struct list *p;
>
> for (p = l; p != NULL; p = p->next) {
> if (key == p->value) {
> 見つかった時の処理;
> goto found;
> }
> }
> 見つからなかった時の処理;
> found:
>
> なんてのを良く書きますけども。他の人はリストや配列に関する検索を必ず独
> 立した関数にするのかな? それともフラグを使う?
私の場合、これは以下のようにしてしまいます。
for (p = l; p != NULL && key != p->value; p = p->next)
;
if (p != NULL) {
見つかった時の処理;
} else {
見つからなかった時の処理;
}
こういう書き方ってあまり一般的じゃないんでしょうか?
ちなみに、判定条件が複雑な場合で、それをマクロや関数で表記するのが
不自然だと感じる場合は、gotoを使う方法で書きます。
--
馬場 昭典 (E-mail: b...@aqua.chem.nagoya-u.ac.jp)
名古屋大学大学院理学研究科物質理学専攻理論化学研究室Ｄ３＋＋
IKEDA Kenji
In article <ac7i5n$bo7$1...@news.cc.nagoya-u.ac.jp>,
b...@aqua.chem.nagoya-u.ac.jp (BABA Akinori) writes:
> こういう書き方ってあまり一般的じゃないんでしょうか?
こう書くでしょうけど…
for (p = l; p != NULL; p = p->next)
if (p->value == key)
break;
if (p != NULL) {
見つかった時の処理;
} else {
見つからなかった時の処理;
}
要は、どっちがわかり易いかでしょう。
説明のために単純化してあるとどちらもわかり易いので、この段階では
ケースバイケースとしか言いようがない。
ただ、見つかんなかった時に同じ判定を2回してるってのが気になるのは確か
です。例だと単純比較でしかないですけど、実際にはその判定が重たい処理に
なる場合だってあります。
見つからない確率がそこそこあって、そこでの効率が云々されなきゃいけない
なら、一般的とかわかり易いとかいう問題ではなくなっていきます。
# singly-linked list の終了判定が重たくなることがあるとは思ってませんけどね。
--
池田研二 稲城駅前在住
Sugihara Yoshimi
BOOL bSearch=TRUE;
p=l;
while(p != NULL && bSearch){
if(p->value == key){
bSearch=FALSE;
}else{
p=p->next;
}
}
if(!bSearch){
見つかった時の処理;
}else{
見つからなかった時の処理;
}
> ただ、見つかんなかった時に同じ判定を2回してるってのが気になるのは確か
> です。例だと単純比較でしかないですけど、実際にはその判定が重たい処理に
> なる場合だってあります。
これだと判定は1回ですみますね。
Sugihara Yoshimi
"Kazuo Fox Dohzono" <doh...@hf.rim.or.jp> wrote in message
news:ac2nj9$2481$1...@news2.rim.or.jp...
unsigned y1 = 0x40000000;
unsigned y2 = 0x80000000;
unsigned yr = 0x8000;
int XX = 0;
int RET = 0;
while(yr > 0){
bLoop=TRUE;
while(yr > 0 && bLoop){
XX |= y1;
if ((X -= XX) < 0){
bLoop=FALSE;
}else{
RET |= yr;
yr >>= 1;
if (yr > 0){
XX |= y2;
XX &= ~y1;
X <<= 1;
y1 >>= 1;
y2 >>= 1;
}
}
}
bLoop=TRUE;
while(yr > 0 && bLoop){
int y3;
yr >>= 1;
if (yr > 0){
y3 = y1;
X <<= 1;
y1 >>= 1;
XX |= y1;
y2 >>= 1;
if (0 <= (X += XX)){
XX &= ~y3;
XX |= y2;
RET |= yr;
bLoop=FALSE;
}else{
XX &= ~y3;
}
}
}
}
return RET;
単純に組みなおしただけ
あってるとおもうけど・・・（汗
＃もう少し煮詰めればもっとまとまると思うけど
Junn Ohta
noro...@mob.or.jpさんは書きました。
> こう書くでしょうけど…
> for (p = l; p != NULL; p = p->next)
> if (p->value == key)
> break;
> if (p != NULL) {
> 見つかった時の処理;
> } else {
> 見つからなかった時の処理;
> }
私もふつうはこれかな。1回しか行わない処理がネスト
の深いところにあるとわかりにくいと思うので。
> 要は、どっちがわかり易いかでしょう。
> 説明のために単純化してあるとどちらもわかり易いので、この段階では
> ケースバイケースとしか言いようがない。
そうですね。
> 見つからない確率がそこそこあって、そこでの効率が云々されなきゃいけない
> なら、一般的とかわかり易いとかいう問題ではなくなっていきます。
効率を考慮しなければならないなら、ほかにもいろいろ
な手管を試みる価値があるでしょうね。
リストがじゅうぶん長くて終了判定のコストが気になる
なら、リストの末尾に番兵をたてて同値判定だけでルー
プを終了させることもあります。
値の大小比較が可能で、しかも同値判定にコストがかか
るなら、リスト生成時によぶんなコストをかけてvalue
がソートされたリストを作っておくかもしれません。そ
うすれば同値判定回数の期待値が半分になるわけです。
リスト探索回数が非常に多いのなら、場合によってはリ
ストを配列に変換して二分探索が可能なように作り換え
るかもしれません。
すでにgotoの話ではないですね。(^^;
Kazuo Fox Dohzono
IKEDA Kenji <noro...@mob.or.jp> writes:
> ただ、見つかんなかった時に同じ判定を2回してるってのが気になるのは確か
> です。
Knuth の Structured Programming with goto statement にはまさにこういう
例が「goto を使うべきケース」として登場しますね.
Kazuo Fox Dohzono
がこういうコーディングだったはずです. とはいえ私は先輩から話を聞いただ
けで見たことはないんですけど.
# 何処かで手に入ったりするのかな? 確か以前久野さんがこのコードについて
# 触れられていたような….
goto を無くすのだけが目的なら, 出発点のコードには登場しません.
for (;;)
{
XX |= y1;
if (XX <= X)
{
X -= XX;
RET |= yr;
}
yr >>= 1;
if (!yr)
return RET;
XX |= y2;
XX &= ~y1;
X <<= 1;
y1 >>= 1;
y2 >>= 1;
}
これだけなのに何故あのようなコーディングになっているのかというと, 比較
と減算はほとんど同じ処理なのに同じことを二度やるのは勿体ないからです.
# 多倍長数だとホントにそれが実感できる.
で, 実はあのコーディングのままでも goto を排除出来ます.
for (;;)
{
XX |= y1;
if (0 <= (X -= XX))
{
XX |= y2;
RET |= yr;
}
else
{
for (;;)
{
int y3 = y1;
X <<= 1;
y1 >>= 1;
yr >>= 1;
XX |= y1;
if (!yr)
return RET;
y2 >>= 1;
if (0 <= (X += XX))
{
XX &= ~y3;
XX |= y2;
RET |= yr;
break;
}
XX &= ~y3;
}
}
XX &= ~y1;
X <<= 1;
y1 >>= 1;
yr >>= 1;
if (!yr)
return RET;
y2 >>= 1;
Hisao Aoyama
> fj.comp.lang.cの記事<868z6gwh...@poe.mob.or.jp>で
> noro...@mob.or.jpさんは書きました。
> > こう書くでしょうけど…
> > for (p = l; p != NULL; p = p->next)
> > if (p->value == key)
> > break;
> > if (p != NULL) {
> > 見つかった時の処理;
> > } else {
> > 見つからなかった時の処理;
> > }
>
> 私もふつうはこれかな。1回しか行わない処理がネスト
> の深いところにあるとわかりにくいと思うので。
私は，
for (p = l; p != NULL && p->value != key; p = p->next)
;
(以下略)
ループ終了の判定が分散するのがいや，goto でないふり
をしている break，continue が嫌いという理由です．
ここから本題...
> リスト探索回数が非常に多いのなら、場合によってはリ
> ストを配列に変換して二分探索が可能なように作り換え
> るかもしれません。
規模が小さいならそのような選択をします．
サーチするときポインターの dereference が少ないのが
良いと思うからです (実測してませんが)．
# うちでは「剥がす」と言っていますが，本当は
# dereference を日本語で何と言うのでしたっけ?
規模がある程度大きくなって，リストをメインテナンスしなが
らサーチする場合は，データのコピーが気になりますから，
バイナリツリーを使います．
思う通りの性能が出ないと，何らかの方法でバランスさせたバ
イナリツリーを使います (お気に入りは red and black)．
----
Hisao Aoyama 青山 尚夫
ASTEC Products, Inc. （株）アステック・プロダクツ
aoy...@astec.co.jp
ku...@gssm.otsuka.tsukuba.ac.jp
> # うちでは「剥がす」と言っていますが，本当は
> # dereference を日本語で何と言うのでしたっけ?
私は「たどる」とか言いますけど、正式には「デレファレンス」なん
でしょうね。「脱参照」なんていう堅い言葉もあったような。
> 規模がある程度大きくなって，リストをメインテナンスしながらサー
> チする場合は，データのコピーが気になりますから，バイナリツリー
> を使います．思う通りの性能が出ないと，何らかの方法でバランスさ
> せたバイナリツリーを使います (お気に入りは red and black)．
せっかくリストなんだからskip listでは? 久野
Kazuo Fox Dohzono
doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
> > ただ、見つかんなかった時に同じ判定を2回してるってのが気になるのは確か
> > です。
>
> Knuth の Structured Programming with goto statement にはまさにこういう
> 例が「goto を使うべきケース」として登場しますね.
蛇足ですが, この場合は goto を使うことより番人を登場させる方に力が入っ
ていた気がします (といってもオーダまで変わるわけではありませんが).
struct list *p;
struct list *tail, sentinel;
sentinel.value = key;
tail->next = &sentinel;
for (p = l; key != p->value; p = p->next)
;
if (p != &sentinel)
見つかった処理;
else
見つからなかった処理;
tail->next = NULL;
ku...@gssm.otsuka.tsukuba.ac.jp
oh...@src.ricoh.co.jpさん:
> これっすか?
> http://www.fides.dti.ne.jp/~oka-t/cpplab-dereference.html
いやー、そんなに新しい奴じゃなくて…でもどこで見たかは思い出せ
ません。すいません。
しかし「脱酸素剤エージレス」とか連想しますね ^_^; 久野
MAEDA Atusi
> aoy...@astec.co.jpさん:
> > # うちでは「剥がす」と言っていますが，本当は
> > # dereference を日本語で何と言うのでしたっけ?
>
> 私は「たどる」とか言いますけど、正式には「デレファレンス」なん
> でしょうね。「脱参照」なんていう堅い言葉もあったような。
剥がすも時々見ますね。教科書でも見た覚えが。(Adaの和訳規格書だっけな?)
ポインタだと私は「手繰る」と言うことが多いかも。
あとは「間接とる」とか。今は通じるのかな。(いやsubmissionじゃなくて。)
Junn Ohta
ma...@cc.tsukuba.ac.jpさんは書きました。
> 剥がすも時々見ますね。教科書でも見た覚えが。(Adaの和訳規格書だっけな?)
> ポインタだと私は「手繰る」と言うことが多いかも。
私の感覚だとこんなところかな?
はがす: ポインターの先にある実体を取り出す。取り
出される値はポインターではない。複数回の
dereferenceが必要な場合も「はがす」で済
ませることもある。
たどる: 現在のオブジェクトからポインターで指され
た同じタイプのオブジェクトを得る。移動す
るのは視点のほう。
たぐる: 現在のオブジェクトからポインターで指され
た同じタイプのオブジェクトを得る。移動す
るのはデータ構造のほう。
つまり、間接参照されているデータを取り出すのは「は
がす」で、リスト操作は「たどる」か「たぐる」になる
わけです。「たどる」と「たぐる」のどちらを使うかは
データ構造のイメージによります。できあがった木構造
を行ったり来たりするのは「たどる」で、畑からサツマ
イモを引き抜くようにしてほしいデータをずるずる引っ
ぱってくるのは「たぐる」ってとこですかね。
dereferenceそのものは「参照はがし」または「ポイン
ターはがし」と書きそうです。
> あとは「間接とる」とか。今は通じるのかな。(いやsubmissionじゃなくて。)
「関節とる」だったりして。(プロレスか? :-)
Funatsu Kunihiro
> たぐる: 現在のオブジェクトからポインターで指され
> た同じタイプのオブジェクトを得る。移動す
> るのはデータ構造のほう。
関係ないけど、この手の単語を考えているときに私が連想する
のは、tangle ということば。なんとなく似てません？
--
ふなつ
tmp...@entscape.net
tabe
田部です。
１点だけ。
日本人は、やはり
欧米、インド、中国に対して主張が弱い。
＃「主張ってのは言いたい事を言えっ」て事です。
反論がある人は、
どうぞ、新しいスレッドを立てて下さい。
--
以上
見て、勝手使って http://rec.ncos.co.jp
<sy...@pb.ctt.ne.jp> wrote in message news:3CE400C3...@pb.ctt.ne.jp...