VCでMFCで作られたプログラムをwin32で同じように作ってみたんですが
プログラムの重さとか処理速度がまったく違いました。言語は同じVCなのに何でMFCのほうが多少重くなったり処理速度が遅くなるんでしょうか？
MFCがやってくれることを"すべて"Win32で実装するなら、それだけ大きく重くなります。
MFCは汎用性を狙っています。
ある目的のため"だけ"にコードを書くなら小さく軽くなるのは当然。
MFCに少しソース付け加えてコンパイルするだけで重くなりますね。
編集 削除付け加えるモノ/付け加え方 によるんじゃないでしょか。
編集 削除>MFCに少しソース付け加えてコンパイルするだけで重くなりますね。
つまりそのコードが…ってことでしょ？
あっしも重いのが嫌でAPIにしました。
APIでプログラム勉強すると、Windowsのプログラムの動きがよくわかるようになったような気がします。
って、こんな風に思っているの俺だけかもしれませんが・・・
Win32のプログラムをするときは、今でも迷わずAPIですね〜。
あれ？
そう言えば、MFCのアプリって、exeを配布する場合によってはDLLとかも配布しないといけなくなかったでしたっけ(VBランタイムみたいな)？
俺の勘違い？
MFC使わないからあまりよくわからんけど、ただ今はPCの処理速度上がっているから、気になるほど遅くはならないのではないでしょか？
MFCでも「スタティックリンク」してしまえば必ずしもDLLは不要ですが、
当然、サイズは大きくなりますね。
# VC6の時代は、安いエディションだとスタティックにできなかったりとかしましたが…。
> APIでプログラム勉強すると、Windowsのプログラムの動きがよくわかるようになったような気がします。
APIでカバーできる範囲はね。
Document-Viewアーキテクチャとかコマンドルーティングとかは、単純にAPIをラップしてるとは言えないので、そういうところまで自力で書くのは面倒くさい。
同じようなのを一度作ってみるのはいい勉強になるだろうけど、毎度作るのは無駄でしかない。
Windowsアプリでのメッセージの流れとか
メッセージループとかその辺の理屈を覚えるにはWin32APIで組むのは良いと思います。
そういう意味ではMFCを勉強する前にWin32APIで組む勉強をした方が
良いですね。そうする事でMFCも使いこなせるようになると思います。
MFCの場合は処理の速さより汎用性に重きを置いて作られています。
ですが、全く同じだけの機能を持ったものを自前作ったら果たして
MFCよりも早くできるのかは疑問ですね。特定用途を目的に処理を
削った物なら早くなるでしょうけれど。
MFCのよさは開発効率があがる事にありますから、
パフォーマンスに対する要求がクリティカルでないなら
MFCを使うメリットはあると思います。
また、ライブラリですからライブラリのコードを使用している部分の
品質は安定します。これはこれでメリットです。
MFCも道具の一つに過ぎませんから仕事でやるならMFCまで使えた方が
良いと思いますし、使う使わないは目的とする成果物の性質によるでしょう。
重い、重くないだと単なる主観になってしまいますから。