220 35602 article Path: news.gmane.org!.POSTED!not-for-mail From: Hyman Rosen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Rotational shift operator Date: Wed, 29 Nov 2017 13:43:16 -0500 Lines: 139 Approved: news@gmane.org Message-ID: References: <69593098-e2cc-487e-bd14-9001b27aa7c1@isocpp.org> <6888287.JoKhHhR3xM@tjmaciei-mobl1> <3058817.kvbDme98ge@tjmaciei-mobl1> <338adc98-aaff-21fd-32de-a048d72ca942@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11477f5e7e74aa055f2383d7" X-Trace: blaine.gmane.org 1511981020 31734 195.159.176.226 (29 Nov 2017 18:43:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 29 Nov 2017 18:43:40 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDKJJPVBQMKRBW777PIAKGQET7KNPHI@isocpp.org Wed Nov 29 19:43:35 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr0-f197.google.com ([209.85.128.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eK7KX-0007n3-3a for gclcip-std-proposals@m.gmane.org; Wed, 29 Nov 2017 19:43:33 +0100 Original-Received: by mail-wr0-f197.google.com with SMTP id 96sf2447576wrk.7 for ; Wed, 29 Nov 2017 10:43:40 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1511981020; cv=pass; d=google.com; s=arc-20160816; b=U88qgJpm+uuJCdWAeK/rljHoNHHxxtHopPcl9QhAZMEp4C/kgJx1FJJR+mFzGNSasl GI7iVhafYRF5WYKL60u3Y2MLr139vqtcrKHz2VreZKoAhZiKpaEt2jWzmY8R0sOy9uVj /0VJtDGjhUsJGErXr4I5FbQ2+EnQvQmVGgNUhP+CLFi4se6BfQORsmj1YLW2MXBqwfrE 4fLjzi4oKSTMghWZh7JAYtfhr0unydx55pwWKYvSqEHlB/NlxoXYFyS2KMmlFTqIOHA4 puJRn0HjROVDXSW1o9Taw6cgfX3KZ6o1mUg9qZdKKLsm+d8cx9KmpGlAs+He3V3uO3Bb O6pA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=KokqSYrK4S9nXMUc3ygq+gRiBJJyqRVRKTYo46K5qWc=; b=iJZSjV7DA0zNS6SZxnTR/un5TQ7eOIWbuJeLW13toGgNVhNeM4OduidrssaaYmvwmD fiLQi3RmP5kv8Cdro03HmuiBgUxB/x43A+DU5F9QUll8HEzRg0dJlegODlhTF6chfRYE 8eoHPsCkP/oveN93Pg3nomoN6e9ouYVWD4trYrKEaqr2sPpyAGekyLbY/Fp4tzrJM3TX EDWXPTspc6ubs4ndnwgsvm5Tj6oJxHaC/yTmFeXsKPNYxwyonovJtHjJTJ3LkpgMe8y+ SmdmPCVmUaUeMi8Pd2c49xgD/wq4nhCrrpcz1dfpMHlPh8TI+SDqBkn+e+FhPU2opGGp Fqxw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ya/5GNfY; spf=pass (google.com: domain of hyman.rosen@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hyman.rosen@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=KokqSYrK4S9nXMUc3ygq+gRiBJJyqRVRKTYo46K5qWc=; b=t3TDY+HPFfgc+kt/Z7oxEnfknKnOKTd4gHKas7pN+sZ3xpxCakbR3jrJxM+XpIZd0h dyuSRX4qGEDReBVpODQ6XFc/P1c6id7ob0so/MSzue6YutJMbB0mJk0nmwrUk6bEXprN AcXE5Je86NceXxmAW1QYX6BiWkRiOt6kBDZilC/LLvgiCAP53WHX5qDmg27wiISobKnA G1mWopHLEwcMiEfqx71qarqaz+O1VXPuw8XCPM5prW4P/YvAqCKGg5tYGnQ967bxX0Yo hk55p5EItzQKfKW0LnGM3KVQ4WM2cNM/EtGNwY5DxWMHYKHrobrFbjMldxAl9J9CuNvo 6bhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=KokqSYrK4S9nXMUc3ygq+gRiBJJyqRVRKTYo46K5qWc=; b=pOZ9uW96kwnfEMIMMyl/+fXeF4n4DXKa0ZlNNQ8N/hhk/XHQ0FnaMG3+vDW4QOG13p QOqT79uGp1QSjlgT9HdhURoNVeWX7A+BzO9YFbEf9pvfZX5cFrbvWs3W7ldChwjq5gRe c/TlHPDfQ7lP3C25IAzAwR43YgSHrh/eRslgvvk9y9HSkBUjcnFd3YlD1OhDbIDujMdn NirFFuqTS/o4fG1Wg32/1oV+DWovJ9Rh+j4hiZlyiR48G6jZSM8FXSSSIcabc9QLfR5b 2y1Vhu3hbWN9DVTW/dHAeTUBPxVGgyr2h3+uDKv0duj5AWtgQPmx4ptUpRRlLwJ5bcxO Fz+w== X-Gm-Message-State: AJaThX420eOSg9+I7vEMVV678hpfUypKjIjqP/TujbUWv/OQa9CoXfcq lH5JioHRwyB2KSRgeVeLzxq+Kw== X-Google-Smtp-Source: AGs4zMZ8lOQ7lfAOA8xG6HD6Ggycjh6QnfewiH4lwT/e46cJUlPwMKLCQZEkEW2SYA16592Y5M7ttA== X-Received: by 10.28.63.83 with SMTP id m80mr628816wma.10.1511981020456; Wed, 29 Nov 2017 10:43:40 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.223.168.1 with SMTP id l1ls5387696wrc.5.gmail; Wed, 29 Nov 2017 10:43:38 -0800 (PST) X-Received: by 10.28.153.210 with SMTP id b201mr3050360wme.2.1511981018882; Wed, 29 Nov 2017 10:43:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511981018; cv=none; d=google.com; s=arc-20160816; b=vCuc+7GAcUIqUvfzFXacsjI+K4NL7oLM1USr0wGArOer2tPTB2S1ZRVPP9JGJYngTu 8BQp4Wgi9duKGvxYCS2bPBbs6Xd4h5TUcMa1VAR+4z2GwjCcEtHiPqp9ugKYIhwKNWen mNkM6krkIigDINzF4BeHEGQwwxfOZMJHrwygScrBzlwUaEdE6KXJap1JDXOb4wGDkvZF 4wVt/aCXG91eCFWJdjlWlfh9tGYQV6LrkIucfAtm4xqb7dT72Y6fFNTuzvnHywtx9W2M v3WJ/md0cmiVAOc3+bJZbc1RexQBADfyktHKNcxbIRCEaz+XxvNjEn5P2swrpa5lHbiG xPYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=lSFKd+o1xYHYC0d37Hc1wZdLkTkf6IvKY9P2NWLfLQ8=; b=J3+Rw5xynPkzrV3LlOcQeMNCLidA5smIVI7xy1Kui9ylSQeewaYClpJL8Ia75uocj0 gKqM1wP0ncQBG2+Xml/bFYGJ/5Y9J1WTUsPSD+ZcTw2d9/YE2RrYV9hFd1RaK+e43+H/ sYIlZ1E81BOUbaxgR6yfXr/izz/U8AnuXc2siN4V/LR8aqk/SMXvB3uCitg/q4Dbc+4x ADqsMncVioCOmnc1JYSx10Sa89IsaYmVQRlI3RI4tQDzzvXRlWLT9kj+KjJXDtYtLnL0 6zkIfGq+pbefMfsSgjyuTTpCC8ZenZ9nInNFUjb2M8psP3RTCz/yAeMBrmCfuVH6Wnvy i9pA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ya/5GNfY; spf=pass (google.com: domain of hyman.rosen@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hyman.rosen@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id h7sor747188wme.83.2017.11.29.10.43.38 for (Google Transport Security); Wed, 29 Nov 2017 10:43:38 -0800 (PST) Received-SPF: pass (google.com: domain of hyman.rosen@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.28.107.16 with SMTP id g16mr3223052wmc.36.1511981018148; Wed, 29 Nov 2017 10:43:38 -0800 (PST) Original-Received: by 10.28.57.214 with HTTP; Wed, 29 Nov 2017 10:43:16 -0800 (PST) In-Reply-To: <338adc98-aaff-21fd-32de-a048d72ca942@gmail.com> X-Original-Sender: hyman.rosen@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ya/5GNfY; spf=pass (google.com: domain of hyman.rosen@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hyman.rosen@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:35602 Archived-At: --001a11477f5e7e74aa055f2383d7 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 29, 2017 at 12:36 PM, Andrey Semashev wrote: > > This means that the behavior of the code is undefined because its result > is different on every target platform, including different numeric results and traps. The standard should suggest that in the absence of traps, the behavior should be implementation-defined in an unsurprising way. This is not possible, because this means that the program can now not only > run differently, but also be *compiled* differently depending on the target architecture Of course it's possible. There is nothing wrong with having compilation results differ based on target architecture. If I have, as per your example, template bool foo () { return true; } template <> bool foo<0>() { return false; } then foo<0x8000u + 0x8000u>() will return true on platforms where unsigned is 32 bits but 0 on platforms where it is 16 bits. And what if the CPU issues a trap in this situation? Do you expect the > compiler to crash or something? > No, then I expect the compiler to issue an error and not compile the program. There is no UB allowed in constant expressions, precisely for this reason. So if you want some particular behavior, you have to define it, and it > should be a fixed single definition, not just "do whatever the CPU does". This, in > turn, means blessing one implementation and penalizing all others to the point > that a particular shift instruction is no longer possible to use. No, I completely disagree. Constant expressions should produce exactly the same result as runtime expressions. If the expression would produce a trap, the constant expression should not compile, otherwise you get whatever your target platform would produce. -- 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/CAHSYqdYXzAr6s-izPHjwB3-8RP_5PwGO5ms0PhmzuA%2Bqqdk45Q%40mail.gmail.com. --001a11477f5e7e74aa055f2383d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 29, 2017 at 12:36 PM, Andrey Semashev <andrey.semashev@gma= il.com> wrote:
This means that the behavior of the code is undefined because its result is= different
on every target platf= orm, including different numeric results and traps.

