Writing Efficient Arguments

[spekyuman]

Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from the
stack and heap to the physical linking and build of the program.

[Default User]

sp*******@gmail.com wrote:

Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from the
stack and heap to the physical linking and build of the program.

No way to tell. It's all platform-specific. If the implementation uses
pointers behind the scenes, there's likely little difference.

If it's important, profile. If not, then use the construct that most
clearly represents the intent of the program.

Brian

[red floyd]

sp*******@gmail.com wrote:

Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from the
stack and heap to the physical linking and build of the program.

I propose that we ban the word "efficient" from newsgroup posts unless
the poster has benchmarked and shown that the micro-optimization he
wants actually may do something.

[gpuchtel]

On Jul 9, 7:03 pm, [e-mail] wrote:

Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from the
stack and heap to the physical linking and build of the program.

>From memory standpoint there is no difference. Assuming the address of

the reference and pointer are coming from the same location, I don't
believe there are additional instructions to set up the stack;
however, as soon as I say that, someone will cite some implementation
where it does.

The 'efficiency' is in the recipient. That is, it does not have to
check if a reference is null - since a reference can never be null.
Finally, I suspect if you declare a pointer parameter as 'void*', you
lose type-checking efficiency, or incur type-checking inefficiency
depending on your point-of-view.

[spekyuman]

On Jul 9, 7:22 pm, red floyd <[e-mail]:

[e-mail] wrote:

Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from the
stack and heap to the physical linking and build of the program.

I propose that we ban the word "efficient" from newsgroup posts unless
the poster has benchmarked and shown that the micro-optimization he
wants actually may do something.

Alright, these methods perform the same exact tasks. In each case,
what will the cost in overhead be? Both implementations refer to an
object indirectly, which allows each method to make internal
modifications. Assume the object is referring to intelligence
photography or uncompressed video. Compare this with the an
inefficient implementation, what background details can you construct?

// SIZEOF(pObject) =4 bytes
// SIZEOF(pObject) =500 * 2^20 bytes
void function(myObject* pObject)
{
...
}

// SIZEOF(refObject) =500 * 2^20 bytes
void function(myObject& refObject)
{
...
}

// Inefficient Implementation
myObject function(myObject copy)
{
...
return copy;
}

[spekyuman]

On Jul 9, 7:11 pm, "Default User" <[e-mail]:

[e-mail] wrote:

Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from the
stack and heap to the physical linking and build of the program.

No way to tell. It's all platform-specific. If the implementation uses
pointers behind the scenes, there's likely little difference.

If it's important, profile. If not, then use the construct that most
clearly represents the intent of the program.

Brian

Are you suggesting this is compiler specific?

[spekyuman]

On Jul 9, 8:06 pm, gpuchtel <[e-mail]:

On Jul 9, 7:03 pm, [e-mail] wrote:

Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from the
stack and heap to the physical linking and build of the program.
From memory standpoint there is no difference. Assuming the address of

the reference and pointer are coming from the same location, I don't
believe there are additional instructions to set up the stack;
however, as soon as I say that, someone will cite some implementation
where it does.

The 'efficiency' is in the recipient. That is, it does not have to
check if a reference is null - since a reference can never be null.
Finally, I suspect if you declare a pointer parameter as 'void*', you
lose type-checking efficiency, or incur type-checking inefficiency
depending on your point-of-view.

Alright, these methods perform the same exact tasks. In each case,
what will the cost in overhead be? Both implementations refer to an
object indirectly, which allows each method to make internal
modifications. Assume the object is referring to intelligence
photography or uncompressed video. Compare this with the an
inefficient implementation, what background details can you construct?

// SIZEOF(pObject) =4 bytes
// SIZEOF(pObject) =500 * 2^20 bytes
void function(myObject* pObject)
{
...
}

// SIZEOF(refObject) =500 * 2^20 bytes
void function(myObject& refObject)
{
...
}

// Inefficient Implementation
myObject function(myObject copy)
{
...
return copy;
}

[bnonaj]

sp*******@gmail.com wrote:

Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from the
stack and heap to the physical linking and build of the program.

Passing by reference automatically assumes only one object, whereas a
pointer may be to part of an array.
void someFnc1(MyObj &inp)
{
inp.doSomething();
inp[1].doSomething(); // This is plain wrong
}

void someFnc2(MyObj *inp)
{
inp->doSomething();
inp[1].doSomething(); // This is valid but maybe wrong and could
cause hard to debug problems
}

