Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!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 22:50:42 -0400 Organization: Friends of the Galactic Collective Lines: 69 Message-ID: <58cd71f7945b428-9876d@gmail.com> References: <9322eedb3a632f5-29a98@gmail.com> <70b21f510c7390e-cc0de@gmail.com> <649063b2282a33c-c8c94@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="18077"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+M7tzfTyJ8IWsCYYN+TPc9" User-Agent: nn 6.7.3 Content-Length: 2741 Cancel-Lock: sha1:dM02DgaSu3j86Wh9E5fB4RvdbxM= Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:4147 On Tue, May 17, 2011 at 02:40:15AM +0000, Seebs wrote: > On 2011-05-17, Uncle Steve wrote: > > That depends. Every function has it's own ranking of relative hotness > > within the application. If you've got money to burn, you can afford > > to throw as many programmers as you want at the problem. Maybe you > > have so much money you don't care that they're optimizing the > > documentation tools. All I know is that I have programming > > proclivities that lead to Cycle Conservation, and who could argue > > against that? > > Someone who has had to debug code that was written with "efficient" habits. > > > I've heard that before, and what I say is that the same skill that is > > used to write the code is also used in debugging the code. I really > > don't see how I'm going to write myself into a situation where I cannot > > debug any system that I wrote. > > Very easily. It is harder to understand how code is failing than to > understand how it's supposed to work. If you don't understand the machine. Or if there's stuff going on that's undocumented. Otherwise, what's the big deal? > > Sure there can, but it must rely on implementation specific > > documentation. > > And even given that... Who says they'll not change it later? Nothing > to keep them from doing so. Who says the documentation is right? Who > says they'll fix a "bug" in this stuff? > > It's the kind of thing people tend to not care about. > > > Maybe, but I think you presume too much when you assume that the > > compiler should be the arbiter of optimization. Possibly some far-in- > > the-future compiler will have strong-AI capabilities wrt code > > generation, but until that time the human programmer will probably be > > able to do a better job than the compiler. All things being equal. > > Well, uhm. > > No. > > It's been at least a decade, probably longer, during which humans have > consistently lost to compilers at optimization. What do you mean by "optimization"? > > Are you saying that there are major changes to the C standard in the > > offing? I don't see how that could be without changing fundamentals, > > and we all know that that is about as likely as porcine avians. > > I don't know about "major", but certainly "significant". Compound literals > were a major change, and I wouldn't be surprised to see comparably significant > changes in future revisions. Yeah, well maybe I'll just become one of those wierd people who lock in all their code to C99, no matter what developments arise. I could do that, you know. I'm a wierdo. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?