www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - GC for noobs

reply "Szymon Gatner" <noemail gmail.com> writes:
Hi,

I am evaluating D for future projects and coming from C++ I find 
it really hard to understand semantics of destruction of 
GC-managed code.

After many application-shutdown crashes caused by invalid order 
of class destructor calls I really think I need to change the way 
I am thinking about them (and resource management in general I 
suppose).

My crashes (still have them and can't track all as debugging D 
sucks) are caused by the fact that d-tor of parent object can be 
called before child d-tors. Adding destroy() calls in parent 
d-tors helped with some of crashes but I really hate this 
solution as I was virtually NEVER using 'delete' in C++.

I feel like I should be doing things in D very differently than I 
am doing them in C++. I now think I should be using structs 
everywhere because I understand them but I do need reference 
semantics (ideally with unique ownership).

Please point me to a literature for C++ programmer that has very 
little experience with GC/resource management, because at this 
point I really feel like GC should be easing things and working 
against me.
Feb 27 2014
parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Thursday, 27 February 2014 at 09:49:08 UTC, Szymon Gatner 
wrote:

 My crashes (still have them and can't track all as debugging D 
 sucks) are caused by the fact that d-tor of parent object can 
 be called before child d-tors. Adding destroy() calls in parent 
 d-tors helped with some of crashes but I really hate this 
 solution as I was virtually NEVER using 'delete' in C++.


Parent in the sense of an inheritance hierarchy or in the sense 
of a successor relation in a graph of objects?

In the latter case the order of destruction is undefined (IMO), 
i.e. if you have class A { B someB; } where B is a class as well, 
than B might be already destroyed if A's destructor is run.
Feb 27 2014
parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Thursday, 27 February 2014 at 09:55:14 UTC, Tobias Pankrath 
wrote:

 On Thursday, 27 February 2014 at 09:49:08 UTC, Szymon Gatner 
 wrote:

 My crashes (still have them and can't track all as debugging D 
 sucks) are caused by the fact that d-tor of parent object can 
 be called before child d-tors. Adding destroy() calls in 
 parent d-tors helped with some of crashes but I really hate 
 this solution as I was virtually NEVER using 'delete' in C++.




Spec says:
--
The garbage collector is not guaranteed to run the destructor for 
all unreferenced objects. Furthermore, the order in which the 
garbage collector calls destructors for unreference objects is 
not specified. This means that when the garbage collector calls a 
destructor for an object of a class that has members that are 
references to garbage collected objects, those references may no 
longer be valid. >> This means that destructors cannot reference 
sub objects. <<
--
Feb 27 2014
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 09:57:51 UTC, Tobias Pankrath 
wrote:

 On Thursday, 27 February 2014 at 09:55:14 UTC, Tobias Pankrath 
 wrote:

 On Thursday, 27 February 2014 at 09:49:08 UTC, Szymon Gatner 
 wrote:

 My crashes (still have them and can't track all as debugging 
 D sucks) are caused by the fact that d-tor of parent object 
 can be called before child d-tors. Adding destroy() calls in 
 parent d-tors helped with some of crashes but I really hate 
 this solution as I was virtually NEVER using 'delete' in C++.




 Spec says:
 --
 The garbage collector is not guaranteed to run the destructor 
 for all unreferenced objects. Furthermore, the order in which 
 the garbage collector calls destructors for unreference objects 
 is not specified. This means that when the garbage collector 
 calls a destructor for an object of a class that has members 
 that are references to garbage collected objects, those 
 references may no longer be valid. >> This means that 
 destructors cannot reference sub objects. <<
 --


Parent-child in the sense of object graph. I did read the spec 
when I started to notice crashes. I must say that it really 
terrified me to my very bones. I always though that higher-level 
memory management environments would give more and not less 
guarantees.

Anyway, I really need to learn how to design the code for CG and 
undefined d-tor calls. Any pointers would be welcome.
Feb 27 2014
parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
Szymon Gatner wrote:

 Parent-child in the sense of object graph. I did read the spec 
 when I started to notice crashes. I must say that it really 
 terrified me to my very bones. I always though that 
 higher-level memory management environments would give more and 
 not less guarantees.

 Anyway, I really need to learn how to design the code for CG 
 and undefined d-tor calls. Any pointers would be welcome.


I think that will depend on your use case. Why do you need to 
refer to child objects in your destructor?
Feb 27 2014
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 10:40:15 UTC, Tobias Pankrath 
wrote:

 Szymon Gatner wrote:

 Parent-child in the sense of object graph. I did read the spec 
 when I started to notice crashes. I must say that it really 
 terrified me to my very bones. I always though that 
 higher-level memory management environments would give more 
 and not less guarantees.

 Anyway, I really need to learn how to design the code for CG 
 and undefined d-tor calls. Any pointers would be welcome.


 I think that will depend on your use case. Why do you need to 
 refer to child objects in your destructor?


I don't need to refer to children, I just want them to do their 
cleanup first as they should.

This is basic resource-management stuff, surely there has to be 
generic advice out there?
Feb 27 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Szymon Gatner:


I just want them to do their cleanup first as they should.


Why? Perhaps if you explain what's behind your needs better, 
people can help better.

Bye,
bearophile
Feb 27 2014
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 11:13:17 UTC, bearophile wrote:

 Szymon Gatner:


I just want them to do their cleanup first as they should.


 Why? Perhaps if you explain what's behind your needs better, 
 people can help better.

 Bye,
 bearophile


In my specific example I am creating OpenGL Renderer. Renderer 
class instance holds GLContext instance. After context creation 
GL objects are created like textures and vertex buffers. Those 
are Texture and VertexBuffer class instances too. It is critical 
that those child resources are freed before GL context is 
destroyed. Thing is, even tho Renderer keeps list of Textures , 
VertexBuffers and  Context object, order of their destruction is 
completely undefined making Context d-tor called first and then 
child resources d-tors which ends in catastrophe.

In C++ (which has a LOT of problems) this is a no-brainer. Order 
of d-tors is fully defined. Sub-objects are destroyed before 
parent d-tor is called so only thing to worry about is the order 
of definition of members.

