references as parameters

[neelagain]

Hi,

This question _must_ have been asked before but I don't seem to find a
exact question(answer) right now.

I wanted to know what is the down side of passing parameters as
reference for data type >= 4 bytes.

For example:

funcRef(const int & i) or funcRef(const UINT & u)

How exactly is this worse than:

funcRef(const int i) or funcRef(const UINT u)

From what I know variables are created in each case, and each of four
bytes. But, type checking is better in first version than next
version. Am I correct?

Thanks,
Neel.

 

[Ian Collins]

Hi,

This question _must_ have been asked before but I don't seem to find a
exact question(answer) right now.

It was asked today!

See the thread "Copy vs. const reference function argument".

I wanted to know what is the down side of passing parameters as
reference for data type >= 4 bytes.

For example:

funcRef(const int & i) or funcRef(const UINT & u)

How exactly is this worse than:

funcRef(const int i) or funcRef(const UINT u)

From what I know variables are created in each case, and each of four
bytes. But, type checking is better in first version than next
version. Am I correct?

No. How would the type checking be different?

 

[neelagain]

It was asked today!

See the thread "Copy vs. const reference function argument".







No.  How would the type checking be different?

Hi Ian,

Thanks! Does this mean in most of the cases both cases will be same?

About type checking, I found that with non-const references, it does
happen. Please see the code below:

#define SOME_INT -10

void funcRef(unsigned int & i) {
unsigned int x = i;
}

void funcVal(unsigned int i){
unsigned int x = i;
}


int _tmain(int argc, _TCHAR* argv[])
{

funcRef(static_cast<unsigned int>(SOME_INT)); //unless you make
parameter const & this will fail..
funcVal(SOME_INT);

int val = 10;
funcRef(static_cast<unsigned int>(val)); //unless you make
parameter const & this will fail..
funcVal(val);

return 0;
}

Thanks,
Neel.

 

[Ian Collins]

On Mar 26, 12:25 pm, Ian Colli

Hi Ian,

Thanks! Does this mean in most of the cases both cases will be same?

About type checking, I found that with non-const references, it does
happen. Please see the code below:

#define SOME_INT -10

void funcRef(unsigned int & i) {
unsigned int x = i;
}

void funcVal(unsigned int i){
unsigned int x = i;
}


int _tmain(int argc, _TCHAR* argv[])

What's that nonsense? I assume you intended to type

int main(int argc, char* argv[])

?

{
funcRef(static_cast<unsigned int>(SOME_INT));

With funcVal, the value will be automatically converted to unsigned.
You might get a warning for this. There isn't an automatic conversion
between int and unsigned&.

 

[dave_mikesell]

Hi,

This question _must_ have been asked before but I don't seem to find a
exact question(answer) right now.

I wanted to know what is the down side of passing parameters as
reference for data type >= 4 bytes.

For example:

funcRef(const int & i) or funcRef(const UINT & u)

How exactly is this worse than:

funcRef(const int i) or funcRef(const UINT u)

What does "const" buy you here?

The real problem is all of the premature optimization in the air
lately.

 

[neelagain]

What does "const" buy you here?

That's what I wanted to know Apparently nothing!

The real problem is all of the premature optimization in the air
lately.

Yes, that's what I was expecting to get - optimization I don't
think there is anything wrong with that though. But, I wanted to know
that in context of data type of less than or equal to 4 bytes. I had
read in one of books/articles (don't remember which) that values can
be directly replaced instead of creating an object.

In the preceding example, that means if compiler finds out that this
value is not changed anywhere it can directly replace parameter "const
unsigned & i" with SOME_INT. In case of value, that may not be
possible because now user is specifically asking for new object.

With user defined types, this may not be possible but built in types
it may be possible. Although problem is, even though compiler may do
that, I do not have a way to find out what are the conditions in which
it can be done or not.

Thanks,
Neel.

 

[Fred Zwarts]

That's what I wanted to know Apparently nothing!

It has a meaning within the function body. In principle it is not needed in a prototype declaration.
Some compilers, however, require the prototype and the full function definition to be
consistent in the use of "const". That's why I use "const" in such prototype declarations.

 

[dave_mikesell]

It has a meaning within the function body. In principle it is not needed in a prototype declaration.
Some compilers, however, require the prototype and the full function definition to be
consistent in the use of "const". That's why I use "const" in such prototype declarations.

I have functions that accept const references and pointers so that the
caller doesn't have its referent or pointee modified, but const is
superfluous when passing by value:

void do_something(int i) // no const
{
i = 99;
}

int k = 0;
do_something(k);
// k is still 0 here

 

[Matthias Buelow]

I wanted to know what is the down side of passing parameters as
reference for data type >= 4 bytes.

For example:

funcRef(const int & i) or funcRef(const UINT & u)

How exactly is this worse than:

funcRef(const int i) or funcRef(const UINT u)

From what I know variables are created in each case, and each of four
bytes. But, type checking is better in first version than next
version. Am I correct?

Passing a value and passing a reference to a variable containing a value
are two different things:

A reference implements call-by-name while otherwise it is call-by-value.
In the case of passing a reference this means that, in the callee, if
you assign to the variable, you change the value of the variable the
reference points to. A reference is equivalent to a pointer but makes
the pointer "transparent" to the programmer, basically, it's just
syntactic sugar.

Maybe running the following program illustrates it a bit better:

------------------------------------------------------------

#include <iostream>

void f_value(int i)
{
i = 1;
}

void f_ref(int &i)
{
i = 2;
}

void f_ptr(int *i)
{
*i = 3;
}

int main()
{
int i = 0;
f_value(i);
std::cout << i << '\n';
f_ref(i);
std::cout << i << '\n';
f_ptr(&i);
std::cout << i << '\n';
return 0;
}

------------------------------------------------------------

 

[Matthias Buelow]

In the preceding example, that means if compiler finds out that this
value is not changed anywhere it can directly replace parameter "const
unsigned & i" with SOME_INT.

No, imho even a const reference must pass the reference because in the
called function you could convert it to a pointer and cast away the
const-ness thus allowing assignment. Perhaps this is undefined
behaviour, I'm not a language lawyer but it certainly can be done. Maybe
some Standard freak can look it up.

 

[James Kanze]

No, imho even a const reference must pass the reference
because in the called function you could convert it to a
pointer and cast away the const-ness thus allowing assignment.
Perhaps this is undefined behaviour, I'm not a language lawyer
but it certainly can be done. Maybe some Standard freak can
look it up.

It depends on whether the original object was const or not.

The real issue is that reference arguments have different
semantics. Consider something like the following:

int global = 1 ;

void
f( int const& i )
{
std::cout << i << std::endl ;
++ global ;
std::cout << i << std::endl ;
}

If f was called with global as an argument, then i had better
change value when global is incremented.