K.Maebashi's BBS

センス・オブ・プログラミング読ませて頂きました。 プログラミングにおけるポイントを押さえていていい本だと感じました。 またループに使用する変数i,j,k,...の由来を知ったときは感激でしたね。 ところで本文中でちょっとした誤りだと思われる箇所を見つけました。 goto文について解説しているところで、JavaとC++にはラベル付きbreakが 存在すると記述されていますが、C++では聞いたことがなかったので念のために ISO/IEC FDIS 14882:1998を調べてみました。ところが自分が調べた限り そのような記述は見つかりませんでしたので、ご確認していただけないでしょうか？ 一応自分が参照したFDISのbreakに関する部分を掲載させていただきます。 では失礼致します。 6.6.1 The break statement The break statement shall occur only in an iterationstatement or a switch statement and causes termination of the smallest enclosing iterationstatement or switch statement; control passes to the statement following the terminated statement, if any.

昨晩は飲んだくれてまして反応が遅れました。すみません。 >0～5 の 6通りの数を表現しています。 あっ。 …重ね重ねありがとうございます。(_o_) 修正しておきました。

>えっ! …と思ってやってみたら本当でした。どうもボケていたようです。 >どう直すべきか悩むところですが、正誤表に入れておきます。 : 正) : しかも、0と10、1と9、2と8などは同じ形ですから、実際は5通りの数しか表現していません。 0～5 の 6通りの数を表現しています。 [1] 0 - 10 [2] 1 - 9 [3] 2 - 8 [4] 3 - 7 [5] 4 - 6 [6] 5

> へぇ、そういうものなんですか(おどろき) > TeXの機能に索引に載せる単語を指定すると > 自動で索引作成してくれるような機能があったと思っていたので > そんな感じに改版するたびに全自動で作ってるのかと思ってました。 編集さんが使っているDTPソフトには、そういう機能があるのだろうと思います。 ミスが出ている以上、どこかに手作業が介在しているのでしょうけど。 たとえば、自動生成した索引を手でレイアウトしなおしていて、再生成すると 手作業分がふっとぶから、そこだけ手で直した…とか(想像です)。 > えっ、全ページ出力し直すわけじゃないんですか。 そのようです。例外として、「体当たり学習」では、タイトルとかの背景の luckyがスペルミスしてる、という問題があって(初版発行まえに差し替えを 要求したはずが、印刷会社側のミスで反映されていなかった)、このときは 第2刷の際に全ページ再出力しました。「どうせ再出力するから、直したい ところがあれば言って欲しい」というようなことを言われました。 > きっとワープロ→プリンタ出力の様なイメージで考えちゃ > いけない世界なんですね...(^^;) 数千とか万とか刷る本は、「小部数ではバカ高だが、たくさん刷れば安くなる」 方法で印刷しますから、事前準備の部分にコストがかかるということなんでしょうね。 ># と、いうことは間違え探しも見つけるたびに言うのではなく、 ># 一気に出さないと迷惑なのかしら? (^^;) いえ、修正は増刷のタイミングで行うわけですから、その分のバッファリングは こちらでできます。見つかるたびに報告していただけたほうがありがたいです。

おひさしぶりです。いつもありがとうございます。 >1と9、2と8、3と7、4と6 も同じ指の形になりませんか？　実質は 5。 えっ! …と思ってやってみたら本当でした。どうもボケていたようです。 どう直すべきか悩むところですが、正誤表に入れておきます。 >p.85 図 2-26 コンパイラの出力が「hello.c」になっています。 こちらもご指摘ありがとうございます。 # ここは、念校時に直してもらうようお願いしたのですが、意図とは異なる # 直され方をしてしまったようです。書き方が悪かったかなあ。

>「センス・オブ・プログラミング」買いました。 書名に「!」をつけるのを忘れました。全角か半角かは？ > 1と9、2と8、3と7、4と6 も同じ指の形になりませんか？　実質は 5。 「実質は 0～5」と書いたつもりでした。

「センス・オブ・プログラミング」買いました。 p.60　しかも、0 と 10は同じ指の形ですから、実質は 0～9 までになるでしょう。 1と9、2と8、3と7、4と6 も同じ指の形になりませんか？　実質は 5。 p.85 図 2-26 コンパイラの出力が「hello.c」になっています。

