K.Maebashi's BBS

お世話になっております、けろ助でございます。 お陰様で風邪も良くなりまして、また勉強に励んでおります。 > あのディレクトリ構成は実際「Web アプリに限定したからこそ」だと思います。 > ていうか私はあれを最初に見たとき、こんなことをフレームワークで決めて欲しくない、 > と思いました。が、ユーザとしては無限の自由度を欲しがりますが、それがかえって > 混乱を招くこともあるわけで、あれはあれでよいのかもしれません。 つたない考えなのですが、これって「『今対象としている問題の領域』をどこに限定し、いかにモデル化する か」というテーマに帰着していくんだと思うんですね。 オブジェクト指向設計の用語では「ドメイン」と呼ぶそうですが。 ドメインの決定とモデル化を上手く行うことが、結局のところ良い設計となる…ということになるのでしょう。 「アルゴリズムとデータ構造」といった、割と枯れたテーマなら、ノウハウや経験則の蓄積も豊富で体系的にま とめられた書籍を気軽に入手して勉強できる程の環境にあると思いますが、上に挙げたテーマは「まだこなれて ないジャンル」であるだけにまだ模索状態なような気がします。 そんな中で、J2EE は一定の成果を上げることができた、と。 今のところ、私はそんな解釈をしています。 > Cが、もし最初から、インデントがいわゆる「K&Rスタイル」になっていないものを > コンパイラのレベルで文法エラーで弾いていたら、スタイルにまつわる宗教戦争は > 発生しなかったわけで。 > # でも、そういうことをツールの設計者がガチガチに決めてしまうと、なんか > # 普及しなさそう、という気もします。 ええ。そういう意味なら、C 言語は、上手いことユーザーのニーズに (今も) マッチした言語ですね。 制限と自由のさじ加減が非常にバランスが良い言語だと思ってます (除：宣言構文)。 「C 言語ポインタ完全制覇」を最初に読んだ時は「殴るんなら James Gosling より Dennis Ritchie だろ」と 思っていた私ですが、Java を本格的に書き始めた今では考えが全く逆ですから (汗)。 で、ツールの制限の話なのですが、実は私、色々な所で悪口を聞く COBOL を嫌いになれません。 COBOL の持つ記述上の制約は、「誰でも、それなりに実用に耐えうるソースを書ける」と信じられていた時代な らではのものだからです。 # 実は私、前の会社でホスト系言語 (COBOL、PLI/I、JCL …等々) の解析プログラムをメンテしてました。 # COBOL はソース記述開始位置等に非常な制約がある言語です。 # また、今では「変態言語」の名は Perl が欲しいままにしていますが、私ならその称号を PL/I に与えたい。 話それました。すみません。 要は、「『作者の設定した自由と制約』が時代やユーザーのニーズとどれだけマッチしているか」、が一番重要 な事項になのだろう、と思った、ということです。 流行る言語なり、ツールなりは、時代に見出されただけであって、後々まで残る方法論とはまた別なのだ、って 事なんです。 前向きに考えるなら「今からでもソフトウェア工学の根本的進歩を目の当たりにできる」と思えるでしょうし、 後ろ向きに考えるなら「なんだ、ソフトウェア工学ってこの程度なのか…」と思える混沌とした時代なのかな…。

>またぞろ風邪がぶり返してきそうです… (鼻水と咳が止まらない…) 何でだろ。 無理されないように。ゆっくり休んでください。 >そうですねぇ…、J2EE は、役割 (ロール) を含め、かなりきっちりとした規定があるようですが、「Web アプ >リに限定したからこそ」という印象が、私にはあるのです。 あのディレクトリ構成は実際「Web アプリに限定したからこそ」だと思います。 ていうか私はあれを最初に見たとき、こんなことをフレームワークで決めて欲しくない、 と思いました。が、ユーザとしては無限の自由度を欲しがりますが、それがかえって 混乱を招くこともあるわけで、あれはあれでよいのかもしれません。 Cが、もし最初から、インデントがいわゆる「K&Rスタイル」になっていないものを コンパイラのレベルで文法エラーで弾いていたら、スタイルにまつわる宗教戦争は 発生しなかったわけで。 # でも、そういうことをツールの設計者がガチガチに決めてしまうと、なんか # 普及しなさそう、という気もします。 > 名前しか知りませんが、Mavenてそーゆーのには役に立たないんでしょーか? これは私も知りませんでした(Jakartaもなんか多すぎ)。勉強しておきます。

