Re: const after initialization / pointers, references and values

[Philippe Sigaud via Digitalmars-d]

> After initialization there is no need to modify the data anymore.
> My first question is: can the data be changed to "const" once
> initialized?

You can have const or immutable data, that can be initialized once.
I tend to use pure functions to do that:


struct Node {
        Node[] block;
        uint num = 0;
}

Node makeDefaultNode() pure {
    return Node(null, 1);
}

void main(){
    immutable Node n = makeDefaultNode();

    import std.stdio;
    writeln(n);
    writeln(typeof(n).stringof);// immutable(Node)
}

You can also use module constructors:

module foo;

immutable myDefault;

static this() {
    myDefault = ...
}

/* rest of code */

I cannot comment much more. I use functions to initialize my immutable
values. I don't know much about module constructors.


> Related to that, how can the default initializer be changed to
> immutable?

In your example code, your default value can be marked immutable, if
you want it.
Just use:

immutable Node[] default_nodes = [
        {num:3},
        {block:[{num:4},{num:6},{block:[{num:5},{num:7}]}]},
        // ...
];

> The second question is related to pointers, references and values
> I know that structs by default use value semantics, but as data
> is large I want to avoid data copying.
> But I would like to avoid use of pointers, so, is there a way of
> using reference semantics in the example code?
> Maybe is as simple as changing from "struct Node" to "class
> Node", but seems intuitive that classes carry more overhead than
> structs.

If you want reference semantics but do not want to have pointers in
your code, yes classes are your best choice.


> How much overhead carries a class in comparison to a struct?

There is an overhead when calling functions, due to the virtual table.
But that's mainly when you construct hierarchies of classes, so that
the runtime can determine which method to call for each object. If you
don't need derived classes, then I guess using a final class is your
best bet. I think it discards the virtual table.

final class { ... }

I'd say: test it. Duplicate your module, change your structs to final
classes and compare the speed of the two modules.