• bearophile <bearophileHUGS lycos.com> Oct 09 2011
• Andrej Mitrovic <andrej.mitrovich gmail.com> Oct 09 2011
• Jonathan M Davis <jmdavisProg gmx.com> Oct 09 2011
• bearophile <bearophileHUGS lycos.com> Oct 10 2011
• Andrej Mitrovic <andrej.mitrovich gmail.com> Oct 10 2011
• Mafi <mafi example.org> Oct 11 2011
• "Steven Schveighoffer" <schveiguy yahoo.com> Oct 12 2011

bearophile <bearophileHUGS lycos.com> writes:

(I show this here because it's probably a silly idea, but it may a chance to
learn something.)
Do you like the idea of a POD that is always managed by reference, as class
instances?


ref struct Foo {}
static assert(Foo.sizeof == 1);
void main() {
    Foo f1; // void reference
    Foo f2 = new Foo; // by reference
}


It is as light as a struct, but you don't need to use the pointer syntax to
manage a Foo instance, the code is cleaner. There is no info field inside a ref
struct, so in some situations the destructor doesn't get called, like regular
structs.

Bye,
bearophile

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

I think this is what refcounted structs are for.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Sunday, October 09, 2011 22:42:35 Andrej Mitrovic wrote:
 I think this is what refcounted structs are for.


That or make it a class and make it final.

- Jonathan M Davis

bearophile <bearophileHUGS lycos.com> writes:

Andrej Mitrovic:

 I think this is what refcounted structs are for.


"ref structs" are regular heap-allocated GC-managed structs, but they are
managed by reference instead of by pointer. So refcounting is not significant
here.

--------------------------

Jonathan M Davis:

 That or make it a class and make it final.


Such class instances have a 2 words overhead, plus runtime code to initialize
those fields. "ref structs" don't have them.

Bye,
bearophile

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 10/11/11, bearophile <bearophileHUGS lycos.com> wrote:
 Andrej Mitrovic:

 I think this is what refcounted structs are for.


 "ref structs" are regular heap-allocated GC-managed structs, but they are
 managed by reference instead of by pointer. So refcounting is not
 significant here.


But can't you just make a wrapper struct that GC-allocates an internal
struct and uses subtyping and refcounting?

Mafi <mafi example.org> writes:

Am 09.10.2011 19:52, schrieb bearophile:
 (I show this here because it's probably a silly idea, but it may a chance to
learn something.)
 Do you like the idea of a POD that is always managed by reference, as class
instances?


 ref struct Foo {}
 static assert(Foo.sizeof == 1);
 void main() {
      Foo f1; // void reference
      Foo f2 = new Foo; // by reference
 }


 It is as light as a struct, but you don't need to use the pointer syntax to
manage a Foo instance, the code is cleaner. There is no info field inside a ref
struct, so in some situations the destructor doesn't get called, like regular
structs.

 Bye,
 bearophile


What about:

struct FooData {...}
alias FooData* Foo;

//dot syntax etc works like you want
//only problem: (new FooData) instead of (new Foo)

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Sun, 09 Oct 2011 13:52:47 -0400, bearophile <bearophileHUGS lycos.com>  
wrote:

 (I show this here because it's probably a silly idea, but it may a  
 chance to learn something.)
 Do you like the idea of a POD that is always managed by reference, as  
 class instances?


 ref struct Foo {}
 static assert(Foo.sizeof == 1);
 void main() {
     Foo f1; // void reference
     Foo f2 = new Foo; // by reference
 }


 It is as light as a struct, but you don't need to use the pointer syntax  
 to manage a Foo instance, the code is cleaner. There is no info field  
 inside a ref struct, so in some situations the destructor doesn't get  
 called, like regular structs.


You can achieve this with pImpl structs.  I think the only difference is  
the creation/destruction must be done via functions instead of new/GC.free.

-Steve