<div dir="ltr"><div dir="ltr"><div>Kostya,</div><div dir="ltr">It sounds like the current approach is utterly conservative: if it sees a call to a constructor in a different translation unit (TU), then it won't assume anything about that constructor's behavior. (For all we know, that constructor's TU might have been compiled without the zero-init flag.)</div><div dir="ltr"><div>This can lead to O(N) redundant initializations:<br></div><div><br></div><div> struct A { A(); int i; };</div><div> struct B : A { B(); };</div><div> struct C : B { C(); };</div><div> // The TU that defines A::A() will initialize `i`.</div><div> // The TU that defines B::B() can't see that `i` will be initialized by A::A(), so it redundantly initializes `i`.</div><div><div> // The TU that defines C::C() can't see that `i` will be initialized by A::A() or B::B(), so it redundantly initializes `i`.</div></div><div><br></div><div>However, this is all because of the current conservative approach, where our TU-compiled-with-zero-init must assume that other TUs were perhaps <i>not</i> compiled with zero-init.</div><div>Richard is saying that you could instead make zero-init an all-or-nothing proposition. Then, B::B() would say "I don't see the definition of A::A() yet, but, since I am being compiled with zero-init, I will assume that that other TU is also going to be compiled with zero-init. So `i` <i>will</i> be initialized; so therefore I don't have to initialize it myself." And so all the redundant initializations would disappear.</div><div><br></div><div>If it later turned out that the TU containing A::A() had not been compiled with zero-init... well, then `i` might remain uninitialized. But so might any variable that began its life in that other TU. So I don't think there's any philosophical problem there.</div><div><br></div><div>I think the "all-or-nothing" approach is probably the right approach. Let each constructor worry about initializing its data members. Don't second-guess the constructor just because you can't see its definition.</div><div><br></div><div>HTH,</div><div>–Arthur</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 16, 2019 at 10:58 PM Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Wed, 16 Jan 2019, 19:35 Kostya Serebryany via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><br><br></div><div dir="auto">Should main be involved, though? </div></div></blockquote><div><br></div><div>How else?</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">By putting the initialisation where it belongs, in the constructor.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>main() creates a local variable on stack and passes it's address to a CTOR, that (in general case) is unknown at the point where we insert initialization. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">It's normally the job of the constructor to initialize the class members, and that's where the information about whether the members are uninitialised lives.</div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div><br></div></div></div></div></div></div></div></div></div></blockquote></div></div></blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>