220 37534 article Path: news.gmane.org!.POSTED!not-for-mail From: Kevin Fitch Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Remove floating point requirement for unordered (multi) set/map Date: Wed, 28 Mar 2018 08:16:32 -0700 (PDT) Lines: 217 Approved: news@gmane.org Message-ID: References: <4c98e549-8f0c-42e5-a054-0234f7cf1e46@isocpp.org> <9d4a8ea3-9e7d-4851-8b28-5cd67779081a@isocpp.org> <1356e140-2985-4fe7-b9ee-70e40738d1cf@isocpp.org> <7b853bcd-47f5-4c2c-841b-13e30472e14c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7110_650115042.1522250192777" X-Trace: blaine.gmane.org 1522250073 4969 195.159.176.226 (28 Mar 2018 15:14:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2018 15:14:33 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCNZV4UAUMBRBUXD53KQKGQEL6KOKUY@isocpp.org Wed Mar 28 17:14:29 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f200.google.com ([209.85.217.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1CmR-000191-Lm for gclcip-std-proposals@m.gmane.org; Wed, 28 Mar 2018 17:14:27 +0200 Original-Received: by mail-ua0-f200.google.com with SMTP id w10sf1824450uac.19 for ; Wed, 28 Mar 2018 08:16:35 -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=92GoPUSP8qcmibIfREsK1P1cjD4nt8ScwVQQkb7UBa0=; b=w00Oe++YBOzL+TgteSrxDfic7bsDG8oCfCK8E/V3Nmj7RVJQi6i9+YQWWJkNc8W0PF TfZo+28wpafmhT0fyf96m23l2u9tOFvEHFThes/EeKq0kTJKRIqEv0Ona2K0ctgncnYw oidNbmiN7ZoEau4w951urxf1TB1U8rVFkg3u2w3aHAo62fp6lx41urcNvhHldVdDc5+4 SQOM2fTQKULmW8bbNMaN/+D0DyBSP3qdKOdRLprVL6ekJb+xyXCMRsG3rC1YFo6/MhdY cTiYdjZjptbEBrM8pLjwS16TWD5z9qPaXkL35s42v5mHHxXwtc7o+jRFtZ21oIdEi/iV rtkw== 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=92GoPUSP8qcmibIfREsK1P1cjD4nt8ScwVQQkb7UBa0=; b=EPFiGFt+hgoSFlJjP8HwqLKU/cT7lfe8wvMFGBzrz28zthQOET9Zmlt8CSmgas7Q5U MK1v8W0GiKI3H5a3G8C/YG9/SDZkYZ6ZyDSX6zwK1BPS3CCm4wpIoOgG/nqQm/WLRwt1 XkvUbW6hi+jprXBK+7/TphToruiG+ZUjJaGHghPMYEAV5TInqZGhYBW4D1TGwM+LCZyF +qDSGQHbULxZUPuTCmVCuHlnW9Sjarkmv2JQZ3tk2bEMFb9B6XlbJ65GUVfvIZnpQZF9 rahm9VLsHKYUQqfhDsOWKENsNmAK937aHkfqzKhYTraJSNQNNz2iabyv+Y3vZe9a3Q+Y crug== 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=92GoPUSP8qcmibIfREsK1P1cjD4nt8ScwVQQkb7UBa0=; b=hu65UuTlUYeOiSxXlZf6JUkTJNpU79Pwy37tS+VEABwEXFKGFt7xREZIzcEvDKbOT9 jYgk8kzrRCaDdPEYXTI+Fpnf+ME4mu8DJbcDeUy/zFNTEhwFNVfSeuENC94UODIIGAA6 IR5+qfLpcb6OCBDV+Zu7E2ktl4v+QCxrirhDsPVeHzg4vFdTuzNh9qPXHp+gKx5lXodX mdFX87LZWLrhN7mhn+SI5oh4Ur8155Ty+EWt9xHjVqzGiqygh3M98d4EDCIEg7EO2Sgc OQv0iYjooQSyKmEnQcpjH0yD3mJLwMft8QEXjKlw9Fj3T9sks5vPh4hAsBCMO90xuJOT LJhg== X-Gm-Message-State: AElRT7GU9QQoZUxh0BwdVAdkk+z0N76U5zIZVfSkG0NQ6zlXecg6hJcU 4JUnsoJ37Jd63fmyAgHnQJ9jhA== X-Google-Smtp-Source: AG47ELsyYuuB08UQn+uGSj2K0p3bhcLp9xyHQN1fcfC83ehrix1a7HXk9MwjS0Zh5m/mIL35t+2V3w== X-Received: by 10.176.6.7 with SMTP id f7mr11859033uaf.2.1522250194968; Wed, 28 Mar 2018 08:16:34 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.160.67 with SMTP id j64ls2443395vke.21.gmail; Wed, 28 Mar 2018 08:16:33 -0700 (PDT) X-Received: by 10.31.140.138 with SMTP id o132mr1414759vkd.8.1522250193382; Wed, 28 Mar 2018 08:16:33 -0700 (PDT) In-Reply-To: <7b853bcd-47f5-4c2c-841b-13e30472e14c@isocpp.org> X-Original-Sender: kfitch42@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:37534 Archived-At: ------=_Part_7110_650115042.1522250192777 Content-Type: multipart/alternative; boundary="----=_Part_7111_1743433310.1522250192777" ------=_Part_7111_1743433310.1522250192777 Content-Type: text/plain; charset="UTF-8" On Wednesday, March 28, 2018 at 10:31:46 AM UTC-4, Nicol Bolas wrote: > > On Wednesday, March 28, 2018 at 9:40:15 AM UTC-4, Kevin Fitch wrote: >> >> Sorry for replying to myself, but I wanted to clarify a few things. >> First, I think one of the greatest strengths of C++ is the philosophy of >> not making you pay for features you don't want/need. >> > > But you have to temper that with the question: what is a "feature"? > Yes, the word feature can be a bit nebulous. But looking at the landscape of computers chips and operating systems out there (i.e. the things the compiler generated code interacts with), there are many things that would count as "features": floating-point, MMU, SIMD/vector, multi-threading... Some of these are more relevant to C++ than others. C++ has been designed over the years to be able to work just find on both 8-bit micros running bare metal as well as massive mutli-core servers running "real" OSs. > A particular class or function from the standard library could be > considered a distinct "feature". Indeed, freestanding implementations are > not required to implement all parts of the standard library. > What I am concerned with is that os/cpu features that should be independent are being bundles into a single standard library feature that means I being pushed away from using the standard library. But I have a hard time seeing fundamental types as distinct "features". > They're called "fundamental" for a reason. I don't see a good reason why > the standards committee needs to design interfaces on the assumption that > even *seeing* the keyword `float` constitutes a major disruption to a > programmer. > I do see a good reason. On many platforms, using any floating point is a major step change that would disrupt the development process. Many projects I have worked on had a blanket rule against using floating point. The ones I have worked on that did not have such a rule were ones where floating point was central to task being accomplished. I don't think you can look at both the history and the current state of the computer chip landscape and not notice that while EVERY CPU has integer support, but there is a significant subset that does not have floating-point support. > That doesn't mean that they should randomly insert `float` for no good > reason. But it also doesn't mean that they need to use inconvenient types > (like a `std::ratio` or whatever) just to avoid using it in interfaces > where `float` would otherwise be quite natural. > I am not saying that we need to remove the 'float' functions, but I want to be able to fully use an unordered container without calling them, so that a decent compiler will elide them and avoid the costs that I don't want to pay. > > While there are legitimate cases for arguments along the lines of "a >> conforming implementation could..." those need to be cognizant of reality. >> In particular the number of conforming implementations is MUCH smaller than >> the number of applications using those conforming implementations. Also, >> the kinds of restrictions I am concerned with are more a function of the >> application than the platform. Some users of a platform without floating >> point hardware (e.g. Arduino) might see software floating point as a huge >> advantage (in terms of things like ease of development), while others using >> the same chip (e.g. the atmega 328p) might see software floating point as a >> nonstarter due to things like code size and runtime. >> > > So, the code size and runtime costs of `float` are too much for you, but > the memory and runtime costs of `unordered_set` are fine? > In a word, YES. I did not post here out of idle speculation. I ran into exactly this case. Embedded systems are not a simple binary distinction, it is not even something that is a simple 1 dimensional spectrum. Each system has its own set of requirements that lead to restrictions that can surprising. > >> It should be the goal of the standard to encourage implementations that >> can gracefully scale in multiple dimensions (required features, code size , >> memory usage...) to fit the needs of any given application. Adding >> non-floating-point methods for dealing with load factor would allow >> conforming implementations to be written such that applications that don't >> want to floating point, don't have to use floating point. >> > > > -- 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/af922ddf-a2c4-4654-a246-de2452477c95%40isocpp.org. ------=_Part_7111_1743433310.1522250192777 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wednesday, March 28, 2018 at 10:31:46 AM UTC-4,= Nicol Bolas wrote:
On Wednesday, March 28, 2018 at 9:40:15 AM UTC-4, Kevin Fitch wrote:<= blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border= -left:1px #ccc solid;padding-left:1ex">
Sorry for replying = to myself, but I wanted to clarify a few things. First, I think one of the = greatest strengths of C++ is the philosophy of not making you pay for featu= res you don't want/need.

