K.Maebashi's BBS

>さっき、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謎+落とし穴徹底解明」のページに戻る」となってますよー(^.-)

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

いつも楽しく読ませていただいております。 で、雑記の「宗教な話」を読んだ感想としては、仰ることには全面的に賛成ですけれども、 「面倒臭いことからは可能な限り逃げるのがプログラマの美徳」と仰る（ぱ）さんらしい 見解だとも思いました。 なぜなら、面倒臭い作業をしなければならない状況ほど、「思考停止」というのは人を楽 にしてくれるからです（人間の生理というのはそういうものなんだそうです）。 ちなみに、私はプログラマとは全く畑の違う職業に就いておりますが、やはり面倒臭い作 業から逃げることが許されない職業です。 もちろん、職業だけで人の思考が規定されるわけでもありませんし、私自身も（ぱ）さん の仰るとおり、思考停止に陥らないよう努力したいものですけど、それでも世の中からは 思考停止な人が消えることはないんでしょうね。

ええと、投稿者により削除された投稿にレスするのもアレかもしれませんが。 昨年は、2月の健康診断に向けて11月末(って30日だから実質12月からですな)から 断酒を始めたわけですが、会社が変わったせいで、健康診断の時期が変わってしまいました。 どうも5月頃らしいです。 「俺はいつ断酒をはじめたらいいんだろ」と同僚に言ったら、 「今から始めればいいのでは」と言われてしまいました。もっともです。

>前橋信者未満な前橋ファン、かつ半人前プログラマな僕としては、これは >是非読みたいです！ ありがとうございます (_o_) >先日の「宗教な話」を深読みすると、論争を巻き起こしそうな内容ってこと >なのでしょうか？期待しています！ そういう面が全くないとは言いませんが、そんなにはないだろう、と 書いた本人は思っていますです。 もちろん既刊の3冊も、そうだと思っています(きっぱり)

前橋信者未満な前橋ファン、かつ半人前プログラマな僕としては、これは 是非読みたいです！ 仕事帰りにさっそく書店に寄ってみます。（って、仕事中に書き込んでますが。。） 先日の「宗教な話」を深読みすると、論争を巻き起こしそうな内容ってこと なのでしょうか？期待しています！

　や、まとまらない話にご意見いただきありがとうございます。 > しょせん日本人が「私は Free Software Foundation 信者である」とか「彼は qmail 信者だから」 >といったところで、葬式のときには仏教に頼る、という程度の意味しか持たないのではないかと思うのです。 　これなんですが、伝統宗教以外の世界で「○○信者」と言ったらそれはけなし言葉だろう、 つまり自分から「○○信者」と名乗ることはあるまい、ということを雑記帳には書いた のですが、書きながら、いやFSF信者だけは「自称」するかもしれない、と思ってました。 いやそのなんとなく。 > Gnu/Linux 遣いが PostgreSQL を使ったり、qmail 信者の人が DNS サーバは BIND だったり。 　正しい姿勢だと思います。所詮は道具なので。 > ...で、そこが日本人の良いところだと思うのです。 　これはつくづくそう思います。 　葬式仏教にはそれなりの存在意義があるし、初詣だって仲間とわいわい行けば楽しい でしょうし。

しょせん日本人が「私は Free Software Foundation 信者である」とか「彼は qmail 信者だから」 といったところで、葬式のときには仏教に頼る、という程度の意味しか持たないのではないかと思うのです。 Gnu/Linux 遣いが PostgreSQL を使ったり、qmail 信者の人が DNS サーバは BIND だったり。 「信者」という言葉の意味、英語の「洗礼を受けた人」よりもだいぶ軽いんじゃないですかね。 ...で、そこが日本人の良いところだと思うのです。 -- yaemon

