Something about Linking

Discussion in 'C++' started by comp.lang.c++.moderated, Jul 8, 2007.

  1. The MSVC CRT source code contains ::eek:perator new function definition(I
    can jump into it when debugging), so can I say there's a function
    built into the crt library? If so, when I define my own ::eek:perator new
    function and use static link, when no ``function already defined in
    *******" error?
    comp.lang.c++.moderated, Jul 8, 2007
    #1
    1. Advertising

  2. comp.lang.c++.moderated

    Bo Persson Guest

    comp.lang.c++.moderated wrote:
    :: The MSVC CRT source code contains ::eek:perator new function
    :: definition(I can jump into it when debugging), so can I say
    :: there's a function built into the crt library? If so, when I
    :: define my own ::eek:perator new function and use static link, when no
    :: ``function already defined in *******" error?

    This is somewhat implementation specific, but generally names defined
    in your code are resolved first, and only later does the linker look
    for names in libraries.

    In this particular case, you will not get the entire library linked
    in, just the functions (and operators) that you actually use.



    Bo Persson
    Bo Persson, Jul 8, 2007
    #2
    1. Advertising

  3. comp.lang.c++.moderated

    James Kanze Guest

    On Jul 8, 7:00 am, "comp.lang.c++.moderated" <>
    wrote:
    > The MSVC CRT source code contains ::eek:perator new function definition(I
    > can jump into it when debugging), so can I say there's a function
    > built into the crt library? If so, when I define my own ::eek:perator new
    > function and use static link, when no ``function already defined in
    > *******" error?


    Most likely, the ::eek:perator new function is in a library
    somewhere, that the linker uses to resolve unknown symbols.
    Since the definition of a library is that an object file it
    contains are part of your program if and only if it resolves one
    or more unresolved externals; typically, the libraries are
    processed in order (although I'm not too sure about VC++---but
    I'd be very surprised if its algorithm didn't respect order);
    and the standard library (usually called something with either
    libc or crt in the name, for historical reasons) is considered
    last. So if you've provided an ::eek:perator new, it gets pulled
    into your program before the standard one, the unresolved
    external is no longer unresolved, and the object file with the
    standard ::eek:perator new is not made part of your program.

    Note that if the only use of ::eek:perator new is in the standard
    library, there might not be an unresolved external for it when
    the compiler processes your library; in such cases, you will get
    the standard one. (Given the amount of template code in the
    standard library, and the fact that template instantiations are
    in the translation unit which uses them, this is in fact highly
    unlikely. You might not use ::eek:perator new explicitly, but
    classes like std::basic_ostream and std::basic_istream do.)
    Similarly, if you define ::eek:perator new and ::eek:perator delete in
    separate source code modules, it's possible for the symbol for
    ::eek:perator new to be unresolved, but no reference to ::eek:perator
    delete yet to have been seen, or vice versa---in such cases, the
    compiler will pull in your ::eek:perator new, but not your
    ::eek:perator delete, or vice versa, which will cause problems
    later. (The simple answer to this is "don't do it".)

    At least under Unix (and probably Windows as well), it is
    possible to have problems if you force consideration of the
    standard library before you include your version. But it takes
    some pretty unusual and convoluted commands to do so.

    Other solutions are possible, of course, like using weak links
    or a special command line option, but as far as I know, the
    above solution is pretty much the only one actually used in
    practice.

    --
    James Kanze (Gabi Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 8, 2007
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Guest

    not linking msvcr70.dll

    Guest, Aug 11, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    953
    Guest
    Aug 11, 2004
  2. Guest
    Replies:
    4
    Views:
    473
    Guest
    Oct 13, 2004
  3. Pekka Järvinen
    Replies:
    2
    Views:
    657
    Richard Tobin
    Apr 29, 2008
  4. Replies:
    4
    Views:
    206
    Tad McClellan
    Jun 1, 2007
  5. Replies:
    9
    Views:
    151
Loading...

Share This Page