220 26365 <9608d5c4-e60f-449e-9078-f27fed1f79fd@isocpp.org> article Path: news.gmane.org!not-for-mail From: FrankHB1989 Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Swapping with volatile lvalues Date: Tue, 21 Jun 2016 03:12:47 -0700 (PDT) Lines: 130 Approved: news@gmane.org Message-ID: <9608d5c4-e60f-449e-9078-f27fed1f79fd@isocpp.org> References: <81998cb5-722e-49a1-be98-7ca1e219b72a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1184_1009700418.1466503967335" X-Trace: ger.gmane.org 1466503972 982 80.91.229.3 (21 Jun 2016 10:12:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jun 2016 10:12:52 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCTJVBPG3QIBBIFGUS5QKGQEMKSFZKA@isocpp.org Tue Jun 21 12:12:52 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f69.google.com ([209.85.214.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bFIfq-0007Za-P2 for gclcip-std-proposals@m.gmane.org; Tue, 21 Jun 2016 12:12:50 +0200 Original-Received: by mail-it0-f69.google.com with SMTP id f6sf35762669ith.1 for ; Tue, 21 Jun 2016 03:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=WbLBKoCeucDbLSCJfshWnJmnzNnps9XAqhXYuDShl2Q=; b=EhF5QEGhtDg6eI9SGXNePiFHzONpzNX8Mv2fi3OSZ6QH35E77QgLlNcIHQZfv+xenj gbzvNu6ndHMBYkdvb3FgT+0qEkf37oL6JpTgLqv5HeTHmxDfg74F3mXIid0TmdKJgWLX jhsOd7UO11V8jptmAzSN6EjVXF/9d7bLEHkS2ZQGR4cp6LVq3YiJjTxJro4pSVb8MQC+ b/rUxpIbV2sh6+4xDosHbSTun7q+C9to3UaIlehf+yEkcacu/EigrJOIAMiqhW/8Lxus wXH74wHVYg5utly2dyD1h30tZwKoVmhbpH+MPweqiy08Kw/aNynyqyFi5WxmSlnrMOl3 YnGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=WbLBKoCeucDbLSCJfshWnJmnzNnps9XAqhXYuDShl2Q=; b=ILwHSo8YIK6NmyEDpI/DgpVioLvoQJj/LECjXq8WEaFBHOhZjDALLtrPQCAUyuFY5Y eeDZTRh9Enqn5GYrsRA0W5GytkbN23hWQVXt5/xbqULOn4ztYqx97uSKHa20KxbO36C8 jVxs3mj2Rq6626UKVSsUUfc6ighIl+9eEaYinDM/aHPZz9i6ZxPzDEuRTCWpprFoe/YR vUq0+Sc3x1uFlE8Z8HF+JP/mlvf+E8GUYr5fvi3suStG6d/UZBgIpWDhvnuyLhg2v3VI ld1VrWGxsnnZpjXB9os1+g3jp5FUlH1T0HYnUGOimSV+4ONFM9GSf90lUlxPEVhOWhlJ aMCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=WbLBKoCeucDbLSCJfshWnJmnzNnps9XAqhXYuDShl2Q=; b=X56jaslSrINS/k270K5HRn3FrXAlbzeop/HfhG2a6phY3DewN0qFViceT0JEhTuz98 XImOEiDJDpQzGPi66+F+bxxQY+P3wK6FdmbYLWID3YBjJsegdLtd5vpHnLNxv0nKHlFq DfLdr4o8XA5P+OfdLZg7ugm0hEJAF8MBIIivH5WirX8LXxhk0Tx12CtvttOB7ih1jP11 dWP1z28yMlIj/SLLXlw31knDJhNMZ9Gc7XTUYabTCm1iGG0my6sH8ZoVUtnn+zxRt+vJ zda1vKCzsMOWPU4Gmmjs8kwDQv8jf2QI7SmzRL+DbbLEEYW75sjoWVlghQ9AWCpvj4mp gcoA== X-Gm-Message-State: ALyK8tLIJBTIRbeO0NLms7EZhK6Q3B9g/BigJwhGRcClLgy8KuGVKZgdcAe+f1p6IrcKUw== X-Received: by 10.157.9.195 with SMTP id 3mr21917756otz.19.1466503969715; Tue, 21 Jun 2016 03:12:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.133.86 with SMTP id r83ls175945itd.19.gmail; Tue, 21 Jun 2016 03:12:48 -0700 (PDT) X-Received: by 10.36.64.133 with SMTP id n127mr44949ita.4.1466503968528; Tue, 21 Jun 2016 03:12:48 -0700 (PDT) In-Reply-To: X-Original-Sender: frankhb1989@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:26365 Archived-At: ------=_Part_1184_1009700418.1466503967335 Content-Type: multipart/alternative; boundary="----=_Part_1185_1053112479.1466503967336" ------=_Part_1185_1053112479.1466503967336 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Call of std::exchange can work, but it seems not so ideal. The return type= =20 of std::exchange is template parameter type T, so when T is a volatile=20 type, lvalue-to-rvalue conversion would be performed, and there are likely= =20 more side effects than needed. I also don't think using the volatile lvalue return value (which is not the= =20 case for std::exchange) a good idea. Discarded-value expressions can work= =20 in such cases, but is seems to be strange and too error-prone. So perhaps= =20 the return type of the call should be void. Regarding with Swappable requriements and symmetry... how about providing 2= =20 overloading? =E5=9C=A8 2016=E5=B9=B46=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC= +8=E4=B8=8B=E5=8D=883:49:58=EF=BC=8CDaniel Kr=C3=BCgler=E5=86=99=E9=81=93= =EF=BC=9A > > 2016-06-21 9:29 GMT+02:00 FrankHB1989 >:= =20 > > I find swapping between the non-volatile and volatile lvalues may be=20 > useful,=20 > > e.g. to save/restore errno where it has volatile type. Though it is eas= y=20 > to=20 > > roll my own wheels, is it being considered in the standard, e.g.=20 > > `templatevoid swap(T, volatile&) noexcept`?=20 > > The way you suggest to provide this (asymmetric) signature, to me that=20 > doesn't seem to be a function that should be named swap and should be=20 > considered during overload resolution of swap functions in the library=20 > as described in [swappable.requirements]. For example, note that=20 > according to the Swappable requirements, there exist a bunch of=20 > requirements regarding symmetry of call expressions and=20 > post-conditions, that don't seem to apply here.=20 > > I have not looked deeper into this, but isn't your suggestion more=20 > indicated to be a variant of std::exchange? But even here I'm not 100%=20 > sure that this picture fits.=20 > > - Daniel=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/9608d5c4-e60f-449e-9078-f27fed1f79fd%40isocpp.or= g. ------=_Part_1185_1053112479.1466503967336 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Call of std::exchange can work, but it seems not so ideal.= The return type of std::exchange is template parameter type T, so when T i= s a volatile type, lvalue-to-rvalue conversion would be performed, and ther= e are likely more side effects than needed.
I also don't think using= the volatile lvalue return value (which is not=20 the case for std::exchange) a good idea. Discarded-value expressions can work in such cases, but is seems to be strange and too error-prone. So per= haps the return type of the call should be void.
Regarding with Swappabl= e requriements and sym= metry... how about providing 2 overloading?

