最近Windowsプログラミングに興味を持ちましていろいろと調べている所なのですが、疑問に思ったので質問させて下さい。
質問の内容はタイトルどおりなのですが、
windowsのシステムが.Net Frameworkに統一されようとしている今、.Net Framework APIがあればMFCを新しく勉強する価値は殆どないと思うのですが、この考えは間違っているでしょうか?
例えば、下の本(実物はまだ見てません)
http://www.amazon.co.jp/exec/obidos/ASIN/4797324 …
では「 MFCを利用したWindowsネイティブプログラムから,最新の.NETアプリケーションの作成方法まで,..」
と紹介されてますが、VC++.NETでプログラミングするのに、なんでMFC?なんて思って仕舞うのですが、MFCでないと出来ないことがあるのでしょうか?
No.1
- 回答日時:
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/ …
No.2
- 回答日時:
.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.3
- 回答日時:
あなたの言っていることは「アセンブラがあればプログラミングできるのに、どうして他の言語が存在するんですか?」というのと変わりません。
これって適材適所ですよね?
ご回答有難うございます。
んー、そう言っているつもりはなかったのですが、「適材適所」と言う点に関しては、理解できます。
(でも「アセンブラがあれば..」という例えは、私が言いたいこととは少しはずれているかな?と思います。
しかし、そうおっしゃりたい気持になったことはなんとなく分ります。)
このような質問をさせていただいたの背景をもう少し説明させていただくと、
将来性を考えた、もう少し思想的、理念的なモノのつもりなんです。
(しかし、質問の言い方は強すぎました。
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.4ベストアンサー
- 回答日時:
>.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を学ぶ意義は将来性を考えても十分にある、というように理解いたしました。
ありがとうございました。
お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!
このQ&Aを見た人はこんなQ&Aも見ています
-
【大喜利】【投稿~9/7】 ロボットの住む世界で流行ってる罰ゲームとは?
ロボットの住む世界で流行ってる罰ゲームとは?
-
フォロワー20万人のアカウントであなたのあるあるを披露してみませんか?
あなたが普段思っている「これまだ誰も言ってなかったけど共感されるだろうな」というあるあるを教えてください
-
映画のエンドロール観る派?観ない派?
映画が終わった後、すぐに席を立って帰る方もちらほら見かけます。皆さんはエンドロールの最後まで観ていきますか?
-
海外旅行から帰ってきたら、まず何を食べる?
帰国して1番食べたくなるもの、食べたくなるだろうなと思うもの、皆さんはありますか?
-
天使と悪魔選手権
悪魔がこんなささやきをしていたら、天使のあなたはなんと言って止めますか?
-
ボタンの表示の色、フォントを変更したい
C言語・C++・C#
-
C言語で、メモリを解放しないで終わるプログラム
C言語・C++・C#
-
CString から LPCTSTRの型に変換
C言語・C++・C#
-
関連するカテゴリからQ&Aを探す
おすすめ情報
- ・漫画をレンタルでお得に読める!
- ・人生のプチ美学を教えてください!!
- ・10秒目をつむったら…
- ・あなたの習慣について教えてください!!
- ・牛、豚、鶏、どれか一つ食べられなくなるとしたら?
- ・【大喜利】【投稿~9/18】 おとぎ話『桃太郎』の知られざるエピソード
- ・街中で見かけて「グッときた人」の思い出
- ・「一気に最後まで読んだ」本、教えて下さい!
- ・幼稚園時代「何組」でしたか?
- ・激凹みから立ち直る方法
- ・1つだけ過去を変えられるとしたら?
- ・【あるあるbot連動企画】あるあるbotに投稿したけど採用されなかったあるある募集
- ・【あるあるbot連動企画】フォロワー20万人のアカウントであなたのあるあるを披露してみませんか?
- ・映画のエンドロール観る派?観ない派?
- ・海外旅行から帰ってきたら、まず何を食べる?
- ・誕生日にもらった意外なもの
- ・天使と悪魔選手権
- ・ちょっと先の未来クイズ第2問
- ・【大喜利】【投稿~9/7】 ロボットの住む世界で流行ってる罰ゲームとは?
- ・推しミネラルウォーターはありますか?
- ・都道府県穴埋めゲーム
- ・この人頭いいなと思ったエピソード
- ・準・究極の選択
このQ&Aを見た人がよく見るQ&A
デイリーランキングこのカテゴリの人気デイリーQ&Aランキング
-
C言語、C+、C++、C#の違い
-
プログラム言語について c言語...
-
COBOLでのNOT = の AND条件
-
C++における継続行
-
delphi vs c
-
昔、MZ-2000やX1でBASICを書い...
-
クオンツに必要なプログラミン...
-
C言語習得したいけど本が高い・・
-
VBSでDim、Private、Publicの違い
-
プログラミング言語について
-
vbaとc言語の関連性について
-
ゲーム作成
-
昔使っていた言語って覚えてますか
-
C言語を好きになりたいのでメリ...
-
UWSCはどのプログラミング言語?
-
今、コンピューター言語で、COB...
-
FORTRANと他の言語(c、c++、ba...
-
C,C++,C#には共通点があるので...
-
なぜvisual basicは単品販売なし?
-
グラフライブラリを自作するに...
マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング
-
今ってプログラミング言語は何...
-
C言語、C+、C++、C#の違い
-
プログラミング言語について
-
COBOLでのNOT = の AND条件
-
近年誕生したプログラミング言語
-
UNITY Float型の接尾辞fって
-
C言語とhtmlの違いを どな...
-
vbaとc言語の関連性について
-
C++における継続行
-
プログラムに書かれる"%"記号の...
-
COBOLで文字タイプを数字...
-
VBSでDim、Private、Publicの違い
-
TO_CHARで小数点以下がある場合...
-
VBSとWSHは読み方が違うだけで...
-
Excel VBAで文字化けする (英語...
-
VCとVC++
-
HTMLとC++で、どんなホームペー...
-
C++ ってなんて読む?
-
UWSCはどのプログラミング言語?
-
会計システムをつくるために必...
おすすめ情報