上へ
開発メモ2001/10/28 gtk+ここのところ gtk+ でコードを書いているけど、設計意図以上のどうでもいいことまで 書かされている気がする。オブジェクト指向をサポートしていない C 言語でオブジェクト指向を 記述しているから仕方ないし、その範囲でよく出来ている方だと思うけど、どうも納得できない。よく使う関数だけ wrap して済ませようと思っていたけど、当初予定より大量のコードを 書くことになって、それを設計意図程度の記述で済むようにするには相当広範囲に wrap する 必要がでてきたので、そろそろ見直すことにする。 2001/10/18 linux プラグイン３動き始めた、結構良い感じだと思う。アプリケーション層より下のレベルを全て外に出せたので、通信媒体、ルーティング、 プロトコル、認証方式、なにがどう変わってもアプリ側の再コンパイルをしなくて済む。 ・・・と喜んでいたらプラグイン側でアプリケーション層より下の層全てをバイナリで 持っているということは、認証方式（ここではシリアルNo.生成規則、統一性は無い） が変わるだけでプラグインの再コンパイルが必要になるということに気づく。 かといってこんなコロコロ変わるものをアプリ側に持たせるわけにもいかなし。 問題はコロコロ変わるシリアルNo.生成規則をバイナリで持っていることなので、 根本的にはなんらかのプログラム言語の搭載が必要になる ・・・・・・考えた結果 プラグイン側に置換ベースの簡易シリアルNoジェネレータを搭載する。 チェックサム等マクロ置換ベースでは対応出来なかったり、想定外の生成規則は perl や sh などを呼び出して対応することにする。 windows のパイプは不安定だった記憶があるので、windows 移植時にはネックになるかも 知れない。そのときは共有メモリか、最悪ファイルリダイレクトしてもらおう。 複数インスタンスは有効利用方法を見つけたので、結局自分で実装。 やっぱり「複数インスタンスが作れないやんけ」と文句言うのは自分だった。(^^; 2001/10/15 ライセンス冗談かと思っていたマイクロソフトの Software Assurancehttp://japan.cnet.com/News/2001/Item/010508-5.html?rn http://www.idg.co.jp/w2000/sprepo/backnumber/report/200107/rep20010702_01.html 本当にはじまったらしい。 http://www.zdnet.co.jp/enterprise/0110/01/01100105.html 契約期限は当初10月1日といわれていたはずだけど 2月29日→7月31日 と延期されたらしい http://www.zdnet.co.jp/news/dj/011009/e_ms.html 納入して３年経つと電話がかかってきて 「パソコンがストライキしてるんだけど(金払えって・・・)」っていう未来が現実味を帯びてきたな linux でも設備が作れることが分かったから、強硬にくれば こちらとしても態度を決めやすいけど、 実際にはもうすこし妥協や微妙な抜け道を用意してユーザーが離れないようにするん じゃないかな（そのかわりシステム部門が抜け道を作った会社から監査の２文字で脅される） 現代版生かさず殺さずだな。 2001/10/14 linux プラグイン２GTK+ は却下といいつつ、別アプリにした場合の挙動がいまいち気に入らないので、 GTK+ で作ってしまいました。作者的には仕事で使うという前提では GTK+ はあまり評価 していないんだけど(^^;、linux 環境ならほぼ間違いなく使えるし、 プラグイン経由で別アプリという手もできるし、Qt や gtk-- を評価している暇もないし、 まぁよしとする。実装コストがかかる分は、複数インスタンス対応を止めることで 元をとることにする。これに文句をいうのはプログラマだけだから、文句を言った人に実装してもらおう。（←悪） ・・・当面作者しか文句を言いそうな人間がいないんだけど(^^; Kylix で作る場合にあてにしていた TStringList の CommaText, Names, Values, ... は無いのでついでにこれも gcc に移植 仕事で作る以上凝って行数を増やすのは 禁止行為なんだけど、メンテナンスが必要な行数で数百行に抑えれば許して くれるだろ・・・たぶん。 久々の C++ なので、使って良いもの、使うべきではないもの、開発環境をチェック、 全体的に1年前と状況はそれほど変わってないようだ。 各種（デフォルト、コピー、キャスト、・・・）コンストラクタBorland C++ Bulder では各種コンストラクタだけでなくコピーオペレータまで 含めて継承されるようになっていたので、最近は仕様が変わったのかと思っていたのですが、 gcc では継承されず、どうやら BC++ の独自拡張だったらしい。 面倒くさいけどやっぱり継承するたびに書かなければ。STL(Standard Template Library)昔 VC++ では結構面倒なことをしないと STL は使えなかったんだけど・・・。 現在の BC++ では普通に使えるようだ。いずれにしても自作している暇は無いので、使うしかない、 コンパイル速度と、環境変更時の予期しない出来事のためにヘッダからは追い出しておく ことにする。 Standard がつくパーツの使用になんでこんなに慎重にならなきゃならないんだか。 string定番が無い状態は相変わらず、そうはいっても char* s は面倒くさいので STL を使うことにする、相変わらずコンパイルが劇的に遅くなる。 C++ 間のインターフェースには使うからヘッダからは追い出せないし、 コンパイル速度のために string クラスを wrap する string クラスを作るという手も あるけど、やりはじめると結構かかりそうだし、C++ をメイン言語にする気はないので これは諦める。gcc のオプションを探したけど、うまく発見できず。プリプロセスをキャッシュ するようなオプションがあると思うんだけど・・・。 constコンパイラによっては正しく扱ってくれないものもあって、どういう方針にするか 悩むところだけど gcc は結構ちゃんと扱ってくれるようだ。小細工をしないで設計意図通り使うことにする。 移植先のコンパイラが古くてエラーが出る場合は型適用のためだけのメンバ関数を増やすか、 そうでなければキャストしまくってもらうかしよう。 例外あいかわらず標準の範囲で使えるのは try catch だけらしい、今回は共有ライブラリ なので、ライブラリ外に例外は送出しない方針なので、それほど問題にはならない。う〜ん、てんぱってるな＞おれ 2001/10/12 linux プラグインある機能を↓こんな感じで提供しようとしていて
それを Linux 環境でどう実装するか考えていたのですが、 良さそうな実装が思いつかず、結局、 共有ライブラリ中のメンバ関数をハンドルと通常の関数で Wrap して それをまた呼び出し元のメンバ関数で Wrap する、 という仕様そのままの力技で押し切ることにしました。 保守上あまり良くないけど、メンバ関数５つ以下なら許せるだろうし、COM プログラムの移植 サンプル的な生き残り方もあるだろ。 ということで、作り始めたのですが、共有ライブラリ中はメモリ空間が違うらしく Kylix ウィンドウ操作系の関数がまともに動かず結局挫折。振り出しに戻ってしまった。 どうしよ。
2001/10/08 localizeまた需要の無さそうな物を作ってしまった。(^^;2001/10/08 買出しツアー電源がいつでも切れて、定型コマンド打ちがメニューから出来て、 ネットワーク対応、見た目が良くて、むかつかない設備を作るため、以下を購入。（後半強引）
tck/tk：定型コマンド打ち程度ならこんなもんで十分。言語仕様はアレだけど、 数十行のプログラムなら大抵の環境で動くことの方が優先・・・採用。 Kylix：ソケットプログラミングだけが目的。・・・採用 配色：見てのとおり背景が白系だとどう配色して良いか分からないんで・・・採用（←黒系でも分からんだろ) アンジャッシュ：うさぎとかめが好き。全体的に面白いと思う。・・・採用（←どないせぇちゅうねん(^^） ラーメンズ：読書対決が好き。全体的に好みが分かれるところではないかと。 |