220 27030 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal - non allocating std::function Date: Thu, 14 Jul 2016 21:30:17 -0700 (PDT) Lines: 289 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1381_1154964299.1468557017645" X-Trace: ger.gmane.org 1468557031 29689 80.91.229.3 (15 Jul 2016 04:30:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Jul 2016 04:30:31 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBW6NUG6AKGQET245RTI@isocpp.org Fri Jul 15 06:30:31 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f200.google.com ([209.85.161.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bNulZ-0007UX-Gk for gclcip-std-proposals@m.gmane.org; Fri, 15 Jul 2016 06:30:21 +0200 Original-Received: by mail-yw0-f200.google.com with SMTP id y188sf189586753ywf.3 for ; Thu, 14 Jul 2016 21:30:21 -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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=OQUmU0S3TIdcSkgoq8b60TE1RKUnhNTq189bQ/yWFk4=; b=HsFtgkrN89FD3ngHk6RiInRg6SKyEf31eLRYEOopiT6CPd/YitbHFZgGBz+AvNGxET hAgGchvZiP8tfaCkJEipJLMIu7smjLJYTxviLsU0hehw1pQUOsQLyLPvP1+iruFNaO5q 5AMabypFYzP0UJIUeCaeaGNnRlGKHpKPgIif8Ep6o96skfQWGZI/uz9Ft+P/rdEJSkO1 rtDSFcBiYb/TG7Gyu011FDbyPHrsDL75mOHhLDYLr4ChCsfzqqovUC+fnpLer+HDGnAC dN1cVOAeE/wN2yrKysCH9uwx/6xDxrGKKb2bPYDWCfe/OpQx5hcsAY5tZqtagbWFWzU8 S4Ew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=OQUmU0S3TIdcSkgoq8b60TE1RKUnhNTq189bQ/yWFk4=; b=EMiRAXy/LP954VX5cOIK7qqHZn6xkUp6MzHhx9d8Zv7649PWHknCn3drdxw+efin7D L/qXnMzD4mklUEF0c4OWZ+igtuaFt6HpYKS4yrQj2njI/NoXs3uR6dNlUBa/tMQ1EC9M Hb5Ze/oJbKVq29IQBuFMVqA8q/NN0MQv6HznyaHwQWDcMjat6Js5TeA9dMgHHMXoynre jlBQFEK9F2go/Fh0NqbkVDClcPZ/AyL3NRF9NKMZ59iSUF0wdss5Y+BxbaawPQxRo3mH J9I6Y4JOj3ellH+33iBbeGCJALpTCj3i+mx+86sqotMwg0JI6Dj5GMZwdIhYa9wzGifc /pRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=OQUmU0S3TIdcSkgoq8b60TE1RKUnhNTq189bQ/yWFk4=; b=JyFN+hdvFZEopstoYXaQA3d5u+EKIjybsHULHMnIJRXyT/I6WXTGO/nflxdxAlvfI9 sNHojGBXVi5qaTgH3ZLBUSQLybXQO19OwXt2qCJa0fpxC+MYvjpSg+xgSP/nBN3uVfXa mCh6f7Hly6fMIj7101fPwoC/zK0+XYXI0KFbDax/F7oTGDosct5ffv4utgpdEmq2KZLa Nbe/zPXo/ZGpw/LAmEXfEzd568j0dctqDEtQn3yELK26NDafJDJ0vM2EDLmpsW8yIsOk 3JYVYbB6JHTzxfSSTcjoSQJYwoGCqe7IQj1+a6Dm3kbRtlnV4Tb8xBkc0ZyFu1+M4OG4 so/Q== X-Gm-Message-State: ALyK8tIbq6b4Lsk/Xw6vK7Vje+bddmyPnC9HRoXJPTH4NKTDN9YyomgUkqINPn9WYNGAYg== X-Received: by 10.237.36.145 with SMTP id t17mr14149076qtc.10.1468557020319; Thu, 14 Jul 2016 21:30:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.18.224 with SMTP id 93ls1194023ios.19.gmail; Thu, 14 Jul 2016 21:30:19 -0700 (PDT) X-Received: by 10.36.3.85 with SMTP id e82mr1495309ite.1.1468557019000; Thu, 14 Jul 2016 21:30:19 -0700 (PDT) In-Reply-To: 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:27030 Archived-At: ------=_Part_1381_1154964299.1468557017645 Content-Type: multipart/alternative; boundary="----=_Part_1382_1518302802.1468557017646" ------=_Part_1382_1518302802.1468557017646 Content-Type: text/plain; charset=UTF-8 On Thursday, July 14, 2016 at 11:19:24 PM UTC-4, Nevin ":-)" Liber wrote: > > On 14 July 2016 at 21:57, Nicol Bolas wrote: > >> It's not a question of "should the standard library care about >> high-performance code". It's a question of "how many high-performance >> corner cases should be in the standard library?" You can keep adding stuff >> to cover corner cases ad infinitum. At some point, you have to draw a line. >> > > Why? > > I remember back in '12 when the big complaint was that the C++ Standard > Library was too small. I must have been sleeping when that got solved. > I remember back in '12 when I completely disagreed with Herb Sutter's statement to that effect. So I'm not really sure what point you're trying to make. I've always felt that C++'s small standard library was a good thing, not a problem to be "solved". My personal criterion are: > > - Things that people keep inventing in multiple places > - Things that are hard to write correctly > > Remember: we are talking about a type which, in the very next section, you >> admit "will only be used in specialized cases". To me, the standard library >> should be for tools that are of general use. >> > > That's you. And no one is forcing you to use the other stuff. > Generally speaking, people do not code in a vacuum. How other people code affects your code, just as your code affects the code of others. Why? Because you may need to share that code. And thus, your code needs to be able to interoperate with theirs. If someone elses code allocates memory, but your project doesn't allow unauthorized allocations, then you can't use their code. If their strings are UTF-16s, then you're going to have to convert your UTF-8s into UTF-16 if you want to use it. If you don't like `enum class`es, but someone used an `enum class` in the interface to their library, you're going to have to make your peace with that language feature in order to use that library. If a library uses filesystem `path`s, but you use C-style file IO (because you like performance), you're going to have to write non-standard code in order to work with their system. And so forth. Some people do code in a vacuum, where the only code they talk to lives in their own world. And that's fine. But let's not ignore the fact that a lot of other people share code. And therefore, what code someone uses very much affects others. This is why standards are important. That's why `shared_ptr` is designed as the "do everything" smart pointer. It is the smart pointer that can work with *anything*. Despite its overhead compared to other possible implementations, it is the lingua franca smart pointer. The nice thing about the C++ standard library as it currently stands is that it usually has only one answer to every general problem (that it covers). Need a dynamic array? `vector`. Need a callback that can call anything? `function`. Need a reference-counted shared ownership object? `shared_ptr`. Need a way to communicate a value/exception between threads? `promise/future`. Etc. Every time the standard library tries to offer multiple ways to achieve the same result, they screw things up. Just look at iostreams vs. C-standard IO. C's IO is very fast and serviceable, but is horribly non-type-safe and doesn't interoperate with `filesystem`. Iostreams has filesystem interop (when the committee fixes that defect) and type-safety, but is very weak on performance when type safety isn't an issue. Neither one is good; there is only the one that is least painful. We had C-standard string-to-number functions, which were unsafe. So we tried to replace them with `stoX` and `to_string`, all of which are broken by the fact that they sue `std::string` directly, not even allowing you to use a string type with a different allocator. That attempt to replace C-standard string conversions went *so badly* that C++17 is going to replace the replacements with more string conversion functions. Converters that seem so terrified of the mistakes of the C++11 converters that they don't even use `string_view`, eschewing it for explicit `char*` ranges. Imagine how much cleaner the standard library could be if iostreams were just an adjacent TS, rather than a fully required part of the C++ standard. Imagine how much refactoring and improvement could have been done on that interface if backwards compatibility were not a requirement. That's why I like the idea of having a dedicated TS specifically for these >> types of things. I'd love to see a TS full of `small_vector`, >> `small_basic_string`, `inplace_function`, and so forth (but not >> `flat_set/map`. Those *need to be* in the standard library). Please >> don't look on TS's as some kind of ghetto for things that are not really >> standard. Yes, they really are standard, they really are supplied by >> compiler vendors, and they really are available. >> > > And people who work on them expect the stuff in them to go into the IS at > some point. > So... there is a genuine intent to adopt a 2D graphics rendering system into the C++ standard library at some point? Really? If you wish to change the focus of TSes, you need to come to meetings and > present your case. > > This actually brings up a small technical deficiency with the current >> proposal: no interop with `std::function`. Well, besides the obvious fact >> that `inplace_function` is a callable and you could therefore shove one >> into a `function` and vice-versa. >> > > Why? What are the actual use cases for that? > The use case of "someone used `std::function` in an interface, but I use `std::inplace_function` internally, and I need to talk to their code." Right now, `std::function` is how lots of C++ code takes callbacks, and for good reason. But if I've wrapped some function in an `inplace_function`, I still need to be able to talk to them. It's basically the same thinking that allows a `unique_ptr` to be moved into a `shared_ptr`. -- 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/d14a6548-9ddf-40c2-adc4-a046aff2d1e2%40isocpp.org. ------=_Part_1382_1518302802.1468557017646 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thursday, July 14, 2016 at 11:19:24 PM UTC-4, Nevin &qu= ot;:-)" Liber wrote:
On 14 July 2016 at 21:57, Nicol Bolas <jmck...@gmail.com> wrote:<= br>
It's not a question of "should the standard library care about=20 high-performance code". It's a question of "how many high-per= formance=20 corner cases should be in the standard library?" You can keep adding= =20 stuff to cover corner cases ad infinitum. At some point, you have to=20 draw a line.