前橋さん、iWA さん、早速のレスありがとうございます。 またぞろ風邪がぶり返してきそうです… (鼻水と咳が止まらない…) 何でだろ。 前橋さん> ディレクトリ階層ということなら、JavaによるWebアプリケーションなら、 前橋さん> J2EEによる規定がありますよね。 前橋さん> その他のアプリケーションだと、confとかetcとかdocとか、よく使うディレクトリ名は 前橋さん> ありますが… きっちり規定されたルールというと… どうでしょうか。 そうですねぇ…、J2EE は、役割 (ロール) を含め、かなりきっちりとした規定があるようですが、「Web アプ リに限定したからこそ」という印象が、私にはあるのです。 J2EE はやたら敷居が高いので本をパラパラと読んだだけでの感想ですが…。 前橋さん> プロパティファイルは読みにくいので、今ならXMLの方がよく使われている気がします。 なるほど。Properties クラスの名前空間は階層的ではないですし、そちらが主流なのは良く解ります。 質問の件に限らず、ずっと思っていたことがありまして、今回改めてそれを確認した思いがします。 それは、「言語にせよ、ツールにせよ、その設計思想を体得しないことには充分に力を引き出せない」というこ とです。 言語やツールの成長を初期から追いかけるか、時間と労力を割いて慣れ親しむかしないといけないのでしょうね。 個人的には、作者にその辺りの説明責任があると思うのですが…。 私の場合、C + Make という環境でいたのですが、同じ UNIX 発祥とはいえ、Java + Ant では考え方が随分違う のでかなり面食らいました。 Win + VB から移行するよりは楽なのでしょうけど。 iWA さん> 名前しか知りませんが、Mavenてそーゆーのには役に立たないんでしょーか? さっそく調べてみました。プロジェクト管理ツールだそうですね。 [Jakarta Project のページ] http://www.ingrid.org/jajakarta/turbine/jp/turbine/maven/index.html [Maven を取り上げているサイト・1] http://www.02.246.ne.jp/~torutk/index.html [Maven を取り上げているサイト・2] http://www-6.ibm.com/jp/developerworks/java/030613/j_j-maven.html Eclipse にすら挫折した (手を出すには時期尚早だと感じた) 私ですので、今すぐ Maven を活用できる訳では ないのですが、Maven が持つ「プロジェクトの標準ディレクトリ構成」はかなり参考になりました。 自分でグジグジ環境をいじってたらこのレベルに辿りつくのに半年じゃ効かんですわ…。 レスを下さった皆様、どうもありがとうございました。 Java に関しては完全に独学 (周りに使える人がいない…) で、暗中模索の状態が続いていたのですが、何だか 少し光が差してきたような気がします。

名前しか知りませんが、Mavenてそーゆーのには役に立たないんでしょーか?

>レスが大変遅れまして申し訳ありません (雑事に追われた挙句風邪で４日間も寝込んでて…日頃の行い？)。 おや。お大事に。 >これが、「『とりあえず動けばいいや』的な作りでも何とかなる場合も多い」という意味でしたら同意です。 >だからこそ、Java を使用したアプリケーションの構築には、デザインパターンのように一定のセオリーや経験 >則の蓄積があるはずだ、と思っていたのです。 ディレクトリ階層ということなら、JavaによるWebアプリケーションなら、 J2EEによる規定がありますよね。 その他のアプリケーションだと、confとかetcとかdocとか、よく使うディレクトリ名は ありますが… きっちり規定されたルールというと… どうでしょうか。 Cに関しては、GNUプロジェクトには規約がありますが、configureを前提にされると 辛い、ていうか嫌。 http://www.sra.co.jp/wingnut/standards-j_toc.html#Managing%20Releases >が、Java には、Java 実行環境内からのみ参照できる環境変数もどきの「プロパティ」というものがありますか >ら、設定ファイルの値はプログラム内から読み込むというのが普通 (らしい) です。 プロパティファイルは読みにくいので、今ならXMLの方がよく使われている 気がします。