>　索引に関しては、私は、ゲラの段階で、索引に載せるべき単語にマーカーで >印を付ける、という以上の作業はしていません。よって、どのようにして索引が >作られているかどうかは知らないんですよ。 へぇ、そういうものなんですか(おどろき) TeXの機能に索引に載せる単語を指定すると 自動で索引作成してくれるような機能があったと思っていたので そんな感じに改版するたびに全自動で作ってるのかと思ってました。 # TeXは修論のとき以来触ってないから、 # もうどんな機能があったか忘却のかなたですねぇ。 # \frac{1}{2} だったかな? >　増刷の際に自動的に直るということはないと思います。増刷時、ポカが >あったりして直す際は、ページ単位で製版し直しているようです。 >ページ単位でコストが発生するため、「全部作り直す」ということはしないはずです。 えっ、全ページ出力し直すわけじゃないんですか。 きっとワープロ→プリンタ出力の様なイメージで考えちゃ いけない世界なんですね...(^^;) # と、いうことは間違え探しも見つけるたびに言うのではなく、 # 一気に出さないと迷惑なのかしら? (^^;)

> ところで、索引とかは何かのツールで自動生成してると思うので、 > 第2版では直っている、もしくは自動的に直ってしまうかもしれませんが > 一つ間違いを見つけました... 　これもご指摘ありがとうございます。 　まずは編集さんに伝えておきました。 > どうしてこういうことが発生するのかしら?ツールにバグがあるのかな? > ツールで索引作成後に文章を書き足したのでしょうか? 　索引に関しては、私は、ゲラの段階で、索引に載せるべき単語にマーカーで 印を付ける、という以上の作業はしていません。よって、どのようにして索引が 作られているかどうかは知らないんですよ。 # 知っていたとして、ここに書いてよいかどうか、という問題もありますが。 >こういう場合、チェック項目が何個もあるんでしょうけど、 >それを自動化できないのはプログラマとしては歯がゆい感じしません? 　元原稿はLaTeXで書いているので、「3章を参照してください」とか 「p.XXXを参照してください」という類の相互参照は、私が提出する段階では 自動チェックできるんですが、いずれにしても組版すれば変わってしまうので、 あとは編集さんにお任せですね。ゲラを見ると、いろいろこう、歯がゆいことも あるんですが(謎) 　増刷の際に自動的に直るということはないと思います。増刷時、ポカが あったりして直す際は、ページ単位で製版し直しているようです。 ページ単位でコストが発生するため、「全部作り直す」ということはしないはずです。

>> これだけの分量に対して、この程度の量の間違いって言うのは >> 私のプログラムのソースコードとバグの比率と比べて >> かなりいいと思いますが。 >いやあ、プログラムのテストと同じで、現状で見つかっているポカの数が >本当のポカの数を反映しているとは限らないわけでして。 >現状のチェックがぬるいだけで、これから増えるかもしれません。 こういう場合、チェック項目が何個もあるんでしょうけど、 それを自動化できないのはプログラマとしては歯がゆい感じしません? ところで、索引とかは何かのツールで自動生成してると思うので、 第2版では直っている、もしくは自動的に直ってしまうかもしれませんが 一つ間違いを見つけました... 索引(INDEX)中の「副作用」の項目を調べると97ページと書いてありますが 実際には副作用の記述は97ページにはなくて98ページにあるようです。 どうしてこういうことが発生するのかしら?ツールにバグがあるのかな? ツールで索引作成後に文章を書き足したのでしょうか? あ、「プロシージャ」は98ページとなっていますが、99ページにあるようですね。 ずれている場所を細かく調べると、どの文章を書き足したかわかる仕組み?(^^)/

> これだけの分量に対して、この程度の量の間違いって言うのは > 私のプログラムのソースコードとバグの比率と比べて > かなりいいと思いますが。 いやあ、プログラムのテストと同じで、現状で見つかっているポカの数が 本当のポカの数を反映しているとは限らないわけでして。 現状のチェックがぬるいだけで、これから増えるかもしれません。 もちろんそうならないことを祈ってますけれど。