Why?

I remember back in '12 when the big complaint was that the C++ Standard= =20 Library was too small.=C2=A0 I must have been sleeping when that got solved= ..

I remember back in '12 w= hen I completely disagreed with Herb Sutter's statement to that effect.= So I'm not really sure what point you're trying to make. I've = always felt that C++'s small standard library was a good thing, not a p= roblem to be "solved".

My personal criterion are:
  • Things that people keep = inventing in multiple places
  • Things that are hard to write correctl= y=C2=A0
=
Remember: we are talking about a type which, in the very next section, you admit=20 "will only be used in specialized cases". To me, the standard lib= rary=20 should be for tools that are of general use.

That's you.=C2=A0 And no one is forcing you to use th= e other stuff.

Generally speak= ing, people do not code in a vacuum. How other people code affects your cod= e, just as your code affects the code of others. Why?

Because you ma= y need to share that code. And thus, your code needs to be able to interope= rate with theirs. If someone elses code allocates memory, but your project = doesn't allow unauthorized allocations, then you can't use their co= de. If their strings are UTF-16s, then you're going to have to convert = your UTF-8s into UTF-16 if you want to use it. If you don't like `enum = class`es, but someone used an `enum class` in the interface to their librar= y, you're going to have to make your peace with that language feature i= n order to use that library. If a library uses filesystem `path`s, but you = use C-style file IO (because you like performance), you're going to hav= e to write non-standard code in order to work with their system.