As for efficiency, I doubt with modern optimising compilers you would
find one more efficient than the other.

JB

[James Kanze]

On Jul 10, 1:22 am, red floyd <[e-mail]:

[e-mail] wrote:

Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from the
stack and heap to the physical linking and build of the program.

I propose that we ban the word "efficient" from newsgroup posts unless
the poster has benchmarked and shown that the micro-optimization he
wants actually may do something.

I totally disagree. Programmer efficiency is very important,
and should only be compromized when absolutely essential. (Most
of the time, of course, we're really concerned with long term
programmer efficiency. We'll invest some additional effort up
front to make the inevitable maintenance easier.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Michael DOUBEZ]

gpuchtel a écrit :

On Jul 9, 7:03 pm, [e-mail] wrote:

>Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from the
stack and heap to the physical linking and build of the program.

[snip]

The 'efficiency' is in the recipient. That is, it does not have to
check if a reference is null - since a reference can never be null.

A reference can be NULL or invalid all the same. The difference is that
the code indicates a NULL wouldn't be expected (i.e. the code is self
explaining; whereas with pointer, you would have to read the doc/comments).

AFAIK the following code is valid (though UB):

void print(int& i)
{
cout<<&i<<endl;
}

int main()
{
print(*static_cast<int*>(0));

return 0;
}

And prints '0'.

Michael

[gpuchtel]

On Jul 10, 6:41 am, Michael DOUBEZ <[e-mail]:

>
AFAIK the following code is valid (though UB):

void print(int& i)
{
cout<<&i<<endl;

}

int main()
{
print(*static_cast<int*>(0));

return 0;

}

And prints '0'.

Michael

A reference cannot be 'null'. What you did created a tempory int
variable that was initialized to 0 (zero), then a reference to that
temporary variable was passed to the print function, which in turn
printed '0'.

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-07-10 05:22, sp*******@gmail.com wrote:

On Jul 9, 8:06 pm, gpuchtel <[e-mail]:

>On Jul 9, 7:03 pm, [e-mail] wrote:

Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from the
stack and heap to the physical linking and build of the program.
From memory standpoint there is no difference. Assuming the address of

the reference and pointer are coming from the same location, I don't
believe there are additional instructions to set up the stack;
however, as soon as I say that, someone will cite some implementation
where it does.

The 'efficiency' is in the recipient. That is, it does not have to
check if a reference is null - since a reference can never be null.
Finally, I suspect if you declare a pointer parameter as 'void*', you
lose type-checking efficiency, or incur type-checking inefficiency
depending on your point-of-view.

Alright, these methods perform the same exact tasks. In each case,
what will the cost in overhead be? Both implementations refer to an
object indirectly, which allows each method to make internal
modifications. Assume the object is referring to intelligence
photography or uncompressed video. Compare this with the an
inefficient implementation, what background details can you construct?

// SIZEOF(pObject) =4 bytes

I assume you meant SIZEOF(myObject*)

// SIZEOF(pObject) =500 * 2^20 bytes

SIZEOF(myObject), by the way, what's wrong with sizeof()?

void function(myObject* pObject)
{
...
}

// SIZEOF(refObject) =500 * 2^20 bytes
void function(myObject& refObject)
{
...
}

If myObject is that large it probably means that function() won't be
called to often, so whatever the overhead of the call is, it will be
insignificant to the total running time of the program, you should focus
your energy on trying to optimise the algorithm that works on the data
instead.

I know this might not be the answer you want, but as others have pointed
out there is no one true answer since it depends on a lot of things,
such as how the compiler implements references, what other optimizations
can be made (inlining etc.) and so on.

Write your program with as clear code as possible, then run it with some
representative test data, if it is to slow then profile it and improve
on the slowest parts (and I can guarantee you, unless you have a very
strange design, it will not be the call overhead). Doing anything else
will just waste your time.

--
Erik Wikström

[Michael DOUBEZ]

gpuchtel a écrit :

On Jul 10, 6:41 am, Michael DOUBEZ <[e-mail]:

>AFAIK the following code is valid (though UB):

void print(int& i)
{
cout<<&i<<endl;

}

int main()
{
print(*static_cast<int*>(0));

return 0;

}

And prints '0'.

>
A reference cannot be 'null'. What you did created a tempory int
variable that was initialized to 0 (zero), then a reference to that
temporary variable was passed to the print function, which in turn
printed '0'.

