VC++ / MFC TIPS

トップ | 更新 | 惑々 | C++ | Emacs | CVS | doxygen | VC/MFC | Libs | リンク

VC++ / MFC 覚書

去年(2000年)あたりから、仕事の上で、どうしても Windows プログラミングをせざるをえなくなってしまった。やり始めてみると、意外に面白いということが分かったのだが、いかんせん、 Windows プログラミングの頻度はそれほど高くない。しばらくすると、やり方をすっかり忘れてしまったりする。そこで、備忘録として、MSDN ライブラリや書籍類から得た情報を、少しずつまとめていこうと思う。

VC++ 定義済みマクロ (2001-03-13)
プリコンパイル済みヘッダー (2001-12-13)
VC++ の困った癖 (2001-12-13)
ドキュメント型 (2001-03-14)

VC++ マクロシンボル

MSDN ライブラリでは、「組み込みマクロ」、「/U、/u (定義済みマクロシンボルの無効化)」あるいは、「Using the SDK Headers」といったページに、組み込みマクロやターゲット指定のマクロシンボルの一覧がある。組み込みでなくても重要なマクロシンボルが他にもあったりするので、もっと詳しい説明の載ったページがあればご教示ください。

以下に、組み込みでないものも含めて、重要と思われるものを、リストしておく。

シンボル説明

_CHAR_UNSIGNED　　 char型が付号無しの場合 (コンパイラオプションで /J を付けたとき) に定義される。

_MSC_VER コンパイラのバージョンを定義する。VC++ 6.0 の場合は、値として、 1200 が定義されている。

_WIN32 WIN32用にコンパイルする場合に定義される。つまり、常に定義されると思ってよい。

_WIN32_DCOM CreateThreadEx で、COINIT_MULTITHREADED を使う場合に定義する必要がある。

WINVER=0x0400 ターゲットが、Windows95 または WinNT 4.0 以上

シンボル	説明
`_CHAR_UNSIGNED`	char型が付号無しの場合 (コンパイラオプションで /J を付けたとき) に定義される。
`_MSC_VER`	コンパイラのバージョンを定義する。VC++ 6.0 の場合は、値として、 1200 が定義されている。
`_WIN32`	WIN32用にコンパイルする場合に定義される。つまり、常に定義されると思ってよい。
`_WIN32_DCOM`	CreateThreadEx で、COINIT_MULTITHREADED を使う場合に定義する必要がある。
`WINVER=0x0400`	ターゲットが、Windows95 または WinNT 4.0 以上

初出: 2001年3月13日

unix などの環境で開発したソースを、AppWizard が作成したプロジェクトに持ってくるときは、プリコンパイル済みヘッダーの扱いに注意する。AppWizard はデフォルトで、カテゴリ「プリコンパイル済みヘッダー」の「プリコンパイル済みヘッダーファイルを使用」をチェックし、「このヘッダーまで」のところに "stdafx.h" を指定しているからだ。この設定だと、.cpp ソースで stdafx.h をインクルードしていない場合、「プリコンパイル済みヘッダーファイルの検索中に予期しないEOFを検出しました」とかいうふざけたエラーが出てしまう。かといって、Windows に特化していないソースで stdafx.h をインクルードするのは気持ちが悪い。

この不都合は、「プリコンパイル済みヘッダーを自動的に使用」のほうをチェックし、「このヘッダーまで」のところに "stdafx.h" を指定してやれば回避できるようだ。コンパイルオプション的には、前者は、/Fp と /Yu の組み合わせで、後者 (回避策のほう) は、/Fp と /YX の組み合わせとなる。しかし、マニュアルを見ても、両者の違いがよくわからない。私の感覚から言うと、「自動的に使用」のほうが勝手に訳のわからん動作をしそうで怖いのだが……。

初出: 2001年12月13日

VC++ の困った癖

VC++ 6.0 には、いくつか困った癖がある。そのうち、解決法があるものを記録しておく。

warning C4786
STL などのヘッダーファイルを取り込むと、mangle された名前が長くなりすぎるためか、 C4786 (デバッグ情報で使われる識別子が長すぎる) という warning が発生する。
```
c:\program files\microsoft visual studio\vc98\include\vector(48) : warning C4786: 
'??0?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?
$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@
std@@QAE@IABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@1@ABV?
$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@1@@Z' :
識別子が '255' 文字に切り捨てられました (browser 情報内)。
```
この warning を避けるには、
#pragma warning (disable: 4786)
というプラグマを使えばよいらしい。
同じような warning で、C4788 というのもある。こちらは、コンパイラが認識する識別子の長さの制限 (255文字) にひっかかった、ということなので、より深刻なのだが、なぜか、C4876 は発生しても、 C4788 に遭遇した経験はない。これは、
- コンパイラは、255文字より長い識別子もちゃんと扱える
- 255文字で切り捨ててしまっているのだが、warnign を出していない
のどちらなんだろう。

