220 21454 article Path: news.gmane.org!not-for-mail From: Myriachan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: alias_ptr, restrict_ptr, unaligned_ptr Date: Thu, 8 Oct 2015 15:40:52 -0700 (PDT) Lines: 148 Approved: news@gmane.org Message-ID: References: <1580933.kjMTu375fQ@tjmaciei-mobl4> <2377636.q9WPHpPlTT@tjmaciei-mobl4> <73acad8c-5bb0-4c97-ada1-833b55af0be6@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_145_946078297.1444344052405" X-Trace: ger.gmane.org 1444344068 3117 80.91.229.3 (8 Oct 2015 22:41:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 Oct 2015 22:41:08 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDKLT4PURQHRB5PB3OYAKGQEV6T6WNQ@isocpp.org Fri Oct 09 00:41:08 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 1ZkJs1-00004q-9k for gclcip-std-proposals@m.gmane.org; Fri, 09 Oct 2015 00:41:05 +0200 Original-Received: by qgx61 with SMTP id 61sf74652406qgx.3 for ; Thu, 08 Oct 2015 15:41:04 -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=6Y528ARrRLAy3tO89UnJ8mwzCaZyK0cyGLhuYO9GJCw=; b=vmAJ7Sd3YbbDbRzwdTdLrY+9NhIGSTF9jwd4y7/jl0FDWi6zD8ivw+kninBOowHCTN dmMwH0dgarIBXuw9f39hSVfhf5ANMFnPcMk2+wkpN/es2oK7fZU/Lv5FpMVA2SuC7L3H qmUndjfsTvkxss9C74zTnVPzHFCQ6ikQ5+JOQTbpfxRILPcGil0EBaEHP4XNDW6zVCYz W2UA1zE1pRQ2Arb2gx6w3X7H8aNtsu+0radBQJotokl38VLUlQ7ECBHbcpdbYv/YQ8i8 i62QmcVvx114u2mK9EdunI0hx2AOpb4gWr59/t1IMVWeaY4efrnwQNztkVcPA+LVQZ+s cJxw== 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=6Y528ARrRLAy3tO89UnJ8mwzCaZyK0cyGLhuYO9GJCw=; b=SPhw6QbXLbyAAUxNdy7cTKH8iO1ZZIG6RgY4oGklqVIK1aSis9ZfGB92qo82UZWhcj +ycIK7pw++5f4Q0qZMuNZB82bQvElECMzPT7GWqo3Qzg7t8PfV8CYnhBRW2HHNKhEzRN TMPpZIGCcGiwdDe/QGzAQsdx75VfgN9ncjawTh6hk6VUwhOY0s6iV1vv4KAcjfrEXWXM 71QfCJ8WURb9AQr6Y2v2y0G16JwBE4DM8FhBP73j2J1TtJT71kWghdFvQ7tCopudOcx9 UuXJTpVMQwXABvR3j2FeXiMyfNhq7dC+v2BKsPS1RrQOja39/c0IYEMWqijf9LoP6htU LfyA== X-Gm-Message-State: ALoCoQm1Dt+hJ7tsvWiLOEJA4avbOyuOH98kEME6y416ciK7k3kkqNlCjT/EQ/md2Re7GeqYVlgI X-Received: by 10.129.72.205 with SMTP id v196mr8019302ywa.11.1444344064402; Thu, 08 Oct 2015 15:41:04 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.136.163 with SMTP id s35ls663499ioi.99.gmail; Thu, 08 Oct 2015 15:40:53 -0700 (PDT) X-Received: by 10.50.143.12 with SMTP id sa12mr94772igb.7.1444344053205; Thu, 08 Oct 2015 15:40:53 -0700 (PDT) In-Reply-To: <73acad8c-5bb0-4c97-ada1-833b55af0be6@isocpp.org> X-Original-Sender: myriachan@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:21454 Archived-At: ------=_Part_145_946078297.1444344052405 Content-Type: multipart/alternative; boundary="----=_Part_146_1522848395.1444344052405" ------=_Part_146_1522848395.1444344052405 Content-Type: text/plain; charset=UTF-8 On Thursday, October 8, 2015 at 5:53:32 AM UTC-7, Nicol Bolas wrote: > > That's more-or-less what I was thinking. By taking the TS route, you get > to actually define a lot of behavior, without breaking certain classes of > machines. > > What is the difference among the proposal types? > However, IEEE-754 would still be a bit... dubious. There are many ARM > platforms that have to emulate floats in software. At the very least, there > should be a way to test whether floats are real IEEE-754 or emulated. > > Isn't that what std::numeric_limits::is_iec559 is for? Also, isn't what is relevant at this level is whether the *object representation* of these types is IEEE-754, regardless of implementation? I'm not asking that the code I gave always work on all implementations; I'm asking that the code I gave always work on all implementations *in which float is unpadded IEEE-754 single-precision*. People write code *all the time* that is not portable to such... irregular > machines. At least this way, they'd be using well-defined behavior, not > relying on what seems to work. And they'll have a way to test whether it's > there or not and fail to compile if it isn't. > > That's what I'm seeking with something like alias_ptr: a well-defined method of accessing implementation-defined behavior. If the example code I gave would cause an exception when read back into a float on a given processor, that's perfectly fine. Invalid object representations are already undefined behavior, though what defines a valid object representation is implementation-defined. In all, overwriting a variable using a wrong-type alias_ptr would be defined as equivalent to std::memcpy. restrict_ptr and unaligned_ptr, on the other hand, are easier. The only issue I see with unaligned_ptr is just with my example: that initial reinterpret_cast of the pointer may itself be invalid. If that's a problem, an alternative would be to have unaligned_ptr's constructor take a void * parameter instead of a T *. unaligned_ptr doesn't otherwise do anything crazy, because you already can std::memcpy an aligned type to an unaligned position in, say, an unsigned char array. Really, alias_ptr and unaligned_ptr are syntactic sugar for std::memcpy, in a manner that is much like many programmers like myself are unfortunately used to. Melissa -- --- 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_146_1522848395.1444344052405 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thursday, October 8, 2015 at 5:53:32 AM UTC-7, Nicol Bo= las wrote:
That's more-or-l= ess what I was thinking. By taking the TS route, you get to actually define= a lot of behavior, without breaking certain classes of machines.
<= br>

