www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Direct access to struct construction, copying and destruction

reply Benjamin Thaut <code benjamin-thaut.de> writes:
While writing certain parts of my own little standard library 
(containers etc) I had to notice that D has a overcomplicated way of 
especially postblitting and destructing structs. By overcomplicated I 
mean that you don't have any other choice but to go through a TypeInfo 
object to the process correctly.

Postblitting:
If the struct has a postblit constructor you can directly call 
__postblit but if it does not have one, you have to go over the TypeInfo 
object to call __fieldPostBlit which is not directly exposed.

Destruction:
Pretty mutch the same situation as for postblitting. If it has a own 
destructor you can call __dtor, but if not you have to use the typeinfo 
object to call the destructor because the appropirate destructor is not 
directly exposed.

I find this strange because having to go through a TypeInfo object, 
which is a lot of unneccessary indirections for calling a function that 
is known at compile time and could even be inlined if it would be called 
directly, seems totaly overkill to me.

I would find it extremly usefull for low level code (unsafe of course) 
to have 3 simple functions that do the following:

cpctor: if present struct needs to be copy constructed, always calls the 
correct copy constructor

postblit: if present the struct needs to be postblit constructed, calls 
__postblit if the struct has a own postblit constructor, otherwise it 
calls __fieldPostBlit

dtor: if present the struct needs to be destructed. Calls the 
appropriate destructor.

This would give a better low level control over struct construction and 
destruction and would allow compilers to inline the functions if 
appropriate.

If some or all of the above is wrong, I'm going to look forward to 
beeing corrected.

Kind Regards
Benjamin Thaut
Jul 08 2012
next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
No one has a opinion on this?
Jul 09 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/09/2012 06:15 PM, Benjamin Thaut wrote:
 No one has a opinion on this?

The features should obviously be exposed. I was astonished that __postblit does not work if there is no explicit postblit defined.
Jul 09 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Sunday, July 08, 2012 15:23:41 Benjamin Thaut wrote:
 While writing certain parts of my own little standard library
 (containers etc) I had to notice that D has a overcomplicated way of
 especially postblitting and destructing structs. By overcomplicated I
 mean that you don't have any other choice but to go through a TypeInfo
 object to the process correctly.
 
 Postblitting:
 If the struct has a postblit constructor you can directly call
 __postblit but if it does not have one, you have to go over the TypeInfo
 object to call __fieldPostBlit which is not directly exposed.
 
 Destruction:
 Pretty mutch the same situation as for postblitting. If it has a own
 destructor you can call __dtor, but if not you have to use the typeinfo
 object to call the destructor because the appropirate destructor is not
 directly exposed.
 
 I find this strange because having to go through a TypeInfo object,
 which is a lot of unneccessary indirections for calling a function that
 is known at compile time and could even be inlined if it would be called
 directly, seems totaly overkill to me.
 
 I would find it extremly usefull for low level code (unsafe of course)
 to have 3 simple functions that do the following:
 
 cpctor: if present struct needs to be copy constructed, always calls the
 correct copy constructor
 
 postblit: if present the struct needs to be postblit constructed, calls
 __postblit if the struct has a own postblit constructor, otherwise it
 calls __fieldPostBlit
 
 dtor: if present the struct needs to be destructed. Calls the
 appropriate destructor.
 
 This would give a better low level control over struct construction and
 destruction and would allow compilers to inline the functions if
 appropriate.
 
 If some or all of the above is wrong, I'm going to look forward to
 beeing corrected.

For destruction, I believe that clear (or destroy on git master) takes care of it, but the rest of it is definitely a problem - though since all of that information lives in TypeInfo, I'd expect your three proposed functions to just be using TypeInfo, which doesn't really help your complaint about indirections (though the compiler may still have enough information there to be able to inline appropriately). - Jonathan M Davis
Jul 09 2012
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 09.07.2012 19:36, schrieb Jonathan M Davis:
 On Sunday, July 08, 2012 15:23:41 Benjamin Thaut wrote:
 While writing certain parts of my own little standard library
 (containers etc) I had to notice that D has a overcomplicated way of
 especially postblitting and destructing structs. By overcomplicated I
 mean that you don't have any other choice but to go through a TypeInfo
 object to the process correctly.

 Postblitting:
 If the struct has a postblit constructor you can directly call
 __postblit but if it does not have one, you have to go over the TypeInfo
 object to call __fieldPostBlit which is not directly exposed.

 Destruction:
 Pretty mutch the same situation as for postblitting. If it has a own
 destructor you can call __dtor, but if not you have to use the typeinfo
 object to call the destructor because the appropirate destructor is not
 directly exposed.

 I find this strange because having to go through a TypeInfo object,
 which is a lot of unneccessary indirections for calling a function that
 is known at compile time and could even be inlined if it would be called
 directly, seems totaly overkill to me.

 I would find it extremly usefull for low level code (unsafe of course)
 to have 3 simple functions that do the following:

 cpctor: if present struct needs to be copy constructed, always calls the
 correct copy constructor

 postblit: if present the struct needs to be postblit constructed, calls
 __postblit if the struct has a own postblit constructor, otherwise it
 calls __fieldPostBlit

 dtor: if present the struct needs to be destructed. Calls the
 appropriate destructor.

 This would give a better low level control over struct construction and
 destruction and would allow compilers to inline the functions if
 appropriate.

 If some or all of the above is wrong, I'm going to look forward to
 beeing corrected.

