One of the legacy application which build in 2010 visual studio(native application) need to be upgraded its one of the DLL which build in visual studio 15, is this possible?
If the interface uses types from the C++ Standard Library, such as std::string, it's unlikely to work. These types generally come from the C++ runtime, and the two versions have different runtime libraries.
If the interface uses LPCSTR, the implementation can use any string library internally (standard, Qt, etc)
Related
After browsing here and there, i have come to following conclusion
Visual Studio Platform Toolset - Compiler, Linker, Assembler etc which changes with each version of Visual Studio (mostly).
Note : If your project is built with previous version of Platform
toolset then it may not work as such with newer version of platform
toolset as they may be incompatible.
Runtime Library - A library which assists in running the code(program) you write by acting as an intermediary between Program and Operating system. It has various options like /Mt /Mtd /MD /MDd which stand for multithreaded static, multithreaded staticdebug, multithreaded dynamic, multithreaded dynamic debug respcetiviely
Note: All modules of your code must be using same Runtime to be
compatible i.e one module built with /Mt should be used with
application too using Runtime library as /Mt else there may be issues.
Am i right in my summary above? Or still i am not clear about this? Can anyone provide their inputs
I have googled, played tutorials and tried to consolidate all the information above. Not sure did i understand it or still having some bits and pieces missing.
SHARED ABOVE
The platform toolset consists of the C++ compiler (cl.exe) and linker (link.exe), along with the C/C++ standard libraries. Since Visual Studio 2015, the major version of the toolset has remained at 14, which means that projects compiled with Visual Studio 2019 or Visual Studio 2017 are ABI-backwards-compatible with projects compiled with Visual Studio 2015.
The Microsoft run-time library provides routines for programming for the Microsoft Windows operating system. These routines automate many common programming tasks that are not provided by the C and C++ languages.The C Run-time Library (CRT) is the part of the C++ Standard Library that incorporates the ISO C99 standard library. The Visual C++ libraries that implement the CRT support native code development, and both mixed native and managed code. All versions of the CRT support multi-threaded development. Most of the libraries support both static linking, to link the library directly into your code, or dynamic linking to let your code use common DLL files.
It looks like std::string is a header only file at Community/VC/Tools/MSVC/?/include/xstring, and all generated code should be included inside a build target.
If I'm correct, how does Microsoft guarantee that the next Visual Studio version doesn't change xstring and the std::string internal structure?
Update 1:
I got many downvotes for this question so let me explain why I decided to ask it.
I'm faced with strange crash, and I can not understand why this happen.
I use latest Qt 5.13.0 (MSVC2017_x64) and also I have some external libraries compiled with Visual Studio 2017. All have /MDd, I checked this with dumpbin util.
When I try to run any code that invokes Qt library and std::string, I'm getting wrong result (and crash at the end).
Here is very simple example:
#include <QApplication.h>
int main(int argc, char** argv) {
QString s1("Test");
std::string s2 = s1.toStdString(); // here we have s2 variable with wrong internal structure
return 0;
}
My idea was that QtCore DLL library has std::string with internal structure not compatible with std::string from Visual Studio 2017. But Qt was created with Visual Studio 2017 (maybe not same as my current Visual Studio, because there was several minor releases), so I decided to ask here if they are compatible or not.
Update 2:
Problem was in _ITERATOR_DEBUG_LEVEL. Looks like Qt was compiled with level 2 and all my external libraries and application were compiled with level 0.
This option affects internal structure of many C++ standard library classes and introduce such side effects. So when we are inside toStdString() and create std::string, we have level 2 and one internal structure. When we are in application code, we have level 0 and another internal structure. We assign object with one internal structure to object with another.
Anyway now I have better understanding of some internals.
how does Microsoft guarantee that the next Visual Studio version doesn't change xstring and the std::string internal structure?
Because they make a decision to guarantee that, or to not guarantee that.
For example, Visual Studio 2015 to 2019 are binary compatible.
That's a decision that was made, to do that. The result, if what you say is true, is that some of the implementation specifics of std::string on that platform are frozen. This is not unusual for libraries. libstdc++'s std::list::size was non-compliant to C++11 for many years, because they could not add a needed member variable without breaking binary compatibility.
In short, this is basically a project management decision, and if they ever change the header in a way that breaks things, they will tell you that binary compatibility has been broken and you need to rebuild and relink things accordingly.
As for your Qt issue, it does smell like a binary compatibility issue. But you say that both Qt and your application have been built in Visual Studio 2017 with /MDd, which would appear to rule that out. I would ask the Qt community for further help, possibly with slightly more information about your environment and about where you obtained Qt. Also ensure that you're using the version of Qt that's intended — perhaps there are multiple installations? Which one's on your include path?
Is std::string header only in Visual Studio?
Not entirely, it also depends on parts of the Standard C++ library that are implemented in Microsoft's Visual C++ Runtime. Building a binary with MSVC requires the VC++ runtimes to be linked. Only static libraries may be built without linking to a runtime, and then you must be careful to include none of the headers that require the runtime.
Is the std::string header only in Visual Studio?
(I originally read the headline this way.)
std::string is part of the C++ standard.
To use std::string on any platform that supports standard C++, you should use #include <string>. It is a standard header available with pretty much any C++ compiler.
Every compiler or platform may implement the standard in its own way though. For example with MSVC you can see that xstring is how Microsoft implements std::string under the hood. If you include xstring.h directly you are writing code that depends on the version of MSVC that provides that header. That code would not be portable to other compilers.
If I'm correct, how does Microsoft guarantee that the next Visual Studio version doesn't change xstring and the std::string internal structure?
Microsoft does not guarantee that the next Visual Studio version will have the same std::string internal structure. In the past the implementation of the standard library has changed with every VC++ runtime release, which is why Windows users end up having dozens of VC++ runtime versions installed in their Add/Remove programs list.
Thankfully Microsoft has given us a guarantee that Visual Studio 2015, 2017, and 2019 all use a binary-compatible C++ runtime. This means that binaries built using the standard library provided in Visual Studio 2015 are compatible with binaries built using 2017 and 2019 too. There is no guarantee (yet) that a future version of Visual Studio will not change the VC++ runtime implemenation again.
I have written a dll in visual studio community 2017. To be used as a general purpose library. Which could be ideally used for any c++ program for any compiler.
How will I best deploy it. (An installer)
In Visual Studio, I can simply add the project and reference it through settings in my IDE, but for it to work in any IDE, what kind of installer project should i use and what all files should be included and how.
You can't deploy a C++ DLL for all compilers. C++ doesn't have an ABI. Not even MSVC++ is compatible across versions, let alone compilers from different vendors.
The Windows solution for binary compatibility is COM. Conveniently, MSVC++ will use the COM ABI for classes that inherit from IUnknown, although you'll also have to adhere to other COM rules for full compatibility. E.g. you can't rely on dynamic_cast, you need QueryInterface.
In one of our C++ solutions, we use 3rd part libraries. These libraries are compatible to VS 2013. Now we are migrating our solution to VS 2017 and found that some of the 3rd party libraries do not have VS 2017 compatible versions.
So we tried to use some of the VS2013 compatible libraries in VS20173 and the tried API calls work fine.
Can I assume that the libraries work with VS 2017 executable without any issues?
In general - no. AFAIK, VC++2015 (aka toolset v140) and VC++2017 (aka toolset v141) are stated to be binary compatible. No such statement were made wrt VC++2013, and I believe there are breaking changes (like sizeof(list) etc).
It might work, but could lead to hard-to-debug problem
Microsoft statement:
"A more-severe kind of change, the breaking change can affect binary compatibility, but these kinds of binary compatibility breaks only occur between major versions of Visual Studio. For example, between Visual Studio 2013 and Visual Studio 2015."
see https://learn.microsoft.com/en-us/cpp/porting/visual-cpp-change-history-2003-2015
Nothing is guaranteed but binary compatibility of Visual C++ compilers is generally better than officially announced. Just make sure you do not create/destroy object across different runtimes, propagate exceptions and do not pass STL related objects as parameters.
If the third party libraries expose C style interfaces and they are compiled as DLLs the task is even easier. So you should review those interfaces and verify how much they vary from the general interoperability guidelines.
I want to write SDK using Visual C++ 2010, which can be used by VC++ 2010 clients, and also old VC++ version clients. Let's say, I want to have it compatible for 2005 and 2008 versions. SDK contains several h, lib and dll files. Libraries have exported C++ classes and global functions. Public SDK interface (h-files) doesn't contain any feature that is not supported in previous VC++ versions. Internal SDK implementation may contain such features (like Lambda expressions, rvalue references etc.).
Some public SDK methods have callback interface parameters. Callback interfaces are defined in my h-files, implemented in the client code and passed to my methods. Can this be a problem?
I made several small tests and found that it works. Does anyone know any problem with using VC++ 2010 SDK by C++ clients, written in old VC++ versions?
Key principles:
You cannot expose any objects from the standard C++ library (std::string etc), their layout is not compatible
You cannot use exceptions, SEH is okay
You cannot return any pointers that require the client code to release the pointed-to resource
You should build with /MT so the client doesn't have a headache digging up the required CRT version
You are generally okay with object layout between 2003 through 2010 as long as you can ensure it is not affected by compiler settings other than /Zp. Virtual inheritance has been troublesome. Verify that sizeof yields the same size regardless of the selected configuration.
COM is a good way to ensure maximum compatibility.