Share a C ++ language & ATL higher order reading notes, you need to jump on the next series in the C ++ language features, it should be considered a quality piece of paper.
class ATL_NO_VTABLE CHello :
// ...
public CComControl<CHello>
{
// ...
}
Leaf classes, inheritance CComControl, incoming himself as a template parameter. ( ATL implement static polymorphism audience skills)
template <class T, class WinBase = CWindowImpl< T > >
class ATL_NO_VTABLE CComControl : public CComControlBase, public WinBase
{
public:
CComControl() : CComControlBase(m_hWnd) {}
// ...
}
CComControl there is a default template arguments CWindowImpl, and CWindowImpl also use the leaves as a class template parameter.
In the initialization list CComControlBase used m_hWnd come a little monster:
m_hWnd is WinBase bring (multiple inheritance)
m_hWnd this time there is no effective value
Because the sub-object CComControlBase prior to the child object WinBase configuration, the child object WinBase allocated only memory (explained below bar)
Here it violates the principle of "use in declaration order" using the member is not initialized, enter the danger zone.
m_hWnd this time there is an effective memory space.
Because leaf objects CHello space has been allocated, the initial value of each member variable is being established by the constructor.
Although CComControlBase using an uninitialized leaves bring class member variable, but be careful to use is still valid.
class ATL_NO_VTABLE CComControlBase
{
public:
CComControlBase(HWND& h) : m_hWndCD(h)
{
memset(this, 0, sizeof(CComControlBase));
m_phWndCD = &h;
// ...
}
// ...
// Attributes
public:
#pragma warning(push)
#pragma warning(disable: 4510 4610) // unnamed union
union
{
HWND& m_hWndCD;
HWND* m_phWndCD;
};
#pragma warning(pop)
// ...
}
Here we enter CComControlBase magical constructor
It himself (as a sub-object) have cleared the memory: the start address of this, the length of their size clears the sizeof (CComControlBase)
Note that this argument is a reference by value and pass by reference here will differ very different (not past almost, mainly optimization)
m_phWndCD assigned address parameters. Small language features Venue:, taking reference address value, because the parameters are consistent with the reference address value referenced object.
Back CComControl constructor initializes the list of issues, child objects CComControlBase of m_phWndCD now points to the other sub-object WinBase in m_hWnd members.
Design discussion: CComControlBase to use a HWND parameter, there is no further use templates, but simply use a member variable. Although CComControlBase child objects and WinBase child objects live in a home - Chello leaf objects inside, CComControlBase should be possible to use a template, we will further m_phWndCD share memory overhead removed. Why not? In order to avoid excessive entanglement, it becomes complicated (for ease of independent thinking and understanding), or HWND need some independence?
Language features curved around: Zaiyu union utility
He said language book "quote once copied, it can not be modified" dark world that's not true. Here you should use some of the underlying characteristics of the language, as well as some of the naming conventions when Windows programming.
Anonymous union let m_hWndCD with m_phWndCD share a memory, by modifying m_phWndCD, we changed the reference value of m_hWndCD!
Between Windows programming naming conventions, we are accustomed to this practice m_pXXX == & m_XXX, the same is true here
&m_hWndCD == m_phWndCD
*m_phWndCD == m_hWndCD
A little crazy, both access methods to the same memory, but still get the same value or, worse m_hWndCD == m_hWnd, this is definitely for the test of the C ++ language willpower!
This article is reproduced at: http://blog.sina.com.cn/s/blog_843c41c80101h3x9.html