220 21383 <63bcac2c-9d1b-4630-91ed-db588475d61e@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: alias_ptr, restrict_ptr, unaligned_ptr Date: Tue, 6 Oct 2015 15:30:43 -0700 (PDT) Lines: 151 Approved: news@gmane.org Message-ID: <63bcac2c-9d1b-4630-91ed-db588475d61e@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5523_2084150407.1444170644013" X-Trace: ger.gmane.org 1444170650 28877 80.91.229.3 (6 Oct 2015 22:30:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Oct 2015 22:30:50 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBFMX2GYAKGQET7XB6GI@isocpp.org Wed Oct 07 00:30:50 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f71.google.com ([209.85.192.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zjakx-0001JL-2V for gclcip-std-proposals@m.gmane.org; Wed, 07 Oct 2015 00:30:47 +0200 Original-Received: by qges62 with SMTP id s62sf18592388qge.1 for ; Tue, 06 Oct 2015 15:30:46 -0700 (PDT) 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 :content-type: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=2FQijGl0dGCIgvjx3BDUKGOxX4Xt84GpN/nMMAaIq0g=; b=G8zLz3ruet3dyNS3wjhF9pYTQgQZ53kyKdBL8mb3EeQxGdLpVsCZbzNAEsim30q7TI 9vkMr1gRv7mPDYPA5N8VRlvqUGaCmJjqK1t2tixrP5F1XdrsEDiywBgE2ehzylfc1lIS EWeTppOesUkHTYsOn/WEq1DjpFP9Vh5AnJyldakpnJ9mTopv2mQIAhTZ5GCduMXlleoF pmbCCt9nBTgq3g6Cy1vhZeL9SFNJ+taISR1zPzE4j+5UpRyCvAsWnSwPfGn7aGsDUBVq DOIMYZtqMWCgrk8de+KE8CbqQAM2hFd8TiMNm8c7DtJazy+hKy+XRN1cCFEStm+9O8Z9 t70g== 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:content-type: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=2FQijGl0dGCIgvjx3BDUKGOxX4Xt84GpN/nMMAaIq0g=; b=d1KLtK9q0Bw8x+zkyJBARY54AvF6AfqOi92n6Zt29yDplMcn18ZF1127wuLYAUq9YH lZpQz2P2uRqToPsg+qWRjnOKmL+Vr+WfDcO2OenmdVOoeYu2xQI9xvqfsOCZHDUy8dzB TeJbr17rmxuRmE82eoF0clC1gZblML1eAdSvY6ely2PNN2M6fgsVM9uwUKPkcCBwD0z3 c8x0dM9qJJaCcNJaXPJ2ZvLe4cwOU2SHe4189LxG+LzBEH/4d3P5YNMdhXPmMNs4otcH JurUWmjoZaymDGJy4kU3ax7Z2Tt+OfT/YClp4i8/6MuVXhlTQFa/6Tbc+C4YrU2GKZaS Wurw== X-Gm-Message-State: ALoCoQmJ6gU9fDc3Mi139Ly0D2Ck4KhHnj16eMe4x28P9LIiR5zMDSoZmMo3VHTqmSSl2VYyhd5H X-Received: by 10.129.78.205 with SMTP id c196mr19394026ywb.21.1444170645845; Tue, 06 Oct 2015 15:30:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.5.139 with SMTP id 133ls23779iof.107.gmail; Tue, 06 Oct 2015 15:30:45 -0700 (PDT) X-Received: by 10.50.43.195 with SMTP id y3mr117436igl.1.1444170645186; Tue, 06 Oct 2015 15:30:45 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:21383 Archived-At: ------=_Part_5523_2084150407.1444170644013 Content-Type: multipart/alternative; boundary="----=_Part_5524_1889809589.1444170644013" ------=_Part_5524_1889809589.1444170644013 Content-Type: text/plain; charset=UTF-8 On Tuesday, October 6, 2015 at 4:46:49 PM UTC-4, Myriachan wrote: > > I think that there should be ways to request pointer aliasing, the inverse > (restricted pointers), and unaligned pointers. > > For alias_ptr, you'd tell it the type being pointed to, and maybe the > types it could alias. The latter is an optimization, but not really > necessary. > > int main() > { > float f = 2.0f; > std::alias_ptr alias = reinterpret_cast(f > ); > *alias = 0x3F800000u; > std::printf("%f\n", f); // prints 1.0 on typical architectures. > } > > The Standard For Programming Language C++ exists for one purpose: to define *behavior*. Not behavior "on typical architectures"; behavior *everywhere*. You have three options: 1) The standard mandates what this code will return. 2) The standard considers it valid, but the value will be implementation-defined. 3) The standard considers this undefined behavior. Creating a feature who's *only purpose* is to trigger undefined behavior is not acceptable. Creating a feature who's only purpose is to trigger implementation-defined behavior is... of dubious merit. And #1 is not reasonably implementable across the broad spectrum of C++-capable hardware. You'd basically be preferring some platforms over others. I would much rather see this provided as some kind of platform-specific functionality, rather than an actual part of the standard. Maybe a technical specification or somesuch, something that is conditionally implemented on platforms where it can be defined. For unaligned_ptr, it would allow access to misaligned objects on hardware > for which this matters. > It's not clear that some platforms could even really implement this. So this has the same problems as your `alias_ptr` idea. -- --- 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_5524_1889809589.1444170644013 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, October 6, 2015 at 4:46:49 PM UTC-4, Myriachan wrote:
I think that th= ere should be ways to request pointer aliasing, the inverse (restricted poi= nters), and unaligned pointers.

For alias_ptr, you'd tell it the type being pointe= d to, and maybe the types it could alias.=C2=A0 The latter is an optimizati= on, but not really necessary.

int main()
{
=C2=A0 =C2=A0 fl= oat f = =3D 2.0= f;
= =C2=A0 =C2=A0 std::alias_ptr<unsigned, float> alias =3D reinterpret_cast<<= span style=3D"color:#008">unsigned *>(f);
=C2=A0 = =C2=A0 *alias = =3D 0x3= F800000u;
=C2=A0 =C2=A0 std::printf("%f\n", f); =C2=A0// prints= 1.0 on typical architectures.
= }


The Standard For Programming Language C++ exists for one purpose= : to define behavior. Not behavior "on typical architectures&qu= ot;; behavior everywhere.

You have three options:

1) T= he standard mandates what this code will return.

2) The standard con= siders it valid, but the value will be implementation-defined.

3) Th= e standard considers this undefined behavior.

Creating a feature who= 's only purpose is to trigger undefined behavior is not acceptab= le. Creating a feature who's only purpose is to trigger implementation-= defined behavior is... of dubious merit.

And #1 is not reasonably im= plementable across the broad spectrum of C++-capable hardware. You'd ba= sically be preferring some platforms over others.

I would much rathe= r see this provided as some kind of platform-specific functionality, rather= than an actual part of the standard. Maybe a technical specification or so= mesuch, something that is conditionally implemented on platforms where it c= an be defined.

For unalig= ned_ptr, it would allow access to misaligned objects on hardware for= which this matters.

It's not clear that some platforms could even really implement t= his. So this has the same problems as your `alias_ptr` idea.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_5524_1889809589.1444170644013-- ------=_Part_5523_2084150407.1444170644013-- .