Where did you get that from ? Even if I wanted it, I couldn't pass a
temporary because the ref is not const.

It is perhaps more understandable if you replace by:
int *ptr=NULL;
print(*ptr)

and add in print
++i; //cause segfault;

Michael

[spekyuman]

On Jul 10, 7:11 am, Erik Wikström <[e-mail]:

On 2007-07-10 05:22, [e-mail] wrote:

On Jul 9, 8:06 pm, gpuchtel <[e-mail]:

On Jul 9, 7:03 pm, [e-mail] wrote:

Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from the
stack and heap to the physical linking and build of the program.
From memory standpoint there is no difference. Assuming the address of

the reference and pointer are coming from the same location, I don't
believe there are additional instructions to set up the stack;
however, as soon as I say that, someone will cite some implementation
where it does.

The 'efficiency' is in the recipient. That is, it does not have to
check if a reference is null - since a reference can never be null.
Finally, I suspect if you declare a pointer parameter as 'void*', you
lose type-checking efficiency, or incur type-checking inefficiency
depending on your point-of-view.

Alright, these methods perform the same exact tasks. In each case,
what will the cost in overhead be? Both implementations refer to an
object indirectly, which allows each method to make internal
modifications. Assume the object is referring to intelligence
photography or uncompressed video. Compare this with the an
inefficient implementation, what background details can you construct?

// SIZEOF(pObject) =4 bytes

I assume you meant SIZEOF(myObject*)

// SIZEOF(pObject) =500 * 2^20 bytes

SIZEOF(myObject), by the way, what's wrong with sizeof()?

void function(myObject* pObject)
{
...
}

// SIZEOF(refObject) =500 * 2^20 bytes
void function(myObject& refObject)
{
...
}

If myObject is that large it probably means that function() won't be
called to often, so whatever the overhead of the call is, it will be
insignificant to the total running time of the program, you should focus
your energy on trying to optimise the algorithm that works on the data
instead.

I know this might not be the answer you want, but as others have pointed
out there is no one true answer since it depends on a lot of things,
such as how the compiler implements references, what other optimizations
can be made (inlining etc.) and so on.

Write your program with as clear code as possible, then run it with some
representative test data, if it is to slow then profile it and improve
on the slowest parts (and I can guarantee you, unless you have a very
strange design, it will not be the call overhead). Doing anything else
will just waste your time.

--
Erik Wikström- Hide quoted text -

- Show quoted text -

In research and development, writing code correctly the first time is
the objective my friend. Prematurely optimizing code and handling data
correctly are two completely different things. Ignorance in favor of
production, is the difference between an easily replacable gear and
computer scientist.

[Victor Bazarov]

sp*******@gmail.com wrote:

On Jul 9, 7:22 pm, red floyd <[e-mail]:

>[e-mail] wrote:

>>Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from
the stack and heap to the physical linking and build of the program.

I propose that we ban the word "efficient" from newsgroup posts
unless the poster has benchmarked and shown that the
micro-optimization he wants actually may do something.

Alright, these methods perform the same exact tasks. In each case,
what will the cost in overhead be?

The third method requires making _at least one_ copy. The overhead
of actually *calling* the third method will be the time of making the
copy of a 'myObject' object. What that is depends on the implementation
(of both the compiler and the 'myObject' class).

Both implementations refer to an
object indirectly, which allows each method to make internal
modifications. Assume the object is referring to intelligence
photography or uncompressed video.

Why does it matter what the object is "referring to"?

Compare this with the an
inefficient implementation, what background details can you construct?

What do you mean by "background details"?

>
// SIZEOF(pObject) =4 bytes
// SIZEOF(pObject) =500 * 2^20 bytes
void function(myObject* pObject)
{
...
}

// SIZEOF(refObject) =500 * 2^20 bytes
void function(myObject& refObject)
{
...
}

// Inefficient Implementation
myObject function(myObject copy)
{
...
return copy;
}

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[spekyuman]

On Jul 10, 8:40 am, "Victor Bazarov" <[e-mail]:

[e-mail] wrote:

On Jul 9, 7:22 pm, red floyd <[e-mail]:

[e-mail] wrote:
Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from
the stack and heap to the physical linking and build of the program.

I propose that we ban the word "efficient" from newsgroup posts
unless the poster has benchmarked and shown that the
micro-optimization he wants actually may do something.

Alright, these methods perform the same exact tasks. In each case,
what will the cost in overhead be?

