220 2824 <91d78642-a52e-4c45-b02f-096c35306487@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Improvements for string literals Date: Wed, 13 Feb 2013 16:09:22 -0800 (PST) Lines: 285 Approved: news@gmane.org Message-ID: <91d78642-a52e-4c45-b02f-096c35306487@isocpp.org> References: <913f9603-aff2-4abf-a330-d4d0f8a2d1e0@isocpp.org> <5a76aa73-1940-4247-b40d-c7c1ba972246@isocpp.org> <41bc2377-7654-43f4-83f1-133edeca18d3@isocpp.org> <7ebf708e-87f3-4e68-9921-c80f862c63a4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_116_23604752.1360800562616" X-Trace: ger.gmane.org 1360800563 13034 80.91.229.3 (14 Feb 2013 00:09:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Feb 2013 00:09:23 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBM6W6CEAKGQECAO7ANI@isocpp.org Thu Feb 14 01:09:44 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f72.google.com ([209.85.219.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U5mOW-0001i2-3w for gclcip-std-proposals@m.gmane.org; Thu, 14 Feb 2013 01:09:44 +0100 Original-Received: by mail-oa0-f72.google.com with SMTP id j6sf9221127oag.11 for ; Wed, 13 Feb 2013 16:09:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:date:from:to:message-id :in-reply-to:references:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=Zm4os5TmST9/fV0FYxCI81kzgsv4htxHR/vOeKjrD6s=; b=GfHN53+FbTsFLJkOXheceZWGNdB50NegyZ4k3/hJ71YoDN5z74FeyHELMAw+Zts7Zz TgpMvpXaDurlsShwqsPTAvMQz9V77mI6mbQfASzjqEwoOdn+bS0jrpcN1Rywipsh4Ziq n3xQ4OJzhAiJW2QMct4KHN+TI2h2ppj1bbun8BTPrTSYISCT39WfADsrpsKctgZERsi9 XSbRS5wiIZuKGbf9fH/RwHMjwiy+dO8k3AhEgbglJU8TQ3EgtXuElh9tWl0VYIc2l2BG I9I2BAhu7Zqj7/2kfncLT/IGEsA29P0b6fI6VYQ1l/ogDMwA/yv/ADae6A6ccY2w5YST t6Wg== X-Received: by 10.182.167.66 with SMTP id zm2mr3868311obb.7.1360800564055; Wed, 13 Feb 2013 16:09:24 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.23.111 with SMTP id l15ls129273obf.12.gmail; Wed, 13 Feb 2013 16:09:22 -0800 (PST) X-Received: by 10.182.189.67 with SMTP id gg3mr24820obc.30.1360800562881; Wed, 13 Feb 2013 16:09:22 -0800 (PST) In-Reply-To: <7ebf708e-87f3-4e68-9921-c80f862c63a4@isocpp.org> X-Original-Sender: jmckesson@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:2824 Archived-At: ------=_Part_116_23604752.1360800562616 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, February 13, 2013 2:40:35 PM UTC-8, Nikolay Ivchenkov wrote: > > On Monday, February 11, 2013 3:01:41 PM UTC+4, Nicol Bolas wrote: >> >> It would be possible to improve classes for immutable strings if >>> parameters could be declared with 'static constexpr' and the overload >>> resolution could select appropriate function depending on whether the >>> argument is known to be a constexpr object with static storage duration: >>> >>> template >>> class basic_immutable_string >>> { >>> public: >>> template >>> basic_immutable_string(static constexpr CharT (&s)[N]); // #1 >>> basic_immutable_string(CharT const *s); // #2 >>> .... >>> }; >>> >>> using immutable_string = basic_immutable_string; >>> >>> template >>> void f(static constexpr char (&x)[N]) >>> { >>> static constexpr char a1[] = "text"; >>> static char a2[] = "text"; >>> auto &ra1 = a1; >>> >>> immutable_string s0 = x; // calls #1 >>> immutable_string s1 = a1; // calls #1 >>> immutable_string s2 = a2; // calls #2 >>> immutable_string s3 = ra1; // calls #2 >>> immutable_string s4 = "text"; // calls #1 >>> } >>> >>> >> Not quite: >> >> static constexpr char ar3[] = {'n', 'o', 't', ' ', 'l', 'i', 't', 'e', >> 'r', 'a', 'l'}; >> >> That would work just as well with your way. >> > > If we remove the constexpr specifier, then initialization > > immutable_string s = ar3; > > will not be well-defined, because ar3 is not a null-terminated string. In > the presence of constexpr the effect of such initialization could be > considered as undefined similarly. > Even if it were NULL-terminated, it wouldn't be a *string literal* anymore. Thus, you could not guarantee that it is a string literal. And therefore, you couldn't make certain assumptions about it. For example, this is well-defined C++ code: const char *GetLiteral() { const char *ar = "blah"; return ar; } This is not. const char *GetLiteral2() { const char ar[] = {'n', 'o', 't', ' ', 'l', 'i', 't', 'e', 'r', 'a', 'l', '\0'}; return ar; } String literals are required to be stored in permanent memory, effectively part of the executable. Arbitrary `const char*`'s are not. What I want is a type that, *in all cases*, is required to come only from actual literals. It's not just that the string is "immutable". It is important that the string come from a string literal as defined by the standard. Being able to create strings with "static constexpr" and whatnot is not the issue here. String literals are not the only source of `char*`s that can be "static constexpr"s. So that won't help. You're looking for a general class of immutable strings, which may be the result of various operations. I'm talking about real, honest-to-God string literals, as defined by the standard. Not the result of various constexpr computations or {} initializations or whatever. -- --- 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/?hl=en. ------=_Part_116_23604752.1360800562616 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wednesday, February 13, 2013 2:40:35 PM UTC-8, Nikolay Ivchenkov= wrote:
On Monday, February 11,= 2013 3:01:41 PM UTC+4, Nicol Bolas wrote:
It would be possible to= improve classes for immutable strings if parameters could be declared with= 'static constexpr' and the overload resolution could select appropriate fu= nction depending on whether the argument is known to be a constexpr object = with static storage duration:

    template <class = CharT>
        class basic_immutab= le_string
    {
    public:
 &n= bsp;      template <std::size_t N>
 =            basic_immutabl= e_string(static constexpr CharT (&s)[N]); // #1
   &n= bsp;    basic_immutable_string(CharT const *s); // #2
&nb= sp;       ....
    };
    using immutable_string =3D basic_immutable_string<c= har>;

    template <std::size_t N>
 =        void f(static constexpr char (&x)[= N])
    {
        s= tatic constexpr char a1[] =3D "text";
     &nbs= p;  static char a2[] =3D "text";
     &nbs= p;  auto &ra1 =3D a1;

      &= nbsp; immutable_string s0 =3D x; // calls #1
    &nb= sp;   immutable_string s1 =3D a1; // calls #1
  &nbs= p;     immutable_string s2 =3D a2; // calls #2
 = ;       immutable_string s3 =3D ra1; // calls= #2
        immutable_string s4 =3D "= text"; // calls #1
    }

