Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.software-eng Subject: Re: Coding standards (was Re: Programmer productivity) Message-ID: <7240@ficc.uu.net> Date: 8 Dec 89 18:49:35 GMT References: <1989Dec6.154103.2078@twwells.com> <14850@well.UUCP> <41413@improper.coherent.com> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 25 In article <41413@improper.coherent.com> dplatt@coherent.com (Dave Platt) writes: > One way in which a savvy C compiler could resolve this, would be to bundle > all of the global variables into a dummy module. ... > An effective C compiler can get around this problem by hashing the names > of the static variables into some horrible string that's guaranteed not > to collide with any other name. Just maintain the address of the start of the dummy module and access the variables as __module_start+offset. This is a common trick for dealing with Cs "file common" scope. No, there's really no reason that you can't have C compiler in a module- oriented system with a function-scope linker. It's just that in general the savings from this aren't very great. For example, look at the common situation where you have two routines to allocate and deallocate a resource: they might as well go in one file... and you're unlikely to be using one of them without the other. And besides, if you're designing a library you really should be doing more than sticking all the modules in a file and compiling them anyway. -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "If you want PL/I, you know where to find it." -- Dennis