Re: [boost] Efficient tuple implementation

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