220 8154 article Path: news.gmane.org!not-for-mail From: Michael Price - Dev Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: A compile-time string literal library type Date: Tue, 17 Dec 2013 19:45:54 -0800 (PST) Lines: 242 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2517_23319239.1387338354477" X-Trace: ger.gmane.org 1387338349 8690 80.91.229.3 (18 Dec 2013 03:45:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Dec 2013 03:45:49 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC63BP4Z2YBRB45UYSKQKGQEMHIEISA@isocpp.org Wed Dec 18 04:45:57 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vt856-0002eD-Ub for gclcip-std-proposals@m.gmane.org; Wed, 18 Dec 2013 04:45:57 +0100 Original-Received: by mail-ie0-f200.google.com with SMTP id at1sf25425185iec.7 for ; Tue, 17 Dec 2013 19:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references: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=Lpja7U9CReFepqlSkryckLMkSwvayab6Mm7Ztp31rTw=; b=NJq5yzCkNhv9o+wVJ6qah/BI6t6eR12u6u47xcq+EN5hU+n9KUVq5v7RNGeko7nw91 qIEenWKi7ESGgAuhfOxzxMEbpzp8pleFNRVXQIUXUuPrbO5wuih0L+wcgV5E9ZU9PCqW kKiZ+T56MB+voW9KoB0bxdNJwYIqA1PVIbxxuryNtkAAwB+f0UOBGh7D6IptTWlTufa3 wVLF2JnqHC/O9k2W+i2g7NXVBLPxsxwhckdwP2HzfBsZaD30rpOpWZoXphEhMJ9WZX25 W04gQev//BI3KuvZzTDVrdFacUbiJXfs6Iy3JiFOEYDZAj5Flb4glnizotGL8Y5EFsuA GJdw== 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:in-reply-to:references :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=Lpja7U9CReFepqlSkryckLMkSwvayab6Mm7Ztp31rTw=; b=DWMa2lUOmRrgYn7/3aH4WR+wA43S5j9kKkB8N0xy1wImrqsk5XWWNyN+Q9LCFMZKpr zwrkxtT+LCSEgQlAMpXaRsb6GvvI1i9tfpHskWD8ycoXTSfjLY0mF4O195BRQ+3r0Dmb kubMBCN4Q/q/5xIny6UeY9kRyVlVrt6RHh+M9J/lXzJ5A5bTfpIVeaJ6BVjxdAqKuWmU RGppDiXx1ZuPoa1bddw4IkMjmqhqznl2TUNfqO0SwX3lPB2AiZu7JzViRrXmCaAYa7Qc DJKnL3Yk/CfStXKbB8AWnZrrlESXeAtt7KMPhm7ItKT2Kyoec2YAn3PAKMxfLpcJFdsW Vmbw== X-Gm-Message-State: ALoCoQmYCwmsWZX1TEF5Hhn94blfg1w/MbDuTQZaekk26luKb4Uvv3qs78Uul9HAwozpDO7mmyER X-Received: by 10.182.111.227 with SMTP id il3mr4189908obb.41.1387338356015; Tue, 17 Dec 2013 19:45:56 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.126.227 with SMTP id nb3ls1043935obb.5.gmail; Tue, 17 Dec 2013 19:45:55 -0800 (PST) X-Received: by 10.182.113.194 with SMTP id ja2mr1843obb.31.1387338354999; Tue, 17 Dec 2013 19:45:54 -0800 (PST) In-Reply-To: X-Original-Sender: michael.b.price.dev@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:8154 Archived-At: ------=_Part_2517_23319239.1387338354477 Content-Type: text/plain; charset=ISO-8859-1 On Sunday, December 15, 2013 10:52:52 PM UTC-6, Zhihao Yuan wrote: > > On Sun, Dec 15, 2013 at 10:26 PM, Michael Price - Dev > > wrote: > > I'm considering writing up a proposal to standardize a library type that > > represents a compile-time sequence of character literals. I'm looking > for a > > first round of feedback. You can view my prototype implementation at > > > https://github.com/michaelbprice/cxx_snippets/blob/master/string_literal/string_literal.cpp > > > > I'm using the top-of-trunk clang to compile with the following > command-line: > > I think you know that the language feature you used > > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3599.html > > is not a part of C++14. > Actually, I was unaware, although I had stumbled upon clang's implementation of said feature mostly by mistake. I'm not intending this for inclusion in C++14, but rather the next version out. I've contacted the author of that proposal to see about addressing the straw poll concerns. > Anyway. > > What's the different between `make_array("str")` and "str"_cs? > > http://isocpp.org/files/papers/N3824.html > > 1. string_literalS are different in types (works with template); > 2. string_literal cannot be modified; > 3. string_literal has some algorithms as member functions. > > So what is the problem you want to solve? Compile-time parsing? > If so, Bristol EWG says: > > 1. don't think template instantiations is the only way to do it; > 2. doubt user to overuse it (a compile time SQL parser is fun, > but what you gain?); > 3. need use cases. > My initially motivating use case was as a proof for yet another change that I will be proposing regarding the message for static_assert. Example: constexpr auto library_name = "BEST"_cs; constexpr auto static_prefix = library_name + ": "_cs; static_assert(false, static_prefix + "Oops, did I say false"); // would print: "BEST: Oops, did I say false" Of course, there's lots of other potential uses. See http://2012.cppnow.org/session/metaparse-complie-time-parsing-with-template-metaprogramming/ for instance (won best presentation award at C++Now 2012). I can't even begin to imagine all of the cool ways that this type of thing could be used. For me, the idea that in order to get a rich interface for strings, one must succumb to the run-time penalty of std::string is just counter to one of the ideas of fundamental underpinnings of C++, namely that we don't make people pay for the things that they don't need. This is very much the same rationale behind std::array (vs. C-arrays or std::vector). > -- > Zhihao Yuan, ID lichray > The best way to predict the future is to invent it. > ___________________________________________________ > 4BSD -- http://4bsd.biz/ > -- --- 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_2517_23319239.1387338354477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sunday, December 15, 2013 10:52:52 PM UTC-6, Zh= ihao Yuan wrote:
On Sun, Dec 15= , 2013 at 10:26 PM, Michael Price - Dev
<michael.b...@gmail.com> wrote:
> I'm considering writing up a proposal to standardize a library typ= e that
> represents a compile-time sequence of character literals.  I'= m looking for a
> first round of feedback.  You can view my prototype implement= ation at
> https://github.com/michaelbprice/cxx_snippets/<= wbr>blob/master/string_literal/string_literal.cpp
>
> I'm using the top-of-trunk clang to compile with the following com= mand-line:

