Re: C run-time library
From: Jerry Coffin (jcoffin_at_taeus.us)
Date: 06/02/04
- Next message: Jerry Coffin: "Re: delete"
- Previous message: Roy Fine: "Re: delete"
- In reply to: Doug Harrison [MVP]: "Re: C run-time library"
- Next in thread: Gil Hamilton: "Re: C run-time library"
- Reply: Gil Hamilton: "Re: C run-time library"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 1 Jun 2004 20:18:52 -0600
In article <8c9pb0hv625lgfl6sroeof9emhrmppjltq@4ax.com>, dsh@mvps.org
says...
[ ... ]
> Programs and the static libraries they use should be compiled using the same
> CRT option and linked to the indicated CRT. The code that is generated
> differs for the compiler switches which specify the CRT, namely /ML, /MT,
> and /MD and their debug variants.
/MD, /ML, etc., do NOT affect the compiler's code generation. These
flags define a couple of preprocessor macros and add a default
library record to the object file.
> You might want to grep the VC headers
> separately for _DLL and _MT to convince yourself of this; it should at least
> give you an idea where the static libraries you write "on a regular basis"
> may fall apart when used in ways you haven't considered.
Precisely what (mistaken) reasoning leads you to believe that they'll
have any affect on my code at all?
> If you can avoid using those parts of the CRT that vary with the _DLL and
> _MT macros and thus achieve your "CRT-neutral static library", by all means,
> knock yourself out.
Gee Doug, you're just too generous!
> Just be certain to vet everything with a high powered
> microscope with each compiler version and CRT flavor you use, because as a
> -Zl fan, you're sacrificing a useful link-time antibugging feature, while
> making promises that can be broken for you at any time.
No, Doug, I'm not doing anything of the sort. You're simply talking
about things of which you're completely ignorant.
> I could see using
> -Zl if you're not using the CRT at all, but if that's the case, why are we
> having this discussion?
Because you didn't bother attempting to learn any of the relevant
facts before you went on the attack.
> >I already saw them. IMO, far from being "the correct approach" they
> >presented what is, at best, a mediocre fall-back for dealing with
> >code that's usually poorly designed.
>
> Then by that "reasoning", I guess MS is clueless with respect to lines
> 49-108 of afx.h. I guess MS and Dinkumware are out there in la la land with
> yvals.h/use_ansi.h. And what about those "mediocre" Boost developers and
> their auto_link.hpp. Are they all just a bunch of knuckleheads? Or is it
> possible they understand the issues in greater depth than you and act
> accordingly?
Doug, you've apparently lost track of what the OP asked, or perhaps
you simply never understood it in the first place. In any case, none
of these is related or even analogous.
Here's the OP's question:
> when building a static library that uses multithreading, which C run-time
> library should be used for "Debug" and "Release"?
Now, I'll reiterate: there is really only one correct answer to this:
use /Zl, and allow the user to pick the correct CRT for his project.
When you build a static library, it's not linked to anything at that
point -- you simply create object files, and put them together into a
library.
It's up to the final user to decide which library he's going to link
with. When/if your library uses the CRT, it should make use of ONLY
its documented interface. Now it's true that the user's choices may
(often will) affect the _implementation_ of the standard library.
That's 100% IRrelevant to the question at hand though -- our library
has absolutely NO business depending on anything except the
documented behavior of the CRT. The CRT, in turn, is required to
provide that behavior, regardless of how it's implemented.
That leaves exactly three possible circumstances in which your
library has to care about which underlying CRT is used: 1) your
library depends on something it shouldn't, or 2) you're stuck with a
CRT that doesn't always live up to its requirements 3) some version
of the library simply doesn't include something you require (e.g. you
use _beginthread, so you need a multithreaded library).
In this case, he's already said that the library DOES use
multithreading, so we can preemptively rule out any possibility of
using the single-threaded libraries. That pretty much removes 3) as
a consideration. Between 1) and 2), the choice is pretty simple: at
least in my experience, the CRT is usually quite carefully written
and heavily tested, so it pretty dependably lives up the promises it
makes.
That leaves only one possibility: if your code cares which version of
the CRT it's linked with, it's depending on something that wasn't
promised to start with. I have no reservations in saying that most
such code is poorly designed (if anything, that's stating the
situation more weakly than it deserves).
--
Later,
Jerry.
The universe is a figment of its own imagination.
- Next message: Jerry Coffin: "Re: delete"
- Previous message: Roy Fine: "Re: delete"
- In reply to: Doug Harrison [MVP]: "Re: C run-time library"
- Next in thread: Gil Hamilton: "Re: C run-time library"
- Reply: Gil Hamilton: "Re: C run-time library"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
