220 18476 <5010db84-4ed4-4d52-a9da-10b8bde377c6@isocpp.org> article Path: news.gmane.org!not-for-mail From: Sean Middleditch Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Exposing string small string optimization size to avoid heap allocation. Date: Sat, 6 Jun 2015 23:21:50 -0700 (PDT) Lines: 164 Approved: news@gmane.org Message-ID: <5010db84-4ed4-4d52-a9da-10b8bde377c6@isocpp.org> References: <19736033-58d4-441d-ae73-19804f8ef575@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_116_2105083771.1433658110271" X-Trace: ger.gmane.org 1433658119 17430 80.91.229.3 (7 Jun 2015 06:21:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Jun 2015 06:21:59 +0000 (UTC) Cc: german.diago@hubblehome.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCDODCNR2QPRB76FZ6VQKGQEGBB5WGQ@isocpp.org Sun Jun 07 08:21:54 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f200.google.com ([209.85.214.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z1Txw-000559-Sm for gclcip-std-proposals@m.gmane.org; Sun, 07 Jun 2015 08:21:53 +0200 Original-Received: by obbgp2 with SMTP id gp2sf120161446obb.1 for ; Sat, 06 Jun 2015 23:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=MHcvFsJiJqxoQ/7sO6nCfRtqNIY7JTFvivy0qeNRsRs=; b=ZG33AfFX6M+ztyQlC1bxTUt249ZDky20yM3gdpGOHqCUSFFEWWmmMyT2VRgGo9tyIP jUMboHXa3yeAuHeaKIKuoS+o2Paavk8R4/j1bV/6egertUN2K7ZTkQSvRmzjwIFEYZRH +owNrdA5je4db2kzUadhtRR3dzqf8JH6bHHVwayQ6nBkhYJXcGqtS/ecZsHgKpcsGTlt ABk0vFXrO10BtzPuWu7ElKFNcotjHvbbcjd+nkrTgk4/NVASUs9eXBIPmvzn3yKA+Gxm lV9tqkh+EG15M7sEDWC5nYDr4okHyYr4DuF4TBhiWLNOWpHqvnudHQ15reuM0RZvicw/ Y1qw== 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:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=MHcvFsJiJqxoQ/7sO6nCfRtqNIY7JTFvivy0qeNRsRs=; b=D1MnCpjdgKaoC+GElt5HmezZeURhLMHu75TXUvJsy4x+72k18lTtECGnBlH2icIFVE 8Z1OVpjRseRG80RnHop+Df0v+sDt9/LC8762LdO7BcFSCVF0ainVY2GtpRRLOd8olWJN 2RnPcz/v5FdVle3Fa6WU8mbKQeXL/mTGNoVuUT7IKgLvw3fFz5ZddzygvmAyGX/K3PH5 pm4C7tDIVCf+hKN4Xv+IFqES4HUyl2v19NTP7pIHeHLPHeph2/qCKSh+sTefRJpu6qkS 002nn8o0vDToEzQt6rvACJDITPzY12LQLSSAopZVkzMhC/FQjE34IPa0i+km/cqPPzLX SLSg== X-Gm-Message-State: ALoCoQlZs5OYm/4Ps6tOa+rEfg8xmMQfWyV/pJXItbiVcME9TjQaXZayYpFmsbF56Ime46psEczA X-Received: by 10.182.106.12 with SMTP id gq12mr15137129obb.6.1433658111715; Sat, 06 Jun 2015 23:21:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.50.240 with SMTP id f16ls858112igo.31.gmail; Sat, 06 Jun 2015 23:21:51 -0700 (PDT) X-Received: by 10.50.64.179 with SMTP id p19mr91652igs.13.1433658111127; Sat, 06 Jun 2015 23:21:51 -0700 (PDT) In-Reply-To: X-Original-Sender: Sean.Middleditch@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:18476 Archived-At: ------=_Part_116_2105083771.1433658110271 Content-Type: multipart/alternative; boundary="----=_Part_117_349854872.1433658110271" ------=_Part_117_349854872.1433658110271 Content-Type: text/plain; charset=UTF-8 (sorry for the self-reply) An additional important point is interoperability. Just writing your own string class is very problematic, even when necessary. If you need to work around std::string for your environment then you also very likely need to avoid libraries that use std::string. Which is most of them; that's the whole point of having a standard string type. string_view will lessen the problems here to a degree, but certainly not eliminate them. This is something I've personally run into a lot with games, where some otherwise very handy library ends up depending on a verboten STL type, or Boost, or one of the oft verboten C++ features, or ends up working around the same problems we have by implementing their own non-standard framework library (and then we'd have to get all these libraries interoperating with us and each other), and so we can't use the library and have to reimplement it from scratch as well as the standard types. It's a domino effect of wasted time and money. On Saturday, June 6, 2015 at 11:08:20 PM UTC-7, Sean Middleditch wrote: > > The real issue with SSO, in my experience, is a bit more complicated. > > What if the std::string implementation doesn't support SSO at the string > lengths you need? Detecting it would at best just let you add a > static_assert telling users that the implementation is unusable. It doesn't > actually fix the problem with the implementation; it just makes it easier > to identify. And once you've rewritten std::string for one implementation, > you might as well just use your version on every implementation so you get > reliable behavior no matter where you go. > > If the standard didn't rely on "QoI" here and just set something users can > rely on, we'd all be in a much better place. Just like how graphics APIs > provide implementation-provided upper bounds for many values but mandate a > reliable cross-implementation lower-bound, which is essential to writing > graphics programs that actually work across multiple > implementations/drivers. > > An even more general solution would allow the user to specify a traits > type that defined that minimal bound. When we write our own STL > replacements we typically don't bother with such traits, since we can just > design to our specific needs, but the standard library probably wants to be > a bit more widely applicable. > > On Friday, June 5, 2015 at 10:14:16 PM UTC-7, german...@hubblehome.com > wrote: >> >> Hello everyone, >> >> I would like to know if there would be interest in a proposal for >> detecting when a string allocates in the heap. >> >> The rationale for this is that there are environments in which heap >> allocations should be forbidden, >> but use of short strings can still be made, with the convenience of >> string functions. >> Embedded environments are such an example: >> >> >> A static member function (or free?) could be provided. Something like: >> >> //Pseudo-C++, no basic_string here to go straight to the question >> class string { >> public: >> static std::size_t max_stack_allocated_size(); >> static bool needs_dynamic_allocation(std::size_t sz); >> }; >> >> Any interest in this? >> >> >> -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_117_349854872.1433658110271 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(sorry for the self-reply)

