Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C++ VC
I came across an odd feature in Visual Studio 2012 today.
 
The symptom is that an executable was unable to find an exported function in one our DLLs. This code functions properly when built in VS 2008.
 
I finally determined the issue. The calling executable was looking for a virtual destructor for the class, but the class itself did not contain a virtual destructor. There is a mismatch in the name mangling between the dll and the caller.
 
Clearly the workaround is simple and straight forward. But it will take time to find all of the instances in our code where this manifests.
 
Is this a new requirement of 2012, or a bug?
Posted 10-Jul-13 11:27am
Comments
Sergey Alexandrovich Kryukov at 10-Jul-13 16:28pm
   
A code sample could help to understand the issue...
—SA
JackDingler at 10-Jul-13 16:47pm
   
I may try a code sample this evening. Should be easy to reproduce.
 
I'm in the habit of making destructors virtual by default.
In this case I'm porting legacy code.
The_Inventor at 11-Jul-13 2:32am
   
MSW has been closing the security holes where it can find them. There was a big change in VS2012 from VS2008. VS is no exception. Not having a destructor, virtual or otherwise, in a .dll is bad if there is a class structure involved. It leaves fragments of memory open to abuse.
JackDingler at 11-Jul-13 9:17am
   
No there is a destructor.
 
The class definition says it's non-virtual. The exported function in the DLL is clearly marked as non-virtual.
 
But the calling application is looking for a virtual destructor and not finding it.
 
What surprised me is that it didn't produce a link time error. I'll check the lib file and see if it differs from the DLL.
JackDingler at 11-Jul-13 10:36am
   
I think I solved the mystery, what likely happened is that I had changed the class to a virtual, and then reverted the change, but the project make didn't update the library on the revert.

1 solution

Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

Microsoft requires it. Read it for yourself: a little funny: "Note that these rules are the same for nonexportable classes."
 
http://msdn.microsoft.com/en-us/library/81h27t8c(v=vs.80).aspx[^]
  Permalink  
Comments
JackDingler at 15-Jul-13 14:00pm
   
Thank you very much. My 5. :)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 OriginalGriff 304
1 Sergey Alexandrovich Kryukov 295
2 Shweta N Mishra 216
3 Maciej Los 210
4 PIEBALDconsult 184
0 OriginalGriff 7,630
1 Sergey Alexandrovich Kryukov 7,022
2 DamithSL 5,586
3 Manas Bhardwaj 4,946
4 Maciej Los 4,525


Advertise | Privacy | Mobile
Web04 | 2.8.1411023.1 | Last Updated 15 Jul 2013
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100