.Net Framework APIがあればMFCはいらないのでは?

質問

最近Windowsプログラミングに興味を持ちましていろいろと調べている所なのですが、疑問に思ったので質問させて下さい。

質問の内容はタイトルどおりなのですが、
windowsのシステムが.Net Frameworkに統一されようとしている今、.Net Framework APIがあればMFCを新しく勉強する価値は殆どないと思うのですが、この考えは間違っているでしょうか？

例えば、下の本(実物はまだ見てません)
http://www.amazon.co.jp/exec/obidos/ASIN/4797324201/249-5720925-3989928
では「 MFCを利用したWindowsネイティブプログラムから，最新の．NETアプリケーションの作成方法まで，..」
と紹介されてますが、VC++.NETでプログラミングするのに、なんでMFC?なんて思って仕舞うのですが、MFCでないと出来ないことがあるのでしょうか?

回答No.4

taka_tetsu · ベストアンサー

>.Net Framework SDK + .Net Platform SDK + VC++ Toolkit
>
>を使えば、MFCでなく、.Net Framework APIを使ってダイナミックリンクの不要のnative codeまで
>落とせるものと考えていたのですが、
>それがそもそもまちがいなのでしょうか。言い換えると、上の組み合わせではnative codeまで落とせても、
>MFCまたはWin32APIを使わなければランタイム不要のコードを生成することができないのでしょうか。

はい、現状では間違いです。.NET Framework自体が巨大なRuntimeであると思ったほうがいいでしょう。.NET FrameworkがOSに統合されて初めてそう言えます。
また、.NET Frameworkを使用するということは将来的にもnative codeはなりません。生成物はアセンブリとなります。

>Win32APIはCのライブラリ。
>MFCはVC++のライブラリ。
>VC++.NETにはその理念に相応しいライブラリで記述したいよね。

ここにも認識に誤りがありますね。

Win32APIは、Windowsのライブラリです。Cのライブラリではありません。Windowsの機能を直接使うためのものです。
インターフェイスもC的なものやC++的なもの、VBで扱いやすいCOM等さまざまです。

VC++.NETはあくまでもVC++のバージョンアップしたもので.NET Frameworkが使えるものという位置づけです。
.NET Frameworkのためだけのものではありません。

それに、VC++で.NET Frameworkの開発は他の方も回答しているとおりあまり適していません。MSは専用の言語であるC#を準備するくらいですから。

ですので、VC++.NETに適しているのライブラリが.NET Frameworkだというのもちょっと・・・という感じですね。私は、MFCやATLになると思います。

>もし、.Net Framework APIがWin32APIの完全な代替物であるのであれば
>(この点は自信がないので質問に含まれています。)

現時点では違いますね。APIを必要とする機能だらけです。MFCであってもすべてのWin32APIを包括しているわけでもありませんし。
まぁ、でも次期OSではそうなるかもしれませんが。

>これからVC++を学ぼうとする人間がMFCを学ぶ意義は、将来性の面からいってかなり薄れているのではないか?

MFCは、Windowsが存在する限り、おそらくなくならないでしょう。そういう意味であれば、将来性はあるフレームワークです。

>だとしたら、なぜ、.Net Framework APIを強調したVC++.NETの解説が見当たらないのだろう?
というくらいに弱めておきます。)

それは、.NET FrameworkがVC++の一部ではないからです。
.NET Frameworkはさまざまな言語から利用できます。C#やVB.NETの解説本が.NET Frameworkを中心に書かれているのはこれらの言語の基本となる技術が.NET Frameworkだからです。
C++は.NET Frameworkの上に成り立っているわけではないですよね。

「適材適所」という言葉を使ったのは、.NET Frameworkを使用可能か？.NET Frameworkを簡単に使えるか？ということでもあります。

>だから、せっかくVC++「.NET 」なら
>それ相応のAPIで書きたいなとみんな思わないのかな?
>それともそうしないのは何か理由があるのかな?

というくらいのレベルの人であれば、VC++での.NET Frameworkの解説を望んでいるのではなく、.NET Framework自体の解説を望むと思いますよ。

メリットは、「.NET Frameworkに対応した任意のプラットホームで実行可能」というだけではなく、「任意の言語で作成されたアセンブリも相互利用できる」こともなんですから。

.NET Frameworkを理解できる人であれば、言語に依存した単純な使い方さえわかれば、それ以上の言語に依存した解説など不要でしょうし。

お礼

再びのご回答ありがとうございます。
しかも私がまさに知りたかったことに詳細に答えて頂き感謝です。

私はLinuxにおけるC/C++自体の経験は少しあるのですが、
Windowsのことは幾ど何も知らない状態でありまして、
自分なりに結構調べたつもりなのですが、
まだまだいろいろと誤解があったようです。
しかも出発点ですでに誤解があったのですね。

>VC++.NETはあくまでもVC++のバージョンアップしたもので.NET Frameworkが使えるものという位置づけです。
.NET Frameworkのためだけのものではありません。

の説明でかなり納得できました。

VC++.NETはシステムを直に弄るところで偉力を発揮するものであり、その為のライブラリは基本的には(現時点では)Win32APIであり、それをVC++用にラップしたMFCを学ぶ意義は将来性を考えても十分にある、というように理解いたしました。

ありがとうございました。

回答No.3

taka_tetsu

あなたの言っていることは「アセンブラがあればプログラミングできるのに、どうして他の言語が存在するんですか？」というのと変わりません。
これって適材適所ですよね？

お礼

ご回答有難うございます。

んー、そう言っているつもりはなかったのですが、「適材適所」と言う点に関しては、理解できます。
(でも「アセンブラがあれば..」という例えは、私が言いたいこととは少しはずれているかな?と思います。
しかし、そうおっしゃりたい気持になったことはなんとなく分ります。)

このような質問をさせていただいたの背景をもう少し説明させていただくと、
将来性を考えた、もう少し思想的、理念的なモノのつもりなんです。

(しかし、質問の言い方は強すぎました。
VC++が.Net Frameworkに含まれることにより、
もし、.Net Framework APIがWin32APIの完全な代替物であるのであれば
(この点は自信がないので質問に含まれています。)
これからVC++を学ぼうとする人間がMFCを学ぶ意義は、将来性の面からいってかなり薄れているのではないか?
だとしたら、なぜ、.Net Framework APIを強調したVC++.NETの解説が見当たらないのだろう?
というくらいに弱めておきます。)

Win32APIはCのライブラリ。
MFCはVC++のライブラリ。
VC++.NETにはその理念に相応しいライブラリで記述したいよね。

という感じです。
もちろん.NET原理主義者でもなんでもないので（笑）
ご指摘も理解できます。

しかし、Linuxも.Netの構想内に入る「かも」しれないという可能性があるのなら、
MFCでなく.NETのAPIで記述したいと思うのが人情というものでは?と思ったりもします。
.NETのAPIで記述しておけば、Linuxが.Net Frameworkに対応するなんてことが起こったら、ソースを幾どそのまま使えます。MFCを使っていたらそんなことはできません。
だから、せっかくVC++「.NET 」なら
それ相応のAPIで書きたいなとみんな思わないのかな?
それともそうしないのは何か理由があるのかな?
と思って質問させて頂きました。

回答No.2

mountbook

.NETプログラムは確かにいろいろな言語で利用できるよい仕組みだと思うのですが、デバイスドライバなどWindowsの内部まで踏み込んだプログラムは.NETでは難しいと思います。また実際先進的なプログラム（DirectXなど）のSDKはWindowsAPIの直接利用またはMFCを前提とした開発環境となっていますので企業の開発ではMFCはまだまだ必要でしょう。少なくとも現状では.NETは内部でネイティブコードに翻訳しながら実行しますので速度的には不利です。

お礼

ご回答有難うございます。

>.NETプログラムは確かにいろいろな言語で利用できるよい仕組みだと思うのですが

私も今回しらべてみて、.Netの構想は面白いと思いました。これまでMicrosoftは嫌いでしたが、.Netの構想ははなかなかよいと感じました。VC++6.0の後継として、VC++7.0ではなくVC++.NETとしたのは、Microsoftの.Net Frameworkに対する気合の現れのように感じられます。

とすれば、現状でMFCを使う理由としてmountbookさんの仰ることは良く理解できるものですが、やっぱり、win32APIのラッパとしてはMFCではなく.Net Framework APIを使うべきなのではないかなあ、そのほうが、実装の変更に影響されないし、それこそ.Net Frameworkの理念にかなうのではないか?と思いました。

しかし、#1のお礼の欄に書かせていただいたように、
ひょっとして、.Net Framework APIではランタイムが必要なコードになってしまうのでしょうか。。。
私の感じとしましては、VC++.Netは
C++ + Win32API + .Net Framework ラッパ
というイメージなので、MFCでなく、.Net Frameworkラッパを使うべきでないかな?と思うわけです。
(現時点でまだ細かいところはWin32APIを使うとしても。)

回答No.1

sha-girl

Frameworkのアプリを作るのにVC++.netは普通選択しません。
VC#.netかVB.netを使います。

VC++.netを選択する理由はネイティブコードのアプリを作るため
だと思います。MFCのライブラリはスタティックリンクできる為
ちょっとしたWindowsアプリを作成する時には効率的でしょう。
(ちなみに市販のパッケージソフトでFrameworkを使ったものなんて
ありませんし、中間コードである事は逆コンパイルされやすい
危険もあります。)

>MFCでないと出来ないことがあるのでしょうか?
MFCって単にSDKをラッピングしたclassです。
むしろMFCだけでは出来ない事があるかもしれません。

お礼

ご回答ありがとうございます。

>VC++.netを選択する理由はネイティブコードのアプリを作るため
だと思います。MFCのライブラリはスタティックリンクできる為
ちょっとしたWindowsアプリを作成する時には効率的でしょう。

.Net Framework SDK + .Net Platform SDK + VC++ Toolkit

を使えば、MFCでなく、.Net Framework APIを使ってダイナミックリンクの不要のnative codeまで落とせるものと考えていたのですが、それがそもそもまちがいなのでしょうか。言い換えると、上の組み合わせではnative codeまで落とせても、MFCまたはWin32APIを使わなければランタイム不要のコードを生成することができないのでしょうか。もし御存じでしたらご教授いただけたら幸です。

>MFCって単にSDKをラッピングしたclassです。
むしろMFCだけでは出来ない事があるかもしれません。

その点は一応、理解しているつもりでおりました。

Object Orientedなインターフェースを持つAPIがフリーでほしかったのですが、MicrosoftはフリーではMFCを提供していないようでした。
ところが、下のURLをみると、.Net Framework APIもWin32apiのラッパのようなもののようで、
またインターフェースは当然OOなので、
これを使えばMFCも不要なのでは?と思ったしだいです。
でも、書籍をしらべたりすると、MFCを説明しているものが多かったので、なんでかな?と疑問に思いました。

http://www.microsoft.com/japan/msdn/net/general/win32map.asp