Niall Douglas
On 7 Jun 2014 at 15:09, Louis Dionne wrote:
Also, for those following the development of Boost.Hana, it is going well and I am preparing for a followup in the near future. Stay tuned!
Louis, Microsoft have announced what's going to be in VS2015 at http://blogs.msdn.com/b/vcblog/archive/2014/06/03/visual-studio-14-ctp .aspx.
I can't access this without signing up, but see below.
Eh, no it's definitely public. Check the link is correct, no spaces etc. Failing that search google for Visual Studio "14" CTP.
My bad, the link was fine.
I was wondering if Boost.Hana could work with VS2015? I mean, VS2014 will clearly be insufficient, but I'd like to know what you think about VS2015. Note that VS2015 still will not have expression SFINAE nor generalised constexpr nor template variables.
Variable templates and generalized constexpr are used in the library. Workarounds _might_ be possible, but I have to say I'm unwilling to make the code less legible in favour of workarounds since Boost.Hana is a bleeding edge library.
Still, if something can easily be done about it and make the library usable by massively more people, I will.
Well, you know the way you've been experimenting with alternative ways of doing the same thing ...
I was thinking you could have a good Hana and a bad Hana :). Good Hana is close to optimal for clang and GCC, while bad Hana is more backwards compatible at the cost of pathological performance. You'd obviously have preprocessor which switches the underlying implementation depending on the compiler.
That's an idea; I'm noting it and I'll think about it when the time is ripe. Right now, I'm experimenting a lot and it would be dumb to make my job harder by supporting workarounds, but that won't be true forever.
Do also bear in mind that MSVC is not an AST based compiler, so all your benchmarks will look totally different on MSVC anyway. What may have O(N^N) scaling on an AST compiler might well be O(N) on MSVC - in fact, that is exactly why MSVC isn't AST based, as internal Microsoft code is so complex it is uncompilable by an AST based compiler. So if you are to support MSVC one day after C++ 14 conformance is reached, the techniques you currently optimise for may well not be useful.
And MSVC isn't going anywhere. It's going to be a Tier 1 C++ compiler for at least the next decade. This might help your design choices today.
Actually, I'm trying to keep the API very independent from the internal implementation. The way I see it so far, performing well on MSVC will be a matter of benchmarking on that compiler and selecting the right implementation internally, and we won't wish that we had a different API. Still, benchmarking on MSVC is something that I have not done yet because I don't have access to that compiler. This is on my todo list, right after making Boost.Hana compilable by GCC. :-) Regards, Louis