Topic: Any proposals on Boost.Swap?
Author: Lingxi Li <lilingxi.cs@gmail.com>
Date: Sat, 10 Oct 2015 05:15:39 -0700 (PDT)
Raw View
------=_Part_3861_78741209.1444479339177
Content-Type: multipart/alternative;
boundary="----=_Part_3862_730596519.1444479339177"
------=_Part_3862_730596519.1444479339177
Content-Type: text/plain; charset=UTF-8
Hi,
I'm wondering if there were any proposals or discussions on evolving
std::swap to boost::swap. While current std::swap always uses the the
generic swap algorithm, boost::swap is able to exploit specialized
algorithms found via ADL if any. When boost::swap is available, I see no
reason to use the current std::swap. So, It seems reasonable to just
implement std::swap the way boost::swap is.
--
---
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_3862_730596519.1444479339177
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>I'm wondering if there were any proposals o=
r discussions on evolving <font face=3D"courier new, monospace" style=3D"ba=
ckground-color: rgb(238, 238, 238);">std::swap</font> to <font face=3D"cour=
ier new, monospace" style=3D"background-color: rgb(238, 238, 238);">boost::=
swap</font>. While current <font face=3D"courier new, monospace" style=3D"b=
ackground-color: rgb(238, 238, 238);">std::swap</font> always uses the the =
generic swap algorithm, <span style=3D"background-color: rgb(238, 238, 238)=
;"><font face=3D"courier new, monospace">boost::swap</font></span> is able =
to exploit specialized algorithms found via ADL if any. When <font face=3D"=
courier new, monospace" style=3D"background-color: rgb(238, 238, 238);">boo=
st::swap</font> is available, I see no reason to use the current <span styl=
e=3D"background-color: rgb(238, 238, 238);"><font face=3D"courier new, mono=
space">std::swap</font></span>. So, It seems reasonable to just implement <=
font face=3D"courier new, monospace" style=3D"background-color: rgb(238, 23=
8, 238);">std::swap</font>=C2=A0the way <font face=3D"courier new, monospac=
e" style=3D"background-color: rgb(238, 238, 238);">boost::swap</font> is.<b=
r></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_3862_730596519.1444479339177--
------=_Part_3861_78741209.1444479339177--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 10 Oct 2015 08:52:47 -0700
Raw View
On Saturday 10 October 2015 05:15:39 Lingxi Li wrote:
> Hi,
>
> I'm wondering if there were any proposals or discussions on evolving
> std::swap to boost::swap. While current std::swap always uses the the
> generic swap algorithm, boost::swap is able to exploit specialized
> algorithms found via ADL if any. When boost::swap is available, I see no
> reason to use the current std::swap. So, It seems reasonable to just
> implement std::swap the way boost::swap is.
How can boost::swap be more efficient than ADL-provided swap methods for a given
type T?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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: Andrey Semashev <andrey.semashev@gmail.com>
Date: Sat, 10 Oct 2015 19:05:48 +0300
Raw View
On 10.10.2015 18:52, Thiago Macieira wrote:
> On Saturday 10 October 2015 05:15:39 Lingxi Li wrote:
>> Hi,
>>
>> I'm wondering if there were any proposals or discussions on evolving
>> std::swap to boost::swap. While current std::swap always uses the the
>> generic swap algorithm, boost::swap is able to exploit specialized
>> algorithms found via ADL if any. When boost::swap is available, I see no
>> reason to use the current std::swap. So, It seems reasonable to just
>> implement std::swap the way boost::swap is.
>
> How can boost::swap be more efficient than ADL-provided swap methods for a given
> type T?
It uses the swap implementation found with ADL or std::swap, if there
isn't one. It also contains various compiler bug workarounds. The
essential advantage of boost::swap over std::swap is that you can always
call qualified boost::swap from the generic code and be sure that the
most efficient implementation is used.
I would go even further with this proposal and made the new swap() call
member swap() function on one of the arguments, if there is such member
function.
--
---
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: David Krauss <potswa@gmail.com>
Date: Sun, 11 Oct 2015 00:07:21 +0800
Raw View
--Apple-Mail=_6F3DC412-4D58-472E-9E4C-003C3E272C52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9310, at 11:52 PM, Thiago Macieira <thiago@macie=
ira.org> wrote:
>=20
> How can boost::swap be more efficient than ADL-provided swap methods for =
a given=20
> type T?
I think that he=E2=80=99s proposing that the qualified call =E2=80=9Cstd::s=
wap=E2=80=9D should use ADL. I mentioned this recently in the thread =E2=80=
=9CP0117: Generic to_string/to_wstring functions.=E2=80=9D
Recap:
> On 2015=E2=80=9310=E2=80=9302, at 3:37 PM, David Krauss <potswa@gmail.com=
> wrote:
>=20
> Question for all: Must qualified std::swap be supported as an accessor to=
the three-move algorithm, e.g. for ADL overloads that add side-effects but=
not optimization?
>=20
> Perhaps it would be a good idea, going forward, to forbid ADL hooks from =
calling their std:: counterparts, so that std may encapsulate ADL.
> On 2015=E2=80=9310=E2=80=9302, at 4:12 PM, David Krauss <potswa@gmail.com=
> wrote:
>=20
>> On 2015=E2=80=9310=E2=80=9302, at 4:07 PM, Sam Kellett <samkellett@gmail=
..com <mailto:samkellett@gmail.com>> wrote:
>>=20
>> how would a user differentiate between a customization hook and somethin=
g that isn't (like the rest of the std:: namespace)?=20
>=20
> They wouldn=E2=80=99t. There would be no way to bypass a third-party libr=
ary=E2=80=99s internal swap details, which sounds like a good thing.
>=20
> It=E2=80=99s true, this would break libraries with bugs for which the wor=
karound is to qualify std::swap. I=E2=80=99ll add to my question, is that b=
reakage significant, either?
--=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/.
--Apple-Mail=_6F3DC412-4D58-472E-9E4C-003C3E272C52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9310, at 11:52 PM, Thiago Macieira <<a href=3D"mailto:thiago@maci=
eira.org" class=3D"">thiago@macieira.org</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D""><span style=3D"font-family: Helve=
tica; font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: no=
ne; display: inline !important;" class=3D"">How can boost::swap be more eff=
icient than ADL-provided swap methods for a given<span class=3D"Apple-conve=
rted-space"> </span></span><br style=3D"font-family: Helvetica; font-s=
ize: 12px; font-style: normal; font-variant: normal; font-weight: normal; l=
etter-spacing: normal; line-height: normal; orphans: auto; text-align: star=
t; text-indent: 0px; text-transform: none; white-space: normal; widows: aut=
o; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span sty=
le=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-var=
iant: normal; font-weight: normal; letter-spacing: normal; line-height: nor=
mal; orphans: auto; text-align: start; text-indent: 0px; text-transform: no=
ne; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stro=
ke-width: 0px; float: none; display: inline !important;" class=3D"">type T?=
</span><br style=3D"font-family: Helvetica; font-size: 12px; font-style: no=
rmal; font-variant: normal; font-weight: normal; letter-spacing: normal; li=
ne-height: normal; orphans: auto; text-align: start; text-indent: 0px; text=
-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px;" class=3D""></div></blockquote></div><br class=
=3D""><div class=3D"">I think that he=E2=80=99s proposing that the qualifie=
d call =E2=80=9C<font face=3D"Courier" class=3D"">std::swap</font>=E2=80=9D=
should use ADL. I mentioned this recently in the thread =E2=80=9C<span sty=
le=3D"font-family: 'Helvetica Neue';" class=3D"">P0117: Generic to_string/t=
o_wstring functions.</span><font face=3D"Helvetica Neue" class=3D"">=E2=80=
=9D</font></div><div class=3D""><span style=3D"font-family: 'Helvetica Neue=
';" class=3D""><br class=3D""></span></div><div class=3D""><span style=3D"f=
ont-family: 'Helvetica Neue';" class=3D"">Recap:</span></div><div class=3D"=
"><span style=3D"font-family: 'Helvetica Neue';" class=3D""><br class=3D"">=
</span></div><div class=3D""><blockquote type=3D"cite" class=3D""><div clas=
s=3D"">On 2015=E2=80=9310=E2=80=9302, at 3:37 PM, David Krauss <<a href=
=3D"mailto:potswa@gmail.com" class=3D"">potswa@gmail.com</a>> wrote:</di=
v><br class=3D"Apple-interchange-newline"><div class=3D""><div class=3D""><=
div class=3D"">Question for all: Must qualified <font face=3D"Courier"=
class=3D"">std::swap</font> be supported as an accessor to the three-=
move algorithm, e.g. for ADL overloads that add side-effects but not optimi=
zation?</div></div><div class=3D""><br class=3D""></div><div class=3D"">Per=
haps it would be a good idea, going forward, to forbid ADL hooks from calli=
ng their <font face=3D"Courier" class=3D"">std::</font> counterpa=
rts, so that <font face=3D"Courier" class=3D"">std</font> may enc=
apsulate ADL.</div></div></blockquote></div><div class=3D""><div class=3D""=
><div class=3D""><br class=3D""></div></div></div><div class=3D""><br class=
=3D""></div><div class=3D""><blockquote type=3D"cite" class=3D""><div class=
=3D"">On 2015=E2=80=9310=E2=80=9302, at 4:12 PM, David Krauss <<a href=
=3D"mailto:potswa@gmail.com" class=3D"">potswa@gmail.com</a>> wrote:</di=
v><br class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"" s=
tyle=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break=
: after-white-space;"><div class=3D""><blockquote type=3D"cite" class=3D"">=
<div class=3D"">On 2015=E2=80=9310=E2=80=9302, at 4:07 PM, Sam Kellett <=
<a href=3D"mailto:samkellett@gmail.com" class=3D"">samkellett@gmail.com</a>=
> wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><d=
iv dir=3D"ltr" class=3D""><div class=3D"gmail_extra">how would a user diffe=
rentiate between a customization hook and something that isn't (like the re=
st of the std:: namespace)? </div></div></div></blockquote></div><br c=
lass=3D""><div class=3D"">They wouldn=E2=80=99t. There would be no way to b=
ypass a third-party library=E2=80=99s internal <font face=3D"Courier" =
class=3D"">swap</font> details, which sounds like a good thing.</div><=
div class=3D""><br class=3D""></div><div class=3D"">It=E2=80=99s true, this=
would break libraries with bugs for which the workaround is to qualify&nbs=
p;<font face=3D"Courier" class=3D"">std::swap</font>. I=E2=80=99ll add to m=
y question, is that breakage significant, either?</div></div></div></blockq=
uote><div class=3D""><div class=3D""><div class=3D"" style=3D"word-wrap: br=
eak-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"=
><div class=3D""><br class=3D""></div></div></div></div></div></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=_6F3DC412-4D58-472E-9E4C-003C3E272C52--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 10 Oct 2015 19:29:25 +0300
Raw View
On 10 October 2015 at 19:07, David Krauss <potswa@gmail.com> wrote:
> I think that he=E2=80=99s proposing that the qualified call =E2=80=9Cstd:=
:swap=E2=80=9D should use
> ADL. I mentioned this recently in the thread =E2=80=9CP0117: Generic
> to_string/to_wstring functions.=E2=80=9D
I don't think that's what he's proposing. In the aforementioned
thread, I quipped
"I have seen ruminations about a std::adl_swap that pulls in ADL."
and boost::swap does exactly what the envisioned adl_swap would do. The
way boost::swap does it could be adopted as the technique for doing it
directly in std::swap instead of adding a separate function.
--=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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 10 Oct 2015 19:32:02 +0300
Raw View
On 10 October 2015 at 19:29, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> and boost::swap does exactly what the envisioned adl_swap would do. The
> way boost::swap does it could be adopted as the technique for doing it
> directly in std::swap instead of adding a separate function.
...although after 10 more seconds, I don't know how to do that without ending up
with infinite recursion. :)
--
---
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: Lingxi Li <lilingxi.cs@gmail.com>
Date: Sat, 10 Oct 2015 09:33:03 -0700 (PDT)
Raw View
------=_Part_3292_530070793.1444494783626
Content-Type: multipart/alternative;
boundary="----=_Part_3293_897017050.1444494783626"
------=_Part_3293_897017050.1444494783626
Content-Type: text/plain; charset=UTF-8
On Sunday, October 11, 2015 at 12:05:54 AM UTC+8, Andrey Semashev wrote:
>
> On 10.10.2015 18:52, Thiago Macieira wrote:
> > On Saturday 10 October 2015 05:15:39 Lingxi Li wrote:
> >> Hi,
> >>
> >> I'm wondering if there were any proposals or discussions on evolving
> >> std::swap to boost::swap. While current std::swap always uses the the
> >> generic swap algorithm, boost::swap is able to exploit specialized
> >> algorithms found via ADL if any. When boost::swap is available, I see
> no
> >> reason to use the current std::swap. So, It seems reasonable to just
> >> implement std::swap the way boost::swap is.
> >
> > How can boost::swap be more efficient than ADL-provided swap methods for
> a given
> > type T?
>
> It uses the swap implementation found with ADL or std::swap, if there
> isn't one. It also contains various compiler bug workarounds. The
> essential advantage of boost::swap over std::swap is that you can always
> call qualified boost::swap from the generic code and be sure that the
> most efficient implementation is used.
>
> I would go even further with this proposal and made the new swap() call
> member swap() function on one of the arguments, if there is such member
> function.
>
>
Yeah, that's a really nice idea! And there are ways to check whether a
given class has a member function with a specified name and signature.
SFINAE then comes in and the implementation is done.
--
---
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_3293_897017050.1444494783626
Content-Type: text/html; charset=UTF-8
<br><br>On Sunday, October 11, 2015 at 12:05:54 AM UTC+8, Andrey Semashev wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10.10.2015 18:52, Thiago Macieira wrote:
<br>> On Saturday 10 October 2015 05:15:39 Lingxi Li wrote:
<br>>> Hi,
<br>>>
<br>>> I'm wondering if there were any proposals or discussions on evolving
<br>>> std::swap to boost::swap. While current std::swap always uses the the
<br>>> generic swap algorithm, boost::swap is able to exploit specialized
<br>>> algorithms found via ADL if any. When boost::swap is available, I see no
<br>>> reason to use the current std::swap. So, It seems reasonable to just
<br>>> implement std::swap the way boost::swap is.
<br>>
<br>> How can boost::swap be more efficient than ADL-provided swap methods for a given
<br>> type T?
<br>
<br>It uses the swap implementation found with ADL or std::swap, if there
<br>isn't one. It also contains various compiler bug workarounds. The
<br>essential advantage of boost::swap over std::swap is that you can always
<br>call qualified boost::swap from the generic code and be sure that the
<br>most efficient implementation is used.
<br>
<br>I would go even further with this proposal and made the new swap() call
<br>member swap() function on one of the arguments, if there is such member
<br>function.
<br>
<br></blockquote><div><br></div><div>Yeah, that's a really nice idea! And there are ways to check whether a given class has a member function with a specified name and signature. SFINAE then comes in and the implementation is done.</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 <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<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 />
------=_Part_3293_897017050.1444494783626--
------=_Part_3292_530070793.1444494783626--
.
Author: Lingxi Li <lilingxi.cs@gmail.com>
Date: Sat, 10 Oct 2015 09:49:58 -0700 (PDT)
Raw View
------=_Part_705_510777750.1444495798329
Content-Type: multipart/alternative;
boundary="----=_Part_706_1068891093.1444495798329"
------=_Part_706_1068891093.1444495798329
Content-Type: text/plain; charset=UTF-8
On Sunday, October 11, 2015 at 12:32:04 AM UTC+8, Ville Voutilainen wrote:
>
> On 10 October 2015 at 19:29, Ville Voutilainen
> <ville.vo...@gmail.com <javascript:>> wrote:
> > and boost::swap does exactly what the envisioned adl_swap would do. The
> > way boost::swap does it could be adopted as the technique for doing it
> > directly in std::swap instead of adding a separate function.
>
> ..although after 10 more seconds, I don't know how to do that without
> ending up
> with infinite recursion. :)
>
So, is requiring all specialized swap algorithms to overload std::swap the
right way to go? ~>_<~
--
---
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_706_1068891093.1444495798329
Content-Type: text/html; charset=UTF-8
<div dir="ltr">On Sunday, October 11, 2015 at 12:32:04 AM UTC+8, Ville Voutilainen wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10 October 2015 at 19:29, Ville Voutilainen
<br><<a href="javascript:" target="_blank" gdf-obfuscated-mailto="edUwfSFlDQAJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">ville.vo...@gmail.com</a>> wrote:
<br>> and boost::swap does exactly what the envisioned adl_swap would do. The
<br>> way boost::swap does it could be adopted as the technique for doing it
<br>> directly in std::swap instead of adding a separate function.
<br>
<br>..although after 10 more seconds, I don't know how to do that without ending up
<br>with infinite recursion. :)
<br></blockquote><div><br></div><div>So, is requiring all specialized swap algorithms to overload <span style="background-color: rgb(238, 238, 238);"><font face="courier new, monospace">std::swap</font></span> the right way to go? ~>_<~</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 <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<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 />
------=_Part_706_1068891093.1444495798329--
------=_Part_705_510777750.1444495798329--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 11 Oct 2015 00:51:51 +0800
Raw View
--Apple-Mail=_45B6A257-0C72-41DC-A5EB-3E4CF949D4E1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9311, at 12:29 AM, Ville Voutilainen <ville.vout=
ilainen@gmail.com> wrote:
>=20
> I don't think that's what he's proposing. In the aforementioned
> thread, I quipped
> "I have seen ruminations about a std::adl_swap that pulls in ADL."
> and boost::swap does exactly what the envisioned adl_swap would do. The
> way boost::swap does it could be adopted as the technique for doing it
> directly in std::swap instead of adding a separate function.
How is that different from what I said? I=E2=80=99m a little interested to =
hear what you thought I was saying, if there=E2=80=99s another alternative=
=E2=80=A6
The implementation is a bit tricky but infinite recursion should be limited=
to cases where the class-specific implementation delegates back to std::sw=
ap, which seems like an anti-pattern. (But, one seemingly worthy of support=
..)
--=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/.
--Apple-Mail=_45B6A257-0C72-41DC-A5EB-3E4CF949D4E1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9311, at 12:29 AM, Ville Voutilainen <<a href=3D"mailto:ville.vou=
tilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>> wrote:</=
div><br class=3D"Apple-interchange-newline"><div class=3D"">I don't think t=
hat's what he's proposing. In the aforementioned<br class=3D"">thread, I qu=
ipped<br class=3D"">"I have seen ruminations about a std::adl_swap that pul=
ls in ADL."<br class=3D"">and boost::swap does exactly what the envisioned =
adl_swap would do. The<br class=3D"">way boost::swap does it could be adopt=
ed as the technique for doing it<br class=3D"">directly in std::swap instea=
d of adding a separate function.<br class=3D""></div></blockquote></div><di=
v class=3D""><br class=3D""></div><div class=3D""><div class=3D"">How is th=
at different from what I said? I=E2=80=99m a little interested to hear what=
you thought I was saying, if there=E2=80=99s another alternative=E2=80=A6<=
/div></div><div class=3D""><br class=3D""></div><div class=3D"">The impleme=
ntation is a bit tricky but infinite recursion should be limited to cases w=
here the class-specific implementation delegates back to <font face=3D"Cour=
ier" class=3D"">std::swap</font>, which seems like an anti-pattern. (But, o=
ne seemingly worthy of support.)</div><div class=3D""><br class=3D""></div>=
</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=_45B6A257-0C72-41DC-A5EB-3E4CF949D4E1--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 11 Oct 2015 00:53:20 +0800
Raw View
--Apple-Mail=_14AF1082-4C7D-47EF-B24A-BB3B5FFD3A8E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9311, at 12:49 AM, Lingxi Li <lilingxi.cs@gmail.=
com> wrote:
>=20
> So, is requiring all specialized swap algorithms to overload std::swap th=
e right way to go? ~>_<~
Users are not allowed to overload std::swap.
Explicit template specialization of std::swap is legal but it=E2=80=99s not=
a very good technique.
--=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/.
--Apple-Mail=_14AF1082-4C7D-47EF-B24A-BB3B5FFD3A8E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9311, at 12:49 AM, Lingxi Li <<a href=3D"mailto:lilingxi.cs@gmail=
..com" class=3D"">lilingxi.cs@gmail.com</a>> wrote:</div><br class=3D"App=
le-interchange-newline"><div class=3D""><span style=3D"font-family: Helveti=
ca; font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none=
; display: inline !important;" class=3D"">So, is requiring all specialized =
swap algorithms to overload<span class=3D"Apple-converted-space"> </sp=
an></span><span style=3D"font-family: Helvetica; font-size: 12px; font-styl=
e: normal; font-variant: normal; font-weight: normal; letter-spacing: norma=
l; line-height: normal; orphans: auto; text-align: start; text-indent: 0px;=
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px=
; -webkit-text-stroke-width: 0px; background-color: rgb(238, 238, 238);" cl=
ass=3D""><font face=3D"courier new, monospace" class=3D"">std::swap</font><=
/span><span style=3D"font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant: normal; font-weight: normal; letter-spacing: normal; l=
ine-height: normal; orphans: auto; text-align: start; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -w=
ebkit-text-stroke-width: 0px; float: none; display: inline !important;" cla=
ss=3D""><span class=3D"Apple-converted-space"> </span>the right way to=
go? ~>_<~</span></div></blockquote></div><br class=3D""><div class=
=3D"">Users are not allowed to overload <font face=3D"Courier" class=3D"">s=
td::swap</font>.</div><div class=3D""><br class=3D""></div><div class=3D"">=
Explicit template specialization of <font face=3D"Courier" class=3D"">std::=
swap</font> is legal but it=E2=80=99s not a very good technique.</div><div =
class=3D""><br class=3D""></div></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=_14AF1082-4C7D-47EF-B24A-BB3B5FFD3A8E--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 10 Oct 2015 20:00:44 +0300
Raw View
On 10 October 2015 at 19:51, David Krauss <potswa@gmail.com> wrote:
>
> On 2015=E2=80=9310=E2=80=9311, at 12:29 AM, Ville Voutilainen <ville.vout=
ilainen@gmail.com>
> wrote:
>
> I don't think that's what he's proposing. In the aforementioned
> thread, I quipped
> "I have seen ruminations about a std::adl_swap that pulls in ADL."
> and boost::swap does exactly what the envisioned adl_swap would do. The
> way boost::swap does it could be adopted as the technique for doing it
> directly in std::swap instead of adding a separate function.
>
>
> How is that different from what I said? I=E2=80=99m a little interested t=
o hear what
> you thought I was saying, if there=E2=80=99s another alternative=E2=80=A6
I thought you might be suggesting that a qualified call to std::swap would =
do
ADL?
--=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/.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Sat, 10 Oct 2015 20:04:25 +0300
Raw View
On 10.10.2015 19:51, David Krauss wrote:
>
> The implementation is a bit tricky but infinite recursion should be
> limited to cases where the class-specific implementation delegates back
> to std::swap, which seems like an anti-pattern. (But, one seemingly
> worthy of support.)
I think the recursion is very possible in the most innocent cases. Like
calling std::swap on fundamental types or UDTs that don't define their
own swap overload.
Seems like a different name is needed after all (e.g. the mentioned
adl_swap).
--
---
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: David Krauss <potswa@gmail.com>
Date: Sun, 11 Oct 2015 01:11:24 +0800
Raw View
--Apple-Mail=_3DB15346-DCB8-4871-ADEA-D31818B2EA23
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9311, at 1:04 AM, Andrey Semashev <andrey.semash=
ev@gmail.com> wrote:
>=20
> I think the recursion is very possible in the most innocent cases. Like c=
alling std::swap on fundamental types or UDTs that don't define their own s=
wap overload.
That would be an implementation bug.
For a function to call its own name using ADL, without calling itself, requ=
ires using a differently-named function in a separate namespace. Having a f=
allback when no ADL overload is defined is icing on the cake=E2=80=A6 but a=
ll that would be hidden within the standard library.
--=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/.
--Apple-Mail=_3DB15346-DCB8-4871-ADEA-D31818B2EA23
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9311, at 1:04 AM, Andrey Semashev <<a href=3D"mailto:andrey.semas=
hev@gmail.com" class=3D"">andrey.semashev@gmail.com</a>> wrote:</div><br=
class=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
; float: none; display: inline !important;" class=3D"">I think the recursio=
n is very possible in the most innocent cases. Like calling std::swap on fu=
ndamental types or UDTs that don't define their own swap overload.</span><b=
r style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; line-height=
: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text=
-stroke-width: 0px;" class=3D""></div></blockquote></div><br class=3D""><di=
v class=3D"">That would be an implementation bug.</div><div class=3D""><br =
class=3D""></div><div class=3D"">For a function to call its own name using =
ADL, without calling itself, requires using a differently-named function in=
a separate namespace. Having a fallback when no ADL overload is defined is=
icing on the cake=E2=80=A6 but all that would be hidden within the standar=
d library.</div><div class=3D""><br class=3D""></div></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=_3DB15346-DCB8-4871-ADEA-D31818B2EA23--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 11 Oct 2015 01:13:01 +0800
Raw View
--Apple-Mail=_2C48E821-7E87-4955-AFBB-F5BC085EA589
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9311, at 1:00 AM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> I thought you might be suggesting that a qualified call to std::swap woul=
d do
> ADL?
Not as a core language extension. I just meant that the standard library wo=
uld do the recommended ADL for you.
--=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/.
--Apple-Mail=_2C48E821-7E87-4955-AFBB-F5BC085EA589
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9311, at 1:00 AM, Ville Voutilainen <<a href=3D"mailto:ville.vout=
ilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>> wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D""><span style=3D"f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant: n=
ormal; font-weight: normal; letter-spacing: normal; line-height: normal; or=
phans: auto; text-align: start; text-indent: 0px; text-transform: none; whi=
te-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-widt=
h: 0px; float: none; display: inline !important;" class=3D"">I thought you =
might be suggesting that a qualified call to std::swap would do</span><br s=
tyle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-v=
ariant: normal; font-weight: normal; letter-spacing: normal; line-height: n=
ormal; orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-st=
roke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-si=
ze: 12px; font-style: normal; font-variant: normal; font-weight: normal; le=
tter-spacing: normal; line-height: normal; orphans: auto; text-align: start=
; text-indent: 0px; text-transform: none; white-space: normal; widows: auto=
; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: =
inline !important;" class=3D"">ADL?</span><br style=3D"font-family: Helveti=
ca; font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""=
></div></blockquote></div><br class=3D""><div class=3D"">Not as a core lang=
uage extension. I just meant that the standard library would do the recomme=
nded ADL for you.</div><div class=3D""><br class=3D""></div></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=_2C48E821-7E87-4955-AFBB-F5BC085EA589--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 11 Oct 2015 01:33:28 +0800
Raw View
--Apple-Mail=_FBF18633-657E-4B06-B688-1445966EF873
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9311, at 1:13 AM, David Krauss <potswa@gmail.com=
> wrote:
>=20
>> On 2015=E2=80=9310=E2=80=9311, at 1:00 AM, Ville Voutilainen <ville.vout=
ilainen@gmail.com <mailto:ville.voutilainen@gmail.com>> wrote:
>>=20
>> I thought you might be suggesting that a qualified call to std::swap wou=
ld do
>> ADL?
>=20
> Not as a core language extension. I just meant that the standard library =
would do the recommended ADL for you.
To be fair, though, there shouldn=E2=80=99t be a normative difference betwe=
en the two alternatives. If the metaprogramming is too hard, the compiler c=
an just implement a special lookup rule, via __builtin_swap or whatever.
--=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/.
--Apple-Mail=_FBF18633-657E-4B06-B688-1445966EF873
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9311, at 1:13 AM, David Krauss <<a href=3D"mailto:potswa@gmail.co=
m" class=3D"">potswa@gmail.com</a>> wrote:</div><div class=3D""><div sty=
le=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;" class=3D""><br class=3D""><div class=3D""><blockquote t=
ype=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=E2=80=9311, at 1=
:00 AM, Ville Voutilainen <<a href=3D"mailto:ville.voutilainen@gmail.com=
" class=3D"">ville.voutilainen@gmail.com</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D""><span style=3D"font-family: Helve=
tica; font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: no=
ne; display: inline !important;" class=3D"">I thought you might be suggesti=
ng that a qualified call to std::swap would do</span><br style=3D"font-fami=
ly: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: normal; orphans: a=
uto; text-align: start; text-indent: 0px; text-transform: none; white-space=
: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"=
class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px; float: none; display: inline !important=
;" class=3D"">ADL?</span><br style=3D"font-family: Helvetica; font-size: 12=
px; font-style: normal; font-variant: normal; font-weight: normal; letter-s=
pacing: normal; line-height: normal; orphans: auto; text-align: start; text=
-indent: 0px; text-transform: none; white-space: normal; widows: auto; word=
-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div></blockquo=
te></div><br class=3D""></div></div><div style=3D"word-wrap: break-word; -w=
ebkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=3D"">=
Not as a core language extension. I just meant that the standard library wo=
uld do the recommended ADL for you.</div></blockquote><br class=3D""><div c=
lass=3D"">To be fair, though, there shouldn=E2=80=99t be a normative differ=
ence between the two alternatives. If the metaprogramming is too hard, the =
compiler can just implement a special lookup rule, via <font face=3D"Courie=
r" class=3D"">__builtin_swap</font> or whatever.</div><div class=3D""><br c=
lass=3D""></div></div></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=_FBF18633-657E-4B06-B688-1445966EF873--
.
Author: Lingxi Li <lilingxi.cs@gmail.com>
Date: Sat, 10 Oct 2015 11:02:20 -0700 (PDT)
Raw View
------=_Part_4057_593895320.1444500140433
Content-Type: multipart/alternative;
boundary="----=_Part_4058_616486471.1444500140433"
------=_Part_4058_616486471.1444500140433
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, October 11, 2015 at 12:53:24 AM UTC+8, David Krauss wrote:
>
>
> On 2015=E2=80=9310=E2=80=9311, at 12:49 AM, Lingxi Li <lilin...@gmail.com=
<javascript:>>=20
> wrote:
>
> So, is requiring all specialized swap algorithms to overload std::swap th=
e=20
> right way to go? ~>_<~
>
>
> Users are not allowed to overload std::swap.
>
> Explicit template specialization of std::swap is legal but it=E2=80=99s n=
ot a=20
> very good technique.
>
>
Is this because function template specializations must respect the=20
exception specifier of the main template, while overloads may not?
--=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_4058_616486471.1444500140433
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, October 11, 2015 at 12:53:24 AM UTC+8, David Krauss wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word">=
<br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9310=E2=80=9311, at 1=
2:49 AM, Lingxi Li <<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"MPDOnktmDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:';return true;" onclick=3D"this.href=3D'javascript:&#=
39;;return true;">lilin...@gmail.com</a>> wrote:</div><br><div><span sty=
le=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:n=
ormal;font-weight:normal;letter-spacing:normal;line-height:normal;text-alig=
n:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing=
:0px;float:none;display:inline!important">So, is requiring all specialized =
swap algorithms to overload<span>=C2=A0</span></span><span style=3D"font-fa=
mily:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-we=
ight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-=
indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgrou=
nd-color:rgb(238,238,238)"><font face=3D"courier new, monospace">std::swap<=
/font></span><span style=3D"font-family:Helvetica;font-size:12px;font-style=
:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-h=
eight:normal;text-align:start;text-indent:0px;text-transform:none;white-spa=
ce:normal;word-spacing:0px;float:none;display:inline!important"><span>=C2=
=A0</span>the right way to go? ~>_<~</span></div></blockquote></div><=
br><div>Users are not allowed to overload <font face=3D"Courier">std::swap<=
/font>.</div><div><br></div><div>Explicit template specialization of <font =
face=3D"Courier">std::swap</font> is legal but it=E2=80=99s not a very good=
technique.</div><div><br></div></div></blockquote><div><br></div><div>Is t=
his because function template specializations must respect the exception sp=
ecifier of the main template, while overloads may not?</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_4058_616486471.1444500140433--
------=_Part_4057_593895320.1444500140433--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 10 Oct 2015 12:48:20 -0700
Raw View
On Saturday 10 October 2015 19:05:48 Andrey Semashev wrote:
> It uses the swap implementation found with ADL or std::swap, if there
> isn't one. It also contains various compiler bug workarounds. The
> essential advantage of boost::swap over std::swap is that you can always
> call qualified boost::swap from the generic code and be sure that the
> most efficient implementation is used.
Again, I don't understand how it can be more efficient than:
using namespace std;
swap(x, y);
Please explain.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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: Miro Knejp <miro.knejp@gmail.com>
Date: Sat, 10 Oct 2015 21:59:07 +0200
Raw View
Am 10.10.2015 um 21:48 schrieb Thiago Macieira:
> On Saturday 10 October 2015 19:05:48 Andrey Semashev wrote:
>> It uses the swap implementation found with ADL or std::swap, if there
>> isn't one. It also contains various compiler bug workarounds. The
>> essential advantage of boost::swap over std::swap is that you can always
>> call qualified boost::swap from the generic code and be sure that the
>> most efficient implementation is used.
> Again, I don't understand how it can be more efficient than:
>
> using namespace std;
> swap(x, y);
>
> Please explain.
It's not about efficiency, it's about "boost::swap(x, y)" replacing the
two lines you had to write, thus turning it into a single expression
usable in noexcept(), decltype() etc.
--
---
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: Thiago Macieira <thiago@macieira.org>
Date: Sat, 10 Oct 2015 13:00:59 -0700
Raw View
On Saturday 10 October 2015 21:59:07 Miro Knejp wrote:
> Am 10.10.2015 um 21:48 schrieb Thiago Macieira:
> > On Saturday 10 October 2015 19:05:48 Andrey Semashev wrote:
> >> It uses the swap implementation found with ADL or std::swap, if there
> >> isn't one. It also contains various compiler bug workarounds. The
> >> essential advantage of boost::swap over std::swap is that you can always
> >> call qualified boost::swap from the generic code and be sure that the
> >> most efficient implementation is used.
> >
> > Again, I don't understand how it can be more efficient than:
> > using namespace std;
> > swap(x, y);
> >
> > Please explain.
>
> It's not about efficiency, it's about "boost::swap(x, y)" replacing the
> two lines you had to write, thus turning it into a single expression
> usable in noexcept(), decltype() etc.
So you want a library function that will do the two lines I wrote?
I think it would be a good idea.
But I also know the Standard Library is not too keen on convenience functions
that can be easily written, so I don't think it's going to happen.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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: Andrey Semashev <andrey.semashev@gmail.com>
Date: Sat, 10 Oct 2015 23:15:14 +0300
Raw View
On 10.10.2015 22:48, Thiago Macieira wrote:
> On Saturday 10 October 2015 19:05:48 Andrey Semashev wrote:
>> It uses the swap implementation found with ADL or std::swap, if there
>> isn't one. It also contains various compiler bug workarounds. The
>> essential advantage of boost::swap over std::swap is that you can always
>> call qualified boost::swap from the generic code and be sure that the
>> most efficient implementation is used.
>
> Again, I don't understand how it can be more efficient than:
>
> using namespace std;
> swap(x, y);
>
> Please explain.
On a conforming compiler the effect is the same. It's shorter to write
and doesn't bring the whole namespace std into your scope. You can see
the implementation for comments about workarounds used in such a
seemingly simple tool.
In addition, less experienced developers often write 'std::swap(x, y)',
which just skips ADL and always uses the generic implementation.
--
---
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: Miro Knejp <miro.knejp@gmail.com>
Date: Sat, 10 Oct 2015 22:21:31 +0200
Raw View
Am 10.10.2015 um 22:00 schrieb Thiago Macieira:
> On Saturday 10 October 2015 21:59:07 Miro Knejp wrote:
>> Am 10.10.2015 um 21:48 schrieb Thiago Macieira:
>>> On Saturday 10 October 2015 19:05:48 Andrey Semashev wrote:
>>>> It uses the swap implementation found with ADL or std::swap, if there
>>>> isn't one. It also contains various compiler bug workarounds. The
>>>> essential advantage of boost::swap over std::swap is that you can always
>>>> call qualified boost::swap from the generic code and be sure that the
>>>> most efficient implementation is used.
>>> Again, I don't understand how it can be more efficient than:
>>> using namespace std;
>>> swap(x, y);
>>>
>>> Please explain.
>> It's not about efficiency, it's about "boost::swap(x, y)" replacing the
>> two lines you had to write, thus turning it into a single expression
>> usable in noexcept(), decltype() etc.
> So you want a library function that will do the two lines I wrote?
>
> I think it would be a good idea.
>
> But I also know the Standard Library is not too keen on convenience functions
> that can be easily written, so I don't think it's going to happen.
>
Considering you have to write these *exact* two lines in *every single
place* you want to swap objects it's more than just convenience, it's
*necessary* for correctness and very easy to forget, especially for
people who aren't perfectly familiar with C++'s overly complex lookup
rules. It's a library function everyone is duplicating in code bases all
over the world with everyone agreeing "this is the correct way to swap"
so why not make it behave like that by default.
Having the entire ADL-correct behavior hidden behind a single expression
is also very beneficial for generic code.
--
---
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: Christopher Horvath <blackencino@gmail.com>
Date: Sat, 10 Oct 2015 18:46:08 -0700
Raw View
Teachability and comprehension is much more important than ease of implemen=
tation.
How is a non-language-expert intended to learn these weird idiosyncrasies? =
I constantly feel like I'm behind by a few steps. Until very recently, I ha=
d been taught (incorrectly, I realize) that I was supposed to overload swap=
in the std:: namespace for my library types, and then always call std::swa=
p explicitly.
The thing I like about these small tidbits is that they declare "the right =
way".
> On Oct 10, 2015, at 1:21 PM, Miro Knejp <miro.knejp@gmail.com> wrote:
>=20
>> Am 10.10.2015 um 22:00 schrieb Thiago Macieira:
>>> On Saturday 10 October 2015 21:59:07 Miro Knejp wrote:
>>>> Am 10.10.2015 um 21:48 schrieb Thiago Macieira:
>>>>> On Saturday 10 October 2015 19:05:48 Andrey Semashev wrote:
>>>>> It uses the swap implementation found with ADL or std::swap, if there
>>>>> isn't one. It also contains various compiler bug workarounds. The
>>>>> essential advantage of boost::swap over std::swap is that you can alw=
ays
>>>>> call qualified boost::swap from the generic code and be sure that the
>>>>> most efficient implementation is used.
>>>> Again, I don't understand how it can be more efficient than:
>>>> using namespace std;
>>>> swap(x, y);
>>>>=20
>>>> Please explain.
>>> It's not about efficiency, it's about "boost::swap(x, y)" replacing the
>>> two lines you had to write, thus turning it into a single expression
>>> usable in noexcept(), decltype() etc.
>> So you want a library function that will do the two lines I wrote?
>>=20
>> I think it would be a good idea.
>>=20
>> But I also know the Standard Library is not too keen on convenience func=
tions
>> that can be easily written, so I don't think it's going to happen.
> Considering you have to write these *exact* two lines in *every single pl=
ace* you want to swap objects it's more than just convenience, it's *necess=
ary* for correctness and very easy to forget, especially for people who are=
n't perfectly familiar with C++'s overly complex lookup rules. It's a libra=
ry function everyone is duplicating in code bases all over the world with e=
veryone agreeing "this is the correct way to swap" so why not make it behav=
e like that by default.
>=20
> Having the entire ADL-correct behavior hidden behind a single expression =
is also very beneficial for generic code.
>=20
> --=20
>=20
> --- You received this message because you are subscribed to the Google Gr=
oups "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-propo=
sals/.
--=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/.
.
Author: Lingxi Li <lilingxi.cs@gmail.com>
Date: Sun, 11 Oct 2015 00:32:35 -0700 (PDT)
Raw View
------=_Part_4262_1321041297.1444548755730
Content-Type: multipart/alternative;
boundary="----=_Part_4263_334622239.1444548755730"
------=_Part_4263_334622239.1444548755730
Content-Type: text/plain; charset=UTF-8
On Sunday, October 11, 2015 at 12:29:28 AM UTC+8, Ville Voutilainen wrote:
>
> "I have seen ruminations about a std::adl_swap that pulls in ADL."
>
>
I don't think it is a very good idea to design such a thing like
std::adl_swap. Despite being extremely artificial, it's counter-intuitive
for a qualified function call to perform ADL. Saying so, boost::swap and my
original idea of enabling std::swap to perform ADL have the same problem of
being counter-intuitive.
Maybe, we should concentrate on designing a thing that is to be used
unqualified. Putting std::swap into global namespace is clearly out of
consideration. But, would a __SWAP(x, y) macro be appropriate? It could be
defined as follows:
#define __SWAP(x, y) \
{ \
using std::swap; \
swap(x, y); \
}
I have at least two points to support this idea. First of all, macros are
typically used unqualified. Few people will ever attempt std::__SWAP.
Secondly, its naming convention and macro nature will remind the user that
it may perform something tricky, so do read the documentation carefully
before using it. A similar thing would be std::_Exit. It woke me up the
time I saw its name. Did similar things ever happen to you? :)
--
---
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_4263_334622239.1444548755730
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, October 11, 2015 at 12:29:28 AM UTC+8, Ville Vo=
utilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">"I have s=
een ruminations about a std::adl_swap that pulls in ADL."
<br><br></blockquote><div><br></div><div>I don't think it is a very goo=
d idea to design such a thing like <span style=3D"background-color: rgb(238=
, 238, 238);"><font face=3D"courier new, monospace">std::adl_swap</font></s=
pan>. Despite being extremely artificial, it's counter-intuitive for a =
qualified function call to perform ADL. Saying so, <span style=3D"backgroun=
d-color: rgb(238, 238, 238);"><font face=3D"courier new, monospace">boost::=
swap</font></span> and my original idea of enabling <span style=3D"backgrou=
nd-color: rgb(238, 238, 238);"><font face=3D"courier new, monospace">std::s=
wap</font></span> to perform ADL have the same problem of being counter-int=
uitive.<br><br>Maybe, we should concentrate on designing a thing that is to=
be used unqualified. Putting <span style=3D"background-color: rgb(238, 238=
, 238);"><font face=3D"courier new, monospace">std::swap</font></span> into=
global namespace is clearly out of consideration. But, would a <span style=
=3D"background-color: rgb(238, 238, 238);"><font face=3D"courier new, monos=
pace">__SWAP(x, y)</font></span> macro be appropriate? It could be defined =
as follows:<br><br><div class=3D"prettyprint" style=3D"border: 1px solid rg=
b(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 25=
0);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #800;" class=3D"styled-by-prettify">#define</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> __SWAP</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> y</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">\</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">\</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">using</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">swap</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">\</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 swap</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">\</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">}</span></div></code></div><br></div><div>I have at least t=
wo points to support this idea. First of all, macros are typically used unq=
ualified. Few people will ever attempt <font face=3D"courier new, monospace=
" style=3D"background-color: rgb(238, 238, 238);">std::__SWAP</font>. Secon=
dly, its naming convention and macro nature will remind the user that it ma=
y perform something tricky, so do read the documentation carefully before u=
sing it. A similar thing would be <span style=3D"background-color: rgb(238,=
238, 238);"><font face=3D"courier new, monospace">std::_Exit</font></span>=
.. It woke me up the time I saw its name. Did similar things ever happen to =
you? :)<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_4263_334622239.1444548755730--
------=_Part_4262_1321041297.1444548755730--
.
Author: Lingxi Li <lilingxi.cs@gmail.com>
Date: Sun, 11 Oct 2015 00:46:54 -0700 (PDT)
Raw View
------=_Part_4752_437341828.1444549615101
Content-Type: multipart/alternative;
boundary="----=_Part_4753_1164046050.1444549615101"
------=_Part_4753_1164046050.1444549615101
Content-Type: text/plain; charset=UTF-8
On Sunday, October 11, 2015 at 12:05:54 AM UTC+8, Andrey Semashev wrote:
>
> I would go even further with this proposal and made the new swap() call
> member swap() function on one of the arguments, if there is such member
> function.
>
>
After a second thought, I think such behavior may be way too smart. In
certain cases, it may surprise users and lead to bugs that are difficult to
find.
--
---
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_4753_1164046050.1444549615101
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, October 11, 2015 at 12:05:54 AM UTC+8, =
Andrey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I would =
go even further with this proposal and made the new swap() call=20
<br>member swap() function on one of the arguments, if there is such member=
=20
<br>function.
<br>
<br></blockquote><div><br></div><div>After a second thought, I think such b=
ehavior may be way too smart. In certain cases, it may surprise users and l=
ead to bugs that are difficult to find.</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_4753_1164046050.1444549615101--
------=_Part_4752_437341828.1444549615101--
.
Author: Moritz Klammler <moritz.klammler@gmail.com>
Date: Sun, 11 Oct 2015 10:32:30 +0200
Raw View
Despite the fact that I don't like the idea of introducing a macro for a
task that can easily be done with a function, there is another problem.
Consider how the following program would be ill-formed if the `ADL_SWAP`
macro be used.
#include <utility>
#define ADL_SWAP(LHS, RHS) { using std::swap; swap(LHS, RHS); }
int
main()
{
int a = 1;
int b = 2;
int c = (std::swap(a, b), 0);
//int c = (ADL_SWAP(a, b), 0);
return c;
}
Of course, this can be circumvented by implementing `ADL_SWAP` as
something like
#define ADL_SWAP(LHS, RHS) std::__detail::__adl_swap(LHS, RHS)
where `std::__detail::__adl_swap` is a function template like
`boost::swap`. A macro wrapping a function only to hide the fact that
it is a function? I'd much prefer not using such a macro. I also think
that `__*` names should not be kept out of everyday programming as much
as possible. Especially if the motivation for the new feature is to
avoid typical programming mistakes by beginners. Those should not be
steered towards ugly `__*` stuff.
Retro-fitting `std::swap` to do some internal ADL would be not only
excessively confusing but also -- for no good reason -- a breaking
change. While *most* of the time, using the qualified `std::swap` is
probably a bug, we have no right to assume that *every* such use is.
Introducing an *additional* `std::adl_swap` function template for
convenience I think would be fine but it should do nothing more than
apply `std::swap` unqualified. If there were other fine nuances in the
semantics of `std::swap` and `std::adl_swap`, it would be very
confusing. We already have many "do what I mean" convenience functions
in the standard library -- I'm thinking mostly of the `std::make_*`
family -- that basically free us from having to type what the compiler
could figure out for us. It seems that `std::adl_swap` would fit that
pattern more or less.
Moritz
--
---
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: Lingxi Li <lilingxi.cs@gmail.com>
Date: Sun, 11 Oct 2015 02:23:37 -0700 (PDT)
Raw View
------=_Part_4445_1174095776.1444555417723
Content-Type: multipart/alternative;
boundary="----=_Part_4446_1890170529.1444555417723"
------=_Part_4446_1890170529.1444555417723
Content-Type: text/plain; charset=UTF-8
On Sunday, October 11, 2015 at 4:32:36 PM UTC+8, Moritz Klammler wrote:
>
> Despite the fact that I don't like the idea of introducing a macro for a
> task that can easily be done with a function, there is another problem.
>
> Consider how the following program would be ill-formed if the `ADL_SWAP`
> macro be used.
>
> #include <utility>
>
> #define ADL_SWAP(LHS, RHS) { using std::swap; swap(LHS, RHS); }
>
> int
> main()
> {
> int a = 1;
> int b = 2;
> int c = (std::swap(a, b), 0);
> //int c = (ADL_SWAP(a, b), 0);
> return c;
> }
>
> Of course, this can be circumvented by implementing `ADL_SWAP` as
> something like
>
> #define ADL_SWAP(LHS, RHS) std::__detail::__adl_swap(LHS, RHS)
>
> where `std::__detail::__adl_swap` is a function template like
> `boost::swap`. A macro wrapping a function only to hide the fact that
> it is a function? I'd much prefer not using such a macro. I also think
> that `__*` names should not be kept out of everyday programming as much
> as possible. Especially if the motivation for the new feature is to
> avoid typical programming mistakes by beginners. Those should not be
> steered towards ugly `__*` stuff.
>
> Retro-fitting `std::swap` to do some internal ADL would be not only
> excessively confusing but also -- for no good reason -- a breaking
> change. While *most* of the time, using the qualified `std::swap` is
> probably a bug, we have no right to assume that *every* such use is.
>
> Introducing an *additional* `std::adl_swap` function template for
> convenience I think would be fine but it should do nothing more than
> apply `std::swap` unqualified. If there were other fine nuances in the
> semantics of `std::swap` and `std::adl_swap`, it would be very
> confusing. We already have many "do what I mean" convenience functions
> in the standard library -- I'm thinking mostly of the `std::make_*`
> family -- that basically free us from having to type what the compiler
> could figure out for us. It seems that `std::adl_swap` would fit that
> pattern more or less.
>
>
> Moritz
>
Agreed. The adl_ prefix would make its semantics (effects) explicit, and
programmers who are not familiar with the ADL thing would not misuse the
function and end up with an infinite recursion. Besides, since it is only
an addition and does not modify anything already in the standard, no
existing code will break. I guess we could consider settling on this
solution. Any more comments?
--
---
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_4446_1890170529.1444555417723
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, October 11, 2015 at 4:32:36 PM UTC+8, Moritz Klammler wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">Despite the fact that I don't =
like the idea of introducing a macro for a
<br>task that can easily be done with a function, there is another problem.
<br>
<br>Consider how the following program would be ill-formed if the `ADL_SWAP=
`
<br>macro be used.
<br>
<br>=C2=A0 =C2=A0 #include <utility>
<br>=C2=A0 =C2=A0=20
<br>=C2=A0 =C2=A0 #define ADL_SWAP(LHS, RHS) { using std::swap; swap(LHS, R=
HS); }
<br>=C2=A0 =C2=A0=20
<br>=C2=A0 =C2=A0 int
<br>=C2=A0 =C2=A0 main()
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 int a =3D 1;
<br>=C2=A0 =C2=A0 =C2=A0 int b =3D 2;
<br>=C2=A0 =C2=A0 =C2=A0 int c =3D (std::swap(a, b), 0);
<br>=C2=A0 =C2=A0 =C2=A0 //int c =3D (ADL_SWAP(a, b), 0);
<br>=C2=A0 =C2=A0 =C2=A0 return c;
<br>=C2=A0 =C2=A0 }
<br>
<br>Of course, this can be circumvented by implementing `ADL_SWAP` as
<br>something like
<br>
<br>=C2=A0 =C2=A0 #define ADL_SWAP(LHS, RHS) std::__detail::__adl_swap(LHS,=
RHS)
<br>
<br>where `std::__detail::__adl_swap` is a function template like
<br>`boost::swap`. =C2=A0A macro wrapping a function only to hide the fact =
that
<br>it is a function? =C2=A0I'd much prefer not using such a macro. =C2=
=A0I also think
<br>that `__*` names should not be kept out of everyday programming as much
<br>as possible. =C2=A0Especially if the motivation for the new feature is =
to
<br>avoid typical programming mistakes by beginners. =C2=A0Those should not=
be
<br>steered towards ugly `__*` stuff.
<br>
<br>Retro-fitting `std::swap` to do some internal ADL would be not only
<br>excessively confusing but also -- for no good reason -- a breaking
<br>change. =C2=A0While *most* of the time, using the qualified `std::swap`=
is
<br>probably a bug, we have no right to assume that *every* such use is.
<br>
<br>Introducing an *additional* `std::adl_swap` function template for
<br>convenience I think would be fine but it should do nothing more than
<br>apply `std::swap` unqualified. =C2=A0If there were other fine nuances i=
n the
<br>semantics of `std::swap` and `std::adl_swap`, it would be very
<br>confusing. =C2=A0We already have many "do what I mean" conven=
ience functions
<br>in the standard library -- I'm thinking mostly of the `std::make_*`
<br>family -- that basically free us from having to type what the compiler
<br>could figure out for us. =C2=A0It seems that `std::adl_swap` would fit =
that
<br>pattern more or less.
<br>
<br>
<br>Moritz
<br></blockquote><div><br></div><div>Agreed. The <span style=3D"background-=
color: rgb(238, 238, 238);"><font face=3D"courier new, monospace">adl_</fon=
t></span> prefix would make its semantics (effects) explicit, and programme=
rs who are not familiar with the ADL thing would not misuse the function an=
d end up with an infinite recursion. Besides, since it is only an addition =
and does not modify anything already in the standard, no existing code will=
break. I guess we could consider settling on this solution. Any more comme=
nts?</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_4446_1890170529.1444555417723--
------=_Part_4445_1174095776.1444555417723--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Sun, 11 Oct 2015 14:50:24 +0300
Raw View
On 11.10.2015 10:46, Lingxi Li wrote:
>
>
> On Sunday, October 11, 2015 at 12:05:54 AM UTC+8, Andrey Semashev wrote:
>
> I would go even further with this proposal and made the new swap() call
> member swap() function on one of the arguments, if there is such member
> function.
>
>
> After a second thought, I think such behavior may be way too smart. In
> certain cases, it may surprise users and lead to bugs that are difficult
> to find.
I don't think so. We already have precedents of std::begin calling
c.begin() on containers (as well as othe iterator accessors).
The motivation for this behavior is that 100% of free swap() overloads I
write are just forwarding to the member swap. I suppose, most, if not
all overloads in the standard library are the same. This is just a
needless code duplication.
--
---
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: Andrey Semashev <andrey.semashev@gmail.com>
Date: Sun, 11 Oct 2015 14:52:41 +0300
Raw View
On 11.10.2015 10:32, Lingxi Li wrote:
> On Sunday, October 11, 2015 at 12:29:28 AM UTC+8, Ville Voutilainen wrote:
>
> "I have seen ruminations about a std::adl_swap that pulls in ADL."
>
>
> I don't think it is a very good idea to design such a thing like
> std::adl_swap. Despite being extremely artificial, it's
> counter-intuitive for a qualified function call to perform ADL. Saying
> so, boost::swap and my original idea of enabling std::swap to perform
> ADL have the same problem of being counter-intuitive.
>
> Maybe, we should concentrate on designing a thing that is to be used
> unqualified. Putting std::swap into global namespace is clearly out of
> consideration. But, would a __SWAP(x, y) macro be appropriate? It could
> be defined as follows:
>
> |
> #define__SWAP(x,y)\
> {\
> usingstd::swap;\
> swap(x,y);\
> }
> |
>
> I have at least two points to support this idea. First of all, macros
> are typically used unqualified. Few people will ever attempt
> std::__SWAP. Secondly, its naming convention and macro nature will
> remind the user that it may perform something tricky, so do read the
> documentation carefully before using it. A similar thing would be
> std::_Exit. It woke me up the time I saw its name. Did similar things
> ever happen to you? :)
No way, no macros, please. The language already has everything needed to
implement boost::swap, so why should the standard library do anything worse.
--
---
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: Lingxi Li <lilingxi.cs@gmail.com>
Date: Sun, 11 Oct 2015 05:55:08 -0700 (PDT)
Raw View
------=_Part_4620_1215154908.1444568108960
Content-Type: multipart/alternative;
boundary="----=_Part_4621_1566683326.1444568108960"
------=_Part_4621_1566683326.1444568108960
Content-Type: text/plain; charset=UTF-8
On Sunday, October 11, 2015 at 7:50:30 PM UTC+8, Andrey Semashev wrote:
>
> On 11.10.2015 10:46, Lingxi Li wrote:
> >
> >
> > On Sunday, October 11, 2015 at 12:05:54 AM UTC+8, Andrey Semashev wrote:
> >
> > I would go even further with this proposal and made the new swap()
> call
> > member swap() function on one of the arguments, if there is such
> member
> > function.
> >
> >
> > After a second thought, I think such behavior may be way too smart. In
> > certain cases, it may surprise users and lead to bugs that are difficult
> > to find.
>
> I don't think so. We already have precedents of std::begin calling
> c.begin() on containers (as well as othe iterator accessors).
>
> The motivation for this behavior is that 100% of free swap() overloads I
> write are just forwarding to the member swap. I suppose, most, if not
> all overloads in the standard library are the same. This is just a
> needless code duplication.
>
>
Be it the iterator accessors or swap, the ultimate goal is to form a common
generic interface to facilitate writing generic algorithms. There are
different choices for the design of such an interface. For example, we may
design the interface as a class method or we may design it as a free
function. In terms of generality, the latter design is more promising, for
non-class types like arrays cannot have methods. I guess this is the
primary motivation driving the free-function design of iterator accessors.
Now that we have iterator accessors as free functions, do we still need the
corresponding methods, if not considering backward compatibility? I guess
so mainly because such operations are unary and closely related to the
target object. As such, they naturally suit being implemented as methods
rather than free functions. The artificial free function forms are solely
designed to serve the goal of forming a common interface. If not for
writing generic algorithms, I would prefer using the method forms. So,
there are reasons to have both the method form and the free function form,
and have the latter simply forward to the former for class types, despite
some code duplication.
Things are different for the swap algorithm which is a binary operation and
demonstrates a sense of symmetry. As such, it naturally suits being
implemented as a free function rather than a method. I have always felt
weird when using the method form. In this case, there is no reason to have
both forms available at the price of code duplication, if not considering
backward compatibility. But the solution should be not to write the method
form rather than not to write the free function form, for the latter is
both more natural and generic.
--
---
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_4621_1566683326.1444568108960
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, October 11, 2015 at 7:50:30 PM UTC+8, Andrey Semashev wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">On 11.10.2015 10:46, Lingxi Li wro=
te:
<br>>
<br>>
<br>> On Sunday, October 11, 2015 at 12:05:54 AM UTC+8, Andrey Semashev =
wrote:
<br>>
<br>> =C2=A0 =C2=A0 I would go even further with this proposal and made =
the new swap() call
<br>> =C2=A0 =C2=A0 member swap() function on one of the arguments, if t=
here is such member
<br>> =C2=A0 =C2=A0 function.
<br>>
<br>>
<br>> After a second thought, I think such behavior may be way too smart=
.. In
<br>> certain cases, it may surprise users and lead to bugs that are dif=
ficult
<br>> to find.
<br>
<br>I don't think so. We already have precedents of std::begin calling=
=20
<br>c.begin() on containers (as well as othe iterator accessors).
<br>
<br>The motivation for this behavior is that 100% of free swap() overloads =
I=20
<br>write are just forwarding to the member swap. I suppose, most, if not=
=20
<br>all overloads in the standard library are the same. This is just a=20
<br>needless code duplication.
<br>
<br></blockquote><div><br></div><div>Be it the iterator accessors or swap, =
the ultimate goal is to form a common generic interface to facilitate writi=
ng generic algorithms. There are different choices for the design of such a=
n interface. For example, we may design the interface as a class method or =
we may design it as a free function. In terms of generality, the latter des=
ign is more promising, for non-class types like arrays cannot have methods.=
I guess this is the primary motivation driving the free-function design of=
iterator accessors. Now that we have iterator accessors as free functions,=
do we still need the corresponding methods, if not considering backward co=
mpatibility? I guess so mainly because such operations are unary and closel=
y related to the target object. As such, they naturally suit being implemen=
ted as methods rather than free functions. The artificial free function for=
ms are solely designed to serve the goal of forming a common interface. If =
not for writing generic algorithms, I would prefer using the method forms. =
So, there are reasons to have both the method form and the free function fo=
rm, and have the latter simply forward to the former for class types, despi=
te some code duplication.<br><br>Things are different for the swap algorith=
m which is a binary operation and demonstrates a sense of symmetry. As such=
, it naturally suits being implemented as a free function rather than a met=
hod. I have always felt weird when using the method form. In this case, the=
re is no reason to have both forms available at the price of code duplicati=
on, if not considering backward compatibility. But the solution should=C2=
=A0be not to write the method form rather than not to write the free functi=
on form, for the latter is both more natural and generic.</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_4621_1566683326.1444568108960--
------=_Part_4620_1215154908.1444568108960--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Sun, 11 Oct 2015 17:35:25 -0700 (PDT)
Raw View
------=_Part_4090_812076518.1444610125965
Content-Type: multipart/alternative;
boundary="----=_Part_4091_1619225340.1444610125975"
------=_Part_4091_1619225340.1444610125975
Content-Type: text/plain; charset=UTF-8
On Saturday, October 10, 2015 at 4:01:03 PM UTC-4, Thiago Macieira wrote:
>
> On Saturday 10 October 2015 21:59:07 Miro Knejp wrote:
> > Am 10.10.2015 um 21:48 schrieb Thiago Macieira:
> > > On Saturday 10 October 2015 19:05:48 Andrey Semashev wrote:
> > >> It uses the swap implementation found with ADL or std::swap, if there
> > >> isn't one. It also contains various compiler bug workarounds. The
> > >> essential advantage of boost::swap over std::swap is that you can
> always
> > >> call qualified boost::swap from the generic code and be sure that the
> > >> most efficient implementation is used.
> > >
> > > Again, I don't understand how it can be more efficient than:
> > > using namespace std;
> > > swap(x, y);
> > >
> > > Please explain.
> >
> > It's not about efficiency, it's about "boost::swap(x, y)" replacing the
> > two lines you had to write, thus turning it into a single expression
> > usable in noexcept(), decltype() etc.
>
> So you want a library function that will do the two lines I wrote?
>
> I think it would be a good idea.
>
> But I also know the Standard Library is not too keen on convenience
> functions
> that can be easily written, so I don't think it's going to happen.
>
>
This is not just a convenience thing. How do you use begin(), size(), or
swap() inside of a decltype expression for defining type traits when things
like decltype only allow for a single expression? How do you use it to
define concepts?
Why is something so fundamental and simple as swapping 2 objects so
needlessly complicated and easy to do incorrectly? Why is it necessary to
have this ridiculous using namespace boilerplate polluting the code every
time a swap happens?
And yes, please make it also call member swap if it didn't find anything
via ADL lookup before falling back to the move construction default. This
will happen anyway if we get uniform call syntax.
The design of the swap operation in C++ is fundamentally broken.
--
---
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_4091_1619225340.1444610125975
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Saturday, October 10, 2015 at 4:01:03 PM UTC-4, Thiago Macieira =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Saturday 10 October 2=
015 21:59:07 Miro Knejp wrote:
<br>> Am 10.10.2015 um 21:48 schrieb Thiago Macieira:
<br>> > On Saturday 10 October 2015 19:05:48 Andrey Semashev wrote:
<br>> >> It uses the swap implementation found with ADL or std::sw=
ap, if there
<br>> >> isn't one. It also contains various compiler bug work=
arounds. The
<br>> >> essential advantage of boost::swap over std::swap is that=
you can always
<br>> >> call qualified boost::swap from the generic code and be s=
ure that the
<br>> >> most efficient implementation is used.
<br>> >=20
<br>> > Again, I don't understand how it can be more efficient th=
an:
<br>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0using namespa=
ce std;
<br>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0swap(x, y);
<br>> >=20
<br>> > Please explain.
<br>>=20
<br>> It's not about efficiency, it's about "boost::swap(x,=
y)" replacing the
<br>> two lines you had to write, thus turning it into a single expressi=
on
<br>> usable in noexcept(), decltype() etc.
<br>
<br>So you want a library function that will do the two lines I wrote?
<br>
<br>I think it would be a good idea.
<br>
<br>But I also know the Standard Library is not too keen on convenience fun=
ctions=20
<br>that can be easily written, so I don't think it's going to happ=
en.
<br><br></blockquote><div><br></div><div>This is not just a convenience thi=
ng. How do you use begin(), size(), or swap() inside of a decltype expressi=
on for defining type traits when things like decltype only allow for a sing=
le expression? How do you use it to define concepts?</div><div><br></div><d=
iv>Why is something so fundamental and simple as swapping 2 objects so need=
lessly complicated and easy to do incorrectly? Why is it necessary to have =
this ridiculous using namespace boilerplate polluting the code every time a=
swap happens?</div><div><br></div><div>And yes, please make it also call m=
ember swap if it didn't find anything via ADL lookup before falling bac=
k to the move construction default. This will happen anyway if we get unifo=
rm call syntax.</div><div><br></div><div>The design of the swap operation i=
n C++ is fundamentally broken.</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_4091_1619225340.1444610125975--
------=_Part_4090_812076518.1444610125965--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Sun, 11 Oct 2015 17:47:51 -0700 (PDT)
Raw View
------=_Part_3931_2058667917.1444610871115
Content-Type: multipart/alternative;
boundary="----=_Part_3932_156597972.1444610871115"
------=_Part_3932_156597972.1444610871115
Content-Type: text/plain; charset=UTF-8
On Sunday, October 11, 2015 at 8:55:09 AM UTC-4, Lingxi Li wrote:
>
> On Sunday, October 11, 2015 at 7:50:30 PM UTC+8, Andrey Semashev wrote:
>>
>> On 11.10.2015 10:46, Lingxi Li wrote:
>> >
>> >
>> > On Sunday, October 11, 2015 at 12:05:54 AM UTC+8, Andrey Semashev
>> wrote:
>> >
>> > I would go even further with this proposal and made the new swap()
>> call
>> > member swap() function on one of the arguments, if there is such
>> member
>> > function.
>> >
>> >
>> > After a second thought, I think such behavior may be way too smart. In
>> > certain cases, it may surprise users and lead to bugs that are
>> difficult
>> > to find.
>>
>> I don't think so. We already have precedents of std::begin calling
>> c.begin() on containers (as well as othe iterator accessors).
>>
>> The motivation for this behavior is that 100% of free swap() overloads I
>> write are just forwarding to the member swap. I suppose, most, if not
>> all overloads in the standard library are the same. This is just a
>> needless code duplication.
>>
>>
> Be it the iterator accessors or swap, the ultimate goal is to form a
> common generic interface to facilitate writing generic algorithms. There
> are different choices for the design of such an interface. For example, we
> may design the interface as a class method or we may design it as a free
> function. In terms of generality, the latter design is more promising, for
> non-class types like arrays cannot have methods. I guess this is the
> primary motivation driving the free-function design of iterator accessors.
> Now that we have iterator accessors as free functions, do we still need the
> corresponding methods, if not considering backward compatibility? I guess
> so mainly because such operations are unary and closely related to the
> target object. As such, they naturally suit being implemented as methods
> rather than free functions. The artificial free function forms are solely
> designed to serve the goal of forming a common interface. If not for
> writing generic algorithms, I would prefer using the method forms. So,
> there are reasons to have both the method form and the free function form,
> and have the latter simply forward to the former for class types, despite
> some code duplication.
>
> Things are different for the swap algorithm which is a binary operation
> and demonstrates a sense of symmetry. As such, it naturally suits being
> implemented as a free function rather than a method. I have always felt
> weird when using the method form. In this case, there is no reason to have
> both forms available at the price of code duplication, if not considering
> backward compatibility. But the solution should be not to write the method
> form rather than not to write the free function form, for the latter is
> both more natural and generic.
>
operator= is also a binary operator and using the same logic one could
argue it should be a free function and not a member as we define it now. On
the other hand, if you need to write a swap yourself, it probably means you
need access to all of the private data members directly and therefore may
make more sense as a method instead of a friend free function.
The point is it actually doesn't matter. Make the extension points support
both ADL non-members and members. Now users can decide whats best for them
and most importantly they don't have to write boilerplater wrappers to
serve whatever convention the standard chose.
Its even more confusing that the STL containers have swap() member
functions which can lead novices to think they can just define member
swap() on their types and it will work. Hey if it works for begin(), why
not for swap()? The best part is that "correct" calls to using std::swap;
swap() will silently ignore their optimized member swap() and fall back to
the unoptimized default.
--
---
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_3932_156597972.1444610871115
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Sunday, October 11, 2015 at 8:55:09 AM UTC-4, Lingxi Li wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On Sunday, October 11, 2015 at 7=
:50:30 PM UTC+8, Andrey Semashev wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex">On 11.10.2015 10:46, Lingxi Li wrote:
<br>>
<br>>
<br>> On Sunday, October 11, 2015 at 12:05:54 AM UTC+8, Andrey Semashev =
wrote:
<br>>
<br>> =C2=A0 =C2=A0 I would go even further with this proposal and made =
the new swap() call
<br>> =C2=A0 =C2=A0 member swap() function on one of the arguments, if t=
here is such member
<br>> =C2=A0 =C2=A0 function.
<br>>
<br>>
<br>> After a second thought, I think such behavior may be way too smart=
.. In
<br>> certain cases, it may surprise users and lead to bugs that are dif=
ficult
<br>> to find.
<br>
<br>I don't think so. We already have precedents of std::begin calling=
=20
<br>c.begin() on containers (as well as othe iterator accessors).
<br>
<br>The motivation for this behavior is that 100% of free swap() overloads =
I=20
<br>write are just forwarding to the member swap. I suppose, most, if not=
=20
<br>all overloads in the standard library are the same. This is just a=20
<br>needless code duplication.
<br>
<br></blockquote><div><br></div><div>Be it the iterator accessors or swap, =
the ultimate goal is to form a common generic interface to facilitate writi=
ng generic algorithms. There are different choices for the design of such a=
n interface. For example, we may design the interface as a class method or =
we may design it as a free function. In terms of generality, the latter des=
ign is more promising, for non-class types like arrays cannot have methods.=
I guess this is the primary motivation driving the free-function design of=
iterator accessors. Now that we have iterator accessors as free functions,=
do we still need the corresponding methods, if not considering backward co=
mpatibility? I guess so mainly because such operations are unary and closel=
y related to the target object. As such, they naturally suit being implemen=
ted as methods rather than free functions. The artificial free function for=
ms are solely designed to serve the goal of forming a common interface. If =
not for writing generic algorithms, I would prefer using the method forms. =
So, there are reasons to have both the method form and the free function fo=
rm, and have the latter simply forward to the former for class types, despi=
te some code duplication.<br><br>Things are different for the swap algorith=
m which is a binary operation and demonstrates a sense of symmetry. As such=
, it naturally suits being implemented as a free function rather than a met=
hod. I have always felt weird when using the method form. In this case, the=
re is no reason to have both forms available at the price of code duplicati=
on, if not considering backward compatibility. But the solution should=C2=
=A0be not to write the method form rather than not to write the free functi=
on form, for the latter is both more natural and generic.</div></blockquote=
><div><br></div><div>operator=3D is also a binary operator and using the sa=
me logic one could argue it should be a free function and not a member as w=
e define it now. On the other hand, if you need to write a swap yourself, i=
t probably means you need access to all of the private data members directl=
y and therefore may make more sense as a method instead of a friend free fu=
nction.</div><div><br></div><div>The point is it actually doesn't matte=
r. Make the extension points support both ADL non-members and members. Now =
users can decide whats best for them and most importantly they don't ha=
ve to write boilerplater wrappers to serve whatever convention the standard=
chose.=C2=A0</div><div><br></div><div>Its even more confusing that the STL=
containers have swap() member functions which can lead novices to think th=
ey can just define member swap() on their types and it will work. Hey if it=
works for begin(), why not for swap()? The best part is that "correct=
" calls to =C2=A0using std::swap; swap() will silently ignore their op=
timized member swap() and fall back to the unoptimized default.</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_3932_156597972.1444610871115--
------=_Part_3931_2058667917.1444610871115--
.
Author: Lingxi Li <lilingxi.cs@gmail.com>
Date: Sun, 11 Oct 2015 18:33:49 -0700 (PDT)
Raw View
------=_Part_161_1327217976.1444613629471
Content-Type: multipart/alternative;
boundary="----=_Part_162_565172749.1444613629471"
------=_Part_162_565172749.1444613629471
Content-Type: text/plain; charset=UTF-8
On Monday, October 12, 2015 at 8:47:51 AM UTC+8, Matthew Fioravante wrote:
>
>
>
> On Sunday, October 11, 2015 at 8:55:09 AM UTC-4, Lingxi Li wrote:
>>
>> On Sunday, October 11, 2015 at 7:50:30 PM UTC+8, Andrey Semashev wrote:
>>>
>>> On 11.10.2015 10:46, Lingxi Li wrote:
>>> >
>>> >
>>> > On Sunday, October 11, 2015 at 12:05:54 AM UTC+8, Andrey Semashev
>>> wrote:
>>> >
>>> > I would go even further with this proposal and made the new swap()
>>> call
>>> > member swap() function on one of the arguments, if there is such
>>> member
>>> > function.
>>> >
>>> >
>>> > After a second thought, I think such behavior may be way too smart. In
>>> > certain cases, it may surprise users and lead to bugs that are
>>> difficult
>>> > to find.
>>>
>>> I don't think so. We already have precedents of std::begin calling
>>> c.begin() on containers (as well as othe iterator accessors).
>>>
>>> The motivation for this behavior is that 100% of free swap() overloads I
>>> write are just forwarding to the member swap. I suppose, most, if not
>>> all overloads in the standard library are the same. This is just a
>>> needless code duplication.
>>>
>>>
>> Be it the iterator accessors or swap, the ultimate goal is to form a
>> common generic interface to facilitate writing generic algorithms. There
>> are different choices for the design of such an interface. For example, we
>> may design the interface as a class method or we may design it as a free
>> function. In terms of generality, the latter design is more promising, for
>> non-class types like arrays cannot have methods. I guess this is the
>> primary motivation driving the free-function design of iterator accessors.
>> Now that we have iterator accessors as free functions, do we still need the
>> corresponding methods, if not considering backward compatibility? I guess
>> so mainly because such operations are unary and closely related to the
>> target object. As such, they naturally suit being implemented as methods
>> rather than free functions. The artificial free function forms are solely
>> designed to serve the goal of forming a common interface. If not for
>> writing generic algorithms, I would prefer using the method forms. So,
>> there are reasons to have both the method form and the free function form,
>> and have the latter simply forward to the former for class types, despite
>> some code duplication.
>>
>> Things are different for the swap algorithm which is a binary operation
>> and demonstrates a sense of symmetry. As such, it naturally suits being
>> implemented as a free function rather than a method. I have always felt
>> weird when using the method form. In this case, there is no reason to have
>> both forms available at the price of code duplication, if not considering
>> backward compatibility. But the solution should be not to write the method
>> form rather than not to write the free function form, for the latter is
>> both more natural and generic.
>>
>
> operator= is also a binary operator and using the same logic one could
> argue it should be a free function and not a member as we define it now. On
> the other hand, if you need to write a swap yourself, it probably means you
> need access to all of the private data members directly and therefore may
> make more sense as a method instead of a friend free function.
>
> The point is it actually doesn't matter. Make the extension points support
> both ADL non-members and members. Now users can decide whats best for them
> and most importantly they don't have to write boilerplater wrappers to
> serve whatever convention the standard chose.
>
> Its even more confusing that the STL containers have swap() member
> functions which can lead novices to think they can just define member
> swap() on their types and it will work. Hey if it works for begin(), why
> not for swap()? The best part is that "correct" calls to using std::swap;
> swap() will silently ignore their optimized member swap() and fall back to
> the unoptimized default.
>
You get a point. Perhaps, the name `adl_swap` should be changed then, for
it does not reflect the forwarding to member part. How
about intro_swap like introsort <https://en.wikipedia.org/wiki/Introsort>?
The intro prefix is short for introspective which has the meaning of being
self-adaptive and hybrid.
--
---
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_162_565172749.1444613629471
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, October 12, 2015 at 8:47:51 AM UTC+8, Matthew Fioravante wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Sunday, October 11, =
2015 at 8:55:09 AM UTC-4, Lingxi Li wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">On Sunday, October 11, 2015 at 7:50:30 PM UTC+8, Andrey Semashev wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">On 11.10.2015 10:46, Lingxi Li w=
rote:
<br>>
<br>>
<br>> On Sunday, October 11, 2015 at 12:05:54 AM UTC+8, Andrey Semashev =
wrote:
<br>>
<br>> =C2=A0 =C2=A0 I would go even further with this proposal and made =
the new swap() call
<br>> =C2=A0 =C2=A0 member swap() function on one of the arguments, if t=
here is such member
<br>> =C2=A0 =C2=A0 function.
<br>>
<br>>
<br>> After a second thought, I think such behavior may be way too smart=
.. In
<br>> certain cases, it may surprise users and lead to bugs that are dif=
ficult
<br>> to find.
<br>
<br>I don't think so. We already have precedents of std::begin calling=
=20
<br>c.begin() on containers (as well as othe iterator accessors).
<br>
<br>The motivation for this behavior is that 100% of free swap() overloads =
I=20
<br>write are just forwarding to the member swap. I suppose, most, if not=
=20
<br>all overloads in the standard library are the same. This is just a=20
<br>needless code duplication.
<br>
<br></blockquote><div><br></div><div>Be it the iterator accessors or swap, =
the ultimate goal is to form a common generic interface to facilitate writi=
ng generic algorithms. There are different choices for the design of such a=
n interface. For example, we may design the interface as a class method or =
we may design it as a free function. In terms of generality, the latter des=
ign is more promising, for non-class types like arrays cannot have methods.=
I guess this is the primary motivation driving the free-function design of=
iterator accessors. Now that we have iterator accessors as free functions,=
do we still need the corresponding methods, if not considering backward co=
mpatibility? I guess so mainly because such operations are unary and closel=
y related to the target object. As such, they naturally suit being implemen=
ted as methods rather than free functions. The artificial free function for=
ms are solely designed to serve the goal of forming a common interface. If =
not for writing generic algorithms, I would prefer using the method forms. =
So, there are reasons to have both the method form and the free function fo=
rm, and have the latter simply forward to the former for class types, despi=
te some code duplication.<br><br>Things are different for the swap algorith=
m which is a binary operation and demonstrates a sense of symmetry. As such=
, it naturally suits being implemented as a free function rather than a met=
hod. I have always felt weird when using the method form. In this case, the=
re is no reason to have both forms available at the price of code duplicati=
on, if not considering backward compatibility. But the solution should=C2=
=A0be not to write the method form rather than not to write the free functi=
on form, for the latter is both more natural and generic.</div></blockquote=
><div><br></div><div>operator=3D is also a binary operator and using the sa=
me logic one could argue it should be a free function and not a member as w=
e define it now. On the other hand, if you need to write a swap yourself, i=
t probably means you need access to all of the private data members directl=
y and therefore may make more sense as a method instead of a friend free fu=
nction.</div><div><br></div><div>The point is it actually doesn't matte=
r. Make the extension points support both ADL non-members and members. Now =
users can decide whats best for them and most importantly they don't ha=
ve to write boilerplater wrappers to serve whatever convention the standard=
chose.=C2=A0</div><div><br></div><div>Its even more confusing that the STL=
containers have swap() member functions which can lead novices to think th=
ey can just define member swap() on their types and it will work. Hey if it=
works for begin(), why not for swap()? The best part is that "correct=
" calls to =C2=A0using std::swap; swap() will silently ignore their op=
timized member swap() and fall back to the unoptimized default.</div></bloc=
kquote><div><br></div><div>You get a point. Perhaps, the name `adl_swap`=C2=
=A0should be changed then, for it does not reflect the forwarding to member=
part. How about=C2=A0intro_swap=C2=A0like=C2=A0<a href=3D"https://en.wikip=
edia.org/wiki/Introsort">introsort</a>? The intro prefix is short for intro=
spective which has the meaning of being self-adaptive and hybrid.</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_162_565172749.1444613629471--
------=_Part_161_1327217976.1444613629471--
.