220 37580 <5001768e-3ea3-4c97-9867-43c5eb56e4ed@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Ben Craig Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Remove floating point requirement for unordered (multi) set/map Date: Fri, 30 Mar 2018 12:27:20 -0700 (PDT) Lines: 125 Approved: news@gmane.org Message-ID: <5001768e-3ea3-4c97-9867-43c5eb56e4ed@isocpp.org> 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> <1df72d61-2659-4864-9a6d-f8ea8fe52792@isocpp.org> <8eb5c7cd-42ec-46bd-8aee-842ef11b885e@isocpp.org> <2ad48eb7-a635-4aaf-9216-7a390791c083@isocpp.org> <8698cc1b-bce1-4c23-bf81-2cab986afe5a@isocpp.org> <7b2a1e15-f345-4749-ab74-b5a53b5dbed0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6875_1074325237.1522438040466" X-Trace: blaine.gmane.org 1522437920 10963 195.159.176.226 (30 Mar 2018 19:25:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Mar 2018 19:25:20 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDCM7T7A5UMRBGM77LKQKGQENYOGXKA@isocpp.org Fri Mar 30 21:25:16 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1zeF-0002g0-AA for gclcip-std-proposals@m.gmane.org; Fri, 30 Mar 2018 21:25:15 +0200 Original-Received: by mail-vk0-f69.google.com with SMTP id k12sf1769054vke.15 for ; Fri, 30 Mar 2018 12:27:23 -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=8rLB1uau0skThDTN09ix7G/iY+rlRCLBzTc3ECTGbT0=; b=HlXx+ub60yk0m0szDOf+5EIOVuNxoxLnhx5Rfft7AeoIgr4WtD+ec62TRHtt0wdSkL tx+h58oY0CY4+ZR+beUyNFLBJh5Og353Whos5FHMtvufV6FQYl3VOejlhKRrapZdEKxZ +270jRhU0ycAiyWTidZHGuOdSe9Ct3Hd5HqLoGm7x6x1lfW5l+dAe8yBqJ0dBL2s1NcN pTT5QpWzTFWscAdvGJ+2h2d45fBqaHupS/E/Gb234KJ+DtS6l8ZEWpdesJHxkjrM1jDB aO/y/K6wq8CgMYAy+Hh31fcbD6QVTSbtpnbVcFfMbzG5f02wAHFYFUMRpf5/N/HVoqpW U86Q== 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=8rLB1uau0skThDTN09ix7G/iY+rlRCLBzTc3ECTGbT0=; b=kiAL4wdtLghPmWOcBJepxqrzOWDrWO+oJb0lfV3el5V2umMU/Iy8ToqvfTIY0uo+2B lqgIJDqNnO4TrT2JoHI5v+Qx3D9cDBvhQaJa6wHQihTb5JNIXNYUTwRrR008KRBIjz6C Nt2ig4JVyTW1hoUeE3kffRsPHUQl0NSKjzYY39Drfx3qUydQx7tcHfAVYFFLll/xtCEd F6yYIrS9xAtK91piAac/j04p3qwwJOhJUlBfv/BpWuuprpvLFsMJM5FP5Fe4W4BvtwQN 305/tLzRz7H4eMAmz+k/YWAy3Lp5d1vKx4E9vnsQR+Tez4Bg/i31HSZvvRZhYZjypqxt 4MIQ== 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=8rLB1uau0skThDTN09ix7G/iY+rlRCLBzTc3ECTGbT0=; b=L8NCcWE1xMw3Mv8CW7VzvypDUy29x7NAPjquFefbTqK2QD5vEsoPlTAzkHXOuSlV6F mR5ttj/uE4gCgT6PnDRKCXTWb6IoLT5Wbo6QHUUBvi3Nb5O+L+wytp/D5kBFkN2CSBm8 W5C1RzfHAlB3kvCS0zkQXSx6YM6mg29Qe2hp1qUx2JpHxP8lpYxDSN2TxyNorHc4OWJA rqm6jrEUgM7aSrN0wCgzSVhLjAzB9xWuIfKs1NK+7q5kLtpfWzVTu1EH+mtDk7btbzgZ +cBpWd+ahz1N/Xt9jz0ycdVjAcuD0nhxLlyYyJs9SB0YyT6HT525tEbvSxS7e4VH3SjZ b0BA== X-Gm-Message-State: ALQs6tDHhgLmEHIdPq3+zTMaUHXpgCfAUWMORcR/aC+84zshwzaqQ8D0 bSrEos3T+YqPnf/oqoIIATzOAw== X-Google-Smtp-Source: AIpwx4+RC+thICssLUxOQBjTf2omynJPUL/zyvBSoWkRyjQ/b30dDHynpaEDaHISl2KkzL7dSaBlng== X-Received: by 10.31.248.68 with SMTP id w65mr96699vkh.97.1522438042643; Fri, 30 Mar 2018 12:27:22 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.168.77 with SMTP id r74ls5259553vke.17.gmail; Fri, 30 Mar 2018 12:27:21 -0700 (PDT) X-Received: by 10.31.63.19 with SMTP id m19mr27425vka.5.1522438041011; Fri, 30 Mar 2018 12:27:21 -0700 (PDT) In-Reply-To: X-Original-Sender: ben.craig@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:37580 Archived-At: ------=_Part_6875_1074325237.1522438040466 Content-Type: multipart/alternative; boundary="----=_Part_6876_214522182.1522438040466" ------=_Part_6876_214522182.1522438040466 Content-Type: text/plain; charset="UTF-8" On Thursday, March 29, 2018 at 8:59:53 AM UTC-5, Kevin Fitch wrote: > > > > On Wednesday, March 28, 2018 at 5:31:48 PM UTC-4, Ben Craig wrote: >> >> Implementations that are targeted at embedded platforms that are fine >> with allocations, fine with exceptions or termination semantics, but not >> fine with floating point. >> > To clarify, was that statement meant to be a question? Perhaps you meant > to say: Do there exist ... And, I would say, emphatically, there are > applications using implementations of the STL targeted at embedded > platforms where that is true. Most often I see applications that are fine > with allocations (with a few restrictions), but not fine with exceptions or > floating point. They key is that implementations targeted at embedded > platforms need to deal with applications that are (or are not) fine with > each of those (and many other things) independently. You can (with a little > effort) use all the features of the STL without using exceptions (e.g. > using operator[] instead of "at" to access members of a vector). You can > use allocators to deal with restrictions on allocation on the platform... > The point of that statement was more to point out that this is a very niche use case. Embedded and exceptionless overlap quite a bit. Embedded with a heap is a smaller audience. Embedded with a heap that doesn't use floating point is even smaller. I typically see the heap getting tossed out before floating point, not because of size, but because of the desire to avoid fragmentation when running for long periods of time. I agree that floating point use in unordered_map is a problem. If I had been doing standards work back when the unordered containers were being proposed, I would be against floating point in those places. I feel that, for the most part, the damage is done though. Adding more interfaces doesn't fix the need for implemenations to use floating point under the hood. If the floating point usage were just at the load_factor calls, then extra interfaces could fix things (like with at() and op[]). However, uses of the floating point values typically extends to any of the growing operations. Implementations could provide a configuration switch to avoid floating point, but I doubt they could make that the default. Each new configuration switch is extra testing burden that needs to be justified with enough users. If I were the maintainer of those libraries, I would need a lot of convincing that this is a common and serious enough problem to justify adding a configuration switch for it. -- 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/5001768e-3ea3-4c97-9867-43c5eb56e4ed%40isocpp.org. ------=_Part_6876_214522182.1522438040466 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thursday, March 29, 2018 at 8:59:53 AM UTC-5, Kevin= Fitch wrote:
=

