Topic: decltype, SFINAE and restricted templates
Author: andy@servocomm.freeserve.co.uk (kwikius)
Date: Thu, 7 Oct 2004 18:10:24 GMT Raw View
regarding N1705 decltype and auto 3.4: decltype and SFINAE,
and N1696 restricted templates.
Maybe the two mechanisms are complimentary here?
IOW might be better to disentagle SFINAE from decltype itself by using
the restricted template mechanism.
regards
Andy Little
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: pdimov@gmail.com (Peter Dimov)
Date: Fri, 8 Oct 2004 18:27:31 GMT Raw View
andy@servocomm.freeserve.co.uk (kwikius) wrote in message news:<2873fa46.0410070612.667fe6b1@posting.google.com>...
> regarding N1705 decltype and auto 3.4: decltype and SFINAE,
> and N1696 restricted templates.
>
> Maybe the two mechanisms are complimentary here?
> IOW might be better to disentagle SFINAE from decltype itself by using
> the restricted template mechanism.
No, I don't see how N1696-style restricted templates can provide the
same functionality. They are a slight extension/syntactic sweetening
of what is already possible.
decltype(t+n, void) combined with SFINAE tests whether t+n is a valid
expression. This is a new capability that the language today does not
possess.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: andy@servocomm.freeserve.co.uk (kwikius)
Date: Sun, 10 Oct 2004 01:08:53 GMT Raw View
pdimov@gmail.com (Peter Dimov) wrote in message news:<abefd130.0410080610.318c8e5d@posting.google.com>...
> andy@servocomm.freeserve.co.uk (kwikius) wrote in message news:<2873fa46.0410070612.667fe6b1@posting.google.com>...
> > regarding N1705 decltype and auto 3.4: decltype and SFINAE,
> > and N1696 restricted templates.
> >
> > Maybe the two mechanisms are complimentary here?
> > IOW might be better to disentagle SFINAE from decltype itself by using
> > the restricted template mechanism.
>
> No, I don't see how N1696-style restricted templates can provide the
> same functionality. They are a slight extension/syntactic sweetening
> of what is already possible.
I meant complimentary in the sense of separate. Firstly SFINAE is
simple and works (eg using enable_if). I hope that:
1) SFINAE can be used on its own
2) decltype can be used on its own
3) decltype and Unrelated SFINAE can work in the same function/class
template.
>
> decltype(t+n, void) combined with SFINAE tests whether t+n is a valid
> expression. This is a new capability that the language today does not
> possess.
Dont get me wrong I am looking forward to decltype. However I can
imagine that it will add a huge burden on the compiler. From this
distance it seems that combining SFINAE and decltype tightly,
increases the load. OTOH I could see something like if((decltype(a()*
b())?is_arithmetic<b>::value : OtherCondition ) being useful.
FWIW Here is a current version of operator*(a,b) where a is a physical
quantity and b is an arithmetic type.SFINAE is used to prevent
ambibuities, but is dependent on type properties. On the one hand I
hope it shows that I am extremely interested in decltype. On the other
I wonder quite how the function will work once the decltype mechanisms
are in place. On the face of it the compiler would just flag an
ambiguity.
// physical_quantity * scalar
template<
typename NamedAbstractQuantity,
typename QuantityUnit,
typename Value_type,
typename Value_type1
>
inline
typename meta::binary_operation_if< // basically enable_if
// Condition: (basically) is Value_type1 an arithmetic type
type_traits::is_ct_quantity_value_type<Value_type1>,
// current result type deduction mechanism
ct_quantity<
NamedAbstractQuantity,
QuantityUnit,
Value_type
>,
std::multiplies,
Value_type1 // want arithmetic types here
>::result_type
// currently parsing Presumably stops here if invalid
operator *(
ct_quantity<
NamedAbstractQuantity,
QuantityUnit,
Value_type
>const & pq,
Value_type1 const& v)
// If continues to here will encounter ambiguous functions above
// eg physical_quantity * physical_quantity,
// physical_quantity * complex<physical_quantity>
// physical_quantity * angle
// SFINAE must now work much harder I guess. if(x){(do();}
becomes {do() } if(x);
{
typename meta::binary_operation<
ct_quantity<
NamedAbstractQuantity,
QuantityUnit,
Value_type
>,
std::multiplies,
Value_type1
>::result_type t( pq.numeric_value() * v );
return t;
}
BTW If there is a working implementation anywhere I would certainly be
interested to try converting my code to see if it can use these
mechanisms. Basically the whole library is based on nested
type-deductions.
regards
Andy Little
regards
Andy Little
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: gdr@cs.tamu.edu (Gabriel Dos Reis)
Date: Sun, 10 Oct 2004 23:55:17 GMT Raw View
andy@servocomm.freeserve.co.uk (kwikius) writes:
[...]
| > decltype(t+n, void) combined with SFINAE tests whether t+n is a valid
| > expression. This is a new capability that the language today does not
| > possess.
|
| Dont get me wrong I am looking forward to decltype. However I can
| imagine that it will add a huge burden on the compiler. From this
decltype is only asking the compiler to give type information it
already has, in current C++.
decltype is related to SFINEA in the same way sizeof is related to
SFINEA. If you have it for sizeof, then logically you have it for
decltype; and vice versa.
It just happens that if you replace sizeof -- which people are
currently doing -- with decltype you can express more things. But
that is just the normal course of actions, whereby if you combine
different language functionalities you can express more than just
focusing on one specific language facility.
And by the way, decltype(t+n, void) is not valid :-)
| distance it seems that combining SFINAE and decltype tightly,
| increases the load. OTOH I could see something like if((decltype(a()*
| b())?is_arithmetic<b>::value : OtherCondition ) being useful.
|
| FWIW Here is a current version of operator*(a,b) where a is a physical
| quantity and b is an arithmetic type.SFINAE is used to prevent
| ambibuities, but is dependent on type properties. On the one hand I
| hope it shows that I am extremely interested in decltype. On the other
| I wonder quite how the function will work once the decltype mechanisms
| are in place. On the face of it the compiler would just flag an
| ambiguity.
|
| // physical_quantity * scalar
| template<
| typename NamedAbstractQuantity,
| typename QuantityUnit,
| typename Value_type,
| typename Value_type1
| >
| inline
| typename meta::binary_operation_if< // basically enable_if
|
| // Condition: (basically) is Value_type1 an arithmetic type
| type_traits::is_ct_quantity_value_type<Value_type1>,
|
| // current result type deduction mechanism
| ct_quantity<
| NamedAbstractQuantity,
| QuantityUnit,
| Value_type
| >,
| std::multiplies,
| Value_type1 // want arithmetic types here
| >::result_type
|
| // currently parsing Presumably stops here if invalid
|
| operator *(
| ct_quantity<
| NamedAbstractQuantity,
| QuantityUnit,
| Value_type
| >const & pq,
| Value_type1 const& v)
|
| // If continues to here will encounter ambiguous functions above
| // eg physical_quantity * physical_quantity,
| // physical_quantity * complex<physical_quantity>
| // physical_quantity * angle
|
| // SFINAE must now work much harder I guess. if(x){(do();}
| becomes {do() } if(x);
I do not understand why. If your function signature or type is
invalid, that is it. decltype does not change how SFINEA works,
i.e. the proposal does not require the compiler to look into function
bodies before deciding whether it should consider the function for
overload purpose.
| {
| typename meta::binary_operation<
| ct_quantity<
| NamedAbstractQuantity,
| QuantityUnit,
| Value_type
| >,
| std::multiplies,
| Value_type1
| >::result_type t( pq.numeric_value() * v );
| return t;
| }
|
| BTW If there is a working implementation anywhere I would certainly be
| interested to try converting my code to see if it can use these
| mechanisms. Basically the whole library is based on nested
| type-deductions.
Working implementation of what?
Of decltype? If yes, then I used to have a working experimental
implementation in GCC, until I screwed up the tree. I tried to put it
back in a working state a week ago. You can, currently, use decltype
at all scopes except in function parameter declaration or in return
type (yes, except the interesting bits ;-)). The reason is very
simple: There is a bug in the g++ mangling scheme and there have
been many debates as to what to do. We did not reach unanimity.
I guess I'm just going to pick the fixes that encountered less
resistance and implement it on the branch.
--
Gabriel Dos Reis
gdr@cs.tamu.edu
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: dave@boost-consulting.com (David Abrahams)
Date: Sun, 10 Oct 2004 23:55:32 GMT Raw View
andy@servocomm.freeserve.co.uk (kwikius) writes:
> Dont get me wrong I am looking forward to decltype. However I can
> imagine that it will add a huge burden on the compiler.
Not really. It doesn't add much more than sizeof already requires.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: andy@servocomm.freeserve.co.uk (kwikius)
Date: Mon, 11 Oct 2004 16:12:56 GMT Raw View
gdr@cs.tamu.edu (Gabriel Dos Reis) wrote in message news:<m3sm8nkr4g.fsf@merlin.cs.tamu.edu>...
> andy@servocomm.freeserve.co.uk (kwikius) writes:
> decltype is only asking the compiler to give type information it
> already has, in current C++.
>
> decltype is related to SFINEA in the same way sizeof is related to
> SFINEA. If you have it for sizeof, then logically you have it for
> decltype; and vice versa.
>
> It just happens that if you replace sizeof -- which people are
> currently doing -- with decltype you can express more things. But
> that is just the normal course of actions, whereby if you combine
> different language functionalities you can express more than just
> focusing on one specific language facility.
Is sizeof that closely related? It requires an object definition, but
should decltype require an object definition?
class X;
class Y;
class Z;
Z const & operator + (X const & x, Y const & y);
void f()
{
X* px;
Y* py;
Z const & zz = *px + *py; //ok
sizeof(*px + *py);// error need definition of Z
}
> And by the way, decltype(t+n, void) is not valid :-)
Well I'm confused then. Whatever I think it would be useful to be able
to find out if an operation is valid eg
static_assert(decltype(a+b) -->true) or something.
I currently use a class to do this, again to knock out invalid
operations with SFINAE.
enable_if<
is_valid_binary_operation<
A,std:plus,B
>,
Sometype
>::type
func(A a, B b);
regards
Andy Little
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: gdr@cs.tamu.edu (Gabriel Dos Reis)
Date: Tue, 12 Oct 2004 16:14:12 GMT Raw View
andy@servocomm.freeserve.co.uk (kwikius) writes:
| gdr@cs.tamu.edu (Gabriel Dos Reis) wrote in message news:<m3sm8nkr4g.fsf@merlin.cs.tamu.edu>...
| > andy@servocomm.freeserve.co.uk (kwikius) writes:
|
| > decltype is only asking the compiler to give type information it
| > already has, in current C++.
| >
| > decltype is related to SFINEA in the same way sizeof is related to
| > SFINEA. If you have it for sizeof, then logically you have it for
| > decltype; and vice versa.
| >
| > It just happens that if you replace sizeof -- which people are
| > currently doing -- with decltype you can express more things. But
| > that is just the normal course of actions, whereby if you combine
| > different language functionalities you can express more than just
| > focusing on one specific language facility.
|
| Is sizeof that closely related?
Yes.
| It requires an object definition, but
| should decltype require an object definition?
I don't think it matters wheter one requires object definition or not.
If you apply sizeof to a non-object type the compiler will complain,
but it will do so only after deducing that the operand is not an
object-type. Decltype just ask the compiler to return that type back
-- instead of going complaining. The type inference as essentially
the same (modulo some minor irregularities).
| class X;
| class Y;
| class Z;
|
| Z const & operator + (X const & x, Y const & y);
|
| void f()
| {
| X* px;
| Y* py;
|
| Z const & zz = *px + *py; //ok
|
| sizeof(*px + *py);// error need definition of Z
Notice that this error happens only after the compiler determines that
the type of the sizeof operand is Z and is incomplete -- decltype
would ask the compiler to return back that information. But it just
happens that the expression is invalid (from type constraint point of
view)in itself; that has noting to do with sizeof or decltype.
Why do you believe decltype adds more burden here?
| }
|
| > And by the way, decltype(t+n, void) is not valid :-)
|
| Well I'm confused then. Whatever I think it would be useful to be able
| to find out if an operation is valid eg
The reason the abose is invalid that "t+n, void" is not a valid
expression, as it is using the comma operator whose
(1) first operand is the expression t+n;
(2) second operand is the type void.
We don't have anything like that in standard C++.
| static_assert(decltype(a+b) -->true) or something.
I don't undertand that syntax.
| I currently use a class to do this, again to knock out invalid
| operations with SFINAE.
|
| enable_if<
| is_valid_binary_operation<
| A,std:plus,B
| >,
| Sometype
| >::type
| func(A a, B b);
So?
--
Gabriel Dos Reis
gdr@cs.tamu.edu
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: pdimov@gmail.com (Peter Dimov)
Date: Tue, 12 Oct 2004 16:14:46 GMT Raw View
gdr@cs.tamu.edu (Gabriel Dos Reis) wrote in message news:<m3sm8nkr4g.fsf@merlin.cs.tamu.edu>...
>
> And by the way, decltype(t+n, void) is not valid :-)
Right, I copied it straight from the example in N1705 3.4, without
thinking. It should probably be decltype(t+n, (void)0).
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: gdr@cs.tamu.edu (Gabriel Dos Reis)
Date: Thu, 14 Oct 2004 04:49:35 GMT Raw View
pdimov@gmail.com (Peter Dimov) writes:
| gdr@cs.tamu.edu (Gabriel Dos Reis) wrote in message news:<m3sm8nkr4g.fsf@merlin.cs.tamu.edu>...
| >
| > And by the way, decltype(t+n, void) is not valid :-)
|
| Right, I copied it straight from the example in N1705 3.4, without
| thinking. It should probably be decltype(t+n, (void)0).
Yep. And I'm doubly guilty :-)
--
Gabriel Dos Reis
gdr@cs.tamu.edu
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: andy@servocomm.freeserve.co.uk (kwikius)
Date: Wed, 13 Oct 2004 20:40:55 GMT Raw View
gdr@cs.tamu.edu (Gabriel Dos Reis) wrote in message news:<m3r7o4vbp2.fsf@merlin.cs.tamu.edu>...
> andy@servocomm.freeserve.co.uk (kwikius) writes:
>
> | gdr@cs.tamu.edu (Gabriel Dos Reis) wrote in message news:<m3sm8nkr4g.fsf@merlin.cs.tamu.edu>...
> | > andy@servocomm.freeserve.co.uk (kwikius) writes:
> | enable_if<
> | is_valid_binary_operation<
> | A,std:plus,B
> | >,
> Sometype
> | >::type
> | func(A a, B b);
>
> So?
So nothing I guess. I'm going to back out of this discussion. I'm
happy to wait and see what develops :-)
regards
Andy Little
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]