Why does CDC::SelectObject(CFont*) accept a CFont object vs. a pointer? - c++

Question

CPaintDC dc(this);
CFont font;
dc.SelectObject(font); // why does this build?
The function CDC::SelectObject takes a pointer of type CFont but why does this build with providing an object? I came across this issue that the above code is unpredictable and can crash sometimes but not always.

Answer 1

The code in question is valid, sort of. It compiles due to a combination of two things:
The CFont::operator HFONT().
An undocumented CDC::SelectObject overload taking an HGDIOBJ handle.
When the compiler tries to match an overload for dc.SelectObject(font), none of them match. So next it tries the user-defined conversion operator (operator HFONT()) that returns an HFONT. That matches the undocumented overload taking an HGDIOBJ (both HGDIOBJ and HFONT are typedef'd as void*).
The code posted in the question is almost correct, too, with 2 exceptions:
The font object is destroyed while still being selected into a device context. While this causes a double-delete bug (the font object is owned by the CFont instance and the device context), the call to DeleteFont gracefully fails when passed an invalid handle.
The font object previously selected into the device context is lost, and thereby leaked.
Neither issue causes unpredictable behavior or intermittent crashes. As explained in your answer, the real code, however, looks like this:
CFont* pOldFont = (CFont*) dc.SelectObject(font);
That is a bug that exhibits undefined behavior. dc.SelectObject(font) returns an HGDIOBJ (typedef'd as void*), which is subsequently cast to an unrelated type (CFont*). While storing the font previously selected into the device context to later restore it is correct, the code is not. An implementation that honors ownership could be:
CPaintDC dc(this);
CFont font;
CFont oldFont;
// Transfer ownership of font to the DC, and the previously selected font into oldFont
oldFont.Attach(dc.SelectObject(font.Detach()));
// Use dc
// Transfer ownership back
font.Attach(dc.SelectObject(oldFont.Detach()));
// oldFont goes out of scope; this a no-op since it no longer owns any resources
// font goes out of scope, releasing all resources owned by it
// dc goes out of scope, releasing all resources owned by objects selected into it
If you are willing to temporarily sacrifice strict ownership semantics, you can make your life easier by using the more standard implementation:
CPaintDC dc(this);
CFont font;
CFont* pOldFont = dc.SelectObject(&font);
// Use dc
dc.SelectObject(pOldFont);
This is safe, even if you exit early, without restoring the device context. It would still lead to a double-delete on the font object owned by both the CFont instance and the device context (which is handled gracefully by the API). It doesn't exhibit a font leak, though, because things are more complicated than it seems: There is another invisible owner involved here, a map controlled by MFC that stores temporary objects (like those returned from CGdiObject::FromHandle, which SelectObject(CFont*) calls). The temporary objects are cleaned up as part of MFC's idle time processing.

Answer 2

I agree with answer by IInspectable and here is my own proof of concept how this works:
#include "stdafx.h"
#include <iostream>
class A {
int a_int = 6;
char* a_carp = "A derived";
public:
operator int() { return a_int; }
operator char*() { return a_carp; }
};
class B : public A {
float b_float = 5.7;
char* b_carp = "B Derived";
public:
operator float() { return b_float; }
operator char*() { return b_carp; }
};
void Print(char * text)
{
std::cout << text << std::endl;
}
int main() {
B b_obj;
// long a = b_obj;
char* c_p = b_obj;
Print(b_obj);
return 0;
}
The above code builds and the output is "B Derived".
How does it works?
When we use an object in place of a different type, the object looks for appropriate conversion operator. If it finds it, it applies it and converts that for you.
In this case, that operator was HFONT(). It is important to note the actual name of the operator doesn't matter, its the return type/signature that matters. So when it finds a match (correct signature), it calls it.
Why unpredictable behavior?
Let me clear that as well since I mention that in OP. The code I posted was related to build issue but the actual code was this:
CFont* pOldFont = (CFont*) dc.SelectObject(font);
And the forced typecasting (CFont*) was the problem. If we pass HGDIOBJ to SelectObject(), it returns HGDIOBJ but it was forced typecasted to CFont * and that was the problem so there is nothing else wrong with using conversion operators.