Re: Problem with reading an int with operator>>

"David Wilkinson" <no-reply@xxxxxxxxxxxx> wrote in message
news:%23%23EdNpoRGHA.5900@xxxxxxxxxxxxxxxxxxxxxxx

P.J. Plauger wrote:

[snip]

I'm not sure that you can statically link at all these days. The only
trick I can think of, which is pretty unpalatable, is to make a
stream that doesn't look like istream<char, char_traits<char> >,
probably by writing your own traits class. That would outsmart
the prebuilt facets in the DLL. But that may well lead to other
surprises.

PJ:

I don't think it's true that you can no longer static link in VC8. I think
it is just (even) more discouraged than before because you cannot static
link if you're using /clr.

Could be. I cloud over when the subject of DLLs comes up, and defer
to people like Pete Becker whenever possible.

One of the many things I like about static linking is that I can patch
the standard library myself (this is important in VC6, where the patches
never made it into the service packs).

I absolutely agree, and prefer static linking in most contexts.

But I have a question. What exactly is compiled into msvcp60.dll (and
corresponding VC7/8 versions)? Is it just std::string and std::wstring?

Grep the headers for all the DLL magic. You can see the classes that
are explicitly instantiated into the DLL.

And what exactly is the purpose of it? Is it just so these objects can be
passed across DLL boundaries?

Well, it does save link time and code size in .exe files.

Personally, I would be prepared to forgo
this advantage if I could keep all my Standard Library in the headers
where it could be easily updated. Is it possible to do this even if one is
dynamically linking CRT (and MFC)?

Dunno. I'd like to think so.

It seems to me that the existence of msvcp60.dll (and VC7/8 versions) is
an impediment to Microsoft updating the standard library when improvements
have been found. Or am I missing something here?

I think Microsoft takes a more comprehensive view of updating the
library, since they can provide new versions of headers, DLLs, and
all in one SP.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


.

Relevant Pages

  • Re: [LogoForum] arguments evaluation sequence
    ... > which automatically searches the function "registerPrimitives " in a user ... > that dll. ... that uses your DLL (i.e. no need to search for registered primitives). ... No other libraries or headers need to be installed, ...
    (comp.lang.logo)
  • Re: Problem with reading an int with operator>>
    ... Yes, but as always with dynamic linking, this is no real advantage if I have to ship the DLL's myself. ... this advantage if I could keep all my Standard Library in the headers where it could be easily updated. ... Is it just a matter of removing all the "#ifdef _DLL" sections? ... an impediment to Microsoft updating the standard library when improvements have been found. ...
    (microsoft.public.vc.stl)
  • Re: Subject: Forcing a .NET obj exposed as COM to use StdCall instead of CdCall
    ... I've seen these extension scripts in products like Mercator and PoepleSoft. ... They basically load a DLL and call a method in it by using GetProcAddress ... headers> // Windows Header Files: ...
    (microsoft.public.dotnet.general)
  • Re: how to export global variable in C dll?
    ... DLL will not link. ... Avoid including CRT/PSDK headers in your DLL headers. ... inside extern "C" block, they're still definitions. ... Now these globals are exported without name mangling ...
    (microsoft.public.vc.language)
  • Re: how to export global variable in C dll?
    ... DLL will not link. ... Avoid including CRT/PSDK headers in your DLL headers. ... In this file define global variables. ... Now these globals are exported without name mangling ...
    (microsoft.public.vc.language)
Loading