<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 16, 2016 at 4:15 PM, Howard Hinnant via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><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">It has been a long time since I wrote this code, but at the time I was able to convince myself that the libc++ initialization of global statics would happen prior other statics programmed by the customer.  At that time, libc++ was being written just for OS X.<br></blockquote><div><br></div><div><br></div><div>I don't think this holds any longer, including on OS X. I know it doesn't hold for things linked in statically (ie libc++experimental). However the alternative is to emit a static construction in every TU that include <iostream> (<a href="http://llvm.org/docs/CodingStandards.html#include-iostream-is-forbidden">http://llvm.org/docs/CodingStandards.html#include-iostream-is-forbidden</a>). I would be pretty unwilling to make that change until *not* doing it becomes a large issue.</div><div><br></div><div>One alternative to using char[] arrays to prevent destruction would be to use a C++11 union with an empty destructor. That could be a possible implementation for Windows.</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">
<br>
Howard<br>
<div class=""><div class="h5"><br>
On May 16, 2016, at 6:02 PM, Yi-Hong Lyu <<a href="mailto:b95705030@ntu.edu.tw">b95705030@ntu.edu.tw</a>> wrote:<br>
><br>
> Hello Jon & Howard,<br>
><br>
> Thanks for your reply. I took a look of C++ specification. It mentioned constructors and destructors for static objects can access these objects (cin/cout/cerr) to read input from stdin or write output to stdout or stderr. As far as I know, cin/cout/cerr is initialized by the constructor of __start_std_streams under src/iostream.cpp. I am wondering how libcxx guarantee ios_base::Init::Init() would be invoked before execution of constructor of any other static objects? Is there any potential 'static initialization order fiasco' issue?<br>
><br>
> Thanks for your help,<br>
> Yi-Hong<br>
><br>
> 2016-05-17 3:54 GMT+08:00 Howard Hinnant via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>>:<br>
> On May 16, 2016, at 2:12 PM, Yi-Hong Lyu via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> ><br>
> > Hello all,<br>
> ><br>
> > I am porting libcxx to Windows (not mingw). I am curious about the design of (w)cin/(w)cout/(w)cout. Currently we define (w)cin/(w)cout/(w)cout as char[] under src/iostream.cpp and initialise them as istream/ostream in function ios_base::Init::Init(). Why don't we defined them as istream/ostream object directly? The drawback of current design in my mind is that cause linking error under Windows. Windows mangler takes data type into account. Reference of std::cin would be translated into ?cin@__1@std@@3V?$basic_istream@DU?$char_traits@D@__1@std@@@12@A (class std::__1::basic_istream<char,struct std::__1::char_traits<char> > std::__1::cin). Definition of std::cin, in contrast, would be translated into ?cin@__1@std@@3PADA (char * std::__1::cin). There is a linking error because two symbols are different.<br>
> ><br>
> > Any suggestion or comment is appreciated,<br>
><br>
> This was done because the standard forbids the destruction of these objects in the atexit chain.<br>
><br>
> Howard<br>
><br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">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>
><br>
><br>
<br>
</div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">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>
<br></blockquote></div><br></div></div>