Writing Efficient Arguments

Discussion in 'C++' started by spekyuman@gmail.com, Jul 10, 2007.

  1. Guest

    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.
     
    , Jul 10, 2007
    #1
    1. Advertising

  2. Default User Guest

    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
     
    Default User, Jul 10, 2007
    #2
    1. Advertising

  3. red floyd Guest

    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.
     
    red floyd, Jul 10, 2007
    #3
  4. gpuchtel Guest

    On Jul 9, 7:03 pm, 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.
     
    gpuchtel, Jul 10, 2007
    #4
  5. Guest

    On Jul 9, 7:22 pm, red floyd <> wrote:
    > 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;
    }
     
    , Jul 10, 2007
    #5
  6. Guest

    On Jul 9, 7:11 pm, "Default User" <> wrote:
    > 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?
     
    , Jul 10, 2007
    #6
  7. Guest

    On Jul 9, 8:06 pm, gpuchtel <> wrote:
    > On Jul 9, 7:03 pm, 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;
    }
     
    , Jul 10, 2007
    #7
  8. bnonaj Guest

    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
     
    bnonaj, Jul 10, 2007
    #8
  9. James Kanze Guest

    On Jul 10, 1:22 am, red floyd <> wrote:
    > 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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jul 10, 2007
    #9
  10. gpuchtel a écrit :
    > On Jul 9, 7:03 pm, 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
     
    Michael DOUBEZ, Jul 10, 2007
    #10
  11. gpuchtel Guest

    On Jul 10, 6:41 am, Michael DOUBEZ <> wrote:

    >
    > 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'.
     
    gpuchtel, Jul 10, 2007
    #11
  12. On 2007-07-10 05:22, wrote:
    > On Jul 9, 8:06 pm, gpuchtel <> wrote:
    >> On Jul 9, 7:03 pm, 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
     
    =?ISO-8859-1?Q?Erik_Wikstr=F6m?=, Jul 10, 2007
    #12
  13. gpuchtel a écrit :
    > On Jul 10, 6:41 am, Michael DOUBEZ <> wrote:
    >
    >> 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
     
    Michael DOUBEZ, Jul 10, 2007
    #13
  14. spekyuman Guest

    On Jul 10, 7:11 am, Erik Wikström <> wrote:
    > On 2007-07-10 05:22, wrote:
    >
    >
    >
    >
    >
    > > On Jul 9, 8:06 pm, gpuchtel <> wrote:
    > >> On Jul 9, 7:03 pm, 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.
     
    spekyuman, Jul 10, 2007
    #14
  15. wrote:
    > On Jul 9, 7:22 pm, red floyd <> wrote:
    >> 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
     
    Victor Bazarov, Jul 10, 2007
    #15
  16. spekyuman Guest

    On Jul 10, 8:40 am, "Victor Bazarov" <> wrote:
    > wrote:
    > > On Jul 9, 7:22 pm, red floyd <> wrote:
    > >> 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, Jul 10, 2007
    #16
  17. spekyuman Guest

    On Jul 10, 8:40 am, "Victor Bazarov" <> wrote:
    > wrote:
    > > On Jul 9, 7:22 pm, red floyd <> wrote:
    > >> 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. ;-)
     
    spekyuman, Jul 10, 2007
    #17
  18. gpuchtel Guest

    On Jul 10, 8:13 am, Michael DOUBEZ <> wrote:
    > gpuchtel a écrit :
    >
    >
    >
    >
    >
    > > On Jul 10, 6:41 am, Michael DOUBEZ <> wrote:

    >
    > >> 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.
     
    gpuchtel, Jul 10, 2007
    #18
  19. gpuchtel wrote:
    > On Jul 10, 8:13 am, Michael DOUBEZ <> wrote:
    >> 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
     
    Thomas J. Gritzan, Jul 10, 2007
    #19
  20. gpuchtel wrote:
    > On Jul 10, 8:13 am, Michael DOUBEZ <> wrote:
    >> gpuchtel a écrit :
    >>
    >>
    >>
    >>
    >>
    >>> On Jul 10, 6:41 am, Michael DOUBEZ <> wrote:

    >>
    >>>> 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
     
    Victor Bazarov, Jul 10, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Edward Diener
    Replies:
    14
    Views:
    4,972
    Josiah Carlson
    Apr 6, 2004
  2. gonzlobo

    Writing more efficient code

    gonzlobo, Jan 1, 2007, in forum: Python
    Replies:
    13
    Views:
    457
    Hendrik van Rooyen
    Jan 3, 2007
  3. Neo
    Replies:
    10
    Views:
    668
    sushant
    Jan 20, 2005
  4. Marco
    Replies:
    19
    Views:
    839
    Dave Vandervies
    Apr 12, 2006
  5. Luca Cerone
    Replies:
    29
    Views:
    1,371
    lucacerone
    Feb 21, 2012
Loading...

Share This Page