I think you know that the language feature you used

  http://www.open-std.org/JTC1/SC22/WG21/docs= /papers/2013/n3599.html

is not a part of C++14. 

Actua= lly, I was unaware, although I had stumbled upon clang's implementation of = said feature mostly by mistake.  I'm not intending this for inclusion = in C++14, but rather the next version out.  I've contacted the author = of that proposal to see about addressing the straw poll concerns. 
 
Anyway.

What's the different between `make_array("str")` and "str"_cs?

  http://isocpp.org/files/papers/N3824.html

 1. string_literalS are different in types (works with template);
 2. string_literal cannot be modified;
 3. string_literal has some algorithms as member functions.

So what is the problem you want to solve?  Compile-time parsing?
If so, Bristol EWG says:

 1. don't think template instantiations is the only way to do it;
 2. doubt user to overuse it (a compile time SQL parser is fun,
    but what you gain?);
 3. need use cases.

My initial= ly motivating use case was as a proof for yet another change that I will be= proposing regarding the message for static_assert.  Example:


constexpr auto library_name =3D "BEST"_cs;
constexpr auto static_prefix =3D library_name + ": "_cs;

static_assert(false,<= /span> static_pre= fix + "Oops, did I say false"<= /span>); // would print: "BEST: Oops,= did I say false"

Of course, there's lots of other potential uses. See http://2012.cppnow.org/session/metaparse-complie-time-parsing= -with-template-metaprogramming/ for instance (won best presentatio= n award at C++Now 2012).  I can't even begin to imagine all of the coo= l ways that this type of thing could be used.

For = me, the idea that in order to get a rich interface for strings, one must su= ccumb to the run-time penalty of std::string is just counter to one of the = ideas of fundamental underpinnings of C++, namely that we don't make people= pay for the things that they don't need. This is very much the same ration= ale behind std::array (vs. C-arrays or std::vector).
 
=
--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--
 
---
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_2517_23319239.1387338354477-- .