[config] What Feature is this??
Folks, I think I'm looking to add a new C++11 defect macro, but don't know what the feature is called, nor can I see a way of detecting it with clang's __has_feature function. The code I want to enable involves function overloading based on a decltype return type as in: auto integrate(args...) -> decltype(expression1); auto integrate(args...) -> decltype(expression2); where expression1 and expression2 are two mutually exclusive options (the conceptual requirements of args means that only one of these 2 will ever be satisfied). This works fine in msvc-14 and later and gcc-4.8 and later, but I don't see any current config macros which cover this case, nor can I figure out what this trick should be called. Alternatively, if anyone has a better way of differentiating between unary and binary functions I'm happy to hear about it ;) Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com
John Maddock wrote:
Folks, I think I'm looking to add a new C++11 defect macro, but don't know what the feature is called, nor can I see a way of detecting it with clang's __has_feature function.
The code I want to enable involves function overloading based on a decltype return type as in:
auto integrate(args...) -> decltype(expression1); auto integrate(args...) -> decltype(expression2);
where expression1 and expression2 are two mutually exclusive options (the conceptual requirements of args means that only one of these 2 will ever be satisfied).
This works fine in msvc-14 and later and gcc-4.8 and later, but I don't see any current config macros which cover this case, nor can I figure out what this trick should be called.
This is in principle just a combination of BOOST_NO_CXX11_DECLTYPE, BOOST_NO_CXX11_TRAILING_RESULT_TYPES and BOOST_NO_SFINAE_EXPR, although depending on `expression1`, BOOST_NO_CXX11_DECLTYPE_N3276 may also be relevant. That's without taking into account bugs, of course.
On 7/23/2017 2:50 PM, John Maddock via Boost wrote:
Folks, I think I'm looking to add a new C++11 defect macro, but don't know what the feature is called, nor can I see a way of detecting it with clang's __has_feature function.
The code I want to enable involves function overloading based on a decltype return type as in:
I never realized that function overloading could occur based on any return type. I always thought it had to be based on the parameter types. Is this part of the C+11 standard ? Where in the standard is this specified ?
auto integrate(args...) -> decltype(expression1);
auto integrate(args...) -> decltype(expression2);
where expression1 and expression2 are two mutually exclusive options (the conceptual requirements of args means that only one of these 2 will ever be satisfied).
This works fine in msvc-14 and later and gcc-4.8 and later, but I don't see any current config macros which cover this case, nor can I figure out what this trick should be called.
Alternatively, if anyone has a better way of differentiating between unary and binary functions I'm happy to hear about it ;)
Thanks, John.
--- This email has been checked for viruses by AVG. http://www.avg.com
On 24/07/2017 13:37, Edward Diener via Boost wrote:
On 7/23/2017 2:50 PM, John Maddock via Boost wrote:
Folks, I think I'm looking to add a new C++11 defect macro, but don't know what the feature is called, nor can I see a way of detecting it with clang's __has_feature function.
The code I want to enable involves function overloading based on a decltype return type as in:
I never realized that function overloading could occur based on any return type. I always thought it had to be based on the parameter types. Is this part of the C+11 standard ? Where in the standard is this specified ? The name mangling of the gnu ABI (used by most unix-like) does not encode the return type, and the result does not have to be used when the function is called. So if such a functionality is added, the mangling issue alone will hurt backward compatibility real bad.
Alain Miniussi wrote:
The name mangling of the gnu ABI (used by most unix-like) does not encode the return type, and the result does not have to be used when the function is called.
So if such a functionality is added, the mangling issue alone will hurt backward compatibility real bad.
Template parameters are encoded though, so when faced with compiler protestations that two function templates are the same, I just start adding dummy class = void parameters to differentiate. That is, template<class... A> auto f(A&&... a) -> decltype(expr1); template<class... A> auto f(A&&... a) -> decltype(expr2); becomes template<class... A> auto f(A&&... a) -> decltype(expr1); template<class... A, class = void> auto f(A&&... a) -> decltype(expr2);
On 07/24/17 14:37, Edward Diener via Boost wrote:
On 7/23/2017 2:50 PM, John Maddock via Boost wrote:
Folks, I think I'm looking to add a new C++11 defect macro, but don't know what the feature is called, nor can I see a way of detecting it with clang's __has_feature function.
The code I want to enable involves function overloading based on a decltype return type as in:
I never realized that function overloading could occur based on any return type. I always thought it had to be based on the parameter types. Is this part of the C+11 standard ? Where in the standard is this specified ?
I think it's not about overloading but about disabling function template instantiations via SFINAE.
auto integrate(args...) -> decltype(expression1);
auto integrate(args...) -> decltype(expression2);
where expression1 and expression2 are two mutually exclusive options (the conceptual requirements of args means that only one of these 2 will ever be satisfied).
This works fine in msvc-14 and later and gcc-4.8 and later, but I don't see any current config macros which cover this case, nor can I figure out what this trick should be called.
Alternatively, if anyone has a better way of differentiating between unary and binary functions I'm happy to hear about it ;)
Thanks, John.
--- This email has been checked for viruses by AVG. http://www.avg.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 7/24/2017 8:29 AM, Andrey Semashev via Boost wrote:
On 07/24/17 14:37, Edward Diener via Boost wrote:
On 7/23/2017 2:50 PM, John Maddock via Boost wrote:
Folks, I think I'm looking to add a new C++11 defect macro, but don't know what the feature is called, nor can I see a way of detecting it with clang's __has_feature function.
The code I want to enable involves function overloading based on a decltype return type as in:
I never realized that function overloading could occur based on any return type. I always thought it had to be based on the parameter types. Is this part of the C+11 standard ? Where in the standard is this specified ?
I think it's not about overloading but about disabling function template instantiations via SFINAE.
I am glad to hear that. I misinterpreted the original message and probably should have realized it. Thanks !
auto integrate(args...) -> decltype(expression1);
auto integrate(args...) -> decltype(expression2);
where expression1 and expression2 are two mutually exclusive options (the conceptual requirements of args means that only one of these 2 will ever be satisfied).
This works fine in msvc-14 and later and gcc-4.8 and later, but I don't see any current config macros which cover this case, nor can I figure out what this trick should be called.
Alternatively, if anyone has a better way of differentiating between unary and binary functions I'm happy to hear about it ;)
Thanks, John.
--- This email has been checked for viruses by AVG. http://www.avg.com
On 24/07/2017 16:18, Edward Diener via Boost wrote:
On 7/24/2017 8:29 AM, Andrey Semashev via Boost wrote:
On 07/24/17 14:37, Edward Diener via Boost wrote:
On 7/23/2017 2:50 PM, John Maddock via Boost wrote:
Folks, I think I'm looking to add a new C++11 defect macro, but don't know what the feature is called, nor can I see a way of detecting it with clang's __has_feature function.
The code I want to enable involves function overloading based on a decltype return type as in:
I never realized that function overloading could occur based on any return type. I always thought it had to be based on the parameter types. Is this part of the C+11 standard ? Where in the standard is this specified ?
I think it's not about overloading but about disabling function template instantiations via SFINAE.
I am glad to hear that. I misinterpreted the original message and probably should have realized it. Thanks !
It's sort of about both actually - we're using SFINAE to select between two overloads based on the properties of the argument types (sort of poor man's Concepts), so we can write: template <class Arg> auto foo(const Arg&) -> decltype(expression-involving-type-Arg) and that function overload will be considered only if the expression inside the decltype compiles. You may have to go through heroics to get the return type correct (use of the comma operator for example), but it's a very easy way to select between function overloads based on which concepts the argument types adhere to. John. --- This email has been checked for viruses by AVG. http://www.avg.com
On 7/24/2017 12:40 PM, John Maddock via Boost wrote:
On 24/07/2017 16:18, Edward Diener via Boost wrote:
On 7/24/2017 8:29 AM, Andrey Semashev via Boost wrote:
On 07/24/17 14:37, Edward Diener via Boost wrote:
On 7/23/2017 2:50 PM, John Maddock via Boost wrote:
Folks, I think I'm looking to add a new C++11 defect macro, but don't know what the feature is called, nor can I see a way of detecting it with clang's __has_feature function.
The code I want to enable involves function overloading based on a decltype return type as in:
I never realized that function overloading could occur based on any return type. I always thought it had to be based on the parameter types. Is this part of the C+11 standard ? Where in the standard is this specified ?
I think it's not about overloading but about disabling function template instantiations via SFINAE.
I am glad to hear that. I misinterpreted the original message and probably should have realized it. Thanks !
It's sort of about both actually - we're using SFINAE to select between two overloads based on the properties of the argument types (sort of poor man's Concepts), so we can write:
template <class Arg> auto foo(const Arg&) -> decltype(expression-involving-type-Arg)
and that function overload will be considered only if the expression inside the decltype compiles. You may have to go through heroics to get the return type correct (use of the comma operator for example), but it's a very easy way to select between function overloads based on which concepts the argument types adhere to.
Thanks, John, I just fell asleep by not realizing you were talking about SFINAE ala enable_if etc. I am surprised that any compiler would operate differently in regard to SFINAE between using the C++03 'return-type some_function(etc.)' form and the C++11 'auto some_function(etc.) -> return-type' form, whether decltype was used or not.
John.
--- This email has been checked for viruses by AVG. http://www.avg.com
On 25/07/2017 06:26, Edward Diener wrote:
Thanks, John, I just fell asleep by not realizing you were talking about SFINAE ala enable_if etc. I am surprised that any compiler would operate differently in regard to SFINAE between using the C++03 'return-type some_function(etc.)' form and the C++11 'auto some_function(etc.) -> return-type' form, whether decltype was used or not.
They don't AFAIK, but you can't use the parameter types in an expression until after they are actually declared as parameters, thus requiring the auto -> form.
On 7/24/2017 7:17 PM, Gavin Lambert via Boost wrote:
On 25/07/2017 06:26, Edward Diener wrote:
Thanks, John, I just fell asleep by not realizing you were talking about SFINAE ala enable_if etc. I am surprised that any compiler would operate differently in regard to SFINAE between using the C++03 'return-type some_function(etc.)' form and the C++11 'auto some_function(etc.) -> return-type' form, whether decltype was used or not.
They don't AFAIK, but you can't use the parameter types in an expression until after they are actually declared as parameters, thus requiring the auto -> form.
Thanks ! Makes perfect sense.
On Tue, Jul 25, 2017 at 2:17 AM, Gavin Lambert via Boost <boost@lists.boost.org> wrote:
On 25/07/2017 06:26, Edward Diener wrote:
Thanks, John, I just fell asleep by not realizing you were talking about SFINAE ala enable_if etc. I am surprised that any compiler would operate differently in regard to SFINAE between using the C++03 'return-type some_function(etc.)' form and the C++11 'auto some_function(etc.) -> return-type' form, whether decltype was used or not.
They don't AFAIK, but you can't use the parameter types in an expression until after they are actually declared as parameters, thus requiring the auto -> form.
To be more precise, you can use parameter *types* but not parameter *names*. Types are declared by the template<...> prefix.
On 25/07/2017 12:19, Andrey Semashev wrote:
On Tue, Jul 25, 2017 at 2:17 AM, Gavin Lambert wrote:
On 25/07/2017 06:26, Edward Diener wrote:
Thanks, John, I just fell asleep by not realizing you were talking about SFINAE ala enable_if etc. I am surprised that any compiler would operate differently in regard to SFINAE between using the C++03 'return-type some_function(etc.)' form and the C++11 'auto some_function(etc.) -> return-type' form, whether decltype was used or not.
They don't AFAIK, but you can't use the parameter types in an expression until after they are actually declared as parameters, thus requiring the auto -> form.
To be more precise, you can use parameter *types* but not parameter *names*. Types are declared by the template<...> prefix.
I thought there was also a related issue with template type inference that way though, but it's possible I'm misremembering.
On 07/25/17 03:40, Gavin Lambert via Boost wrote:
On 25/07/2017 12:19, Andrey Semashev wrote:
On Tue, Jul 25, 2017 at 2:17 AM, Gavin Lambert wrote:
On 25/07/2017 06:26, Edward Diener wrote:
Thanks, John, I just fell asleep by not realizing you were talking about SFINAE ala enable_if etc. I am surprised that any compiler would operate differently in regard to SFINAE between using the C++03 'return-type some_function(etc.)' form and the C++11 'auto some_function(etc.) -> return-type' form, whether decltype was used or not.
They don't AFAIK, but you can't use the parameter types in an expression until after they are actually declared as parameters, thus requiring the auto -> form.
To be more precise, you can use parameter *types* but not parameter *names*. Types are declared by the template<...> prefix.
I thought there was also a related issue with template type inference that way though, but it's possible I'm misremembering.
I'm not aware of such issue, but we surely did use SFINAE in function return types since C++03 era.
participants (6)
-
Alain Miniussi -
Andrey Semashev -
Edward Diener -
Gavin Lambert -
John Maddock -
Peter Dimov