This is just an example but I would think that it is something 
rather important to have... What about child objects 
un-registering themselves in d-tors from a list that parent 
object holds and parent is destroyed first? What about 
asynchronous completion handler object that should notify some 
other object that it finished/not finished a job but a notifee is 
already destroyed because application is being shut-down? I 
honestly can't imagine how to reason about object graph lifetimes 
in GC world and I am sure I am missing something very basic. 
Probably a very different mindset.
Feb 27 2014
next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Thursday, 27 February 2014 at 12:25:49 UTC, Szymon Gatner 
wrote:

 On Thursday, 27 February 2014 at 11:13:17 UTC, bearophile wrote:

 Szymon Gatner:


I just want them to do their cleanup first as they should.


 Why? Perhaps if you explain what's behind your needs better, 
 people can help better.

 Bye,
 bearophile


 In my specific example I am creating OpenGL Renderer. Renderer 
 class instance holds GLContext instance. After context creation 
 GL objects are created like textures and vertex buffers. Those 
 are Texture and VertexBuffer class instances too. It is 
 critical that those child resources are freed before GL context 
 is destroyed. Thing is, even tho Renderer keeps list of 
 Textures , VertexBuffers and  Context object, order of their 
 destruction is completely undefined making Context d-tor called 
 first and then child resources d-tors which ends in catastrophe.

 In C++ (which has a LOT of problems) this is a no-brainer. 
 Order of d-tors is fully defined. Sub-objects are destroyed 
 before parent d-tor is called so only thing to worry about is 
 the order of definition of members.

 This is just an example but I would think that it is something 
 rather important to have... What about child objects 
 un-registering themselves in d-tors from a list that parent 
 object holds and parent is destroyed first? What about 
 asynchronous completion handler object that should notify some 
 other object that it finished/not finished a job but a notifee 
 is already destroyed because application is being shut-down? I 
 honestly can't imagine how to reason about object graph 
 lifetimes in GC world and I am sure I am missing something very 
 basic. Probably a very different mindset.


