Worrying std::string problem
Has there been some fundamental change to std::string between VS2005 and VS2015?
I'm building an app with VS2015 (which I only recently installed). It links to some DLLs that were built with VS2005. Sooner or later I'll get around to re-building the DLLs but I figured I should be okay for s short while. I know there are various things to avoid - such as not allocating memory in a VS2005 DLL and then trying to free it in a VS2015 app but I didn't anticipate a problem with std::string. Take this function as an example:-
Code:
void some_func()
{
std::string test = call_some_func_in_the_vs2005_dll();
// rest of function...
}
The function is in my main app - so test will be of whatever type of string is known to VS2015. But call_some_func_in_the_vs2005_dll() returns a std::string as it was previously known to VS2005. This allocation from one type to the other type invariably crashes my program. It doesn't necessarily crash it at the point of assignment. Usually the crash happens when returning from the function (i.e something has corrupted the stack).
Does that make sense to anybody here or have I got some really weird problem going on.?
Re: Worrying std::string problem
Quote:
Does that make sense to anybody here
Yes. Basically if you pass non-PODTs to/from dlls then you need to make sure that the versions of the STL used are the same in each. You'll need to re-compile any dlls used with your VS2015 .exe with the VS2015 compiler. If you have a situation where you know that the dlls and the .exe are going to be out of step compile-wise, then I would suggest that you only pass PODTs between.
Re: Worrying std::string problem
Thanks 2kaud, I fixed it by changing the code to this:-
Code:
std::string test = call_some_func_in_the_vs2005_dll().c_str();
It's kinda obvious when you think about it but I must admit, it hadn't even occurred to me... :blush:
Re: Worrying std::string problem
You're lucky. Even that isn't guaranteed will work :cry: The same problem can occur even if you pass your own classes and the class has changed between the version in the .dll and the version in the .exe!
Re: Worrying std::string problem
Re: Worrying std::string problem
Quote:
Originally Posted by
John E
I'm building an app with VS2015 (which I only recently installed). It links to some DLLs that were built with VS2005.
This is what I hate STL for: you either compile every single binary thing with the same compiler or never let any STL thing stick out of the binary. This diminishes dynamic linkage benefits near to nothing in C++ world.
Re: Worrying std::string problem
Quote:
Originally Posted by
Igor Vartanov
This is what I hate STL for: you either compile every single binary thing with the same compiler or never let any STL thing stick out of the binary. This diminishes dynamic linkage benefits near to nothing in C++ world.
:thumb:
Re: Worrying std::string problem
Quote:
Originally Posted by
Igor Vartanov
This is what I hate STL for: you either compile every single binary thing with the same compiler or never let any STL thing stick out of the binary. This diminishes dynamic linkage benefits near to nothing in C++ world.
this is like to hate swimming because of getting wet ... :)
Re: Worrying std::string problem
Quote:
Originally Posted by
superbonzo
this is like to hate swimming because of getting wet ... :)
Haha - a bit harsh though, Superbonzo :)
As an update... my original goal was to take a project previously written with VS2005 and rebuild it using VS2015. It's a large project so I can't do it all at once - but I've been pleasantly surprised at how smoothly it's all going. I need to be careful of course (there are certain things I need to be wary about) but on the whole, STL is the only real show-stopper. If everything isn't compiled with the same compiler, it simply doesn't work. :cry:
I don't think there's any way around it though - unless one of you guys can think of something..? std::string isn't too bad because it can be converted to char* but stuff like std::list maybe isn't so simple.
Re: Worrying std::string problem
Quote:
Originally Posted by
superbonzo
this is like to hate swimming because of getting wet ... :)
No, this is like to hate fording because of no ferry around.
Re: Worrying std::string problem
Quote:
Originally Posted by
John E
I don't think there's any way around it though - unless one of you guys can think of something..?
given that it's a temporary thing ( if I got it correctly, you plan to recompile all DLLs with the same newer compiler ) a more robust workaround could be to use some marshalling solution.
That is, suppose your scenario is like this
Code:
// main exe, compiler A
std::some_container = some_dll_function( some_std_variable );
// dll, compiler B
std::some_container some_dll_function( std::some_other_container const& );
then you could write ( say, using some existing STL compatible, portable serialization library, like boost.serialization, etc... )
Code:
// main exe, compiler A
std::some_container = some_dll_function( some_std_variable );
// bridge dll, compiler A
std::some_container some_dll_function( std::some_other_container const& var )
{
return deserialize( some_dll_function_marshalled( serialize( var )) );
}
// bridge dll, compiler B
seralized_archive some_dll_function_marshalled( seralized_archive const& var_ )
{
return serialize( some_dll_function( deserialize(var_) ) );
}
// dll, compiler B
std::some_container some_dll_function( std::some_other_container const& );
clearly, this will have a performance cost though ...
Re: Worrying std::string problem
Quote:
Originally Posted by
Igor Vartanov
No, this is like to hate fording because of no ferry around.
why do you think so ? STL is not designed for binary compatibility from the beginning, yet we do have binary compatible solutions in the c++ world if one needs so ( with a vast choice of possible performance<->portability tradeoffs ).
in this sense, using templates and then ranting about binary portability it's kind of schizofrenical ...
one may claim that it's morally wrong for a standard language library to miss binary compatible containers, but then one should face the technical challanges and tradoffs of such a choice ... after all, c++ is not Java
Re: Worrying std::string problem
Quote:
STL is not designed for binary compatibility from the beginning,
...and binary compatibility is not actually required. What would help is interface compatibility so xxx.get() in .exe always uses xxx.get() in the .dll irrespective of the versions of the xxx class used in each. As long as xxx contains .get() in both then the .exe should call the correct .get() in .dll.
This is not just an issue with STL. This is a wider problem with the public members of classes.
Re: Worrying std::string problem
Quote:
Originally Posted by
superbonzo
why do you think so ?
I don't think so. I feel like that. The difference is obvious. :)
Quote:
in this sense, using templates and then ranting about binary portability it's kind of schizofrenical ...
Emotion is kinda irrational thing. I grunt about lots of things, and never care if I look schizophrenic or not sensible enough for somebody's eyes. Just. Don't. Care. ;)
Re: Worrying std::string problem
Quote:
Originally Posted by
2kaud
...and binary compatibility is not actually required. What would help is interface compatibility so xxx.get() in .exe always uses xxx.get() in the .dll irrespective of the versions of the xxx class used in each. As long as xxx contains .get() in both then the .exe should call the correct .get() in .dll.
this is not quite true, unless you enforce object de/allocation on dll side only. Given typical usage of stl objects ( ie, as automatic variables, as members of other classes, etc... ) binary compatibility is required even if you manage to avoid all inlining and link against the same dll supplied implementation.
