-
August 1st, 2016, 12:46 PM
#1
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.?
"A problem well stated is a problem half solved.” - Charles F. Kettering
-
August 1st, 2016, 01:16 PM
#2
Re: Worrying std::string problem
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.
All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!
C++23 Compiler: Microsoft VS2022 (17.6.5)
-
August 1st, 2016, 01:53 PM
#3
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...
"A problem well stated is a problem half solved.” - Charles F. Kettering
-
August 1st, 2016, 04:11 PM
#4
Re: Worrying std::string problem
You're lucky. Even that isn't guaranteed will work 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!
All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!
C++23 Compiler: Microsoft VS2022 (17.6.5)
-
August 2nd, 2016, 03:26 PM
#5
Re: Worrying std::string problem
-
August 9th, 2016, 04:38 AM
#6
Re: Worrying std::string problem
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.
Best regards,
Igor
-
August 9th, 2016, 05:06 AM
#7
Re: Worrying std::string problem
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.
All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!
C++23 Compiler: Microsoft VS2022 (17.6.5)
-
August 10th, 2016, 02:26 AM
#8
Re: Worrying std::string problem
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 ...
-
August 10th, 2016, 02:47 AM
#9
Re: Worrying std::string problem
"A problem well stated is a problem half solved.” - Charles F. Kettering
-
August 10th, 2016, 02:55 AM
#10
Re: Worrying std::string problem
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.
Best regards,
Igor
-
August 10th, 2016, 03:09 AM
#11
Re: Worrying std::string problem
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 ...
-
August 10th, 2016, 03:26 AM
#12
Re: Worrying std::string problem
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
-
August 10th, 2016, 04:00 AM
#13
Re: Worrying std::string problem
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.
All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!
C++23 Compiler: Microsoft VS2022 (17.6.5)
-
August 10th, 2016, 08:32 AM
#14
Re: Worrying std::string problem
Originally Posted by superbonzo
why do you think so ?
I don't think so. I feel like that. The difference is obvious.
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.
Best regards,
Igor
-
August 11th, 2016, 02:44 AM
#15
Re: Worrying std::string problem
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.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|