why should one use "&" in "const char*const& szString"

Discussion in 'C++' started by alariq, Feb 23, 2009.

  1. alariq

    alariq Guest

    Can some one explain me why should one use this construction. Is there
    any need for "&" ?
    Is there any difference between those 2 options: (excluding that in
    first case *szString is passed by value and in second - by reference):
    1) const char*const& szString
    2) const char*const szString


    Thanks is andvance
     
    alariq, Feb 23, 2009
    #1
    1. Advertising

  2. alariq

    alariq Guest

    thanks for clarifications!
     
    alariq, Feb 23, 2009
    #2
    1. Advertising

  3. alariq

    itaj sherman Guest

    On Feb 23, 5:23 pm, alariq <> wrote:
    > Can some one explain me why should one use this construction. Is there
    > any need for "&"  ?
    > Is there any difference between those 2 options: (excluding that in
    > first case *szString is passed by value and in second - by reference):
    > 1) const char*const& szString
    > 2) const char*const szString
    >
    > Thanks is andvance


    if you're talking about a parameter to a function as in:

    void func1( char const* const& r );
    void func2( char const* const r );

    or in general for any copyable type T:

    void func1( T const& r );
    void func2( T const r );

    In you're case T = char const*

    The difference is that in func1, the referenced T object is const to
    the code in func1, but may be non-const to someone else, who can
    change it. On the other hand in func2, once the funtion has been
    called, it has its own object that no one else can change.
    When calling func1 someone else, may change the state of the T object
    and the change will be reflected on the object used by func1 (because
    it is the same object). This someone else can be code in a different
    thread executing at the same time as func1, or else if func1 keeps
    that reference in some data structure, then even after func1 returns,
    the caller of func1 can change the state of the object referred to by
    that data structure.
     
    itaj sherman, Feb 25, 2009
    #3
  4. alariq

    itaj sherman Guest

    On Feb 25, 4:43 pm, itaj sherman <> wrote:
    > On Feb 23, 5:23 pm, alariq <> wrote:
    >
    > > Can some one explain me why should one use this construction. Is there
    > > any need for "&"  ?
    > > Is there any difference between those 2 options: (excluding that in
    > > first case *szString is passed by value and in second - by reference):
    > > 1) const char*const& szString
    > > 2) const char*const szString

    >
    > > Thanks is andvance

    >
    > if you're talking about a parameter to a function as in:
    >
    > void func1( char const* const& r );
    > void func2( char const* const r );
    >
    > or in general for any copyable type T:


    I mean, to be able to declare func2, type T needs a public copy
    constructor, assignment isn't necessary.

    >
    > void func1( T const& r );
    > void func2( T const r );
    >
    > In you're case T = char const*
    >
    > The difference is that in func1, the referenced T object is const to
    > the code in func1, but may be non-const to someone else, who can
    > change it. On the other hand in func2, once the funtion has been
    > called, it has its own object that no one else can change.
    > When calling func1 someone else, may change the state of the T object
    > and the change will be reflected on the object used by func1 (because
    > it is the same object). This someone else can be code in a different
    > thread executing at the same time as func1, or else if func1 keeps
    > that reference in some data structure, then even after func1 returns,
    > the caller of func1 can change the state of the object referred to by
    > that data structure.


    And I don't know if compiler optimizations could change anything about
    what I said.
     
    itaj sherman, Feb 25, 2009
    #4
  5. itaj sherman schrieb:

    > In you're case T = char const*


    I find it amazing that even programmers who know the difference
    between e.g. "foo->bar" and "foo.bar" sometimes don't seem to
    differentiate between "you're" and "your".

    Peter
     
    Peter Remmers, Feb 27, 2009
    #5
  6. alariq

    itaj sherman Guest

    On Feb 27, 9:00 am, Peter Remmers
    <> wrote:
    > itaj sherman schrieb:
    >
    >  > In you're case T = char const*
    >
    > I find it amazing that even programmers who know the difference
    > between e.g. "foo->bar" and "foo.bar" sometimes don't seem to
    > differentiate between "you're" and "your".
    >
    > Peter


    I know the difference just as well as I know the difference between
    foo.bar and boo->bar. It's not the same as differentiating. Sometimes
    I don't seem to differentiate between foo.bar and foo->bar too, and
    it's only at compile time that I find out about it.
     
    itaj sherman, Mar 1, 2009
    #6
  7. alariq

    James Kanze Guest

    On Feb 23, 4:39 pm, Jeff Schwab <> wrote:
    > Victor Bazarov wrote:
    > > alariq wrote:
    > >> Can some one explain me why should one use this construction. Is there
    > >> any need for "&" ?
    > >> Is there any difference between those 2 options: (excluding that in
    > >> first case *szString is passed by value and in second - by reference):
    > >> 1) const char*const& szString
    > >> 2) const char*const szString


    > > Actually, it's vice versa - in the first case it's passed by
    > > reference and in the second - by value. But you're correct
    > > it doesn't really make much of a difference. A *possible*
    > > (yet unlikely) reason is that they wanted to make some kind
    > > of obscure overloading work or pick some particular
    > > template... Or did it simply out of habit (more likely).


    > In addition to what Victor said, it's worth noting that the
    > pass-by-reference overload may be slower, especially if the
    > function's definition has not yet been seen by the compiler at
    > the point of call. The problem is that the pass-by-reference
    > overload is allowed to retain a pointer to its argument (thus
    > restricting possible optimizations), whereas the pass-by-value
    > version is not.


    In practice, the pass by reference is always implemented by
    passing a pointer. Which means that the object referred to must
    be locked in memory. For simple objects, which could otherwise
    be in a register, this can make a significant difference; if a
    function takes an int const&, and I pass it 43, the compiler
    must create a temporary value (in memory) of type int,
    iniitialize it with 43, then take the address of this variable
    and pass it. If I just declare the function to take an int (or
    an int const), the compiler can just pass the value immediately.

    Within the called function, of course, the compiler must take
    into account that the reference might be an alias; i.e. that
    other references might refer to it, or that it might refer to a
    global variable. This can lead to a lot more memory accesses
    than otherwise.

    In theory, the above should apply to any "smallish" type,
    including non-polymorphic class types which only require one or
    two words. In practice, I'm not aware of any compiler which
    manages to optimize such objects into registers when they have
    user defined constructors, so passing by const reference will
    usually result in one copy less, with no other real effects, at
    the call site. (The issues concerning aliasing still affect the
    called function, however.) For this reason, one common
    convention is to pass class types by reference to const, and
    everything else by value.

    --
    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, Mar 2, 2009
    #7
  8. alariq

    James Kanze Guest

    On Feb 27, 5:16 pm, Jeff Schwab <> wrote:
    > Peter Remmers wrote:
    > > itaj sherman schrieb:


    > > > In you're case T = char const*


    > > I find it amazing that even programmers who know the
    > > difference between e.g. "foo->bar" and "foo.bar" sometimes
    > > don't seem to differentiate between "you're" and "your".


    > +1


    > Joel Spolsky advocates that all programmers should take
    > classes in writing. I am inclined to agree.


    IMHO, that's putting the cart before the horse. You shouldn't
    be allowed to learn programming until you can express yourself
    clearly and concisely in your native language.

    In this particular case, however, I'd make allowance for a
    possible typo, rather than automatically assuming that the
    poster didn't know or understand the difference. (I know that I
    know the difference, but I'll bet that if you were to search all
    of my postings, you'd find a couple of slip ups.) And of
    course, there's also the possibility that English isn't the
    poster's native language.

    --
    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, Mar 2, 2009
    #8
  9. alariq

    James Kanze Guest

    On Mar 2, 3:55 pm, Jeff Schwab <> wrote:
    > James Kanze wrote:
    > > On Feb 23, 4:39 pm, Jeff Schwab <> wrote:
    > >>>> Is there any difference between those 2 options:
    > >>>> 1) const char*const& szString
    > >>>> 2) const char*const szString
    > >> the pass-by-reference overload may be slower, especially if
    > >> the function's definition has not yet been seen by the
    > >> compiler at the point of call. The problem is that the
    > >> pass-by-reference overload is allowed to retain a pointer
    > >> to its argument (thus restricting possible optimizations),
    > >> whereas the pass-by-value version is not.

    > > In practice, the pass by reference is always implemented by
    > > passing a pointer.
    > > If I just declare the function to take an int (or
    > > an int const), the compiler can just pass the value immediately.


    > Right, although probably not "immediately" in the sense of an
    > immediate argument to the opcode. At least, if the function
    > definition has not been seen by the compiler at the point of
    > call, the int probably has to be pushed onto the stack.
    > That's still better than pushing a *pointer* to the int onto
    > the stack.


    The int value has to be put where ever parameters are put. The
    first five go into registers on my machine.

    > > one common convention is to pass class types by reference to
    > > const, and everything else by value.


    > Where reasonable, I use traits classes to determine the
    > correct type to pass.


    In templates, of course, you don't know whether T is a class
    type or not, so you have to fudge. For the most part, people
    seem to prefer const reference, on the grounds that non-class
    types are fairly rare.

    Other considerations also come into consideration. If the
    function is going to modify the value (e.g. as with an
    iterator), then pass by value often makes sense even for class
    types, and in cases where there is an inversion of control,
    there's no really adequate solution: const reference means that
    the callback function must be const, non-const reference means
    that you can't pass an rvalue, and value means that you've lost
    identity. (The standard library uses value in such cases---if
    you need identity, then you must add a level of indirection.)

    --
    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, Mar 3, 2009
    #9
    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. D. Shane Fowlkes
    Replies:
    3
    Views:
    631
    S. Justin Gengo
    Feb 24, 2004
  2. Darrel
    Replies:
    1
    Views:
    356
    Scott Allen
    Nov 11, 2004
  3. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    910
    Mark Rae
    Dec 21, 2006
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,999
    Smokey Grindel
    Dec 2, 2006
  5. Chuckk Hubbard
    Replies:
    1
    Views:
    313
    Peter Otten
    Jun 9, 2008
Loading...

Share This Page