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

[Yi-Hong Lyu via cfe-dev]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160517/98ae4910/attachment.html>