From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89273 invoked by alias); 10 Aug 2016 17:03:44 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 89250 invoked by uid 89); 10 Aug 2016 17:03:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*M:online, differ, H*r:sk:mailout, HX-HELO:sk:mailout X-HELO: mailout05.t-online.de Received: from mailout05.t-online.de (HELO mailout05.t-online.de) (194.25.134.82) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 10 Aug 2016 17:03:42 +0000 Received: from fwd33.aul.t-online.de (fwd33.aul.t-online.de [172.20.27.144]) by mailout05.t-online.de (Postfix) with SMTP id D88C942349DC; Wed, 10 Aug 2016 19:03:36 +0200 (CEST) Received: from [192.168.0.16] (rCo0M4ZXohQItdPS-qGs2g2CLX49W3DQPtADdT6an0dqcRzPqp8t1oyqm6e4YzfZIr@[115.165.93.200]) by fwd33.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1bXWuk-1R8JtI0; Wed, 10 Aug 2016 19:03:34 +0200 Message-ID: <1470848609.639.405.camel@t-online.de> Subject: Re: protected alloca class for malloc fallback From: Oleg Endo To: Trevor Saunders Cc: Jeff Law , Richard Biener , Aldy Hernandez , Martin Sebor , gcc-patches Date: Wed, 10 Aug 2016 17:03:00 -0000 In-Reply-To: <20160809174139.GA18239@ball> References: <57A3F57F.3050509@gmail.com> <57A4A5E8.90205@redhat.com> <1470420954.639.64.camel@t-online.de> <44EE0FB0-A8B9-43F9-BF58-C4D7D27DA944@gmail.com> <57A5B8BE.2000004@redhat.com> <941D179C-146F-4004-BECB-9FB066DDCC8D@gmail.com> <21bcbebe-28a8-58a7-68e8-af9abcb03dce@redhat.com> <20160808173939.GA13790@ball> <1470742429.639.196.camel@t-online.de> <20160809174139.GA18239@ball> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00857.txt.bz2 On Tue, 2016-08-09 at 13:41 -0400, Trevor Saunders wrote: > If what you want is the ability to put the buffer on the stack > instead of the heap then I think a stack_string class that > interoperates with your string class is the thing you want. I'd avoid a separate stack_string class. Instead use a linear allocator with storage allocated on the stack, e.g.: typedef std::basic_string, linear_allocator my_tmp_string; void bleh (int foo) { linear_allocator buffer (alloca (1024), 1024); tmp_string aaa (buffer); aaa += "test"; aaa += "moon"; ... // what happens when "buffer" runs out of space? // throw? switch to heap alloc? ... } > > I don't really see anything wrong with a string class being a really > fancy smart pointer that has a bunch of useful string stuff on it. That's what std::string basically is? > As for operator == I'd be fairly ok with that, other than it hiding > a O(N) operation in ==. Yes, it makes it more difficult to carry out algorithm complexity analysis using grep... > Regretably necessary sure, but I'm not sure its funny. Hence the quotes. > The first big problem with using the stl is that the subset available > in C++98 isn't that great, you could maybe hack up libstdc++ so that > you can use newer types just without the bits that use newer language > features, but that would take some work. Or just wait until people have agreed to switch to C++11 or C++14. I don't think in practice anybody uses an C++11-incapable GCC to build a newer GCC these days. > The other big problem is that the stl is often too general, and tries > to be too simple. std::string is actually a good example of both of > those problems. There's really no reason it should use size_t > instead of uint32_t for the string length / capacity. Yes, some of the things in the STL are collections of compromises for general-purpose usage. If you're doing something extra fancy, most likely you can outperform the generic STL implementation. But very often it's actually not needed. > It would also be a lot better if it had separate types for strings > where you want an internal buffer or don't. Using custom allocators is one way. For example ... template struct linear_allocator_with_buffer; template using stack_string = std::basic_string, linear_allocator_with_buffer>; But then ... stack_string<32> a = "a"; stack_string<64> b = "b"; b += a; ... will not work because they are different types. One drawback of using custom allocators for that kind of thing is being unable to pass the above stack_string to a function that takes a "const std::string&" because they differ in template parameters. But that's where std::string_view comes in. Cheers, Oleg