For destruction, I believe that clear (or destroy on git master) takes care of it, but the rest of it is definitely a problem - though since all of that information lives in TypeInfo, I'd expect your three proposed functions to just be using TypeInfo, which doesn't really help your complaint about indirections (though the compiler may still have enough information there to be able to inline appropriately). - Jonathan M Davis

Clear uses the TypeInfo. The proposed functions should not be library functions but directly aviable from the compiler. Something like __postblit and __dtor but properly implemented. Kind Regards Benjamin Thaut
Jul 09 2012
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 10.07.2012 00:53, schrieb Jonathan M Davis:
 On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
 Clear uses the TypeInfo. The proposed functions should not be library
 functions but directly aviable from the compiler. Something like
 __postblit and __dtor but properly implemented.

Well, since all of the necessary information is in the TypeInfo, not in the type itself, I don't see how you're going to do that. As I understand it, it's not the compiler that deals with all of that. It's druntime. So, without a major redesign, there's no way that the compiler is going to generate that stuff for you. That's druntime's job. - Jonathan M Davis

So who fills the TypeInfo objects, the runtime? I always assumed that the compiler fills the TypeInfo and therefor has all the neccessary information already at hand. Kind Regards Benjamin Thaut
Jul 09 2012
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 10.07.2012 07:13, schrieb Jonathan M Davis:
 On Tuesday, July 10, 2012 06:53:29 Benjamin Thaut wrote:
 Am 10.07.2012 00:53, schrieb Jonathan M Davis:
 On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
 Clear uses the TypeInfo. The proposed functions should not be library
 functions but directly aviable from the compiler. Something like
 __postblit and __dtor but properly implemented.

Well, since all of the necessary information is in the TypeInfo, not in the type itself, I don't see how you're going to do that. As I understand it, it's not the compiler that deals with all of that. It's druntime. So, without a major redesign, there's no way that the compiler is going to generate that stuff for you. That's druntime's job. - Jonathan M Davis

So who fills the TypeInfo objects, the runtime? I always assumed that the compiler fills the TypeInfo and therefor has all the neccessary information already at hand.

I don't know the details, but as I understand it, all of the logic for actually copying and destroying things properly is in druntime. The compiler doesn't do any of that. That being the case, any code which wants to use a type's postblit or destructor needs to use druntime. Right now, I believe that the compiler just uses hooks into the druntime code like it does with stuff like new and AAs. So, to skip using the druntime functions to properly copy or destroy an object, the compiler would have to duplicate the logic which currently resides in druntime. - Jonathan M Davis

Thats fine, I don't want the compiler to duplicate that logic. I just want the compiler to expose all the neccessary function that are provided by the compiler anyway so *I* can duplicate the logic from D-Runtime *without* going over a TypeInfo Object. Kind Regards Benjamin Thaut
Jul 11 2012
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 11.07.2012 09:33, schrieb Jonathan M Davis:
 On Wednesday, July 11, 2012 09:28:15 Benjamin Thaut wrote:
 Am 10.07.2012 07:13, schrieb Jonathan M Davis:
 On Tuesday, July 10, 2012 06:53:29 Benjamin Thaut wrote:
 Am 10.07.2012 00:53, schrieb Jonathan M Davis:
 On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
 Clear uses the TypeInfo. The proposed functions should not be library
 functions but directly aviable from the compiler. Something like
 __postblit and __dtor but properly implemented.

Well, since all of the necessary information is in the TypeInfo, not in the type itself, I don't see how you're going to do that. As I understand it, it's not the compiler that deals with all of that. It's druntime. So, without a major redesign, there's no way that the compiler is going to generate that stuff for you. That's druntime's job. - Jonathan M Davis

So who fills the TypeInfo objects, the runtime? I always assumed that the compiler fills the TypeInfo and therefor has all the neccessary information already at hand.

I don't know the details, but as I understand it, all of the logic for actually copying and destroying things properly is in druntime. The compiler doesn't do any of that. That being the case, any code which wants to use a type's postblit or destructor needs to use druntime. Right now, I believe that the compiler just uses hooks into the druntime code like it does with stuff like new and AAs. So, to skip using the druntime functions to properly copy or destroy an object, the compiler would have to duplicate the logic which currently resides in druntime. - Jonathan M Davis

Thats fine, I don't want the compiler to duplicate that logic. I just want the compiler to expose all the neccessary function that are provided by the compiler anyway so *I* can duplicate the logic from D-Runtime *without* going over a TypeInfo Object.

Then look over TypeInfo and see what it does. It may be possible to just duplicate what it's doing. I don't know. Certainly, TypeInfo is used by druntime to do the postblits and destructors, so even the compiler is using TypeInfo for doing that. - Jonathan M Davis

I already now what type info does, it does nothing. The compiler fills in the xpostblit and xdtor fields of the TypeInfo_Struct with the correct function pointers to postblit or destruct functions. These fields always contain the correct function to call. But the __postblit and __dtor funtions that are directly callable on the struct itself, are only correct if there is a explicit destructor / postblit constructor defined. So it shouldn't be much of a problem to also expose the __fielddtor and __fieldpostblit functions that get filled into the TypeInfo_Struct object anyway. Kind Regards Benjamin Thaut
Jul 11 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
 Clear uses the TypeInfo. The proposed functions should not be library
 functions but directly aviable from the compiler. Something like
 __postblit and __dtor but properly implemented.

Well, since all of the necessary information is in the TypeInfo, not in the type itself, I don't see how you're going to do that. As I understand it, it's not the compiler that deals with all of that. It's druntime. So, without a major redesign, there's no way that the compiler is going to generate that stuff for you. That's druntime's job. - Jonathan M Davis
Jul 09 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, July 10, 2012 06:53:29 Benjamin Thaut wrote:
 Am 10.07.2012 00:53, schrieb Jonathan M Davis:
 On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
 Clear uses the TypeInfo. The proposed functions should not be library
 functions but directly aviable from the compiler. Something like
 __postblit and __dtor but properly implemented.

Well, since all of the necessary information is in the TypeInfo, not in the type itself, I don't see how you're going to do that. As I understand it, it's not the compiler that deals with all of that. It's druntime. So, without a major redesign, there's no way that the compiler is going to generate that stuff for you. That's druntime's job. - Jonathan M Davis

So who fills the TypeInfo objects, the runtime? I always assumed that the compiler fills the TypeInfo and therefor has all the neccessary information already at hand.

I don't know the details, but as I understand it, all of the logic for actually copying and destroying things properly is in druntime. The compiler doesn't do any of that. That being the case, any code which wants to use a type's postblit or destructor needs to use druntime. Right now, I believe that the compiler just uses hooks into the druntime code like it does with stuff like new and AAs. So, to skip using the druntime functions to properly copy or destroy an object, the compiler would have to duplicate the logic which currently resides in druntime. - Jonathan M Davis
Jul 09 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, July 11, 2012 09:28:15 Benjamin Thaut wrote:
 Am 10.07.2012 07:13, schrieb Jonathan M Davis:
 On Tuesday, July 10, 2012 06:53:29 Benjamin Thaut wrote:
 Am 10.07.2012 00:53, schrieb Jonathan M Davis:
 On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
 Clear uses the TypeInfo. The proposed functions should not be library
 functions but directly aviable from the compiler. Something like
 __postblit and __dtor but properly implemented.

Well, since all of the necessary information is in the TypeInfo, not in the type itself, I don't see how you're going to do that. As I understand it, it's not the compiler that deals with all of that. It's druntime. So, without a major redesign, there's no way that the compiler is going to generate that stuff for you. That's druntime's job. - Jonathan M Davis

So who fills the TypeInfo objects, the runtime? I always assumed that the compiler fills the TypeInfo and therefor has all the neccessary information already at hand.

I don't know the details, but as I understand it, all of the logic for actually copying and destroying things properly is in druntime. The compiler doesn't do any of that. That being the case, any code which wants to use a type's postblit or destructor needs to use druntime. Right now, I believe that the compiler just uses hooks into the druntime code like it does with stuff like new and AAs. So, to skip using the druntime functions to properly copy or destroy an object, the compiler would have to duplicate the logic which currently resides in druntime. - Jonathan M Davis

Thats fine, I don't want the compiler to duplicate that logic. I just want the compiler to expose all the neccessary function that are provided by the compiler anyway so *I* can duplicate the logic from D-Runtime *without* going over a TypeInfo Object.

Then look over TypeInfo and see what it does. It may be possible to just duplicate what it's doing. I don't know. Certainly, TypeInfo is used by druntime to do the postblits and destructors, so even the compiler is using TypeInfo for doing that. - Jonathan M Davis
Jul 11 2012
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 11 Jul 2012 04:21:29 -0400, Benjamin Thaut  
<code benjamin-thaut.de> wrote:

 I already now what type info does, it does nothing.
 The compiler fills in the xpostblit and xdtor fields of the  
 TypeInfo_Struct with the correct function pointers to postblit or  
 destruct functions. These fields always contain the correct function to  
 call. But the __postblit and __dtor funtions that are directly callable  
 on the struct itself, are only correct if there is a explicit destructor  
 / postblit constructor defined. So it shouldn't be much of a problem to  
 also expose the __fielddtor and __fieldpostblit functions that get  
 filled into the TypeInfo_Struct object anyway.

Also see this: http://d.puremagic.com/issues/show_bug.cgi?id=5667 -Steve
Aug 23 2012