Subject: Re: [boost] Efficient tuple implementation
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2014-06-08 12:25:13
Niall Douglas <s_sourceforge <at> nedprod.com> writes:
> 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
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. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk