Answered by:
Compiling 64-Bit Results in a 2259 (Cannot instantiate abstract class)

Question
-
I built a shell context menu extension based on the sample code in the SDK. It compiles just fine for 32 bit, but when I try to compile for 64-bit I get the 2259 error.
This is the output: Why does this work for 32 bit and not 64? Thanks.
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include\atlcom.h(1801) : error C2259: 'ATL::CComObject<Base>' : cannot instantiate abstract class
1> with
1> [
1> Base=CEojShellExt
1> ]
1> due to following members:
1> 'HRESULT IContextMenu::GetCommandString(UINT_PTR,UINT,UINT *,LPSTR,UINT)' : is abstract
1> C:\Program Files\Microsoft SDKs\Windows\v6.1\Include\shobjidl.h(1978) : see declaration of 'IContextMenu::GetCommandString'
1> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include\atlcom.h(1790) : while compiling class template member function 'HRESULT ATL::CComCreator<T1>::CreateInstance(void *,const IID &,LPVOID *)'
1> with
1> [
1> T1=ATL::CComObject<CEojShellExt>
1> ]
1> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include\atlcom.h(1881) : see reference to class template instantiation 'ATL::CComCreator<T1>' being compiled
1> with
1> [
1> T1=ATL::CComObject<CEojShellExt>
1> ]
1> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include\atlcom.h(1877) : while compiling class template member function 'HRESULT ATL::CComCreator2<T1,T2>::CreateInstance(void *,const IID &,LPVOID *)'
1> with
1> [
1> T1=ATL::CComCreator<ATL::CComObject<CEojShellExt>>,
1> T2=ATL::CComCreator<ATL::CComAggObject<CEojShellExt>>
1> ]
1> .\EojExt.cpp(14) : see reference to class template instantiation 'ATL::CComCreator2<T1,T2>' being compiled
1> with
1> [
1> T1=ATL::CComCreator<ATL::CComObject<CEojShellExt>>,
1> T2=ATL::CComCreator<ATL::CComAggObject<CEojShellExt>>
1> ]
http://digitalcamel.blogspot.com - .Net, ILM, SQL and Anything Else That Falls Out Of My BrainWednesday, April 22, 2009 7:06 PM
Answers
-
Actually, I'm compiling on a 64-bit system. The code was originally written on a 32-bit system.
I replaced the function prototype with a version that looks like the one it's complaining about and the code now compiles fine for both platforms. I don't know if that's the proper way to deal with it, but it seems to be working. If I find that there are issues, I'll post them.
J
http://digitalcamel.blogspot.com - .Net, ILM, SQL and Anything Else That Falls Out Of My Brain- Marked as answer by Jerry Camel Thursday, April 23, 2009 1:37 AM
Thursday, April 23, 2009 1:37 AM
All replies
-
Okay... I think I understand a bit of what's happening... The 64-bit header defines the GetCommandString function with a different signature than the 32 bit header. (At least I think that's what's happening.)
GetCommandString(UINT_PTR,UINT,UINT *,LPSTR,UINT) - 64-bit
vs.
GetCommandString(UINT,UINT,UINT *,LPSTR,UINT) - 32-bit
So the question is, how do you implement this so it can be compiled either way?
Thanks.
J
http://digitalcamel.blogspot.com - .Net, ILM, SQL and Anything Else That Falls Out Of My BrainWednesday, April 22, 2009 7:16 PM -
From the output above it appears you are compiling on a 32 bit system. Is that correct?
I recall having lots of problems cross compiling to the non-native architecture for anything with (D)COM/ATL in it. Have you tried compiling the code on a 64 bit platform? I know there's a workaround for this issue but I just spent 10 minutes looking for it without any luck.
Joseph w Donahue joseph@odonahue.com www.odonahue.comThursday, April 23, 2009 1:19 AM -
Actually, I'm compiling on a 64-bit system. The code was originally written on a 32-bit system.
I replaced the function prototype with a version that looks like the one it's complaining about and the code now compiles fine for both platforms. I don't know if that's the proper way to deal with it, but it seems to be working. If I find that there are issues, I'll post them.
J
http://digitalcamel.blogspot.com - .Net, ILM, SQL and Anything Else That Falls Out Of My Brain- Marked as answer by Jerry Camel Thursday, April 23, 2009 1:37 AM
Thursday, April 23, 2009 1:37 AM