delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/09/30/16:28:52

Message-Id: <199909301623.TAA08201@ankara.Foo.COM>
From: "S. M. Halloran" <mitch AT duzen DOT com DOT tr>
Organization: User RFC 822- and 1123-compliant
To: djgpp AT delorie DOT com
Date: Thu, 30 Sep 1999 20:29:18 +0200
MIME-Version: 1.0
Subject: Re: Linker trimming unused code/data
In-reply-to: <37F33128.C1086E5F@maths.unine.ch>
X-mailer: Pegasus Mail for Win32 (v3.12)
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On 30 Sep 99, Gautier was found to have commented thusly:

> Is there a way to make ld trim unused code/data ?
> It _seems_ not to do such deletions...
> Is there an alternative linker ?

The object file (*.o), whether archived in a library (*.a) or existing by 
itself, is the smallest, indivisible element the linker can deal with.

That means if you have function definitions (or instances of classes?) taking 
up large footprints in terms of byte size, you probably need to organize your 
source files better, placing many function definitions/globals in a few large 
source files into new source files.

I haven't read any books on how to organize code, manage (big) projects, and 
design well-written applications of moderate to huge size, but there is 
probably a general feeling that each source module should contain as a rule 
only one public (extern) function definition, with all other function 
definitions inside the module declared private (static) and being used either 
to support each other and/or the public function.  That way if you get the 
compiler saying "this function declared static but is unused", that function 
definition probably belongs in a separate source file as a "helper" or as the 
source file's public function or should be deleted.

There are people who like to pile it all into one source file, even if it's a 
150,000 - 200,000 lines of source code, and then there are people who go the 
other extreme and put only one function per file, perhaps trying to win some 
competition for getting the smallest executable footprint with maximal coding 
"power".  The well-done project is probably somewhere in between.


Mitch Halloran
Research (Bio)chemist
Duzen Laboratories Group
Ankara       TURKEY

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019