Visual Studio 2005の機能限定版が、無料で配布されています。 Visual Studio 2005 Express Edition は、デバッガ、インテリセンス付エディタがフルに使える統合環境です。 ここでは、Visual C++ Express Editionでどこまでできるか検討してみました。
Visual Studio 2005の機能限定版が、無料で配布されています。 Visual Studio 2005 Express Edition は、デバッガ、インテリセンス付エディタがフルに使える統合環境です。 ここでは、Visual C++ Express Editionでどこまでできるか検討してみました。
Express Editionは、プログラミング学習、.NET Frameworkの開発が前提になっています。
そのため、デフォルトでは従来のWIN32 APIを利用した開発ができません。
Platform SDKの追加インストールが必要です。
XPなどでも、WindowsR Server 2003 SP1 Platform SDKで問題ないです。
下のリンクを参考にしてください。
なお、説明内容が微妙に間違っています。 プロジェクトの作成時に、[WIN32コンソールアプリケーション]を選んだ後でないと、 [Windowsアプリケーション]が選択できません。 [WIN32コンソールアプリケーション]を選んだ後, [アプリケーションの設定]で[Windowsアプリケーション]が選択可能です。 [DLL]を選べば、ネイティブDLLプロジェクトも作成できます。
Visual C++ 2005 Express Edition と Microsoft Platform SDK を一緒に使うウィザードが生成したソースを見ると、WinMain()が_tWinMain()になってますが、基本的に一緒です。 UNICODEコンパチの関係で2003くらいからこうなってます。
Platform SDKには、古いですが、ATL3.0が付属しています。
もしや、無料でWTLの開発環境が構築できるのでは!?
というか、私にとってはこれが本題でした。
いろいろ試した結果、準備は必要ですが、WTL開発可能です。
プロジェクト作成ウィザードも使えます。
でも、リソースエディタが使えません。あぅ。
まず前提として、Platform SDKをインストールしておいてください。 2006年1月現在、WTL8.0が最新版です。SourceForgeからダウンロードできます。
SourceForge WTL
WTLのパッケージにはセットアップ用のスクリプトが付属しているのですが、
Express Editionではスクリプトがうまく動作しないようです。
手動でセットアップする必要があります。
WTL8.0.6137 以降、Express Edition用のセットアップスクリプトが追加されました。
ATLが3.0と古いため、一部編集が必要です。
何のためにSDKに入ってるんだか・・・
WTL8.0.6356 以降、ATLの編集が不要になりました。
stdafx.h にWTL_USE_SDK_ATL3マクロが追加され、リンカオプションで対応するようになりました。
atlthunk.libが最新のSDKに入ってません。
Visual C++ .NET2003のソースを参考に編集しているので、問題ないと思います。
//PVOID __stdcall __AllocStdCallThunk(VOID);
//VOID __stdcall __FreeStdCallThunk(PVOID);
//#define AllocStdCallThunk() __AllocStdCallThunk()
//#define FreeStdCallThunk(p) __FreeStdCallThunk(p)
#define AllocStdCallThunk() HeapAlloc(GetProcessHeap(),HEAP_GENERATE_EXCEPTIONS,sizeof(_stdcallthunk))
#define FreeStdCallThunk(p) HeapFree(GetProcessHeap(),0,p)
//#pragma comment(lib, "atlthunk.lib")
以前のVCは、C++標準仕様を勝手に拡張しており、この記述が許されていました。
しかし、2005で標準仕様に準拠したらしく、古いATLのコードがエラーになっています。
for(int i = 0; i < m_aChainEntry.GetSize(); i++)
FAQを見る限り、Express Editionで作成したアプリは、商用配布も可のようです。
フリーのアプリを配布しても、全然問題ないでしょう。
配布する場合、一般のPCでも動作するように、以下の点に気をつけましょう。
VCを使ったことのある人にはわかりきったことだと思いますが、 デフォルトのプロジェクトはDebug用で、配布用ではありません。 [ビルド]-[構成マネージャ]で、Releaseに変更してください。
VC2005では、CRTのバージョンが8.0です。
一般ユーザのPCには、8.0なんてまずインストールされていません。
コンソールアプリやWIN32アプリの場合、そのまま配布するとまず動きません。
プロジェクトのプロパティを開き、[C/C++]-[コード生成]-[ランタイムライブラリ]を
マルチスレッド(/MT)に変更してください。
VC2005では、デフォルトでUNICODEになっています。
古いOSで動かしたいなら、UNICODEは止めたほうがいいです。
プロジェクトのプロパティを開き、[構成プロパティ]-[全般]-[文字セット]を
「マルチバイト文字セットを使用する」に変更することお奨めします。
また、VC2005でUNICODEにすると、どっかにバグがあったと思います。
内容は忘れましたが、そのうちSPで直るでしょう。
SDKの追加インストールは必要なものの、Express Editionは製品版と遜色ない 機能を持っています。が・・・
MFCは、ウィザードとの連携がないとほとんど意味がないです。
VC6.0用のプロジェクトをテンプレートに使うこともできなくはないでしょうが・・・
ATLはまだなんとかなるかも。MIDLも使えるし。
ここまでネイティブWIN32やWTLにこだわって書いてきましたが、 今後はやっぱり.NET Frameworkでの開発がメインになってくるんじゃないでしょうか。 というか、なった方がいいと思う。
2005 Express Editionの登場で、.NET Frameworkの開発環境は万全です。 ネイティブWIN32のリソースエディタが使えませんが、 .NET Frameworkではより強力なフォームデザイナが使えます。
ATL、MFCも使えませんが、C#, C++, VB共通のクラスライブラリが使えます。 パフォーマンスが必要なところはC++で書いて、 生産性重視のところはC#、なんてのも当たり前にできます。 正直、もうMFCはいらないと思う・・・
Window32 APIを使ってC/C++でゼロからごりごり書くのにこだわる人も
結構いると思います。私も、コンソールアプリつくるのにFrameworkは要らないと思うし。
でも、.NET Frameworkには普及して欲しいです。
やっぱ便利ですんで。
世の中にもうちょっと普及してくれれば、
Frameworkは互換性がちょっと・・・なんてこともなくなるはずです。
Frameworkで作成された市販アプリがもっと出てこれば普及すると思うんですが。
.NET FrameworkをC++を使って記述する場合、 Visual C++ 2005では、C++/CLIというものを使います。 2003では、共通言語仕様に合わせるため、拡張C++が使用されていました。 2003の拡張C++がマイクロソフト固有だったのに対し、 C++/CLIは、標準規格として登録される模様です。
CLIの拡張機能・制限事項は、ほとんどGC(ガベージコレクション)に
かかわるものです。
2003の時の、__gcのようなアンダースコア付のキーワードはなくなりましたが、
ポインタでもC++参照でもない、GC参照という妙なものができました。
^ であらわします。
String^ s = gcnew String();
GC参照であることを明示したいというのはわかるんですが、^ はねぇ・・・
こんなのC++じゃないや!って人は、おとなしくC#を使ったほうがいいかも。 違う言語なら、仕様が違うのも当然ですから納得できます。 私もそうしてます。 中途半端にC++とついてるから、違和感あるんですよね。。。
それでもC++を使うメリットは、パフォーマンス上の利点だけでなく、 マネージ・コードとネイティブ・コードを混在できることです。 フォームなどの外観は.NET Frameworkでつくっておいて、 内部は従来のWindows APIで実装、なんてことが平然とできます。 というか、そのためのC++です。 windows.hのヘッダがそのまま使えます。 C#やVBみたいに、いちいちAPIの宣言を書く必要がありません。
2003の頃はとっても使いにくかったマネージ拡張C++ですが、 C++/CLIのおかげで、C#いらないくらい使いやすいです。