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

[Howard Hinnant via cfe-dev]

On May 16, 2016, at 9:58 PM, Eric Fiselier <eric at efcs.ca> wrote:
> 
> 
> 
> 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.

Interesting.

> I know it doesn't hold for things linked in statically (ie libc++experimental).

Agreed.  At the time I made this decision, I was consciously deciding that OS X would have only a dylib std::lib option.

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

At the time, Apple was (and almost certainly still is) allergic to namespace scope statics requiring dynamic initialization.  By moving __start_std_streams into a source, as opposed to its traditional place in a header, I reduced the number of namespace scope statics associated with <iostream> from once per inclusion to only one for linking against the std::lib.  This was a deliberate design choice to deal with Apple’s allergies.

I have no strong opinion on if, when or where this design decision should be reversed.  I’m merely documenting the rationale that I used in case that is helpful.

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

That sounds interesting.  Another option is a clean-sheet optimal implementation for each platform separated out with #if.  It isn’t that much code.

Howard

> 
> 
> 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
> >
> >
> 
> 
> _______________________________________________
> 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/d1dd7af1/attachment.sig>