Doxygenによる開発のカンフル

どうもJudaです。

最近Doxygenをはじめました。

Doxygenはコメント生成ツールでかなりメジャーなものだとおもいます。類似したものにはJavaDocやphpDocsとかあるとおもいます。

Doxygenの導入は基本的にはInstallerをOfficialからもらってきて、終わりだとおもいます。DoxygenのGUIとしてDoxyWizardがついているので、比較的簡単にDocumentの生成まではいけるとおもいます。

GraphVizも簡単に手に入れられるので、いれてみるとよりクラスダイアグラムなどが綺麗に画像データになります。

そして、日本語でDoxygenを動かす際にいくつかの問題が起こると思います。

1. 出力ファイルで文字化けが起こること。
2. 入力ファイルが読み込めないこと。
3. ファイルの検索がうまくされないこと。

１、は基本的にはExpertの設定でDoxygen_OutputEncodingのような設定のパラメータを「Shift_JIS」など日本語に対応したものにすればよいとおもいます。

２、もInputを「Shift_JIS」ないし、日本語に対応したものにして、なおかつ読み込ませるデータのEncodeを整えることと、Encodeできない文字を使用しないということになります。

３、もファイルパスをコピー＆ペーストしているとよく起こるのですが、Doxygenでは￥のディレクトリの区切りが利用できないので、/に変換してください。

それで本題。

DoxygenではCalledByやCallという関数での関係性を表示し、リンクを張ってくれる機能があります。

これを利用すると、呼び出し先と呼び出し元をしっかりしらべることができます。さらに、ソースコードを合わせて出力するようにしていれば、対象となる関数のソースコードを表示してくれるので、より一層ソースコードを探検するのが楽になります。

Doxygenを導入すること、運用することには、コメント付けなどいくつかの規約がありますが、単純に関数の呼び出し関係を整理して表示してくれるので、これだけでもかなりツールとしてありがたいものがあります。ただ静的な解析でのサポートなので、動的な解析はたぶんサポートしていません。それでも改修やDebugのときの一助になることは間違いないでしょう。

SilverlightのDataBinding

どうもJudaです。

ちょっと失敗こいたので、注意点を。

DataBindingをするときに、DataContextからデータを取ると思う。そのときに対象となるインスタンスの定義がpublicになっていないとDataBindingは失敗する。どうしてか、それは取得と設定がカプセル化されてしまいアクセスするすべがなくなってしまうからである。

Silverlight Sketchflowの変換

どうもJudaです。

実稼動プロジェクトに変換

http://msdn.microsoft.com/ja-jp/library/ee371158(Expression.30).aspx

今まで散々探したのに見つからなかったのに、今頃見つかるなんて。

Google C++ Test Framework

どうもJudaです。
最近Google C++ Test Framework(以下googletest)を いまさら 導入してみました。
googletestはxUnitの流れをくむTestのFrameworkで少しでもxUnit系のテストについての知識があれば、すぐに使えるという触れ込みです。とりあえず公式な情報を翻訳したサイトで勉強すれば、何とかわかります。ちょっと面白いのは、OpenCVのドメインでGoogleTestDocsの日本語訳がホストされていることかなぁ。
肝心の使い方は、公式に書かれているので、割愛しますが、ちょっと読み解くときに面倒に感じたことをいくつか。

• メジャーなコンパイラのためにはすでに特別なプロジェクトが用意されているので、それを利用すること。MSVCとかG++とかは用意されているので、それを利用すればいいので、Cmakeを利用しなくてもいいこと。ただしCmakeを利用した生成もサポートされているので、そちらを利用してもいい。
• MSVCに限らないと思うが、Runtimeの種類で別のSolutionが用意されている。たとえば、マルチスレッドとマルチスレッドDLLで別のRuntime体系になるので、別のSolutionが用意されていて、基本的にはマルチスレッドになっている。なので、MSVCの人でMDｄとかMDのRuntimeを使う人は、gtest_md.slnを利用する。
• MSVCはテスト用のプロジェクトにgtest.projもしくはgtest_md.projをプロジェクトに含めて、テスト用のProjectはその追加したgoogletestのProjectへの依存関係を作ることが必要である。
• TEST_Fを使う場合には事前に::testing::Testクラスを継承したクラスをつくる必要性がある。TEST_F(test_fixture, test_name)でtest_fixtureの部分には利用したい::testing::Testを継承したクラス名を使う。またTest部分ではクラス内部のように変数を扱ってテストできる、はず。
• ::testing::Testの仮想メソッドにはSetup(),TearDown()があるが、名前は厳密に継承元にある奴でないと動作しない。(当たり前) またそれぞれのクラスの利用のタイミングであるが、それぞれデフォルトコンストラクタやデストラクタでは利用できない仮想メソッドや例外が発生しやすいメソッドの利用などの場合には、利用する価値が出てくると思う。この質問に対する回答もある。

上記のような部分で疑問がわいてくると思う。それよりもまず入門ガイドを読まないと話にならないし、それぞれの利用シナリオもに記述されているので、こちらも参照したい。翻訳サイトがあるので、そちらで知識を得ることを優先して、効率よくテストをするために、まずは効率よくFrameworkを使いこなさないといけない。