<br><br><div class="gmail_quote">2013/3/8 Johannes Pfau <span dir="ltr"><<a href="mailto:johannespfau@googlemail.com" target="_blank">johannespfau@googlemail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Am 08.03.2013 05:52, schrieb Maxim
Fomin:<br>
</div><div><div class="h5">
<blockquote type="cite"><br>
<br>
<div class="gmail_quote">2013/3/8 Walter Bright <span dir="ltr"><<a href="mailto:walter@digitalmars.com" target="_blank">walter@digitalmars.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On 3/7/2013 12:19 PM, Johannes Pfau wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 07.03.2013 20:45, schrieb Walter Bright:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 3/7/2013 9:36 AM, Johannes Pfau wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm sorry I have to pester you with this again, but I
still have some questions regarding POD types and I'd
like to fix this in GDC.<br>
<br>
So from last discussion:<br>
>> Wouldn't it be legal to still pass non-PODs
in registers when calling functions and only copying
them back to<br>
>> the stack if the address is needed? As we
pass structs by value anyway, how could this be
problematic?<br>
><br>
> No, not allowed. Consider why there are copy
constructors, and what they do.<br>
<br>
I compiled some test programs with dmd and dmd _does_
pass non-POD values in registers as I suggested above.<br>
See this example:<br>
<a href="https://gist.github.com/jpf91/5064703" target="_blank">https://gist.github.com/jpf91/5064703</a>
(D)<br>
<a href="https://gist.github.com/jpf91/5064764" target="_blank">https://gist.github.com/jpf91/5064764</a>
(ASM)<br>
</blockquote>
<br>
That's because objects with constructors are now
regarded as POD.<br>
</blockquote>
<br>
This example uses a postblit to make sure the type is not
a POD. It's obvious in the ASM that the copy ctor is
called,<br>
</blockquote>
<br>
</div>
Oops, I missed that. It's a bug in dmd.<br>
</blockquote>
</div>
<br>
Isn't there another bug with struct parameter which is copied
twice - on caller and callee side?<br>
<br>
function D main<br>
Date d = _D1e4Date6__initZ;<br>
setDate((Date __cpcttmp7 = __cpcttmp7.__cpctor(d); , __cpcttmp7))<br>
<br>
function e.setDate<br>
x.opAssign((Date __cpcttmp6 = __cpcttmp6.__cpctor(d); ,
__cpcttmp6))<br>
<br>
</blockquote></div></div>
setDate assigns d to the global variable x so the second call to the
cpctor seems to be caused by that and valid.<span class="HOEnZb"><font color="#888888"><br>
<pre cols="72">--
Johannes Pfau</pre>
</font></span></div><br></blockquote></div>DMD still generates double copy if variable is changed to local<br><br>void setDate(Date d)<br>{<br>Date x;<br>x = d;<br>}<br><br>function e.setDate<br>Date x = _D1e4Date6__initZ;<br>
x.opAssign((Date __cpcttmp6 = __cpcttmp6.__cpctor(d); , __cpcttmp6))<br><br>function D main<br>Date d = _D1e4Date6__initZ;<br>setDate((Date __cpcttmp7 = __cpcttmp7.__cpctor(d); , __cpcttmp7))<br><br>Anyway whether variable is tls or not is irrelevant. Compiler should not make a copy when assigning. <br>