From: Mike McCarty (jmccarty_at_ssd.usa.alcatel.com)
Date: 2001-03-05 20:33:55
My message was not intended to be an attack.
On Mon, 5 Mar 2001, Ullrich von Bassewitz wrote:
>
> On Mon, Mar 05, 2001 at 11:24:47AM -0600, Mike McCarty wrote:
> > For better readability you may want to use macros:
> >
> > #define POKE(addr,val) (*(unsigned char *)(addr)=(val))
> >
> > This definitely REDUCES readability and obscures what the code
> > is doing.
> >
> > Which code is easier for you to read?
> >
> > (a) VideoMode = VIDEO_REVERSE;
> >
> > (b) POKE(199,1) /* Set video mode to reverse */
>
> Your quote is completely out of context (or my english is even worse than I
> thought). The sentence "For better readability you may want to use macros" on
What I saw was a section headed by the statement followed by
two sets of macros. Since no restriction was made on the statement
regarding *which* macros enhanced readability, I thought it
was obvious that it applied to both.
> the page references the example above (in the FAQ), where memory access is
> done in full length. Which code is easier for you to read?
>
> (a) *(unsigned char*)199 = 1;
>
> (b) POKE (199, 1);
I like neither of those two lines, but the first makes more sense
to a C programmer. It at least states what is being done. Both of them
suffer from having direct numbers in them. I prefer
POKE(VideoMode,REVERSE_VIDEO);
to either of them, and prefer
VideoMode = REVERSE_VIDEO;
to all the others put together.
> And, later on I'm proposing predefined variables for hardware access, saying
> that this is the most readable way. So where is the difference between your
> statements and mine?
This I didn't see.
> > I recommend that people NOT implement PEEK and POKE at all. The direct C
> > is more readable than the macros. Even better is to implement macros
> > which make the code understandable without having to add comments.
>
> For someone with a BASIC background (and many people programming the old
> machines do have BASIC knowledge), PEEK and POKE are completely readable and
People who have a BASIC background, and are making a transition to C, would
be well advised to abandon some of the bad practices common in BASIC. This
is one of them.
> do have a meaning. It is easy to translate BASIC programs using PEEK and POKE,
> this would be another reason to use them. So while I would recommend to use
You mean it is easy to get a program which is equivalent and has
whatever defects were present in the original, whether forced by the
language or not. When I modify code, and am spending time with it as
much as is required to make it work in another language, I want to
improve it if I can.
> fixed memory variables as I have done in the FAQ and in posts to this list, I
> don't think that PEEK and POKE are evil. Just use what is best in a given
> situation.
"Evil" is a strong word; I wouldn't use it. In my mind, though, they
are on a par with code written like this in C (all variables are
global, of course)
L100: Count = 1;
L110: if (Count >= 11) goto L200;
L120: Gosub500();
L130: Count = Count+1;
L140: goto L100;
L200:
...
void Gosub500() {
L510: printf("Count = %d\n",Count);
L520: return
}
...
It may be easy to do, but it is not desirable to do, and incorporates
some of the poorer features of a cruder language into a more refined
language. It is gauche.
It also presumes that one can modify a program without understanding
what it does. Taking the time to understand the program may reveal that
it actually does not work properly. In the projects which involve
translation from assembly to C that I have been involved in, several
serious defects were found in the original code and repaired, due to
having to spend the time to understand what the code does. Often very
tangled logic got raveled and turned into clean easy to read code.
BASIC (in its early incarnations) forced a very assembly type
programming style.
Mike
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:39 CET