www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Overload resolution (value vs reference)

reply "m0rph" <m0rph.mailbox gmail.com> writes:
How does compiler selects the proper function among overloaded
functions which differ only in the way the argument is passed (by
reference or by value)? Is there a way, to control this behavior?

Result of execution of the test code:
passed by value: 8
passed by value: 3
passed by value: Foo(10)


Test code:

import std.stdio;

struct Foo {
      int value;
}

void f(T)(T foo)
{
      writeln("passed by value: ", foo);
}

void f(T)(const ref T foo)
{
      writeln("passed by reference: ", foo);
}

void main()
{
      // 8 is a r-vlaue, so it's passed by value
      f(8);

      // i is a l-value, it's passed by value and it's ok
      int i = 3;
      f(i);

      // foo is a l-value, it's passed by value again, but if
structure will be big enough it'll be ineffective

      auto foo = Foo();
      foo.value = 10;
      f(foo);
}
Oct 21 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sun, 2012-10-21 at 19:01 +0200, m0rph wrote:

 How does compiler selects the proper function among overloaded
 functions which differ only in the way the argument is passed (by
 reference or by value)? Is there a way, to control this behavior?
 
 Result of execution of the test code:
 passed by value: 8
 passed by value: 3
 passed by value: Foo(10)
 
 
 Test code:
 
 import std.stdio;
 
 struct Foo {
       int value;
 }
 
 void f(T)(T foo)
 {
       writeln("passed by value: ", foo);
 }
 
 void f(T)(const ref T foo)
 {
       writeln("passed by reference: ", foo);
 }
 
 void main()
 {
       // 8 is a r-vlaue, so it's passed by value
       f(8);
 
       // i is a l-value, it's passed by value and it's ok
       int i = 3;
       f(i);
 
       // foo is a l-value, it's passed by value again, but if
 structure will be big enough it'll be ineffective
 
       auto foo = Foo();
       foo.value = 10;
       f(foo);
 }
 


http://dlang.org/function.html#function-overloading

The big thing to remember here is that constness matters more than
refness when overloads are chosen, so if you want refness to matter when
choosing an overload, then the constness of the overloads must match,
and if there's ever a question between const and non-const, it's the
constness of the argument being passed in which wins (e.g. if you have
ref T and const ref T, then which one gets called depends on whether the
argument is const or not).

As your code stands, if it were

void f(T)(T foo)
{
    f(foo);
}

void f(T)(const ref T foo)
{
    //...
}

you would get an infinite loop when passing an rvalue to f, whereas

void f(T)(const T foo)
{
    f(foo);
}

void f(T)(const ref T foo)
{
    //...
}

would not.

- Jonathan M Davis
Oct 21 2012
next sibling parent "m0rph" <m0rph.mailbox gmail.com> writes:
Thanks for explanation!
Oct 22 2012
prev sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Sunday, 21 October 2012 at 22:47:00 UTC, Jonathan M Davis 
wrote:


 http://dlang.org/function.html#function-overloading

 The big thing to remember here is that constness matters more 
 than refness when overloads are chosen, so if you want refness 
 to matter when choosing an overload, then the constness of the 
 overloads must match, and if there's ever a question between 
 const and non-const, it's the constness of the argument being 
 passed in which wins (e.g. if you have ref T and const ref T, 
 then which one gets called depends on whether the argument is 
 const or not).


  There any word on if this was going to change? I'm meaning 
towards structs/classes with const preference vs non-const 
preferences. I recall a while back while trying to make copy/move 
functions and I had to completely duplicate the functions so it 
would use the right versions.
Oct 22 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, October 22, 2012 22:54:44 Era Scarecrow wrote:

 On Sunday, 21 October 2012 at 22:47:00 UTC, Jonathan M Davis
 
 wrote:

 http://dlang.org/function.html#function-overloading
 
 The big thing to remember here is that constness matters more
 than refness when overloads are chosen, so if you want refness
 to matter when choosing an overload, then the constness of the
 overloads must match, and if there's ever a question between
 const and non-const, it's the constness of the argument being
 passed in which wins (e.g. if you have ref T and const ref T,
 then which one gets called depends on whether the argument is
 const or not).


 
 There any word on if this was going to change? I'm meaning
 towards structs/classes with const preference vs non-const
 preferences. I recall a while back while trying to make copy/move
 functions and I had to completely duplicate the functions so it
 would use the right versions.


AFAIK, there are no plans to change it. I don't think that it's even been 
suggested.

For the most part though, you can just have the non-ref version call the ref 
version as long as there's a ref version with the same constness, so even if 
you have to duplicate the function, you don't have to duplicate its body. You 
might be stuck with some duplication between the const and non-const overloads 
though if you have all 4 of them.

- Jonathan M Davis
Oct 22 2012
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 22 October 2012 at 21:58:04 UTC, Jonathan M Davis 
wrote:

 AFAIK, there are no plans to change it. I don't think that it's 
 even been suggested.


  I thought I suggested it back for a different order of 
preferences. Basically boils down to accepting the const ones 
over the non-const whenever applicable and possible. Quite 
annoying that it was accepting non-const copy over const ref for 
the purposes I was going for.


 For the most part though, you can just have the non-ref version 
 call the ref version as long as there's a ref version with the 
 same constness, so even if you have to duplicate the function, 
 you don't have to duplicate its body. You might be stuck with 
 some duplication between the const and non-const overloads 
 though if you have all 4 of them.


  Yeah I know... I guess best practice is to offer all const or 
non-const of particular function names/uses, but that doesn't 
always want to work. Let's see how did that go...

  struct S {
    ref S opAssign(S s);           //move. TDPL pg. 257-259
    ref S opAssign(const ref S s); //copy (almost postblitz)

/* as of current, only the 'move' is always used unless the 
struct is actually const. inout isn't applicable I think. I'm 
promising not to change the input on the copy, and the move can't 
be const (if there's any addressing to transfer). I consider the 
reference the important distinction, yet the non-const is always 
called/preferred */

    ref S opAssign(const S s); //duplicate(s) of above in reverse
    ref S opAssign(ref S s);   //best match works better now
  }
Oct 22 2012