Topic: Any reason not to allow more types of function overloads?
Author: gmisocpp@gmail.com
Date: Wed, 19 Mar 2014 19:05:46 -0700 (PDT)
Raw View
------=_Part_187_28127114.1395281146044
Content-Type: text/plain; charset=UTF-8
Consider this program:
#include <cstdio>
int printf( const char* string_not_format ) // optimal/safe version for 1
argument
{
fputs( string_not_format, stdout );
return 0;
}
int main()
{
printf( "No need to scan me for % characters. Just print me.\n" );
}
Compiled with clang++, it yields ambiguity as you may or may not have
expected:
clang++ vp.cpp -ovp.exe
vp.cpp:11:5: error: call to 'printf' is ambiguous
printf( "No need to scan me for % characters. Just print me.\n" );
^~~~~~
....\stdio.h:378:15: note: candidate function
int __cdecl printf(const char * __restrict__ _Format,...);
^
vp.cpp:3:5: note: candidate function
int printf( const char* string_not_format ) // optimal/safe version for 1
argument
^
1 error generated.
If C++ supported, overloads in this manner, the above program would be a
possibility and in this particular example it would possibly present an
opportunity for optimization without requiring compiler heroics to do that.
It may even catch bugs:
string fmt = from_the_unknown(); // Oooo no....
printf( fmt.c_str() );
This is a made-up example use case, but hopefully demonstrates one
potential use case that could fix bugs and improve performance.
Are there good reasons not to allow a proposal like this, which is where in
the presence of variable length argument overloads, prefer more
specific matches if they exist, like the above example of picking a
specific char* match over the variable length arg one?
Thanks
--
---
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_187_28127114.1395281146044
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Consider this program:</div><div><br></div><div>#incl=
ude <cstdio></div><div><br></div><div>int printf( const char* string_=
not_format ) // optimal/safe version for 1 argument<br>{<br> &nb=
sp; fputs( string_not_format, stdout );<br> return 0;<br>=
}</div><div>int main()<br>{<br> printf( "No need to scan =
me for % characters. Just print me.\n" ); <br>}</div><div><br></div><div>Co=
mpiled with clang++, it yields ambiguity as you may or may not have ex=
pected:</div><div><br></div><div>clang++ vp.cpp -ovp.exe<br>vp.cpp:11:=
5: error: call to 'printf' is ambiguous<br> printf( "No n=
eed to scan me for % characters. Just print me.\n" );<br> =
^~~~~~<br>...\stdio.h:378:15: note: candidate function<br> int __cde=
cl printf(const char * __restrict__ _Format,...);<br> &nbs=
p; ^<br>vp.cpp:3:5: n=
ote: candidate function<br>int printf( const char* string_not_format ) // o=
ptimal/safe version for 1 argument<br> ^<br>1 error gener=
ated.</div><div><br></div><div>If C++ supported, overloads in this manner, =
the above program would be a possibility and in this particular example it =
would possibly present an opportunity for optimization without requiring co=
mpiler heroics to do that.</div><div><br></div><div>It may even catch bugs:=
</div><div>string fmt =3D from_the_unknown(); // Oooo no....</div><div>prin=
tf( fmt.c_str() );</div><div><br></div><div>This is a made-up example use c=
ase, but hopefully demonstrates one potential use case that could=
fix bugs and improve performance.</div><div><br></div><div>Are there good =
reasons not to allow a proposal like this, which is where in the presence o=
f variable length argument overloads, prefer more specific matches if =
they exist, like the above example of picking a specific char* match o=
ver the variable length arg one?</div><div><br></div><div>Thanks</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_187_28127114.1395281146044--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Wed, 19 Mar 2014 21:25:18 -0700
Raw View
--089e0149c3807e910804f5022a1c
Content-Type: text/plain; charset=UTF-8
> Are there good reasons not to allow a proposal like this, which is where
in the presence of variable length argument overloads, prefer more
specific matches if they exist, like the above example of picking a
specific char* match over the variable length arg one?
Yes; namely, that variadic functions are not type safe ever. You can't pass
e.g. a std::string to a variadic function, for example.
The C++11 solution to this is to declare a variadic function template
rather than a variadic function. Variadic function templates operate in the
manner you expect here.
template<typename... Args>
void Example(Args&&... args)
{
}
void Example()
{
}
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
On Wed, Mar 19, 2014 at 7:05 PM, <gmisocpp@gmail.com> wrote:
> Consider this program:
>
> #include <cstdio>
>
> int printf( const char* string_not_format ) // optimal/safe version for 1
> argument
> {
> fputs( string_not_format, stdout );
> return 0;
> }
> int main()
> {
> printf( "No need to scan me for % characters. Just print me.\n" );
> }
>
> Compiled with clang++, it yields ambiguity as you may or may not have
> expected:
>
> clang++ vp.cpp -ovp.exe
> vp.cpp:11:5: error: call to 'printf' is ambiguous
> printf( "No need to scan me for % characters. Just print me.\n" );
> ^~~~~~
> ...\stdio.h:378:15: note: candidate function
> int __cdecl printf(const char * __restrict__ _Format,...);
> ^
> vp.cpp:3:5: note: candidate function
> int printf( const char* string_not_format ) // optimal/safe version for 1
> argument
> ^
> 1 error generated.
>
> If C++ supported, overloads in this manner, the above program would be a
> possibility and in this particular example it would possibly present an
> opportunity for optimization without requiring compiler heroics to do that.
>
> It may even catch bugs:
> string fmt = from_the_unknown(); // Oooo no....
> printf( fmt.c_str() );
>
> This is a made-up example use case, but hopefully demonstrates one
> potential use case that could fix bugs and improve performance.
>
> Are there good reasons not to allow a proposal like this, which is where
> in the presence of variable length argument overloads, prefer more
> specific matches if they exist, like the above example of picking a
> specific char* match over the variable length arg one?
>
> Thanks
>
> --
>
> ---
> 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/.
--089e0149c3807e910804f5022a1c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> Are there good reasons not to allow a proposal like t=
his, which is=20
where in the presence of variable length argument overloads, prefer more
specific=C2=A0matches if they exist,=C2=A0like the above example of pickin=
g a=20
specific char* match over the variable length arg one?<div><br></div><div>Y=
es; namely, that variadic functions are not type safe ever. You can't p=
ass e.g. a std::string to a variadic function, for example.<br><br>The C++1=
1 solution to this is to declare a variadic function template rather than a=
variadic function. Variadic function templates operate in the manner you e=
xpect here.<br>
<br>template<typename... Args><br>void Example(Args&&... args=
)<br>{<br>}<br><br>void Example()<br>{<br></div><div>}<br></div><div><br></=
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.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">htt=
p://stackoverflow.com/users/82320/billy-oneal</a></div>
</div></div>
<br><br><div class=3D"gmail_quote">On Wed, Mar 19, 2014 at 7:05 PM, <span =
dir=3D"ltr"><<a href=3D"mailto:gmisocpp@gmail.com" target=3D"_blank">gmi=
socpp@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:1ex">
<div dir=3D"ltr"><div>Consider this program:</div><div><br></div><div>#incl=
ude <cstdio></div><div><br></div><div>int printf( const char* string_=
not_format ) // optimal/safe version for 1 argument<br>{<br>=C2=A0=C2=A0=C2=
=A0 fputs( string_not_format, stdout );<br>
=C2=A0=C2=A0=C2=A0 return 0;<br>}</div><div>int main()<br>{<br>=C2=A0=C2=A0=
=C2=A0 printf( "No need to scan me for % characters. Just print me.\n&=
quot; ); <br>}</div><div><br></div><div>Compiled=C2=A0with clang++, it yiel=
ds ambiguity as you may or may not have expected:</div>
<div><br></div><div>clang++=C2=A0vp.cpp -ovp.exe<br>vp.cpp:11:5: error: cal=
l to 'printf' is ambiguous<br>=C2=A0=C2=A0=C2=A0 printf( "No n=
eed to scan me for % characters. Just print me.\n" );<br>=C2=A0=C2=A0=
=C2=A0 ^~~~~~<br>...\stdio.h:378:15: note: candidate function<br>
=C2=A0 int __cdecl printf(const char * __restrict__ _Format,...);<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^<=
br>vp.cpp:3:5: note: candidate function<br>int printf( const char* string_n=
ot_format ) // optimal/safe version for 1 argument<br>=C2=A0=C2=A0=C2=A0 ^<=
br>1 error generated.</div>
<div><br></div><div>If C++ supported, overloads in this manner, the above p=
rogram would be a possibility and in this particular example it would possi=
bly present an opportunity for optimization without requiring compiler hero=
ics to do that.</div>
<div><br></div><div>It may even catch bugs:</div><div>string fmt =3D from_t=
he_unknown(); // Oooo no....</div><div>printf( fmt.c_str() );</div><div><br=
></div><div>This is a made-up example use case, but hopefully demonstrates=
=C2=A0one potential use case that=C2=A0could fix bugs and improve performan=
ce.</div>
<div><br></div><div>Are there good reasons not to allow a proposal like thi=
s, which is where in the presence of variable length argument overloads, pr=
efer more specific=C2=A0matches if they exist,=C2=A0like the above example =
of picking a specific char* match over the variable length arg one?</div>
<div><br></div><div>Thanks</div><span class=3D"HOEnZb"><font color=3D"#8888=
88"><div><br></div></font></span></div><span class=3D"HOEnZb"><font color=
=3D"#888888">
<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 <a href=3D"mailto:std-proposals+unsubscribe@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>
</font></span></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
--089e0149c3807e910804f5022a1c--
.
Author: gmisocpp@gmail.com
Date: Wed, 19 Mar 2014 22:24:42 -0700 (PDT)
Raw View
------=_Part_123_19187077.1395293082605
Content-Type: text/plain; charset=UTF-8
On Thursday, March 20, 2014 5:25:18 PM UTC+13, Billy O'Neal wrote:
>
> > Are there good reasons not to allow a proposal like this, which is where
> in the presence of variable length argument overloads, prefer more
> specific matches if they exist, like the above example of picking a
> specific char* match over the variable length arg one?
>
> Yes; namely, that variadic functions are not type safe ever. You can't
> pass e.g. a std::string to a variadic function, for example.
>
> The C++11 solution to this is to declare a variadic function template
> rather than a variadic function. Variadic function templates operate in the
> manner you expect here.
>
> template<typename... Args>
> void Example(Args&&... args)
> {
> }
>
> void Example()
> {
> }
>
>
> Billy O'Neal
>
Yes, and what I was thinking can't be used to even fix the C API as C can't
overload at al. Doh!
This does make me wonder now if the printf API would ever be re-implemented
as a C++ api in the way that you are describing.
I'm not aware of any implementation that does that, but I'm curious what
would stop that being viable and what gain there might be.
One gain would be from the example I gave in the first post, but I think
compilers possibly make that substitution anyway.
Thanks
--
---
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_123_19187077.1395293082605
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, March 20, 2014 5:25:18 PM UTC+13, Bil=
ly O'Neal wrote:<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-left-style: solid;"><div dir=3D"ltr">> Are ther=
e good reasons not to allow a proposal like this, which is=20
where in the presence of variable length argument overloads, prefer more
specific matches if they exist, like the above example of pickin=
g a=20
specific char* match over the variable length arg one?<div><br></div><div>Y=
es; namely, that variadic functions are not type safe ever. You can't pass =
e.g. a std::string to a variadic function, for example.<br><br>The C++11 so=
lution to this is to declare a variadic function template rather than a var=
iadic function. Variadic function templates operate in the manner you expec=
t here.<br>
<br>template<typename... Args><br>void Example(Args&&... args=
)<br>{<br>}<br><br>void Example()<br>{<br></div><div>}<br></div><div><br></=
div></div><div><br clear=3D"all"><div><div dir=3D"ltr">
<div>Billy O'Neal</div></div></div></div></blockquote><div><br></div><div>Y=
es, and what I was thinking can't be used to even fix t=
he C API as C can't overload at al. Doh!</div><div>This does make me w=
onder now if the printf API would ever be re-implemented as a&nbs=
p;C++ api in the way that you are describing.</div><div>I'm not aware of an=
y implementation that does that, but I'm curious what would stop that being=
viable and what gain there might be.</div><div>One gain would be from the =
example I gave in the first post, but I think compilers possibly make that =
substitution anyway.</div><div><br></div><div>Thanks</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_123_19187077.1395293082605--
.
Author: "=?utf-8?B?YmlsbHkub25lYWxAZ21haWwuY29t?=" <billy.oneal@gmail.com>
Date: Wed, 19 Mar 2014 22:49:31 -0700
Raw View
------=_Part_0_1395294571350
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
That would break conforming programs which try to create a function pointer to printf, for instance. It would also break conforming programs which already escaped the printf input. E.g. your proposal silently changes the output of the following:
#include <cstdio>
int main() {
std::printf("Hello %% world");
}
Overloads with subtly different behaviors are bad. Silently changing program behavior is bad too.
If you want literal string printing use std::printf("%s", "string here") or std::puts(" string here").
Sent from a touchscreen. Please excuse the brevity and tpyos.
----- Reply message -----
From: gmisocpp@gmail.com
To: <std-proposals@isocpp.org>
Subject: [std-proposals] Any reason not to allow more types of function overloads?
Date: Wed, Mar 19, 2014 10:24 PM
On Thursday, March 20, 2014 5:25:18 PM UTC+13, Billy O'Neal wrote:> Are there good reasons not to allow a proposal like this, which is
where in the presence of variable length argument overloads, prefer more
specific matches if they exist, like the above example of picking a
specific char* match over the variable length arg one?
Yes; namely, that variadic functions are not type safe ever. You can't pass e.g. a std::string to a variadic function, for example.
The C++11 solution to this is to declare a variadic function template rather than a variadic function. Variadic function templates operate in the manner you expect here.
template<typename... Args>
void Example(Args&&... args)
{
}
void Example()
{
}
Billy O'Neal
Yes, and what I was thinking can't be used to even fix the C API as C can't overload at al. Doh!
This does make me wonder now if the printf API would ever be re-implemented as a C++ api in the way that you are describing.
I'm not aware of any implementation that does that, but I'm curious what would stop that being viable and what gain there might be.
One gain would be from the example I gave in the first post, but I think compilers possibly make that substitution anyway.
Thanks
--
---
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/.
------=_Part_0_1395294571350
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
<div style=3D"font-size: 12pt; font-family: Calibri,sans-serif;"><div>That =
would break conforming programs which try to create a function pointer to p=
rintf, for instance. It would also break conforming programs which already =
escaped the printf input. E.g. your proposal silently changes the output of=
the following:</div><div><br></div><div>#include <cstdio></div><div>=
int main() {</div><div> std::printf("Hello %% world");</div><d=
iv>}</div><div><br></div><div>Overloads with subtly different behaviors are=
bad. Silently changing program behavior is bad too.</div><div><br></div><d=
iv>If you want literal string printing use std::printf("%s", "string here")=
or std::puts(" string here").</div><div><br></div><div>Sent from a touchsc=
reen. Please excuse the brevity and tpyos.</div><br><div id=3D"htc_header">=
----- Reply message -----<br>From: gmisocpp@gmail.com<br>To: <std-propos=
als@isocpp.org><br>Subject: [std-proposals] Any reason not to allow more=
types of function overloads?<br>Date: Wed, Mar 19, 2014 10:24 PM</div></di=
v><br><div dir=3D"ltr"><br><br>On Thursday, March 20, 2014 5:25:18 PM UTC+1=
3, Billy O'Neal wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">> Ar=
e there good reasons not to allow a proposal like this, which is=20
where in the presence of variable length argument overloads, prefer more
specific matches if they exist, like the above example of pickin=
g a=20
specific char* match over the variable length arg one?<div><br></div><div>Y=
es; namely, that variadic functions are not type safe ever. You can't pass =
e.g. a std::string to a variadic function, for example.<br><br>The C++11 so=
lution to this is to declare a variadic function template rather than a var=
iadic function. Variadic function templates operate in the manner you expec=
t here.<br>
<br>template<typename... Args><br>void Example(Args&&... args=
)<br>{<br>}<br><br>void Example()<br>{<br></div><div>}<br></div><div><br></=
div></div><div><br clear=3D"all"><div><div dir=3D"ltr">
<div>Billy O'Neal</div></div></div></div></blockquote><div><br></div><div>Y=
es, and what I was thinking can't be used to even fix t=
he C API as C can't overload at al. Doh!</div><div>This does make me w=
onder now if the printf API would ever be re-implemented as a&nbs=
p;C++ api in the way that you are describing.</div><div>I'm not aware of an=
y implementation that does that, but I'm curious what would stop that being=
viable and what gain there might be.</div><div>One gain would be from the =
example I gave in the first post, but I think compilers possibly make that =
substitution anyway.</div><div><br></div><div>Thanks</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_0_1395294571350--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 20 Mar 2014 19:23:05 +0800
Raw View
--Apple-Mail=_BC915FE3-F722-43B8-A755-08670598B7B7
Content-Type: text/plain; charset=ISO-8859-1
On 2014-03-20, at 1:49 PM, billy.oneal@gmail.com wrote:
> That would break conforming programs which try to create a function pointer to printf, for instance.
I think the proposal is to introduce an overload precedence where an empty list matches the absence of any parameters better than it matches a C-style ellipsis. I don't think he proposes to add a printf overload to std::.
I like the idea; my first intuition was that it should work this way. It would also make some SFINAE introspection tricks easier. Currently you have to pass a dummy into the ellipsis just to "make it work."
--
---
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/.
--Apple-Mail=_BC915FE3-F722-43B8-A755-08670598B7B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03–20, at 1:49 PM, <a href=3D"mailto:billy.oneal@gmail.com">bil=
ly.oneal@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline">=
<blockquote type=3D"cite"><div style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style=3D"font-size: =
12pt; font-family: Calibri, sans-serif;"><div>That would break conforming p=
rograms which try to create a function pointer to printf, for instance.</di=
v></div></div></blockquote><div><br></div><div>I think the proposal is to i=
ntroduce an overload precedence where an empty list matches the absence of =
any parameters better than it matches a C-style ellipsis. I don’t thi=
nk he proposes to add a printf overload to <font face=3D"Courier">std::</fo=
nt>.</div><div><br></div><div>I like the idea; my first intuition was that =
it should work this way. It would also make some SFINAE introspection trick=
s easier. Currently you have to pass a dummy into the ellipsis just to &ldq=
uo;make it work.”</div></div><br></body></html>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
--Apple-Mail=_BC915FE3-F722-43B8-A755-08670598B7B7--
.
Author: gmisocpp@gmail.com
Date: Thu, 20 Mar 2014 13:57:27 -0700 (PDT)
Raw View
------=_Part_1208_7905545.1395349047519
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi
On Friday, March 21, 2014 12:23:05 AM UTC+13, David Krauss wrote:
>
>
> On 2014=E2=80=9303=E2=80=9320, at 1:49 PM, billy...@gmail.com <javascript=
:> wrote:
>
> That would break conforming programs which try to create a function=20
> pointer to printf, for instance.
>
>
> I think the proposal is to introduce an overload precedence where an empt=
y=20
> list matches the absence of any parameters better than it matches a C-sty=
le=20
> ellipsis. I don=E2=80=99t think he proposes to add a printf overload to s=
td::.
>
> I like the idea; my first intuition was that it should work this way. It=
=20
> would also make some SFINAE introspection tricks easier. Currently you ha=
ve=20
> to pass a dummy into the ellipsis just to =E2=80=9Cmake it work.=E2=80=9D
>
>
Yes that was the motivation.
Billy's reply has got me wondering what a C++ printf would gain over the C=
=20
version if built along the lines of Billy's reply and as also mentioned on=
=20
Bjarnes Home Page, but I'm not proposing that.
--=20
---=20
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 e=
mail 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-proposa=
ls/.
------=_Part_1208_7905545.1395349047519
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi<br><br>On Friday, March 21, 2014 12:23:05 AM UTC+13, Da=
vid Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div style=3D"-ms-word-wrap: =
break-word;"><br><div><div>On 2014=E2=80=9303=E2=80=9320, at 1:49 PM, <a on=
mousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;" href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"kUhybr3A4VMJ">billy...@gmail.com</a> wrote:</div><br><b=
lockquote type=3D"cite"><div style=3D"font: 12px/normal Helvetica; text-tra=
nsform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; =
white-space: normal; font-size-adjust: none; font-stretch: normal;"><div st=
yle=3D"font-family: Calibri,sans-serif; font-size: 12pt;"><div>That would b=
reak conforming programs which try to create a function pointer to printf, =
for instance.</div></div></div></blockquote><div><br></div><div>I think the=
proposal is to introduce an overload precedence where an empty list matche=
s the absence of any parameters better than it matches a C-style ellipsis. =
I don=E2=80=99t think he proposes to add a printf overload to <font face=3D=
"Courier">std::</font>.</div><div><br></div><div>I like the idea; my first =
intuition was that it should work this way. It would also make some SFINAE =
introspection tricks easier. Currently you have to pass a dummy into the el=
lipsis just to =E2=80=9Cmake it work.=E2=80=9D</div></div><br></div></block=
quote><div><br></div><div>Yes that was the motivation.</div><div><br></div>=
<div>Billy's reply has got me wondering what a C++ printf would gain over t=
he C version if built along the lines of Billy's reply and as also mentione=
d on Bjarnes Home Page, but I'm not proposing that.</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_1208_7905545.1395349047519--
.