The third method requires making _at least one_ copy. The overhead
of actually *calling* the third method will be the time of making the
copy of a 'myObject' object. What that is depends on the implementation
(of both the compiler and the 'myObject' class).

Both implementations refer to an
object indirectly, which allows each method to make internal
modifications. Assume the object is referring to intelligence
photography or uncompressed video.

Why does it matter what the object is "referring to"?

Compare this with the an
inefficient implementation, what background details can you construct?

What do you mean by "background details"?

// SIZEOF(pObject) =4 bytes
// SIZEOF(pObject) =500 * 2^20 bytes
void function(myObject* pObject)
{
...
}

// SIZEOF(refObject) =500 * 2^20 bytes
void function(myObject& refObject)
{
...
}

// Inefficient Implementation
myObject function(myObject copy)
{
...
return copy;
}

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Background Details =What processes are occurring during a function
call? How are pointers and references treated during this time? What
exactly happens to their memory and what they reference during this
particular time? You know, the good stuff...

[spekyuman]

On Jul 10, 8:40 am, "Victor Bazarov" <[e-mail]:

[e-mail] wrote:

On Jul 9, 7:22 pm, red floyd <[e-mail]:

[e-mail] wrote:
Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from
the stack and heap to the physical linking and build of the program.

I propose that we ban the word "efficient" from newsgroup posts
unless the poster has benchmarked and shown that the
micro-optimization he wants actually may do something.

Alright, these methods perform the same exact tasks. In each case,
what will the cost in overhead be?

The third method requires making _at least one_ copy. The overhead
of actually *calling* the third method will be the time of making the
copy of a 'myObject' object. What that is depends on the implementation
(of both the compiler and the 'myObject' class).

Both implementations refer to an
object indirectly, which allows each method to make internal
modifications. Assume the object is referring to intelligence
photography or uncompressed video.

Why does it matter what the object is "referring to"?

Compare this with the an
inefficient implementation, what background details can you construct?

What do you mean by "background details"?

// SIZEOF(pObject) =4 bytes
// SIZEOF(pObject) =500 * 2^20 bytes
void function(myObject* pObject)
{
...
}

// SIZEOF(refObject) =500 * 2^20 bytes
void function(myObject& refObject)
{
...
}

// Inefficient Implementation
myObject function(myObject copy)
{
...
return copy;
}

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Haha, I must complement your question Victor Bazarov. I included what
the object was referring to for people without imaginations. ;-)

[gpuchtel]

On Jul 10, 8:13 am, Michael DOUBEZ <[e-mail]:

gpuchtel a écrit :

On Jul 10, 6:41 am, Michael DOUBEZ <[e-mail]:

AFAIK the following code is valid (though UB):

void print(int& i)
{
cout<<&i<<endl;

}

int main()
{
print(*static_cast<int*>(0));

return 0;

}

And prints '0'.

A reference cannot be 'null'. What you did created a tempory int
variable that was initialized to 0 (zero), then a reference to that
temporary variable was passed to the print function, which in turn
printed '0'.

Where did you get that from ? Even if I wanted it, I couldn't pass a
temporary because the ref is not const.

It is perhaps more understandable if you replace by:
int *ptr=NULL;
print(*ptr)

and add in print
++i; //cause segfault;

Michael- Hide quoted text -

- Show quoted text -

I didn't say (or mean) 'you' would pass a temporary, I was implying
what the compiler will do (pass). Simply stated, there is no such
thing as a 'null' reference. All your example does is to create a
reference to a (tempory) int value that contains the value of zero.
Your example of a null pointer is not relevant to the discussion of
the (im)possibility of having a 'null' reference.

[Thomas J. Gritzan]

gpuchtel wrote:

On Jul 10, 8:13 am, Michael DOUBEZ <[e-mail]:

>Where did you get that from ? Even if I wanted it, I couldn't pass a
temporary because the ref is not const.

It is perhaps more understandable if you replace by:
int *ptr=NULL;
print(*ptr)

and add in print
++i; //cause segfault;

Michael- Hide quoted text -

- Show quoted text -

I didn't say (or mean) 'you' would pass a temporary, I was implying
what the compiler will do (pass). Simply stated, there is no such
thing as a 'null' reference. All your example does is to create a
reference to a (tempory) int value that contains the value of zero.
Your example of a null pointer is not relevant to the discussion of
the (im)possibility of having a 'null' reference.

You are wrong. The expression
static_cast<int*>(0)
or whatever you saw in Michael's code does not create a temporary integer.

