CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 15 of 15
  1. #1
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    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

  2. #2
    2kaud's Avatar
    2kaud is online now Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    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)

  3. #3
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    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

  4. #4
    2kaud's Avatar
    2kaud is online now Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    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)

  5. #5
    Join Date
    Nov 2003
    Posts
    1,902

    Re: Worrying std::string problem

    http://forums.codeguru.com/showthrea...63#post2194163

    A longer type-up of what 2kaud has explained...

    gg

  6. #6
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,620

    Re: Worrying std::string problem

    Quote Originally Posted by John E View Post
    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

  7. #7
    2kaud's Avatar
    2kaud is online now Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    Re: Worrying std::string problem

    Quote Originally Posted by Igor Vartanov View Post
    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)

  8. #8
    Join Date
    Oct 2008
    Posts
    1,456

    Re: Worrying std::string problem

    Quote Originally Posted by Igor Vartanov View Post
    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 ...

  9. #9
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    Re: Worrying std::string problem

    Quote Originally Posted by superbonzo View Post
    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.

    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.
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  10. #10
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,620

    Re: Worrying std::string problem

    Quote Originally Posted by superbonzo View Post
    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

  11. #11
    Join Date
    Oct 2008
    Posts
    1,456

    Re: Worrying std::string problem

    Quote Originally Posted by John E View Post
    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 ...

  12. #12
    Join Date
    Oct 2008
    Posts
    1,456

    Re: Worrying std::string problem

    Quote Originally Posted by Igor Vartanov View Post
    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

  13. #13
    2kaud's Avatar
    2kaud is online now Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    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)

  14. #14
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,620

    Re: Worrying std::string problem

    Quote Originally Posted by superbonzo View Post
    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

  15. #15
    Join Date
    Oct 2008
    Posts
    1,456

    Re: Worrying std::string problem

    Quote Originally Posted by 2kaud View Post
    ...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
  •  





Click Here to Expand Forum to Full Width

Featured