Returning an array?

[Steven T. Hatton]

I believe it is technically possible to return a pointer to the first
element of an array. I can persuade the returned pointer to act like an
array, with some qualifications. I'm specifically interested in
multidimensiona l arrays.

It is often said that arrays and pointers are virtually identical. My
observations are that my (gcc) compiler knows the difference between T*, T
a1[9], and a2[3][3].

What I'm currently trying to do is to return a pointer (or reference) to an
array which was passed in as a container for the results of matrix
calculations taking two other matrices as arguments. It's the same concept
as using ostream& print(&ostream out, const objType& obj){ out << obj.data;
return out; }. I don't absolutely /need/ the functionality, but it would
be more intuitive to work with in some instances.

AFAIK, there is no way to specify an array return type. Whereas I can
specify 'ostream&', I cannot specify 'T[][dimensions]' as a return type. I
can use 'T*' as the return type and cast the returned array to T*. But
then it's not the same type as was passed in. Not to mention that it is
rather tricky playing with arrays at that level.

There are various reasons I would rather not use the stl containers. I can
create my own containers. AAMOF, that's what I'm doing. I don't need nor
even want iterators. Is wrapping the array in some kind of class type
object the only viable approach to passing arrays around?
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

[Victor Bazarov]

Steven T. Hatton wrote:

I believe it is technically possible to return a pointer to the first
element of an array.
Yes, it is possible.
I can persuade the returned pointer to act like an
array, with some qualifications. I'm specifically interested in
multidimensiona l arrays.

It is often said that arrays and pointers are virtually identical. My
observations are that my (gcc) compiler knows the difference between T*, T
a1[9], and a2[3][3].
They are not the same type, if that's what you're alluding to.

What I'm currently trying to do is to return a pointer (or reference) to an
array which was passed in as a container for the results of matrix
calculations taking two other matrices as arguments. It's the same concept
as using ostream& print(&ostream out, const objType& obj){ out << obj.data;
return out; }. I don't absolutely /need/ the functionality, but it would
be more intuitive to work with in some instances.
"Intuitive" is not really objective. But if it's intuitive to you,
by all means, do it.
AFAIK, there is no way to specify an array return type. Whereas I can
specify 'ostream&', I cannot specify 'T[][dimensions]' as a return type. I
can use 'T*' as the return type and cast the returned array to T*. But
then it's not the same type as was passed in. Not to mention that it is
rather tricky playing with arrays at that level.

There are various reasons I would rather not use the stl containers. I can
create my own containers. AAMOF, that's what I'm doing. I don't need nor
even want iterators. Is wrapping the array in some kind of class type
object the only viable approach to passing arrays around?

Yes, actually. That's a very common approach. Wrapping it in a struct
is the simplest thing, and has worked for generations of C programmers.

You could, of course, try to work with _references_ to arrays, but the
syntax is really convoluted, to say the least. Although, you coudl get
around it with some typedefs...

typedef double (&dMatrix3x3)[3][3];

dMatrix3x3 mul(dMatrix3x3 m, double d)
{
m[0][0] *= d; m[0][1] *= d; m[0][2] *= d;
m[1][0] *= d; m[1][1] *= d; m[1][2] *= d;
m[2][0] *= d; m[2][1] *= d; m[2][2] *= d;
return m;
}

int main()
{
double m[3][3] = { 1,2,3,4,5,6,7,8 ,9 };
mul(mul(m, 2), 5);

// m should now contain { 10,20,30 ...
}

V

[JKop]

int* Blah()
{
int monkey[12];

return monkey;
}
int main()
{
int* const &poo = Blah();

poo[2] = 3; //UB: The array no longer exists
}

-JKop

[JKop]

You could, of course, try to work with _references_ to arrays, but the
syntax is really convoluted, to say the least.

I disagree. It's simple operator and operand precedence:
int &k[5]; //an array of 5 references to integers

int (&k)[5]; //a reference to an array of 5 integers
-JKop

[Sharad Kala]

"JKop" <NU**@NULL.NULL > wrote in message

int &k[5]; //an array of 5 references to integers

Never knew that array of references are legal! Have you ever tried to
compile this code ?

Sharad

[Sharad Kala]

