[fpc-pascal] function returning a record vs paramaters

[L505]

| No. Even no performance loss. The "additional pointer" is the same as
| the otherwise used "var parameter". The following two pascal procedure
| do essentially the same, they just differ in syntax:
|
| function proc_1: t_record;
| begin
|   result.a := 1;
| end;
|
| procedure proc_2(var x: t_record);
| begin
|   x.a := 1;
| end;
|
| The first form, proc_1, is silently converted to the second form, by the
| compiler.

Thanks for clearing up that.  Same amount of pointers in the end.


| At least for free pascal, there is no lack in performance when you
| "return a record".
|
| I'm not sure if I get your point right, especially concerning Ada ...
| Anyway, if people question how a parameter can possibly return a value,
| tell them a "var parameter" allows more than a function result. It
| allows the called procedure to -act- on the data, including both reading

Yes, and useful in recursive situations.. because you don't want to be
re-copying the data to another var if it's just going to be re-used again and
again anyway. Might as well just add on or modify the existing var over and over
again.

| and writing. That would be "in out" in Ada. In Pascal, this is also
| known as "call by reference", and not necessarily hackish ... Think of a
| procedure that calculates and inserts the checksum in a telegram that
| already contains valid data:

Well, confusing especially when you are using code completion/code insight - the
vars inside brackets get confusing. You can't tell which vars inside the
brackets are result parameters(dummy ones), and which are your working
parameters. Unless they were prefixed with Result_ , or unless you really knew
the function well (more time in the help docs).

If the variable is prefixed with result_ for example, you at least know while
looking at code insight, that this is a result variable, (a dummy variable). It
stops you from going into the help docs, or getting confused as much.

The other issue is that people are afraid of global variables or even partially
global variables, and all sorts of people say to not use them.. but obviously
they are very useful in some situations.

|
| procedure insert_checksum(var a_telegram: t_telegram_record);
|
| This procedure reads the telegram data, calculates some sort of checksum
| and fills in the telegram's checksum field. This cannot be done with the
| "return a record" method, except when passing the parameter twice (=
| performance loss).

Right, so definitely use the right tool for the right job. I've done this a few
times where it makes sense to use the existing var to modify existing data. I
just have failed to acknowledge those situations it seems (hehe).

One could go as far as never even using functions at all, and just using
procedures. But definitely more readable if you utilize them in the right
situations. I think for code insight and clarity purposes I'll stick to
returning data as value where possible. But like you say, when modifying
existing data, utilize the "passing a parameter" or "call by reference" way It
will be more effiecient and offers less code noise and var copying.