On 13/06/15 21:05 +0300, Ville Voutilainen wrote:
Another round! The new patch
- makes sure not to change non-deduced parameters to deduced ones, and adds
tests for that.
- removes the name of the bool non-type template parameter for the 'concepts'.
- introduces shortcuts for making the use of
On 8 June 2015 at 19:01, Ville Voutilainen ville.voutilai...@gmail.com wrote:
Yes, it should be uglified, thanks.
Ahem, yes, actually removed since it's there only to be specialized.
Another round! The new patch
- makes sure not to change non-deduced parameters to deduced ones, and adds
tests
* include/std/tuple
In the hunk below, should the sizes_match template parameter
be privatized (since it isn't part of the public interface)?
Or perhaps even removed if it's not used?
Martin
@ -457,6 +457,73 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
};
+
+ // Concept utility
On 8 June 2015 at 18:53, Ville Voutilainen ville.voutilai...@gmail.com wrote:
On 8 June 2015 at 18:37, Martin Sebor mse...@redhat.com wrote:
In the hunk below, should the sizes_match template parameter
be privatized (since it isn't part of the public interface)?
Or perhaps even removed if it's
On 8 June 2015 at 18:37, Martin Sebor mse...@redhat.com wrote:
In the hunk below, should the sizes_match template parameter
be privatized (since it isn't part of the public interface)?
Or perhaps even removed if it's not used?
Yes, it should be uglified, thanks.
On 7 June 2015 at 11:12, Ville Voutilainen ville.voutilai...@gmail.com wrote:
Does the following code still compile with your patch?
struct A { int a,b; };
std::tupleint,int,A a(3,4,{1,2});
No. :/ And we have no test for it.. I'll need to look at that.
Ahem, yes, this is because the
On Sun, 7 Jun 2015, Ville Voutilainen wrote:
On 7 June 2015 at 11:12, Ville Voutilainen ville.voutilai...@gmail.com wrote:
Does the following code still compile with your patch?
struct A { int a,b; };
std::tupleint,int,A a(3,4,{1,2});
No. :/ And we have no test for it.. I'll need to look at
On 7 June 2015 at 11:33, Ville Voutilainen ville.voutilai...@gmail.com wrote:
You use a lot: typename enable_ifX, bool::type=true
while the current code seems to favor: class=typename enable_ifX::type.
I don't really care which one is used, but it is easier to read when the
style is consistent
On Sun, 7 Jun 2015, Ville Voutilainen wrote:
- explicit
- constexpr tuple(const _Elements... __elements)
+ templatetypename... _UElements, typename
+enable_if__and_is_sameconst _Elements,
+const _UElements...::value
+
On 7 June 2015 at 09:53, Marc Glisse marc.gli...@inria.fr wrote:
Since the paper does not mention looking at _MoveConstructibleTuple or
_ImplicitlyMoveConvertibleTuple here, could you add a comment explaining
why that is needed?
Sure.
Does the following code still compile with your patch?
This patch implements the so-called conditionally-explicit constructors
for tuple and pair, and also constrains the default constructors of tuple and
pair. The patch does not try to implement the part in N4387 that allows
constructing tuples from shorter packs than the tuple's element count,
I
11 matches
Mail list logo
