Re: Problem with reading an int with operator>>

Stephen Howe wrote:

I had somehow thought that the whole of the standard library was in
header files. but I guess it isn't, and that if I do dynamic linking and
use any part of the (new) standard library, then I will need to link to
MSVCP60.DLL.


Here at work we are using VC++ 2003.
We should be shortly switching to VC++ 2005.
I have looked round the office to see if we have any PC's left with Visual
C++ 6.0 installed (there is one machine and I will find out tomorrow). More
on this below.

I am baffled by what you say, but I think the intention (even if the reality
is not so) is that if you compile stand alone, you should not get
dependencies to any of MSVCRT.DLL, MSVCP60.DLL or MSVCIRT.DLL.

Now I know there were a few flaws in the header files for Visual Studio
5.0/6.0.
And further these were fixed by downloading header files from Dinkumware.
The implications of that is that is anything inline is fixed.


But I still do not understand why std::string, which IS completely
implemented in header files, is compiled into MSVCP60.DLL.


Why? You are thinking from the compiler point-of-view not the linker's
point-of-view.

If you do


#include <string>

unsigned foobar()
{ std::string test("Here I am");
return test.size();
}


then a call to the constructor for std::string and destructor will be
inserted into the code of foobar.
That is an actual function call. And that will be expanded from the
definition of std:string in <string>.
But where does that constructor for std::string actually live? Where does it
reside? The body of the code?
Well if you compiled with /MD in force, the constructor, I think, lives
inside MSVCP60.DLL.
If you compiled with /ML or /MT in force, the constructor I think, lives
inside LIBP.LIB or LIBPMT.LIB and is linked in. I say "I think" because I
have not checked this. A linker MAP file would confirm/deny this. In any
case, you will find that some template functions are instantiated in your
OBJ file but some are not and are pulled out from LIB files or a call to DLL
is generated.

[snip]

Returning back to Visual 6.0.
If you get dependencies on MSVCP60.DLL despite compiling throughout with /ML
or /MT, then I think that is a Microsoft oversight (bug?). The intention was
that your standalone program should be self-sufficient, not dependent on any
DLL (apart from Windows OS ones) if compiled with /ML or /MT. It might be an
idea to try the code above with VC++ 6.0, run it though DEPENDS and find out
exactly what is being imported from MSVCP60.DLL.

Cheers

Stephen Howe


Stephen:

Thanks again for the reply.

I think you misunderstand me. I always use static linking and do not have any need for MSVCP60.DLL. I applied the Dinkumware patches and they worked without rebuilding anything (except my code of course).

What I am concerned about is that even after 6 service packs, the last surely after the legal issues were resolved, these patches did not make their way into MSVCP60.DLL. So that if I did want to use dynamic linking, the VC6 standard library would be defective. I know there is at least one defect in the VC7.1 standard library, and we know how many service packs there have been for that.

std::string is based on a templated class, so (export lacking) I would normally expect it to be inlined into my program. But as Tom pointed out, there are only two common instantiations of much of the standard library, i.e. those for char and wchar_t, and MS has chosen to compile those into the C++ RTL DLL. Unfortunately, IMHO, but they did.

It seems that there must be things that are compiled into MSVCP60.DLL that are not compiled into LIBP.LIB or LIBPMT.LIB (otherwise the patches would not take effect), and I am not sure why this is. I will try to find time to play around with DEPENDS and find out what is where.

But for now I remain a happy static linker...

David Wilkinson


.

Relevant Pages

  • Header files
    ... In the fortran code that I have, there is a subroutine in which ... I am using a pgi compiler to compile 2D.F and my code. ... character...and it gives the names of all header files. ...
    (comp.lang.fortran)
  • Re: Another question on VS2003 to VS2005
    ... EVERY instance of the word "PASCAL" from the Platform SDK, MFC, and other header files. ... One thing you can do is add the /P switch to the compile line for this file (that's ... Check if LONG, GSFAR, GSPASCAL and GSEXPORT are correctly defined as something ... a class definition in a header file that is included before these lines. ...
    (microsoft.public.vc.mfc)
  • Re: changing module files
    ... > actually defined somewhere is not determined until compile time. ... methods, they must be defined in the declaration used by callers, ... > understand and be comfortable with all of the preprocessor macros. ... No macros are needed by C or C++ header files particularly except ...
    (comp.lang.fortran)
  • Re: Problem with reading an int with operator>>
    ... is not so) is that if you compile stand alone, ... Now I know there were a few flaws in the header files for Visual Studio ... If you compiled with /ML or /MT in force, the constructor I think, lives ... If I examine the imports from MSVCP71.DLL that TEST.EXE has made, ...
    (microsoft.public.vc.stl)
  • Re: what is fast dynamically linked executable or statically linked executable ?how to decide?
    ... Could one use specific compile time flag with makefile or is it ... to make code small often make executables significantly slower. ... Dynamic linking may make your code faster or slower; ...
    (comp.lang.c)