reference to array?

[Gernot Frisch]

Hope you know what I mean...


void Work(int& r[4])
{
r[0]=0;
}

int main(int, char**)
{
int a[4]
Work(a);
}

--
-Gernot
int main(int argc, char** argv) {printf
("%silto%c%cf%cgl%ssic%ccom%c", "ma", 58, 'g', 64, "ba", 46, 10);}

________________________________________
Looking for a good game? Do it yourself!
GLBasic - you can do
www.GLBasic.com

 

[John Harrison]

Hope you know what I mean...


void Work(int& r[4])

void Work(int (&r)[4])

Reference to array, not array of references (which is not allowed).

john

 

[Ron Natalie]

Hope you know what I mean...


void Work(int& r[4])

You've declared a four element array of references
rather than a refernce to array of 4 ints (which would
be int (&r)[4].

However, you don't even need that. C++ inherits the
braindamaged array passing behavior from C. A silent
conversion of the function type to pointer-to-first element
occurs.

Your code will work the way you expect if you define the
function as:
void Work(int r[4]) {

Arrays are not passed by value as would be consistant with every other
type in the language. The array r is the same as the one in the caller
here.

 

[JKop]

Gernot Frisch posted:

Hope you know what I mean...


void Work(int& r[4])
{
r[0]=0;
}

int main(int, char**)
{
int a[4]
Work(a);
}

Here's some functions that'll alter an array of 4 elements:

void Monkey(int* const p_blah) throw()
{
p_blah[0] = 67;
p_blah[1] = -54;
p_blah[2] = 76;
p_blah[3] = 47;
}

void Ape(int blah[4]) throw() //Looks like it's passing by value...
{
blah[0] = 67;
blah[1] = -54;
blah[2] = 76;
blah[3] = 47;
}


void Cow(int (&blah)[4]) throw()
{
blah[0] = 67;
blah[1] = -54;
blah[2] = 76;
blah[3] = 47;
}


-JKop

 

[Gernot Frisch]

Your code will work the way you expect if you define the

function as:
void Work(int r[4]) {

How can I happen to be so silly to have forgotten that... Thank you
very much.

 

[DaKoadMunky]

Your code will work the way you expect if you define the

function as:
void Work(int r[4]) {

But that would allow passing the address of any int to the function be it a
single element or an array of any size.

Maybe the function is hardcoded to work with arrays of a specific size.

It seems the reference syntax would prevent this kind of usage...

void func(int (&r)[3])
{
}

int main()
{
int *x;
func(x); //Sorry

int y[2];
func(y); //Nope

return 0;
}

Do you see any value in the "reference to array" syntax?

I have never needed it, but am curious to peoples opinions.

 

[Cy Edmunds]

Gernot Frisch posted:

Hope you know what I mean...


void Work(int& r[4])
{
r[0]=0;
}

int main(int, char**)
{
int a[4]
Work(a);
}

Here's some functions that'll alter an array of 4 elements:

void Monkey(int* const p_blah) throw()
{
p_blah[0] = 67;
p_blah[1] = -54;
p_blah[2] = 76;
p_blah[3] = 47;
}

I think const is a little misleading here. The function gets a copy of the
pointer anyway so the caller wouldn't care if the function changed its
value. Also, I see you have discovered throw specifications. Unfortunately
they don't do what you might think (for instance prevent the function from
throwing) and I think most experienced programmers avoid them.

[snip]

 

[JKop]

void Monkey(int* const p_blah) throw()
{
p_blah[0] = 67;
p_blah[1] = -54;
p_blah[2] = 76;
p_blah[3] = 47; }

I think const is a little misleading here.

I disagree. It's crystal clear to me that "p_blah" is a local object of type
"int*" and that it's const. Sure, it's not needed, but I use "const"
wherever possible and it allows for more obvious optimization.

The function gets a copy of
the pointer anyway so the caller wouldn't care if the function changed
its value.
Agreed.

Also, I see you have discovered throw specifications.
Indeed.

Unfortunately they don't do what you might think (for instance prevent
the function from throwing) and I think most experienced programmers
avoid them.

I know exactly how it works. If this particular function threw an exception,
then the function "std::unexpected" would be called.

The reason I stick it in is that I *know* that my function won't ever throw
an exception, and as with "const", I'll use it wherever possible.

I wouldn't though for instance do the following:

void blah()
{
string k("salj");
}


Because I don't know the insides of that type and it may very well throw an
exception I'm unaware of.


-JKop


-JKop

 

[JKop]

void blah()
{
string k("salj");
}

Should've been:


void blah() throw()
{

string k("salj");
}


-JKop

 

[Richard Herring]

void blah()
{
string k("salj");
}

Should've been:


void blah() throw()
{

string k("salj");
}
[/QUOTE]

Shouldn't.

What do you think happens if the string constructor can't allocate
enough memory?

 

[JKop]

Richard Herring posted:

void blah()
{
string k("salj"); }

Should've been:


void blah() throw()
{

string k("salj"); }

Shouldn't.

What do you think happens if the string constructor can't allocate
enough memory?[/QUOTE]


Asshole, please read both my posts, then and only then return with your
usual asshole remarks.


-JKop

 

[Richard Herring]

Shouldn't.

What do you think happens if the string constructor can't allocate
enough memory?

Asshole, please read both my posts,[/QUOTE]

Life's too short.

If you can't take the trouble to say what you mean the first time round,
you need to make sure your corrections contain enough context to make
your point clear. Otherwise, expect people reading posts in isolation
to take them at face value.

then and only then return with your
usual asshole remarks.

If you don't like them, there are obvious solutions.

 

[Cy Edmunds]

Should've been:


void blah() throw()
{

string k("salj");
}


-JKop

Tell it to Herb:

http://www.gotw.ca/publications/mill22.htm

 

[-JKop]

Cy Edmunds posted:

http://www.gotw.ca/publications/mill22.htm

Interesting! Thanks.


-JKop