I had the same problem in Dgame. Therefore I use shared pointers 
(https://github.com/Dgame/Dgame/blob/master/Graphics/Surface.d#L90) 
or if I have to use classes, I use this:

https://github.com/Dgame/Dgame/blob/master/Window/Window.d#L44
https://github.com/Dgame/Dgame/blob/master/Window/Window.d#L177

I put the instances in a module global array and the module dtor 
finalize the data.
Feb 27 2014
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 12:32:36 UTC, Namespace wrote:

 On Thursday, 27 February 2014 at 12:25:49 UTC, Szymon Gatner 
 wrote:

 On Thursday, 27 February 2014 at 11:13:17 UTC, bearophile 
 wrote:

 Szymon Gatner:


I just want them to do their cleanup first as they should.


 Why? Perhaps if you explain what's behind your needs better, 
 people can help better.

 Bye,
 bearophile


 In my specific example I am creating OpenGL Renderer. Renderer 
 class instance holds GLContext instance. After context 
 creation GL objects are created like textures and vertex 
 buffers. Those are Texture and VertexBuffer class instances 
 too. It is critical that those child resources are freed 
 before GL context is destroyed. Thing is, even tho Renderer 
 keeps list of Textures , VertexBuffers and  Context object, 
 order of their destruction is completely undefined making 
 Context d-tor called first and then child resources d-tors 
 which ends in catastrophe.

 In C++ (which has a LOT of problems) this is a no-brainer. 
 Order of d-tors is fully defined. Sub-objects are destroyed 
 before parent d-tor is called so only thing to worry about is 
 the order of definition of members.

 This is just an example but I would think that it is something 
 rather important to have... What about child objects 
 un-registering themselves in d-tors from a list that parent 
 object holds and parent is destroyed first? What about 
 asynchronous completion handler object that should notify some 
 other object that it finished/not finished a job but a notifee 
 is already destroyed because application is being shut-down? I 
 honestly can't imagine how to reason about object graph 
 lifetimes in GC world and I am sure I am missing something 
 very basic. Probably a very different mindset.


 I had the same problem in Dgame. Therefore I use shared 
 pointers 
 (https://github.com/Dgame/Dgame/blob/master/Graphics/Surface.d#L90) 
 or if I have to use classes, I use this:

 https://github.com/Dgame/Dgame/blob/master/Window/Window.d#L44
 https://github.com/Dgame/Dgame/blob/master/Window/Window.d#L177

 I put the instances in a module global array and the module 
 dtor finalize the data.


Module d-tor() looks like a pretty good solution, thanks. 
shared_ptr tho... I was really hoping that I am moving away from 
it to a better place...

Still, this feels like working around a language issue, if c-tor 
order is defined why d-tor isn't? I am ok with non-deterministic 
time of execution of d-tors/finalizers but not-having 
parent-child d-tor order defined? That is weird.
Feb 27 2014
next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Thursday, 27 February 2014 at 13:00:27 UTC, Szymon Gatner 
wrote:

 On Thursday, 27 February 2014 at 12:32:36 UTC, Namespace wrote:

 On Thursday, 27 February 2014 at 12:25:49 UTC, Szymon Gatner 
 wrote:

 On Thursday, 27 February 2014 at 11:13:17 UTC, bearophile 
 wrote:

 Szymon Gatner:


I just want them to do their cleanup first as they should.


 Why? Perhaps if you explain what's behind your needs better, 
 people can help better.

 Bye,
 bearophile


 In my specific example I am creating OpenGL Renderer. 
 Renderer class instance holds GLContext instance. After 
 context creation GL objects are created like textures and 
 vertex buffers. Those are Texture and VertexBuffer class 
 instances too. It is critical that those child resources are 
 freed before GL context is destroyed. Thing is, even tho 
 Renderer keeps list of Textures , VertexBuffers and  Context 
 object, order of their destruction is completely undefined 
 making Context d-tor called first and then child resources 
 d-tors which ends in catastrophe.

 In C++ (which has a LOT of problems) this is a no-brainer. 
 Order of d-tors is fully defined. Sub-objects are destroyed 
 before parent d-tor is called so only thing to worry about is 
 the order of definition of members.

 This is just an example but I would think that it is 
 something rather important to have... What about child 
 objects un-registering themselves in d-tors from a list that 
 parent object holds and parent is destroyed first? What about 
 asynchronous completion handler object that should notify 
 some other object that it finished/not finished a job but a 
 notifee is already destroyed because application is being 
 shut-down? I honestly can't imagine how to reason about 
 object graph lifetimes in GC world and I am sure I am missing 
 something very basic. Probably a very different mindset.


 I had the same problem in Dgame. Therefore I use shared 
 pointers 
 (https://github.com/Dgame/Dgame/blob/master/Graphics/Surface.d#L90) 
 or if I have to use classes, I use this:

 https://github.com/Dgame/Dgame/blob/master/Window/Window.d#L44
 https://github.com/Dgame/Dgame/blob/master/Window/Window.d#L177

 I put the instances in a module global array and the module 
 dtor finalize the data.


 Module d-tor() looks like a pretty good solution, thanks. 
 shared_ptr tho... I was really hoping that I am moving away 
 from it to a better place...

 Still, this feels like working around a language issue, if 
 c-tor order is defined why d-tor isn't? I am ok with 
 non-deterministic time of execution of d-tors/finalizers but 
 not-having parent-child d-tor order defined? That is weird.


I use this solution especially because I have to finalize the 
data before I call SDL_Quit. And therefore I cannot trust the 
non-deterministic execution of the Dtor.
Feb 27 2014
parent "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 13:04:17 UTC, Namespace wrote:

 I use this solution especially because I have to finalize the 
 data before I call SDL_Quit. And therefore I cannot trust the 
 non-deterministic execution of the Dtor.


I fully understand that ;)

I will take a look at DGame too for sure. Atm now I am still 
learning D and its abilities to directly use C code.
Feb 27 2014
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On 2/27/2014 10:00 PM, Szymon Gatner wrote:


 Still, this feels like working around a language issue, if c-tor order
 is defined why d-tor isn't? I am ok with non-deterministic time of
 execution of d-tors/finalizers but not-having parent-child d-tor order
 defined? That is weird.


I've never seen a garbage collected language where the GC guarantees 
order of destruction. There's probably a very good reason for it.
Feb 27 2014
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 2/27/2014 9:25 PM, Szymon Gatner wrote:


 This is just an example but I would think that it is something rather
 important to have... What about child objects un-registering themselves
 in d-tors from a list that parent object holds and parent is destroyed
 first? What about asynchronous completion handler object that should
 notify some other object that it finished/not finished a job but a
 notifee is already destroyed because application is being shut-down? I
 honestly can't imagine how to reason about object graph lifetimes in GC
 world and I am sure I am missing something very basic. Probably a very
 different mindset.


Two simple rules I follow.




I tend to add two methods to classes that need to do any sort of set up 
and clean up: initialize and terminate. Then, at app exit, I make sure 
that the terminate methods are called either with scope(exit) or, if I 
want to log any exceptions that percolate up to main, try-catch-finally. 
Something like this:

class TextureManager {
    private TexContainer _loadedTextures;
    public void initialize() {...}
    public void terminate() {
       foreach( tex; _loadedTextures[])
           tex.terminate();
    }
}

struct Game {
      disable this();
      disable this( this );

     private static TextureManager _texMan;

     public static void initialize() {
        _texMan = new TextureManager();
        _texMan.initialize();
     }
     public static void terminate() {
         _texMan.terminate();
     }
}

void main() {
    scope( exit ) Game.terminate();
    Game.initialize();
}

In some parts of a system, for objects that tend to be short lived, I'll 
use structs with destructors for RAII. A good example of this is for 
vertex and fragment shaders. The shader programs are long-lived, so 
those are classes, but I always destroy the shader objects as soon as 
any programs that need them are built. So those are perfect candidates 
for the struct-based RAII approach.

RAII is a convenient tool, but it's just that, a tool. One of the 
tradeoffs you have to make with D's GC is that you can't use RAII the 
same way you do in C++. You *can* use it with structs, but for classes 
you're going to have to put C++ out of your head.
Feb 27 2014
parent reply "Remo" <remo4d gmail.com> writes:
On Thursday, 27 February 2014 at 13:07:37 UTC, Mike Parker wrote:

 On 2/27/2014 9:25 PM, Szymon Gatner wrote:


 This is just an example but I would think that it is something 
 rather
 important to have... What about child objects un-registering 
 themselves
 in d-tors from a list that parent object holds and parent is 
 destroyed
 first? What about asynchronous completion handler object that 
 should
 notify some other object that it finished/not finished a job 
 but a
 notifee is already destroyed because application is being 
 shut-down? I
 honestly can't imagine how to reason about object graph 
 lifetimes in GC
 world and I am sure I am missing something very basic. 
 Probably a very
 different mindset.


 Two simple rules I follow.



 resources

 I tend to add two methods to classes that need to do any sort 
 of set up and clean up: initialize and terminate. Then, at app 
 exit, I make sure that the terminate methods are called either 
 with scope(exit) or, if I want to log any exceptions that 
 percolate up to main, try-catch-finally. Something like this:

 class TextureManager {
    private TexContainer _loadedTextures;
    public void initialize() {...}
    public void terminate() {
       foreach( tex; _loadedTextures[])
           tex.terminate();
    }
 }

 struct Game {
      disable this();
      disable this( this );

     private static TextureManager _texMan;

     public static void initialize() {
        _texMan = new TextureManager();
        _texMan.initialize();
     }
     public static void terminate() {
         _texMan.terminate();
     }
 }

 void main() {
    scope( exit ) Game.terminate();
    Game.initialize();
 }

 In some parts of a system, for objects that tend to be short 
 lived, I'll use structs with destructors for RAII. A good 
 example of this is for vertex and fragment shaders. The shader 
 programs are long-lived, so those are classes, but I always 
 destroy the shader objects as soon as any programs that need 
 them are built. So those are perfect candidates for the 
 struct-based RAII approach.

 RAII is a convenient tool, but it's just that, a tool. One of 
 the tradeoffs you have to make with D's GC is that you can't 
 use RAII the same way you do in C++. You *can* use it with 
 structs, but for classes you're going to have to put C++ out of 
 your head.



Then the question is why not use structs all the time?
After using D for a bit more as a week I come to the solution 
that looks like this.

strict WasAClassInCpp
{
     disable this(); //sadly we can not use ctor in D like in C++ 
:(
     disable this(this); //this is not a copy constructor, this is 
something called after all the data in the struct was copied...

   ~this(){ ... }  //dtor, just like in C++
}

So all my classes in C++ are ported to D structs.
I was using class only to port abstract class from C++.
Replacing it by inerface.
Feb 27 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 27 February 2014 at 13:18:51 UTC, Remo wrote:

 Then the question is why not use structs all the time?


Key class feature is run-time polymorphism (via 
interfaces/inheritance). I tend to use structs for everything 
else in my personal code.
Feb 27 2014
next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Thursday, 27 February 2014 at 13:31:45 UTC, Dicebot wrote:

 On Thursday, 27 February 2014 at 13:18:51 UTC, Remo wrote:

 Then the question is why not use structs all the time?


 Key class feature is run-time polymorphism (via 
 interfaces/inheritance). I tend to use structs for everything 
 else in my personal code.


Maybe we really should implement ARC classes... :)
Feb 27 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 27 February 2014 at 13:44:11 UTC, Namespace wrote:

 On Thursday, 27 February 2014 at 13:31:45 UTC, Dicebot wrote:

 On Thursday, 27 February 2014 at 13:18:51 UTC, Remo wrote:

 Then the question is why not use structs all the time?


 Key class feature is run-time polymorphism (via 
 interfaces/inheritance). I tend to use structs for everything 
 else in my personal code.


 Maybe we really should implement ARC classes... :)


I don't see how it is relevant. I would not have used ARC classes 
either.
Feb 27 2014
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Thursday, 27 February 2014 at 14:12:58 UTC, Dicebot wrote:

 On Thursday, 27 February 2014 at 13:44:11 UTC, Namespace wrote:

 On Thursday, 27 February 2014 at 13:31:45 UTC, Dicebot wrote:

 On Thursday, 27 February 2014 at 13:18:51 UTC, Remo wrote:

 Then the question is why not use structs all the time?


 Key class feature is run-time polymorphism (via 
 interfaces/inheritance). I tend to use structs for everything 
 else in my personal code.


 Maybe we really should implement ARC classes... :)


 I don't see how it is relevant. I would not have used ARC 
 classes either.