An additiona= l important point is interoperability. Just writing your own string class i= s very problematic, even when necessary. If you need to work around std::st= ring for your environment then you also very likely need to avoid libraries= that use std::string. Which is most of them; that's the whole point of hav= ing a standard string type. string_view will lessen the problems here to a = degree, but certainly not eliminate them.

This is = something I've personally run into a lot with games, where some otherwise v= ery handy library ends up depending on a verboten STL type, or Boost, or on= e of the oft verboten C++ features, or ends up working around the same prob= lems we have by implementing their own non-standard framework library (and = then we'd have to get all these libraries interoperating with us and each o= ther), and so we can't use the library and have to reimplement it from scra= tch as well as the standard types.

It's a domino e= ffect of wasted time and money.

On Saturday, June 6, 2015 at = 11:08:20 PM UTC-7, Sean Middleditch wrote:
The real issue with SSO, in my experience, is = a bit more complicated.

What if the std::string implemen= tation doesn't support SSO at the string lengths you need? Detecting it wou= ld at best just let you add a static_assert telling users that the implemen= tation is unusable. It doesn't actually fix the problem with the implementa= tion; it just makes it easier to identify. And once you've rewritten std::s= tring for one implementation, you might as well just use your version on ev= ery implementation so you get reliable behavior no matter where you go.

If the standard didn't rely on "QoI" here and just se= t something users can rely on, we'd all be in a much better place. Just lik= e how graphics APIs provide implementation-provided upper bounds for many v= alues but mandate a reliable cross-implementation lower-bound, which is ess= ential to writing graphics programs that actually work across multiple impl= ementations/drivers.

An even more general solution= would allow the user to specify a traits type that defined that minimal bo= und. When we write our own STL replacements we typically don't bother with = such traits, since we can just design to our specific needs, but the standa= rd library probably wants to be a bit more widely applicable.
On Friday, June 5, 2015 at 10:14:16 PM UTC-7, german...@hubb= lehome.com wrote:
Hello everyone,

I would like to know if there would b= e interest in a proposal for detecting when a string allocates in the heap.=

The rationale for this is that there are environm= ents in which heap allocations should be forbidden,
but use of sh= ort strings can still be made, with the convenience of string functions.&nb= sp;
Embedded environments are such an example:


A static member function (or free?) could be provided= .. Something like:

//Pseudo-C++, no basic_string he= re to go straight to the question
class string {
 =  public:
       static std::size_t max_= stack_allocated_size();
       static bool ne= eds_dynamic_allocation(std::size_t sz);
};

Any interest in this?


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_117_349854872.1433658110271-- ------=_Part_116_2105083771.1433658110271-- .