K.Maebashi's BBS

どうも、はじめまして。 ご質問の件ですが、一般に 「自分が何をしたいのか、きちんと日本語で説明できないうちは、 　プログラムは書けない」 と言えます。(ちょうど「センス・オブ・プログラミング!」にそんなことを書きました。) >引数が文字列で,戻り値がファイルというような形です。 ... >「おにぎり」というキーワードを入力 >↓ >ファイル名がおにぎりというファイルを出力 ここだけ読むと import java.io.*; class Test { File hoge(String path) { return new File(path); } } こんなことがしたいようにも読めますが… File f = Test.hoge("hoge.txt"); と呼び出した後で何をしたいのかが不明ですし。 本当にやりたいことは、ファイル名から「ファイル」を得ることじゃなく、 「そのファイルを読み書きするためのナニモノか」を得ることなんじゃないかなあ、 という気がします(合ってますか?)。 だとすれば、Fileではなく、FileInputStreamやFileOutputStreamを使うことになるでしょう。 このへんのクラスの説明については、JavaのAPIリファレンス http://java.sun.com/j2se/1.4/ja/docs/ja/api/index.html を参照してください。 http://java.sun.com/j2se/1.4/ja/docs/ja/api/java/io/File.html http://java.sun.com/j2se/1.4/ja/docs/ja/api/java/io/FileInputStream.html http://java.sun.com/j2se/1.4/ja/docs/ja/api/java/io/FileOutputStream.html

質問ですー JAVAでプログラムを組もうとしています。 JAVAでは文字列や数字などintなどの変数によって格納できますが、 ファイルを格納するということは、できるのでしょうか？ 例えば 引数が文字列で,戻り値がファイルというような形です。 「おにぎり」というキーワードを入力 ↓ ファイル名がおにぎりというファイルを出力 というような形です。 宜しくお願いします。 プログラム初心者なので、出来もしない事を書いてあるかもしれません。 初歩的なことかもしれませんが宜しくお願いします。 そこも踏まえて宜しくです。。

>これは、この構造体の例よりも もっと合法な使い方である、 >単なる可変長配列を realloc() した場合にも起きる問題ですね。 うーん、たとえば折れ線を表現するときに、 typedef struct { int point_count; Point *point; } Polyline; typedef struct { int point_count; Point point[1]; } Polyline; というふたつの実現方法があって、どちらを使うかを考えたとき、 後者の方法だと、pointの数を増減させるたびにPolylineのアドレスが 変わってしまう、ということを言いたかったのですが。 確かにどちらもrealloc()すればpointの指すアドレスは変わりますが、 「pointはPolyline以外誰も指してないけど、Polylineを指してる奴は いっぱいいる」というケースはたぶんたくさんあって、後者の方が 危険度がかなり高いと思います(程度問題にせよ)。 >この手法は、C99 で合法化されたと考えて良いと思います。 >以下参照: >http://seclan.dll.jp/c99d/c99d04.htm#dt19990726 これはそうですね。 そういえばGCCにも、point[0]と書ける拡張機能がありました。

> このテクニックで可変長配列を実現すると、realloc()で配列を > 拡張したとき、 これは、この構造体の例よりも もっと合法な使い方である、 単なる可変長配列を realloc() した場合にも起きる問題ですね。 例としては、むしろ、pArry[1] みたいなアクセスでまずいことに なることを挙げた方がいいような気がします。 > 微妙です。少なくとも合法と言い切ることはできません。 この手法は、C99 で合法化されたと考えて良いと思います。 以下参照: http://seclan.dll.jp/c99d/c99d04.htm#dt19990726

