220 37529 <7b853bcd-47f5-4c2c-841b-13e30472e14c@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Remove floating point requirement for unordered (multi) set/map Date: Wed, 28 Mar 2018 07:31:46 -0700 (PDT) Lines: 129 Approved: news@gmane.org Message-ID: <7b853bcd-47f5-4c2c-841b-13e30472e14c@isocpp.org> References: <4c98e549-8f0c-42e5-a054-0234f7cf1e46@isocpp.org> <9d4a8ea3-9e7d-4851-8b28-5cd67779081a@isocpp.org> <1356e140-2985-4fe7-b9ee-70e40738d1cf@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_22399_1409633125.1522247506614" X-Trace: blaine.gmane.org 1522247388 8069 195.159.176.226 (28 Mar 2018 14:29:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2018 14:29:48 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBVGO53KQKGQEHHLR4VY@isocpp.org Wed Mar 28 16:29:44 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 1f1C57-0001xl-L1 for gclcip-std-proposals@m.gmane.org; Wed, 28 Mar 2018 16:29:41 +0200 Original-Received: by mail-ua0-f200.google.com with SMTP id h5sf1679337ual.18 for ; Wed, 28 Mar 2018 07:31:49 -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=XrAGJF9wR5Ie/doTSXW+4PiYZ9v9Y/vUxIHayi4oM34=; b=lFaVX0W8Jf+QQbQA2vbYokADEqWN9/YZf3nNCI/bch52EtfPa9eCWs8B+owqBfPseu ZKf531mbzbl4++1Os3TDfXPM97fvJFmvDtIJWsyDZrV+Pj66ihP0LbClk3aYl8+hGfFb eGN3JJUw1DDCOVg3/F772sEBrRaFhKCs06KlaFUWGCjO+g7dLAuA6JWOV8boDLdKmcOq Ik7y9hD59vslJ0lL2zMj0KVmEnkj9k4WU8L9rZxSiptT7aDrkU1jYySv0bDIFF1XZu/L jkPZycf1ZieDt5Hp7XDygk4jxlDbKbAm9kYFicE1a4MlAGL6fbHWVU3T2GZ0wmGZyR6G IsXQ== 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=XrAGJF9wR5Ie/doTSXW+4PiYZ9v9Y/vUxIHayi4oM34=; b=HrrElVCAYFFGVVZGRzMuYgFf6RBlW3K9X9CWc9eCzBvJZIVtv/1zdGoQ5W0zC3VKPm L1M//6GYjc3B1UeGdLWxWI6K+BSBC/Ecs74/C70WQRZkOlU2XFnNUD+7s7yBZ+cGNkpj Y0XYsxEG+DKQHXJLXd21oUm6Gu6t1vJFIJqqo26dZoxphQgqNStjWpZ543oub4BO0622 EWrFdJGqSa42MA6CzRSHJdylmTzNzdtXrWFDcTnkxSSzTpg2Fu0S853tuIBx4D+VKtsP LuVEAIxo+BfGYvHp/KLCCAfddEICpvpcwbEZaZh5QH0t636AiHuXhfUbCqfEVhWUULXn 5ifw== 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=XrAGJF9wR5Ie/doTSXW+4PiYZ9v9Y/vUxIHayi4oM34=; b=Z61WWHDInO+ztD9+/txq64ZDEZnC9NMLvi8K56YF92WB1NrZrOXDnHunVOvZvUD8vV CnTjG4YXOwF12+gdTpv/UWfZMqMprNdUmjonF4ZKcMnVuSRld1P1eqFAk7Y41z1pJRP3 //nVBADwZs/LcMBp1F0fydTopx9MvYZKEaZEFPSXUhNirEE7KDme2echf9MucvNWgEs2 FVnYTpudOR/YxZsIegtkORISUjye1xEyoGshW6tB64McthK9/1HIhEmBHqk+HD3jtApo 7oBnI/HF9T+La5nIbtbRks8JJ2NjQl7ABwYo7YKxVfmZo5HOdZjnzfIOH0ErVlJ4fvbg VNxw== X-Gm-Message-State: AElRT7FWcs1p4o/JSVDitC2ZiywcxqpQFcn1eWZPAGGN+UGnFqff/Kw0 0VZ3ibeeC4Qfvr0NvAtuCT7vvg== X-Google-Smtp-Source: AG47ELt/CAtA01fteQsdKhHBfR/VL/TUcUuj23NrsoLrjVW6JRD9PaBPFa3TFwpq24nUWyqcA/tffw== X-Received: by 10.31.248.68 with SMTP id w65mr16147835vkh.97.1522247508952; Wed, 28 Mar 2018 07:31:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.168.77 with SMTP id r74ls2317297vke.17.gmail; Wed, 28 Mar 2018 07:31:47 -0700 (PDT) X-Received: by 10.31.148.135 with SMTP id w129mr2106187vkd.14.1522247507093; Wed, 28 Mar 2018 07:31:47 -0700 (PDT) In-Reply-To: <1356e140-2985-4fe7-b9ee-70e40738d1cf@isocpp.org> X-Original-Sender: jmckesson@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:37529 Archived-At: ------=_Part_22399_1409633125.1522247506614 Content-Type: multipart/alternative; boundary="----=_Part_22400_1326985161.1522247506614" ------=_Part_22400_1326985161.1522247506614 Content-Type: text/plain; charset="UTF-8" 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"? 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. 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. 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. 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? > 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/7b853bcd-47f5-4c2c-841b-13e30472e14c%40isocpp.org. ------=_Part_22400_1326985161.1522247506614 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, March 28, 2018 at 9:40:15 AM UTC-4, Kevin Fi= tch wrote:
Sor= ry for replying to myself, but I wanted to clarify a few things. First, I t= hink one of the greatest strengths of C++ is the philosophy of not making y= ou pay for features you don't want/need.

But= you have to temper that with the question: what is a "feature"?<= br>
A particular class or function from the standard library could be co= nsidered a distinct "feature". Indeed, freestanding implementatio= ns are not required to implement all parts of the standard library.

= But I have a hard time seeing fundamental types as distinct "features&= quot;. They're called "fundamental" for a reason. I don't= see a good reason why the standards committee needs to design interfaces o= n the assumption that even seeing the keyword `float` constitutes a = major disruption to a programmer.

That doesn't mean that they sh= ould randomly insert `float` for no good reason. But it also doesn't me= an that they need to use inconvenient types (like a `std::ratio` or whateve= r) just to avoid using it in interfaces where `float` would otherwise be qu= ite natural.

While there are legitimate cases for arguments along the line= s of "a conforming implementation could..." those need to be cogn= izant of reality. In particular the number of conforming implementations is= MUCH smaller than the number of applications using those conforming implem= entations. Also, the kinds of restrictions I am concerned with are more a f= unction of the application than the platform. Some users of a platform with= out floating point hardware (e.g. Arduino) might see software floating poin= t 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 floati= ng point as a nonstarter due to things like code size and runtime.

So, the code size and runtime costs of `float` are too m= uch for you, but the memory and runtime costs of `unordered_set` are fine?<= br>=C2=A0
It should be the goal of the standard to encourage implementations that c= an gracefully scale in multiple dimensions (required features, code size , = memory usage...) to fit the needs of any given application. Adding non-floa= ting-point methods for dealing with load factor would allow conforming impl= ementations to be written such that applications that don't want to flo= ating point, don't have to use floating point.
<= br>=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/7b853bcd-47f5-4c2c-841b-13e30472e14c= %40isocpp.org.
------=_Part_22400_1326985161.1522247506614-- ------=_Part_22399_1409633125.1522247506614-- .