mfcの描画機能について備忘録

mfcの描画機能ついて

• ドキュメント・ビュー構造化
• OnPaintで描画される。コントロールは自動で描画される。
• 参考ページ　http://c-loft.com/blog/?p=370
• オーナードロー機能
• 自由度の高い描画が可能。ほぼ、自由に表現できる。ただ、ボタンの影や、クリック時の強調処理等、全てを自分で記載する必要がある。
• OnPaintを使わずに、OnDrawItemで描画処理を記載する。
• ※mfcではDrawItemをオーバーロードすると利用可能。
• 参考ページ　http://www.kumei.ne.jp/c_lang/sdk/sdk_41.htm
• カスタムドロー機能
• オーナードローよりかは自動描画処理に任せつつ、コントロールをカスタマイズ表示できる。カスタムドローするタイミングを自分で決めることが出来る。ただ、それでも結構めんどくさいみたい。
• 参考ページ　http://www.kumei.ne.jp/c_lang/sdk3/sdk_261.htm
• 
  

shared_ptrについて

shared_ptrを利用して、配列のポインタを自動解放することが出来なかった。
環境はVisualStudio2008。
C++11からは開放関数にstd::default_deleteを指定すると、自動開放可能！
2,008を早く2013にしたいけど、インストーラの関係から難しい。。。

代替案として、
boostの機能を利用すると、shared_ptrで配列も同時解放が可能。
例：　boost::shared_ptr<int[]> testData;
配列の領域を一気に取得したい場合はコンストラクタを使用するようにしないと上手くいかないので注意。
例：　boost::shared_ptr<int[]> testData(new int[5]);

他に、C++の型推論機能として、autoというのは実装されていることを知ったが、C++11からの機能だった。。。ここでも、2008の壁がある。。。
型推論を使うと、コードを記載する量が減るので将来的に使っていきたい。

make_sharedを使用すると、boost::shared_ptrの書き換えが可能。何のためにあるのか、あんまり未だよくわからないので、分かったら追記します。

プログラミング開発で感じること

今日はプログラミングがあんまり、進んでない。
なんでかなーと思ったので、ここに、自分なりの考えを書いておく。


１．僕は全体像を捉える前に動いてしまうことが多い。後から、やってみて、出来なかったことに気付いて、手戻りが多く発生してしまっている。
→何故、そのやり方で上手くいくのか。自分の中で、納得のいく答えを出すようにしよう。
注意点としては、考えすぎて、思考が止まっていると感じることもあること。思考が進んでないなと感じたら、紙に書くようにして、前に進めるか。わからない所を小規模なコードを書いて、動作を確認するなどしよう。

２．理解できない現象が発生した時は、その対応策を自分なりに決めて持っておく。そうすると、迷わないので早い。
→以下、対応策
２－１．表示されているエラー文を読む。
　意外と出来ていない。特に初めて見るエラーで数が多いと見ないことがある。その時は、最初に発生したエラーだけを熟読しよう。

２－２．以前、成功した事例を知らないか考える。
　意外と、前回成功したパターンというのがある。闇雲に修正するよりも、前回を踏襲するのが安定して早いし、同じ失敗をしない。もし、パターンが無いのなら、まずWebで調べて、それでもなければ、自分で小規模なコードを書いてみると良い。それでも無理なら、知識不足なので、壁にぶち合っていることを周りの人にも言って、しっかりと知識を深めよう。

モダンC言語プログラミング

モダンC言語プログラミングを読んで、アウトップとしないと忘れそうなのでブログに書く

継承について
C言語で継承の機能を疑似的に使用することが出来る。これは構造体の先頭に宣言した変数はその内包されている構造体に変換することが出来る機能を利用している。
例えば、
struct Data {
    int common;
    int unique;
};
という構造体が会ったときに、commonのアドレスを知っていれば、そのアドレスを利用して、Dataのアドレスと認識させることが出来るということ。
これにより、先頭に宣言した変数に共用で使用するデータを定義し、2番目以降にそれぞれの処理に必要なデータを定義して、処理することが可能になる。これはC#のインターフェース機能とほぼ同等のことが出来ることを意味している。（ここの説明が難しい。。。）
この手法を利用して、様々なデザインパターンを利用することが可能になる。


デザインパターンについて
以下の５つのパターンがある

1. Stateパターン
2. テンプレートパターン
3. オブザーバーパターン
4. チェインオブレスポンシビリティパターン
5. ビジターパターン

