Tested on Linux-PPC64. The idea here is to get the constructor templates
to step out of the way if what they are dealing with will be handled by
a special member function, like the copy constructor. Doing so properly
fixes the bug at hand and likely other similar cases, too. The problem
in getting
On 24 May 2016 at 17:59, Ville Voutilainen wrote:
Slight tweak. The avoidance of _NotSameTuple wasn't quite correct for
the templates that
take const tuple<_UElements...>& or tuple<_UElements...>&& instead of
const _UElements&...
or _UElements&&...
This patch introduces a new helper alias to c
On 24 May 2016 at 19:35, Ville Voutilainen wrote:
> Slight tweak. The avoidance of _NotSameTuple wasn't quite correct for
> the templates that
> take const tuple<_UElements...>& or tuple<_UElements...>&& instead of
> const _UElements&...
> or _UElements&&...
>
> This patch introduces a new helper
On 24/05/16 19:49 +0300, Ville Voutilainen wrote:
On 24 May 2016 at 19:35, Ville Voutilainen wrote:
Slight tweak. The avoidance of _NotSameTuple wasn't quite correct for
the templates that
take const tuple<_UElements...>& or tuple<_UElements...>&& instead of
const _UElements&...
or _UElements&
On 25 May 2016 at 16:55, Jonathan Wakely wrote:
> On 24/05/16 19:49 +0300, Ville Voutilainen wrote:
>>
>> On 24 May 2016 at 19:35, Ville Voutilainen
>> wrote:
>>>
>>> Slight tweak. The avoidance of _NotSameTuple wasn't quite correct for
>>> the templates that
>>> take const tuple<_UElements...>&
On 26/05/16 01:07 +0300, Ville Voutilainen wrote:
On 25 May 2016 at 16:55, Jonathan Wakely wrote:
On 24/05/16 19:49 +0300, Ville Voutilainen wrote:
On 24 May 2016 at 19:35, Ville Voutilainen
wrote:
Slight tweak. The avoidance of _NotSameTuple wasn't quite correct for
the templates that
tak