>>b)KeywordとPKeywordの区別はつけられるのか、という気がしますし、 >タグ検索のような事ができると聞いた事が有ります。例えばKeywordで検索すると >＜Keyword＞＜／Keyword＞の属性をメタファイルからチョイスし（複数ある場合もあります） XMLから特定の要素を抜き出したいのであれば、DOMなりSAXなり使えばよいと思います。 ただ、私が「KeywordとPKeywordの区別はつけられるのか」と書いているのは、 「PKeywordはそもそも不要では?」ということです。 既に例示されているA, Bでは、AがBへのリンクを持つだけでなく、BもAへの リンクを持つことになるのでは? つまりPKeywordは不要で、 単純に「共通のKeywordを含むメタデータへリンクする」ということに なるのではないかと思うわけです。 >>c)LOMだと、他のリソースを参照する場合はRelationという要素を使うようですし。 >LOMのRelationは，他のコンテンツ（LOMではない）を関係付ける記述です。また おっと、これは私が誤解していました。失礼しました。 >何か良い正規化の仕方は，あるでしょうか？ >>a)メタデータクラスとキーワードクラスができて、 >>b)メタデータクラスはキーワードクラスを0..*で集約していて、 >>c)キーワードクラスは、そのキーワードにより関連するメタデータへの >>　参照を保持するようにする。 ここのところ、修正します。あるキーワードから、そのキーワードにより 関連するメタデータは複数ありますよね。 >>または、LOMの構造を意識するなら、 >> >>a)メタデータクラスとキーワードクラスとリレーションクラスができて、 >>b)メタデータクラスはキーワードクラスを0..*で集約していて、 >>c)メタデータクラスはリレーションクラスも0..*で集約していて、 >>d)リレーションクラスは、そのメタデータと、何らかの要因(必ずしもそれは >>　キーワードの一致でなくてもよい)で関係するメタデータへの参照を >>　保持するようにする。 >これも勉強します。「0..*で集約」の意味が解っていないという寂しさ・・ 正直、この件に関する限り、特にOO用語を使う必要はないように思います。

はじめまして（ぱ）さん。有難うございます（＾0＾） ものすごい早い回答で嬉しいです。またご丁寧な説明有難うございます。 ならびに少々わかりづらい文面があったこと申し訳ありません。 プログラム初心者の私にとって，メタデータの関係付けプログラムを 作成するのは，色々と難解な所が有ります。・・（ToT) 頑張ります。 >a)あるデータについて、Keywordはひとつのような気はしませんし、 確かに複数ある場合があります。 >b)KeywordとPKeywordの区別はつけられるのか、という気がしますし、 タグ検索のような事ができると聞いた事が有ります。例えばKeywordで検索すると ＜Keyword＞＜／Keyword＞の属性をメタファイルからチョイスし（複数ある場合もあります） ただし聞いた事があるだけなので，実際にみた事はありません。仮に無かった場合は， JAVAプログラムでタグから属性見つけるプログラムを作成することは，できるできるでしょうか？出来たらいいんですけど・・・ >c)LOMだと、他のリソースを参照する場合はRelationという要素を使うようですし。 LOMのRelationは，他のコンテンツ（LOMではない）を関係付ける記述です。また そのコンテンツを，LOM作成者が知っている必要があります。 私がやろうとしている事は，メタデータ同士を関連付けるプログラムでござります。 メタデータAを登録すると⇒自動的に関連付ける という感じです。つまり他のオブジェクトを意識せずに関連付ける事が出来ます。 「属性を記述することで関係を持たせる」というコンセプトで考えています。 >ひとつのメタデータには複数のキーワードがあり、 >あるメタデータから、共通するKeywordを含む(全ての?)メタデータへの >参照を持ちたいのなら、テーブルを分けて正規化するのがセオリーの >ように思うんですが、どうでしょうか。 流石でございます。確かに今のDB構造では，ダメだと思っていました。 今どのように正規化するのかも検討しています。←実はDBについても初心者なので 　　　　　　　　　　　　　　　　　　　　　　本を抱えて勉強中です。 　　　　　　　　　　　　　　　　　　　　　　本は，SQLでござんす。。 何か良い正規化の仕方は，あるでしょうか？ Keyword属性 PKeyword属性 リンク先ID この3つは，複数ある場合があります。 >a)メタデータクラスとキーワードクラスができて、 >b)メタデータクラスはキーワードクラスを0..*で集約していて、 >c)キーワードクラスは、そのキーワードにより関連するメタデータへの >　参照を保持するようにする。 > >または、LOMの構造を意識するなら、 > >a)メタデータクラスとキーワードクラスとリレーションクラスができて、 >b)メタデータクラスはキーワードクラスを0..*で集約していて、 >c)メタデータクラスはリレーションクラスも0..*で集約していて、 >d)リレーションクラスは、そのメタデータと、何らかの要因(必ずしもそれは >　キーワードの一致でなくてもよい)で関係するメタデータへの参照を >　保持するようにする。 これも勉強します。「0..*で集約」の意味が解っていないという寂しさ・・ 知識が無く申し訳ないです。。。 以下にアドレス 3aeem029@keyaki.cc.u-tokai.ac.jp

