[cfe-dev] [libcxx] Why the type of (w)cin/(w)cout/(w)cout are char []?

Eric Fiselier via cfe-dev cfe-dev at lists.llvm.org
Mon May 16 18:58:59 PDT 2016


On Mon, May 16, 2016 at 4:15 PM, Howard Hinnant via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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.
>


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> (
http://llvm.org/docs/CodingStandards.html#include-iostream-is-forbidden). I
would be pretty unwilling to make that change until *not* doing it becomes
a large issue.

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.


>
> Howard
>
> On May 16, 2016, at 6:02 PM, Yi-Hong Lyu <b95705030 at ntu.edu.tw> wrote:
> >
> > Hello Jon & Howard,
> >
> > 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?
> >
> > Thanks for your help,
> > Yi-Hong
> >
> > 2016-05-17 3:54 GMT+08:00 Howard Hinnant via cfe-dev <
> cfe-dev at lists.llvm.org>:
> > On May 16, 2016, at 2:12 PM, Yi-Hong Lyu via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> > >
> > > Hello all,
> > >
> > > 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 at std@@3V?$basic_istream at DU?$char_traits at D@__1 at std@@@12 at 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 at __1@std@@3PADA (char * std::__1::cin). There is a linking error
> because two symbols are different.
> > >
> > > Any suggestion or comment is appreciated,
> >
> > This was done because the standard forbids the destruction of these
> objects in the atexit chain.
> >
> > Howard
> >
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> >
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160516/2fb86459/attachment.html>


More information about the cfe-dev mailing list