220 7808 <12c2ccb1-3183-423a-a706-0e5134a284a0@isocpp.org> article Path: news.gmane.org!not-for-mail From: amluto@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Add basic_string::resize_uninitialized (or a similar mechanism) Date: Mon, 18 Nov 2013 12:41:59 -0800 (PST) Lines: 76 Approved: news@gmane.org Message-ID: <12c2ccb1-3183-423a-a706-0e5134a284a0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_599_14216815.1384807319510" X-Trace: ger.gmane.org 1384807318 22586 80.91.229.3 (18 Nov 2013 20:41:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Nov 2013 20:41:58 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDA4RGWPT4GRBGPXVGKAKGQENKZDAAQ@isocpp.org Mon Nov 18 21:42:04 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pb0-f70.google.com ([209.85.160.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ViVdz-00010q-HW for gclcip-std-proposals@m.gmane.org; Mon, 18 Nov 2013 21:42:03 +0100 Original-Received: by mail-pb0-f70.google.com with SMTP id rq2sf1462045pbb.9 for ; Mon, 18 Nov 2013 12:42:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe:content-type; bh=aLyJfwScJiRjqMut00MPvdq6hBd+rtSY4V77bCoJ8Tc=; b=oRgCD56JQUbbFrkMiqg7Ipw8may8Fuox8M6sftkfOjsUBd6k1WEAJKasOyZweJe8WK jUhL398ZJQ18OQlWLgfAwZKDxbjeZf0Cslea9XKGLbdgJ1XAhe1O2rIQtQ/0AawIU+kB 6iOjyK38UMs9+lFycH+yn+SLez8d9ViY6av1filENf2ErOMW8wtDTit29QP4D7STQfW8 qDf9OJHPmCio6EO+W3e0X6LXD0SJMj6Dg2eR91OTfTSr0tjyYbAdmz7Mi0M/WQwg5Zx4 YMVWqFAPbrhlFZomoVJI2GXDZWXR2EOMp/26m09n0rhKEm60Vx/st7IlpSLnljTJfFLN ew0w== 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:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=aLyJfwScJiRjqMut00MPvdq6hBd+rtSY4V77bCoJ8Tc=; b=NHZxtgnTN0wC7Sq3TZs2p1AfX2+EEsov4hJFMm4vlsLlc4G+0XHRqHJBiTTK+RzVg3 PnRyEHQmLoWivUNJmwGw/Rf/HbUKq4mN91sERiSQbqKizMJRLtjI0cauKMftMTSh0BKZ 209D+g1ebBVsPIaldYMw1vvWCaLk4PUdoOfuXF+6719oUTqQm4RBxEXr/6370Qb1t0kz 00VPu/KoTKDyPrhLh9htsdTeM+ixBV90JIElGxzsCNo885yP7LhuzU25ujrk41lp3ww0 NYR1FzBaJzxZGeouo7NUDNaPV42zL47pDIP6CcPjrBYe/n4F3UFav0s4pXtZjw0adOWH aBPA== X-Gm-Message-State: ALoCoQlSYBmxwwC3G1LRdxUesg0jvjVjAD6CRpBZmLQPDcTbu6GeLCcNw8xMR/ejBvR07a6tVw41 X-Received: by 10.66.168.198 with SMTP id zy6mr939301pab.46.1384807322363; Mon, 18 Nov 2013 12:42:02 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.66.229 with SMTP id i5ls2057665igt.10.gmail; Mon, 18 Nov 2013 12:42:00 -0800 (PST) X-Received: by 10.50.9.33 with SMTP id w1mr389748iga.12.1384807320812; Mon, 18 Nov 2013 12:42:00 -0800 (PST) X-Original-Sender: amluto@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:7808 Archived-At: ------=_Part_599_14216815.1384807319510 Content-Type: text/plain; charset=ISO-8859-1 There are many mechanisms around that create basic_string objects that contain some form of formatted data (e.g. ostringstream, to_string). Unfortunately, there is currently no way to obtain a basic_string of nonzero size and interesting contents without either composing the contents externally and copying or writing to the string twice. The former can be achieved by composing the contents of the string as an array or a sequence and using the basic_string constructors. The latter can be achieved by using resize() and operator[] to create a blank string and fill it in. For applications where a reasonable approximation of the final size of the string is known in advance (or where users are willing to over-allocate), it's tempting to try to optimize by resizing the string and composing in place. This wastes time because basic_string::resize() always fully initializes the string. If basic_string had a method like resize_uninitialized that changed the size of the underlying array but did *not* construct the elements (with similar semantics to declaring an uninitialized local variable of type char). This would only be allowed for sufficiently trivial character types. (std::vector has much the same issue.) Thoughts? -- --- 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_599_14216815.1384807319510 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There are many mechanisms around that create basic_string = objects that contain some form of formatted data (e.g. ostringstream, to_st= ring).  Unfortunately, there is currently no way to obtain a basic_str= ing of nonzero size and interesting contents without either composing the c= ontents externally and copying or writing to the string twice.

The f= ormer can be achieved by composing the contents of the string as an array o= r a sequence and using the basic_string constructors.  The latter can = be achieved by using resize() and operator[] to create a blank string and f= ill it in.

For applications where a reasonable approximation of the = final size of the string is known in advance (or where users are willing to= over-allocate), it's tempting to try to optimize by resizing the string an= d composing in place.  This wastes time because basic_string::resize()= always fully initializes the string.

If basic_string had a method l= ike resize_uninitialized that changed the size of the underlying array but = did *not* construct the elements (with similar semantics to declaring an un= initialized local variable of type char).  This would only be allowed = for sufficiently trivial character types.

(std::vector has much the = same issue.)

Thoughts?

--
 
---
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-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/<= /a>.
------=_Part_599_14216815.1384807319510-- .