It casts a null pointer constant into the type int*. He (Michael)
dereferenced the null pointer, passing it to a int reference.

The point is, you can have a 'null' reference, but you can't have one
without invoking undefined behaviour.

--
Thomas
http://www.netmeister.org/news/learn2quote.html

[Victor Bazarov]

gpuchtel wrote:

On Jul 10, 8:13 am, Michael DOUBEZ <[e-mail]:

>gpuchtel a écrit :

>>On Jul 10, 6:41 am, Michael DOUBEZ <[e-mail]:

>>>AFAIK the following code is valid (though UB):

>>>void print(int& i)
{
cout<<&i<<endl;

>>>}

>>>int main()
{
print(*static_cast<int*>(0));

>>> return 0;

>>>}

>>>And prints '0'.

>>A reference cannot be 'null'. What you did created a tempory int
variable that was initialized to 0 (zero), then a reference to that
temporary variable was passed to the print function, which in turn
printed '0'.

Where did you get that from ? Even if I wanted it, I couldn't pass a
temporary because the ref is not const.

It is perhaps more understandable if you replace by:
int *ptr=NULL;
print(*ptr)

and add in print
++i; //cause segfault;

Michael- Hide quoted text -

- Show quoted text -

I didn't say (or mean) 'you' would pass a temporary, I was implying
what the compiler will do (pass). Simply stated, there is no such
thing as a 'null' reference. All your example does is to create a
reference to a (tempory) int value that contains the value of zero.

No temporary of type 'int' exists (or created) in the expression

static_cast<int*>(0)

The compiler should see the _integer_literal_ 0 and the static_cast
to a pointer type, and should create a *null pointer value* (of type
'int*', a pointer to int). It's all done in compile time.

Your example of a null pointer is not relevant to the discussion of
the (im)possibility of having a 'null' reference.

Why isn't it? As shown, the example is essentially the same as

...
int *p = 0;
print(*p); // no static cast needed
...

IIRC, most recent proposed corrections to the Standard actually allow
creation of a "null reference" provided that the contents of the
referred object are never evaluated (no lvalue-to-rvalue conversion
is performed). Taking address of that reference (using the operator
& on it) should yield a null pointer.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Default User]

sp*******@gmail.com wrote:

On Jul 9, 7:11 pm, "Default User" <[e-mail]:

[e-mail] wrote:

Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing
arguments via pointer or reference? Avoid the stereotypical urge
of debating effective coding style. Instead, think of particular
scenarios: passing a 512MB object to function. Think behind the
scenes, from the stack and heap to the physical linking and build
of the program.

No way to tell. It's all platform-specific. If the implementation
uses pointers behind the scenes, there's likely little difference.

If it's important, profile. If not, then use the construct that most
clearly represents the intent of the program.

Are you suggesting this is compiler specific?

I'm not suggesting that. I'm stating that. Of course it is, how could
it be anything else? The Standard specifies no performance
characteristics for either.


Brian

[Bo Persson]

sp*******@gmail.com wrote:
:: On Jul 9, 7:22 pm, red floyd <[e-mail]:
::: [e-mail] wrote:
:::: Pointer and reference arguments provide C++ programmers with the
:::: ability to modify objects. What is more efficient, passing
:::: arguments via pointer or reference? Avoid the stereotypical urge
:::: of debating effective coding style. Instead, think of particular
:::: scenarios: passing a 512MB object to function. Think behind the
:::: scenes, from the stack and heap to the physical linking and
:::: build of the program.
:::
::: I propose that we ban the word "efficient" from newsgroup posts
::: unless the poster has benchmarked and shown that the
::: micro-optimization he wants actually may do something.
::
:: Alright, these methods perform the same exact tasks. In each case,
:: what will the cost in overhead be? Both implementations refer to an
:: object indirectly, which allows each method to make internal
:: modifications. Assume the object is referring to intelligence
:: photography or uncompressed video. Compare this with the an
:: inefficient implementation, what background details can you
:: construct?
::
:: // SIZEOF(pObject) =4 bytes
:: // SIZEOF(pObject) =500 * 2^20 bytes
:: void function(myObject* pObject)
:: {
:: ...
:: }
::
:: // SIZEOF(refObject) =500 * 2^20 bytes
:: void function(myObject& refObject)

