Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Uncle Steve Newsgroups: comp.lang.c Subject: Re: Non-constant initializers Date: Mon, 16 May 2011 04:49:40 -0400 Organization: Friends of the Galactic Collective Lines: 104 Message-ID: References: <0ca8ca5b-e73e-418a-935f-0fcc17fdf404@q14g2000prh.googlegroups.com> <9322eedb3a632f5-29a98@gmail.com> <70b21f510c7390e-cc0de@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: mx03.eternal-september.org; posting-host="9mti4zl2mrQmHFyxsa0q3g"; logging-data="25079"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/0ocJtCFVyA43dsj/eY+sC" User-Agent: nn 6.7.3 Content-Length: 4418 Cancel-Lock: sha1:/9J9nmSxwoc++dCFl66tMPWHrrw= Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:4057 Sorry, skipped your message this morning by accident. On Sun, May 15, 2011 at 03:59:14AM +0000, Seebs wrote: > On 2011-05-14, Uncle Steve wrote: > > You're making this too easy. What could be cleaner than a variable > > declaration outside of main() which also initializes it to the value it > > should have before main() is called? > > Nearly anything? Most cesspits, for instance. > > I'm fully aware that I can > > assign a value to a variable any time I write code or macros to do it, > > but there are certain kinds of application parameters, for instance, > > which you may derive empirically, and assign once. I should think > > that most programmers know about these types of variables. > > Yes. I set them up at some point AFTER the program has started running, > because before it's running the world is not in a known or well-defined > state. Well, it's fairly difficult to approach this without making reference to a specific implementation. main() is supposed to be the defined entrypoint for C programs, and anything that happens before that is supposed (I assume) to set up the execution environment defined by the standard, and is implementation specific. OK. I get it. Sorry for my confusion over what the gcc info doc said. > > It could do just about anything if it was a C function, couldn't it? > > Well, that's the thing. How much do you know about the way in which > the library initializes various internals which need to be in a particular > state for your code to execute? I don't know anything about how the system libraries are initialized. Perhaps I should look; glibc, ulibc, bsd libc, etc. probably all do things differently (within reason), meaning I'd probably have to code a special case for every port of the app. if I was to use implementation- specific hooks. > > I'm big on macros, but sometimes they clutter up the code with > > redundant code blocks that are deader than a doornail. Maybe the > > compiler will weed them out with global CSE, maybe not. If they > > aren't in the code to begin with, they can't possibly get into the > > instruction cache. > > I refer you to Rules 1 and 2 of optimization. > > Which is to say: > > Rule 1: Don't do it. > Rule 2 (only for experts): Don't do it yet. I rely on a consistent heuristic: develop efficient coding habits. Within the limits of my skill, this seems to work ok. I don't really agonize over loops as I might have when I was a teenager fooling around with asm on small machines. I know the other Rule of optimization: Rule 3: Write better algorithms. Which isn't to say that it can't be fun to find a clever way to shave cycles. There are an endless number of programming tricks that one can experiment with, on critical paths, if you've got the time. > For the sorts of things it makes sense to try to use as initializers, you > can reasonably be confident that the value will be fully computed before > your code is done compiling. For many scalars and string constants this is true, and I have no argument about that fact. What this is becoming, however, is a pedantic disagreement over the validity of function calls in the outermost scope of a C program. It seems a little arbitrary that function calls are only valid in the main() scope, or at least this is what I perceive as being what the standard says from your replies. Don't worry, I'm not going to press the C2015 Committee[1] to revise the standard. I simply don't care about it all that much, but it is worth noting. > There are, right now, probably as many as two dozen people in the world > who have a legitimate reason to form thoughts like "what if this code > ends up in the instruction cache?". You are not one of them. Alas, you have penetrated my disguise. I am not worthy to decide what code should or should not be in the instruction cache. I am sorry if I have offended your grace, or shamed the honored guild of instruction cachers with my unworthy considerations. In the Future, I will endeavor to think about memory as a transparent medium of data storage. [1] Joke. Not sure what the next revision of C will be called. I can't see there being many changes at this point, C should be about ready to be carved in stone by now. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?