ATL COM code will not compile on upgrade to VS2015 - c++

Question

Folks
I am in the process up upgrading a legacy application from VS2008 to VS2015. It is extremely dependent on ATL and COM. I have noticed a change in _ATL_COM_MODULE70 in atlbase.h that is causing issues.
In ...\9.0\VC\atlmfc\include\atlbase.h it is defined as:
struct _ATL_COM_MODULE70
{
UINT cbSize;
HINSTANCE m_hInstTypeLib;
_ATL_OBJMAP_ENTRY** m_ppAutoObjMapFirst;
_ATL_OBJMAP_ENTRY** m_ppAutoObjMapLast;
CComCriticalSection m_csObjMap;
};
However in ...\14.0\VC\atlmfc\include\atlcom.h it is defined as:
struct _ATL_COM_MODULE70
{
UINT cbSize;
HINSTANCE m_hInstTypeLib;
_ATL_OBJMAP_ENTRY_EX** m_ppAutoObjMapFirst;
_ATL_OBJMAP_ENTRY_EX** m_ppAutoObjMapLast;
CComCriticalSection m_csObjMap;
};
This causes the following code not to compile:
HRESULT FreeThreadSingletons (void)
{
for (_ATL_OBJMAP_ENTRY** ppEntry = _AtlComModule.m_ppAutoObjMapFirst; ppEntry < _AtlComModule.m_ppAutoObjMapLast; ppEntry++)
{
if (*ppEntry != NULL)
{
_ATL_OBJMAP_ENTRY* pEntry = *ppEntry;
CComClassFactoryThreadSingleton *pThread;
if ((pThread = dynamic_cast<CComClassFactoryThreadSingleton *>(pEntry->pCF)) != NULL)
{
pThread->ReleaseAllObjects ();
}
}
}
return S_OK;
}
The reason is because m_ppAutoObjMapFirst is of type _ATL_OBJMAP_ENTRY_EX in VC14 and _ATL_OBJMAP_ENTRY in VC9.
Microsoft's documentation for VS2015 says that the struct should be the same in VC14 as in VC9:
https://msdn.microsoft.com/en-us/library/ayw1b6h5.aspx
Now for the question. Has anyone seen this issue in the past and is there a workaround that does not involve rewriting everything to the _ATL_OBJMAP_ENTRY_EX interface?

Answer 1

Thanks for the response H. Guijit. Here is Microsoft's response:
As you have already noticed, the documentation in MSDN at _ATL_COM_MODULE70 Structure is inaccurate.
_ATL_OBJMAP_ENTRY and _ATL_OBJMAP_ENTRY_EX are typedefs for two different structures defined in atlbase.h
Unfortunately, you have fallen victim to code that relies on internal structures and implementations that are subject to change.
Not the most helpful thing I have ever read..
I have changed the code to retrieve IUnknown from pCache->pCF
HRESULT FreeThreadSingletons (void)
{
for (_ATL_OBJMAP_ENTRY_EX** ppEntry = _AtlComModule.m_ppAutoObjMapFirst; ppEntry < _AtlComModule.m_ppAutoObjMapLast; ppEntry++)
{
if (*ppEntry != NULL)
{
_ATL_OBJMAP_ENTRY_EX* pEntry = *ppEntry;
CComClassFactoryThreadSingleton *pThread;
if ((pThread = dynamic_cast<CComClassFactoryThreadSingleton *>((pEntry->pCache)->pCF)) != NULL)
{
pThread->ReleaseAllObjects ();
}
}
}
return S_OK;
}
I am not sure this will work yet as I'm still battling build problems but hope to run the application up in the next day or two.

Answer 2

You can rewrite it like this:
for(auto ppEntry = _AtlComModule.m_ppAutoObjMapFirst; ppEntry < _AtlComModule.m_ppAutoObjMapLast; ppEntry++)
This is always correct, no matter the type of the pointer.
I suppose you could avoid modifying your source with some preprocessor magic, but I would consider doing so to be a bit of a disaster for maintainability.
As for having seen this in the past... Microsoft quite often extends existing structs and functions, and when they do the extended struct or function gets 'ex' appended to its name. 'ex' structs are usually (always?) identical to the older version, just with extra fields. Same with 'ex' functions, which usually just get some extra parameters.