>> ! = >>となっているように見えます ... >編集さんに確認メールを出しておきました。 　回答が来ました。 　結論から言うと、「!が全角になっていた」そうです。 　本文中で感嘆符として使う「!」は、私はいつも半角で書いていますが、 編集の際に全角に統一するらしく、その際、置換しすぎたそうです。 　本多さんご指摘の図を含め、第2刷にギリギリ間に合ったそうです。 　取り急ぎ、ご報告まで。

>　この週末は風邪引いて寝込んでまして、反応が遅れましてすみません。 ご自愛くださいませ。 >　正誤表の方ですが、ちょうど増刷がかかり、通しチェックをしていたので、 >それで見つけたポカと合わせてページを作成しました。 これだけの分量に対して、この程度の量の間違いって言うのは 私のプログラムのソースコードとバグの比率と比べて かなりいいと思いますが。 #まぁ、それは比較対照が悪すぎとも言いますが...(^^;)。 なにしろ、書物の世界はプログラムと違って コンパイラが構文チェックしてくれませんから ほとんど机上デバッグですもんね。

>センスオブプログラミングの95ページに掲載されてる否定演算子(名前うろ覚え) > != >ですが、間にスペースが入って > ! = >となっているように見えます ご指摘ありがとうございます。 確かにそう見えます。私自身、「心の隅にひっかかってた」状態でした。 ただ、 ・私から編集さんに原稿を出すときは、当然電子入稿(テキストファイル)である ・私が出した元原稿では、そんなところにスペースはない ・編集さんのところでわざわざそんなところをいじることはないだろう という判断で、フォントの都合か何かかと思っていました。 でも、別ページを見ると、もっと詰まっているところもありますよね。 編集さんに確認メールを出しておきました。

センスオブプログラミングの95ページに掲載されてる否定演算子(名前うろ覚え) != ですが、間にスペースが入って ! = となっているように見えます

>初めまして。koicと申します。 はじめまして。 >スレ違いでしたらすみません。 とんでもないです。スレッドタイトルそのままです。あああ。 >「センス・オブ・プログラミング!」のページに書かれているISBNが「Java謎+落とし穴徹底解明」のISBNになっております。 修正しました。重ね重ねポカしてましてすみません(_o_)

>P66の繰り上がり計算回路の「OR回路」の記号がAND回路で書かれています。 　ご指摘ありがとうございます。 　この週末は風邪引いて寝込んでまして、反応が遅れましてすみません。 　正誤表の方ですが、ちょうど増刷がかかり、通しチェックをしていたので、 それで見つけたポカと合わせてページを作成しました。 　…が、本多さんのご指摘は、気付いてすぐ編集さんにメールを入れたのですが、 たぶん第2刷に間に合っていないと思います。残念。

初めまして。koicと申します。 スレ違いでしたらすみません。 「センス・オブ・プログラミング!」のページに書かれているISBNが「Java謎+落とし穴徹底解明」のISBNになっております。

P66の繰り上がり計算回路の「OR回路」の記号がAND回路で書かれています。

こんばんは。 > それはそう思います。でもそれはお互い様であるわけで、 > プロジェクトに入ったら、「郷に従え」とは思います。 同意します。 そういうわけで私は新規作成の場合は自分のスタイルで打って コンパイル通ったら括弧の位置を直したりしてます(^-^;) 追加の場合は直してる時間がもったいないので 最初から規約に従ってコーディングしますね。 > 関数の最初のレベルはインデントしない、という規約もあった これってちょっと誤認識しそう(^-^;) 最近は4タブでエディタ横幅が広いのでネストを展開したり、 内部関数化して切り離すほうが現実的かもしれないですね。 # 実はまだ8タブ規約のプロジェクトも健在してます。 そういえば昔は変数宣言だけはインデントしないところは多かったような。 int main(void) { char hoge; int piyo; /*--- 以下略 ---*/ } 処理がどこから始まるかがパッと見で判らないからなんでしょうけど、 私はあまり好きになれませんでした。 > 組み込みとかでもまた話は違うとは思います。 私も組み込みは経験がないので何とも言えなかったり・・・ メモリを節約するなら共用体も有効かも！？ # サーバ系だと怒られそうですが。 グローバル変数は今の時代なら「クラス内static変数にすれば十分」とか 色々な選択ができるので議論が広がりそうですね。 ちなみに未だに残っている80文字制限ですが、 「telnetでシェルスクリプトなどを覗くクライアントがいて折り返すと大激怒される」 という理由のあって渋々やっているプロジェクトがありました。 # もちろん彼らはコードが読めないのですが・・・

