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

[Howard Hinnant via cfe-dev]

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.

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 at __1@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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160516/82616146/attachment.sig>