Topic: Improvements for string literals
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 10 Feb 2013 18:52:27 -0800 (PST)
Raw View
------=_Part_139_6368071.1360551147809
Content-Type: text/plain; charset=ISO-8859-1
Note: the type `charT` refers to any of the available character types, for
the various string literals.
It is often useful to want to differentiate between a mere string and a
string that comes from a string literal. So what I was thinking was that
string literals should return some specialized type, which can be used
instead of a `const charT[]`/`const charT*`.
The first hurdle is the definition of this. I don't think it can be a real
C++ type, because C++ overload resolution rules would play havoc with this.
Even if the type was implicitly convertible to a `const charT[]` and `const
charT*`, you can only get one implicit conversion between the source type
and the destination type. So something as simple as this:
void Func(const std::string &str);
Func("a string");
would not work without modifications to `std::string`. And while we could
do that with our string classes, we can't do it to othe people's classes.
So this would be a *massively* breaking change.
Now, we *could* do it with some template metaprogramming magic. Using
`static if` notation (because I have no stomach for `std::enable_if`:
struct string_literal
{
template<typename T>
operator T() const if(is_convertible<const char*, T>::value)
{ return T((const char*)*this) }
operator const char*() const {...}
};
This would allow the type to be convertible to any T which can be
implicitly constructed from the literal type.
Another potential pitfall is in template argument deduction contexts.
Normally, a string literal is always deduced as a `const charT [n]`. So if
a function is expecting that kind of deduction to work, it could become a
problem. I'm not sure how to resolve that one; perhaps some specific
language around template argument deduction of string literals would work.
Anyone think of any other problems?
Now obviously, this is a lot of work, fraught with peril. What is the
upside?
1: We get the ability to have functions which take values that we are *
certain* are string literals.
2: We can use template metaprogramming to differentiate between someone
passing any old `const charT*` and an actual string literal. This could be
useful for std::string implementations, where they could store an allocated
string or a string_literal, depending on how it was initialized. Obviously
non-const member accesses will cause a copy of the string, similar to COW,
but without the general dangers of that construct.
3: We can do useful tricks. For example, it would be great to introduce a
char8_t for UTF-8 encoded literals. But because we didn't do that for
C++11, we can't have C++14 simply declare that `u8""` must become a `const
char8_t[]`; it would break any code that currently expects it to be a
`const char[]`. However, we can declare that the type `u8""` returns can be
implicitly converted into both of them. But after the conversion is done,
you can't convert between them. So the direct use of the literal expression
will result in something special that picks one from the other. Namely,
this type.
As for the class interface itself, I have no problem with forcing you to
convert it into a `string_ref` (or whatever we're calling it) in order to
access any functionality more advanced than:
constexpr size_t size() noexcept;
constexpr bool empty() noexcept;
const_reference charT *operator[];
constexpr const charT *data() noexcept;
So... good? Bad?
--
---
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_139_6368071.1360551147809
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Note: the type `charT` refers to any of the available character types, for =
the various string literals.<br><br>It is often useful to want to different=
iate between a mere string and a string that comes from a string literal. S=
o what I was thinking was that string literals should return some specializ=
ed type, which can be used instead of a `const charT[]`/`const charT*`.<br>=
<br>The first hurdle is the definition of this. I don't think it can be a r=
eal C++ type, because C++ overload resolution rules would play havoc with t=
his. Even if the type was implicitly convertible to a `const charT[]` and `=
const charT*`, you can only get one implicit conversion between the source =
type and the destination type. So something as simple as this:<br><br><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wr=
ap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">Func</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">string</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&am=
p;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">str</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">Func</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
080;" class=3D"styled-by-prettify">"a string"</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">);</span></div></code></div><br>would no=
t work without modifications to `std::string`. And while we could do that w=
ith our string classes, we can't do it to othe people's classes. So this wo=
uld be a <i>massively</i> breaking change.<br><br>Now, we <i>could</i> do i=
t with some template metaprogramming magic. Using `static if` notation (bec=
ause I have no stomach for `std::enable_if`:<br><br><div class=3D"prettypri=
nt" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 1=
87, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> string_literal<br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">operator</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">is_convertible</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">char</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">*,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>:=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">value</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">((</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">char</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*)*<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">this</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br><br> </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">operator</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">char</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">*()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{...}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div><br>This wou=
ld allow the type to be convertible to any T which can be implicitly constr=
ucted from the literal type.<br><br>Another potential pitfall is in templat=
e argument deduction contexts. Normally, a string literal is always deduced=
as a `const charT [n]`. So if a function is expecting that kind of deducti=
on to work, it could become a problem. I'm not sure how to resolve that one=
; perhaps some specific language around template argument deduction of stri=
ng literals would work.<br><br>Anyone think of any other problems?<br><br>N=
ow obviously, this is a lot of work, fraught with peril. What is the upside=
?<br><br>1: We get the ability to have functions which take values that we =
are <i>certain</i> are string literals.<br><br>2: We can use template metap=
rogramming to differentiate between someone passing any old `const charT*` =
and an actual string literal. This could be useful for std::string implemen=
tations, where they could store an allocated string or a string_literal, de=
pending on how it was initialized. Obviously non-const member accesses will=
cause a copy of the string, similar to COW, but without the general danger=
s of that construct.<br><br>3: We can do useful tricks. For example, it wou=
ld be great to introduce a char8_t for UTF-8 encoded literals. But because =
we didn't do that for C++11, we can't have C++14 simply declare that `u8""`=
must become a `const char8_t[]`; it would break any code that currently ex=
pects it to be a `const char[]`. However, we can declare that the type `u8"=
"` returns can be implicitly converted into both of them. But after the con=
version is done, you can't convert between them. So the direct use of the l=
iteral expression will result in something special that picks one from the =
other. Namely, this type.<br><br>As for the class interface itself, I have =
no problem with forcing you to convert it into a `string_ref` (or whatever =
we're calling it) in order to access any functionality more advanced than:<=
br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">const=
expr</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> size_=
t size</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> noexcept</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> empty</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> noexcept</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>const_reference charT </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">*</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">operator</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">[];</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">constexpr</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> charT </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">data</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> noexcept</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span></div></code></div><br>So... goo=
d? Bad?<br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_139_6368071.1360551147809--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Mon, 11 Feb 2013 01:44:52 -0800 (PST)
Raw View
------=_Part_168_32446896.1360575892843
Content-Type: text/plain; charset=ISO-8859-1
You're still breaking template specializations- for example, std::begin().
Also, your operator should be for a const char[N], not const char*.
Finally, it seems to me that you really need this<https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!topic/std-proposals/fgCw1xFGZLM>
proposal.
--
---
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_168_32446896.1360575892843
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
You're still breaking template specializations- for example, std::begin(). =
Also, your operator should be for a const char[N], not const char*.<div><br=
></div><div>Finally, it seems to me that you really need <a href=3D"ht=
tps://groups.google.com/a/isocpp.org/forum/?fromgroups=3D#!topic/std-propos=
als/fgCw1xFGZLM">this</a> proposal.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_168_32446896.1360575892843--
.
Author: Nikolay Ivchenkov <mk.ivchenkov@gmail.com>
Date: Mon, 11 Feb 2013 01:46:18 -0800 (PST)
Raw View
------=_Part_201_17904782.1360575978691
Content-Type: text/plain; charset=ISO-8859-1
On Monday, February 11, 2013 6:52:27 AM UTC+4, Nicol Bolas wrote:
>
>
> 2: We can use template metaprogramming to differentiate between someone
> passing any old `const charT*` and an actual string literal. This could be
> useful for std::string implementations, where they could store an allocated
> string or a string_literal, depending on how it was initialized. Obviously
> non-const member accesses will cause a copy of the string, similar to COW,
> but without the general dangers of that construct.
>
std::basic_string cannot be implemented so. Expression str[0] (where str is
an instance of std::string) shall not throw exceptions and the equality
str.c_str() == &str[0] shall always hold:
void f(std::string &str)
{
char const *p1 = str.c_str();
char *p2 = &str[0];
if (!str.empty())
*p2 = '?';
assert(p1 == p2);
}
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 CharT>
class basic_immutable_string
{
public:
template <std::size_t N>
basic_immutable_string(static constexpr CharT (&s)[N]); // #1
basic_immutable_string(CharT const *s); // #2
....
};
using immutable_string = basic_immutable_string<char>;
template <std::size_t N>
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
}
--
---
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_201_17904782.1360575978691
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Monday, February 11, 2013 6:52:27 AM UTC+4, Nicol Bolas wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><br>2: We can use template metaprogrammi=
ng to differentiate between someone passing any old `const charT*` and an a=
ctual string literal. This could be useful for std::string implementations,=
where they could store an allocated string or a string_literal, depending =
on how it was initialized. Obviously non-const member accesses will cause a=
copy of the string, similar to COW, but without the general dangers of tha=
t construct.<br></blockquote><div><br>std::basic_string cannot be implement=
ed so. Expression str[0] (where str is an instance of std::string) shall no=
t throw exceptions and the equality str.c_str() =3D=3D &str[0] shall al=
ways hold:<br><br> void f(std::string &str)<br> =
{<br> char const *p1=
=3D str.c_str();<br> char *p2 =
=3D &str[0];<br> if (!str.emp=
ty())<br> =
*p2 =3D '?';<br> assert(p1 =3D=
=3D p2);<br> }<br><br>It would be possible to improve cla=
sses for immutable strings if parameters could be declared with 'static con=
stexpr' and the overload resolution could select appropriate function depen=
ding on whether the argument is known to be a constexpr object with static =
storage duration:<br><br> template <class CharT><br=
> class basic_immutable_string<br=
> {<br> public:<br> &n=
bsp; template <std::size_t N><br> =
basic_immutable_string(sta=
tic constexpr CharT (&s)[N]); // #1<br> &n=
bsp; basic_immutable_string(CharT const *s); // #2<br> &nb=
sp; ....<br> };<br><br> &nbs=
p; using immutable_string =3D basic_immutable_string<char>;<br>=
<br> template <std::size_t N><br> =
void f(static constexpr char (&x)[N])<br> =
; {<br> static conste=
xpr char a1[] =3D "text";<br> sta=
tic char a2[] =3D "text";<br> aut=
o &ra1 =3D a1;<br><br> immuta=
ble_string s0 =3D x; // calls #1<br> &nb=
sp; immutable_string s1 =3D a1; // calls #1<br> &nbs=
p; immutable_string s2 =3D a2; // calls #2<br>  =
; immutable_string s3 =3D ra1; // calls #2<br> =
; immutable_string s4 =3D "text"; // ca=
lls #1<br> }<br></div><br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_201_17904782.1360575978691--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 11 Feb 2013 03:01:41 -0800 (PST)
Raw View
------=_Part_949_33418972.1360580502048
Content-Type: text/plain; charset=ISO-8859-1
On Monday, February 11, 2013 1:46:18 AM UTC-8, Nikolay Ivchenkov wrote:
>
> On Monday, February 11, 2013 6:52:27 AM UTC+4, Nicol Bolas wrote:
>>
>>
>> 2: We can use template metaprogramming to differentiate between someone
>> passing any old `const charT*` and an actual string literal. This could be
>> useful for std::string implementations, where they could store an allocated
>> string or a string_literal, depending on how it was initialized. Obviously
>> non-const member accesses will cause a copy of the string, similar to COW,
>> but without the general dangers of that construct.
>>
>
> std::basic_string cannot be implemented so. Expression str[0] (where str
> is an instance of std::string) shall not throw exceptions and the equality
> str.c_str() == &str[0] shall always hold:
>
> void f(std::string &str)
> {
> char const *p1 = str.c_str();
> char *p2 = &str[0];
> if (!str.empty())
> *p2 = '?';
> assert(p1 == p2);
> }
>
Fair enough.
>
> 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 CharT>
> class basic_immutable_string
> {
> public:
> template <std::size_t N>
> basic_immutable_string(static constexpr CharT (&s)[N]); // #1
> basic_immutable_string(CharT const *s); // #2
> ....
> };
>
> using immutable_string = basic_immutable_string<char>;
>
> template <std::size_t N>
> 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 ar3[] = {'n', 'o', 't', ' ', 'l', 'i', 't', 'e', 'r', 'a',
'l'};
That would work just as well with your way.
--
---
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_949_33418972.1360580502048
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, February 11, 2013 1:46:18 AM UTC-8, Nikolay Ivchenkov wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday, February 11, 20=
13 6:52:27 AM UTC+4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><br>2: We can use template metaprogramming to differentiate between som=
eone passing any old `const charT*` and an actual string literal. This coul=
d be useful for std::string implementations, where they could store an allo=
cated string or a string_literal, depending on how it was initialized. Obvi=
ously non-const member accesses will cause a copy of the string, similar to=
COW, but without the general dangers of that construct.<br></blockquote><d=
iv><br>std::basic_string cannot be implemented so. Expression str[0] (where=
str is an instance of std::string) shall not throw exceptions and the equa=
lity str.c_str() =3D=3D &str[0] shall always hold:<br><br> &=
nbsp; void f(std::string &str)<br> {<br> &=
nbsp; char const *p1 =3D str.c_str();<br> &nbs=
p; char *p2 =3D &str[0];<br> &=
nbsp; if (!str.empty())<br> =
*p2 =3D '?';<br> &nbs=
p; assert(p1 =3D=3D p2);<br> }<br=
></div></blockquote><div><br>Fair enough.<br> </div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div><br>It would be possible to improve classe=
s for immutable strings if parameters could be declared with 'static conste=
xpr' and the overload resolution could select appropriate function dependin=
g on whether the argument is known to be a constexpr object with static sto=
rage duration:<br><br> template <class CharT><br>&n=
bsp; class basic_immutable_string<br>&n=
bsp; {<br> public:<br>  =
; template <std::size_t N><br> &nb=
sp; basic_immutable_string(static=
constexpr CharT (&s)[N]); // #1<br>  =
; basic_immutable_string(CharT const *s); // #2<br> =
....<br> };<br><br> &=
nbsp; using immutable_string =3D basic_immutable_string<char>;<br><br=
> template <std::size_t N><br> &nb=
sp; void f(static constexpr char (&x)[N])<br> &n=
bsp; {<br> static constexpr=
char a1[] =3D "text";<br> static=
char a2[] =3D "text";<br> auto &=
amp;ra1 =3D a1;<br><br> immutable=
_string s0 =3D x; // calls #1<br> =
immutable_string s1 =3D a1; // calls #1<br> &=
nbsp; immutable_string s2 =3D a2; // calls #2<br> &n=
bsp; immutable_string s3 =3D ra1; // calls #2<br> &n=
bsp; immutable_string s4 =3D "text"; // calls=
#1<br> }<br></div><br></blockquote><div><br>Not quite:<b=
r><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">static=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> ar3</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">[]</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{</span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify">'n'</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #080;" class=3D"styled-by-prettify">'o'</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080=
;" class=3D"styled-by-prettify">'t'</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify">' '</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #080;" class=3D"styled-by-prettify">'l'</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080=
;" class=3D"styled-by-prettify">'i'</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify">'t'</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #080;" class=3D"styled-by-prettify">'e'</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080=
;" class=3D"styled-by-prettify">'r'</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify">'a'</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #080;" class=3D"styled-by-prettify">'l'</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br=
>That would work just as well with your way.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_949_33418972.1360580502048--
.
Author: Nikolay Ivchenkov <mk.ivchenkov@gmail.com>
Date: Wed, 13 Feb 2013 14:40:35 -0800 (PST)
Raw View
------=_Part_107_12740275.1360795235897
Content-Type: text/plain; charset=ISO-8859-1
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 CharT>
>> class basic_immutable_string
>> {
>> public:
>> template <std::size_t N>
>> basic_immutable_string(static constexpr CharT (&s)[N]); // #1
>> basic_immutable_string(CharT const *s); // #2
>> ....
>> };
>>
>> using immutable_string = basic_immutable_string<char>;
>>
>> template <std::size_t N>
>> 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.
--
---
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_107_12740275.1360795235897
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Monday, February 11, 2013 3:01:41 PM UTC+4, Nicol Bolas wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div>It would be possible to improve classes for immutable strings if para=
meters could be declared with 'static constexpr' and the overload resolutio=
n could select appropriate function depending on whether the argument is kn=
own to be a constexpr object with static storage duration:<br><br> &nb=
sp; template <class CharT><br> &nb=
sp; class basic_immutable_string<br> {<br> &nb=
sp; public:<br> template &l=
t;std::size_t N><br> &nbs=
p; basic_immutable_string(static constexpr CharT (&s)[N]); =
// #1<br> basic_immutable_string(=
CharT const *s); // #2<br> ....<b=
r> };<br><br> using immutable_string =
=3D basic_immutable_string<char>;<br><br> template =
<std::size_t N><br> void f(=
static constexpr char (&x)[N])<br> {<br> &=
nbsp; static constexpr char a1[] =3D "text";<br>&nb=
sp; static char a2[] =3D "text";<br>&nb=
sp; auto &ra1 =3D a1;<br><br> =
immutable_string s0 =3D x; // calls #1=
<br> immutable_string s1 =3D a1; =
// calls #1<br> immutable_string =
s2 =3D a2; // calls #2<br> immuta=
ble_string s3 =3D ra1; // calls #2<br> &=
nbsp; immutable_string s4 =3D "text"; // calls #1<br> }<b=
r></div><br></blockquote><div><br>Not quite:<br><br><div style=3D"backgroun=
d-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;b=
order-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#008"=
>static</span><span style=3D"color:#000"> </span><span style=3D"color:#008"=
>constexpr</span><span style=3D"color:#000"> char ar3</span><span style=3D"=
color:#660">[]</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">{</span><span style=3D"color:#080">'n'</span><span style=3D"color:#660=
">,</span><span style=3D"color:#000"> </span><span style=3D"color:#080">'o'=
</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#080">'t'</span><span style=3D"color:#660">,</span><=
span style=3D"color:#000"> </span><span style=3D"color:#080">' '</span><spa=
n style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#080">'l'</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#080">'i'</span><span style=3D=
"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#080">'t'</span><span style=3D"color:#660">,</span><span style=3D"color:#=
000"> </span><span style=3D"color:#080">'e'</span><span style=3D"color:#660=
">,</span><span style=3D"color:#000"> </span><span style=3D"color:#080">'r'=
</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#080">'a'</span><span style=3D"color:#660">,</span><=
span style=3D"color:#000"> </span><span style=3D"color:#080">'l'</span><spa=
n style=3D"color:#660">};</span><span style=3D"color:#000"><br></span></div=
></code></div><br>That would work just as well with your way.<br></div></bl=
ockquote><div><br>If we remove the constexpr specifier, then initialization=
<br><br> immutable_string s =3D ar3;<br><br>will not be w=
ell-defined, because ar3 is not a null-terminated string. In the presence o=
f constexpr the effect of such initialization could be considered as undefi=
ned similarly.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_107_12740275.1360795235897--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 13 Feb 2013 16:09:22 -0800 (PST)
Raw View
------=_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 CharT>
>>> class basic_immutable_string
>>> {
>>> public:
>>> template <std::size_t N>
>>> basic_immutable_string(static constexpr CharT (&s)[N]); // #1
>>> basic_immutable_string(CharT const *s); // #2
>>> ....
>>> };
>>>
>>> using immutable_string = basic_immutable_string<char>;
>>>
>>> template <std::size_t N>
>>> 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
<br><br>On Wednesday, February 13, 2013 2:40:35 PM UTC-8, Nikolay Ivchenkov=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday, February 11,=
2013 3:01:41 PM UTC+4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div>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:<br><br> template <class =
CharT><br> class basic_immutab=
le_string<br> {<br> public:<br> &n=
bsp; template <std::size_t N><br> =
basic_immutabl=
e_string(static constexpr CharT (&s)[N]); // #1<br> &n=
bsp; basic_immutable_string(CharT const *s); // #2<br>&nb=
sp; ....<br> };<br><b=
r> using immutable_string =3D basic_immutable_string<c=
har>;<br><br> template <std::size_t N><br> =
void f(static constexpr char (&x)[=
N])<br> {<br> s=
tatic constexpr char a1[] =3D "text";<br> &nbs=
p; static char a2[] =3D "text";<br> &nbs=
p; auto &ra1 =3D a1;<br><br> &=
nbsp; immutable_string s0 =3D x; // calls #1<br> &nb=
sp; immutable_string s1 =3D a1; // calls #1<br> &nbs=
p; immutable_string s2 =3D a2; // calls #2<br> =
; immutable_string s3 =3D ra1; // calls=
#2<br> immutable_string s4 =3D "=
text"; // calls #1<br> }<br></div><br></blockquote><div><=
br>Not quite:<br><br><div style=3D"background-color:rgb(250,250,250);border=
-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break=
-word"><code><div><span style=3D"color:#008">static</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#008">constexpr</span><span style=3D=
"color:#000"> char ar3</span><span style=3D"color:#660">[]</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"c=
olor:#080">'n'</span><span style=3D"color:#660">,</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#080">'o'</span><span style=3D"color:#=
660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#080">=
't'</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </=
span><span style=3D"color:#080">' '</span><span style=3D"color:#660">,</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#080">'l'</span><=
span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span =
style=3D"color:#080">'i'</span><span style=3D"color:#660">,</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#080">'t'</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#080">'e'</span><span style=3D"color:#660">,</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#080">'r'</span><span style=3D"color:#=
660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#080">=
'a'</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </=
span><span style=3D"color:#080">'l'</span><span style=3D"color:#660">};</sp=
an><span style=3D"color:#000"><br></span></div></code></div><br>That would =
work just as well with your way.<br></div></blockquote><div><br>If we remov=
e the constexpr specifier, then initialization<br><br> im=
mutable_string s =3D ar3;<br><br>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.<br></div></blo=
ckquote><div><br>Even if it were NULL-terminated, it wouldn't be a <i>strin=
g literal</i> 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:<br><br><div class=3D"prettyprint" st=
yle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 18=
7); border-style: solid; border-width: 1px; word-wrap: break-word;"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">char</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">*</span><span style=3D"color: #606;" class=3D"styled-by-prettify">GetL=
iteral</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">ar </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"blah=
"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> ar</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span></div></code></div><br>Thi=
s is not.<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">char</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">GetLiteral2</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">char</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> ar</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[]</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #080;" =
class=3D"styled-by-prettify">'n'</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">'o'</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">'t'</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;=
" class=3D"styled-by-prettify">' '</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">'l'</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">'i'</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;=
" class=3D"styled-by-prettify">'t'</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">'e'</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">'r'</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;=
" class=3D"styled-by-prettify">'a'</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">'l'</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">'\0'</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> ar</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span></div></code></div><br>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, <i>in all case=
s</i>, 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.<br><br>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.<br><br>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.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_116_23604752.1360800562616--
.
Author: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Wed, 20 Feb 2013 15:34:33 -0800 (PST)
Raw View
------=_Part_1094_25195516.1361403273116
Content-Type: text/plain; charset=ISO-8859-1
On Monday, February 11, 2013 3:52:27 AM UTC+1, Nicol Bolas wrote:
>
> Note: the type `charT` refers to any of the available character types, for
> the various string literals.
>
> It is often useful to want to differentiate between a mere string and a
> string that comes from a string literal. So what I was thinking was that
> string literals should return some specialized type, which can be used
> instead of a `const charT[]`/`const charT*`.
>
>
I have proposed in some discussions that we could also have a type that is
special cased by overload resolution similar to std::initializer_list.
Where that type is special cased for "{...}", our additional type is
special cased for string literals. Example:
void f(string_ref s) {
}
void f(const char (&x)[4]) { }
string_ref could be that language-support type. When you then call f with a
string literal "foo", special overload resolution rules say that the first
f is picked, even though the conversion sequence for both parameters would
be an identity conversion (string-literal -> string_ref => identity
conversion. not a user defined conversion sequence!).
--
---
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_1094_25195516.1361403273116
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, February 11, 2013 3:52:27 AM UTC+1, Nicol Bolas wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">Note: the type `charT` refers to=
any of the available character types, for the various string literals.<br>=
<br>It is often useful to want to differentiate between a mere string and a=
string that comes from a string literal. So what I was thinking was that s=
tring literals should return some specialized type, which can be used inste=
ad of a `const charT[]`/`const charT*`.<br><br></blockquote><div><br></div>=
<div>I have proposed in some discussions that we could also have a type tha=
t is special cased by overload resolution similar to std::initializer_list.=
Where that type is special cased for "{...}", our additional type is speci=
al cased for string literals. Example:</div><div><br></div><div> &nbs=
p; void f(string_ref s) {</div><div><br></div><div> }</div><di=
v><br></div><div> void f(const char (&x)[4]) { }</div><div=
><br></div><div>string_ref could be that language-support type. When you th=
en call f with a string literal "foo", special overload resolution rules sa=
y that the first f is picked, even though the conversion sequence for both =
parameters would be an identity conversion (string-literal -> string_ref=
=3D> identity conversion. not a user defined conversion sequence!).</di=
v>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1094_25195516.1361403273116--
.