Why not? Overhead? No RAII support?
Feb 27 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 27 February 2014 at 14:14:43 UTC, Namespace wrote:

 Why not? Overhead? No RAII support?


Simply no reason to use classes, structs have all features I need 
for cases when polymorphism is not necessary (95%+). Being value 
type is also convenient as it leaves more control to the 
programmer and RAII is nice cherry on top.
Feb 27 2014
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 14:18:47 UTC, Dicebot wrote:

 On Thursday, 27 February 2014 at 14:14:43 UTC, Namespace wrote:

 Why not? Overhead? No RAII support?


 Simply no reason to use classes, structs have all features I 
 need for cases when polymorphism is not necessary (95%+). Being 
 value type is also convenient as it leaves more control to the 
 programmer and RAII is nice cherry on top.


They actually don't have all the necessary features in D afaiu. 
They do have value semantics but can't represent uniqueness 
because of missing move d-tor.

For example in C++ I can create a function that returns a Texture 
class instance and be sure that it is the only one when receiving 
it (because copying is disabled). Then I can always safely 
release all resources related to this texture in objects d-tor. 
In D I can't use struct for this because I would get double-free 
in d-tor so a class instance has to be used instead.
Feb 27 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 27 February 2014 at 14:37:14 UTC, Szymon Gatner 
wrote:

 They actually don't have all the necessary features in D afaiu. 
 They do have value semantics but can't represent uniqueness 
 because of missing move d-tor.

 For example in C++ I can create a function that returns a 
 Texture class instance and be sure that it is the only one when 
 receiving it (because copying is disabled). Then I can always 
 safely release all resources related to this texture in objects 
 d-tor. In D I can't use struct for this because I would get 
 double-free in d-tor so a class instance has to be used instead.


You can disable postblit to make entity non-copyable: 
http://dlang.org/struct.html#StructPostblit
Feb 27 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
There is also one complex and feature-reach implementation of 
uniqueness concept by Sonke Ludwig : 
https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/cor
/concurrency.d#L281 
(Isolated!T)

Priceless for message passing concurrency.
Feb 27 2014
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:

 There is also one complex and feature-reach implementation of 
 uniqueness concept by Sonke Ludwig : 
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/cor
/concurrency.d#L281 
 (Isolated!T)

 Priceless for message passing concurrency.


Tbh it only looks worse and worse to me :(

Another example of code necessary to overcome language 
limitations.
Feb 27 2014
next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner 
wrote:

 On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:

 There is also one complex and feature-reach implementation of 
 uniqueness concept by Sonke Ludwig : 
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/cor
/concurrency.d#L281 
 (Isolated!T)

 Priceless for message passing concurrency.


 Tbh it only looks worse and worse to me :(

 Another example of code necessary to overcome language 
 limitations.


Do you know Rust? http://www.rust-lang.org/
Feb 27 2014
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 14:56:22 UTC, Namespace wrote:

 On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner 
 wrote:

 On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:

 There is also one complex and feature-reach implementation of 
 uniqueness concept by Sonke Ludwig : 
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/cor
/concurrency.d#L281 
 (Isolated!T)

 Priceless for message passing concurrency.


 Tbh it only looks worse and worse to me :(

 Another example of code necessary to overcome language 
 limitations.


 Do you know Rust? http://www.rust-lang.org/


I do. Do you want me to go away? ;)
Feb 27 2014
next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Thursday, 27 February 2014 at 15:09:39 UTC, Szymon Gatner 
wrote:

 On Thursday, 27 February 2014 at 14:56:22 UTC, Namespace wrote:

 On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner 
 wrote:

 On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:

 There is also one complex and feature-reach implementation 
 of uniqueness concept by Sonke Ludwig : 
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/cor
/concurrency.d#L281 
 (Isolated!T)

 Priceless for message passing concurrency.


 Tbh it only looks worse and worse to me :(

 Another example of code necessary to overcome language 
 limitations.


 Do you know Rust? http://www.rust-lang.org/


 I do. Do you want me to go away? ;)


No ;) But maybe Rust has your needed features. ;)
If you want to stay at D, you can use the shared and unique 
pointer of Dgame.Internal if you want.
Feb 27 2014
prev sibling parent "Remo" <remo4d gmail.com> writes:
On Thursday, 27 February 2014 at 15:09:39 UTC, Szymon Gatner 
wrote:

 On Thursday, 27 February 2014 at 14:56:22 UTC, Namespace wrote:

 On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner 
 wrote:

 On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:

 There is also one complex and feature-reach implementation 
 of uniqueness concept by Sonke Ludwig : 
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/cor
/concurrency.d#L281 
 (Isolated!T)

 Priceless for message passing concurrency.


 Tbh it only looks worse and worse to me :(

 Another example of code necessary to overcome language 
 limitations.


 Do you know Rust? http://www.rust-lang.org/


 I do. Do you want me to go away? ;)


