|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
On Sat, 2002-07-06 at 10:21, gabriel rosenkoetter
>
> I'll grant that didn't *used* to be as easy as it is now, but there
> is certainly no excuse for things like hand-coding assembler-style
> optimizations into even C code these days (and for the past five
> years at least). It is completely possible to apply OOP techniques
> in C, and no reason not to. The fact that the language lets you do
> stupid things is a terrible reason to actually *do* them.
Well the problem with languages like C is that there are SO MANY stupid
things you can do by accident, by leaving off a * in front of a
variable, etc., that it is bound to happen eventually.
Think about:
Say I have a function, I have a number I pass to it. The function
always takes a value between 1 and 30. In C, I would see this declared
as an integer... and you could physically pass any value to it. So it
could happen somehow that the number 5000 or -50 gets passed to it, even
as a constant. In pascal, you can of course do it the same way, but you
can also declare a type holding between 1 and 30. Suddenly, anything
that the compiler can catch at compile-time (like using a constant of
3000 where this data type is used) will throw and error and halt the
compile. Since this is done at compile time, it has no run-time penalty
on the code, it's "Free" error checking - why NOT use it? (You can also
enable run-time checking, which will catch assignments that are invalid
at run-time, but this will have a performance penalty and slow down the
program, so this is typically used only for debugging).
It's like when I took accounting. We had to do it on paper, and add up
huge columns of numbers. Despite the fact that it was simple
arithmetic, it was very likely you would make a mistake going down the
whole page, and something wouldn't quite add up. Programmers like to
use C because it allows control, and they say "I know what I'm doing",
but then because of a little typo, there is a int that is being seen as
a pointer, something allocated that is never released, or some buffer
overflow problems. Many of the most common programming errors simply
don't happen in languages like pascal and modula 3.
Some things that sound like a good idea in theory (for example, OOP)
cause problems when put into practice too much (f.e. too many levels of
inheritance slows things down). Since compile-time checking is "Free",
I think it should be used wherever possible. I heard the argument
before like "well I don't know what values this int might hold!"... well
then you should sit down and think about the program a little before you
code! Am I wrong?
-- noah silva
______________________________________________________________________
Philadelphia Linux Users Group - http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion - http://lists.phillylinux.org/mail/listinfo/plug
|
|