Crash on deallocating temporary?

[LB]

Say I have this as a DLL's code:

std::string Name()
{
    return("My Plugin Name");
}

This DLL is loaded dynamically and the Name function pointer is retrieved via GetProcAddress like below:
std::string (*Name)() = (std::string (*)())GetProcAddress(DLL, "Name");
This works perfectly fine. Now, here's the problem:
std::string name = Name(); //crash!
The name is properly returned and such, the problem comes when the program goes to deallocate the temporary string object returned by the DLL's Name function.

What am I doing wrong and how can I fix it without pointers or references? I'm having this problem throughout most of my application and it's really causing huge issues...

[webJose]

Are you compiling the DLL with the same compiler as the program?

[LB]

Yes, I've made sure the settings are the same and that the calling conventions match, and they are both being compiled in Debug mode.

[webJose]

I just produced a test solution in Visual Studio 2010 and everything worked OK for me using debug builds. I exported the DLL function using extern "C" __declspec(dllexport), in case that matters.

What compiler are you using? Can you reproduce the issue in another compiler?

[LB]

I'm using VC++2008, and unfortunately I cannot reproduce it in a new project.

Should I create new projects to reset the settings and copy everything into them?

[webJose]

Well, desperate times call for desperate measures, I guess. If you are cornered, do so. But do it slowly. Try to do it in chunks and test after each chunk is migrated. If it happens again, you should be able to get an idea of what chunk of code did it.

[webJose]

But just so you know, if you are planning to allow third party plugins, this cannot work. STL implementations vary from one compiler to the next and even the final binary can have important differences that will for sure make your program crash. It can even crash if the DLL is compiled with the same compiler, different version!

If you want to create plugins, you must not use C++ classes. You must limit yourself to use C data types only. This is why COM is like it is: Classes are simply not binary-compatible. The only common ground between C++ compilers is the way they export C functions. If you really want objects, go for a full blown COM plugin architecture.

[LB]

That's a problem I will have without even writing any code at all in the DLL, as both the DLL and the main app need to utilize a library that may or may not have been compiled for the same version as they expect. If I am to plan for different compilers and such, then I am to abandon this entire project :p

[webJose]

Well, better to find out early that late I say. The only decent choice for plugins that I know of in C++ is COM.