passing array to function

**whiteflags** · 01-09-2014

I think you're deliberately ignoring my point here.

Is it not part of the contract when you use C arrays that you have to keep track of their size?

Well, the article's examples should probably be rewritten to loops doing stuff with the array. That makes more sense, but doesn't change the dangers of not knowing the array bounds.

You say this to me, but I can say that all the code dealing with them in the article can't do anything about the rule which causes C arrays to degrade to a pointer to the first element. If you want to work with C arrays, it is part of the contract that you know their size. You object to some of the easy to use answers on very silly grounds.

Sticking to the example I picked out. It says,

(to actually call the proper function to pass along the size; this may be a problem in larger projects where some programmer does not know of this function).

So basically you have to know about the function to call it, but you can say this about any part of any program ever coded.

You even espouse the approach passing arrays as references before we ever hear that maybe C arrays aren't the right type. The problem is that this approach causes massive overloading based on type.

The array type, and its behavior in a majority of contexts, means that you should be writing functions that accept arrays of various sizes. It doesn't help to ruin a perfectly good function with nonsense like assert(size == 10); That's not going to work the second that the array is intentionally different. And a majority of the examples are contrived because of this reason; the article itself doesn't acknowledge how arrays are actually used in programs.

This article could be shortened considerably it admitted that C arrays were the wrong type in some places.

**phantomotap** · 01-09-2014

However, your range-like function has its downsides: it pushes the checking of valid ranges to the caller, which causes more bugs.

O_o

Really? The same argument for a fourth/fifth time? You've learned nothing?

*sigh*

I think I'll just hope someone else posts the links...

Soma

**Elysia** · 01-10-2014

Originally Posted by phantomotap

O_o

Really? The same argument for a fourth/fifth time? You've learned nothing?

*sigh*

I think I'll just hope someone else posts the links...

Soma

Hehehe.
I gave it some thought last night and came to the conclusion that it's probably the same as just passing a pointer to the first element of the array and the size of the array you want to process.
The only "downside" I could find was that you could augment the interface to take a pointer to the first element, the beginning offset, the end offset and the size and the function can make sure the combination is sane, whereas with just two arguments, the function cannot.
Still, it is the programmer's responsibility to maintain the size, but it matters whether the caller or callee makes appropriate checks since the later often leads to less bugs in my experience.

**Elysia** · 01-10-2014

Originally Posted by whiteflags

You even espouse the approach passing arrays as references before we ever hear that maybe C arrays aren't the right type. The problem is that this approach causes massive overloading based on type.

You're right. That should probably be mentioned.

The array type, and its behavior in a majority of contexts, means that you should be writing functions that accept arrays of various sizes. It doesn't help to ruin a perfectly good function with nonsense like assert(size == 10); That's not going to work the second that the array is intentionally different. And a majority of the examples are contrived because of this reason; the article itself doesn't acknowledge how arrays are actually used in programs.

This article could be shortened considerably it admitted that C arrays were the wrong type in some places.

So we do agree that the examples should be rewritten to accept variably sized arrays. And yet, a lot of functions do take arrays of known size. I think that, at the very least, this should be mentioned because I see a lot of programs that do it that way and the fact that the compiler completely ignores the size in the declaration is very dangerous...

The article also focuses on approaching as many different approaches to passing arrays as possible and discussing advantages and disadvantages because you are likely to see all these somewhere (the ones missing are probably legacy interfaces and iterator interfaces). That said, while the article isn't perfect, at least I think it does some things to raise awareness, which is better than nothing. Also, as lazy as I am, changes are probably slow, so if you aren't lazy, then feel free to change the article a little bit to fit your vision better. It is, after all, the advantage of an open wiki.

**whiteflags** · 01-10-2014

The only "downside" I could find was that you could augment the interface to take a pointer to the first element, the beginning offset, the end offset and the size and the function can make sure the combination is sane, whereas with just two arguments, the function cannot.

The one thing a function that accepts a range expressed in pointers can do is process the whole range. In so doing, there will be checks like first < last, which will fail if, say, first and last in the argument list are swapped, or the beginning was offset too far. It's very hard to mess up and crash in ways that other functions cannot.

**Elysia** · 01-10-2014

It's hard to mess up the function, but it's easy to mess up the parameters that you send to the function.
It is not so easy to enforce that last ∈ R(array), given some array "array".
Which is kind of the downside of pointers. Once you are in the territory of pointers, it's very easy to crash programs in my experience. All it takes is one wrong pointer. It works all great and well if your program is running as intended, but as as soon as some error occurs in the program, chances are it might crash due to a bad pointer. C++ (and C) is scary stuff.

