Something about Linking

  • Thread starter comp.lang.c++.moderated
  • Start date
C

comp.lang.c++.moderated

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

Bo Persson

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
 
J

James Kanze

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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,431
Messages
2,571,679
Members
48,796
Latest member
Greg L.

Latest Threads

Top