Re: C run-time library

From: Doug Harrison [MVP] (dsh_at_mvps.org)
Date: 06/01/04 

Date: Tue, 01 Jun 2004 11:25:40 -0500

Jerry Coffin wrote:

>In article <rfkmb056i2m2c28aoh31gfsmjcruimerc2@4ax.com>, dsh@mvps.org
>says...
>
>[ ... ]
>
>> In a word, NO, NO, NO. OK, so that was three words. :) It's hard to imagine
>> a significant body of code that could be compiled in a CRT-neutral way.
>
>I find it sufficiently easy to imagine that I do it on a regular
>basis.
>
>> The only reason I can see to use /Zl is to save space in libraries,
>
>If that's all you can see, you should learn to look more carefully.
>
>> which these
>> days would appear to amount to an insignificant amount of space.
>
>If space saving was the primary concern, they might as well remove
>the switch entirely. It's not.

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. 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.

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. 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. 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?

>> See my answer and Carl's follow-up example for the correct approach.
>
>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 Harrison
Microsoft MVP - Visual C++

Relevant Pages

  • Re: Different C runtime libraries
    ... > MS insists that we use the same CRT version when linking .LIBs inside EXEs. ... > The compiler also issues warnings and sometimes duplicate references. ... I would not expect static libraries to be exchangeable among different ...
    (microsoft.public.vc.language)
  • Re: Does anyone have a 19 inch flat screen
    ... LCD? ... A flat screen is just a regular ... The marketing people are really pushing that name, ... Much more so than my 19" Viewsonic flatscreen CRT. ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)
  • Re: Sony KDL-V32A12U - freeview and sci fi?
    ... compared to a cheaper CRT (regular made from heavy glass ... If you are going for a 28 or 32 inch job, definately get a CRT, unless ... for a surround sound thing and have exciting noise. ...
    (uk.tech.digital-tv)
  • OT: Danke :-)
    ... Compiler erzeugt wurde auch immer mit der passenden CRT ... Aber auch der GCC und sein Linker will wissen, was er in welcher Form als Entry-Point in die PE schreiben soll. ... 90% von Windows besteht nur noch ...
    (microsoft.public.de.vc)
  • Re: D3/Linux compile question
    ... consider zero a valid array element while the Prime flavors do. ... 02 EQUATE ZERO TO ARRAY ... 07 CRT ARRAY ... Compiler catches line 6 and 13 as subscript out of range. ...
    (comp.databases.pick)
Loading