Path: chuka.playstation.co.uk!news From: gil@snsys.com (Gil Jaysmith) Newsgroups: scea.yaroze.problems.pc Subject: Re: long long ints for improved accuracy Date: Thu, 18 Dec 1997 12:57:04 GMT Organization: SN Systems Lines: 46 Message-ID: <3499196c.1356650@news.playstation.co.uk> References: <673eim$9k36@chuka.playstation.co.uk> <6740vu$9k39@chuka.playstation.co.uk> <676jav$9k310@chuka.playstation.co.uk> <3497b487.81595878@news.playstation.co.uk> <01bd0b87$760261c0$b8bf43ce@wkwerner> Reply-To: gil@snsys.com NNTP-Posting-Host: trish.snsys.com X-Newsreader: Forte Free Agent 1.11/32.235 "Wayne K. Werner" wrote: >> Good linkers should only ever load in the individual object modules >> which are referenced from libraries. >I don't know of a linker that doesn't! The original message seemed to be implying that there was one that didn't, so I CMAed. I'd hope there isn't a lazy linker which brings everything in, since it'd give you a heart attack when you saw the image size. >BTW, related functions, that are always used >together (ie. init and term functions of a library) should not be >separate. If you use one, you use the other. Also, consider >something like a 3d engine. You know if you init it, you are >also going to call add_object(), del_object() etc, or there is >no point in initing the engine. There is no reason, based on >linking considerations, not to put all of the functions in the >same source module. Logical considerations (grouping for >functionality, for instance) are another matter. True. This also applies to any state variables you happen to require exported from the module. Standard C Library will tend towards the one-per state because the functions are usually orthogonal; you might get strlen packed in with a couple other functions in a basic string object, but other than that, and certainly in the PSX's case, it's one-per until you hit the movie library or suchlike. Neat segue to engines: a group of related functions should, as you say, be treated as a logical class, whether or not it's actually in C++, and classes should be grouped into a single object. In C++ doing this yourself saves you hassle rather than space, since the virtual function table requires all the class functions to be linked in anyway; their addresses are taken at link time. In the case of C where the functions are logically grouped but not specifically referenced other than by the user code, it's potentially the case that fine-tuning the granularity will save you a few bytes if the linker can't strip dead code. For example: most PSX games don't terminate, whereas most PC games do, and since most games available on both formats are ported from the PC rather than to it, you're more likely to find code which you may not eventually need, mostly destructors and graceful-cleanup routines. All of which might sound like a hell of an extreme case, but since PSX developers are regularly on the phone to ask how they can find another 2K (or less), I tend to trade in extreme cases :=) - Gil