From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84089 invoked by alias); 10 Aug 2016 10:04:25 -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 84077 invoked by uid 89); 10 Aug 2016 10:04:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f42.google.com Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 10 Aug 2016 10:04:22 +0000 Received: by mail-wm0-f42.google.com with SMTP id f65so80896822wmi.0 for ; Wed, 10 Aug 2016 03:04:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=McRHLKYyh9NoSbH4beHyWAS/LXmG2TnMl7VuFsIYOnU=; b=lC6XVT3srjZN6GHRQFwSmPov/3004YueKim8qarSGZXnAuTJO2BoRC7fSMvtkjsuCg AgO7fuJ48h6KflcmNhAy0I1E3tsvdUW87qQ7ivFpmCkemyc7dbk+sM9Ihz+DjxqjJAkd SboxBaMSn9H0NIg0uKtADLKjGFN5YUEBy1zMRzlxMdWqGy8CUvAxb2nnKLWTXxQ7PlxV ijcxvOz7DcAqdXfTmciwllBf4X4QET10k74yPuNuEKr+KsditskjrsztjT96vzqgseST u67wHSWRVvZ4CQQbJY1GHuaR36hwBUOptGKTaojZazaBdFNLAwTA+QjqBwmQhdagTKvF YoEQ== X-Gm-Message-State: AEkoouu41nHs4ig2cVOLEJSEgrpj/SQhhD41CgOBGXmi+dCYDvI4RFd4fCyVa22hBBSNwxiys2T2asA3GBgGJw== X-Received: by 10.28.209.14 with SMTP id i14mr2260376wmg.35.1470823459645; Wed, 10 Aug 2016 03:04:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.137.202 with HTTP; Wed, 10 Aug 2016 03:04:18 -0700 (PDT) In-Reply-To: <57A9D7E5.6090208@redhat.com> References: <57A32741.7010003@redhat.com> <57A3F57F.3050509@gmail.com> <57A4A5E8.90205@redhat.com> <57A9D7E5.6090208@redhat.com> From: Richard Biener Date: Wed, 10 Aug 2016 10:04:00 -0000 Message-ID: Subject: Re: protected alloca class for malloc fallback To: Aldy Hernandez Cc: Martin Sebor , gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00791.txt.bz2 On Tue, Aug 9, 2016 at 3:17 PM, Aldy Hernandez wrote: > On 08/05/2016 01:55 PM, Richard Biener wrote: > > Hi Richard. > >> Please don't use std::string. For string building you can use obstacks. > > > Alright let's talk details then so I can write things up in a way you > approve of. > > Take for instance simple uses like all the tree_*check_failed routines, > which I thought were great candidates for std::string-- they're going to be > outputted to the screen or disk which is clearly many times more expensive > than the malloc or overhead of std::string: > > length += strlen ("expected "); > buffer = tmp = (char *) alloca (length); > length = 0; > while ((code = (enum tree_code) va_arg (args, int))) > { > const char *prefix = length ? " or " : "expected "; > > strcpy (tmp + length, prefix); > length += strlen (prefix); > strcpy (tmp + length, get_tree_code_name (code)); > length += strlen (get_tree_code_name (code)); > } > > Do you suggest using obstacks here, or did you have something else in mind? Why would you want to get rid of the alloca here? > How about if it's something like the above but there are multiple exit > points from the function. I mean, we still need to call obstack_free() on > all exit points, which is what I wanted to avoid for something as simple as > building a throw-away string. But you'll end up in internal_error ("tree check: %s, have %s in %s, at %s:%d", buffer, get_tree_code_name (TREE_CODE (node)), function, trim_filename (file), line); where you have an interface using C strings again. It's not that the standard library is bad per-se, it's just using a tool that doesn't fit its uses. This makes the code a messy mix of two concepts which is what I object to. Yes, the above example may have premature optimization applied. Is that a reason to re-write it using std::string? No. Is it a reason to rewrite it using obstracks? No. Just leave it alone. Richard. > > Aldy