Christopher Coale <chris95...@...> wrote: > Paul Herring wrote: > > billcu34<bill...@...> <mailto:billcu1%40suddenlink.net>> wrote: > > > > double Sma(double *ds, int size) > > > > { > > > > double res = 0; > > > > for (int i = 0; i < size; i++) > > > > res += ds[i]; > > > > return ds / (double)size; > > > > } > > > > > > My compiler complained about the ds in the return statement. > > > It wanted this I guess 'cause I changed it and it accepted.
Guessing is bad programming. The error is that ds has pointer type. You can't divide a pointer. > > It should in fact read > > return res/size; Which highlights the need to find the source of errors, rather than just band-aiding them. <snip> > Yeah, my mistake. I didn't bother testing - I just typed it > in the e-mail quickly. > > Casting to a double is to avoid compiler warnings A bad practice. You silenced the warning but completely ignored why it was issued. So instead of fixing the problem, you white-washed it. > (which will just make that a cast anyways). Not sure what you're saying here. Without the cast, there is an implicit conversion of size from int to double. A cast is an explicit conversion, but a conversion is not a cast. > I could have used a double as the parameter, but why? > It needs a whole number Yes, but why? > (which generally isn't going to need to be 64-bits, > let alone 32) You seem to have a keen eye for irrelevancies. ;-) Why focus on its precise width? And did you mean '32-bits, let alone 64'? > - int is perfect for that. But size_t is better. Since it's necessarily big enough to store the size of the whole array, it must be big enough to store the number of elements. Neither of those guarantees hold for int. I have used 8MB implementations where int was still only 16-bit. I dare say there are some embedded environments where this is still the case. You could argue that size_t may have performance issues because it is often wider than int. But I've yet to encounter an implementation where the performance actually warranted a smaller/faster type. True, on some systems wider types can be fractionally slower, but you're not likely to encounter an implementation where size_t is particularly slow. Only on 8-bit micros have I encountered data registers that are smaller than address registers. On such systems, decent compilers will often utilise address registers for wide integer types (even int) precisely because of their speed. -- Peter
