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: Tue, 17 May 2011 17:37:53 -0400 Organization: Friends of the Galactic Collective Lines: 54 Message-ID: <1e4faf063b586a4-388ce@gmail.com> References: <9322eedb3a632f5-29a98@gmail.com> <70b21f510c7390e-cc0de@gmail.com> <649063b2282a33c-c8c94@gmail.com> <58cd71f7945b428-9876d@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="C0fhggvyHjVJR/UuPkOfnw"; logging-data="16367"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/qxKT3sMwwfcDCvlEmnEym" User-Agent: nn 6.7.3 Content-Length: 2109 Cancel-Lock: sha1:sOX8TZ3ai7za5/ylnN9q9OSLfuc= Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:4192 On Tue, May 17, 2011 at 04:14:50AM +0000, Seebs wrote: > On 2011-05-17, Uncle Steve wrote: > > On Tue, May 17, 2011 at 02:40:15AM +0000, Seebs 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? > > Otherwise, the big deal is that if there's a bug, *by definition* you > don't quite understand how the code works. Figuring it out necessarily > involves understanding something you didn't understand when writing it. Your approach to the problem assumes bugs a priori. It's fairly difficult to argue against a position where someone has already assumed the concluding point. > If something is near the limits of what I can design and code correctly, > it will be Too Hard to debug. I might be able to muddle through, but in > general, it'll stump me. > > So I carefully write stuff that's as simple as I can make it, to reduce > the risk. Of course. No programmers expose themselves to the risk of error intentionally. Slow and steady as she goes is the order of the day in programming. > >> 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"? > > I mean "trying to make code faster by means other than algorithm design". > Stuff like, say, trying to hand-tune assembly, or trying to decide when > a loop should or shouldn't be unrolled, anything like that. The kind of > thing that is implied by trying to decide whether something will fit in > an instruction cache. I suppose it depends on the application. Some people go to lengths to avoid cache-line thrashing, and all the rest. Most applications don't require that level of analytical detail, and so your point is valid for the majority of cases. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?