I have looked at Rust and Go but I still prefer D2 :)
D2  CTFE, templates and mixin are great.
Another advantage of D is the 'easy' porting from C and C++.

But this problems with structs and classes...
I am also missing Rvalue references (move semantics) from C++11.
Feb 27 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Szymon Gatner:


 Tbh it only looks worse and worse to me :(


Perhaps for your use case it's better for you to stick with 
C++11? While I have written a good amount of D code (perhaps 
200_000 lines or more), I still use Python a lot, etc.

Bye,
bearophile
Feb 27 2014
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 14:58:50 UTC, bearophile wrote:

 Szymon Gatner:


 Tbh it only looks worse and worse to me :(


 Perhaps for your use case it's better for you to stick with 
 C++11? While I have written a good amount of D code (perhaps 
 200_000 lines or more), I still use Python a lot, etc.


For now I don'r really see alternative. Isn't resource a 
management a crucial part of everyday programming? Or is it 
really just me?

I do use Python for simple tools and work mainly in C++11(ish as 
it is really just Microsoft's dialect).

Thing is, I really want to use D. I want "Modern convenience", 
"Modeling power" and "Native efficiency". I want to feel like 
home wrt to syntax and at the same time I want for some problems 
to just go away. I think I am just not getting something being so 
deeply rooted in C++.
Feb 27 2014
parent reply "Remo" <remo4d gmail.com> writes:
On Thursday, 27 February 2014 at 15:15:06 UTC, Szymon Gatner 
wrote:

 On Thursday, 27 February 2014 at 14:58:50 UTC, bearophile wrote:

 Szymon Gatner:


 Tbh it only looks worse and worse to me :(


 Perhaps for your use case it's better for you to stick with 
 C++11? While I have written a good amount of D code (perhaps 
 200_000 lines or more), I still use Python a lot, etc.


 For now I don'r really see alternative. Isn't resource a 
 management a crucial part of everyday programming? Or is it 
 really just me?


Resource management is important part, but part but not every 
language handles it the same way.
Apparently some peoples prefers that the language do almost all 
of this by it self no mater how bad/slow it is.


 I do use Python for simple tools and work mainly in C++11(ish 
 as it is really just Microsoft's dialect).


What do you mean by Microsoft's dialect?
Feb 27 2014
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 15:36:02 UTC, Remo wrote:

 What do you mean by Microsoft's dialect?


I mean half-implemented buggy version of C++11 in VC2012 ;)
Feb 27 2014
parent reply "Remo" <remo4d gmail.com> writes:
On Thursday, 27 February 2014 at 15:39:48 UTC, Szymon Gatner 
wrote:

 On Thursday, 27 February 2014 at 15:36:02 UTC, Remo wrote:

 What do you mean by Microsoft's dialect?


 I mean half-implemented buggy version of C++11 in VC2012 ;)


Or in VC2013, but if you can use Intel compiler then it is better.
Feb 27 2014
parent "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 15:56:26 UTC, Remo wrote:

 On Thursday, 27 February 2014 at 15:39:48 UTC, Szymon Gatner 
 wrote:

 On Thursday, 27 February 2014 at 15:36:02 UTC, Remo wrote:

 What do you mean by Microsoft's dialect?


 I mean half-implemented buggy version of C++11 in VC2012 ;)


 Or in VC2013, but if you can use Intel compiler then it is 
 better.


VC2013 at least has variadics... I will not spend another 400 
bucks just for that tho, and only a year after previous release. 
But that is OT ;)
Feb 27 2014
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner 
wrote:

 On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:

 There is also one complex and feature-reach implementation of 
 uniqueness concept by Sonke Ludwig : 
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/cor
/concurrency.d#L281 
 (Isolated!T)

 Priceless for message passing concurrency.


 Tbh it only looks worse and worse to me :(

 Another example of code necessary to overcome language 
 limitations.


Or, alternatively:

A language flexible enough to facilitate library solutions for 
problems that would normally require explicit language support.
Feb 27 2014
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 18:06:58 UTC, John Colvin wrote:

 On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner 
 wrote:

 On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:

 There is also one complex and feature-reach implementation of 
 uniqueness concept by Sonke Ludwig : 
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/cor
/concurrency.d#L281 
 (Isolated!T)

 Priceless for message passing concurrency.


 Tbh it only looks worse and worse to me :(

 Another example of code necessary to overcome language 
 limitations.


 Or, alternatively:

 A language flexible enough to facilitate library solutions for 
 problems that would normally require explicit language support.


I dig flexibility, I really do, and I appreciate D's features 
that enable that, but in case of such basic thing as a resource 
management, I just want things to work without surprises by 
default.
Feb 27 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 27 February 2014 at 18:29:57 UTC, Szymon Gatner 
wrote:

 I dig flexibility, I really do, and I appreciate D's features 
 that enable that, but in case of such basic thing as a resource 
 management, I just want things to work without surprises by 
 default.


Resource management (including memory management) is on of most 
complicated areas in programming. I can call it anything but 
basic.
Feb 28 2014
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Friday, 28 February 2014 at 10:44:22 UTC, Dicebot wrote:

 On Thursday, 27 February 2014 at 18:29:57 UTC, Szymon Gatner 
 wrote:

 I dig flexibility, I really do, and I appreciate D's features 
 that enable that, but in case of such basic thing as a 
 resource management, I just want things to work without 
 surprises by default.


 Resource management (including memory management) is on of most 
 complicated areas in programming. I can call it anything but 
 basic.


I didn't mean "basic" in the sense of "easy" but in the sense of 
something that has to dealt with all the time / is common 
requirement.

"Programs == Algorithms + Data structures" great man once said. D 
is pretty damn good at algorithms part, better than C++ thanks to 
ranges (zero cost composability codegen issues aside) but data 
strucutres... I wish I felt the same way about them.

Is it really so much to ask for? That child's finalizers are 
called before parent finalizer (assuming no circular refs, then 
again there are no weak class refst in D right)? Parent holds 
references to them for crying out loud... Why is that not the 
default and obvious behaviour? Is that a limitation imposed by GC 
somehow? My understanding is that GC has to scan from root to 
leaves so it knows the structure exactly anyway, why not just 
generate finalizer call list when traversing?
Feb 28 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 28 February 2014 at 11:28:01 UTC, Szymon Gatner wrote:

 I didn't mean "basic" in the sense of "easy" but in the sense 
 of something that has to dealt with all the time / is common 
 requirement.


Yes, it needs to be dealt with all the time but in a different 
ways. Problem is with getting sensible defaults. D makes a 
reasonable assumption that most applications don't actually care 
about tight bullet-proof resource management and defaults to GC. 
I may not like it but it fits criteria "built-in resource 
management" and pretty much shows that it is not as basic as one 
may think.


 "Programs == Algorithms + Data structures" great man once said. 
 D is pretty damn good at algorithms part, better than C++ 
 thanks to ranges (zero cost composability codegen issues aside) 
 but data strucutres... I wish I felt the same way about them.


Most problems I have with D data structures come from qualifiers, 
not from resource management. I really don't understand why this 
looks that much of a problem. That said, my background very 
influenced by plain C and that results in different habits and 
expectations.


 Is that a limitation imposed by GC somehow? My understanding is 
 that GC has to scan from root to leaves so it knows the 
 structure exactly anyway, why not just generate finalizer call 
 list when traversing?


Can't tell because of my very limited knowledge about GC 
internals. In practice I don't care because I never ever want to 
interfere with GC resource mangement -  stuff that I want to 
micro-managed is allocated from custom pools and thus is not a 
subject to unexpected destructor calls.
Feb 28 2014
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 2/28/2014 8:43 PM, Dicebot wrote:


 Most problems I have with D data structures come from qualifiers, not
 from resource management. I really don't understand why this looks that
 much of a problem. That said, my background very influenced by plain C
 and that results in different habits and expectations.


I have a strong C background as well and have never had any complaints 
about resource management in D. Every complaint I've seen has come from 
people trying to do C++-like RAII. And, though I don't understand it 
either, it does seem to be a big issue for them.
Feb 28 2014
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Friday, 28 February 2014 at 11:54:52 UTC, Mike Parker wrote:

 On 2/28/2014 8:43 PM, Dicebot wrote:


 Most problems I have with D data structures come from 
 qualifiers, not
 from resource management. I really don't understand why this 
 looks that
 much of a problem. That said, my background very influenced by 
 plain C
 and that results in different habits and expectations.


 I have a strong C background as well and have never had any 
 complaints about resource management in D. Every complaint I've 
 seen has come from people trying to do C++-like RAII. And, 
 though I don't understand it either, it does seem to be a big 
 issue for them.


It really is, RAII is the most important idiom in C++, in short 
no RAII == buggy code. I mean proper C++ not 
C-with-classes-no-templates-no-exceptions bs.

So to sum up: C folks are not really happy, C++ folks are not
Feb 28 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 28 February 2014 at 12:15:21 UTC, Szymon Gatner wrote:

 It really is, RAII is the most important idiom in C++, in short 
 no RAII == buggy code. I mean proper C++ not 
 C-with-classes-no-templates-no-exceptions bs.

 So to sum up: C folks are not really happy, C++ folks are not 



Repeating this again and again - you can use RAII. Just not with 
GC. It is importan idiom and it is supported. But it is not "one 
true way" so it is not supported for everything.
Feb 28 2014
parent "Szymon Gatner" <noemail gmail.com> writes:
On Friday, 28 February 2014 at 12:17:22 UTC, Dicebot wrote:

 On Friday, 28 February 2014 at 12:15:21 UTC, Szymon Gatner 
 wrote:

 It really is, RAII is the most important idiom in C++, in 
 short no RAII == buggy code. I mean proper C++ not 
 C-with-classes-no-templates-no-exceptions bs.

 So to sum up: C folks are not really happy, C++ folks are not 



 Repeating this again and again - you can use RAII. Just not 
 with GC. It is importan idiom and it is supported. But it is 
 not "one true way" so it is not supported for everything.


I know I can, my point is that it is more difficult and I don't 
like it ;)
Feb 28 2014
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 2/28/2014 9:15 PM, Szymon Gatner wrote:


 So to sum up: C folks are not really happy, C++ folks are not really



I'm a C folk and I'm really happy :)
Feb 28 2014
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Friday, 28 February 2014 at 12:48:47 UTC, Mike Parker wrote:

 On 2/28/2014 9:15 PM, Szymon Gatner wrote:


 So to sum up: C folks are not really happy, C++ folks are not 
 really



 I'm a C folk and I'm really happy :)


