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