前橋さん、本多さん、レスありがとうございます。 レスが大変遅れまして申し訳ありません (雑事に追われた挙句風邪で４日間も寝込んでて…日頃の行い？)。 こちらでお二人にまとめてレスしようと思います。 前橋さん> いやあ、このあたりは、最近はかなり「若い奴にお任せ」してる部分が大きいので、 前橋さん> 私がこの方面に詳しいかというとそんなことはないと思います (^^; ガーン。そうなのですか…。 前橋さん> 詳しくないなりに思うところを書きますが、こういうのはアプリケーションと 前橋さん> 環境により千差万別なわけですが、実はプログラマが仕事で書くプログラムの 前橋さん> 95%は特定顧客からの受注アプリケーションだという現実があって(※1)、 前橋さん> その場合、特に相手がUNIXワークステーションだったりすると環境はかなり 前橋さん> 限定できますから、「ディレクトリまるごとtarで固めてインストール先で展開。 前橋さん> パスは全て絶対指定」みたいなやり方でもなんとかなっちゃう、という面はあると 前橋さん> 思います。 前橋さん> Windows環境ではさすがにそういうのは避けるべきかと思いますが(PCはきっと 前橋さん> 他のことにも使うので)、業務用の特注アプリケーションだと、Cドライブにしか 前橋さん> インストールできなくてもさほど問題にはならなかったりします。 これが、「『とりあえず動けばいいや』的な作りでも何とかなる場合も多い」という意味でしたら同意です。 例えば、実行モジュールと設定ファイルが同一ディレクトリに置く、なんてことはマトモなアプリケーションで ならやってはいけないことだと思いますが、動かそうと思えば動くわけですし…。 前橋さん> 一般に配布するのでどこでも動くようにしたい、と考え出すと、途端に難しく 前橋さん> なりますよね。Cの場合、かつては#ifdef __SOLARIS__ とか書いてましたが 前橋さん> これはひどいということでautoconfみたいなのが出てきましたけどconfig.hに 前橋さん> 頼ってたらテストが大変(というか不可能)という状況には変わりなく、 前橋さん> 結局は、(Javaが本質的にそうであるように)最初からどこでも動くように書くのが 前橋さん> 正しいのでしょう。 私もそう思います。 だからこそ、Java を使用したアプリケーションの構築には、デザインパターンのように一定のセオリーや経験 則の蓄積があるはずだ、と思っていたのです。 が、お話を聞く限りそういう類のものは無いようですね…。 本多さん> Javaはよくわかりませんが、私はX関係とかで一般に公開されている 本多さん> かなり熟練されている人たちが作ったと思われるプログラムの 本多さん> ディレクトリ構造とかを真似してみたりしてます。 こういうノウハウは、まだ誰もドキュメントとして体系的にまとめてはいないのでしょうね。 X 関係ですか…へっぽこな私には厳しそうだ…。 …と、ここまで考えて、「アプリケーションの構成法を一般的な形に体系化するのは実は無理があるのではない か」と思えるようになってきました。 設定ファイルの読み込み方ひとつ取っても、C だと設定ファイルに記述された値を環境変数に代入し、シェル上 でコマンドに引数として渡すのが普通 (らしい) です。 が、Java には、Java 実行環境内からのみ参照できる環境変数もどきの「プロパティ」というものがありますか ら、設定ファイルの値はプログラム内から読み込むというのが普通 (らしい) です。 パスの指定にしても、C ならカレントディレクトリからの相対指定が可能なのに、Java は基底ディレクトリか らの相対指定しかできませんし…。 Make と Ant では、もう基本にある考え方そのものが違うという気がします。 でもなぁ…せめて個別のビルドツールについて、その設計思想を解説した本やサイトくらいあっても良さそうな ものだとやっぱり思うのですよ。

tasaedaです。ご返信ありがとうございます。 >正直、私としてはあまりこういう質問が来ることは想定していなかったのですが、 私もちょっと筋違いかなとは思ったのですが、引用については様々な本や記事で話題に なっていますし、少しでも自信がなければ（私自身経験不足ですから）しっかり確認を とっておいた方が良いだろうと思いまして。 >ということで、数ページ程度の引用でしたらまったく問題ありません。 なるほど、承知しました。一つの基準として覚えておきます。もっとも数ページも引用 してしまっては、私程度の筆力では間違いなく「主従の関係」が逆転してしまいそうです。 >もし必要でしたら、該当部分の電子ファイルをお送りしますが、どうしましょうか? それは大変助かります。本の文章をネットで掲載するには、自分でキーボードを叩か ねばなりませんしね。（私は遅筆なものですから） ではご厚意に甘えてメールを出させていただきますので、いつでも結構ですからご返信 いただければ幸甚です。 過分なご配慮、ありがとうございました。

>前橋様、皆様、初めまして。tasaedaと申します。 はじめまして。 >そういうわけですので、差し支えなければ前橋さんからの引用に関しての注意点や >不都合とお考えになることについて、お教えいただけたらと存じます。 状況は了解いたしました。 正直、私としてはあまりこういう質問が来ることは想定していなかったのですが、 私自身の都合からすれば、その引用を読んで「もう本は買わなくてもいいや」と 思う人さえ出て来なければ差し支えないわけです(おそらく出版社さんとしても)。 具体的には「1章まるごと」とかの転載をされなければ問題ないと思います。 1ページ程度であれば全然問題ないです。 また、引用部分を読んで、「こんなクソ本買うのやめた」と思う人がいたとしても、 それは仕方がないと思います(立ち読みでも発生し得る話ですし)。 本来、この本を読んでメリットを受ける人が(仮にいるとして)、その引用部分を読んで、 目的を達成してしまうと、私としては(経済的に)嬉しくないわけですけど、 1ページやそこらはもともと立ち読みできる範囲内ですから。 ということで、数ページ程度の引用でしたらまったく問題ありません。 引用した上でボロクソにけなそうがかまいません(再反論はするかもしれませんけどね) ので、ご自由にしてください。 もし必要でしたら、該当部分の電子ファイルをお送りしますが、どうしましょうか? もっとも私の手元にあるのは編集さんの手が入る前の、著者校正もしていないものだけ ですから、漢字の使い方が違っていたり誤植があったりしますけれど。 必要でしたら、そう言っていただければ、1/10中にはメールで送れると思います。

前橋様、皆様、初めまして。tasaedaと申します。 プログラミングに関する話題ではないのですが、掲題に関する質問がございますので 投稿させていただきます。 私のホームページでは雑文のようなものを書いているのですが、近日中の日記に前橋 さんの「センス・オブ・プログラミング」から一部を引用させていただこうと考えて おります。 具体的には、今のところP.10の24行目からP.11の15行目くらいまでを想定しています。 ただ読み始めて間がないので、他に感銘を受けた箇所を見つけた時は、もう少し増える かもしれません。 引用の理由ですが、プログラミングに関することでは全くございません。最近「抽象」 についての駄文を書いているとき、偶然手元にある貴著を拝読し、「これは自分の 考えにピッタリだ！」と思いましたので、早速日記に書こうと思いました。 ただ、引用部分が少々長くなりそう（あるいは増えそう）だな、と感じましたので、 これは前もって著者様に確認しておいた方がよいと判断し、この度お伺いを立てた 次第です。 そういうわけですので、差し支えなければ前橋さんからの引用に関しての注意点や 不都合とお考えになることについて、お教えいただけたらと存じます。 無論、文化庁の言う「引用における注意事項」は当然守りますが、それ以外に留意 して欲しいことがございましたら、ということです。 以上、宜しくお願いいたします。 追記：前橋さんの本には「C言語 ポインタ完全制覇」以降全てお世話になっており ます。もう何年もたちますが「最後は本人次第だなぁ」と痛感しております（苦笑）

ISO C99はすっかり頭から抜け落ちていたので、今調べなおしました (^^; >int32_t を生で使うのがアレなのは賛成ですが、 >typedef int32_t CustomerID; のようにして >int ではなく CustomerID を使うってのは OK >なんですよね？ 私の主張は「低レベルな概念をわざわざアプリケーションにばらなくな」 ということなので、CustomerIDを使うのであれば問題ないと思います。 ただ、ISO C99を前提にするのなら、CustomerIDなら、int_least32_tの 方が移植性が高そうには思います。 が、「どの環境でも同じようにバグって欲しい」とか、 「バイトオーダーがある程度限定されてもよいから生データでやりとりしたい」 とかの状況も当然あるとは思います。移植性という点ではどちらもなんとも 中途半端だと思いますが、全面否定はできません。 >int32_t の定義されてない古い処理系上で、 >上の CustomerID のような typedef を行うために、 >アプリケーションで「typedef int int32_t;」するのも >OK なんですよね？ 上のような意図なので、これもOKですね。 いつもながら軽率な表現ですみません(ご指摘ありがとうございます(_o_)) 意図としてはそのあたりだとご理解くださいませ。

一応、念のため確認です。 int32_t を生で使うのがアレなのは賛成ですが、 typedef int32_t CustomerID; のようにして int ではなく CustomerID を使うってのは OK なんですよね？ あと、int32_t は既に C言語標準に含まれているので、 基本的にはアプリケーションで定義する必要はないわけ ですが、int32_t の定義されてない古い処理系上で、 上の CustomerID のような typedef を行うために、 アプリケーションで「typedef int int32_t;」するのも OK なんですよね？

>> 私は特殊なソフトウエアを作ってる場合が多いので、あれですけど、 >> 色々な環境からハードウエアを直に叩く様なアプリケーションを >> 作っていて、そういう時整数型のビット数とかは非常に重要になっていたりしますが。 >もちろんそういう低レベルな階層を意識しなければならないケースでは、 >ビット数を意識する必要があると思います。それでもできるだけ階層化して、 >下の方に押し込めたいところですが。 私の感覚が特殊な状況にあったようですね。 私の作るアプリケーションが いわゆるICデバイスを生で扱うためのもので、 最上位...つまりユーザインターフェイスにまでビット数やら 各ビットの01情報が見えないといけないという「超特殊」なモノ... 私が特殊な環境のプログラムばかり作っているってことを忘れてました(^^;) しかも、私の環境がWindows⇔UNIXという移植性は(あまり)考える必要がないので バイトオーダと言うことも考えから抜け落ちてました。 そうですねぇ。一般の例えばワープロとかで、使うintが何bitか なんて概念が残ってる必要はないですよねぇ。

件名を変えました。 >># そういう意味で、typedef int int32_t; みたいなのは、少なくともアプリケーション >># プログラムとしては、方向性が間違ってると思う。 … > 一般のアプリではビット数なんか気にしないで作らんとあかんって言うことでしょうか? まあ、簡単に言ってしまえばそういうことです。 > でも、ファイルフォーマットとかでやっぱりビット数って重要になりそうですが。 ファイルにデータを吐き出したいのなら結局バイト列まで面倒を見なければ いけないでしょう。int32_tを、32bitだからってそのままファイルに吐いてたら、 バイトオーダーの問題さえ解決できません。まあ、バイトオーダー(とか負の数の 表現方法とか)が同じ環境に限り移植性が高い、というだけでもメリットは もちろんあるので、全面的に否定はしませんが。 コンピュータの世界では、実に色々な概念が階層的に構成されていて、 ハードに近い「低レベルな」概念を、より抽象的な概念で隠す、という層の 積み重ねになっています。が、typedef int int32_t; は、より低レベルな階層を 剥き出しにする方向の定義になっている。これじゃあ向きが反対です。 その意味で、私は、Javaな人が、「Javaでは、Cなんかと違い、intとかの データ型のサイズがきちんと規定されているから良い」という主張が理解できません。 「intは最低限いくつからいくつまでの数を表現できる」という規定があれば (本来は)十分じゃないでしょうか。実際、Cの規格ではそれは保証していますし。 # intが3万ちょっとであふれるのは嫌だ、ということなら、「俺のプログラムは # intが32ビット以上の環境だけを対象とする」と言ってもよいでしょう。 2147483647に1足すと-2147483648になる、なんてことを仕様で保証しても、 「どの環境でも同じようにバグる」ことが保証できるだけでしょう。 現実問題としては「どの環境でも同じようにバグる」と助かるのは確かですが、 そういう意味で利便を図るなら、実行時エラーにする(できる)ほうが 筋が通ってますよね(C#のように)。 > 私は特殊なソフトウエアを作ってる場合が多いので、あれですけど、 > 色々な環境からハードウエアを直に叩く様なアプリケーションを > 作っていて、そういう時整数型のビット数とかは非常に重要になっていたりしますが。 もちろんそういう低レベルな階層を意識しなければならないケースでは、 ビット数を意識する必要があると思います。それでもできるだけ階層化して、 下の方に押し込めたいところですが。

あけまして おめでとうございます。 少し趣旨の異なる質問ですが ># そういう意味で、typedef int int32_t; みたいなのは、少なくともアプリケーション ># プログラムとしては、方向性が間違ってると思う。 この方向性が間違っていると言うのは, どういうことを意味してるのでしょう? int32_tみたいな型を利用するのは、けっこう便利だと思うのですが。 一般のアプリではビット数なんか気にしないで作らんとあかんって言うことでしょうか? でも、ファイルフォーマットとかでやっぱりビット数って重要になりそうですが。 私は特殊なソフトウエアを作ってる場合が多いので、あれですけど、 色々な環境からハードウエアを直に叩く様なアプリケーションを 作っていて、そういう時整数型のビット数とかは非常に重要になっていたりしますが。 >>ビルドについて詳細に取り上げている書籍、もしくはサイトをご存知の方、ご教授願います。 >これは私も知りたいです。詳しい方、よろしくお願いいたします。 Javaはよくわかりませんが、私はX関係とかで一般に公開されている かなり熟練されている人たちが作ったと思われるプログラムの ディレクトリ構造とかを真似してみたりしてます。 まぁ、新規に作り始めることが少ないので、 既にある環境で何も考えずに やってることがほとんどですが。 なんつうか、頭を使わない私なのでした。

>皆様初めまして、ＨＮ「けろ助」と申します。 はじめまして。 >ビルドを効率的、柔軟に行えるようにするには、makefile (make)、build.xml (ant) の記述ノウハウはもちろ >んのこと、ディレクトリ構成等も慎重に考えて設計しなくてはならないように思います。 いやあ、このあたりは、最近はかなり「若い奴にお任せ」してる部分が大きいので、 私がこの方面に詳しいかというとそんなことはないと思います (^^; 詳しくないなりに思うところを書きますが、こういうのはアプリケーションと 環境により千差万別なわけですが、実はプログラマが仕事で書くプログラムの 95%は特定顧客からの受注アプリケーションだという現実があって(※1)、 その場合、特に相手がUNIXワークステーションだったりすると環境はかなり 限定できますから、「ディレクトリまるごとtarで固めてインストール先で展開。 パスは全て絶対指定」みたいなやり方でもなんとかなっちゃう、という面はあると 思います。 Windows環境ではさすがにそういうのは避けるべきかと思いますが(PCはきっと 他のことにも使うので)、業務用の特注アプリケーションだと、Cドライブにしか インストールできなくてもさほど問題にはならなかったりします。 一般に配布するのでどこでも動くようにしたい、と考え出すと、途端に難しく なりますよね。Cの場合、かつては#ifdef __SOLARIS__ とか書いてましたが これはひどいということでautoconfみたいなのが出てきましたけどconfig.hに 頼ってたらテストが大変(というか不可能)という状況には変わりなく、 結局は、(Javaが本質的にそうであるように)最初からどこでも動くように書くのが 正しいのでしょう。 # そういう意味で、typedef int int32_t; みたいなのは、少なくともアプリケーション # プログラムとしては、方向性が間違ってると思う。 Javaではそういうところは改善されているはずが、Webアプリ構築のために アプリケーションサーバを導入すると移植性なんかどっか行っちゃったりしますし、 JDKのバージョンに泣かされることもあります。 「Tigerはいつになったら仕事で使えるんだろう?」 「あと数年は無理じゃないですかねえ」 という会話を、まさに今日、同僚としてました。 >ビルドについて詳細に取り上げている書籍、もしくはサイトをご存知の方、ご教授願います。 これは私も知りたいです。詳しい方、よろしくお願いいたします。 ※1「魔法のおなべ」より http://cruel.org/freeware/magicpot.html

皆様初めまして、ＨＮ「けろ助」と申します。 職業プログラマ歴３年と９ヶ月のまだまだへっぽこです。 前橋さんのファン歴（？）は「Java 謎＋落とし穴」発刊以来ですから丸３年くらいでしょうか。 で、いきなりですが質問なのです。 本格的なアプリケーションを作る場合、「ソースを書いてコンパイルする」だけではなく、「リリース用のファ イルセット (実行モジュールや設定ファイル等の集合) を作成する」という作業も必要になってくると思います。 そして世間一般ではこの作業を「ビルド」と言い習わしているようです (正確な定義は良く認識できていません。 コンパイル～リリース用ファイルセット作成までの、一連の作業を「ビルド」と言っている場合もあれば、個別 の作業行為を「ビルド」と言っている場合もあるからです)。 ビルドを効率的、柔軟に行えるようにするには、makefile (make)、build.xml (ant) の記述ノウハウはもちろ んのこと、ディレクトリ構成等も慎重に考えて設計しなくてはならないように思います。 プログラマにとってデータ構造やアルゴリズムと同程度に重要な話題に思えるのですが、参考になる書籍やサイ トが見つからずに困っております。 ビルドツールの使い方そのものについては充分な情報が得られるのですが…。 ビルドについて詳細に取り上げている書籍、もしくはサイトをご存知の方、ご教授願います。 特に Java＋ant に向いた情報を必要としています。 「自分は大抵こんな構成で作ってる」「このオープンソースの設計が参考になる」「そんなものはプログラマの 基本教養じゃ。この青二才め」等、何でも構いません。 よろしくお願いします。 個人的には、前橋さんに「本格的なアプリケーションの構築技法」の本を出していただきたいな…と思っていた りするのですが。

Perlに詳しいわけではありませんが、故あって最近Perlのソースを眺めたりも してるので、ちょっと調べてみました。 >perlの場合、関数の引数は全て配列(@_)として扱われます。なので、この場合は、 >一つ目の%sには$_[0]が、二つ目の%sには$_[1]が、三つ目の%sには$_[2]が入ります。 Perlで記述された関数についてはその通りでしょうが、今回のケースのsprintfは Perl組み込みの関数ですから、Cで書かれた実装部分に引数の数が渡っているかどうかが 問題では? で、5.8.6のソースから探したところ、どうもsv.cのPerl_sv_vcatpvfnが sprintfの実装のように見えます(1000行近い巨大関数。sprintfじゃあ しょうがないですが)。 void Perl_sv_vcatpvfn(pTHX_ SV *sv, const char *pat, STRLEN patlen, va_list *args, SV **svargs, I32 svmax, bool *maybe_tainted) doop.cのPerl_do_printf()から追跡すると、このsvmaxが、引数の数のように見えます。 printfかましてminiperlを再構築し、確認しましたが、実際に引数の数が渡って きているようです。 が、この関数の中でsvmaxをどう使っているか見てみると、 if (svix < svmax) { というように「svmaxを超えてないか?」というチェックは何箇所かでしてますが、 上記の箇所でもelse節はなかったりするので、そのために何も起きないんじゃ ないでしょうか。

あけましておめでとうございます。今年もよろしくお願いいたします。 しばらくごぶさたしてましてすみません。 この年末は、風邪ひいて寝込むわ、紅茶ひっくり返して太ももをやけどするわで、 ただでさえ短い正月休みの前半は寝ている間に終わってしまいました。 Webページの更新を含め、やりたいことはいろいろあったはずなので、 3が日の間にぼちぼち進めるつもりです　　　…無理かも。断酒も明けたし。 なお、正月バージョンの壁紙は、 「へなちょこ愚連隊」 http://www6.wind.ne.jp/hena/index.html からお借りしました。

>Perlのようなインタプリタ型の言語は、なぜエラーにならないのでしょうか？ インタプリタだから、ではなくて、perlの言語仕様的な問題です。 perlの場合、関数の引数は全て配列(@_)として扱われます。なので、この場合は、 一つ目の%sには$_[0]が、二つ目の%sには$_[1]が、三つ目の%sには$_[2]が入ります。 このとき、Cあたりだと配列長を超えたらそのままバッファオーバーラン、Javaだと 例外が投げられますが、perlの場合は読むときはundefが返り、書くときは自動で 配列長が拡大されます。 今回の場合は、$_[2]を読もうとして返ってきたundefが文字列化されて空文字列 扱いになったわけです。

>>externで「外部にあるよ！」と宣言してるにも関わらず、 >「プログラマの意図」はそうなのかもしれませんが、言語規格書の主張は違います。 >3.5-6 で、こういう宣言を行うと hoge() は内部結合のままだと書かれています。 ふむふむ。C++だとそう記述があるのですね。 ありがとうございます。

御指摘ありがとうございます。 >sprintf は「可変個引数」な関数です。 >固定な引数＝必ず必要な引数、が無いとエラーになりますが、 >可変個数部分＝有るか無いかは状況次第、が過不足していてもエラー検出することはできません。 >原理的に不可能。 申し訳ありません。すっかり忘れていました。 （前橋さんの本などで、話題になっていたのに・・・） printf系の関数は実引数が不足しているときの動作は未定義でしたね。 >C/C++ では上記コードのエラー検出はされません。 確認せずに記述してしまいました。（VC++でも検出しませんでした） 大変お騒がせ致しました。 （件名のインタプリタとコンパイラとは一切関係ありませんでした (;_;) ）

>my $string = sprintf("%s %s %s\n", $day, $message); perl はぜんぜん知りませんが、この sprintf が C の sprintf と同じ機能と仮定して： C/C++ では上記コードのエラー検出はされません。 sprintf は「可変個引数」な関数です。 固定な引数＝必ず必要な引数、が無いとエラーになりますが、 可変個数部分＝有るか無いかは状況次第、が過不足していてもエラー検出することはできません。 原理的に不可能。 # GNU CC では printf 系関数のフォーマット引数が文字列リテラルな場合に限り、 # 個数や形の不一致を検出してくれますが、一般的には無理。

とりあえず以下 C++ の話に限定 (ISO/IEC 14882:1998) 。 # C 規格書はウチに帰r) >externで「外部にあるよ！」と宣言してるにも関わらず、 「プログラマの意図」はそうなのかもしれませんが、言語規格書の主張は違います。 3.5-6 で、こういう宣言を行うと hoge() は内部結合のままだと書かれています。

いつも楽しく拝見しています。 久しぶりに投稿します。konです。 質問なんですが、 共通機能でログを作成する機能をPerlで作成する事になりました。 その際、ログファイルに情報を1行ずつ書くのですが 必ず最後にスペースが入って改行される現象がありました。 原因は my $string = sprintf("%s %s %s\n", $day, $message); 上記のコードで、2番目の%sの後のスペースが表示されて、3番目の%sが引数のエラー にならない事が分かりました。 Ｃなどのコンパイラ型の言語なら、コンパイルエラーになりますが Perlのようなインタプリタ型の言語は、なぜエラーにならないのでしょうか？ （strictはいれてますが、ワーニングにもなりません） Perlのマスターが言うには、”Perlはアバウトだからね”と意味不明（論理的でない？） 回答が返ってきました。私も、あまりPerlをやっていないのでとても 気持ちが悪いです。

>は、「コンパイラさん、宣言はブロックスコープを越えないで…」というような、私の嘆きの意味合いです。 なるほど、そうでしたか。 私は「ブロックスコープを超えるのはなんで？」と読めたのでその理由を書き足したのです(^-^;) # とりあえず解決！？

>まぁ、コンパイラがリンク処理を行う段階でexternなんていう情報は >すっかり消えうせて関数名だけ残ってしまう。 >しかも、名前の一致する呼び出し元と実体をリンク処理しちゃう。 ここ、私の解釈が間違ってましたね・・・ 本多さんの意図はexternで「外部にあるよ！」と宣言してるにも関わらず、 同一ファイル内に同じ名前があると「外部」を見に行かなくなるってことですね。 # ブロックスコープの「外にある」という風に解釈するのが自然！？

クリスマスバージョン(柄にもなく)ということで背景をいじってみました。 イブの晩が終わったら戻そうと思います。 少し前、板ごとにCSSをいじれるようスクリプトを修正しました。 なので、以前作ったテスト掲示板↓では、古いCSSがそのまま適用されています。 http://kmaebashi.com/bbs/list.php?boardid=testbbs 板ごとに多少の紹介文をページ上部に入れられるような修正もしたのですが、 とりあえず今は時間がないので 今回の素材は以下のページからお借りしました。 http://kisetu.chu.jp/navi_fuyu_xmas.html ところで、クリスマスといえば、最近久々にアクセス記録なぞ見たのですが、 「赤鼻のトナカイ」「赤鼻のトナカイ 歌詞」という検索キーワードで この雑記↓に到達した人が最近結構いらっしゃるようです。さすがはクリスマス。 http://kmaebashi.com/zakki/zakki0009.html#xmas きっとお役には立てなかったと思います。すみませんねえ。

自己レスです。 >>a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 >なのに、既存の宣言(hoge1の関数ブロック内の宣言)との整合性がチェックされているとは…。 は、「コンパイラさん、宣言はブロックスコープを越えないで…」というような、私の嘆きの意味合いです。

れぷさんへ。 > a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 > b)hoge2()の中のpiyoの呼び出しで、宣言がないので暗黙にintを返す関数として >　宣言されて、 > c)その宣言の段階で、既存の宣言との整合性がチェックされ、なぜかこのときは >　hoge1()の中での宣言とのチェックも行っていて、そのためにエラーになった。 なので、 「a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、」なのですが、 最終的には、 「c)その宣言の段階で、既存の宣言との整合性がチェックされ、なぜかこのときは 　hoge1()の中での宣言とのチェックも行っていて、そのためにエラーになった。 」 となるので、前者の文章は「完結していて」が「完結していない」という結論になります。 (チェックされていればhoge1で完結している事にはなりませんので、(ぱ)さんは完結していないと仰りたかったんだと私は解釈しております。間違ってたらごめんなさい。) という訳で(私の解釈が正しければ)、bcc32では774RRさんが仰っている > と思います。C++ と違い C の場合、K&R1 の頃の（いわゆる non-ansi C) との後方互換性を > 保つため、規格書に書かれていない（もしくは規格書が禁じている）後方互換のための機能が > いくつも有効になっている処理系がほとんどのようです。 となります。 という訳でして、hoge1()のextern宣言時では「外部関数はグローバルにあると想定するしかない」ですよね。 で、宣言が完結していていない(コンパイラが余計(?)なことをしてくれるため)ため、「外部関数はグローバルにあると想定するしかない」がhoge2にも摘要されるので、れぷさんの仰る通り、 > なので「外部関数はグローバルにあると想定するしかない」→「だから整合チェックがかかるのでは？」と思ったわけです。 となります。 一応念の為に書いておきます。

>　と仰っているので、C++の名前空間的な機能が無い限り衝突はされられないので、それはできないとい >う結論になると思います(少なくても私の知っている限りでは)。 そうなりますね。 実は私が反応したのはお二方の文、 　　>>a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 　　>なのに、既存の宣言(hoge1の関数ブロック内の宣言)との整合性がチェックされているとは…。 だったりします。 なので「外部関数はグローバルにあると想定するしかない」→「だから整合チェックがかかるのでは？」と思ったわけです。 ちなみにstaticを使ってしまうと、最初のソースの記述では hoge1()もhoge2()もstaticのほうを呼び出してしまうので、 元のソースとは構成を変える必要が出てしまいますね(^-^;)