それぞれを簡単に説明すると

1. Stateパターン　→　スイッチ文の代わりに状態のクラス₍構造体₎を使う。そうすると、状態遷移表がそのままプログラミング出来るので、バグが少ないし、実装しやすいし、網羅性も大丈夫だよ。というすごい組み込みで便利なパターン
2. テンプレートパターン　→　メモリ確保と解放のようなセットで必要な処理を、必ず実施させる。コールバックを使った機能で、どんな時でも、メモリの開放を忘れないので、不要で不毛で無駄に時間のかかるバグを追いかけなくて済む涙が出るくらいありがたいパターン。ファイルのオープン、クローズ等何にでも使える。
3. オブザーバーパターン　→エラー処理などを呼び出すクラスと呼び出されるクラスで依存関係を分離出来る。コールバックを使っていて、呼び出されるクラスを不要に変更する必要を失くし、ファイルの肥大化を抑えるパターン
4. チェインオブレスポンシビリティパターン→変数チェックなどの処理が複数ある場合に、呼び出すクラス側で簡単に順番を変えられるようにするパターン。配列のリスト構造に似ている。変数チェック等と同じ形式の関数で変数チェックをオーバーラップする感じのパターン(説明しにくいですね。。。）
5. ビジターパターン　→　二つの機能を一つのクラス₍構造体₎に持たせるときに、お互いに疎結合な状態にさせることが出来るパターン。それにより、拡張性、バグが減る、ファイルの肥大化を防ぐ、ソースが読みやすくなる等の様々なメリットが生まれる。コード量は少し増えそう。

まとめ

上記の機能を利用することで、様々なバグを減らし、無駄なデバッグ時間を減らし、ファイルの肥大化を防ぐことで、コードの可読性を上げることが出来る。デザインパターン最高！

以上が、自分なりにまとめてみた結果。忘れたころにまず、これを読み返そう♪

参考文献
本　モダンC言語プログラミング

eclipse CDT + googleTestでの開発環境

今日はeclipse CDTでの開発環境構築についてメモ
中々に時間がかかったので備忘録もかねて。
今まで、eclipse関係は最終的に失敗で終わっていたので少し嬉しい。

環境
windows 8.1
eclipse pledias fulledition 4.4
googletest 1.70

モダンC言語プログラミングのサンプルコードをテストした。
テストコードは何でもいいと思われる。

やったことは

1. eclipseのインストール
2. MinGWのパスを通す(例 C:\Development\eclipse\eclipse\mingw\bin)
3. 新規プロジェクト作成(ファイル→新規→C++プロジェクト）
4. プロジェクト名を入力後、空のプロジェクト　MINGCC　を選択して、完了
5. googletestのtopフォルダをコマンドプロンプトで開く(パス例　C:\Development\gtest-1.7.0）
6. g++ -isystem include -I. -c src/gtestall.ccコマンドを実行　※ -pthreadをつければ、マルチスレッドになるみたいだけど、POSIXの別ライブラリをインストールする必要があるのでやっていない。
7. mkdir lib コマンドを実行
8. ar -rv libgtest.a gtest-all.oコマンドを実行
9. eclipseの作成したプロジェクトを選択して、プロジェクト→プロパディ　の中の　ツール設定→C/C++ビルド→設定→GCC　C++ Compiler→インクルード　に　googletestのパスを通す（例　"C:\Development\gtest-1.7.0\include"）
10. 同じツール設定内の　GCC　C　Compiler→Dialect→Language standardをISOC99(-std=c99)にする。
11. 同じツール設定内の　MinGW C++ Linker→ライブラリ　ライブラリの検索パスにlibgtest.aのパスを通す(例 "C:\Development\gtest-1.7.0\lib\")
12. 同じツール設定内の　MinGW C++ Linker→ライブラリ　ライブラリにgtestを登録する。これは先ほど作成したlibgtest.aのlibとaを抜いたもの。僕のようなwindowsしかさわったことない人間には意味不明だったが、linux系ではわりと普通のことみたい。
13. 同プロパディ内のC/C++ 一般→パスおよびシンボル→ライブラリー・パスにgoogletestのincludeパスを通す(例 C:\Development\gtest-1.7.0\lib\)
14. 同パスおよびシンボル→ソース・ロケーション→リンク・フォルダ　で　ファイルシステム内のフォルダーにリンクをチェックし、対象となるテストコードを選択（例　D:\data\study\modanCsamples\chapter04\chainOfResponsibility01)
15. 以上で設定は終了
16. 後はコンパイルが通るはずなので、コンパイルして実行してみてちょ。

実行結果画面

考察

・googletestはコンパイルして使う。必要なパス、インクルード、ライブラリを設定すると、コンパイルして実行できる。まとめると、それだけで、当たり前のことですね。それが中々、初めての時は落ち着かないと、道を見失ってしまっていけないですね(>_<)

・コンソール画面を見ながら、エラーを推察するのが非常に大切だと感じた☆

・後、googletestのreadmeをきちんと読んだら、答えのってました。英語はつい避けてしまうが、英語を忌避せずまずreadmeを読むようにしていこうーと思う♪

参考になったページ

http://blog.myspoon.info/2013/08/eclipse-cdtgoogle-test.html

参考にした本

モダンC言語プログラミング

VC++の共有メモリについて

共有メモリについて

1. 共有メモリで共有時のメモリ容量について
大容量のデータをコピーする際は書込先と読込元と２箇所でデータを展開する必要が有るため、必要なメモリ容量は３倍になるかもしれない。（検証要）
共有メモリを作成時に、書込側でデータをコピーする必要が生じるため、同じプログラム内で、２倍必要になる（検証済み）
※もちろん、コピー元のデータを最初から、共有メモリで宣言していれば、データのコピーが不要になるため、メモリ容量が増えることはないが、その場合、共有メモリの増減（バイナリデータのnew deleteに当たる）は排他制御の絡みで、制御が非常に難解になると考えられる。

２．共有メモリで共有できるデータについて
バイナリデータ、構造体、どちらも可能。
同じデータを共有する場合、dll内でメモリマッピングを利用して、データを両方から読みだすのが一般的みたい。先輩が言ってた。

３．C++とC#間のメモリ共有について
ネットを調べた限りは可能。基本機能はC++、C#共にWindowsAPIを利用しており、問題はない。但し、C#はメモリポインタを扱う概念が無いため、unsafeでポインタを利用する必要がある。もし、.net4.5を利用するならば、専用のクラスが実装されているので、そちらを使えば良さそう（検証要）
参考になったページ
http://devlights.hatenablog.com/entry/20101123/p1


まとめ
いろいろ考えたが、メモリ容量が大きいデータを扱う場合は、そのデータの３倍近いデータを扱えるメモリ容量がないと、共有メモリを利用するのは止めておいたほうが良さそう。
・構造体の共有は一般的に可能なようだ。



以上です！

第2回 xamlの勉強

今日は２時間位xamlの勉強を頑張った。

詰まった所を備忘録的に書きます。



一つ目がxamlとC#の変数との関連付けについてで、dataGridをコレクションと紐付けていたが、
コレクションを変更してもViewの方が変更されず詰まった。

原因はObservableCollectionを利用していたのだが、ObservableCollectionにはコレクションのアイテムの中身を変更してもViewへの通知がされないということだった。ObservableCollectionのレコード（１行）に対して、挿入、削除、置換えを行った場合にのみViewへの通知が行われる。
また、置き換えにも一応の注意点があり、以下のような書き方は失敗する。
var tmp = ObservableCollectionData[2];
tmp = 5;
ObservableCollectionData[2] = tmp;
原因はObservableCollectionData[2]の先頭アドレスが書き換えられないためだと思われる。

下記のように書くと成功する
var tmp = new ObservableCollection( ObservableCollectionData[2]);
tmp = 5;
ObservableCollectionData[2] = tmp;

参考にしたページは以下です。
http://smdn.jp/programming/netfx/collections/3_objectmodel_2_observablecollection/



もう一つが終了処理についてで、まだ解決しきれていない。
アプリケーションの終了時にファイルにデータを保存するにしたい。WindowクラスにあるClosedイベントを呼び出すことで、終了時に発生するイベントを捕まえることは出来るようになった。
参考にしたページｈ下記です。
http://simplestar.syuriken.jp/lesson/047_WPFAppStep1.html


現在はClosedイベントを呼び出したMainWindow(View）からMainViewModel(ViewModel）へのアクセスの仕方がまだ、よくわからない。xamlで宣言している以上MainWoindowから読み出せると思うのだけど。

そんな感じでした。思った以上に進まない(T_T)　
黄にしたら負けだね。一歩ずつ進めます。

上記は私の私見ですので、間違ったことを書いているかもしれません。
ご指摘板だければ、可能な限り修正致します。


では！！！