On 29 Sep 2013 at 14:52, Beman Dawes wrote:
I don't think it occurred to them or to me during the discussions that anyone would try to workaround failures before the clang folks had a chance to introduce Microsoft compatibility fixes. I'll get back to Chandler with a request for a public statement of their plan.
I think there are multiple issues at work here, and the list is conflating them all as one. It might be worth disambiguating them: 1. There is getting clang to compile Mingw-path Boost on Windows. This is fairly easy, simply configure clang to pretend to be Mingw and apart from some minor gotchas this works and spits out Mingw type PE binaries. 2. There is getting clang to compile MSVC-path Boost on Windows with all its quirks workarounds and special cases and code paths for legacy MSVCs which modern MSVCs sometimes emulate if they spot a legacy pattern. This is very similar to IE10 spotting IE6 patterns and forcing legacy behaviour to prevent legacy code breakage. 3. There is getting clang to compile Boost as if it were MSVC18 (VS2013). Here the new, much less customised Dinkumware STL and much more conformant compiler ought to let Boost disable custom MSVC code paths in many cases, and adopt the GCC/clang code paths instead. Someone just needs to go through and try flipping code path selection switches to see what happens with the latest MSVC [1]. Item 1 is an easy add to Boost Build, though I struggle to see the value add for Boost apart from clang AST parsing on Windows. Item 2 is valuable to clang developers for debugging clang, and not really anyone else. Item 3 is value adding to Boost. Item 3 is the one Boost ought to encourage. Note that Item 2 and Item 3 are not mutually incompatible. Item 3 can be implemented with no damage done to Item 2 with the right design. If clang's developers want Item 2, they can supply the appropriate preprocessor macros to have Boost output the quirkest, most MSVC-specific possible code. Meanwhile, Boost can move ahead by removing MSVC quirk code paths for newer MSVCs, something I think everyone will agree would be a huge win in maintenance and bugs. [1]: It took a bit of creativity and effort, but I now have a single C++ path for VS2013 and GCC and clang in Boost.AFIO. Exact same C++ for all three compilers. I'm very pleased with VS2013, it's a huge improvement. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/