C'mon, GC has to be an itch for you mallocers :)

Come to the dark side...
Feb 28 2014
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 28 February 2014 at 12:52:28 UTC, Szymon Gatner wrote:

 I'm a C folk and I'm really happy :)




+1


 C'mon, GC has to be an itch for you mallocers :)

 Come to the dark side...


It sometimes is. In that case we don't use GC.

Don't get me wrong - there are issues with current GC enforcement
and it is a major problem for real-time applications, there are
lot of threads with debates on topic (with me acting on
against-the-GC side). But it is a very small subset of
applications most programmers will never even write once in their
life, for everything else existing tools are pretty good.

I really think it is more of C++ architectural habit that itches
you right now :)
Feb 28 2014
prev sibling parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Friday, 28 February 2014 at 11:43:58 UTC, Dicebot wrote:

 On Friday, 28 February 2014 at 11:28:01 UTC, Szymon Gatner 
 wrote:

 I didn't mean "basic" in the sense of "easy" but in the sense 
 of something that has to dealt with all the time / is common 
 requirement.


 Yes, it needs to be dealt with all the time but in a different 
 ways. Problem is with getting sensible defaults. D makes a 
 reasonable assumption that most applications don't actually 
 care about tight bullet-proof resource management and defaults 
 to GC. I may not like it but it fits criteria "built-in 
 resource management" and pretty much shows that it is not as 
 basic as one may think.