I think you have a problem here - sizeof(refObject) returns the size
of the object, not of the reference. A reference is just an alias for
an object. Anything you do to the reference actually happens to the
object it refers to.
:: {
:: ...
:: }
::
:: // Inefficient Implementation
:: myObject function(myObject copy)
:: {
:: ...
:: return copy;
:: }

This might be very efficient, if you need to return a modified object
without affecting the original.
Bo Persson

[gpuchtel]

On Jul 10, 11:24 am, "Thomas J. Gritzan" <[e-mail]>
wrote:

>
You are wrong. The expression
static_cast<int*>(0)
or whatever you saw in Michael's code does not create a temporary integer.

The syntax you quoted is neither the original syntax nor the context
in which I wrote my response. The original syntax and context was:

print(*static_cast<int*>(0));

not:

static_cast<int*>(0)

I may be wrong (I have been wrong before; however I'm still
verifying), but what I am saying is that in the construction of the
call to 'print', a temporary variable of type 'int' is created and a
reference to it passed to 'print', which must be valid because the OP
indicated it printed '0'. IOW, the zero is the value of the temporary
int variable, not the value of the reference.

Let me repeat least I am not clear, I am digging through my reference
from which I am basing my opion, which as I said could be wrong.
Anyway, the syntax being quoted by others is not in the context of
which I was responding.

[Victor Bazarov]

gpuchtel wrote:

On Jul 10, 11:24 am, "Thomas J. Gritzan" <[e-mail]>
wrote:

>>
You are wrong. The expression
static_cast<int*>(0)
or whatever you saw in Michael's code does not create a temporary
integer.

The syntax you quoted is neither the original syntax nor the context
in which I wrote my response. The original syntax and context was:

print(*static_cast<int*>(0));

not:

static_cast<int*>(0)

I may be wrong (I have been wrong before; however I'm still
verifying), but what I am saying is that in the construction of the
call to 'print', a temporary variable of type 'int' is created

You *are* wrong. No temporary is created since 'print' expects
a reference. Only reference binding occurs here (the argument of
'print' is bound to the l-value resulting from dereferencing the
pointer obtained from the static_cast).

and a
reference to it passed to 'print', which must be valid because the OP
indicated it printed '0'.

Of course it printed 0! The "OP" printed the *address* of the object
referred to by the argument. Please make an effort here and re-read
the posts in the thread.

IOW, the zero is the value of the temporary
int variable, not the value of the reference.

<sigh>

>
Let me repeat least I am not clear, I am digging through my reference
from which I am basing my opion, which as I said could be wrong.
Anyway, the syntax being quoted by others is not in the context of
which I was responding.

What context *is* it then? Your own invented context?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[gpuchtel]

On Jul 10, 1:25 pm, "Victor Bazarov" <[e-mail]:

>
You *are* wrong.

agreed.

[Michael DOUBEZ]

gpuchtel a écrit :

On Jul 10, 8:13 am, Michael DOUBEZ <[e-mail]:

>gpuchtel a écrit :

>>On Jul 10, 6:41 am, Michael DOUBEZ <[e-mail]:
AFAIK the following code is valid (though UB):
void print(int& i)
{
cout<<&i<<endl;
}
int main()
{
print(*static_cast<int*>(0));
return 0;
}
And prints '0'.
A reference cannot be 'null'. What you did created a tempory int
variable that was initialized to 0 (zero), then a reference to that
temporary variable was passed to the print function, which in turn
printed '0'.

Where did you get that from ? Even if I wanted it, I couldn't pass a
temporary because the ref is not const.

It is perhaps more understandable if you replace by:
int *ptr=NULL;
print(*ptr)

and add in print
++i; //cause segfault;

Michael- Hide quoted text -

- Show quoted text -

I didn't say (or mean) 'you' would pass a temporary, I was implying
what the compiler will do (pass). Simply stated, there is no such
thing as a 'null' reference. All your example does is to create a
reference to a (tempory) int value that contains the value of zero.
Your example of a null pointer is not relevant to the discussion of
the (im)possibility of having a 'null' reference.

I don't understand what you mean and I don't see where is your temporary
or why the compiler will create one.

"*static_cast<int*>(0)" is deferencing an int value at address NULL
(assuming NULL is int promoted to 0). The value is passed into the
function which expect a reference.

If the compiler created a temporary it wouldn't be a reference; it would
be a bug in the compiler because it would not modify my value.

My understanding of a 'null' reference is a reference which reference is
null. As in the following