for 文のループ変数
STL などのヘッダーファイルを取り込む場合は、MS独自のコンパイラ拡張機能を ON にしておく必要がある。しかし、この機能を ON にすると、どうしたわけか、
for ( int i; … ) {
などのループ変数が、for の外で宣言されたものとして扱われてしまう。したがって、同じ名前のループ変数を、複数の for 文で使用することができなくなってしまうのだ。
これを解決するには、
#define for if(0);else for
などという手で逃げるしかないようだ。

vector<string> を char * の配列で初期化できない
次のコードは、vector<string> の適切なコンストラクタを選択することに失敗するようだ。
```
	const char *strArray[] = { "foo", "bar", "hoge" };
	vector<string> strVector( strArray, strArray+3 );
```
しかたがないので、resize してから copy という方法で逃げる。
```
	const char *strArray[] = { "foo", "bar", "hoge" };
	vector<string> strVector( 3 );
	std::copy( strArray, strArray+3, strVector.begin() );
```
この方法は、コンストラクタの初期化指定のところに書けないのがつらいところ。

従来の C 標準ライブラリに含まれる識別子は std 名前空間で宣言されていない
```
#include <cstdio>

int main()
{
    std::printf( "foo\n" );
}
	
```
などとやると、VC++ は、「error C2039: 'printf' : 'std' のﾒﾝﾊﾞではありません。」とかいうエラーを返してくれる。要するに、cstdio は、 stdio.h への単なるシンボリックリンクってことか?

std::string は、clear() メソッドをサポートしていない
かわりに、erase() メソッドを使う。

set_new_handler ではなく _set_new_handler を使う
かつ、
- <new> に加え、 <new.h> もインクルードする
- ハンドラ型の名前は、new_handler ではなく、_PNH
- ハンドラ型の定義は、int (*_PNH)( unsigned int )

using std::vector; を宣言しておいても vector<int>::iterator が使えない
やはり、std:: で修飾してやらないといけない。
```
	std::vector<int>::iterator it = vec.begin(); 
```
テンプレートに対する using 宣言は、その instanciation には及ばないのか? 謎だ。

using namespace X; と using X::foo; を同時に宣言すると、オーバーロードの解決が出来なくなる
たとえば、次のようなコードでは、foo のオーバーロードの解決ができない。 (ひょっとすると、C++ の標準仕様かも? g++ では通っちゃうけど)
```
namespace FOO {
void foo( int ch );
void foo( const char *s  );
}

using namespace FOO;
using FOO::foo;

int main()
{
    foo( "abc" );

    return 0;
}	
```

クラステンプレート内でのテンプレート friend 関数の記法

template<class T> class Foo;
template<class T> void func( Foo<T> * );

template<class T> class Foo {
    friend void func<T>( Foo<T> * ); // コンパイルエラー
    friend void func( Foo<T> * );    // コンパイルが通る
};

でも、標準規格は、前者の「コンパイルエラー」のほうだ。

追記: 2001年12月13日
初出: 2001年3月13日

ドキュメント型

文字列リソースの IDR_MAINFRAME などで定義される「ドキュメント型」については、 MSDN ライブラリの「ドキュメントの型を表す文字列リソースの書式」に説明が書いてある。

ここでよく分からないのが、6つめのパラメタ、「ドキュメント型の識別子」である。これは、どうやらレジストリに登録されるものらしい。さらには、次のような記述がある。

「(これが) 指定されていないと、Windows のファイルマネージャは、このドキュメントの型を登録できません。」

おいおい、今どき、「ファイルマネージャ」はないだろう。それとも、ここで言う「ファイルマネージャ」というのは、いわゆる、あの Win3.x 時代の遺物のことではなくて、何か別の物を指しているのだろうか。

まあ、それはともかく、他のパラメタには、ファイル拡張子の指定もあるので、要するに、拡張子との関連付けに使用される識別子、という理解でよいのかな。これについては自信がないので、識者のご教示を乞いたい。

[2001-03-14] 識者より、「ドキュメント型はそーゆーことです。」とのメールあり。Thanks > OGT

初出: 2001年3月13日

トップページへ / Last modified: 2001-12-13 13:21:14 JST
Created by OKA Toshiyuki < oka-t@fides.dti.ne.jp >

シンボル	説明
`_CHAR_UNSIGNED`	char型が付号無しの場合 (コンパイラオプションで /J を付けたとき) に定義される。
`_MSC_VER`	コンパイラのバージョンを定義する。VC++ 6.0 の場合は、値として、 1200 が定義されている。
`_WIN32`	WIN32用にコンパイルする場合に定義される。つまり、常に定義されると思ってよい。
`_WIN32_DCOM`	CreateThreadEx で、COINIT_MULTITHREADED を使う場合に定義する必要がある。
`WINVER=0x0400`	ターゲットが、Windows95 または WinNT 4.0 以上