<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 16, 2014 at 11:41 AM, Herb Sutter <span dir="ltr">&lt;<a href="mailto:hsutter@microsoft.com" target="_blank">hsutter@microsoft.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Matt quoted:<u></u><u></u></span></p><div class="im">
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal">&quot;The lifetime of an object of type T begins when:<u></u><u></u></p>
<p class="MsoNormal">— storage with the proper alignment and size for type T is obtained, and<u></u><u></u></p>
<p class="MsoNormal">— if the object has non-trivial initialization, its initialization is complete.&quot;<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
</div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Perhaps the necessary fix is to strike “if the object has non-trivial initialization” here. I don’t see why trivial constructors are special – sure, they don’t
 do anything, but they are notionally important.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">A bag of memory of alignment and size suitable for T is-not-a T object until its (possibly trivial) ctor is called on that memory – it seems wrong for that
 to be true for all T except trivially-constructible T’s (with implicit universal type-punning for all types &lt;= sizeof(T)).</span></p></div></div></blockquote><div><br></div><div>That&#39;s an interesting possibility that I hadn&#39;t considered. It&#39;s definitely appealing in some ways, but I think that it, too, would imply some pretty big surgery in some pretty fundamental parts of the standard. So let&#39;s consider the following code snippet:</div>
<div>  struct MyPOD { int x; }; // 1</div><div>  void* vp = malloc(sizeof(MyPOD)); // 2</div><div>  MyPOD* p1 = static_cast&lt;MyPOD*&gt;(vp); // 3</div><div>  MyPOD* p2 = new MyPOD; // 4</div><div><br></div><div>So the basic question I&#39;d ask is: after line 4, what are you allowed to do with p1 and what are allowed to do with p2, and how do the answers differ? We&#39;ve got a couple of choices.</div>
<div><br></div><div>First choice: we decide that you aren&#39;t allowed to do anything that involves dereferencing p1, since p1 doesn&#39;t point to an object. (No object&#39;s lifetime has begun in line 2 or line 3. I find that unappealing. I don&#39;t think it&#39;s the status quo, either in the standard&#39;s text, or in what compilers do, or in what programmers expect. If we forbade it and compiler implementers took us seriously, it would break the world.</div>
<div><br></div><div>Second choice: we decide that you&#39;re allowed to do just the same things with p1 as you are with p2. (Except, of course, that you&#39;re required to free p1 versus deleting p2.) So *p2 is an object and *p1 isn&#39;t, but you&#39;re allowed to use *p1 as if it was an object.</div>
<div><br></div><div>One consequence of the second choice: we&#39;d need to go through the standard and make sure that the words actually say what we want. I bet we don&#39;t currently have the notion of a contiguous region of storage that isn&#39;t an object of type MyPOD but can be used as if it was an object of type MyPOD. And, of course, we&#39;d probably have to figure out what the difference is between an actual object of type MyPOD and a region of storage that isn&#39;t an object but is allowed to be used as if it was an object: if there isn&#39;t any difference between the two concepts then it&#39;s a little less clear why we need both of them.</div>
<div><br></div><div>I&#39;m still leaning toward thinking that, after line 4, both *p1 and *p2 are objects of type MyPOD. I don&#39;t know how the standard should say that, though. Some change, somewhere, seems called for.</div>
<div><br></div><div>                          --Matt</div><div><br></div></div></div></div>