C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  decltype, SFINAE and restricted templates          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message kwikius Guest Posted: Thu Oct 07, 2004 6:10 pm    Post subject: decltype, SFINAE and restricted templates 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 ] Back to top Peter Dimov Guest Posted: Fri Oct 08, 2004 6:27 pm    Post subject: Re: decltype, SFINAE and restricted templates [email]andy (AT) servocomm (DOT) freeserve.co.uk[/email] (kwikius) wrote in message news:<2873fa46.0410070612.667fe6b1 (AT) posting (DOT) google.com>... Quote: 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 ] Back to top kwikius Guest Posted: Sun Oct 10, 2004 1:08 am    Post subject: Re: decltype, SFINAE and restricted templates [email]pdimov (AT) gmail (DOT) com[/email] (Peter Dimov) wrote in message news:<abefd130.0410080610.318c8e5d (AT) posting (DOT) google.com>... Quote: andy (AT) servocomm (DOT) freeserve.co.uk (kwikius) wrote in message news:<2873fa46.0410070612.667fe6b1 (AT) posting (DOT) 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. Quote: 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 Quote: inline typename meta::binary_operation_if< // basically enable_if // Condition: (basically) is Value_type1 an arithmetic type type_traits::is_ct_quantity_value_type // current result type deduction mechanism ct_quantity< NamedAbstractQuantity, QuantityUnit, Value_type Quote: , std::multiplies, Value_type1 // want arithmetic types here Quote: ::result_type // currently parsing Presumably stops here if invalid operator *( ct_quantity< NamedAbstractQuantity, QuantityUnit, Value_type Quote: 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 * 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 Quote: , std::multiplies, Value_type1 Quote: ::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 ] Back to top Gabriel Dos Reis Guest Posted: Sun Oct 10, 2004 11:55 pm    Post subject: Re: decltype, SFINAE and restricted templates [email]andy (AT) servocomm (DOT) freeserve.co.uk[/email] (kwikius) writes: [...] Quote: 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 :-) Quote: 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 // 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 * 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. Quote: { 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 [email]gdr (AT) cs (DOT) tamu.edu[/email] 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 ] Back to top David Abrahams Guest Posted: Sun Oct 10, 2004 11:55 pm    Post subject: Re: decltype, SFINAE and restricted templates [email]andy (AT) servocomm (DOT) freeserve.co.uk[/email] (kwikius) writes: Quote: 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 ] Back to top kwikius Guest Posted: Mon Oct 11, 2004 4:12 pm    Post subject: Re: decltype, SFINAE and restricted templates [email]gdr (AT) cs (DOT) tamu.edu[/email] (Gabriel Dos Reis) wrote in message news:<m3sm8nkr4g.fsf (AT) merlin (DOT) cs.tamu.edu>... Quote: andy (AT) servocomm (DOT) 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 } Quote: 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 Quote: , 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 ] Back to top Gabriel Dos Reis Guest Posted: Tue Oct 12, 2004 4:14 pm    Post subject: Re: decltype, SFINAE and restricted templates [email]andy (AT) servocomm (DOT) freeserve.co.uk[/email] (kwikius) writes: Quote: gdr (AT) cs (DOT) tamu.edu (Gabriel Dos Reis) wrote in message news:<m3sm8nkr4g.fsf (AT) merlin (DOT) cs.tamu.edu>... [email]andy (AT) servocomm (DOT) freeserve.co.uk[/email] (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. Quote: 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). Quote: 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? Quote: } 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++. Quote: static_assert(decltype(a+b) -->true) or something. I don't undertand that syntax. Quote: 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 [email]gdr (AT) cs (DOT) tamu.edu[/email] 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 ] Back to top Peter Dimov Guest Posted: Tue Oct 12, 2004 4:14 pm    Post subject: Re: decltype, SFINAE and restricted templates [email]gdr (AT) cs (DOT) tamu.edu[/email] (Gabriel Dos Reis) wrote in message news:<m3sm8nkr4g.fsf (AT) merlin (DOT) cs.tamu.edu>... Quote: 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 ] Back to top kwikius Guest Posted: Wed Oct 13, 2004 8:40 pm    Post subject: Re: decltype, SFINAE and restricted templates [email]gdr (AT) cs (DOT) tamu.edu[/email] (Gabriel Dos Reis) wrote in message news:<m3r7o4vbp2.fsf (AT) merlin (DOT) cs.tamu.edu>... Quote: andy (AT) servocomm (DOT) freeserve.co.uk (kwikius) writes: | [email]gdr (AT) cs (DOT) tamu.edu[/email] (Gabriel Dos Reis) wrote in message news:<m3sm8nkr4g.fsf (AT) merlin (DOT) cs.tamu.edu>... | > [email]andy (AT) servocomm (DOT) freeserve.co.uk[/email] (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 ] Back to top Gabriel Dos Reis Guest Posted: Thu Oct 14, 2004 4:49 am    Post subject: Re: decltype, SFINAE and restricted templates [email]pdimov (AT) gmail (DOT) com[/email] (Peter Dimov) writes: Quote: gdr (AT) cs (DOT) tamu.edu (Gabriel Dos Reis) wrote in message news:<m3sm8nkr4g.fsf (AT) merlin (DOT) 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 [email]gdr (AT) cs (DOT) tamu.edu[/email] 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 ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language, library and standards All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.