"JKop" <NU**@NULL.NULL > wrote in message
news:vx******** ***********@new s.indigo.ie...

int (&k)[5]; //a reference to an array of 5 integers

This too is illegal. You need to initialize the reference, i.e. it has to be
bound to something for sure.

Sharad

[JKop]

Sharad Kala posted:

"JKop" <NU**@NULL.NULL > wrote in message

int &k[5]; //an array of 5 references to integers

Never knew that array of references are legal! Have you ever tried to
compile this code ?

Sharad

You're correct, there can't be an array of references.

But... my syntax above *would* define such if it were legal... (ie. I have
the correct operator precedence)
-JKop

[JKop]

Sharad Kala posted:

"JKop" <NU**@NULL.NULL > wrote in message
news:vx******** ***********@new s.indigo.ie...

int (&k)[5]; //a reference to an array of 5 integers

This too is illegal. You need to initialize the reference, i.e. it has
to be bound to something for sure.

Sharad

int main()
{
int poo[5];

int (&blah)[5] = poo;
}
-JKop

[Steven T. Hatton]

Victor Bazarov wrote:

Steven T. Hatton wrote:

It is often said that arrays and pointers are virtually identical. My
observations are that my (gcc) compiler knows the difference between T*,
T a1[9], and a2[3][3].
They are not the same type, if that's what you're alluding to.

Yes, that's pretty much what I had intended. I should have waited until I
got some sleep before sending this. (I actually figured it out before I
went to bed. Nonetheless...) . I had simply been passing the wrong things
to my functions.

float m[3][3] = {{1,2,3},{4,5,6 },{7,8,9}};

// this doesn't work:
void print(unsigned rowSize, float* mat[]){/*...*/}
error: cannot convert `float (*)[3]' to `float**' for argument `2'
to `void print(unsigned int, float**)'

// nor does this:
void print(unsigned rowSize, float** mat){/*...*/}
error: cannot convert `float (*)[3]' to `float**' for argument `2'
to `void print(unsigned int, float**)'

// Now, this lovely bit of hackerie *does* work

void print(unsigned rowSize, float* mat00)
{
float** mat = &mat00;

unsigned size = rowSize * rowSize;
// perhaps size_t would be more correct than unsigned?

cout << "\n---------- matrix mat** -----------\n";
for(unsigned i = 0; i < size; i++)
{
if(i%rowSize == 0 && i != 0){cout<<"\n";}
cout << setw(4) << *(*(mat + i/size ) + i%size) <<" ";
}
cout << "\n";
}

float m[3][3] = {{1,2,3},{4,5,6 },{7,8,9}};
print(3, &m[0][0]);
"Intuitive" is not really objective. But if it's intuitive to you,
by all means, do it.

I believe there are other advantages as well. I have not experimented with
it, but I should be able to chain operations together in a single
expression this way.

create my own containers. AAMOF, that's what I'm doing. I don't need
nor even want iterators. Is wrapping the array in some kind of class type
object the only viable approach to passing arrays around?

Yes, actually. That's a very common approach. Wrapping it in a struct
is the simplest thing, and has worked for generations of C programmers.

You could, of course, try to work with _references_ to arrays, but the
syntax is really convoluted, to say the least. Although, you coudl get
around it with some typedefs...

typedef double (&dMatrix3x3)[3][3];

I believe that's the/an answer I was fishing for. The obvious problem with
pointers, references and arrays is that of discriminating between a pointer
to an array and an array of pointers. Likewise for references.

BTW. I tried to figure out if it was meaningful to create an array of
references to the elements of another array. For example,
float m[3][3];
float& ref_m[3][3]; // somehow make ref_m[i][j] == m[j][i];

I concluded that this could not be done. Am I correct?

--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

[JKop]

// this doesn't work:
void print(unsigned rowSize, float* mat[]){/*...*/}
error: cannot convert `float (*)[3]' to `float**' for argument `2'
to `void print(unsigned int, float**)'

// nor does this:
void print(unsigned rowSize, float** mat){/*...*/}
error: cannot convert `float (*)[3]' to `float**' for argument `2'
to `void print(unsigned int, float**)'

// Now, this lovely bit of hackerie *does* work

void print(unsigned rowSize, float* mat00)

Try

void print(unsigned rowSize, float blah[3]);
-JKop