aleksa said:
void setpixel(unsigned char *buff, int width, int height, int x, int
y, unsigned char red, unsigned char green, unsigned char blue)
{
 unsigned char *pixel = buff + ((y * width) + x) * 3;
 pixel[0] = red;
 pixel[1] = green;
 pixel[2] = blue;
}
Thanks, pretty straightforward, but I'll have to convert it to
monochrome BMP.
(There will be a chorus of demands to use size_ts instead of ints,
which are correct.
My English is poor here..
Do you say that people would say size_t is a better choice here,
but *you* stick with ints (as in, sorry folks, ints are correct)?
Yes, I think that's what Malcolm is saying.
Incidentally, I had to go back to the parent article to confirm that
Malcolm was the one who wrote it. Please leave attribution lines in
place for any quoted text.
Why would size_t be better? From what I read here:
http://bytes.com/topic/c/answers/220206-what-size_t
size_t should not be used here..
Speaking of unattributed quotations, that web page appears to be a
copy of a thread from comp.lang.c, published with no indication of
where it came from and with a strong implication that the articles
were posted by bytes.com's "community of C / C++ experts". So this
article will probably appear on bytes.com as well.
To anyone reading this on bytes.com: I am not a member of this
"community", and bytes.com does not have my permission to re-post
this article or falsely claim credit for it.
Anyway, the thread you refer to includes several different opinions on
the topic. The statement that you should use int rather than size_t
appears to be from Malcolm, the same person you were replying to,
so I wouldn't say it's supporting evidence.
My own opinion is that size_t is the appropriate type to use for
an array index. It's ok to use int if you're reasonably sure
that indices cannot exceed INT_MAX, but can be difficult to be
sure of that as the program is modified in the future. size_t,
on the other hand, is very nearly guaranteed to be big enough
(the rationale for that has been discussed here at length before).
Also, width, height, x and y are always positive values,
so int could/should be unsigned int (by my POW).
I've seen examples where always-positive variables are
not defined as unsigned int, only int, so I'm doing the
same, even though I don't understand why.
unsigned int typically (almost always) can represent a wider range
of positive values than int. For example, on a 16-bit system
INT_MAX is typically 32767 and UINT_MAX is typically 65535.
So that might be a slight advantage for unsigned int over int.
But size_t (another unsigned type) has the further advantage that
it's guaranteed to be able to represent any valid array index.
There are some pitfalls in using unsigned types (unsigned int,
unsigned long, size_t, etc.). Integer types, whether signed
or unsigned, represent a finite subrange of the infinite set of
mathematical integers. If you stay well within that subrange, you
can safely pretend that you're dealing with mathematical integers.
As you approach the endpoints of the range, you can run into cases
where the results of a calculation don't match the mathematical
result, and may not even be well defined. For signed types, those
endpoints are at large negative and positive values that you're often
not likely to reach. For unsigned types, one of the endpoints is at
0, well within the range of values you're likely to be dealing with.
An example:
unsigned int count = 10;
while (count >= 0) {
/* ... */
count --;
}
This is an infinite loop, because the condition "count >= 0" is always
true.
Using int for array indices is quite common, and I'm not saying
that it's wrong. But I do think that size_t is the safest and most
sensible type to use for array indices. You just have to keep in
mind that it's an unsigned type and watch out for any pitfalls.
Obviously not everyone agrees.