Re: Problem with reading an int with operator>>

"David Wilkinson" <no-reply@xxxxxxxxxxxx> wrote in message
news:eAgSNGpRGHA.5468@xxxxxxxxxxxxxxxxxxxxxxx

Thanks for the reply. Inline:

P.J. Plauger wrote:

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.

Yes, but as always with dynamic linking, this is no real advantage if I
have to ship the DLL's myself. Is the real reason not what I say (same as
it is for MFC with extension DLL's)?

From what I see, DLLs *cause* the problem of passing objects across
DLL boundaries. But maybe I'm missing some other point you're making.

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.


But don't you write these library headers?

Yes. Then Microsoft works 'em over and we decide how much of their
changes to fold back into our baseline for our own products.

Is it just a matter of removing
all the "#ifdef _DLL" sections?

You don't have to do that. It's a matter of defining the appropriate
guiding macro definitions when you build. These either build for
DLLs or for a static library.

What I would like (if I used
dynamic linking) would be a preprocessor symbol that I could define that
would remove the "extern" declarations, something like:

#if defined _DLL and !defined _NO_EXTERN

Would this not be possible? Or is there more to it than this?

It's already there (see _BUILD), but that's not the whole story.
We can't seem to build certain libraries static because of conflicts
with the underlying libraries we have to use. Typically, there's one
magic runtime function we have to use as-is and another that we have
to replace, and both are packaged in the same module. Similarly,
we *have* to build other libraries static whether we want to or not.

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.

Yes, but in VC6 we had 6 service packs none of which, for whatever reason,
included the patches. And in VC7/7.1/8 we so far have none.

I can't comment on Microsoft's support decisions. It's their business
how they do it. We're the back room guys.

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


.

Relevant Pages

  • Re: How to get imagebase after a DLL gets loaded
    ... The main difference between DLL and static library in this context is ... so that it is not meant to be integrated with the client code ... SPEAKING ABOUT STATIC LIBRARIES HERE, AND I *EXPLICITLY* SAID IT THIS ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Problem with reading an int with operator>>
    ... P.J. Plauger wrote: ... passed across DLL boundaries? ... We can't seem to build certain libraries static because of conflicts ...
    (microsoft.public.vc.stl)
  • Re: How to get a .lib from .dll
    ... Using the Borland tools, you should first run "IMPDEF" on the DLL file ... information in it to create ".LIB" import libraries with;)... ... from Windows version to Windows version...so, ...
    (comp.lang.asm.x86)
  • Re: How to get a .lib from .dll
    ... Using the Borland tools, you should first run "IMPDEF" on the DLL file ... information in it to create ".LIB" import libraries with;)... ... from Windows version to Windows version...so, ...
    (alt.lang.asm)
  • Re: How to get imagebase after a DLL gets loaded
    ... During the process of building the DLL, ... Implementing a library that requires users of the library to instantiate ... predict what variable name you will use at initialization time. ... Some third-party libraries DO require that you instantiate a pre-defined ...
    (microsoft.public.win32.programmer.kernel)
Loading