Finding the size wasn't the issueOriginally Posted by dwks
Passing it as an extra argument was!
Finding the size wasn't the issue
Passing it as an extra argument was!
You can, but the only issue I have against using code written like that is that invariably someone else will use my code and do something wrong with macro and pass in a pointer or something.
Example:
Some things don't always work as you would like...Code:void MyFunction(float vec[36]) { // now what happens if you use vectorsum_array() here? }
I think one thing that makes the whole argument entirely invalid is the fact that most API's are what they are. And there is no way around passing in array sizes. So welcome to the way of the programming world, Pharao.
Yeah, you're right. The issue was having to pass the number of elements in the array to the function. So why are we suggesting vectors? [edit] Or comtemplating suggesting them or whatever. [/edit] I think my suggestion's just as valid.Finding the size wasn't the issue
Passing it as an extra argument was!
But anyway, I don't think I'd ever use it myself, for the reason master5001 outlined.
Or the C programming world, as Elysia would say.So welcome to the way of the programming world, Pharao.
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
You are right, C++ arrays are the same business, but at least you have vectors to fall back on. That and other standard template library features that address issues with other complicated areas of C programming. Even programs I write in Delphi use the same APIs as the ones I write in C/C++. My assembler programs that use dynamic memory have to deal with passing size as a parameter.. Its just a programming issue in general.
There are two distinct ways of knowing the length of an array [or string, list, or whatever]: Either you keep a count the number of items, or you mark the end. Both are equally valid, and each have their own good and bad points.
And of course, C is also able to encapsulate data - you just can't as easily access the encapsulated data using member functions.
For example, we can easily make a variable length float array:
--Code:struct floatarray { size_t len; float *data; }; vectorsum(floatarray* array) { int i=0; float sum=0; for(i=0;i<array->len;i++) sum+=array->data[i]; return sum; } int main() { floatarray array; const int n = 100; int i; array.data = malloc(sizeof(float) * n); array.len = n; for(i = 0; i < n; i++) array.data[i] = 1.0 / (i+1); printf("sum = %5.2f\n", vectorsum(&array)); return 0; }
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
After what mats just posted, I am not sure what else to add to this thread!
Or the even more fun way to program these sorts of things:
Example:
But that can get kind of annoying to have to incorporate. Its mostly similar to the initial thing I suggested.Code:/* The type is more for logical understanding of what is going on that anything. */ struct array_t { size_t length; char data[]; }; void *array_alloc(size_t size) { struct array_t *obj; if(!size) return 0; size += sizeof(struct array_t); obj = malloc(size); return (obj)?obj + 1:0; } void array_free(void *ptr) { struct array_t *obj = ptr; if(obj) free(obj - 1); } size_t array_size(void *ptr) { struct array_t *obj = ptr; if(obj) return (obj-1)->length; return 0; }
Because regardless of how you turn it, you still have to pass the size in either hard-coded form or some sort of compile time expression or macro. With vectors, you don't
^_^Or the C programming world, as Elysia would say.
At least until C dies (that's a big if, though) or APIs stop being C compatible...
A lot of functional languages use container objects (like vectors or something like the examples posted by matsp and myself) to handle their own arrays. Somewhere the data must be stored. The C way of thinking about it, however, is that its the programmers problem to maintain that information. Not the environments. PASCAL/Delphi seem to handle arrays so much better than C. At least bounds checks are thoroughly respected. But I hate that language family so I won't even attempt to sound like I am backing it up.
