determining the size of an array when passed by ref

Is there a reason why I get the correct result when I use this approach within the function that I instantiated my class as an array but when I do the same thing in a function where I pass the array class (byref) I get 1?

Code:

---

sizeof array / sizeof array[0]

---

The suggestion was made that I should have used the "vector" class as an alternative approach to create my class array instead of using native arrays. As this would provide some built-in features for the array, such as storing the size and allowing dynamic sizing, while also providing some safety, such as range-checking.

When an array is passed to a function, it is converted to a pointer. The called function only ever receives a pointer. A pointer is not associated with any information related to the size of what it points at.

sizeof(array) will therefore be the sizeof(pointer), not the size of the array passed.

When you pass the array by ref then actually you are passing a pointer.That's why this i is a good approach.If you pass the whole object then the copy constructor will be invoked,and a big(maybe) object has to be copied and passed as an argument and then be destroyed!

However i think that it would be helpful to post your code,in order to exactly see what you are doing.Or just wait for a user that is very good to answer(there are many here)

EDIT->one already did ;)

you can pass an array by reference with templates:

Code:

---

template<int N>
void SomeFunction(char (&c)[N]);

---

then sizeof(c) will actually be the length of the array in bytes, but in this situation, you then can use N instead of sizeof(c) / sizeof(char).

Quote:

---

Originally Posted by std10093

When you pass the array by ref then actually you are passing a pointer.That's why this i is a good approach.If you pass the whole object then the copy constructor will be invoked,and a big(maybe) object has to be copied and passed as an argument and then be destroyed!

---

No, that is not correct.
There are two ways to pass arrays: by address (or pointer, if you will; which is presumably what the OP did since sizeof won't work then), and by reference (which Elkvis covered).

It boggles my mind that people find this so hard.

Compute the size before the call.

Code:

---

void foo( type array[], size_t nelem );

foo( array, sizeof(array) / sizeof(array[0]) );

---

Or just stop poisoning function call parameter lists with unnecessary parameters that the compiler can deduce itself (and lessen the amount of mistakes and errors).

Quote:

---

Originally Posted by mdehnel

The suggestion was made that I should have used the "vector" class as an alternative approach to create my class array instead of using native arrays. As this would provide some built-in features for the array, such as storing the size and allowing dynamic sizing, while also providing some safety, such as range-checking.

---

If you specifically want a fixed size array, then consider using std::array instead of std::vector.

Quote:

---

Originally Posted by Elysia

Or just stop poisoning function call parameter lists with unnecessary parameters that the compiler can deduce itself (and lessen the amount of mistakes and errors).

---

If you are talking with respect to whiteflags' post #6, then I note that the size parameter is not necessarily unnecessary since there may not be a guarantee that the argument will be a fixed size array.

Quote:

---

Originally Posted by laserlight

since there may not be a guarantee that the argument will be a fixed size array.

---

in that case you'd have an overloaded function to handle it.

Quote:

---

Originally Posted by laserlight

If you are talking with respect to whiteflags' post #6, then I note that the size parameter is not necessarily unnecessary since there may not be a guarantee that the argument will be a fixed size array.

---

Yes, there are cases where it might be necessary, but I really want to get across the message: Don't use a size parameter unless absolutely necessary.
If it looks like you need one, seriously consider your design. Can you use a container (eg std::vector) instead?

Quote:

---

If it looks like you need one, seriously consider your design. Can you use a container (eg std::vector) instead?

---

I actually agree, by the way. I've just never thought of a valid reason to pass an array by reference. It's easy to say it prevents errors, but I'd prefer like two or three other ideas that just work better because of convention, IMO. It's just not worth knowing.

Quote:

---

in that case you'd have an overloaded function to handle it.

---

If you start with the interface you posted, you would have to duplicate functionality (implementation); you couldn't just call that function from an overloaded interface.

You need to start with a robust general interface; you can add convenience wrappers at your leisure.

Quote:

---

Or just stop poisoning function call parameter lists with unnecessary parameters that the compiler can deduce itself (and lessen the amount of mistakes and errors).

---

The parameter is obviously necessary; you've moved the information about in one way or the other, but the information is still a requirement.

Quote:

---

Don't use a size parameter unless absolutely necessary.

---

The code you forward (as Elkvis posted) does not eliminate the size parameter; it moves the size parameter into a template.

That's useful for a convenience function, but it doesn't improve the implementation.

Soma

http://cboard.cprogramming.com/cplus...ml#post1116592

I suspect the OP's interpretation of "pass by reference" was passing a pointer, not the trickery shown by Elkvis (neat as it is, when used right).

Quote:

---

Originally Posted by phantomotap

The code you forward (as Elkvis posted) does not eliminate the size parameter; it moves the size parameter into a template.

That's useful for a convenience function, but it doesn't improve the implementation.

---

Indeed.

It is also a function that will not work in this example.

Code:

---

template<int N>  void SomeFunction(char (&c)[N])    // Elkvis's function
{
    // something with elements of c, cognisant of the value of N
}

void intermediary(char a[])
{
    SomeFunction(a);    //  This will not compile, fortunately
}

int main()
{
    char x[2];

    SomeFunction(x);    //  will call Elkvis's template function correctly

    intermediary(x);      //  attempt to call Elkvis's template function
}

---

Fortunately, a C++ compiler will reward you with a compilation error in the body of intermediary() - unless the SomeFunction() template has been specialised for a char pointer. This is because the argument a inside intermediary() is actually a pointer, lacking size information. Which brings us back to the OP's original problem ....

Quote:

---

Originally Posted by phantomotap

The parameter is obviously necessary; you've moved the information about in one way or the other, but the information is still a requirement.

---

Oh sure. I don't think anyone disagrees with that. The disagreement is more of how to pass along that information (ie via the compiler implicitly deducing it, some standard library keeping track of it or passing it explicitly).

Quote:

---

Originally Posted by grumpy

It is also a function that will not work in this example.

---

But this may be a good thing.
There are some valid differences about pointers vs arrays (such as sizeof), which may be critical for safe code.
Imagine someone having a function taking an explicit size, then passing an array with sizeof to that function. So far, so good, right?
Then imagine someone suddenly changing the array to a pointer and forgetting to change the sizeof. Boom! A bug right there, and you won't realize it until runtime.
But if you have a strongly typed function that only accepts arrays, you will get a compile error and can fix it before it becomes a bug.

Quote:

---

Originally Posted by Elysia

But this may be a good thing.
There are some valid differences about pointers vs arrays (such as sizeof), which may be critical for safe code.
Imagine someone having a function taking an explicit size, then passing an array with sizeof to that function. So far, so good, right?
Then imagine someone suddenly changing the array to a pointer and forgetting to change the sizeof. Boom! A bug right there, and you won't realize it until runtime.
But if you have a strongly typed function that only accepts arrays, you will get a compile error and can fix it before it becomes a bug.

---

Sure. I agree with you on that. My post wasn't a criticism of your technique. It's just that I've seen a few too many people make the unjustified leap to believing that your technique can be used to obtain a size of an array from a pointer. The compiler complains, which it should, they ask why, and the discussion becomes circular.