On 12/29/2012 4:38 AM, Jacob Carlborg wrote:
> On 2012-12-29 00:53, Andrej Mitrovic wrote:
>
>> I suggest we implement a compiler trait via __traits(isPOD, Type).
>> C++11 has is_pod, D should have a Phobos template that wraps around
>> the new trait.
>
> Do we need a new trait, can't this be done in pure D?

Yes for a new trait, for the reasons:

1. POD status is affected by a number of characteristics. This would all have to be rather carefully done to ensure an exact match with the compiler.

2. There are many discussions here about changing the definition of POD. The likelihood of changing the compiler, and then neglecting to change the Phobos version or not updating the Phobos version correctly is high.

On Saturday, 29 December 2012 at 01:53:15 UTC, David Nadlinger wrote:
>  - There are also possible performance implications: Structs that just wrap a single field in order to enrich it with type information, such as Duration or a Quantity struct from a units of measurement library, will likely benefit from being passed in registers (if available), even if they will probably have constructors. In fact, having such one-field structs behave like a naked value might be vitally important to be able to decorate a C API with e.g. units information (even if such code would strictly speaking be architecture dependent).
>
> As far as I can see – and I'm merely guessing based on the isPOD comment here – the only reason for not just applying the C/C++ definition in the obvious way might be a quirk in the DMD backend implementation?

I had started but never finished such a wrapping struct for units, and I gave it another try recently (https://github.com/biozic/siunits).

Clearly, when using POD structs, the code of the function 'quality' in examples/rlc.d, executes way more rapidly (5x) than using non-POD structs. The only difference between POD and non-POD in my tests is the presence of non-default constructors, which is versioned out in the POD version.

Code of the quality function with POD struct (compiled with -O -inline -release):
---
		push	RBP
		mov	RBP,RSP
		fld	tbyte ptr 020h[RBP]
		fld	tbyte ptr 010h[RBP]
		fld	tbyte ptr [0FFFFE77Ch][RIP]
		fmulp	ST(1),ST
		fld	tbyte ptr 030h[RBP]
		fmulp	ST(1),ST
		fdivp	ST(1),ST
		pop	RBP
		ret
---

Same code with the non POD version (same compiler flags):
---
		push	RBP
		mov	RBP,RSP
		sub	RSP,0B0h
		mov	RSI,[00h][RIP]
		lea	RDI,-040h[RBP]
		movsd
		movsd
		fld	tbyte ptr [0FFFFE5C4h][RIP]
		fstp	tbyte ptr -040h[RBP]
		mov	word ptr -036h[RBP],0
		mov	dword ptr -034h[RBP],0
		lea	RSI,-040h[RBP]
		lea	RDI,-050h[RBP]
		movsd
		movsd
		lea	RSI,-050h[RBP]
		lea	RDI,-060h[RBP]
		movsd
		movsd
		mov	RSI,[00h][RIP]
		lea	RDI,-030h[RBP]
		movsd
		movsd
		fld	tbyte ptr 010h[RBP]
		fld	tbyte ptr -060h[RBP]
		fmulp	ST(1),ST
		fstp	tbyte ptr -030h[RBP]
		mov	word ptr -026h[RBP],0
		mov	dword ptr -024h[RBP],0
		lea	RSI,-030h[RBP]
		lea	RDI,-070h[RBP]
		movsd
		movsd
		lea	RSI,-070h[RBP]
		lea	RDI,-080h[RBP]
		movsd
		movsd
		mov	RSI,[00h][RIP]
		lea	RDI,-020h[RBP]
		movsd
		movsd
		fld	tbyte ptr 030h[RBP]
		fld	tbyte ptr -080h[RBP]
		fmulp	ST(1),ST
		fstp	tbyte ptr -020h[RBP]
		mov	word ptr -016h[RBP],0
		mov	dword ptr -014h[RBP],0
		lea	RSI,-020h[RBP]
		lea	RDI,-090h[RBP]
		movsd
		movsd
		lea	RSI,-090h[RBP]
		lea	RDI,-0A0h[RBP]
		movsd
		movsd
		mov	RSI,[00h][RIP]
		lea	RDI,-010h[RBP]
		movsd
		movsd
		fld	tbyte ptr 020h[RBP]
		fld	tbyte ptr -0A0h[RBP]
		fdivp	ST(1),ST
		fstp	tbyte ptr -010h[RBP]
		mov	word ptr -6[RBP],0
		mov	dword ptr -4[RBP],0
		lea	RSI,-010h[RBP]
		lea	RDI,-0B0h[RBP]
		movsd
		movsd
		fld	tbyte ptr -0B0h[RBP]
		mov	RSP,RBP
		pop	RBP
		ret
---

I will use such a library in an environment that is not performance critical. But I hope that this will eventually be optimized.

Thanks,
Nicolas

On 1/14/2013 11:24 AM, Nicolas Sicard wrote:
> I had started but never finished such a wrapping struct for units, and I gave it
> another try recently (https://github.com/biozic/siunits).
>
> Clearly, when using POD structs, the code of the function 'quality' in
> examples/rlc.d, executes way more rapidly (5x) than using non-POD structs. The
> only difference between POD and non-POD in my tests is the presence of
> non-default constructors, which is versioned out in the POD version.
>
> Code of the quality function with POD struct (compiled with -O -inline -release):

Please make a bugzilla entry with this. Thanks!

On Monday, 14 January 2013 at 21:18:13 UTC, Walter Bright wrote:
> On 1/14/2013 11:24 AM, Nicolas Sicard wrote:
>> I had started but never finished such a wrapping struct for units, and I gave it
>> another try recently (https://github.com/biozic/siunits).
>>
>> Clearly, when using POD structs, the code of the function 'quality' in
>> examples/rlc.d, executes way more rapidly (5x) than using non-POD structs. The
>> only difference between POD and non-POD in my tests is the presence of
>> non-default constructors, which is versioned out in the POD version.
>>
>> Code of the quality function with POD struct (compiled with -O -inline -release):
>
> Please make a bugzilla entry with this. Thanks!

Done: http://d.puremagic.com/issues/show_bug.cgi?id=9320

English is not my mother language, so I hope the summary is OK.

On 1/14/2013 2:10 PM, Nicolas Sicard wrote:
> English is not my mother language, so I hope the summary is OK.

Not to worry. I work with lots of ESL engineers, and your English is excellent.

On Saturday, 29 December 2012 at 14:24:41 UTC, Andrei Alexandrescu wrote:
> On 12/29/12 4:03 AM, Dmitry Olshansky wrote:
>> P.S. I'm starting to hate the special nature of struct constructors:
>> they can't have 0-arguments, now they disallow POD, what next?
>
> Yes, constructors should not influence the POD-ness of data; only postblits should.
>
> Andrei

Default constructor may (even if they are not allowed, they may when disabled, which is allowed).