Not that it's necessarily the right thing to do in your particular
application, but I'd chalk it up to a matter of style rather than a
clear-cut right or wrong situation.
Absolutely. My post was simply to point out that I was thinking about
ludicrously small optimizations in an arena where you're least likely to
be concerned about such a thing, rather than which answer ultimately is
"correct". Sure, were my app's success measured in frames per second I
might worry about something like this... but then you'd be using C or
asm anyhow, much more than likely.
VB, Java, .NET and friends all sacrifice (if you'll forgive the
oversimplification) speed for ease of programming and program
maintenance. COM is a perfect example -- I've seen a couple of suites I
work with go from "pure code" to easily reused objects in a COM
architecture. But in both circumstances the hardware available didn't
provide similar "eyeball" performance in the new COM-based product
compared to the old C-based for four years or so. VB6, particularly VB
as glue between COM objects, absolutely isn't a place where speed is
goal number one.
At the same time I think Mark's point is on the money -- there are
certainly people who are too liberal in coding style, and will overuse
objects in place of smart code and, more importantly, *smart coding
practices*. People who understand the value of simply thinking about
whether comparing err.number to 0 and then potentially taking a branch
versus setting to 0 each time are more likely (if you ask me) to design
software that at a macro level will be just as frugal and carefully
constructed. People who don't understand how to conserve and program
elegantly certainly make slow, crappy code. I've seen it over and over
(and probably guilty of it as well a few times!). And as Mark pointed
out, where you've got bits-a-plenty, cycles do start becoming awfully
sacred.
I would love to hear of 6502 asm/2600 programming forming part of a comp
sci cirriculum. I don't know what good working with all the registers
and instructions you'll find in a modern-day x86 chip really does for
the future .NET programmers of the world (C programmers, again, a
different story). I even made a quick pitch to O'Reilly about making a
book that covered the subject (in which case I finally would have to
write a game! Woohoo!). The lessons I learned when I actually tried
making a demo or two for the 2600 have served me right well once I
entered the workplace of zeroes and ones (no formal training, unless you
count a Pascal course in high school).
At any rate, sorry to get long-winded, but just wanted to say, "Watch
out newbies; crack open dasm and you might just learn something!"
Ruffin Bailey
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
