Having not tried 2006, I am not certain as to linking, but it is likely that unless optimization is turned on that it will be compiled in.
Pascal unit design is intended to be the modular linking level. Ie if you use a dcu, the dcu is linked. Any special Delphi gymnastics on top of this would be unknown unless the answer comes from a published whitepaper, or you disassemble yourself and look. I guess the safest answer is to refactor. That's what programmers do. See a flaw in code locations due to changes in time, and move stuff around. If you place your concerned function call into its own unit then you can guarantee its only linked into the apps that you want. That's really much easier than wondering what the linker does each time you change versions. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Bird Sent: Sunday, 28 May 2006 11:48 a.m. To: 'NZ Borland Developers Group - Delphi List' Subject: [DUG] Delphi Linker A question about the Delphi 2006 linker -I thought I had this answered some time ago, but now I am not sure. If I have a code only unit (no form) that has a number of utility procedures and functions in it, and I use 1 or 2 in a program does the whole unit get linked in or only the used functions/procedures. I had an answer before (see below) that unused procedures are eliminated by the linker. Now I suspect this maybe is wrong: I have such a library unit. One procedure in the unit has some proprietary code that is only used by one program run in house, and is large. I do not want this code included in any other programs, for reasons of size and also for giving others an opportunity to disassemble it. It is not called by any other program so I assumed it would be ommited from the exe files. HOWEVER out of curiosity I examined the exe file of a program that does NOT call this procedure and found one of the constant strings declared only in this procedure WAS IN the exe file. So does Delphi link in unused procedures in a unit or not? Does anyone know the internal workings of the Delphi Linker and can comment? ====previous on the subject Date: Aug 10 2005 - 4:12pm [DUG] ========== Tracey: my speculation stands corrected ;) if your answer is more concrete than mine :) it does sound reasonable. Dennis Chuah wrote: > > This is incorrect. The compiler optimisation switch does not control > how the linker works. Basically any unit level procedures and > functions or symbol that are not referred to are removed by the > linker, optimisation or not. All static or class methods are similarly > treated. Any virtual or dynamic methods, even private ones, are NOT > elliminated by the linker and will always be included. Code in the > initialization section and in the DPR is always included. > > In a DPK, the whole DCU is included. > > Related ... all class data members are always created when a class is > constructed, even unused private members. > >> From: Kyley Harris <[EMAIL PROTECTED]> >> Date: Wed, 10 Aug 2005 15:01:45 +1200 >> >> Delphi links the entire DCU into the application. The idea is to keep >> dcu's as concise as necessary, and to remove >> unneeded ones from the uses clauses. with Optimization turned on when >> you compile a dcu it will remove any >> lines of code that are perceived as unnecessary to the application. >> >> John Bird wrote: >> >>> A question about how Delphi works... >>> >>> 1 - Main question is about Library routines. I maintain a library >>> unit with >>> a lot of (non-visual) procedures and functions for various >>> miscellaneous >>> tasks - date formatting, number formatting, file i/o etc. Some 70 >>> routines >>> and growing. Now when I use this unit in a program, does (a) >>> everything in >>> the unit get compiled and linked in, or (b) is it smart enough just >>> to get >>> just the code called (including library procedures called from another >>> called from the program). I have come from another language where it >>> always >>> did (b), hoping Delphi is as smart. If not, then I need to separate my >>> library procedures into smaller logically related units rather than one >>> humungous big unit with everything in it to avoid the programs getting >>> bloated with non-used code. John _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi
