220 37287 <1fea07df-46a6-4df2-865a-849be8f8d129@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: jeffersoncarpenter2@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Pointer overload for || Date: Sun, 11 Mar 2018 00:38:17 -0800 (PST) Lines: 100 Approved: news@gmane.org Message-ID: <1fea07df-46a6-4df2-865a-849be8f8d129@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4686_264317583.1520757497056" X-Trace: blaine.gmane.org 1520757377 4961 195.159.176.226 (11 Mar 2018 08:36:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Mar 2018 08:36:17 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDMNDCNA64OBB6WVSPKQKGQE34PQP5Y@isocpp.org Sun Mar 11 09:36:13 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1euwSi-0001AX-Qn for gclcip-std-proposals@m.gmane.org; Sun, 11 Mar 2018 09:36:12 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id b64sf4433098vkf.2 for ; Sun, 11 Mar 2018 00:38:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=9RShAWCzZgh4JP5IC+URE/wSoLYJK/QUtzF9USsKUZE=; b=QhZwqn8Rv5HPWzYRzfO+V5nqSNhoZiBLATB26ynVRc7XTtaHJTanfUgu51weIW7SeG +FxptvD3/TGW3Loy3B/D/QaAw4a7x4pxX5rou3Aq7J/HDzFyF5gyK2Xw0Q30vgj/TSQ2 A+IKfPl5OhPtuvMNtYPk3NQJD7An/xdZAsYfqdpfpB5hhiUOkDY7kKJoivkMC/R99w5N DGPhvG3wjSz77XCRpu3S9UMApPRm+np9IKR3gsJJaDTdZVPbSxH+6bd44Cb+LfVsMlth EqSJjXNYytC09hgD0K+EtSB4ENs5RNZKp3ItJZCJA2FVpKVRnOGCsF0zsKFSOFUB5R1f N5RQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=9RShAWCzZgh4JP5IC+URE/wSoLYJK/QUtzF9USsKUZE=; b=QHzhp8XqLb6UNKZdguTEv0H9NP+VYaZSQMpbZznn8W2yMEUu56ztqE5HjV1xWx+kqI 0EBtKR1JkSi7UyiDNrVSIvi804W167Ev47tV4Ib/ULT9SzLKWul81Fjo+acTY1rbRNvZ TMp1QR/BrSX5vkC9reNqQK+XhNg4fKhDk6aD7ksJkCsikS3ixsvOMUKfn33jrd95fi8Z c1GrYDt5TMzPG1YTK3kUdueBgyPpVtJIi4Hp9wluXxvvyEauinpLROgp29xeEbofmFQG 0nIOtI62m9QL6ll2euQGFUauICc2blU6/hzfk7+jWtvFv+64Yl4Ff57rcH0hy6qRR1pd PrLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id: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=9RShAWCzZgh4JP5IC+URE/wSoLYJK/QUtzF9USsKUZE=; b=j7PSf2CBUGjP/cRiwrf7fw3Ev5hH9D+pjm2jnxr32nxi/1UUBQNCxKxKLugt/5Gh3t qV1Y83rmgNfFJFmlzcXIwWEtvftsSITSJTo3UEu7B9GECHxGioSSDT56kSfJA11mu6uN /7DRjVAKMpNCge5WW97yLCxy3ykba28zBwxZ5z6azybfG1SGVRUnrQRL3OKxzElBo8Wr vLh3g34e8kQ5ovMRhjQMLa/9NHQKMe2/B7jwMEkZva2/tqX5pUpVUNpJzGXYguq02cH2 iaZOVSxaORRTRexGADh73mHU9QH0E8PNYQbWOKTJVoYdBLYuz37k/BTo2vLVicpdK/WA /gIA== X-Gm-Message-State: AElRT7Hc1VdYY8fxRzW7+WScVYB8Sf9A4vxFxRPsixHco+CeLs/XGCKa XdIMRiTmtHisdITUXoKNfdd0iA== X-Google-Smtp-Source: AG47ELvBYGV6waePrNDDz4LGRmgQqMmo7cyi6Xn2CPcOjnUPQRJx34IJpUU4zfstHJS8y4HVao+42w== X-Received: by 10.176.79.226 with SMTP id t34mr2003800uah.92.1520757499283; Sun, 11 Mar 2018 00:38:19 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.205.194 with SMTP id d185ls5784492vkg.20.gmail; Sun, 11 Mar 2018 00:38:17 -0800 (PST) X-Received: by 10.31.157.18 with SMTP id g18mr532508vke.2.1520757497680; Sun, 11 Mar 2018 00:38:17 -0800 (PST) X-Original-Sender: jeffersonCarpenter2@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:37287 Archived-At: ------=_Part_4686_264317583.1520757497056 Content-Type: multipart/alternative; boundary="----=_Part_4687_1570609456.1520757497056" ------=_Part_4687_1570609456.1520757497056 Content-Type: text/plain; charset="UTF-8" Not sure how this will be received -- I haven't posted here much. Just thought it would be worth mentioning this idea. Suppose you have an API that you want to optionally allocate storage for your user. They can either pass in a pointer to some existing allocated space, or pass in a null pointer and space is allocated for them. void foo(int *x) { if (x == nullptr) { x = new int; } // etc. } Just figured it would be a decent idea if the || operator received a pointer overload. Then you could write the more succinct void foo(int *x) { x = x || new int; } or even (ducks for cover) void foo(int *x) { x ||= new int; } would be nice. Currently, if I am not mistaken, || (excluding user-defined overloads) is a boolean-only operator. It is indeed the case that nullptr is the only value that becomes false when cast to a boolean, and all other pointer values become true. So I don't see how adding an || overload for pointers would break any existing code. The main thing that would make this a no-go would be if the semantics of || required that both operands be evaluated -- whether or not the left-hand one is false. Then the whole point as I see it would be lost - the above examples would merely leak memory. - Jefferson Carpenter -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1fea07df-46a6-4df2-865a-849be8f8d129%40isocpp.org. ------=_Part_4687_1570609456.1520757497056 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not sure how this will be received -- I haven't posted= here much.=C2=A0 Just thought it would be worth mentioning this idea.
<= br>Suppose you have an API that you want to optionally allocate storage for= your user.=C2=A0 They can either pass in a pointer to some existing alloca= ted space, or pass in a null pointer and space is allocated for them.
void foo(int *x) {
=C2=A0 if (x =3D=3D nullptr) {
=C2=A0=C2=A0=C2= =A0 x =3D new int;
=C2=A0 }
=C2=A0 // etc.
}

Just figured i= t would be a decent idea if the || operator received a pointer overload.=C2= =A0 Then you could write the more succinct

void foo(int *x) {
=C2= =A0 x =3D x || new int;
}

or even (ducks for cover)

void f= oo(int *x) {
=C2=A0 x ||=3D new int;
}

would be nice.

C= urrently, if I am not mistaken, || (excluding user-defined overloads) is a = boolean-only operator.=C2=A0 It is indeed the case that nullptr is the only= value that becomes false when cast to a boolean, and all other pointer val= ues become true.=C2=A0 So I don't see how adding an || overload for poi= nters would break any existing code.

The main thing that would make = this a no-go would be if the semantics of || required that both operands be= evaluated -- whether or not the left-hand one is false.=C2=A0 Then the who= le point as I see it would be lost - the above examples would merely leak m= emory.

- Jefferson Carpenter

--
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/1fea07df-46a6-4df2-865a-849be8f8d129= %40isocpp.org.
------=_Part_4687_1570609456.1520757497056-- ------=_Part_4686_264317583.1520757497056-- .