But you have to tem= per that with the question: what is a "feature"?

Yes, the word feature can be a bit nebulous.=C2=A0 But loo= king at the landscape of computers chips and operating systems out there (i= ..e. the things the compiler generated code interacts with), there are many = things that would count as "features": floating-point, MMU, SIMD/= vector, multi-threading... Some of these are more relevant to C++ than othe= rs. C++ has been designed over the years to be able to work just find on bo= th 8-bit micros running bare metal as well as massive mutli-core servers ru= nning "real" OSs.
=C2=A0
A particular class or functi= on from the standard library could be considered a distinct "feature&q= uot;. Indeed, freestanding implementations are not required to implement al= l parts of the standard library.

What = I am concerned with is that os/cpu features that should be independent are = being bundles into a single standard library feature that means I being pus= hed away from using the standard library.

But I have a hard time se= eing fundamental types as distinct "features". They're called= "fundamental" for a reason. I don't see a good reason why th= e standards committee needs to design interfaces on the assumption that eve= n seeing the keyword `float` constitutes a major disruption to a pro= grammer.

I do see a good reason. On many p= latforms, using any floating point is a major step change that would disrup= t the development process. Many projects I have worked on had a blanket rul= e against using floating point. The ones I have worked on that did not have= such a rule were ones where floating point was central to task being accom= plished.=C2=A0 I don't think you can look at both the history and the c= urrent state of the computer chip landscape and not notice that while EVERY= CPU has integer support, but there is a significant subset that does not h= ave floating-point support.
=C2=A0
That doesn't mean that th= ey should randomly insert `float` for no good reason. But it also doesn'= ;t mean that they need to use inconvenient types (like a `std::ratio` or wh= atever) just to avoid using it in interfaces where `float` would otherwise = be quite natural.