void print(int& i)
{
assert(&i != NULL ) ; // will trigger in my example

//...
}
The code I originally posted is directly equivalent to:

void print(int* i)
{
cout<<i<<endl;
}
int main()
{
print(static_cast<int*>(0));
return 0;
}
My point is that 'null' reference do exists the same way null pointer
exists.

Michael

[gpuchtel]

On Jul 11, 4:04 am, Michael DOUBEZ <[e-mail]:

>
I don't understand what you mean and I don't see where is your temporary
or why the compiler will create one.

Michael, I already admitted I was wrong in a previous post. I am still
flipping through pages to find the snippet of code that caused me to
come to my original (wrong) conclusion, to which I admit now for the
second time.

[Michael DOUBEZ]

gpuchtel a écrit :

On Jul 11, 4:04 am, Michael DOUBEZ <[e-mail]:

>I don't understand what you mean and I don't see where is your temporary
or why the compiler will create one.

Michael, I already admitted I was wrong in a previous post. I am still
flipping through pages to find the snippet of code that caused me to
come to my original (wrong) conclusion, to which I admit now for the
second time.

Yes. My news reader had scrambled the thread and I hadn't seen it before
answering.
Sorry for the garbage.

Michael

[Andre Kostur]

Michael DOUBEZ <mi************@free.frwrote in news:46948d64$0$3691
$4*******@news.free.fr:

My point is that 'null' reference do exists the same way null pointer
exists.

Not in a well-formed C++ program which doesn't invoke Undefined Behaviour.
NULL pointers can exist, "NULL" references cannot.

[Victor Bazarov]

Andre Kostur wrote:

Michael DOUBEZ <mi************@free.frwrote in news:46948d64$0$3691
$4*******@news.free.fr:

>My point is that 'null' reference do exists the same way null pointer
exists.

Not in a well-formed C++ program which doesn't invoke Undefined
Behaviour. NULL pointers can exist, "NULL" references cannot.

Please see issue 232 on Committee core language issue list.

http://www.open-std.org/jtc1/sc22/wg...ctive.html#232

I believe the issue is still under discussion.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Michael DOUBEZ]

Andre Kostur a écrit :

Michael DOUBEZ <mi************@free.frwrote in news:46948d64$0$3691
$4*******@news.free.fr:

>My point is that 'null' reference do exists the same way null pointer
exists.

Not in a well-formed C++ program which doesn't invoke Undefined Behaviour.
NULL pointers can exist, "NULL" references cannot.

Putting appart issue 232 of WG21. My point is deferencing a NULL pointer
that is expected to be not NULL is also UB.

If you read the whole thread, the reason I mentionned it is that
reference gives a false sense of security ("reference cannot be NULL").
I don't propose to assert value of reference in code, I only want to
mention that it can happen and it is likely a bug.

For the sake of completeness, reference are also subject to dangling
pointer (commonly by returning the reference to a local object) which is
equally UB.

Michael

[James Kanze]

On Jul 10, 12:41 pm, Michael DOUBEZ <[e-mail]:

gpuchtel a écrit :

On Jul 9, 7:03 pm, [e-mail] wrote:

Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from the
stack and heap to the physical linking and build of the program.

[snip]
The 'efficiency' is in the recipient. That is, it does not have to
check if a reference is null - since a reference can never be null.

A reference can be NULL or invalid all the same.

Only if the code contains undefined behavior, and even then, who
knows. Generally speaking, there is no way to get a null
reference without incurring undefined behavior, and once you've
incurred undefined behavior, there are no guarantees concerning
what you get.

The difference is that the code indicates a NULL wouldn't be
expected (i.e. the code is self explaining; whereas with
pointer, you would have to read the doc/comments).

AFAIK the following code is valid (though UB):

So which is it? Valid, or undefined behavior? It can't be
both.

void print(int& i)
{
cout<<&i<<endl;
}

int main()
{
print(*static_cast<int*>(0));
return 0;
}

And prints '0'.

Maybe. On some implementation. Some days of the month. I've
definitly used an implementation where it would core dump.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 10, 5:16 pm, gpuchtel <[e-mail]:

On Jul 10, 8:13 am, Michael DOUBEZ <[e-mail]:

gpuchtel a écrit :

On Jul 10, 6:41 am, Michael DOUBEZ <[e-mail]:
>AFAIK the following code is valid (though UB):

>void print(int& i)
>{
> cout<<&i<<endl;
>}

