Re: Problem with reading an int with operator>>

David Wilkinson wrote:
Tom Widmer [VC++ MVP] wrote:

David Wilkinson wrote:

But I still do not understand why std::string, which IS completely implemented in header files, is compiled into MSVCP60.DLL. It just seems to cause a lot of trouble. Again, I use static linking, so it doesn't bother me.



Unlike std::vector and the other containers/algorithms/etc., std::basic_string only has two commonly used specializations, at least one of which (std::string) is used internally by the iostreams implementation. So, given that the iostreams stuff is included in the DLL, why not also export string and wstring, to slightly reduce compile time, exe size and program memory usage (due to not having multiple copies of the string's code in memory at once)?

Tom


Tom;

Because it makes it impossible to patch std::string without rebuilding MSVCP60.DLL (if you use static linking).

My question was rhetorical. At the time the decision was made to include string in the DLL, it obviously wasn't known that it either had any bugs in or that there would be a problem with patching the DLL in an SP, which is obviously the normal way that library bugs are handled.

The patches for <string> and
<xstring> were available at Dinkumware for many years, but never made into any of the 6 VC6 service packs. To this day, the getline bug remains in dynamically linked VC6 (SP6). For static linking, you just patch the headers.

I'm sure it is partly the old legal problem, but I think MS is very unwilling to create multiple versions of the C++ RTL DLL's, because they already have enough trouble with the C RTL and MFC DLL's. And of course, in C++, if you change the layout of a class in the DLL, you will break existing code.

I think they are trying to improve matters with the new shared side-by-side assembly stuff. I believe this allows MS to fix the CRT DLLs using Windows Update (with your application's permission, I assume).

So, I say put as little as possible into the C++ RTL DLL's.

That just leads to code bloat. If you've got 10 CRT using DLLs, you'll end up with 11 copies of std::string's code, etc.

I'm still not sure why there has to be such a DLL at all. Since most of the standard library is defined in header files, why isn't all of it?

For the same reasons that other libraries aren't defined solely in header files. To put non-template functions (or explicit specializations of template functions) in header files, they must be declared inline, which is going to cause serious bloat in many cases. The only reason most of it is in header files is due to compiler limitations when it comes to templates.

In
fact, I thought that if you purchased Dinkumware's C++ upgrade library (or switched to STLPORT), all you had to do is change the include path. I think I'm still missing something.

Dinkumware's upgrade library involves new binaries I believe. STLport also has dll and lib files, though only if you want to use STLport's IOstreams.

The iostreams component is really quite big, and almost all of it is brought into any statically CRT linking project that does any std IO, so basically you are adding the much of the size of the CRT DLL to every ..exe and DLL that statically links to the CRT. Not to mention the shared heap as well, which can be useful if you want to pass ownership of memory across the DLL boundary.

If you don't use DLLs, then the only advantage of dynamically linking to the CRT is the side-by-side assembly stuff I mentioned above.

Tom
.

Relevant Pages

  • Re: DLLs and facets
    ... It sounds like the EXE and DLL are using the same CRT DLL, ... must be regarded as equivalent to static linking in terms of melding your ... whenever you update the compiler. ...
    (microsoft.public.vc.stl)
  • Re: DLLs and facets
    ... It sounds like the EXE and DLL are using the same CRT DLL, ... must be regarded as equivalent to static linking in terms of melding your ... whenever you update the compiler. ...
    (microsoft.public.vc.stl)
  • Re: When were scanf_s functions introduced?
    ... that's about how static linking works. ... Increased memory usage (if you run two apps with the CRT static linked ... another CRT DLL). ...
    (microsoft.public.platformsdk.security)
  • Template Libraries
    ... I am trying to create a library of stacks, lists templates in a DLL. ... am getting a linker error when trying to tie in my library to another ... statements in them as all the code is now in the header files. ...
    (comp.lang.cpp)
  • Re: mfc size
    ... your DLL size but not solve any problems; and you cannot use such a DLL with any MFC ... MFC environment, so a DLL that does static linking will royally and totally fail (the app, ... for example, will not be able to find the window map for the windows created in the DLL, ...
    (microsoft.public.vc.mfc)
Quantcast