[Scroll down for an English translation and answer...]
ðÒÉ×ÅÔ äÍÉÔÒÉÊ,
éÚ×ÉÎÉÔÅ, ÐÏÖÁÌÕÊÓÔÁ, ÞÔÏ Ñ ÔÁË ÐÌÏÈÏ ÇÏ×ÏÒÀ ÐÏ-ÒÕÓÓËÉ. îÏ ÚÄÅÓØ
ÍÅÖÄÕÎÁÒÏÄÎÙÊ ÆÏÒÕÍ "comp.lang.c++". úÎÁÞÉÔ, Ë ÓÏÖÁÌÅÎÉÀ, ÞÔÏ ÎÁÐÉÓÁÔØ
ÐÏ-ÁÎÇÌÉÊÓËÉ Õ ÎÁÓ ÏÂÑÚÁÔÅÌØÎÏ. ìÕÞÛÅ ×ÓÅÇÏ ÂÙÌÏ ÂÙ, ÞÔÏÂÙ ÐÏÌÕÞÉÔØ
ÏÔ×ÅÔ ÐÏ-ÒÕÓÓËÉ, ÔÁËÖÅ ÐÏÐÒÏÓÉÔØ Ë ÆÏÒÕÍÕ "relcom.comp.lang.c-c++" ÉÌÉ
"relcom.fido.su.c++" ÉÌÉ ÄÒÕÇÁÍ ... ÍÎÏÇÉÅ ÔÁËÉÈ ÆÏÒÕÍÏ× ÅÓÔØ.
[ïÔ×ÅÔ ÄÁÌØÛÅ ×ÎÉÚÕ...]
÷ ÐÒÏÅËÔÅ × Ä×ÕÈ ÒÁÚÎÙÈ .cpp ÆÁÊÌÁÈ ÏÐÒÅÄÅÌÅÎÙ ÏÄÉÎÁËÏ×ÙÅ
ÆÕÎËÃÉÉ, ÎÁÐÒÉÍÅÒ:
void foo () { return; }
÷ ÔÒÅÔØÅÍ .cpp ÆÁÊÌÅ ÅÓÔØ ÏÂßÑ×ÌÅÎÉÅ É ×ÙÚÏ× 'foo'
ËÔÏ-ÎÉÂÕÄØ ÚÎÁÅÔ, ÓÕÝÅÓÔ×ÕÅÔ ÌÉ ÔÅÏÒÉÑ, ÏÐÒÅÄÅÌÑÀÝÁÑ ÐÏ×ÅÄÅÎÉÅ
ÌÉÎËÏ×ÝÉËÁ × ÔÁËÉÈ ÓÌÕÞÁÑÈ ?
ÞÔÏ ÂÕÄÅÔ ÅÓÌÉ
- ÄÏÐÏÌÎÉÔÅÌØÎÙÅ ÏÐÒÅÄÅÌÅÎÉÑ ÆÕÎËÃÉÉ ÓÏÄÅÒÖÁÔØÓÑ × .lib (.dll),
ÐÏÄËÌÀÞÅÎÎÏÊ Ë ÐÒÏÅËÔÕ ?
- ×ÙÚÏ×Ù ÆÕÎËÃÉÉ ÓÏÄÅÒÖÁÔØÓÑ × .lib (.dll),
ÐÏÄËÌÀÞÅÎÎÏÊ Ë ÐÒÏÅËÔÕ ?
ÐÒÁËÔÉÞÅÓËÁÑ ÓÔÏÒÏÎÁ: ÎÅÏÂÈÏÄÉÍÏ ÐÅÒÅÏÐÒÅÄÅÌÉÔØ
ÇÌÏÂÁÌØÎÙÊ new & delete, ÔÁË ÞÔÏÂÙ ×ÓÅ ÂÉÂÌÉÏÔÅËÉ, ÉÓÐÏÌØÚÕÅÍÙÅ
× ÐÒÏÅËÔÅ (ÓÏÄÅÒÖÁÝÉÅÓÑ × .cpp, .lib, .dll)
×ÙÚÙ×ÁÌÉ ÐÅÒÅÏÐÒÅÄÅÌÅÎÎÙÅ new & delete
==============
First, a rough translation of the question which was posed in Russian
[use a Russian font with KOI-8 code page to view properly]:
"Let's assume that there are two different .cpp files within the same
project, each with different implementations of the same function, for
example:
void foo() { return; }
"In a third file, there is also a declaration of the function "foo".
"Can anyone tell me how the linker is supposed to behave in such
situations?
"What happens:
- if there are additional implementations of such functions in a .lib
(.dll) which is included in the project?
- if the .lib (.dll) contains declarations of the functions?
"The practical situation is that it is necessary to overload global
new and delete so that all libraries included in the project use the
[same] overloaded new and delete."
==============
Difficult to answer with my bad Russian, but I'll try in English:
If the linker cannot resolve the different functions, you receive a
linker error. Be very grateful in that case! Problems arise when new
and delete are implemented differently in the library than in the
other modules, and you do "new" in one module, but "delete" in
another. This is especially true when some modules are using static
libraries and others not.
There are some ways to avoid such problems:
(a) Implement the functions (here: new and delete) in a DLL and make
sure that all modules use dynamic runtime linking to use the same DLL;
(b) Link everything statically with the same static memory-management
DLL;
(c) Always do "delete" in the same module where "new" is called. If
you must have different implementations, this is the only way to do it
AFAIK.
For example, you want to (or must) allocate memory in a DLL and return
a pointer to that memory to the calling function in another module.
Implement a "FreeMemory" function in the DLL which deletes the memory
instead of having the caller do it by calling "delete". The
implementation of "FreeMemory" is trivial -- you just call "delete"
(or "delete[]", as the case may be) but you are then sure that the
memory will be deallocated properly.
