Writing Efficient Arguments

[ThreeRight]

depends on what your using it for isnt it? for referance, you cant "redefine" a referance while you can make a pointer to point to something else. so, it depends on the program and if you want to change whatever that pointer is pointing to something else.

 

[Default User]

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]

(e-mail address removed) wrote:
::: (e-mail address removed) 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]

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]

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.

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

 

[gpuchtel]

You *are* wrong.

agreed.

 

[Michael DOUBEZ]

gpuchtel a écrit :

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]

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 :

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]

[email protected]:

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]

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/wg21/docs/cwg_active.html#232

I believe the issue is still under discussion.

V

 

[Michael DOUBEZ]

Andre Kostur a écrit :

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]

gpuchtel a écrit :

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]

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]

Please see issue 232 on Committee core language issue list.

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.

 

[persenaama]

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...- Hide quoted text -

Why not look at the generated code? Look from your compiler's
documentation how to enable assembly output if it is supported.

g++ uses -S,
Microsoft compilers often use /Fa,
etc..

 

[persenaama]

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 :

gpuchtel a écrit :

On Jul 9, 7:03 pm, (e-mail address removed) 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.

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

I mean syntaxically valid but UB.

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