>int main()
>{
> print(*static_cast<int*>(0));
> return 0;
>}

>And prints '0'.

A reference cannot be 'null'. What you did created a tempory int
variable that was initialized to 0 (zero), then a reference to that
temporary variable was passed to the print function, which in turn
printed '0'.

Where did you get that from ? Even if I wanted it, I couldn't pass a
temporary because the ref is not const.

It is perhaps more understandable if you replace by:
int *ptr=NULL;
print(*ptr)

and add in print
++i; //cause segfault;

I didn't say (or mean) 'you' would pass a temporary, I was implying
what the compiler will do (pass).

What the compiler will do is undefined. His code has undefined
behavior, so the compiler can do anything it wants. I've used
compilers that behave as he describes, but I've also used
compilers which will core dump in his initial code.

Simply stated, there is no such
thing as a 'null' reference. All your example does is to create a
reference to a (tempory) int value that contains the value of zero.

That would also be fine. It's undefined behavior, and the
compiler can do whatever it wants. I'm not aware of a compiler
which does as you describe, but it wouldn't surprise me too
much.

Your example of a null pointer is not relevant to the discussion of
the (im)possibility of having a 'null' reference.

Programs with undefined behavior aren't relevent to any
discussion of how C++ behaves.:-)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 11, 4:12 pm, "Victor Bazarov" <[e-mail]:

Andre Kostur wrote:

Michael DOUBEZ <[e-mail] in news:46948d64$0$3691
$[e-mail]:

My point is that 'null' reference do exists the same way null pointer
exists.

Not in a well-formed C++ program which doesn't invoke Undefined
Behaviour. NULL pointers can exist, "NULL" references cannot.

Please see issue 232 on Committee core language issue list.

http://www.open-std.org/jtc1/sc22/wg...ctive.html#232

I believe the issue is still under discussion.

Certain issues are under discussion, but I don't think that
anyone is proposing a change to the rule that a reference must
bind to a valid object.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[persenaama]

On Jul 10, 7:40 pm, "Bo Persson" <[e-mail]:

I think you have a problem here - sizeof(refObject) returns the size
of the object, not of the reference. A reference is just an alias for
an object. Anything you do to the reference actually happens to the
object it refers to.

It doesn't return size of the object. It returns size of the type
object. There is a slight difference; here's demonstration:

// begin listing
#include <iostream>

class foo
{
int i;
virtual int value() const { return 1; }
};

class bar : public foo
{
int j;
virtual int value() const { return 2; }
};

void test(foo& f)
{
std::cout << sizeof(f) << std::endl;
}

int main()
{
foo f;
bar b;

test(f);
test(b);
}
// end listing

[Michael DOUBEZ]

James Kanze a écrit :

On Jul 10, 12:41 pm, Michael DOUBEZ <[e-mail]:

>gpuchtel a écrit :

>>On Jul 9, 7:03 pm, [e-mail] wrote:
Pointer and reference arguments provide C++ programmers with the
ability to modify objects. What is more efficient, passing arguments
via pointer or reference? Avoid the stereotypical urge of debating
effective coding style. Instead, think of particular scenarios:
passing a 512MB object to function. Think behind the scenes, from the
stack and heap to the physical linking and build of the program.
[snip]
The 'efficiency' is in the recipient. That is, it does not have to
check if a reference is null - since a reference can never be null.

>A reference can be NULL or invalid all the same.

Only if the code contains undefined behavior, and even then, who
knows. Generally speaking, there is no way to get a null
reference without incurring undefined behavior, and once you've
incurred undefined behavior, there are no guarantees concerning
what you get.

True. I see the point. The wording would be: in a well formed program,
no reference can be null. But in practice, you can get UB (a bug)
through the form of null-reference.

The UB stays for deferencing a NULL pointer but the UB is prior to the
function call in the case of null-reference bug.

>The difference is that the code indicates a NULL wouldn't be
expected (i.e. the code is self explaining; whereas with
pointer, you would have to read the doc/comments).

>AFAIK the following code is valid (though UB):

So which is it? Valid, or undefined behavior? It can't be
both.

I mean syntaxically valid but UB.

>void print(int& i)
{
cout<<&i<<endl;
}

>int main()
{
print(*static_cast<int*>(0));
return 0;
}

>And prints '0'.

Maybe. On some implementation. Some days of the month. I've
definitly used an implementation where it would core dump.

Agreed. I am still waiting for the dragons-out-of-the-nose flavor :)

Michael