<div dir="rtl"><div dir="ltr">Hi Howard,</div><div dir="ltr"><br></div><div dir="ltr">I'm a no expert on library design... the motivaton for message (I should have detailed to make it clearer) come from a user's perspective:</div>

<div dir="ltr"><br></div><div dir="ltr">I noticed both clang and gcc compile a trivial program three times slower when including iostream from libcxx compared with including iostream from stdlibc++ . I checked all combinations, posted full details in my previous message. </div>

<div dir="ltr"><br></div><div dir="ltr">The version I'm using the the latest obtained from the svn. I wasn't aware there is a different windows port of it? anyhow, the latest svn compiles without special problems using clang from the builds site and the MingW 4.8.1 C library and header files. I also built the required libcxxabi. the build seems to work but I have not tested it yet, especially if exceptions work at all.</div>

<div dir="ltr"><br></div><div dir="ltr">The changes I made in both builds were flags only, added </div><div dir="ltr"><font face="courier new, monospace">-Wno-deprecated-register -Wno-ignored-attributes</font> to avoid warnings on MingW headers, <font face="courier new, monospace">-target i686-pc-mingw32 </font>since clang.exe was compiled on VC and assume this is the target, <font face="courier new, monospace">-nostdinc -Ilibcxxdirectory -Imingwincludedirectory</font><font face="arial, helvetica, sans-serif"> to use the libcxx header files.</font></div>

<div dir="ltr"><br></div><div dir="ltr">I did not submit a patch yet since it's not clear to me what is the "official" way to build libcxx. There are both CMakeLists (which do not have the correct flags for compiling) and a buildit shell script. I used the shell script.</div>

<div dir="ltr"><br></div><div dir="ltr">Yaron</div><div dir="ltr"><br></div></div><div class="gmail_extra"><div dir="ltr"><br><br><div class="gmail_quote">2013/10/2 G M <span dir="ltr"><<a href="mailto:gmisocpp@gmail.com" target="_blank">gmisocpp@gmail.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi Yaron</div><div> </div><div>I think there is a need to do some work on libcxx's modularity / layering, but I wouldn't focus on doing it for speed purposes myself.</div>

<div> </div><div>I think it needs a look at more for correctness and porting issues than anything else.</div>
<div> </div><div>I suspect (and I may be wrong) that you are basing some of your libcxx's modularity thoughts on the Windows port?</div><div> </div><div>The Windows port is still in a bit of a hacked state. libcxx on Apple/Linux is not.</div>


<div> </div><div>You might want check your modularity thoughts on apple/Linux to get something more representative of the real libcxx? If you think there is real modularity issues in the apple/Linux version I'd be more surprised.</div>


<div> </div><div>I have been thinking about this problem and have some ideas to reduce and refactor the windows include situation now I understand it a little better.</div><div>There's two or 3 places where we can improve the situation for Windows. But again in my mind the emphasis is more on correctness and layering than speed.</div>


<div> </div><div>Once my outstanding patches are committed I'll fix some of this up.</div><div> </div></blockquote></div></div></div>