<= br>Not quite:

static constexpr char ar3[] =3D {'n', 'o', = 't', ' ', 'l'<= span style=3D"color:#660">, 'i', 't', 'e', 'r', = 'a', 'l'};

That would = work just as well with your way.

If we remov= e the constexpr specifier, then initialization

    im= mutable_string s =3D ar3;

will not be well-defined, because ar3 is n= ot a null-terminated string. In the presence of constexpr the effect of suc= h initialization could be considered as undefined similarly.

Even if it were NULL-terminated, it wouldn't be a strin= g literal anymore. Thus, you could not guarantee that it is a string li= teral. And therefore, you couldn't make certain assumptions about it. For e= xample, this is well-defined C++ code:

const char *GetL= iteral()
<= span style=3D"color: #660;" class=3D"styled-by-prettify">{
    const char *ar =3D "blah= ";<= span style=3D"color: #000;" class=3D"styled-by-prettify">
    = return ar;
}

Thi= s is not.

const= char *GetLiteral2()
{
  const char ar[] =3D {'n', 'o',= 't', ' ', 'l',= 'i', 't', 'e',= 'r', 'a', 'l',= '\0'};
  return ar;
}

String literals are requir= ed to be stored in permanent memory, effectively part of the executable. Ar= bitrary `const char*`'s are not. What I want is a type that, in all case= s, is required to come only from actual literals. It's not just that th= e string is "immutable". It is important that the string come from a string= literal as defined by the standard.

Being able to create strings wi= th "static constexpr" and whatnot is not the issue here. String literals ar= e not the only source of `char*`s that can be "static constexpr"s. So that = won't help.

You're looking for a general class of immutable strings,= which may be the result of various operations. I'm talking about real, hon= est-to-God string literals, as defined by the standard. Not the result of v= arious constexpr computations or {} initializations or whatever.

--
 
---
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-pro= posals/?hl=3Den.
 
 
------=_Part_116_23604752.1360800562616-- .