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 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 "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
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 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
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 reply 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
parent reply 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
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