Not really different tho. Actual function call swqence might be 
different but the scheme is always the same: acquire resource, 
allocate, connect, take from pool vs release, deallocate, 
disconnect, return to pool. All of those fall under resource 
management - there is a finite amout of a resouce whether it is a 
memory, a system process, a file or a databese connection and it 
is crucial to the system stability that all of them are properly 
returned / released AND in proper order (which is of course 
reverse to "acquisition").
Feb 28 2014
parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 28/02/2014 13:22, Szymon Gatner a écrit :

 On Friday, 28 February 2014 at 11:43:58 UTC, Dicebot wrote:

 On Friday, 28 February 2014 at 11:28:01 UTC, Szymon Gatner wrote:

 I didn't mean "basic" in the sense of "easy" but in the sense of
 something that has to dealt with all the time / is common requirement.


 Yes, it needs to be dealt with all the time but in a different ways.
 Problem is with getting sensible defaults. D makes a reasonable
 assumption that most applications don't actually care about tight
 bullet-proof resource management and defaults to GC. I may not like it
 but it fits criteria "built-in resource management" and pretty much
 shows that it is not as basic as one may think.


 Not really different tho. Actual function call swqence might be
 different but the scheme is always the same: acquire resource, allocate,
 connect, take from pool vs release, deallocate, disconnect, return to
 pool. All of those fall under resource management - there is a finite
 amout of a resouce whether it is a memory, a system process, a file or a
 databese connection and it is crucial to the system stability that all
 of them are properly returned / released AND in proper order (which is
 of course reverse to "acquisition").


I had a lot of difficulties too with the release order of resources. Of 
course I am coming from c++, in which it's to ease to manage.
I got some head-hack for the resource management, maybe a DIP must be 
done here about a module dedicated to the resource management? Or at 
least a tutorial in the wiki?


I finally solve my issues, but I am not happy, cause the way it's done 
seems to be too much error prone (resource leaks).


I used to work on mobile devices and some kind of resources have to be 
released as soon as possible. I also don't really like having a lot of 
applications running on devices never releasing resources, it can break 

applications at the same time, you'll have to buy more memory.
Feb 28 2014
prev sibling parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Thu, 27 Feb 2014 18:29:55 -0000, Szymon Gatner <noemail gmail.com>  
wrote:


 On Thursday, 27 February 2014 at 18:06:58 UTC, John Colvin wrote:

 On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner wrote:

 On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:

 There is also one complex and feature-reach implementation of  
 uniqueness concept by Sonke Ludwig :  
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/cor
/concurrency.d#L281  
 (Isolated!T)

 Priceless for message passing concurrency.


 Tbh it only looks worse and worse to me :(

 Another example of code necessary to overcome language limitations.


 Or, alternatively:

 A language flexible enough to facilitate library solutions for problems  
 that would normally require explicit language support.


 I dig flexibility, I really do, and I appreciate D's features that  
 enable that, but in case of such basic thing as a resource management, I  
 just want things to work without surprises by default.


Amen.  (Not used religiously)

I have been around D for a long time, and I have noticed a growing trend  
of solving problems with "clever" but complicated library solutions when  
in *some* cases a simpler built-in solution was possible.  I realise  
Walter's time is precious and I realise that adding complexity to the  
language itself is something to be generally avoided, but I think  
sometimes we make the wrong choice.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Feb 28 2014
parent "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 28 February 2014 at 10:45:53 UTC, Regan Heath wrote:

 On Thu, 27 Feb 2014 18:29:55 -0000, Szymon Gatner 
 <noemail gmail.com> wrote:


 On Thursday, 27 February 2014 at 18:06:58 UTC, John Colvin 
 wrote:

 On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner 
 wrote:

 On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:

 There is also one complex and feature-reach implementation 
 of uniqueness concept by Sonke Ludwig : 
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/cor
/concurrency.d#L281 
 (Isolated!T)

 Priceless for message passing concurrency.


 Tbh it only looks worse and worse to me :(

 Another example of code necessary to overcome language 
 limitations.


 Or, alternatively:

 A language flexible enough to facilitate library solutions 
 for problems that would normally require explicit language 
 support.


 I dig flexibility, I really do, and I appreciate D's features 
 that enable that, but in case of such basic thing as a 
 resource management, I just want things to work without 
 surprises by default.


 Amen.  (Not used religiously)

 I have been around D for a long time, and I have noticed a 
 growing trend of solving problems with "clever" but complicated 
 library solutions when in *some* cases a simpler built-in 
 solution was possible.  I realise Walter's time is precious and 
 I realise that adding complexity to the language itself is 
 something to be generally avoided, but I think sometimes we 
 make the wrong choice.

 R


Yeah scope -> scoped is IMO such a wrong choice. :)
Feb 28 2014
prev sibling parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 14:41:27 UTC, Dicebot wrote:

 On Thursday, 27 February 2014 at 14:37:14 UTC, Szymon Gatner 
 wrote:

 They actually don't have all the necessary features in D 
 afaiu. They do have value semantics but can't represent 
 uniqueness because of missing move d-tor.

 For example in C++ I can create a function that returns a 
 Texture class instance and be sure that it is the only one 
 when receiving it (because copying is disabled). Then I can 
 always safely release all resources related to this texture in 
 objects d-tor. In D I can't use struct for this because I 
 would get double-free in d-tor so a class instance has to be 
 used instead.


 You can disable postblit to make entity non-copyable: 
 http://dlang.org/struct.html#StructPostblit


How can I then use it as a function return value? Or store in a 
container?

Actually if postblit had a bool param saying that the source is 
rvalue then moving would be possible by just resetting relevant 
fields in source object.
Feb 27 2014
parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 27 February 2014 at 14:49:48 UTC, Szymon Gatner 
wrote:

 You can disable postblit to make entity non-copyable: 
 http://dlang.org/struct.html#StructPostblit


 How can I then use it as a function return value? Or store in a 
 container?

 Actually if postblit had a bool param saying that the source is 
 rvalue then moving would be possible by just resetting relevant 
 fields in source object.


Yep, moving ownership is the main issue (as opposed to just 
prohibiting any copy). But returning from function is not copying 
because of D semantics and you can do some tricks because of it:

http://dpaste.dzfl.pl/99ca668a1a8d

==================================

import std.c.stdlib;

struct Unique
{
	int* data;
	
	 disable this(this);
	
	~this()
	{
		if (data)
			free(data);
	}
	
	Unique release()
	{
		scope(exit) this.data = null;
		return Unique(data);
	}
}

void main()
{
	Unique x1 = Unique(cast(int*) malloc(int.sizeof));
	
	// auto x2 = x1; // error
	auto x2 = x1.release();
	assert(x1.data is null);
	assert(x2.data !is null);
}
Feb 27 2014
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 27 February 2014 at 14:37:14 UTC, Szymon Gatner 
wrote:

 They actually don't have all the necessary features in D afaiu. 
 They do have value semantics but can't represent uniqueness 
 because of missing move d-tor.


struct MovingStruct {
      disable this(this);
     typeof(this) release() {
         auto p = this.payload;
         this.payload = null;
         return typeof(this)(p);
     }
}


That does moving via an explicit release call which is statically 
forced upon you by the disabled copy.

MovingStruct s = some_payload;
// MovingStruct s2 = s; // compile error
MovingStruct s2 = s.release;
assert(s.payload is null); // passes
assert(s2.payload is some_payload); // we good


You can also easily do structs with reference semantics:

struct RefStruct {
     private struct Impl {
       // implementation here
     }
     Impl* payload;
     alias payload this;
}

RefStruct is now just a thin wrapper over a pointer and thus 
inherits the pointer's semantics.

You can add a destructor to RefStruct to free it 
deterministically with RAII as well. To avoid double free, you 
can use the move technique or refcounting:


struct RefCountingStruct {
     private struct Impl {
       // implementation here

       int refcount;
     }
     Impl* payload;
     alias payload this;

      disable this(); // disable default constructor to force 
factory
     static RefCountingStruct create() {
          RefCountingStruct t = void;
          t.payload = new Impl();
          t.payload.refcount = 1;
          return t;
     }
     this(this) { if(payload !is null) payload.refcount++; }
     ~this() {
           if(payload !is null) {
               payload.refcount--;
               if(payload.refcount == 0)
                    whatever_free(payload);
           }
     }
}



i wish my book was out but it is still only half done... but i 
wrote a chapter with like eight different struct tricks like 
this. structs rock.
Feb 27 2014
next sibling parent "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 16:10:34 UTC, Adam D. Ruppe 
wrote:

 On Thursday, 27 February 2014 at 14:37:14 UTC, Szymon Gatner 
 wrote:

 They actually don't have all the necessary features in D 
 afaiu. They do have value semantics but can't represent 
 uniqueness because of missing move d-tor.


 struct MovingStruct {
      disable this(this);
     typeof(this) release() {
         auto p = this.payload;
         this.payload = null;
         return typeof(this)(p);
     }
 }


 That does moving via an explicit release call which is 
 statically forced upon you by the disabled copy.

 MovingStruct s = some_payload;
 // MovingStruct s2 = s; // compile error
 MovingStruct s2 = s.release;
 assert(s.payload is null); // passes
 assert(s2.payload is some_payload); // we good


 You can also easily do structs with reference semantics:

 struct RefStruct {
     private struct Impl {
       // implementation here
     }
     Impl* payload;
     alias payload this;
 }

 RefStruct is now just a thin wrapper over a pointer and thus 
 inherits the pointer's semantics.

 You can add a destructor to RefStruct to free it 
 deterministically with RAII as well. To avoid double free, you 
 can use the move technique or refcounting:


 struct RefCountingStruct {
     private struct Impl {
       // implementation here

       int refcount;
     }
     Impl* payload;
     alias payload this;

      disable this(); // disable default constructor to force 
 factory
     static RefCountingStruct create() {
          RefCountingStruct t = void;
          t.payload = new Impl();
          t.payload.refcount = 1;
          return t;
     }
     this(this) { if(payload !is null) payload.refcount++; }
     ~this() {
           if(payload !is null) {
               payload.refcount--;
               if(payload.refcount == 0)
                    whatever_free(payload);
           }
     }
 }



 i wish my book was out but it is still only half done... but i 
 wrote a chapter with like eight different struct tricks like 
 this. structs rock.


Wow, that is pretty great stuff. Bit verbose, but gets the job 
done. Is there a way to factor it out for reuse? As a mixin 
probably? Thanks! Will surely try this. And I want your book.
Feb 27 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 27 February 2014 at 16:10:34 UTC, Adam D. Ruppe 
wrote:

 struct RefCountingStruct {
     private struct Impl {
       // implementation here

       int refcount;
     }
     Impl* payload;
     alias payload this;



Isn't it exactly what Phobos RefCounted does?
Feb 27 2014
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 27 February 2014 at 17:31:57 UTC, Dicebot wrote:

 Isn't it exactly what Phobos RefCounted does?


Yes, though knowing how the implementation works is good for 
stuff like interfacing with C where you might need different 
acquire/free/add count/release functions than phobos uses.

http://dlang.org/phobos/std_typecons.html#RefCounted

It always uses malloc and free, which isn't always (actually, in 
my cases, is rarely ever) what you want.

It is (obviously) possible to write a generic one that takes 
aliases (or delegates if you want all refcounted things to have 
the same parent type regardless of allocation strategy) for these 
functions, I've done that somewhere on the ng or my http server 
before too, but phobos doesn't do that either.

The phobos one also doesn't let you wrap classes which is 
sometimes useful.
Feb 27 2014
prev sibling parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 13:31:45 UTC, Dicebot wrote:

 On Thursday, 27 February 2014 at 13:18:51 UTC, Remo wrote:

 Then the question is why not use structs all the time?


 Key class feature is run-time polymorphism (via 
 interfaces/inheritance). I tend to use structs for everything 
 else in my personal code.


That is very similar to my thoughts atm. Explicit call to init() 
/ terminate() are so C :/ It really seems that there is no escape 
from value semantics and shared_ptr. Worst part is there is no 
even standard shared/weak pointer provided. I must say I am 
kindof disappointed by all this. I realize that it is not D's 
fault but still, it is suppose to be "better C++", and while I do 
see that wrt to templates / TMP, my favourite feature of C++ are 
d-tors...
Feb 27 2014
parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 27 February 2014 at 14:29:05 UTC, Szymon Gatner 
wrote:

 Explicit call to init() / terminate() are so C :/


It is much better than C because of `scope(exit) terminate()` 
though :)
Also you can use struct destructors same as in C++


 Worst part is there is no even standard shared/weak pointer 
 provided.



which helps in some cases.


 I must say I am kindof disappointed by all this. I realize that 
 it is not D's fault but still, it is suppose to be "better 
 C++", and while I do see that wrt to templates / TMP, my 
 favourite feature of C++ are d-tors...


It is not supposed to be "better C++", not anymore at least. 
Something that dissapoints lot of people and there has been a lot 
of pushing in this direction lately but historically this domain 
was under-developed.
Feb 27 2014