What is the difference among the proposal ty= pes?
=C2=A0
H= owever, IEEE-754 would still be a bit... dubious. There are many ARM platfo= rms that have to emulate floats in software. At the very least, there shoul= d be a way to test whether floats are real IEEE-754 or emulated.
=C2=A0<= /div>

Isn't that what std::numeric_limits<float>::is_iec559 = is for?=C2=A0 Also, isn't what is relevant at this level is whether the= object representation of these types is IEEE-754, regardless of imp= lementation?

I'm not asking that the code I gave always work on = all implementations; I'm asking that the code I gave always work on all= implementations in which float is unpadded IEEE-754 single-precision.

=
People write code all the t= ime that is not portable to such... irregular machines. At least this w= ay, they'd be using well-defined behavior, not relying on what seems to= work. And they'll have a way to test whether it's there or not and= fail to compile if it isn't.


T= hat's what I'm seeking with something like alias_ptr: a well-defined method of acce= ssing implementation-defined behavior.=C2=A0 If the example code I gave wou= ld cause an exception when read back into a float on a given processor, tha= t's perfectly fine.=C2=A0 Invalid object representations are already un= defined behavior, though what defines a valid object representation is impl= ementation-defined.=C2=A0 In all, overwriting a variable using a wrong-type= alias_ptr would= be defined as equivalent to std::memcpy.

restrict_ptr and unaligned_ptr, on the other hand, are easier.=C2=A0 The o= nly issue I see with un= aligned_ptr is just with my example: that initial reinterpret_cast of the pointer ma= y itself be invalid.=C2=A0 If that's a problem, an alternative would be= to have unaligned_ptr<= /span>'s constructor take a void * parameter instead of a T *.

unaligned_ptr doesn't otherwise do anything c= razy, because you already can std::memcpy an aligned type to an unaligned position in, say,= an unsigned char array.

Really, alias_ptr and u= naligned_ptr are syntactic sugar for std::memcpy, in a manner that is much like many= programmers like myself are unfortunately used to.

Melissa

--

---
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_146_1522848395.1444344052405-- ------=_Part_145_946078297.1444344052405-- .