Probably because you are dynamically linking the runtime library (i.e. the Standard Library). You can statically link it (I think you can do it in the Express Edition, but I personally can't guarantee it) by going to Project->Properties->Configuration Properties->C/C++->Code Generation and changing the "Runtime Library" to "Multi-threaded (/MT)". Programs which don't do this require the user to install the Redistributable Package from Microsoft, which contains the DLLs that your dynamically linked program requires.

Quote:Original post by MikeTacular
Probably because you are dynamically linking the runtime library (i.e. the Standard Library). You can statically link it (I think you can do it in the Express Edition, but I personally can't guarantee it) by going to Project->Properties->Configuration Properties->C/C++->Code Generation and changing the "Runtime Library" to "Multi-threaded (/MT)". Programs which don't do this require the user to install the Redistributable Package from Microsoft, which contains the DLLs that your dynamically linked program requires.

Although it probably won't (yet) affect the OP, it's still worth noting that statically linking to the CRT libs can create some really nasty bugs when working with DLLs. The static CRT is fine as long as you're working with very simple or small projects. But for anything larger, it's usually not a good idea.

Quote:Original post by Yann L

Quote:Original post by MikeTacular
Probably because you are dynamically linking the runtime library (i.e. the Standard Library). You can statically link it (I think you can do it in the Express Edition, but I personally can't guarantee it) by going to Project->Properties->Configuration Properties->C/C++->Code Generation and changing the "Runtime Library" to "Multi-threaded (/MT)". Programs which don't do this require the user to install the Redistributable Package from Microsoft, which contains the DLLs that your dynamically linked program requires.

Although it probably won't (yet) affect the OP, it's still worth noting that statically linking to the CRT libs can create some really nasty bugs when working with DLLs. The static CRT is fine as long as you're working with very simple or small projects. But for anything larger, it's usually not a good idea.

I was actually thinking about starting a thread asking why you would want to dynamically link the CRT. Can you elaborate on these bugs?

Quote:Original post by MikeTacular
I was actually thinking about starting a thread asking why you would want to dynamically link the CRT. Can you elaborate on these bugs?

The CRT libraries have static data areas they use to store control structures for resources allocated and serviced by the CRT: memory management (malloc/free and new/delete), file allocators (everything from FILE to std::fstream types), etc.

Now, suppose you have an application that uses two DLLs. Say you statically link the CRT with your application and the DLLs. What will happen is that your host app and the two DLLs will each instanciate local versions of the static CRT control data structures. Basically, there will be three entirely separate CRTs existing simultaneously, that know nothing about each other.

In practice that means that you cannot use a resource created by one of these isolated CRTs in another CRT, if such usage would access the CRT control structures. Otherwise, you will get anything from a crash, over heap corruption to totally weird and unpredictable effects. For example, you cannot open a file in one DLL, and read from/write to it from another DLL. You cannot allocate memory in one DLL and free it in another (or in your host application). And so on. It is very hard to ensure this, especially when using modern C++ containers and C++ interfaces between the DLLs. You don't always know what resources will access internal CRT control structures, and it can change from one CRT version to the next. Mistakes are subtle and very hard to avoid. The bugs generated by such small mistakes can be extremely challenging to track.

If you link with the dynamic CRT, only one single version of the static CRT data will ever be instanciated by your process - the one in the CRT DLL.

Oh, and your executable + DLLs will be considerably smaller too.

Quote:Original post by asp_
since you can't really expect the classes to have the same binary layout across compiler version changes so you won't get a huge saving with just 1 DLL instance loaded.

Consider a modern DLL and plugin heavy application such as 3DSMax. My current (relatively clean) 3DSMax 2009 installation consists of around 290 DLLs. This will significantly increase if you install third party plugins. I'll let you do the math, if every single one of these DLLs had a local copy of the CRT linked in...

And it's not just about memory savings. As I mentioned above, creating clean and modern OO interfaces with DLLs, that support inheritance, polymorphism and generic containers is extremely difficult, error prone and chaotic if you use static CRTs. It becomes trivial with dynamic linked CRTs. The choice shouldn't be too difficult, unless your application is so small that it doesn't use any external DLL.

Quote:Original post by asp_
You shouldn't really share C++ classes at all IMO.

Of course you should. OOP interfaces are mostly relevant in the context of tightly coupled modules, such as plugins. Plugin modules will always be loaded by the application they were designed for. There is no reason to avoid elegant C++ interfaces and stay with primitive and unintuitive lists of hundreds of extern "C"-style functions in this day and age.

And you don't have to force the use of a single compiler either. All what is important, is that all binary modules for one platform are compiled using the same compiler. So compiling everything in MSVC or everything in gcc are both fine. It's only the attempt to mix compiled binaries that will fail. But this is mostly irrelevant anyway.