question about sorting function arguments

[pulzu]

For my assignment the professor gave an example of a sorting function as:

 void static mysort(int (&x)[ASIZE] );

I'm confused as to what int (&x)[ASIZE] would mean as arguments. ASIZE is suppose to be the max size of our array that we pass into to be sorted. The function is a member of a class that has all the functions with the same name (overloading?). He also implied we can add more arguments to the function as needed.

[whiteflags]

ASIZE is not just the max size, it is THE size of the array that needs to be passed in. You should find with some experimenting that other sizes result in compiler errors. It's one reason why I don't like this technique...

The overloads are likely just variations on the type of array.

Basically the only way to call it successfully is to declare an array of ASIZE length and pass in that array:

int array[ASIZE] = { 1,2,3,6,5,4 };
sort(array);

[algorism]

It's declaring x as a reference to an int array of size ASIZE.
I can discern no advantage, however, since ASIZE is a constant.
The usual way to do it (in C) is like this:

void mysort(int x[], int size); // or size_t size

In C++ a std::vector or std::array is preferred.

[laserlight]

It is the way for you to have the array itself passed by reference, and in so doing avoid the conversion of the array into a pointer to its first element. Observe:

#include <iostream>

#define ASIZE 10

static void mysort(int (&x)[ASIZE]);

int main()
{
    int a[ASIZE];
    mysort(a);

    int b[ASIZE + 1];
    mysort(b);
}

static void mysort(int (&x)[ASIZE])
{
    std::cout << sizeof(int*) << " versus " << sizeof(x) << std::endl;
}

You will see that while mysort(a) is fine since you can pass an array of ASIZE int elements by reference to a parameter that is a reference to an array of ASIZE int elements, mysort(b) results in a compile error since an array of ASIZE + 1 int elements does not match in type. Now, remove the mysort(b) call, compile and run the program. You will most likely observe that sizeof(x) is not equal to sizeof(int*), whereas if mysort were:

static void mysort(int x[ASIZE]);

It would be equal since x would be a pointer to int.

[pulzu]

Thanks for your reply, helped a lot. And everyone else as well!

[Elysia]

I can discern no advantage, however, since ASIZE is a constant.

I can. It allows you to enforce, at compile time, that the array is of exactly ASIZE elements. Any less and any more will result in a compile error.

The usual way to do it (in C) is like this:

void mysort(int x[], int size); // or size_t size

If you do it this way, you put the responsibility on the caller to pass the correct size. If the size is incorrect, bad things™ will happen. If you use good guidelines and code review, chances that you will pass the incorrect size will be diminished, but there's no guarantee that you pass the correct size. The above guarantees that it's exactly ASIZE elements. All. the. time. Unless there's a compiler bug.

In C++ a std::vector or std::array is preferred.

This is still good advice, though, and would be the preferred approach.

[Guest]

Is there logic to this syntax (as with function pointers), that follows from the general rules of variable declaration, or is it just one of those cases where some solution was needed? It doesn't seem very intuitive.

// these would seem less weird
void mysort(int x[100]&);
void mysort(int[100]& x);

[algorism]

Is there logic to this syntax (as with function pointers), that follows from the general rules of variable declaration, or is it just one of those cases where some solution was needed? It doesn't seem very intuitive.

// these would seem less weird
void mysort(int x[100]&);
void mysort(int[100]& x);

The logic is identical to that of function pointers. The array indexing operator has higher precedence (same as the function application operator), so the parentheses are needed around the (&x) part. Your second example syntax would be better but since C++ is meant to be as compatible as possible with C, the syntax can't be cleaned up.

Does anyone see any advantages of this reference-to-C-array approach? It has the disadvantage of requiring a fixed-sized array. I don't see any advantages.

[Elysia]

Does anyone see any advantages of this reference-to-C-array approach? It has the disadvantage of requiring a fixed-sized array. I don't see any advantages.

I mentioned some advantages in post #6.
If you want to accept arrays of any size, you can make the size a template parameter, which is way superior to the C approach.

[whiteflags]

If you do it this way, you put the responsibility on the caller to pass the correct size. If the size is incorrect, bad things™ will happen. If you use good guidelines and code review, chances that you will pass the incorrect size will be diminished, but there's no guarantee that you pass the correct size. The above guarantees that it's exactly ASIZE elements. All. the. time. Unless there's a compiler bug.

This can be more unhelpful than the debugging it tries to prevent.

Because what would be nice is just passing in an array and getting the size correct no matter what. But with passing arrays by reference if the chosen constant is too big or too small, you have the same problem. It might be right for some arrays and wrong for others.

I find you have to write code around passing arrays by reference in order to get it to work correctly. I find that very stupid.

[King Mir]

This can be more unhelpful than the debugging it tries to prevent.

Because what would be nice is just passing in an array and getting the size correct no matter what. But with passing arrays by reference if the chosen constant is too big or too small, you have the same problem. It might be right for some arrays and wrong for others.

I find you have to write code around passing arrays by reference in order to get it to work correctly. I find that very stupid.

It may not be useful for an algorithm like sort, because you're better off with a more generic sort algorithm. But if you only ever need to use a particular size array, then this technique works fine, although it's still inferior to using std::array. For example, you might have a game board that is a fixed size array. Usually this would be a 2d array, but the principles are the same either way. In this case you could use this technique to pass around game boards, which would fail to compile if you ever pass it a game board with the wrong dimensions.

There is a third option that is often preferable however: passing in a class that contains the array in question. This is more type safe, because it incorporates the semantic meaning, such as that of being a game board, in the type.


In this example of demonstration sorting the technique is fine, IMO, since it allows the beginner-programmer implementer to ignore the complexities of variable size arrays, and focus on sorting. It is of course, an academic example.

[algorism]

I mentioned some advantages in post #6.
If you want to accept arrays of any size, you can make the size a template parameter, which is way superior to the C approach.

I'm sorry. I don't know how I missed your previous post.

So the advantage is compile-time checking that the fixed-sized C-style array is correctly sized, and that the user of the function doesn't need to pass in the size. It's not necessarily superior to the C code since they are solving different problems, with the C version being variable-sized, but clearly that's not what is being asked for here. Still, this is C++ so, as you say, a C++ solution is better, presumably involving array or vector.

[Elysia]

They don't solve the same problem, no, but if you make the size a template arguments, it becomes a superior way of doing it. There's no way to get the size wrong.

[MutantJohn]

What if we just implemented this in terms of an instantiation of the iterator_traits class instead?

[rcgldr]

The parameter could be a reference to a row in a matrix, although it would need a cast to be used this way.

#define NROW 2
#define NCOL 3

void foo(int (&x)[NCOL])
{
    ((int (*)[NCOL])x)[1][2] = 1;
}

int main()
{
static int m[NROW][NCOL];
    foo(m[0]);
    return 0;
}