No, this has nothing to do with '51s, but I want the opinions of some of you tenured chaps: In a circular queue, what do you consider the head and what do you consider the tail? I've always know the tail as the point (index, whatever) that points to the next available free space in the buffer. That is, data is placed IN at the tail, and removed from the head position. I learned this definition years ago when digging into the IBM PC's keyboard buffer and a book on the topic listed the pointers as I describe above. That's how I've thought of them ever since and is how several google results describes them as well. You?
I can not make head or tail of these names and have thus abandoned them. I use fetch_ptr and store_ptr or fetch_offs and store_offs. If someone reading your program can not immediateley figure out which is which, then names contradict good programming practice. Erik
I can't disagree with either of your replies...makes perfect sense and I'll probably switch to those terms. Problem is, I'm (once again) changing the diapers of someone elses *** child and a) the term "head" and "tail" seems to be used frequently, and b) they seem to be ass-backward from the way I learned it and from what I glean from web searches. Is there any standard when using these terms? ...or did someone simply pull them out of thin air years ago?
Queueing at the head of a line at the bank or post office makes people mad. That's why I always enqueue myself at the tail and let the person at the counter dequeue people from the head of the line. Smart people do it "the one true way" ;-) -- Enqueueing at the tail and dequeueing from the head. I personally don't use the head/tail nomenclature because there is too much confusion. So much so, that I've actually seen the head/tail roles reversed in the same client project. I do like the others have mentioned and use read/write pointers, get/put pointers, etc.
Good analogy, but since you're now the 3rd person to confirm the confusion, I'm convinced I'm going to change. Frankly, working with one's self is never a problem. Doing it with legacy code and with teams...becomes a different issue.
Frankly, working with one's self is never a problem I strongly disagree. Have you never had to work on some of your own stuff you had not seen for, say, 5 years and had to add/change comments to make your own stuff understandable to yourself? The comments, names etc used when in the middle of development may, at that time, make perfect sense, but to somone that does not have "the picture" in his/her head they may be total gobbelygook. The old adage "comment for the benefit of others" may very well be true, but as we all, to some extent are egotistical, I like "comment for your own benefit" better. Erik
I strongly disagree. I agree with what you said in that sense...yes, we all wonder WTF we did in our old code from time to time. What I was referring to was specifically the "head & tail" terms: I've never had any problem with understanding those in [b]my[/b] code because I've been consistent from day one with them. Dealing with "diaper code" where there's 3 or 4 different authors mangling different styles together (which describes the current mess I'm saddled with) is a different story.
The old adage "comment for the benefit of others" may very well be true, but as we all, to some extent are egotistical, I like "comment for your own benefit" better. How true. Have you ever heard the argument "If you can't comment it in the code well enough for ANYONE to understand, then you don't understand it yourself"? I love that one.
In the interrupt-driven serial I/O routines I've written (http://www.keil.com/download/docs/intsio2.zip.asp) I name the head and tail in and out. I think that's pretty clear. Jon