I am not saying tha= t we need to remove the 'float' functions, but I want to be able to fully use an unordered container without calling=20 them, so that a decent compiler will elide them and avoid the costs that I don't want to pay.
=C2=A0

While there are legitimate cases for arguments al= ong the lines of "a conforming implementation could..." those nee= d to be cognizant of reality. In particular the number of conforming implem= entations is MUCH smaller than the number of applications using those confo= rming implementations. Also, the kinds of restrictions I am concerned with = are more a function of the application than the platform. Some users of a p= latform without floating point hardware (e.g. Arduino) might see software f= loating point as a huge advantage (in terms of things like ease of developm= ent), while others using the same chip (e.g. the atmega 328p) might see sof= tware floating point as a nonstarter due to things like code size and runti= me.

So, the code size and runtime costs of `floa= t` are too much for you, but the memory and runtime costs of `unordered_set= ` are fine?

In a word, YES. I did not = post here out of idle speculation. I ran into exactly this case. Embedded s= ystems are not a simple binary distinction, it is not even something that i= s a simple 1 dimensional spectrum. Each system has its own set of requireme= nts that lead to restrictions that can surprising.

=C2=A0
It should be the goal of = the standard to encourage implementations that can gracefully scale in mult= iple dimensions (required features, code size , memory usage...) to fit the= needs of any given application. Adding non-floating-point methods for deal= ing with load factor would allow conforming implementations to be written s= uch that applications that don't want to floating point, don't have= to use floating point.

=C2=A0

--
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/af922ddf-a2c4-4654-a246-de2452477c95= %40isocpp.org.
------=_Part_7111_1743433310.1522250192777-- ------=_Part_7110_650115042.1522250192777-- .