220 39291 <87240a3d-623f-4f7f-8e7c-fa8c9482fa72@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: gmisocpp@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Alternative proposal for mapping P0709 Deterministic Exceptions into C Date: Sun, 22 Jul 2018 16:00:59 -0700 (PDT) Lines: 75 Approved: news@gmane.org Message-ID: <87240a3d-623f-4f7f-8e7c-fa8c9482fa72@isocpp.org> References: <6a65c934-5d2a-4e75-b88d-9eaaee338bd3@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7711_1738017687.1532300459975" X-Trace: blaine.gmane.org 1532300336 31581 195.159.176.226 (22 Jul 2018 22:58:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 22 Jul 2018 22:58:56 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCM3TRNUXUDBBLEZ2TNAKGQEHW2IAJI@isocpp.org Mon Jul 23 00:58:52 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f198.google.com ([209.85.213.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fhNJT-00086t-D7 for gclcip-std-proposals@m.gmane.org; Mon, 23 Jul 2018 00:58:51 +0200 Original-Received: by mail-yb0-f198.google.com with SMTP id b18-v6sf9117001ybq.9 for ; Sun, 22 Jul 2018 16:01:02 -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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=oaeZdDOik80e7+/rvtXJMQZoPuyHB+Q/kj5690/iiLg=; b=tbGjWvsgDOQmW76cKD8vthjwdbPmx3INVrx/nO51sbCOD/vTRLPSQJPQPH/sqnaZuH ekUcWN+i454lTwIIzjy6kIDJi+abOS1rsAagr+WkQ4aUpyTqthtUk1t9Jb5GhTOheuGd 4c9HfL9MdOtvkptsz94/mJGod3HBp9XV+SqXMTZXdXeGOqwbp7jl+1u6lSnzqJYKsYyn Y+/imY9m5qFsdM8RWWa0tOs5zYGWOc61t5p1o3cxhvcRV/vaFxt8oJ6/MiOnamkOKKRv 2GIqBFmWIo7KHYXt5VH8hHURv8dsTx3SX+SZQ4SSmjC26j+BVGtMm4bTvuesQ4KIesvF U7zQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=oaeZdDOik80e7+/rvtXJMQZoPuyHB+Q/kj5690/iiLg=; b=YtGjJxobnuobfaf8jzOpWmmxL6PCRs5N/yQKRqpEbNHsFcg2yByYSDpRXm2+kvB8vL c3g5PR4gY5iESd1vw8rBMQu7k5GV5erNvXjYkeowH4wbPsnzRbWWVRQNimRI8FdylyX4 RG8sywLrRT7/HJxZKXGjVxpsc/gnYQ1BjjR7vlOI1flbGnhxWbbhzGH9go9nwWtfOrmv 5fFQIZyuhRbK0W2zaU2IUGqJ9ZiWE+CItYTi/CDajX7RjD8FXKhroQy5s0qg6jjbogbk cRu+ldrrmhIzAV96YHzdOVqE1am2IkiClpZUYZtZ14bPpqiVzD1MJIrgpX5LPFXnyJTl 1ROQ== 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: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=oaeZdDOik80e7+/rvtXJMQZoPuyHB+Q/kj5690/iiLg=; b=kBfqYnNzIfe2tj+iF7W9T44VP/gCkg3J28EK92AHOUeJuV9HAtoft9hEkIDOep8A+u KGBoV4pONwHLnvhftaMmUDamz2fLMKIxylkUQDTAfmo4YgUIP2QYyNtgmqMcFoTGMjqM Xpc0Di08X7qlc+fbI1s9FH8vCK3f+q1f92+0QZlI5Xq9X5eA0y7suzEaig/oIcQTZK3V fs5XDc6bHGQ+oWPld61rxD25Lt3TSNVUjzAmivzhHZoEYjyR2GTNwCF+yg+aj8vINjsB UFnRwzXpQTKFASMc0EQ/wdtgzcn/nQFBVaQ1tcjVqcXL4/PZvnno5X64y15Qp1ymzbdU 9MQQ== X-Gm-Message-State: AOUpUlFn2bVBTI2IRwH/pl6jjgp8MwzPPMYpguUp+63gJLzMLV1EdSW8 0REMjNh0MQY17/otn6CjHCuEJA== X-Google-Smtp-Source: AAOMgpdjxX896X3/VreSt1daKod66XnRFpiO55adM3lZr9cJUUhzFt+bpxiwgZ8cH+8UIvygPFY5FA== X-Received: by 2002:a0d:f544:: with SMTP id e65-v6mr3351746ywf.238.1532300461904; Sun, 22 Jul 2018 16:01:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:6d44:: with SMTP id i65-v6ls1609550ybc.8.gmail; Sun, 22 Jul 2018 16:01:00 -0700 (PDT) X-Received: by 2002:a25:5f4a:: with SMTP id h10-v6mr211036ybm.5.1532300460683; Sun, 22 Jul 2018 16:01:00 -0700 (PDT) In-Reply-To: <6a65c934-5d2a-4e75-b88d-9eaaee338bd3@isocpp.org> X-Original-Sender: gmisocpp@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:39291 Archived-At: ------=_Part_7711_1738017687.1532300459975 Content-Type: multipart/alternative; boundary="----=_Part_7712_897747478.1532300459975" ------=_Part_7712_897747478.1532300459975 Content-Type: text/plain; charset="UTF-8" "To discriminate between integers and pointers we require that all pointers must point to data aligned at an even address, and that all error codes should be odd. We use then, the least significant bit of the error to discriminate between a pointer to some data containing further information about the error (error is even), and an integer that directly encodes information about the error (error is odd) 1" This to me seems pretty horrible. Overall, do we really need this 'expected' kind of type to be quite so constrained and magic, to require an even address etc. etc. In other words, if the type was actually something that was specified as a 'normal' C/C++ struct without any of those gymnastics and data packing or require some carry register etc., would the code be that dramatically worse that we should require such magic or constraints than a regular type without all the magic and alignment requirements? -- 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/87240a3d-623f-4f7f-8e7c-fa8c9482fa72%40isocpp.org. ------=_Part_7712_897747478.1532300459975 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

"To discriminate between integers= and pointers we require that all pointers
must point to data aligned at= an even address, and that all error codes should be
odd. We use then, t= he least significant bit of the error to discriminate between
a pointer = to some data containing further information about the error (error is
ev= en), and an integer that directly encodes information about the error (erro= r
is odd) 1"

This to me seems pretty horri= ble.

Overall, do we really need this 'expected= ' kind of type to be quite so constrained and magic,=C2=A0to require an= even address etc. etc.
In other words, if the type was actually = something that was specified=C2=A0as a 'normal' C/C++ struct withou= t any of those gymnastics and data packing or=C2=A0require some carry regis= ter etc., would the code be that dramatically worse that we should require = such magic or constraints than a regular type without all the magic and ali= gnment requirements?

--
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/87240a3d-623f-4f7f-8e7c-fa8c9482fa72= %40isocpp.org.
------=_Part_7712_897747478.1532300459975-- ------=_Part_7711_1738017687.1532300459975-- .