Topic: decltype(using ....; expression)
Author: Sebastian Mach <mach.seb@gmail.com>
Date: Sat, 2 Nov 2013 10:33:33 -0700 (PDT)
Raw View
------=_Part_259_11422508.1383413613991
Content-Type: text/plain; charset=ISO-8859-1
I just stumbled on a problem whose details you can find in
http://stackoverflow.com/questions/19744324/decltype-and-mixing-adl-lookup-with-non-adl-lookup.
Basically, I am looking for a clean syntax to solve the following problem:
template <typename T>
auto foo(T t) -> decltype (something(t))
{
using std::something;
return something(t);
}
This shall work for both intrinsic types (like in `foo(float t) .... return
ilogb(t);`) and also for ADL-looked-up types (like in `foo(Nanometer t)
..... return ilogb(t);`.
Simply using `T` does not work. See for example `std::ilogb`, which returns
`int` for all T.
I am not sure about the new syntax in C++14, with regards to SFINAE-based
overloads:
template <typename T>
auto foo(T t) // this overload should be used if there is a
something(t) available as is
{
....
}
template <typename T>
auto foo(T t) // this overload should be used for classes for which
begin() and end() is defined.
{
....
}
SFINAE would not be able to disambiguate both here, right?
As the StackOverflow QA shows, the quick solution is another level of
indirection, namely a namespace that merges the ADL lookups with lookups
for intrinsic types.
But what would you think about the following syntax:
template <typename T>
auto foo(T t) -> decltype(using std::something; something(t)) { .... }
Within decltype, name lookup is already performed in C++11. I can't tell
how much this simplifies implementation in compilers, though.
Best regards
Sebastian Mach
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_259_11422508.1383413613991
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I just stumbled on a problem whose details you can find in=
http://stackoverflow.com/questions/19744324/decltype-and-mixing-adl-lookup=
-with-non-adl-lookup.<br><br><br>Basically, I am looking for a clean syntax=
to solve the following problem:<br><br><span style=3D"font-family: courier=
new,monospace;"><br> template <typename T><br>&nbs=
p; auto foo(T t) -> decltype (something(t))<br> &=
nbsp; {<br> using std::something;=
<br> return something(t);<br>&nbs=
p; }</span><br><br>This shall work for both intrinsic types (li=
ke in `foo(float t) .... return ilogb(t);`) and also for ADL-looked-up type=
s (like in `foo(Nanometer t) .... return ilogb(t);`.<br><br>Simply using `T=
` does not work. See for example `std::ilogb`, which returns `int` for all =
T.<br><br>I am not sure about the new syntax in C++14, with regards to SFIN=
AE-based overloads:<br><br><br><span style=3D"font-family: courier new,mono=
space;"> template <typename T><br>  =
; auto foo(T t) // this overload should be used if there is a something(t) =
available as is<br> {<br> &n=
bsp; ....<br> }<br><br> template =
<typename T><br> auto foo(T t) // this overload sho=
uld be used for classes for which begin() and end() is defined.<br> &n=
bsp; {<br> ....<br> &n=
bsp; }<br></span><br>SFINAE would not be able to disambiguate both he=
re, right?<br><br>As the StackOverflow QA shows, the quick solution is anot=
her level of indirection, namely a namespace that merges the ADL lookups wi=
th lookups for intrinsic types. <br><br>But what would you think about the =
following syntax:<br><span style=3D"font-family: courier new,monospace;"><b=
r> template <typename T><br> auto=
foo(T t) -> decltype(using std::something; something(t)) { .... }</span=
><br><br>Within decltype, name lookup is already performed in C++11. I can'=
t tell how much this simplifies implementation in compilers, though.<br><br=
><br><br>Best regards<br><br>Sebastian Mach<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_259_11422508.1383413613991--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 03 Nov 2013 09:43:49 +0800
Raw View
On 11/3/13 1:33 AM, Sebastian Mach wrote:
> Basically, I am looking for a clean syntax to solve the following problem:
>
>
> template <typename T>
> auto foo(T t) -> decltype (something(t))
> {
> using std::something;
> return something(t);
> }
If you omit the trailing-return-type, then you get return type deduction
in C++14, which seems to do what you want in this case. It can be
slightly brittle, but if you use it purely to bring the using
declaration outside the function scope, the danger should be contained.
It's also idiomatic to use decltype(auto) for a deduced return type, but
it doesn't matter if you're returning a prvalue.
> I can't tell
> how much this simplifies implementation in compilers, though.
The simplest solution is the one you already have :v) . As for
efficiency or performance, you have to be doing a lot of something for
that to matter.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Sebastian Mach <mach.seb@gmail.com>
Date: Sun, 3 Nov 2013 01:43:17 -0700 (PDT)
Raw View
------=_Part_572_27061142.1383468197870
Content-Type: text/plain; charset=ISO-8859-1
> If you omit the trailing-return-type, then you get return type deduction
> in C++14, which seems to do what you want in this case. It can be
> slightly brittle, but if you use it purely to bring the using
> declaration outside the function scope, the danger should be contained.
>
But then I couldn't use SFINAE, right? I.e., afair, even in C++14, SFINAE
is on the signature and/or return type of a function, not the body.
I don't have a fabulously great example, but I try (I omit std::declval for
readability here):
template <typename T>
auto foo (T lhs, T rhs)
-> decltype(sin(lhs[0] + lhs[0])) // State that T must have a subscript
operator that yields an addable type for which 'sin' must be defined
{
....
}
template <typename T>
auto foo (T lhs, T rhs) -> decltype(sin(lhs + lhs)) // State that T itself
is an addable type
{
....
}
In C++14, I could just use
template <typename T> auto foo (T lhs, T rhs) {....}
template <typename T> auto foo (T lhs, T rhs) {....}
which is then ambiguous.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_572_27061142.1383468197870
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If you om=
it the trailing-return-type, then you get return type deduction=20
<br>in C++14, which seems to do what you want in this case. It can be=20
<br>slightly brittle, but if you use it purely to bring the using=20
<br>declaration outside the function scope, the danger should be contained.
<br></blockquote><div><br>But then I couldn't use SFINAE, right? I.e., afai=
r, even in C++14, SFINAE is on the signature and/or return type of a functi=
on, not the body.<br><br>I don't have a fabulously great example, but I try=
(I omit std::declval for readability here):<br><span style=3D"font-family:=
courier new,monospace;"><br>template <typename T><br>auto foo (T lhs=
, T rhs)<br> -> decltype(sin(lhs[0] + lhs[0])) // State that T must=
have a subscript operator that yields an addable type for which 'sin' must=
be defined<br>{<br> ....<br>}<br><br>template <typena=
me T><br>auto foo (T lhs, T rhs) ->=20
decltype(sin(lhs + lhs)) // State that T itself is an addable type<br>{<br>=
....<br>}</span><br><br>In C++14, I could just use <br><=
br><span style=3D"font-family: courier new,monospace;">template <typenam=
e T> auto foo (T lhs, T rhs) {....}<br>template <typename T> auto =
foo (T lhs, T rhs) {....}</span><br><br>which is then ambiguous.<br></div><=
/div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_572_27061142.1383468197870--
.
Author: Sebastian Mach <mach.seb@gmail.com>
Date: Sun, 3 Nov 2013 01:45:58 -0700 (PDT)
Raw View
------=_Part_29_17858686.1383468358385
Content-Type: text/plain; charset=ISO-8859-1
By the way, a more important example is given by R. Martinho Fernandez at
http://stackoverflow.com/questions/7635939/how-do-i-write-an-adl-enabled-trailing-return-type-or-noexcept-specification
:
> Imagine I'm writing some container template or something. And the time
comes to specialize `std::swap` for it. As a good citizen, I'll enable ADL
by doing something like this:
>
> template <typename T>
> void swap(my_template<T>& x, my_template<T>& y) {
> using std::swap;
> swap(x.something_that_is_a_T, y.something_that_is_a_T);
> }
>
> This is very neat and all. Until I want to add an exception
specification. My `swap` is `noexcept` as long as the swap for `T` is
`noexcept`. So, I'd be writing something like:
>
> template <typename T>
> void swap(my_template<T>& x, my_template<T>& y)
> noexcept(noexcept(swap(std::declval<T>(), std::declval<T>())))
>
> Problem is, the `swap` in there needs to be the ADL-discovered `swap` or
`std::swap`. How do I handle this?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_29_17858686.1383468358385
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">By the way, a more important example is given by R. Martin=
ho Fernandez at http://stackoverflow.com/questions/7635939/how-do-i-write-a=
n-adl-enabled-trailing-return-type-or-noexcept-specification :<br><br><br>&=
gt; Imagine I'm writing some container template or something. And the time =
comes to specialize `std::swap` for it. As a good citizen, I'll enable ADL =
by doing something like this:<br>><br>> template &l=
t;typename T><br>> void swap(my_template<T>&a=
mp; x, my_template<T>& y) {<br>> =
using std::swap;<br>> &n=
bsp; swap(x.something_that_is_a_T, y.something_that_is_a_T);<br>> &=
nbsp; }<br>><br>> This is very neat and all. Until I want to ad=
d an exception specification. My `swap` is `noexcept` as long as the swap f=
or `T` is `noexcept`. So, I'd be writing something like:<br>><br>>&nb=
sp; template <typename T><br>> void =
swap(my_template<T>& x, my_template<T>& y)<br>> =
; noexcept(noexcept(swap(std::declval&l=
t;T>(), std::declval<T>())))<br>><br>> Problem is, the `swap=
` in there needs to be the ADL-discovered `swap` or `std::swap`. How do I h=
andle this?<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_29_17858686.1383468358385--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 04 Nov 2013 07:13:48 +0800
Raw View
On 11/3/13 4:43 PM, Sebastian Mach wrote:
>
>> If you omit the trailing-return-type, then you get return type deduction
>> in C++14, which seems to do what you want in this case. It can be
>> slightly brittle, but if you use it purely to bring the using
>> declaration outside the function scope, the danger should be contained.
>>
> But then I couldn't use SFINAE, right? I.e., afair, even in C++14, SFINAE
> is on the signature and/or return type of a function, not the body.
Correct, but then in C++17 when Concepts Lite finally gets passed,
you'll just state the parameter type requirements without any sneaky
hook in the signature.
Personally I would like to get all kinds of using-declarations in all
contexts. "Using" a namespace name as a member-declaration should make
an individually ADL-associated function, and make the name usable
without qualification in members. (Using a member from a local context
should un-hide the name, reversing the effect of any surrounding local
context.)
Alternately you could ask for a lambda function in an unevaluated
context, as long as it's the postfix-expression of a function call. You
could have decltype( []{ using std::ilogb; return ilogb( t() ); }() ) .
My sense is that adding using declarations into subexpressions, where no
other declarations may occur, would be too narrow and too irregular.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Sun, 3 Nov 2013 17:14:31 -0800
Raw View
--001a1133458ecf5bd504ea4fa538
Content-Type: text/plain; charset=ISO-8859-1
>even in C++14, SFINAE is on the signature and/or return type of a
function, not the body.
No, SFINAE is in the body. Consider:
template <typename Integral>
Integral add(Integral left, Integral right)
{
return left + right;
}
template <typename T>
std::vector<T> add(std::vector<T> left, std::vector<T> const& right)
{
left.insert(left.begin(), right.begin(), right.end());
return left;
}
int main()
{
std::vector<double> test;
std::vector<double> test2;
test.push_back(42.0);
std::vector<double> result(add(test, test2));
}
Note that template argument deduction runs before overload resolution.
Trying to substitute std::vector<double> for "Integral" above produces:
std::vector<double> add(std::vector<double> left, std::vector<double> right)
{
return left + right;
}
which is invalid because vector has no operator+. Thus substitution fails
and this overload is removed from the candidate set. The mechanisms like
enable_if by which people abuse this mechanism for metaprogramming is an
unintended side effect of the feature of allowing code like the above to
compile.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Sun, Nov 3, 2013 at 1:43 AM, Sebastian Mach <mach.seb@gmail.com> wrote:
>
> If you omit the trailing-return-type, then you get return type deduction
>> in C++14, which seems to do what you want in this case. It can be
>> slightly brittle, but if you use it purely to bring the using
>> declaration outside the function scope, the danger should be contained.
>>
>
> But then I couldn't use SFINAE, right? I.e., afair, even in C++14, SFINAE
> is on the signature and/or return type of a function, not the body.
>
> I don't have a fabulously great example, but I try (I omit std::declval
> for readability here):
>
> template <typename T>
> auto foo (T lhs, T rhs)
> -> decltype(sin(lhs[0] + lhs[0])) // State that T must have a subscript
> operator that yields an addable type for which 'sin' must be defined
> {
> ....
> }
>
> template <typename T>
> auto foo (T lhs, T rhs) -> decltype(sin(lhs + lhs)) // State that T itself
> is an addable type
> {
> ....
> }
>
> In C++14, I could just use
>
> template <typename T> auto foo (T lhs, T rhs) {....}
> template <typename T> auto foo (T lhs, T rhs) {....}
>
> which is then ambiguous.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1133458ecf5bd504ea4fa538
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>>even in C++14, SFINAE is on the signature and/or =
return type of a function, not the body.<br></div><div>No, SFINAE is in the=
body. Consider:</div><div>=A0</div><div><font face=3D"courier new,monospac=
e">template <typename Integral><br>
Integral add(Integral left, Integral right)<br>{<br>=A0=A0=A0 return left +=
right;<br>}</font></div><div><font face=3D"courier new,monospace">template=
<typename T><br>std::vector<T> add(std::vector<T> left, =
std::vector<T> const& right)<br>
{<br>=A0=A0=A0 left.insert(left.begin(), right.begin(), right.end());<br>=
=A0=A0=A0 return left;<br>}</font></div><div><font face=3D"courier new,mono=
space">int main()<br>{<br>=A0=A0=A0 std::vector<double> test;<br>=A0=
=A0=A0 std::vector<double> test2;<br>
=A0=A0=A0 test.push_back(42.0);<br>=A0=A0=A0 std::vector<double> resu=
lt(add(test, test2));<br>}</font><br></div><div>Note that template argument=
deduction runs before overload resolution. Trying to substitute std::vecto=
r<double> for "Integral" above produces:</div>
<div>=A0</div><div><font face=3D"courier new,monospace">std::vector<doub=
le> add(std::vector<double> left, std::vector<double> right)=
<br>{<br>=A0=A0=A0 return left + right;<br>}</font><br></div><div>which is =
invalid because vector has no operator+. Thus substitution fails and this o=
verload is removed from the candidate set. The mechanisms like <font face=
=3D"courier new,monospace">enable_if</font> by which people abuse this mech=
anism for metaprogramming is an unintended side effect of the feature of al=
lowing code like the above to compile.</div>
<div>=A0</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div =
dir=3D"ltr"><div>Billy O'Neal</div><div><a href=3D"https://bitbucket.or=
g/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</a></div><d=
iv><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_=
blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sun, Nov 3, 2013 at 1:43 AM, Sebastia=
n Mach <span dir=3D"ltr"><<a href=3D"mailto:mach.seb@gmail.com" target=
=3D"_blank">mach.seb@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-le=
ft-width:1px;border-left-style:solid">If you omit the trailing-return-type,=
then you get return type deduction=20
<br>in C++14, which seems to do what you want in this case. It can be=20
<br>slightly brittle, but if you use it purely to bring the using=20
<br>declaration outside the function scope, the danger should be contained.
<br></blockquote><div><br>But then I couldn't use SFINAE, right? I.e., =
afair, even in C++14, SFINAE is on the signature and/or return type of a fu=
nction, not the body.<br><br>I don't have a fabulously great example, b=
ut I try (I omit std::declval for readability here):<br>
<span style=3D"font-family:courier new,monospace"><br>template <typename=
T><br>auto foo (T lhs, T rhs)<br>=A0-> decltype(sin(lhs[0] + lhs[0])=
) // State that T must have a subscript operator that yields an addable typ=
e for which 'sin' must be defined<br>
{<br>=A0=A0=A0 ....<br>}<br><br>template <typename T><br>auto foo (T =
lhs, T rhs) ->=20
decltype(sin(lhs + lhs)) // State that T itself is an addable type<br>{<br>=
=A0=A0=A0 ....<br>}</span><br><br>In C++14, I could just use <br><br><span =
style=3D"font-family:courier new,monospace">template <typename T> aut=
o foo (T lhs, T rhs) {....}<br>
template <typename T> auto foo (T lhs, T rhs) {....}</span><br><br>wh=
ich is then ambiguous.<br></div></div><div class=3D"HOEnZb"><div class=3D"h=
5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1133458ecf5bd504ea4fa538--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 4 Nov 2013 05:59:12 +0200
Raw View
--001a1134a67a55c8fb04ea51f092
Content-Type: text/plain; charset=ISO-8859-1
On 4 November 2013 03:14, Billy O'Neal <billy.oneal@gmail.com> wrote:
> >even in C++14, SFINAE is on the signature and/or return type of a
> function, not the body.
> No, SFINAE is in the body. Consider:
>
There's no such thing as "SFINAE in the body".
> template <typename Integral>
> Integral add(Integral left, Integral right)
> {
> return left + right;
> }
> template <typename T>
> std::vector<T> add(std::vector<T> left, std::vector<T> const& right)
> {
> left.insert(left.begin(), right.begin(), right.end());
> return left;
> }
> int main()
> {
> std::vector<double> test;
> std::vector<double> test2;
> test.push_back(42.0);
> std::vector<double> result(add(test, test2));
> }
> Note that template argument deduction runs before overload resolution.
> Trying to substitute std::vector<double> for "Integral" above produces:
>
> std::vector<double> add(std::vector<double> left, std::vector<double>
> right)
> {
> return left + right;
> }
> which is invalid because vector has no operator+. Thus substitution fails
> and this overload is removed from the candidate set. The mechanisms like
> enable_if by which people abuse this mechanism for metaprogramming is an
> unintended side effect of the feature of allowing code like the above to
> compile.
>
>
>
That's not how it works. The "Integral" overload isn't removed, but the
vector<T> overload
is a better match, so the Integral overload's definition is never
instantiated for vector. If such
an instantiation would be attempted, it would be a hard error, not a SFINAE
case.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1134a67a55c8fb04ea51f092
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 November 2013 03:14, Billy O'Neal <span dir=3D"ltr"><<a=
href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail.=
com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><div>>=
even in C++14, SFINAE is on the signature and/or return type of a function,=
not the body.<br>
</div></div><div>No, SFINAE is in the body. Consider:</div></div></blockquo=
te><div><br></div><div>There's no such thing as "SFINAE=A0 in the =
body".<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>=A0</div><div><font face=3D"courier new,monospace">te=
mplate <typename Integral><br>
Integral add(Integral left, Integral right)<br>{<br>=A0=A0=A0 return left +=
right;<br>}</font></div><div><font face=3D"courier new,monospace">template=
<typename T><br>std::vector<T> add(std::vector<T> left, =
std::vector<T> const& right)<br>
{<br>=A0=A0=A0 left.insert(left.begin(), right.begin(), right.end());<br>=
=A0=A0=A0 return left;<br>}</font></div><div><font face=3D"courier new,mono=
space">int main()<br>{<br>=A0=A0=A0 std::vector<double> test;<br>=A0=
=A0=A0 std::vector<double> test2;<br>
=A0=A0=A0 test.push_back(42.0);<br>=A0=A0=A0 std::vector<double> resu=
lt(add(test, test2));<br>}</font><br></div><div>Note that template argument=
deduction runs before overload resolution. Trying to substitute std::vecto=
r<double> for "Integral" above produces:</div>
<div>=A0</div><div><font face=3D"courier new,monospace">std::vector<doub=
le> add(std::vector<double> left, std::vector<double> right)=
<br>{<br>=A0=A0=A0 return left + right;<br>}</font><br></div><div>which is =
invalid because vector has no operator+. Thus substitution fails and this o=
verload is removed from the candidate set. The mechanisms like <font face=
=3D"courier new,monospace">enable_if</font> by which people abuse this mech=
anism for metaprogramming is an unintended side effect of the feature of al=
lowing code like the above to compile.</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div><br><br></div></font></span></div></blockquote><div><br></div><div>Tha=
t's not how it works.=A0 The "Integral" overload isn't re=
moved, but the vector<T> overload<br>is a better match, so the Integr=
al overload's definition is never instantiated for vector. If such <br>
an instantiation would be attempted, it would be a hard error, not a SFINAE=
case.<br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1134a67a55c8fb04ea51f092--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Sun, 3 Nov 2013 21:20:02 -0800
Raw View
--089e01183e36cbb94a04ea53137e
Content-Type: text/plain; charset=ISO-8859-1
Of course it is instantiated for vector -- it has to, otherwise overload
resolution can't run. (How could overload resolution choose which one was
the better match before the declaration for the template function was
generated?)
See also N3485 13.3.1 [over.match.funcs]/7:
In each case where a candidate is a function template, candidate function
template specializations are generated
using template argument deduction (14.8.3, 14.8.2). Those candidates are
then handled as candidate
functions in the usual way.
which clearly says that template argument deduction happens when generating
the candidate set, before overload resolution occurs.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Sun, Nov 3, 2013 at 7:59 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 4 November 2013 03:14, Billy O'Neal <billy.oneal@gmail.com> wrote:
>
>> >even in C++14, SFINAE is on the signature and/or return type of a
>> function, not the body.
>> No, SFINAE is in the body. Consider:
>>
>
> There's no such thing as "SFINAE in the body".
>
>
>> template <typename Integral>
>> Integral add(Integral left, Integral right)
>> {
>> return left + right;
>> }
>> template <typename T>
>> std::vector<T> add(std::vector<T> left, std::vector<T> const& right)
>> {
>> left.insert(left.begin(), right.begin(), right.end());
>> return left;
>> }
>> int main()
>> {
>> std::vector<double> test;
>> std::vector<double> test2;
>> test.push_back(42.0);
>> std::vector<double> result(add(test, test2));
>> }
>> Note that template argument deduction runs before overload resolution.
>> Trying to substitute std::vector<double> for "Integral" above produces:
>>
>> std::vector<double> add(std::vector<double> left, std::vector<double>
>> right)
>> {
>> return left + right;
>> }
>> which is invalid because vector has no operator+. Thus substitution fails
>> and this overload is removed from the candidate set. The mechanisms like
>> enable_if by which people abuse this mechanism for metaprogramming is an
>> unintended side effect of the feature of allowing code like the above to
>> compile.
>>
>>
>>
> That's not how it works. The "Integral" overload isn't removed, but the
> vector<T> overload
> is a better match, so the Integral overload's definition is never
> instantiated for vector. If such
> an instantiation would be attempted, it would be a hard error, not a
> SFINAE case.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e01183e36cbb94a04ea53137e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Of course it is instantiated for vector -- it has to,=
otherwise overload resolution can't run. (How could overload resolutio=
n choose which one was the better match before the declaration for the temp=
late function was generated?)</div>
<div>=A0</div><div>See also N3485 13.3.1 [over.match.funcs]/7:</div><div>=
=A0</div><div><font face=3D"LMRoman10-Regular"><font face=3D"LMRoman10-Regu=
lar"><p align=3D"LEFT">In each case where a candidate is a function templat=
e, candidate function template specializations are generated</p>
</font></font><p align=3D"LEFT"><font face=3D"LMRoman10-Regular"><font face=
=3D"LMRoman10-Regular">using template argument deduction (</font></font><fo=
nt color=3D"#0000ff" face=3D"LMRoman10-Regular"><font color=3D"#0000ff" fac=
e=3D"LMRoman10-Regular"><font color=3D"#0000ff" face=3D"LMRoman10-Regular">=
14.8.3</font></font></font><font face=3D"LMRoman10-Regular"><font face=3D"L=
MRoman10-Regular">, </font></font><font color=3D"#0000ff" face=3D"LMRoman10=
-Regular"><font color=3D"#0000ff" face=3D"LMRoman10-Regular"><font color=3D=
"#0000ff" face=3D"LMRoman10-Regular">14.8.2</font></font></font><font face=
=3D"LMRoman10-Regular"><font face=3D"LMRoman10-Regular">). Those candidates=
are then handled as candidate</font></font></p>
<font face=3D"LMRoman10-Regular"><font face=3D"LMRoman10-Regular">
</font></font><p><font face=3D"LMRoman10-Regular"><font face=3D"LMRoman10-R=
egular">functions in the usual way.</font></font></p>which clearly says tha=
t template argument deduction happens when generating the candidate set, be=
fore overload resolution occurs.</div>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sun, Nov 3, 2013 at 7:59 PM, Ville Vo=
utilainen <span dir=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.c=
om" target=3D"_blank">ville.voutilainen@gmail.com</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote"><div class=3D"im">On 4 November 2013 03:14, Billy O'Neal <span =
dir=3D"ltr"><<a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">=
billy.oneal@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><div><div>>even in C++14, SFINAE is on=
the signature and/or return type of a function, not the body.<br>
</div></div><div>No, SFINAE is in the body. Consider:</div></div></blockquo=
te><div><br></div></div><div>There's no such thing as "SFINAE=A0 i=
n the body".<br><br></div><div class=3D"im"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-colo=
r:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div>=A0</div><div><font face=3D"courier new,monospace">te=
mplate <typename Integral><br>
Integral add(Integral left, Integral right)<br>{<br>=A0=A0=A0 return left +=
right;<br>}</font></div><div><font face=3D"courier new,monospace">template=
<typename T><br>std::vector<T> add(std::vector<T> left, =
std::vector<T> const& right)<br>
{<br>=A0=A0=A0 left.insert(left.begin(), right.begin(), right.end());<br>=
=A0=A0=A0 return left;<br>}</font></div><div><font face=3D"courier new,mono=
space">int main()<br>{<br>=A0=A0=A0 std::vector<double> test;<br>=A0=
=A0=A0 std::vector<double> test2;<br>
=A0=A0=A0 test.push_back(42.0);<br>=A0=A0=A0 std::vector<double> resu=
lt(add(test, test2));<br>}</font><br></div><div>Note that template argument=
deduction runs before overload resolution. Trying to substitute std::vecto=
r<double> for "Integral" above produces:</div>
<div>=A0</div><div><font face=3D"courier new,monospace">std::vector<doub=
le> add(std::vector<double> left, std::vector<double> right)=
<br>{<br>=A0=A0=A0 return left + right;<br>}</font><br></div><div>which is =
invalid because vector has no operator+. Thus substitution fails and this o=
verload is removed from the candidate set. The mechanisms like <font face=
=3D"courier new,monospace">enable_if</font> by which people abuse this mech=
anism for metaprogramming is an unintended side effect of the feature of al=
lowing code like the above to compile.</div>
<span><font color=3D"#888888">
<div><br><br></div></font></span></div></blockquote><div><br></div></div><d=
iv>That's not how it works.=A0 The "Integral" overload isn=
9;t removed, but the vector<T> overload<br>is a better match, so the =
Integral overload's definition is never instantiated for vector. If suc=
h <br>
an instantiation would be attempted, it would be a hard error, not a SFINAE=
case.<br></div></div><br></div></div><div class=3D"HOEnZb"><div class=3D"h=
5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01183e36cbb94a04ea53137e--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 4 Nov 2013 07:29:12 +0200
Raw View
--089e013cba283c365e04ea533229
Content-Type: text/plain; charset=ISO-8859-1
On 4 November 2013 07:20, Billy O'Neal <billy.oneal@gmail.com> wrote:
> Of course it is instantiated for vector -- it has to, otherwise overload
> resolution can't run. (How could
>
Its declaration is, its definition isn't. Partial ordering doesn't
instantiate function bodies.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e013cba283c365e04ea533229
Content-Type: text/html; charset=ISO-8859-1
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 4 November 2013 07:20, Billy O'Neal <span dir="ltr"><<a href="mailto:billy.oneal@gmail.com" target="_blank">billy.oneal@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Of course it is instantiated for vector -- it has to, otherwise overload resolution can't run. (How could </div>
</div></blockquote><div><br></div><div>Its declaration is, its definition isn't. Partial ordering doesn't instantiate function bodies.<br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--089e013cba283c365e04ea533229--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 04 Nov 2013 13:31:33 +0800
Raw View
On 11/4/13 1:20 PM, Billy O'Neal wrote:
> Of course it is instantiated for vector -- it has to, otherwise overload
> resolution can't run. (How could overload resolution choose which one was
> the better match before the declaration for the template function was
> generated?)
You might want to take a step back and look at what you're arguing.
You've just implied that SFINAE is incapable of hiding a function
definition from an incompatible type. You said that the definition of
every candidate is instantiated before overload resolution occurs.
The process is like this:
1. Find candidate declarations.
2. Instantiate candidate template declarations. Ignore errors here, and
candidates that cause them.
3. Find the best candidate. If it's defined as = delete, fail.
*If* this is an evaluated context (not sizeof or decltype), then there's
one more step:
4. If a template was selected, instantiate its definition.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Sun, 3 Nov 2013 22:01:40 -0800
Raw View
--001a113334a0b6502404ea53a839
Content-Type: text/plain; charset=ISO-8859-1
That would work too :) :sigh: I'm getting all confused by Clause 13 and
Clause 14.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Sun, Nov 3, 2013 at 9:31 PM, David Krauss <potswa@gmail.com> wrote:
> On 11/4/13 1:20 PM, Billy O'Neal wrote:
>
>> Of course it is instantiated for vector -- it has to, otherwise overload
>> resolution can't run. (How could overload resolution choose which one was
>> the better match before the declaration for the template function was
>> generated?)
>>
>
> You might want to take a step back and look at what you're arguing. You've
> just implied that SFINAE is incapable of hiding a function definition from
> an incompatible type. You said that the definition of every candidate is
> instantiated before overload resolution occurs.
>
> The process is like this:
>
> 1. Find candidate declarations.
> 2. Instantiate candidate template declarations. Ignore errors here, and
> candidates that cause them.
> 3. Find the best candidate. If it's defined as = delete, fail.
>
> *If* this is an evaluated context (not sizeof or decltype), then there's
> one more step:
>
> 4. If a template was selected, instantiate its definition.
>
>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
> proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113334a0b6502404ea53a839
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">That would work too :) :sigh: I'm getting all confused=
by Clause 13 and Clause 14.</div><div class=3D"gmail_extra"><br clear=3D"a=
ll"><div><div dir=3D"ltr"><div>Billy O'Neal</div><div><a href=3D"https:=
//bitbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONea=
l/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sun, Nov 3, 2013 at 9:31 PM, David Kr=
auss <span dir=3D"ltr"><<a href=3D"mailto:potswa@gmail.com" target=3D"_b=
lank">potswa@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<div class=3D"im">On 11/4/13 1:20 PM, Billy O'Neal wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">
Of course it is instantiated for vector -- it has to, otherwise overload<br=
>
resolution can't run. (How could overload resolution choose which one w=
as<br>
the better match before the declaration for the template function was<br>
generated?)<br>
</blockquote>
<br></div>
You might want to take a step back and look at what you're arguing. You=
've just implied that SFINAE is incapable of hiding a function definiti=
on from an incompatible type. You said that the definition of every candida=
te is instantiated before overload resolution occurs.<br>
<br>
The process is like this:<br>
<br>
1. Find candidate declarations.<br>
2. Instantiate candidate template declarations. Ignore errors here, and can=
didates that cause them.<br>
3. Find the best candidate. If it's defined as =3D delete, fail.<br>
<br>
*If* this is an evaluated context (not sizeof or decltype), then there'=
s one more step:<br>
<br>
4. If a template was selected, instantiate its definition.<div class=3D"HOE=
nZb"><div class=3D"h5"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113334a0b6502404ea53a839--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 4 Nov 2013 08:06:52 +0200
Raw View
--089e013cba28ec785204ea53b8ee
Content-Type: text/plain; charset=ISO-8859-1
On 4 November 2013 08:01, Billy O'Neal <billy.oneal@gmail.com> wrote:
> That would work too :) :sigh: I'm getting all confused by Clause 13 and
> Clause 14.
>
[over.match.best]/1, last bullet:
" F1 and F2 are function template specializations, and the function
template for F1 is more specialized than the template for F2 according to
the partial ordering rules described in 14.5.6.2."
14.5.6.2 is [temp.func.order], and there paragraphs 3 and 4 describe the
rest. The body
of the function template does not participate in partial ordering at all.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e013cba28ec785204ea53b8ee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 November 2013 08:01, Billy O'Neal <span dir=3D"ltr"><<a=
href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail.=
com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">That wou=
ld work too :) :sigh: I'm getting all confused by Clause 13 and Clause =
14.</div>
</blockquote><div><br>[over.match.best]/1, last bullet:<br><br>" F1 an=
d F2 are function template specializations, and the function template for F=
1 is more specialized than the template for F2 according to the partial ord=
ering rules described in 14.5.6.2."<br>
<br></div><div>14.5.6.2 is [temp.func.order], and there paragraphs 3 and 4 =
describe the rest. The body<br></div><div>of the function template does not=
participate in partial ordering at all.<br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013cba28ec785204ea53b8ee--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Sun, 3 Nov 2013 22:09:05 -0800
Raw View
--089e0153884840f46904ea53c3c5
Content-Type: text/plain; charset=ISO-8859-1
It was not my understanding that it would participate in partial ordering
-- it was my understanding that the function which resulted in the invalid
body wouldn't participate in overload resolution at all. ( I believe I was
incorrect, however )
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Sun, Nov 3, 2013 at 10:06 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 4 November 2013 08:01, Billy O'Neal <billy.oneal@gmail.com> wrote:
>
>> That would work too :) :sigh: I'm getting all confused by Clause 13 and
>> Clause 14.
>>
>
> [over.match.best]/1, last bullet:
>
> " F1 and F2 are function template specializations, and the function
> template for F1 is more specialized than the template for F2 according to
> the partial ordering rules described in 14.5.6.2."
>
> 14.5.6.2 is [temp.func.order], and there paragraphs 3 and 4 describe the
> rest. The body
> of the function template does not participate in partial ordering at all.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0153884840f46904ea53c3c5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It was not my understanding that it would participate in p=
artial ordering -- it was my understanding that the function which resulted=
in the invalid body wouldn't participate in overload resolution at all=
..=A0( I believe I was incorrect, however )</div>
<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" targe=
t=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http:/=
/stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stacko=
verflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sun, Nov 3, 2013 at 10:06 PM, Ville V=
outilainen <span dir=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.=
com" target=3D"_blank">ville.voutilainen@gmail.com</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote"><div class=3D"im">On 4 November 2013 08:01, Billy O'Neal <span =
dir=3D"ltr"><<a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">=
billy.oneal@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">That would work too :) :sigh: I'm get=
ting all confused by Clause 13 and Clause 14.</div>
</blockquote></div><div><br>[over.match.best]/1, last bullet:<br><br>"=
F1 and F2 are function template specializations, and the function template=
for F1 is more specialized than the template for F2 according to the parti=
al ordering rules described in 14.5.6.2."<br>
<br></div><div>14.5.6.2 is [temp.func.order], and there paragraphs 3 and 4 =
describe the rest. The body<br></div><div>of the function template does not=
participate in partial ordering at all.<br></div></div><br></div></div>
<div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0153884840f46904ea53c3c5--
.
Author: Sebastian Mach <mach.seb@gmail.com>
Date: Mon, 4 Nov 2013 00:57:58 -0800 (PST)
Raw View
------=_Part_90_18325768.1383555478145
Content-Type: text/plain; charset=ISO-8859-1
I realise that the namespace workaround can yield problems:
namespace mix_cmath {
using std::cos;
template <typename T> auto cos (T a) -> decltype(cos(a));
}
This yields an ambiguity on g++:
error: 'template<class T> decltype (cos(a)) gaudy::find_cmath::cos(T)'
conflicts with previous using declaration 'template<class _Tp> constexpr
typename __gnu_cxx::__enable_if<std::__is_integer<_Tp>::__value,
double>::__type std::cos(_Tp)'
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_90_18325768.1383555478145
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I realise that the namespace workaround can yield problems=
:<br><br> namespace mix_cmath {<br> &nbs=
p; using std::cos;<br>  =
; template <typename T> auto cos (T a) -> decltype(cos(a));<=
br> }<br><br>This yields an ambiguity on g++:<br><br>&nbs=
p;error: 'template<class T> decltype (cos(a)) gaudy::find_cmath::cos(=
T)' conflicts with previous using declaration 'template<class _Tp> co=
nstexpr typename __gnu_cxx::__enable_if<std::__is_integer<_Tp>::__=
value, double>::__type std::cos(_Tp)'<br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_90_18325768.1383555478145--
.
Author: Sebastian Mach <mach.seb@gmail.com>
Date: Mon, 4 Nov 2013 02:55:23 -0800 (PST)
Raw View
------=_Part_2560_8259803.1383562523113
Content-Type: text/plain; charset=ISO-8859-1
Here is a more general workaround that works without introducing function
signatures in the workaround namespaces (and so without provoking
ambiguities):
namespace mix_cmath {
using std::cos;
template <typename T> using cos_type =
decltype(cos(std::declval<T>()));
}
template <typename T>
mix_cmath::cos_type<T> sin (T);
However, I would find the following better still:
template <typename T>
auto cos (T t) -> decltype(using std::cos; cos(t));
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2560_8259803.1383562523113
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Here is a more general workaround that works without intro=
ducing function signatures in the workaround namespaces (and so without pro=
voking ambiguities):<br><br> namespace mix_cmath {<=
br> using std::cos;<br> &nbs=
p; template <typename T> using cos_type=
=3D decltype(cos(std::declval<T>()));<br> }<=
br><br> template <typename T><br> =
mix_cmath::cos_type<T> sin (T);<br><br><br>However, I wo=
uld find the following better still:<br><br> template <=
;typename T><br> auto cos (T t) -> decltype(using s=
td::cos; cos(t));</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2560_8259803.1383562523113--
.
Author: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Mon, 4 Nov 2013 12:32:28 +0100
Raw View
--047d7b111d075a9f6d04ea5845a8
Content-Type: text/plain; charset=ISO-8859-1
Am 04.11.2013 09:57 schrieb "Sebastian Mach" <mach.seb@gmail.com>:
>
> I realise that the namespace workaround can yield problems:
>
> namespace mix_cmath {
> using std::cos;
> template <typename T> auto cos (T a) -> decltype(cos(a));
> }
>
> This yields an ambiguity on g++:
>
This looks like an inproper application of the trick. Why would you give
the "signatur template" the same name as the function you want to find?
Don't see a reason for that (given the drawbacks) and hence no need for a
workaround.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b111d075a9f6d04ea5845a8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Am 04.11.2013 09:57 schrieb "Sebastian Mach" <<a href=3D"mailt=
o:mach.seb@gmail.com">mach.seb@gmail.com</a>>:<br>
><br>
> I realise that the namespace workaround can yield problems:<br>
><br>
> =A0=A0=A0 namespace mix_cmath {<br>
> =A0=A0=A0=A0=A0=A0=A0 using std::cos;<br>
> =A0=A0=A0=A0=A0=A0=A0 template <typename T> auto cos (T a) ->=
decltype(cos(a));<br>
> =A0=A0=A0 }<br>
><br>
> This yields an ambiguity on g++:<br>
></p>
<p dir=3D"ltr">This looks like an inproper application of the trick. Why wo=
uld you give the "signatur template" the same name as the functio=
n you want to find? Don't see a reason for that (given the drawbacks) a=
nd hence no need for a workaround.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b111d075a9f6d04ea5845a8--
.