calling external fcn in a C++ Lib- trouble

calling external fcn in a C++ Lib- trouble

I have written an ADSRX application for interfacing with AutoCAD that works great. However, I need to add a call to a new fcn they (Autodesk) added to let Autocad know that my app is MDI "aware". I added an explciti interface just as with all the other library fcns and issued the call at the appropriate spot. However, the linker comes up with the ever-popular "unresolved external" message. I use DUMPBIN to check that the fcn was in one of the libs I am linking against and am given the following

  ?acrxRegisterAppMDIAware@@YA_NPAX@Z (bool __cdecl acrxRegisterAppMDIAware(void *))  

My interface looks like this:

        integer*4 function acrxRegisterAppMDIAware(appID)  
!DEC$ ATTRIBUTES C, ALIAS : '_acrxRegisterAppMDIAware' :: acrxRegisterAppMDIAware  
         integer*4 appID  
	end function  

I don't have any experience in C++ and can't quite determine how to declare the interface for this particular fcn since all of the others compile, link and operate fine. Any suggestions?

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

It looks as uf they forgot to declare that particular function extern "C" in VC++ ;-). However, the declaration suggests that it's just an ordinary cdecl function, just the name is mangled in default VC++ fashion. Try copy&paste of that sausage of mangled (?acrxRegisterAppMDIAware@@YA_NPAX@Z) name into ALIAS -- it should work.


Yep, That solves it. Wow, how does the name get magled like that. Is the software that builds the lib responsible (VC++) or is humna actully coming up with this?

This is VC++ default name mangling, used for "typesafe binding". Many C++ compilers use that feature, although it's not standardized. As you can see, (Microsoft's) dumpbin was able to reconstruct entire declaration of the routine based solely on name mangling. extern "C" keyword in C++ headers overrides that decoration and forces "standard" decoration (_Foo@4 for stdcall or _Foo for cdecl); apparently it was forgotten (or purposely left?) in your case.

Leave a Comment

Please sign in to add a comment. Not a member? Join today