最近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.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を学ぶ意義は将来性を考えても十分にある、というように理解いたしました。
ありがとうございました。
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.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.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/ …
お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!
似たような質問が見つかりました
- その他(コンピューター・テクノロジー) .NET Frameworkがコントロールパネル>プログラムと機能に表示されない。 3 2022/12/31 15:33
- Windows 10 このWindowsUpdateの失敗メッセージは何を物語るか? 5 2023/07/17 11:49
- その他(セキュリティ) Software Distribution folder の rename 手順 1 2022/08/19 13:08
- Visual Basic(VBA) フレームワーク「4.8.1」で、[Sub Main]が動かない。助けて下さい 3 2022/11/14 15:40
- ソフトウェア VisualStudio のデータブレークポイントを有効にする方法 1 2023/05/01 09:42
- プリンタ・スキャナー Brother MFC-7460DNの一時停止解除について 1 2022/12/03 12:38
- その他(コンピューター・テクノロジー) (コマンドプロンプト)コマンドプロンプトのactiveについて 2 2022/07/16 17:21
- ノートパソコン Win10 EXCEL でのエラー 2 2022/04/03 15:57
- Visual Basic(VBA) VBAでArrayListを使う為の「mscorlib.tlb」の参照設定について 3 2022/03/23 19:45
- C言語・C++・C# ActiveXコントロールを.NETにインポートできない??? 2 2023/05/02 02:50
このQ&Aを見た人はこんなQ&Aも見ています
-
性格の違いは生まれた順番で決まる?長男長女・中間子・末っ子・一人っ子の性格の傾向
同じ環境で生まれ育っても、生まれ順で性格は違うものなのだろうか。家庭教育研究家の田宮由美さんに教えてもらった。
-
【VC++】MFC、C++/CLI(CLR)、C#の違い、及び、これからの展望
C言語・C++・C#
-
C言語で、メモリを解放しないで終わるプログラム
C言語・C++・C#
-
ボタンの表示の色、フォントを変更したい
C言語・C++・C#
-
-
4
排他的論理和 BCC(水平パリティ《偶数》)の算出
C言語・C++・C#
-
5
MFCとC++/CLIとの比較
C言語・C++・C#
-
6
Visual C++とVisual C++.NETの違い
その他(プログラミング・Web制作)
-
7
CString から LPCTSTRの型に変換
C言語・C++・C#
-
8
エディットコントロールのイベントハンドラ
Microsoft ASP
-
9
C++でのCRLFについて
C言語・C++・C#
関連するカテゴリからQ&Aを探す
おすすめ情報
このQ&Aを見た人がよく見るQ&A
デイリーランキングこのカテゴリの人気デイリーQ&Aランキング
-
web2.0以前のインターネットで...
-
C言語とhtmlの違いを どな...
-
プログラムに書かれる"%"記号の...
-
C言語、C+、C++、C#の違い
-
アカデミックパックが使いづら...
-
今、コンピューター言語で、COB...
-
C言語って古いですか?
-
UNITY Float型の接尾辞fって
-
COBOLでのNOT = の AND条件
-
ホワイトハッカーを目指そうか...
-
C++における継続行
-
UWSCはどのプログラミング言語?
-
Delphiに詳しい方助けてくださ...
-
先日、技術の授業がありました...
-
Excel VBAで文字化けする (英語...
-
HTMLとC++で、どんなホームペー...
-
COBOLで文字タイプを数字...
-
順列の内容をすべて表示するプ...
-
C++の将来性・・・
-
GMLとは何でしょうか
マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング
-
C言語、C+、C++、C#の違い
-
プログラム言語について c言語...
-
プログラムに書かれる"%"記号の...
-
C言語とhtmlの違いを どな...
-
vbaとc言語の関連性について
-
AIって何のソフトで作っている...
-
UNITY Float型の接尾辞fって
-
COBOLでのNOT = の AND条件
-
TO_CHARで小数点以下がある場合...
-
COBOLで文字タイプを数字...
-
プログラム言語について プログ...
-
C++における継続行
-
swift言語の最適化 swift最適化...
-
VBSとWSHは読み方が違うだけで...
-
C++ ってなんて読む?
-
web2.0以前のインターネットで...
-
Excel VBAで文字化けする (英語...
-
VBSでDim、Private、Publicの違い
-
HTMLとC++で、どんなホームペー...
-
Pythonって何を意識した言語な...
おすすめ情報