On Wednesday, March 28, 2018 at 5:31:48 PM UTC-4, Ben Craig wrote:<= blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border= -left:1px #ccc solid;padding-left:1ex">
Implementations tha= t are targeted at embedded platforms that are fine with allocations, fine w= ith exceptions or termination semantics, but not fine with floating point.<= /div>
To clarify, was that statement meant to be a questio= n? Perhaps you meant to say: Do there exist ... And, I would say, emphatica= lly, there are applications using implementations of the STL targeted at em= bedded platforms where that is true. Most often I see applications that are= fine with allocations (with a few restrictions), but not fine with excepti= ons or floating point. They key is that implementations targeted at embedde= d platforms need to deal with applications that are (or are not) fine with = each of those (and many other things) independently. You can (with a little= effort) use all the features of the STL without using exceptions (e.g. usi= ng operator[] instead of "at" to access members of a vector). You= can use allocators to deal with restrictions on allocation on the platform= ....

The point of that stat= ement was more to point out that this is a very niche use case.=C2=A0 Embed= ded and exceptionless overlap quite a bit.=C2=A0 Embedded with a heap is a = smaller audience.=C2=A0 Embedded with a heap that doesn't use floating = point is even smaller.=C2=A0 I typically see the heap getting tossed out be= fore floating point, not because of size, but because of the desire to avoi= d fragmentation when running for long periods of time.

=
I agree that floating point use in unordered_map is a problem.=C2=A0 I= f I had been doing standards work back when the unordered containers were b= eing proposed, I would be against floating point in those places.=C2=A0 I f= eel that, for the most part, the damage is done though.=C2=A0 Adding more i= nterfaces doesn't fix the need for implemenations to use floating point= under the hood.=C2=A0 If the floating point usage were just at the load_fa= ctor calls, then extra interfaces could fix things (like with at() and op[]= ).=C2=A0 However, uses of the floating point values typically extends to an= y of the growing operations.=C2=A0 Implementations could provide a configur= ation switch to avoid floating point, but I doubt they could make that the = default.=C2=A0 Each new configuration switch is extra testing burden that n= eeds to be justified with enough users.=C2=A0 If I were the maintainer of t= hose libraries, I would need a lot of convincing that this is a common and = serious enough problem to justify adding a configuration switch for it.

--
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/5001768e-3ea3-4c97-9867-43c5eb56e4ed= %40isocpp.org.
------=_Part_6876_214522182.1522438040466-- ------=_Part_6875_1074325237.1522438040466-- .