ここのサーバを借りているお客さんから、自分のところでも tDiary を使いたいという要望が。
tDiary の tar ボールを取ってきて、適切なディレクトリに解凍しました。
設定をさくさくと済ませて Web からアクセスしてみてもエラーになってしまいました。
しばらく試行錯誤していましたが、ようやく原因がわかってきました。
tDiary (←この「めも日記」で使われています)の高速化の為に mod_ruby を使っているのですが、
それが suEXEC wrapper を通した時に別ユーザーの権限で使えないというのが原因みたいです。
つまり、suEXEC の効果がなくなってしまって、ディレクトリの作成といった
そのユーザー権限で動作させる必要がある命令が Forbidden になってしまうということみたいです。
とりあえず mod_ruby を外してみたところ、意図した動作に。
mod_ruby や mod_perl を suEXEC 環境で使う時には気をつけた方が良いみたいですね。
Visual SourceSafe 6.0 の作業フォルダの表示されているところを Spy++ でチェックしてみました。
あの部分、ステータスバーなんですね。
まぁ、想像はついていましたが。
同じように見える、「あふ」のファイル一覧の上にあるボリュームラベルが表示されている部分を見てみたら。
てっきりステータスバーだろうと思っていたら、なんと「TPanel」でした…。
VCL だったのね…。 (^^;
C++ Builder か Delphi のどっちで開発してるんだろうなぁ？
CStdString
STL の basic_string を MFC の CString っぽく使えるようにしたラッパークラスみたいです。
MFC/ATL の CString を使ったことのある人ならば、この便利さが分かるはずです。
メンバ関数の Format や GetBuffer,ReleaseBuffer といったものが使えるのはとても便利。
これは使えそうですね。
アプリケーションの新規機能の追加をしました。
それはいいのですが、その後、別のバグが出てきました。
再現条件を絞っていったら、私が修正した部分を、私のチェックイン前のコードに戻すとバグがきれいになくなるという事態に…。
完全に私のせいじゃん。 (^^;
調べていったら、仮想関数のパラメータを変更してしまった為、オーバーライドが効かなくなっていたのでした。
動いている関数を見てみると、
「このパラメータ使われてないぢゃん。だったら消しちゃえ。」
…って感じで書き換えてたのが、実は仮想関数でベースクラスから呼び出されていたという…。
だめだめだなぁ…。今度から気をつけよう。 (^^;
自販機でお茶を買おうとしたところ。
110円のジュースの隣に140円の大きめなペットボトルのお茶が置いてありました。
普通に140円入れてお茶のボタンを押したら。
当然ながら下からペットボトルのお茶が出てきたんですが、それとは別に30円のお釣りが出てきました。
設定を隣と同じで110円にしてあるみたいですね。
業者の方が間違えたんだろうとは思いますが、思いがけないラッキーでした。 (笑)
ありがとー。 (^_^)/
通勤帰りの新幹線で席に座ったところ、後ろから「ぶーんぶーん」という携帯のバイブの振動が。
後ろを見てみると、携帯が落ちていました。
早速車掌さんに届けました。
次の駅で駅員さんに届けるって言ってたけど、落とし主は手前の駅で既に降りてたから不安かも。
持ち主のところにちゃんと返るといいなぁ。
COM のメモリ領域の確保の為に CoTaskMem 系の便利な API があるのね…。
今まで IMalloc インターフェイスを介してわざわざ使っていました…。 (^^;
…よくよく見てみたら、手持ちの COM の本のほとんどにも CoTaskMemAlloc の使い方が載っていたのに…。 ＿|￣|○
OS を再インストールしてからプリンタの設定が出来ていなかったので設定しました。
ネットワークプリンタに繋いでいるのですが、Windows 2000/XP でのプリンタの設定をいつも間違えてしまいます。
プリンタの設定ウィザードを開くと
という2つの選択肢があるのですが、いつも後者を選択してしまいます。
実は、後者は Microsoft ネットワーク(NetBIOS)で共有されたプリンタを示しています。
家のプリンタは LPR プロトコルで繋がっているので、「ローカルプリンタ」→「Standard TCP/IP Port」を選択しなければなりません。
毎度のことながらまぎらわしいなぁ…。 (^^;
ここにめもしておいてもまたもや間違えそうだ…。
BSTR およびC文字列の変換
ATL の文字列変換マクロで出来ないっけか？
…とか思いつつ、めもっておこう。 (^^;
VC6 アドイン開発を少しやっています。
始めは難しそうだなぁと思っていたのですが、Word や Excel のマクロと同じ感じで出来ちゃうっぽい。
まぁ、C++ を使っているので COM の取り扱いがめんどくさいのですが、それだけです。
↓ここから下は自分だけのめも。
ちなみに、上のはインクルードファイルと実装ファイルを切り替えるアドインの作り方の例です。
COM オートメーションのインターフェイスで、
IDispatch* から別のインターフェイスに変換することがよくあります。
reinterpret_cast でも動くことが多いんですが、めんどくさくてもきっちりと QueryInterface で取り出しましょう。(謎)
確かに毎回毎回めんどくさいですけどね…。
サントリーのポーションの CM が楽しいです。
これは好きだなぁ。
http://www.suntory.co.jp/softdrink/FF/
戦闘で食らったダメージを考えればポーションで回復したヒットポイントなど微々たるものなんだから、
どちらかが譲るか、半分ずつ飲んで 50 ポイントずつ回復した方がお互い幸せになれると思うのですが…。 (^^;
Boost: スマートポインタプログラミングテクニック
めもめも…。
OLE テクノロジー プログラミング ヒント集
めもめも…。
デバドラ開発なんて私には縁がないですが、これは面白そうですね。
VC コンパイラの COM サポートの中に、
といったオートメーション関係の便利なクラスがあったのを初めて知りました…。
なんか、どこを見てもあんまり出てない気がするんですが…。
2006-03-06(Mon) 仮想関数絡みのバグ に書いたバグですが、
「ATL インターナル」という本に載っていた「シミュレートされた動的バインディング」というテクニックを使えばこういうミスを防げるのではないかと思いました。
シミュレートされた動的バインディングとは、テンプレートを使った関数の継承テクニックで、
実行時に仮想関数ポインタが解決されるのではなく、コンパイル時に呼び出す関数を決めてしまうというものです。
ベースクラスのテンプレート引数が T だとしたら、ベースクラスで次のようにして継承されたクラスの関数を呼び出します。
static_cast<T*>(this)->Function();
自分自身を継承されたクラス T に static_cast して、その継承されたクラスに存在しているであろう関数 Function を呼び出します。
継承されたクラスでは次のように定義しておきます。
class CDerived : public CBase<CDerived>
{
public:
void Function();
};
これはよく考えられていますね。
これなら、テンプレートでコンパイル時に呼び出す関数を解決してしまうので、
(私がやったように)勝手にパラメータを変更してしまったとしても、その場でコンパイルエラーが出てビルド出来なくなります。
ビルド出来なくなるということは実行ファイルが作られないということなので、
下手にバグとして市場に出てしまうのを食い止めることが出来ますね。
ビルドエラーが出たら、直前にやった内容の「関数のパラメータを変更してしまったのが悪いんだ」と思うことが出来て、デバッグに役立ちます。
…ただ、私の職場では C++ のテンプレートを使うことはコーディングルールで禁止されているので
こういうテクニックを駆使することは出来ないのですが…。 ＿|￣|○
ATLの仮想関数とvtable
__declspec(novtable) や ATL の FinalConstruct, FinalRelease の意味がいまいちわからなかったのですが、
これを読んだらなんとなくわかってきました。
VS 2003/2005 のアドインで、新しくファイルを開くには
DTE.ItemOperations.OpenFile
を利用すれば良いらしい。
ただ、この OpenFile はマクロでは利用できないので、
この機能を使おうと思ったらマクロではなくアドインを開発する必要があるっぽい。
いつもファイラーとして「あふ」を使っています。
これはとても便利です。
ドライブを切り替えるのも、「L」→「C」とかやれば C ドライブに切り替えることが出来ます。
…って、コピーされとる…。
見てみたら、最初の「L」が押されてなかったみたいです。
コピーをキャンセルしてコピーしたやつを削除して元通りになったのですが。
もしこの時、C ドライブの代わりに D ドライブを選んでいたら…。
「D」はファイル/フォルダの削除のキーなので、ゴミ箱にも残らずにカーソル位置にあった
ファイル or フォルダを闇に葬り去っているところでした…。
これは冷や汗をかきました…。
次からはこういうミスを防ぐ為に、あふの設定を安全指向にふることにしました。
まずは、各種設定(1)ファイル操作の「通常の削除はゴミ箱を使用する」のチェックをオンに、
それから各種設定(2)のマーク無しファイル操作を「即操作する」から「何もしない」に変更しました。
これで、ファイルの削除やコピーなどはまずファイルをマークしておかないと使えなくなりました。
さらに、削除されたファイルはゴミ箱に残るので万が一削除してもまだ助かる可能性があります。
う〜ん、C ドライブで本当に良かった…。 (^^;
LockWindowUpdate という、再描画を禁止する API があることを初めて知りました。
こういう API があったとは…。
GNU wget のビルドを VC6SP6 でしようとすると、内部コンパイルエラーを出して落ちてしまいます。
その落ちるファイルの先頭に、コンパイルの最適化機能をオフにする #pragma 文を入れたら正常にコンパイルすることが出来ました。
どうやら VC6SP6 のバグみたいで…。
めもめも…。
Vine Linux での Apache2 + suEXEC + PHP5 の Web サーバの立て方が書いてあります。
私がやろうと思っていることを既に実現しているので、これは参考になります。
このサーバは Slackware で動いているのですが、pLaTeX が完備されている Vine に乗り換えようと思っているので…。
めもめも…。
VS2003 を入れた後で VS2005 を入れたら、VC 2003 のコマンドラインプロンプトがうまく動かなくなってしまいました。
私だけでしょうか？
具体的には、パスに cl.exe などが通っていない状態です。
調べてみたら、勝手に cl.exe などが D ドライブから C ドライブへと移動されていた感じです。
私だけなのかな？
仕方がないので、VS2003 の vsvars.bat の MSVCDIR 環境変数を、現在 cl.exe があるディレクトリに修正しました。
それからはコマンドラインプロンプトが正常に動くようになったのですが…。
なんか納得いかないなぁ…。
忘れそうなのでここにめも。
VC6 で使える DirectX SDK の最終版は、DirectX SDK 9.0b Update(2003 Summer)です。
一応、これより一つ後の DirectX SDK 9.0c - October 2004 でも動くようにすることは出来るのですが、
Read Me を読んだ限りでは「VC6 はサポートしていない」と、はっきりと(英語で)書いてあったのでわざわざ苦労することもないですね。
例外安全性についていろいろ書いてあります。
まだ中身は見てないけど、参考になるかもしれません。
ちなみに、C++ の例外安全性についての議論は、「Exceptional C++」という本がとても参考になります。
・ meta [mod_perlはCGIじゃないので、root権限で実行されるってのをきいたことがあります。 下記スレをsuexec..]
・ Noppi [> mod_perl は CGI じゃない 確かにそうですね。基本的なことを忘れていました。 (^^; ]