GDIオブジェクト解放時のDeleteObjectとSelectObjectの順番

Question

疑問

現在MFCでWindowsアプリケーションを開発している者です。

Win32APIの公式ドキュメントで、::DeleteObjectのページに

指定したハンドルが有効でない場合、または現在 DC に選択されている場合、戻り値は 0 です。

描画オブジェクト(ペンまたはブラシ)は、DC で選択されている間は削除しないでください。

と記述がありました。
https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-deleteobject

MFCにおいてもそれは同様と思い、GDIオブジェクトを解放するときはCDC::SelectObject → CGdiObject::DeleteObjectの順番で呼ぶようにしていました（DeleteObjectはCGdiObjectのデストラクタで呼ばれることも認識しています）。
ところが、この順番でなくても正しくGDIオブジェクトは解放されていることに気づき、疑問が生まれ調べましたが、有効な手掛かりが得られず、質問に至っています。

以下に詳細を書いていきます。

実験用のソースコード

// View.cpp

// MFCのクラスを用いた実験
void ResourceLeakTest1(CDC& dc);

//Win32APIを用いた実験
void ResourceLeakTest2(CDC& dc);

static const int penNumber = 5000;

// DeleteObjectを自分で呼ぶためstatic変数
static CPen pens[penNumber];

void MyView::OnDraw(CDC* pDC)
{
    ResourceLeakTest1(*pDC); 
    ResourceLeakTest2(*pDC);
}

void ResourceLeakTest1(CDC& dc)
{
	for (int index = 0; index < penNumber; index++)
	{
		pens[index].CreatePen(PS_SOLID, 0, RGB(200, 200, 0));
		CPen* oldPen = dc.SelectObject(&pens[index]);
                
       // 適当にたくさん円を描く
		dc.Ellipse(CRect(CPoint(10 + index * 2, 10 + index * 2), CPoint(30 + index * 2, 30 + index * 2)));

       // SelectObjectより先にDeleteObjectを呼んでみる。
		BOOL result = pens[index].DeleteObject();

       // 予想では、resultはFALSEになり、ASSERTに引っ掛かる。
       // 仮に引っ掛からなかったとしても、この関数を抜けたときに
       // 5000個のGDIオブジェクトのリソースリークが起きている。
		ASSERT(result != FALSE);

		dc.SelectObject(oldPen);
	}
}

static HPEN hPens[penNumber];

void ResourceLeakTest2(CDC& dc)
{
	HDC hdc = dc.GetSafeHdc();
	for (int index = 0; index < penNumber; index++)
	{
		hPens[index] = ::CreatePen(PS_SOLID, 5, RGB(255, 0, 0));
		HPEN hOldPen = (HPEN)::SelectObject(hdc, hPens[index]);

       // 適当に直線をたくさん描く
		::MoveToEx(hdc, 100 + index * 2, 10, NULL);
		::LineTo(hdc, 10, 100);

       // 先ほどと同様
		BOOL result = ::DeleteObject(hPens[index]);
		ASSERT(result != 0);

		::SelectObject(hdc, hOldPen);
	}
}

実際に起こっていること

GDIオブジェクトのリソースリークは、タスクマネージャーの詳細タブにある「GDIオブジェクト」列で確認しています。

ResourceLeakTest1は、MFCのクラスを用いた実験です。
ソースコード中のコメントに書いた自分の予想に反して、ASSERTに引っ掛からず(DeleteObjectは1を返している)、GDIオブジェクトのリソースリークも起きていませんでした(penNumberの数だけGDIオブジェクトが増えなかった)。

ResourceLeakTest2はWin32APIを使った実験です。こちらも、同様の結果となりました。

なお、ソースコード中のDeleteObjectをコメントアウトすると、当たり前ですがGDIオブジェクトがpenNumberの数だけ(今回は5000個)増えました。

教えていただきたいこと

なぜ、リソースリークが起きないのでしょうか。
また、公式にこのことについて言及している記事があれば教えてください。

よろしくお願いいたします。

Answer 1

完全に信用に足る情報とは言えませんが…

ここの１つ目の回答が同じような実験をしており，２つ目の回答がそれに関する話をしている様子です．（公式にドキュメントされてはいないけれども，あまりにも多くの人がここでミスるのでちょっとした対策が講じられている…という話っぽい？　ただし示されているリンク先がForbiddenで見れないみたいです）

https://stackoverflow.com/questions/8500137/

Comments

[fana]

本当に削除が遅延されるような仕組みになっているのかもしれませんが，（残念ながら）それが正式なドキュメントに書かれていない以上，我々があえてそのことを前提とした実装を行う理由はないので，その意味で「どうでもいい」話でしかない，と思います．

[Kosho9513]

ご回答いただきありがとうございます。
リンク先のやりとりを読みました。Forbiddenの記事もぜひ読んでみたかったです。。。
公式ドキュメントに書いてあることと実際の動きが異なることが気持ち悪くて、なぜなのか知りたかったのですが、fana様がおっしゃるように、実際の実装では公式で推奨されていない方法をあえて選択しないようにします。

[KOZ6.0]

これかな？
https://devblogs.microsoft.com/oldnewthing/20130306-00/?p=5043

[Kosho9513]

ありがとうございます。
おそらくこれだと思います！
英語が苦手なので、じっくり読んでみます。