3

In C++ I can write a function like this:

int test(params) { }

And the value returned is only a number (r-value). But it is also possibile to do this:

int& test(params) { }

In this case the function returns a "complete variable". This means that the returned value is not just a value like before but it is a complete variabile having both r-value and l-value.

Is this possibile in Delphi? The first function would be function test(params):integer; but what about the second?

I have seen something similar when I try to implement a parallel for loop. Look at here there is an &. Does it have the reference meaning? I wasnt able to find a good answer by myself.

Alberto Miola
  • 4,643
  • 8
  • 35
  • 49
  • The `&` is explained in the documentation here: http://docwiki.embarcadero.com/RADStudio/en/Fundamental_Syntactic_Elements#Extended_Identifiers Essentially it is used to "escape" reserved words – David Heffernan May 19 '17 at 07:56
  • See also: [Is the practice of returning a C++ reference variable, evil?](http://stackoverflow.com/questions/752658/) – David Heffernan May 19 '17 at 07:57
  • Thank you I didnt see that in the documentation. I am attending a C++ class and I wanted to do a comparison between delphi and c++ (and not java in this case ofc) so I was confused about the presence of & – Alberto Miola May 19 '17 at 08:01
  • 1
    Yes, finding that in the documentation is tricky. It's a case of you need to know what it means in order to be able to search for it! – David Heffernan May 19 '17 at 08:08

1 Answers1

5

Delphi does not support return-by-reference semantics like C++ does. The only options available are either:

  • return a pointer:

    function test(params): PInteger;

  • use a var or out output parameter:

    procedure test(params; var output: Integer);

procedure test(params; out output: Integer);
Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • 2
    But if you want to return a full value, please do not return pointers! The var/out solution is the best, – Rudy Velthuis May 19 '17 at 09:13
  • @RudyVelthuis That blanket statement doesn't make much sense to me. Sometimes returning a reference is appropriate, sometimes it is not. It depends on what you are trying a achieve. – David Heffernan May 19 '17 at 13:14
  • 1
    @Remy `var` or `out` do not correspond to *returning* a reference. They correspond to *passing in* references. – David Heffernan May 19 '17 at 13:16
  • @David: If a value or record must be returned, pointers are always a bad choice. Yes, it is a blanket statement, and if the pointer is just a pointer into to something that was passed in, it's fine, but generally, that is not the case. Generally, it is bad habit to return values through pointers. – Rudy Velthuis May 19 '17 at 13:20
  • 1
    @Rudy You don't understand. If you want to return a reference, return a reference. If you want to return a value, return a value. The type is irrelevant. Sometimes you want to return a reference, sometimes a value. You can't make a blanket statement. If I want to allow the caller to modify some value that I own, returning a value doesn't get it done. And vice versa. – David Heffernan May 19 '17 at 13:36
  • I do understand. I am merely saying: "generally: don't return a reference, if you can avoid it." And yes, I can make that blanket statement (you saw me doing it, so I could ) because it is almost always a bad idea to return a reference/pointer. There are exceptions (there are exceptions to almost *any* rule), but there are only a few. – Rudy Velthuis May 19 '17 at 14:18
  • @Rudy OK. Now you have changed your position. Always to almost always. Now you agree with me. – David Heffernan May 20 '17 at 07:17