**whiteflags** · 01-10-2014

All it takes is one bad iterator too, though. So when I said it's hard to mess up in ways other functions cannot, I admitted what you just told me, and you in effect added nothing new.

**Elysia** · 01-10-2014

Yeah, I just commented on how scary iterators and pointers are and in effect, how scary that makes C and C++, because I felt to

**MutantJohn** · 01-11-2014

I don't know what you guys are scared of, my pointer arithmetic is perfect. Always. Except for when I screw up.

**Elysia** · 01-11-2014

Originally Posted by MutantJohn

Except for when I screw up.

And then the program crashes and burns.

**phantomotap** · 01-11-2014

And then the program crashes and burns.

O_o

Potentially true for every mistake; why are you treating points/iterators with such fear?

Seriously, why are you programming in C/C++? Every post of yours that proselytizes C++ references features largely available to other languages. (For example, Python has scoped destruction and generics through decorators/"monkey patching" sufficient for most of your work.) Every post of yours complaining about C++ is referencing problems largely solved in other languages. (You may look no further than C#, with which you'd be partly familiar, to find many do not exist.) Every time you insist a newbie write code to babysit clients you are telling them to do things other languages (Ada/Java/PHP/Python/Ruby) do automatically.

I know I've asked before, but I strongly recommend you branch out from C/C++ as it really doesn't seem a good fit for you.

Soma

**smokeyangel** · 01-11-2014

I suppose having an array as an argument with an explicit length might help readability.

In general I pretty much hate arrays. I understand that they're easier to introduce to beginners than pointers or STL, but it usually takes the average beginner a very short time to say "hold on, why are arrays the only things that are passed by reference in my trivial program? Why can't I assign one array to another? Why is it behaving differently in this function to a function a passed it to? My array isn't big enough, how do I make it bigger? C is soooo hard." Then "I've figured it out! It's just a pointer, right?".

There are many scary bits of C, but I think arrays irk me because they come up so soon in textbooks and courses, before most people have anywhere near the knowledge to make sense of them. Stupid arrays. Bad arrays!

**whiteflags** · 01-11-2014

There are many scary bits of C, but I think arrays irk me because they come up so soon in textbooks and courses, before most people have anywhere near the knowledge to make sense of them. Stupid arrays. Bad arrays!

That's only true if C is also teaching you how to program which is mistake number one. My university track didn't touch C++ until after I'd studied higher level languages like VB.

Even if you just want to look at C teaching material by itself, there are a few beliefs I have about said material: you aren't going to please everyone, the best resources say what they will explain to readers and who the readers should be, and staying away from data structures is somewhat sadistic. I feel like at a certain point, there is only so much you can say before you talk about arrays and other structures. Arrays also happen to be the simplest structure, so it seems like a logical start.

**smokeyangel** · 01-11-2014

Totally agree there -- I did struggle with C for a while (a few months I guess) before having to learn VB for school. People may mock VB but it certainly lets you get stuff done, and teaches you to think logically -- when I came back to C and other languages I found it a lot easier.

I've never tried to teach anyone C, so I'm probably talking nonsense - but I would have said structs would be a better aggregate to start with. Simply because they behave much less 'mysteriously'. But then.... all of C (and all languages I guess) are things that you have to learn, then learn again, then learn the bits you didn't get the first time. There's probably no right order to do it in. I just feel pain for beginners perplexed by arrays.

**phantomotap** · 01-12-2014

[Edit]
As whiteflags says, a lot of opinions exists on teaching C and teaching programming with C; I'm only expressing my opinion from my experience teaching and not intending to claim a fact.
[/Edit]

O_o

Well, this is going to be one of those controversial things, but I'd recommend teaching pointers--as in pointers to single objects--before touching arrays.

Yes. As said, arrays are pretty much the simplest data structure, but you don't have to jump to linked lists--as is so common--just to introduce the need for, reason behind, and use of pointers.

Code:

void Add(int * sum, int augend, int addend);
// ...
int main()
{
    int sum;
    Add(&sum, 1, 1);
}

If you can get a new student past the indirection hump, the treatment of arrays as decaying to pointers is a far easier concept to understand.

The mechanics of indirection is best served exactly after the introduction of "user defined functions" (I am assuming that some "standard functions"--specifically `printf'--are taught before introducing "user defined functions".) and just before `scanf'.

Soma