Success Through Cluelessness

[Ramsey]

Recently I was having a problem where the creation of an fstream object
in my lib file would crash. The lib file was linked to a managed dll.

I fixed the problem by changing the 'Run time library' to have a value
of 'Multi-threaded Debug DLL (/MDd)' on all the lib files, dlls, and
the executable in my solution.


Question 1) Why does my code require a Run time library? My lib file
makes no windows api calls. Just standard c++ objects like fstream.


Now I can understand the difference between debug mode and non-debug
mode. I can also understand the difference between single threaded and
multi-threaded. But I have no clue what the difference is between
'Multi-threaded (/MT)' and 'Multi-threaded DLL (/MD)'

Question 2) What is the difference between 'Multi-threaded (/MT)' and
'Multi-threaded DLL (/MD)'?

Question 3) Is this the difference between my code statically linking
to the Run-time library vs dynamically linking to the run-time library?


Question 4) And am I going to have to package extra dlls with my
release? I'd rather not if possible.

Question 5) Since my project uses a GUI, i can understand why
multithreaded libraries are required. But I don't understand why
creating an fstream object would crash when using 'Multi-threaded
(/MT)' while it would succeed when using 'Multi-threaded DLL (/MD)'.


Question 6) if 'Multi-threaded DLL (/MD)' setting is required when for
dlls, why didn't VS automatically set the when I created dll project in
my solution.

Any help in resolving my cluelessness is greatly appreciated.
Thank You,
Ramsey

 

[Carl Daniel [VC++ MVP]]

Recently I was having a problem where the creation of an fstream
object in my lib file would crash. The lib file was linked to a
managed dll.

I fixed the problem by changing the 'Run time library' to have a value
of 'Multi-threaded Debug DLL (/MDd)' on all the lib files, dlls, and
the executable in my solution.


Question 1) Why does my code require a Run time library? My lib file
makes no windows api calls. Just standard c++ objects like fstream.

Which are supplied by the runtime library. You don't need a runtime library
to make Windows calls.

Now I can understand the difference between debug mode and non-debug
mode. I can also understand the difference between single threaded and
multi-threaded. But I have no clue what the difference is between
'Multi-threaded (/MT)' and 'Multi-threaded DLL (/MD)'

Question 2) What is the difference between 'Multi-threaded (/MT)' and
'Multi-threaded DLL (/MD)'?

/MD means that the CRT is in a DLL (MSVCRT.DLL) rather than a static library
(libcmt.lib).

Question 3) Is this the difference between my code statically linking
to the Run-time library vs dynamically linking to the run-time
library?
Precisely.

Question 4) And am I going to have to package extra dlls with my
release? I'd rather not if possible.

That depends on whether your target systems already have the required CRT
DLLs. In general, the answer is yes.

Question 5) Since my project uses a GUI, i can understand why
multithreaded libraries are required. But I don't understand why
creating an fstream object would crash when using 'Multi-threaded
(/MT)' while it would succeed when using 'Multi-threaded DLL (/MD)'.

It's because you're using managed code. The CLR uses the DLL runtime
library (the CLR itself is written in C++ afterall). In order to not have
multiple heaps, file tables, etc, everything must use the DLL runtime
library.

Question 6) if 'Multi-threaded DLL (/MD)' setting is required when for
dlls, why didn't VS automatically set the when I created dll project
in my solution.

It's not automatically required, but it's the right answer most of the time.
It is required for managed code. VC++ 2005 makes this the default (and will
flag an error if you try to do otherwise).

-cd

 

[Arnaud Debaene]

Recently I was having a problem where the creation of an fstream
object in my lib file would crash. The lib file was linked to a
managed dll.

I fixed the problem by changing the 'Run time library' to have a value
of 'Multi-threaded Debug DLL (/MDd)' on all the lib files, dlls, and
the executable in my solution.


Question 1) Why does my code require a Run time library? My lib file
makes no windows api calls. Just standard c++ objects like fstream.

And where do you think the "C++ objects like fstream" are implemented?
Precisely in the CRT (C-Run Time library).

Now I can understand the difference between debug mode and non-debug
mode. I can also understand the difference between single threaded and
multi-threaded. But I have no clue what the difference is between
'Multi-threaded (/MT)' and 'Multi-threaded DLL (/MD)'

Question 2) What is the difference between 'Multi-threaded (/MT)' and
'Multi-threaded DLL (/MD)'?

When compiling with /MT, your code is using the CRT version that is included
in the static libray libcmt.lib. It means each module in your app (either
DLL or EXE) will have it's own copy of the CRT, and will maintain it's own
copy of the CRT internal structures, including file handles table, memory
allocator, etc... It means that, for example, if you open a file in a DLL
with fopen, you couldn't pass the HFILE to the exe and have the EXE use that
handle successfully.
When compiling with /MD, all modules of your app will use the same version
of the CRT that comes packaged in the msvcr71 and mscvp71 DLLs, so modules
can freely exchange file handles, pointers to dynamically allocated memory,
etc...

Question 3) Is this the difference between my code statically linking
to the Run-time library vs dynamically linking to the run-time
library? Exactly.

Question 4) And am I going to have to package extra dlls with my
release? I'd rather not if possible.

Yes, you will have to. Is it really so much of a problem? How is your app
distributed?

Question 5) Since my project uses a GUI, i can understand why
multithreaded libraries are required. But I don't understand why
creating an fstream object would crash when using 'Multi-threaded
(/MT)' while it would succeed when using 'Multi-threaded DLL (/MD)'.

Managed C++ is a particular cases : The .NET runtime requires you to link to
the CRT DLL (don't know exactly why, that's the way it is).

Question 6) if 'Multi-threaded DLL (/MD)' setting is required when for
dlls, why didn't VS automatically set the when I created dll project
in my solution.

Historical reason I would say, as some people still are reluctent to
distribute the CRT dlls with their app.

Arnaud
MVP - VC