=E5=9C=A8 2016=E5= =B9=B46=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D= =883:49:58=EF=BC=8CDaniel Kr=C3=BCgler=E5=86=99=E9=81=93=EF=BC=9A2016-06-21 9:29 GMT+02:00 FrankHB1989 &l= t;fra= nk...@gmail.com>:
> I find swapping between the non-volatile and volatile lvalues may = be useful,
> e.g. to save/restore errno where it has volatile type. Though it i= s easy to
> roll my own wheels, is it being considered in the standard, e.g.
> `template<typename T>void swap(T, volatile&) noexcept`?

The way you suggest to provide this (asymmetric) signature, to me that
doesn't seem to be a function that should be named swap and should = be
considered during overload resolution of swap functions in the library
as described in [swappable.requirements]. For example, note that
according to the Swappable requirements, there exist a bunch of
requirements regarding symmetry of call expressions and
post-conditions, that don't seem to apply here.

I have not looked deeper into this, but isn't your suggestion more
indicated to be a variant of std::exchange? But even here I'm not 1= 00%
sure that this picture fits.

- Daniel

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/9608d5c4-e60f-449e-9078-f27fed1f79fd= %40isocpp.org.
------=_Part_1185_1053112479.1466503967336-- ------=_Part_1184_1009700418.1466503967335-- .