And= so forth.

Some people do code in a vacuum, where the only code they= talk to lives in their own world. And that's fine. But let's not i= gnore the fact that a lot of other people share code. And therefore, what c= ode someone uses very much affects others.

This is why standards are= important. That's why `shared_ptr` is designed as the "do everyth= ing" smart pointer. It is the smart pointer that can work with anyt= hing. Despite its overhead compared to other possible implementations, = it is the lingua franca smart pointer.

The nice thing about the C++ = standard library as it currently stands is=20 that it usually has only one answer to every general problem (that it cover= s). Need a=20 dynamic array? `vector`. Need a callback that can call anything?=20 `function`. Need a reference-counted shared ownership object?=20 `shared_ptr`. Need a way to communicate a value/exception between=20 threads? `promise/future`. Etc.

Every time the standard library trie= s to offer multiple ways to achieve the same result, they screw things up. = Just look at iostreams vs. C-standard IO. C's IO is very fast and servi= ceable, but is horribly non-type-safe and doesn't interoperate with `fi= lesystem`. Iostreams has filesystem interop (when the committee fixes that = defect) and type-safety, but is very weak on performance when type safety i= sn't an issue. Neither one is good; there is only the one that is least= painful.

We had C-standard string-to-number functions, which were u= nsafe. So we tried to replace them with `stoX` and `to_string`, all of whic= h are broken by the fact that they sue `std::string` directly, not even all= owing you to use a string type with a different allocator. That attempt to = replace C-standard string conversions went so badly that C++17 is go= ing to replace the replacements with more string conversion functions. Conv= erters that seem so terrified of the mistakes of the C++11 converters that = they don't even use `string_view`, eschewing it for explicit `char*` ra= nges.

Imagine how much cleaner the standard library could be if iost= reams were just an adjacent TS, rather than a fully required part of the C+= + standard. Imagine how much refactoring and improvement could have been do= ne on that interface if backwards compatibility were not a requirement.
=
That's why I like the idea of having a dedicated TS specifically for these=20 types of things. I'd love to see a TS full of `small_vector`,=20 `small_basic_string`, `inplace_function`, and so forth (but not=20 `flat_set/map`. Those need to be in the standard library). Please don't look on TS's as some kind of ghetto for things that are not= =20 really standard. Yes, they really are standard, they really are supplied by compiler vendors, and they really are available.

And people who work on them expect the stuff in them to go into the IS at=20 some point.

So... there is a g= enuine intent to adopt a 2D graphics rendering system into the C++ standard= library at some point? Really?

If you= wish to change the focus of TSes, you need to come=20 to meetings and present your case.
=C2=A0
This actually brings up a small technical deficiency with the current=20 proposal: no interop with `std::function`. Well, besides the obvious=20 fact that `inplace_function` is a callable and you could therefore shove one into a `function` and vice-versa.
Why?=C2=A0 What are the actual use cases for that?
<= /div>

The use case of "someone used `std::f= unction` in an interface, but I use `std::inplace_function` internally, and= I need to talk to their code." Right now, `std::function` is how lots= of C++ code takes callbacks, and for good reason. But if I've wrapped = some function in an `inplace_function`, I still need to be able to talk to = them.

It's basically the same thinking that allows a `unique_ptr= ` to be moved into a `shared_ptr`.

--
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/d14a6548-9ddf-40c2-adc4-a046aff2d1e2= %40isocpp.org.
------=_Part_1382_1518302802.1468557017646-- ------=_Part_1381_1154964299.1468557017645-- .