220 35700 <8de15bed-cea6-471e-9ed7-a6df92f2a128@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Jared Grubb Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Rotational shift operator Date: Fri, 1 Dec 2017 11:39:01 -0800 (PST) Lines: 95 Approved: news@gmane.org Message-ID: <8de15bed-cea6-471e-9ed7-a6df92f2a128@isocpp.org> References: <69593098-e2cc-487e-bd14-9001b27aa7c1@isocpp.org> <8575602.V2okVmv5xV@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1531_1591062369.1512157141750" X-Trace: blaine.gmane.org 1512157148 27213 195.159.176.226 (1 Dec 2017 19:39:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Dec 2017 19:39:08 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDVKDF4E7IDRBVW7Q3IQKGQEYNF53UA@isocpp.org Fri Dec 01 20:39:00 2017 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 1eKr9E-0006KB-Ms for gclcip-std-proposals@m.gmane.org; Fri, 01 Dec 2017 20:38:56 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id t20sf4301786vkb.17 for ; Fri, 01 Dec 2017 11:39:04 -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: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=Qs4QLzMYhvBRJ3yyhaASGdlyiZeY423UnvMMS4fSa1w=; b=fX84WXtJo6I5CB5qTK7yTfkWEalbPH3eNBy5Lhv6c4AZYKInN3fyplGidYxsWI9QUn mKdycQajSqqNFZeLkm3T/Y/uupv5RSSOr2xGGesnWH5OoeB3TEgWldZW0iqtPEJ3dfTS /IfCluSQVG8TQky3EImFGI+kK6yB4QA9kfeXMlKILbdMqjy9BdvtEjyblgeRHkcR64tb zLfABYbkn+an+fehn1zkp+xa7aOKmblQZsHEOkxFCsaLDXMvM0I5nxFG7L92w8JpL3Rf 9NCCmpW4FCnwl8bFuq8NfCTrjAUwPoqqWHHkd768x7AUMpLbsf2wtE5cY/q8cdC96ByJ kDfg== 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=Qs4QLzMYhvBRJ3yyhaASGdlyiZeY423UnvMMS4fSa1w=; b=tQWilpsL8CieUP5H08To7YuVObCv5tKVv/K6dF6vYZWGEgJ8YW/YDjCKiD9o3xhxZv bW3a789JaQTQGrtdVGljh4+J/g5xzU9r2Ziv3qUUn01OwIqNThsyOA3AgFdhMhcciC3q S5ZRetGaJ4rWOZtDvvNvq9pD1KsFS946AOrDV36CekFlb+J1fSudYRWCsMmwCy4/XEjQ B5bAwmm9Pj6oCvQOuv2+/VNKGI38b03h5ZosV/qLXQGxvKDpcyp/7Oqb56rG3qAYQoYo Hbn8JdQyqeZvjh3uBYOywe2UIbeL+uhYN2fnayZLBQR/7big5zgT1K3m8+Q7ZJeFotUx jo2Q== 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=Qs4QLzMYhvBRJ3yyhaASGdlyiZeY423UnvMMS4fSa1w=; b=KdRXXL11FM4GYKn1J/o3nYOl6KwhJSwQheBG1s/cakdzPxbIwpYc2y4yl6Wrj3fy64 Ap6OV5tki/sDhtp5Sar/gvqBjX52M/7uAIximhsyduoGn8lNrLeL53k5E36pUUjBn2g4 MkpgI0ci5t+4MGDECBTGdusHioodTHUi73dxcGm7VZXPbYOlkPevqQ2k5w0U98BYiEEg xr4UtcQbl+bhZDltgo4PLFKvzLpzPbVnbucI2xEjv8HLJIVWP2QlxIW82TXBoRJGSOWX tMDPzR8ol6EJuk1ENjHvrGaGq1qb6+jxxNyff1u5Imt2QIGCSgMEMps16ucrh+NCKGIA 7Tng== X-Gm-Message-State: AJaThX6bROsAgrc0oEaB6ZCFRp1FgKbMeW+/9pzvKV5JrY0pKcU8eJ95 yGbtVMd+CNsozRC5cuxVTKI/1g== X-Google-Smtp-Source: AGs4zMZJj6IYBKb8yGUUeE/ClBAcxKAyDT+ndCSgbqnKhG8Ul0cFa/EkFDANoHHskUB9wDI7BkzC1w== X-Received: by 10.176.9.233 with SMTP id e41mr3542093uah.39.1512157143730; Fri, 01 Dec 2017 11:39:03 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.159.50.104 with SMTP id y37ls464873uad.10.gmail; Fri, 01 Dec 2017 11:39:02 -0800 (PST) X-Received: by 10.31.161.87 with SMTP id k84mr438865vke.10.1512157142288; Fri, 01 Dec 2017 11:39:02 -0800 (PST) In-Reply-To: X-Original-Sender: jared.grubb@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:35700 Archived-At: ------=_Part_1531_1591062369.1512157141750 Content-Type: multipart/alternative; boundary="----=_Part_1532_1910257527.1512157141750" ------=_Part_1532_1910257527.1512157141750 Content-Type: text/plain; charset="UTF-8" On Friday, December 1, 2017 at 8:36:41 AM UTC-8, Hyman Rosen wrote: > > > The most natural behavior for a compiler is to do exactly that - it > allocates memory for > objects, and reading the object just returns whatever is in that memory. > Although you might expect that to be the "natural" thing to expect, that's not actually how modern operating systems work. For example, I recommend you watch Facebook's exploration of trying to do strings better. (https://www.reddit.com/r/programming/comments/56xxmb/the_strange_details_of_stdstring_at_facebook/). In particular, start watching that video at time 21:00 and see the explanation of what happens when you try to read uninitialized data on a new memory page (explanation starts about 24:45 or so). Are you arguing that the allocator or the kernel are also broken? This is how one (many? most?) modern allocators/kernels behave. If we were to change the compiler do the "natural" thing you propose, you're going to cause the program (or allocator) to pessimistically do extra work it doesn't have to do today (eg, require that malloc zero-initialize everything it allocates, or require that malloc returns a pointer to real allocated pages instead of providing pages on demand like it can do today). It's far better to ask programmers to write sensible code -- not to require the compiler to make *all* code slower just to save us from shooting our foot when we write silly code. -- 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/8de15bed-cea6-471e-9ed7-a6df92f2a128%40isocpp.org. ------=_Part_1532_1910257527.1512157141750 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Friday, December 1, 2017 at 8:36:41 AM UTC-8, H= yman Rosen wrote:

The most natural behavior for = a compiler is to do exactly that - it allocates memory for
objects, and = reading the object just returns whatever is in that memory.=C2=A0

Although you might expect t= hat to be the "natural" thing to expect, that's not actually = how modern operating systems work.

For example= , I recommend you watch Facebook's exploration of trying to do strings = better. (https://www.reddit.com/r/programming/comments/56xxmb/the_strange_d= etails_of_stdstring_at_facebook/). In particular, start watching that video= at time 21:00 and see the explanation of what happens when you try to read= uninitialized data on a new memory page (explanation starts about 24:45 or= so).

Are you arguing that the allocator or t= he kernel are also broken? This is how one (many? most?) modern allocators/= kernels behave. If we were to change the compiler do the "natural"= ; thing you propose, you're going to cause the program (or allocator) t= o pessimistically do extra work it doesn't have to do today (eg, requir= e that malloc zero-initialize everything it allocates, or require that mall= oc returns a pointer to real allocated pages instead of providing pages on = demand like it can do today).

It's far better = to ask programmers to write sensible code -- not to require the compiler to= make *all* code slower just to save us from shooting our foot when we writ= e silly code.

--
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/8de15bed-cea6-471e-9ed7-a6df92f2a128= %40isocpp.org.
------=_Part_1532_1910257527.1512157141750-- ------=_Part_1531_1591062369.1512157141750-- .