Th= e standard should suggest that in the absence of traps, the behavior should= be
implementation-defined in an unsurprising way.

This is not possible, because this means that the program can now not only = run differently,=C2=A0
but als= o be *compiled* differently depending on the target architecture

Of course it's possible.=C2=A0 There is nothing wrong with h= aving compilation results differ
based on target architecture.=C2=A0 If = I have, as per your example,

tem= plate <unsigned N> bool foo=C2=A0 =C2=A0() { return true;=C2=A0 }
template <>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0bool foo<0>() { return false; }
=
then foo<0x8000u + 0x8000u>() will return true on platforms where unsigned is
32 bits=C2=A0but 0 on platforms where it is 1= 6 bits.

And what if the CPU issues a trap in this situation? Do you expect the comp= iler to crash or something?

No, then I expect the = compiler to issue an error and not compile the program.

There is no UB allowed in constant expressions, precisely for this reason.<= /blockquote>
So if you want some particular b= ehavior, you have to define it, and it should
be a fixed single definition, not just "do whatever the = CPU does". This, in turn,
m= eans blessing one implementation and penalizing all others to the point tha= t
a particular shift instruction= is no longer possible to use.

No, I completely disagr= ee.=C2=A0 Constant expressions should produce exactly the
same result as= runtime expressions.=C2=A0 If the expression would produce a trap,
the constant expression should not compile, otherwise you get whatever y= our
target platform would produce.

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYXzAr6s-= izPHjwB3-8RP_5PwGO5ms0PhmzuA%2Bqqdk45Q%40mail.gmail.com.
--001a11477f5e7e74aa055f2383d7-- .