>初めまして，ねこさんといいます。 ねこさんさん(でいいんでしょうか?) はじめまして。 >例 >Aというメタデータ内 >＜Keyword＞仲間＜／Keyword＞ >＜PKeyword＞学校＜／PKeyword＞ > >Bというメタデータ内（Aと同じく） >＜Keyword＞相性＜／Keyword＞ >＜PKeyword＞仲間＜／PKeyword＞ ええと、私はLOMについては今調べた知識しかありませんので、見当外れの ことを言ってましたらすみません。 このモデルには正直ちょっと違和感を感じます。 a)あるデータについて、Keywordはひとつのような気はしませんし、 b)KeywordとPKeywordの区別はつけられるのか、という気がしますし、 c)LOMだと、他のリソースを参照する場合はRelationという要素を使うようですし。 >AのKeyword属性とBのPKeyword属性が同じなので >AとBは関係しているようにしたいのです。 > >これをDBに記述すると >メタID　メタデータ名　Keyword属性　PKeyword属性　リンク先ID >　1　　　　　A　　　　　仲間　　　　　　学校　　　　　 2 >　2　　　　　B　　　　　相性　　　　　　仲間　　　　　 Keywordがひとつでよく、KeywordとPKeywordの区別があってよく、 ひとつのメタデータが参照するメタデータもひとつでよいのなら、 このテーブルでよいのでしょうが、それでよいのでしょうか? ひとつのメタデータには複数のキーワードがあり、 あるメタデータから、共通するKeywordを含む(全ての?)メタデータへの 参照を持ちたいのなら、テーブルを分けて正規化するのがセオリーの ように思うんですが、どうでしょうか。 >またこれを実現するための >オブジェクト指向が聞けるとすごく嬉しいです。 >（これを先に教えていただけると嬉しいです） 「オブジェクト指向が聞けると」というのはちょっとよくわかりませんが (^^; a)メタデータクラスとキーワードクラスができて、 b)メタデータクラスはキーワードクラスを0..*で集約していて、 c)キーワードクラスは、そのキーワードにより関連するメタデータへの 　参照を保持するようにする。 または、LOMの構造を意識するなら、 a)メタデータクラスとキーワードクラスとリレーションクラスができて、 b)メタデータクラスはキーワードクラスを0..*で集約していて、 c)メタデータクラスはリレーションクラスも0..*で集約していて、 d)リレーションクラスは、そのメタデータと、何らかの要因(必ずしもそれは 　キーワードの一致でなくてもよい)で関係するメタデータへの参照を 　保持するようにする。 ということになるのではないでしょうか。 ズレたこと言ってましたらすみません。

