On Fri, 15 Feb 2008 20:53:21 +0100, Saaa wrote:

> From the D1 documentation:
> For dynamic array and object parameters, which are passed by reference,
> in/out/ref apply only to the reference and not the contents.
> 
> What exactly (internally memory wise) does 'passing' mean. Is it like copying?


When a function's parameter is either a dynamic (variable-length) array or an object, the function does not get a copy of the parameter's data given to it. Instead it gets the address of the array/object instance. Actually, for arrays the function gets both the address and the length.

This is in contrast with structs, static (fixed-length) arrays, and basic data types. In these cases, the function does get a copy of the parameter's data.

> And does this mean that static arrays are not passed by reference and should
> I use:
> void func(ref array.ptr)
> ,because otherwise the whole array is passed (copied) ? (which sound slow:)

Exactly (almost). Use this instead ...


   void func(ref X[n] array)

Where 'X' is the array's datatype and 'n' is its fixed length. There is no need for the '.ptr' property when also using 'ref'. An alternative is to use pointers directly, but then you loose array-bounds checking.

   void func( X* array)


> Another question :)
> 
> What is the advantage of making a function/variable static?
> It makes it nonvirtual, right. Why is this good?
> When should I make something static or final?

I assume by "function/variable" here, you are referring to a class member.

You would make a function member 'static' if you wanted to call it without using a specific object. It belongs to the class and not a class instance (object). It is kind of like a free function that is scoped to the class's namespace.

    class Foo
    {
        static void Bar() { . . . }
    }
    . . .
    Foo.Bar();  // Call the Foo class's Bar function.

You would make a variable member 'static' if you wanted to use it without requiring a specific object. It belongs to the class and not a class instance (object). It is kind of like a global variable that is scoped to the class's namespace.

    class Foo
    {
        static int nextid = 1;
        int myID;
        this() { synchronized {myId = nextid; nextid++;} }
    }
    . . .
    Foo A = new Foo;
    Foo B = new Foo;
    writefln("A=%s, B=%s, next=%s", A.myID, B.myID, Foo.nextid);

    // Displays "A=1, B=2, next=3"


> A private function/var can't used by anything in a 'lower' scope, right?

I'm not sure what you mean by 'lower' scope.

A private function/variable can only be accessed from code within the same module as its declaration.

However there is a bug, which has been around for years but Walter doesn't regard as urgent, where 'private' can be overturned if the reference to the private function/variable is fully qualifed. In that case, code from any module can access the "so called private" entity.

   // -- file AA.d ---
   private int c;

   // -- file BB.d ---
     c = 1; // correctly fails.
     AA.c = 2; // Incorrectly works.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Saaa:

> What exactly is the namespace of a function?

Informally it's the set of names (variables, etc) that you can see and use from the code inside the function. (Probably it's a bit more complex than that, but the base is that one.)

Bye,
bearophile

Saaa wrote:
> Thanks again,
> 
> I don't think I ever override a function, should I make them final then, for optimizing purposes, or is final only for classes?

Are you developing an application or a library?

If it's a library, don't final it unless it's deep in the bowels where nobody will reasonably tread, or unless the library really requires performance.

If it's an application, feel free. You probably won't have much need for inheritance, but then, the optimizations from your final classes might not be that great.

But really, it's your decision.

Saaa <empty@needmail.com> wrote:
> How about passing a huge structure. Does this need something like a pointer
> to the struct?
> I mean, is the passing done optimal here:
> 
> struct S{
> int n1=1;
> int n2=2;
> ..
> int n999=999;
> }
> 
> void func(S s){
> ..
> }
> 
> void main (){
> S t;
> func(t);
> ..
> }

Use ref or pointer, whatever suits you best.  Usually ref is preferable because it makes no difference at the call site:

void func(ref S s){
..
}

void main (){
S t;
func(t);  // only a pointer is actually passed
..
}

If you use a pointer though, you must explicitly pass an address of your struct:

void func(S* s){
..
}

void main (){
S t;
func(&t); // explicit address expression
..
}

-- 
SnakE

Derek Parnell wrote:
 > This is in contrast with structs, static (fixed-length) arrays, and basic
> data types. In these cases, the function does get a copy of the parameter's
> data.

No, static arrays are 'reference' types.  Meaning they are passed as just the address of the first element.  You have to wrap them in a struct to get copy semantics for them.

On Sun, 17 Feb 2008 05:09:44 +0100, torhu wrote:

> Derek Parnell wrote:
>   > This is in contrast with structs, static (fixed-length) arrays, and
> basic
>> data types. In these cases, the function does get a copy of the parameter's data.
> 
> No, static arrays are 'reference' types.  Meaning they are passed as just the address of the first element.  You have to wrap them in a struct to get copy semantics for them.

Thanks for the correction. I was sure that at one stage static arrays were passed by value. This will simplify some of my code now.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

>> Thanks again,
>>
>> I don't think I ever override a function, should I make them final then, for optimizing purposes, or is final only for classes?
>
> Are you developing an application or a library?
>
> If it's a library, don't final it unless it's deep in the bowels where nobody will reasonably tread, or unless the library really requires performance.
>
> If it's an application, feel free. You probably won't have much need for inheritance, but then, the optimizations from your final classes might not be that great.

This reads as making a function final will hurt the optimization.
btw. I don't use classes :), only functions.
(application)

>
> But really, it's your decision.

Saaa wrote:
>>> Thanks again,
>>>
>>> I don't think I ever override a function, should I make them final then, for optimizing purposes, or is final only for classes?
>> Are you developing an application or a library?
>>
>> If it's a library, don't final it unless it's deep in the bowels where nobody will reasonably tread, or unless the library really requires performance.
>>
>> If it's an application, feel free. You probably won't have much need for inheritance, but then, the optimizations from your final classes might not be that great.
> 
> This reads as making a function final will hurt the optimization.
> btw. I don't use classes :), only functions.
> (application)

Marking a class or a method on a class as final can improve performance. DMD might not take advantage of that as often as you like.

Marking a function that is not in a class as final should do absolutely nothing.

>
> Marking a class or a method on a class as final can improve performance. DMD might not take advantage of that as often as you like.
>
> Marking a function that is not in a class as final should do absolutely nothing.

Ah ok, thanks :)

Making it:
It's a global variable that can be accessed/used only inside, the set of
names (variables, etc) that you can see and use from the code inside the
function, aka namespace of that function.

Does it contradict with:
A static variable inside a function (which I did not cover in my last
post), will keep its value after the function has exited, and even when
it's being called again.

I can't tell :D

>
>> What exactly is the namespace of a function?
>
> Informally it's the set of names (variables, etc) that you can see and use from the code inside the function. (Probably it's a bit more complex than that, but the base is that one.)
>
> Bye,
> bearophile