>あとスタイルは長年の経験で手が憶えたとおりに打ってしまうので、 >それを変えるのが嫌というのも原因かもしれませんね。実際、変えるの難しいですし。 それはそう思います。でもそれはお互い様であるわけで、 プロジェクトに入ったら、「郷に従え」とは思います。 きっと違う誰かが保守するわけですからね。 ただ、聞いた話ですが、 int main(void) { printf("hello\n"); if (a==0) { printf("world.\n"); } } みたいな感じで、関数の最初のレベルはインデントしない、という 規約もあったそうです。確かに関数の切れ目はコメントなどでわかるから 無駄にインデントを深くしないためには合理的なのかもしれませんが… でも、あんまり一般的じゃない規約はちょっと勘弁してほしい、とも思ったり。 >私もここ何年かで読み手主体で名前をつけるようになりました。（WinAPIの影響かも） WinAPIやJavaのおかげで、最近の世代では長い名前が当たり前になっているかも しれませんね。今あれを本に書くのはちょっと時代遅れだったかも。 >グローバル変数はゲーム系だと良く利用しますし、 >「オープン系ではこう」「でもゲーム系はこう」なんて限定したほうが良いのかな、と思ってます。 組み込みとかでもまた話は違うとは思います。経験がないのであまり語れませんが。 実行環境にメモリがなくても、開発環境のコンパイラが賢ければ、(インライン関数とかで) カバーできる部分もあるのではないか、と思いますが…　Cだと苦しいですかね。

丁度いいタイミングで「ソースを読む」ことに関連するサイトを発見(^-^;) ソースコードを読むための技術 　　http://i.loveruby.net/ja/misc/readingcode.html 引用元： 　　http://d.hatena.ne.jp/oooooooo/20041109#p2 　　→言われてみると確かに、と思いました。 　　　私は他人のソースを読むのは好きです。

>　「中括弧の位置論争」なんかはもう純粋に好みの問題でしかない そうですね。 あとスタイルは長年の経験で手が憶えたとおりに打ってしまうので、 それを変えるのが嫌というのも原因かもしれませんね。実際、変えるの難しいですし。 （変数名、関数名のつけ方にも言えますね） だから私は自分のスタイルでコーディングして、 必要最低限（要は目立ちそうなところだけ）だけ規約どおりに直してます。 >　私は、本にも書いたとおり、「読むとき」の方が重要だと考えているので >あのような記述になりましたが、異なる立場はもちろんあって良いわけで、 私もここ何年かで読み手主体で名前をつけるようになりました。（WinAPIの影響かも） 下手に省略しないので命名も意外と楽ですし、統一が取りやすい感じがします。 逆にcreateをcrtなんて略されると私は思い出すのが面倒だなと最近思ったり・・・ >立場が変われば「変数なんて1文字でいいよね」とか「グローバル変数マンセー」が >正解になることもあるかもしれません。 変数一文字は「y = a * x + b」など明らかに意味が読み取れるなら問題ないでしょうね。 ただ、数学得意な方がこぞってこれをやってしまうと 普通のプログラマが演算ライブラリを弄るのにひと苦労かも(^-^;) グローバル変数はゲーム系だと良く利用しますし、 「オープン系ではこう」「でもゲーム系はこう」なんて限定したほうが良いのかな、と思ってます。

>さっき、X-Wordのサンプルコード(Windows版)をダウンロードしてビビりました。 >xword_ver1.0\maebashi\book\kotsu\xword_ver1.0\src_dos\com\kmaebashi\xword >なんか、一般向けに配布するにしちゃ、やけに階層が深くないですか?(^^;) すみません、単純に、圧縮する際のミスでした。修正しました。 報告ありがとうございました。 ログを見ると、30人ほどの方が既にダウンロードされていたようです。 確認不足でご迷惑をおかけいたしました。