初めまして，ねこさんといいます。 質問です。 メタデータのタグの間にある語彙と別のメタデータのタグの間にある語彙 を関係付けDBに反映するプログラムをJAVAで作成しようとしているのですが， なんせ初めてなもので何処からはじめていいのかが解りません。 またメタデータは，XML形式（LOM）です 例 Aというメタデータ内 ＜Keyword＞仲間＜／Keyword＞ ＜PKeyword＞学校＜／PKeyword＞ Bというメタデータ内（Aと同じく） ＜Keyword＞相性＜／Keyword＞ ＜PKeyword＞仲間＜／PKeyword＞ である場合，（特に脈絡は、ありませんがメタデータには，タグが 　　　　　　　KeywrodとPKeywrodがありその間に語彙が記述されています） AのKeyword属性とBのPKeyword属性が同じなので AとBは関係しているようにしたいのです。 これをDBに記述すると メタID　メタデータ名　Keyword属性　PKeyword属性　リンク先ID 　1　　　　　A　　　　　仲間　　　　　　学校　　　　　 2 　2　　　　　B　　　　　相性　　　　　　仲間　　　　　 このようにKeyword属性とPKeyword属性が同じメタデータがあった場合 Keyword属性の方にリンク先IDを追加する。 (リンク先IDは，Keyword属性とPKeyword属性が同じだった場合の PKeyword属性のメタIDが反映される。上記で記すと2となる） また新しくメタデータが追加された場合，同じくDBに反映させたいのです。 どのようにプログラムをすればよろしいでしょうか？ またこれを実現するための オブジェクト指向が聞けるとすごく嬉しいです。 （これを先に教えていただけると嬉しいです） 長々と申し訳ありません。どうぞ宜しくお願い致します。 以下にメールを書きます 3aeem029@keyaki.cc.u-tokai.ac.jp

>>hoge.h, piyo.hが共にプライベートヘッダファイルならどこかでまとめて >>#define GLOBAL_VARIABLE_DEFINEして#includeしますし、 >そのまとめて include っつーことは globals.c とか作るということですか？ >モジュール切り分け原則に反しているような気がしてなんとなくいやです。 globals.cを作るか、ということですが、 そのglobals.cが、プログラム全域のグローバル変数の定義を行う、 ということなら、Noです。 あるモジュールについて、「そのモジュールの内部だけで使う、ソースを超えた スコープを持つ変数」の定義を行うglobal.cなら、作るかもしれません。 たとえば先のcalcの例だと、電卓モジュール「CLC」内にglobals.cを 置くかもしれません(モジュールごとにディレクトリが分けられていて、 ソースファイル名の重複が許されるとして)。 モジュールをまたがったglobals.cがあるなら「モジュール切り分け 原則に反している」と私も思いますが、モジュール内でしか見ない グローバル変数のためのglobals.cなら、問題ないと思います。 # ここでモジュールは「複数の.cの集合体」と定義しています。 ## Mayerさんの「オブジェクト指向入門」に「ヘッダファイルはモジュールを ## 破壊する」ってあったけど、使い方次第だと思うんだけどなあ。 ただ、実際には、ひとつのモジュールに、そんなにたくさんプライベート ヘッダファイルがあるわけはないので、どこかのソースで代表させて終わりです。 CLCの場合はinterface.cですね。 # どこのソースで代表させるかが不明確なので(たとえ3行しかなくても)globals.c # を書くべきだ、という主張には正当性があると思います。 >組み込み系では「状態保持」のための変数は、プログラムが生きている >＝電源が入っている限り、ずっと必要なので必然的に静的変数(大域変数)になっちゃいます。 >んで getter/setter も最適化の都合でインライン関数化したかったりするんです。 なるほど。アクセサを書くことまではできても、ヘッダファイルを切り分けると、 コンパイル単位が分かれてしまうからインライン展開が効かず効率が悪くなる わけですね。 Javaなんかだと、javacによるコンパイルはソース単位ですが、 JITコンパイラが実行時にソースを超えたインライン展開までやってくれたり するようです。でも組み込みじゃ難しいですよね。

>hoge.h, piyo.hが共にプライベートヘッダファイルならどこかでまとめて >#define GLOBAL_VARIABLE_DEFINEして#includeしますし、 そのまとめて include っつーことは globals.c とか作るということですか？ モジュール切り分け原則に反しているような気がしてなんとなくいやです。 >piyo.hが別モジュールのパブリックヘッダなら、グローバル変数は公開しないので >この問題は起きないんですね。 御意。ではあるのですが... 組み込み系では「状態保持」のための変数は、プログラムが生きている ＝電源が入っている限り、ずっと必要なので必然的に静的変数(大域変数)になっちゃいます。 んで getter/setter も最適化の都合でインライン関数化したかったりするんです。 っとなるとプライベートヘッダとパブリックヘッダの分離とか、 理想を追いかけていられない実装上の都合があったりするのです(泣)

>手間と言えば手間なんですが、グローバル変数にするような >ものは、必ず初期化する趣味なので、GLOBAL みたいな簡単な >マクロでは対処できなかったりします (たとえ 0 や NULL で >初期化する場合でも、明示的に初期化するスタイルを採って >ます)。 GLOBAL char *hoge[] #ifdef GLOBAL_VARIABLE_DEFINE = { "foo", "bar", } #endif /* GLOBAL_VARIABLE_DEFINE */ ; とか書いたこともありますけどね (^^; >また、そもそもグローバル変数なんてほとんど使わないので、 >手間的にはたいしたことないです。 別レスで書きましたけど、実は私もそうです。 別レスで挙げたCLC_Interpreterのように、構造体にまとめて malloc()で領域を確保することが多いです。 # わかりにくいですがCLC_Interpreterはポインタでして、 # こういうふうにポインタがポインタでないかのようにtypedefするのは # よろしくないなあ、と今は思っています。当時はXtとかのスタイルを見て # かっこいいと思ってしまったわけですが。 ## clc_current_interpreterのようなものを静的に持ってしまうと ## リエントラントでなくなります。当時はマルチスレッドなんて ## そうそう使わないよね、と思ってたわけですが… ## まあ、リエントラントにしたい場合も、外部のインタフェースにだけは影響を ## 与えないようにしてあるからまあ許容範囲かと。 >昔風のプログラムなら >グローバル変数にする場合も、たいていは accessor/mutator >関数でラップして見かけは関数にしてしまうことがほとんど >です。 たとえばclc_current_interpreterは関数でラップされていませんが、 CLCモジュールの外から見えることもありません。 これはモジュールの粒度をどのくらいにするかという問題だと思いますが、 「関連の強いソースの集合体としてのモジュール」内(せいぜい数千行レベル)で あれば、この程度のカプセル化の侵食は許容範囲じゃないかなあ、 と私は思っています。 もちろん最初からgetter/setterを書いたからといってさしたる手間でも ないですけれど。

>http://kmaebashi.com/programmer/pointer.html >では GLOBAL int global_variable; を推奨されているようですが、私は反対です。 うーん。 GLOBALに反対する根拠として一番大きいのは、私としては 「Cの構文をねじ曲げるようなマクロはよろしくない」という原則に 反しているからじゃないかな、と思っています。 #define BEGIN { みたいなシンタックスのレベルで改変を入れるようなマクロは確かに いろんな意味でまずいでしょう。 >hoge.c の中で >#include "hoge.h" >int global_variable; >と書いても ISO 文法上何の問題も無いので。 これはそうですね。 >もし仮に hoge.c の中で >#define GLOBAL_VARIABLE_DEFINE >#include "hoge.h" >#include "piyo.h" >とかやっちゃうと hoge piyo 両方の大域変数が定義されてしまいます。 私のヘッダファイルの切り分け方からすると、 http://kmaebashi.com/programmer/c_yota/module.html hoge.h, piyo.hが共にプライベートヘッダファイルならどこかでまとめて #define GLOBAL_VARIABLE_DEFINEして#includeしますし、 piyo.hが別モジュールのパブリックヘッダなら、グローバル変数は公開しないので この問題は起きないんですね。 >わざわざ同一の記述を複数の個所で行なうのは間違いのもとである このメリットは一応それなりの説得力はあるかと思っています。 が、私が実際これをどう使っているかというと、たとえばここで 公開しているソースでは、 http://kmaebashi.com/programmer/c_yota/calc_html/calc.html #ifdef GLOBAL_VARIABLE_DEFINE #define GLOBAL #else #define GLOBAL extern #endif GLOBAL CLC_Interpreter clc_current_interpreter; これ一個だけ…　だったら必要ないじゃん、というのはもっともですね (^^;

> hoge.h の中では必ず > extern int global_variable; > と書くべきだと考えます。 僕も自分で一から書くソフトウェアでは、 GLOBAL のようなマクロは使わず、extern 宣言と、変数の 実体の定義と 2回書いてます。 手間と言えば手間なんですが、グローバル変数にするような ものは、必ず初期化する趣味なので、GLOBAL みたいな簡単な マクロでは対処できなかったりします (たとえ 0 や NULL で 初期化する場合でも、明示的に初期化するスタイルを採って ます)。 また、そもそもグローバル変数なんてほとんど使わないので、 手間的にはたいしたことないです。昔風のプログラムなら グローバル変数にする場合も、たいていは accessor/mutator 関数でラップして見かけは関数にしてしまうことがほとんど です。プロファイルとって効率が問題になるようだったら、 あとで実装をマクロに直すだけですから、最初からグローバル 変数として見せる必要があるとは思えません。逆に、最初は 変数で済んでいたものが、後になって変更時に手続きをフック したくなることは結構あります。(単に最初の仕様検討がいい 加減なだけだって話もありますが… ^^;) > globals.c とか作るのは個人的には嫌っています。 同じく globals.c みたいなものは作りません。 こういうのって、モジュール分けの原則に反してますよね。

　はじめまして、トルと申します。 　追加・削除する時は、分けると２箇所を修正する必要がありますから、分けない方が一箇所で済み、何かと楽ではないですか？ >globals.c とか作るのは個人的には嫌っています。 　私は嫌いではありませんよ。

発言数が少ないようなのでネタ振りなど。 http://kmaebashi.com/programmer/pointer.html では GLOBAL int global_variable; を推奨されているようですが、私は反対です。 hoge.h の中では必ず extern int global_variable; と書くべきだと考えます。 hoge.c の中で #include "hoge.h" int global_variable; と書いても ISO 文法上何の問題も無いので。 もし仮に hoge.c の中で #define GLOBAL_VARIABLE_DEFINE #include "hoge.h" #include "piyo.h" とかやっちゃうと hoge piyo 両方の大域変数が定義されてしまいます。 #undef GLOBAL_VARIABLE_DEFINE しますか？めんどくさいです。 ヘッダ中から別ヘッダを #include しているとそもそも分離不可能だし。 globals.c とか作るのは個人的には嫌っています。 >わざわざ同一の記述を複数の個所で行なうのは間違いのもとである こと自体は御意なのです。でも、 関数(原型)宣言と関数定義を両方書く必要があるなら、 大域変数の宣言と定義を両方書いても大差ないぢゃん、とか思う今日この頃。 皆様はどうお考えですか？

>「ハッカーと画家」、出版されるみたいですよ。 > >http://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi?Shiro 　遅くなりましたが、情報提供ありがとうございます。 　Webで公開されている文書11本に、書き下ろしを4本加えた本ですか。 その11本がどれだかわからないのですが、この中からチョイスしたものなんですかね。 　http://www.paulgraham.com/articles.html 　翻訳されたものがWebで読めるのかわかりませんが、読めるのだとしたら、 やっぱりどうしても購入を躊躇してしまう…

こんにちは。 「ハッカーと画家」、出版されるみたいですよ。 http://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi?Shiro ↑の、2004/9/30の箇所で査読者募集していました。

>ですよねぇ。あれだけ居た人々はいったいどこに行ってしまったのでしょうか。 ># Java人口自体は増えてると思うんですが……。 2chかなあ… それとも小さなコミュニティに分散したのか… これは私も不思議に思っていますので、ご存知の方、情報をお願いいたします(_o_)

>JavaHouse自体、最近はほとんど流量がないじゃないですか。 ですよねぇ。あれだけ居た人々はいったいどこに行ってしまったのでしょうか。 # Java人口自体は増えてると思うんですが……。 # 最近はどの案件もみ～んなJava。(おいらは異端のPerl屋さん^^;) >私が知っているところだと、Java読書会BOFくらいですかねえ。 情報ありがとうございます。一度入って様子を見てみます。 >JavaMailネタでしたら、木下さんもいますし。 そーいえばJavaMailの本の存在をどっかで見かけたよーな気がするなー、と思って 「JavaMail 木下」でぐぐってみたのですが……まだちゃんと中身確認してませんが、 この本とWebページみれば質問事項一通り解決しそーな予感が(^^; ぁぅぁぅ。 # 如何にJavaについて情報収集してなかったかとゆー……。

>JavaHouseに質問投げたら応答無し子さん(;_;)だったので JavaHouse自体、最近はほとんど流量がないじゃないですか。 アーカイブも復活しませんし。高木さんもすっかり投げてますよね。 というわけで >## それとも質問の仕方がマズかったのかなぁ……。 これはないと思います。 >他のところに聞こーかと思うんですが、どこか良さげな >ところありますでしょーか? 私が知っているところだと、Java読書会BOFくらいですかねえ。 http://www.iaj.or.jp/bukai/java/wg_bof/jfriends.html JavaMailネタでしたら、木下さんもいますし。

JavaHouseに質問投げたら応答無し子さん(;_;)だったので 他のところに聞こーかと思うんですが、どこか良さげな ところありますでしょーか? # 2ch?(^^; ## それとも質問の仕方がマズかったのかなぁ……。