>「センス・オブ・プログラミング」読ませていただきました。 >読んで良かったと思いました。 はじめまして。読んでいただきありがとうございます。 >ところで、可変長配列について説明(P153)がちょっと足りないのでは？ このテクニックは、私も「ポインタ完全制覇」では説明していますが、 今回の本で必要だったかというとどうかと思います。 Cに特化した話ですし(だからこそ「Cに特有の話」の項になら書いてよいのでは、 というご意見なのだと思いますが)、それに、このテクニックは、使用できる 状況が限定されますし。 このテクニックで可変長配列を実現すると、realloc()で配列を拡張したとき、 構造体本体のアドレスまで変わってしまう可能性があります。 よって、この構造体を指しているポインタがどこかにあるときは、 このテクニックは使えません。 また、可変長配列にできる要素が最後のひとつだけ、という問題もあります。 このテクニックを使う機会は、「その構造体を、連続した塊としてファイルに 吐いたり、ネットワークでどこかに送りたい」というケースに限定されるように 思います。 >Ｃではこれが間違いではありません。---① 微妙です。少なくとも合法と言い切ることはできません。 C-FAQには以下の記述があります。 http://www.kouno.jp/home/c_faq/c2.html#6 | この技巧は人気がある。ただしDennis Ritchieは「Cの実装への | 根拠のない馴れ馴れしさ」と呼んだ。公式な解釈によると上の | 技巧は Cの 規格に厳密には準拠していないと考えられる。 私も同じように思います。が、ほぼ全ての環境で動くと思うので、 移植性を根拠にこれを使うことをためらう必要はないでしょうけど。 >この２点が「Ｃに特有の話」である事で、この説明が足りないと思いました。 補足の形で(Webに)載せた方がよいかどうかは、現在思案中です。

「センス・オブ・プログラミング」読ませていただきました。 読んで良かったと思いました。 特に３章は共感する所が多くありました。 私もコピペやっちゃうんですよね、そして後で後悔してますね。 新人の頃に読めたらもっと何か違っていたかもと思いもしました。 ところで、可変長配列について説明(P153)がちょっと足りないのでは？ 特に「Ｃに特有の話」の部分にかかります。 typedef struct _VARIABLEARRY { int valMaxIndex; char val[1]; // １つの配列のインデックス値は本来０だけが有効。 // char val[0]; の記述はコンパイラの実装により異なる。 }VARIABLEARRY; たとえばこの場合 int maxIndex = 10; VARIABLEARRY *pArry; pArry = malloc( sizeof(VARIABLEARRY) + maxIndex ); pArry->valMaxIndex = maxIndex; pArry->val[1] = 'a'; // 配列のインデックス値が宣言した範囲を超えている。 の表記が許される事です。 BASICでは配列のインデックス値が範囲を超えるとエラーです。 Ｃではこれが間違いではありません。---① また、構造体の最後のメンバを配列にする事でこれが可能である事です。---② typedef struct _VARIABLEARRY { char val[1]; int valMaxIndex; }VARIABLEARRY; とした場合は正しく機能しません。 この２点が「Ｃに特有の話」である事で、この説明が足りないと思いました。

>ところで本文中でちょっとした誤りだと思われる箇所を見つけました。 >goto文について解説しているところで、JavaとC++にはラベル付きbreakが >存在すると記述されていますが、C++では聞いたことがなかったので念のために ご指摘ありがとうございます。 とりあえず手元のStroustrup本で確認しましたが、C++にラベル付きbreakは ありませんね。なぜかは知りませんが勘違いしていたようです。 これは罪の重い間違いだと思います。申し訳ありません。 正誤表に載せておきました。

センス・オブ・プログラミング読ませて頂きました。 プログラミングにおけるポイントを押さえていていい本だと感じました。 またループに使用する変数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」など明らかに意味が読み取れるなら問題ないでしょうね。 ただ、数学得意な方がこぞってこれをやってしまうと 普通のプログラマが演算ライブラリを弄るのにひと苦労かも(^-^;) グローバル変数はゲーム系だと良く利用しますし、 「オープン系ではこう」「でもゲーム系はこう」なんて限定したほうが良いのかな、と思ってます。