さっき、X-Wordのサンプルコード(Windows版)をダウンロードしてビビりました。 xword_ver1.0\maebashi\book\kotsu\xword_ver1.0\src_dos\com\kmaebashi\xword なんか、一般向けに配布するにしちゃ、やけに階層が深くないですか?(^^;) (kmaebashiという名前のフォルダが2度現れて、階層がループしてるのかと疑いました) 今後、配布するコードを格納するためのフォルダとかを熟慮した結果こうなった...ということかしら? まだ、この本を手に入れてないんですけど、 「普通は、これくらい深い階層で開発するべきなんだ」とか書いてあったりして?

　お買い上げいただきありがとうございます。 >スタイルについては「なぜ相手がそうしているのか」を理解する気があれば、 >話は大荒れになったりしないんだろうといつも思いますけどね(^-^;) ># もしかして雑記はこのための布石とか？ 　そうかもしれません (^^; 　雑記帳の方には、 | 最終的に「好み」や「優先度」の問題に落ち着くようなことは結論は出ませんけど 　と書きましたが、スタイルに関する宗教戦争にもこういう面はあると思います。 　リンク集にも入れている「「いんちき」心理学研究所」の編集後記のページで、 こんな記述があります。 http://2shin.net/neko/ | コップに水が半分あって、「もう半分しかない」と解釈するか | 「まだ半分もある」と解釈するかでどちらが正しいかを議論して | どれだけ意味があるのか。 　「中括弧の位置論争」なんかはもう純粋に好みの問題でしかないと思いますが、 たとえば変数名をどれくらいの長さにするのか、ということであれば、 ソースを「書くとき」と「読むとき」のどちらに重点を置くかで 正しい対応が変わってきます。 　私は、本にも書いたとおり、「読むとき」の方が重要だと考えているので あのような記述になりましたが、異なる立場はもちろんあって良いわけで、 立場が変われば「変数なんて1文字でいいよね」とか「グローバル変数マンセー」が 正解になることもあるかもしれません。

昔のエディタのアルゴリズム（ポインタを逆向きに繋ぎかえる）とかが 掲載されていたので興味を持って買いました。 # 恥ずかしながらその辺り知らなかったもので・・・ かなり現場寄りの要点が書かれていますね。 私も「あー、そうなんだよ。」なんて思いながら読み進めてました。 # 私もこれくらい的確な説明で指導できればなぁ(T_T) スタイルについては「なぜ相手がそうしているのか」を理解する気があれば、 話は大荒れになったりしないんだろうといつも思いますけどね(^-^;) # もしかして雑記はこのための布石とか？

>「「センス・オブ・プログラミング!」のページに戻る」ためのリンクが >「「Java謎+落とし穴徹底解明」のページに戻る」となってますよー(^.-) うわ、ご指摘ありがとうございます。修正しました。 >コピペしたでしょ? 図星です。 この本の中に、「コピペすると後で必ず後悔するよ」ってことが書いてあるのですが、 まさに身をもってそれを実践してしまいました(_o_)

どうでもいいことですが、例題プログラム「X-Word」のページの一番下にある 「「センス・オブ・プログラミング!」のページに戻る」ためのリンクが 「「Java謎+落とし穴徹底解明」のページに戻る」となってますよー(^.-)

>いつも楽しく読ませていただいております。 どうもです。 >なぜなら、面倒臭い作業をしなければならない状況ほど、「思考停止」というのは人を楽 >にしてくれるからです（人間の生理というのはそういうものなんだそうです）。 ええと、プログラマのような「面倒なことを回避できる仕事」ならともかく、 回避できない仕事の人は思考停止もある程度しょうがない、ということでしょうか? うーん、仕事上のことであればそうかもしれませんが、それ以外のことについては どうでしょうか。職種が全てに影響を与えるほど、みんな心血絞って仕事してる わけじゃない気がするんですが。 あと、雑記で書いた「進化論と創造論」のような話なら、それこそ日常生活を 送るには関係ない話です。「神様が創ったんだよ」を丸呑みするよりは、 「おら知らね」の方がずっと誠実な態度だと思えるんですよね。