On Friday 05 June 2015 22:25:43 Nicol Bolas wrote:
> In such environments, you are advised to write your own fixed-length string
> class. Remember: standard library objects are meant for general users. Some
> people have special needs, and they should write special types to handle
> them.

Are you sure we're talking about the same std::string which is a template
specialisation of a template that supports any character type, with any traits
for those characters and with an arbitrary allocator?

That sounds to me that it's not general users, but instead the class is meant
to be used in quite a lot of different scenarios.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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/.

.

On Sunday 07 June 2015 01:15:37 Sean Middleditch wrote:
> Pretty much every C++ library (save those explicitly written for games or
> embedded, tellingly) depend on std::string.

And Qt.

Because, in our opinion, std::string sucks.

std::(u16,u32,w)string is better. But it still lacks a lot.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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/.

.

On Sun, Jun 7, 2015 at 3:54 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> had an immediate drop-in replacement in C++11. How long do you think it
> would take to get rid of a bad std::string?

Based on the bad one we already have? :p

And again, the COW string example is somewhat amusing. I think you
have an incomplete understanding of what C++11's change was all about
and some misunderstandings about which mistakes led to it being
necessary to ban them.

> You want to change the standard to make your preferred subset
> (-=C2=ADfno=C2=ADexceptions, -=C2=ADfno=C2=ADrtti) actually a supported e=
lement of the standard.
> That's basically a red flag to C++ programmers saying "Don't use these
> features!"

Or a flag telling them to gracefully _support_ not having them in
place, which is exactly the case I've found whenever I file a bug
against a library using these features.

I get your fear here. I understand the perspective you're coming from.
I just disagree that it's as big of an issue as you think.

> Specialized needs require specialized tools.
>
> However, there is a way to give specialized tools a bit more standardizat=
ion
> than some library on GitHub: Technical Specifications. Maybe SG-14 should
> focus on a TS that includes various features (stand-alone, that don't aff=
ect
> existing types). A string class with configurable SSO, etc. That way, eve=
n

Way ahead of you. :)

(well, okay, slightly ahead of you, anyway.)

> But like language vivisection (ie: standard support for not having RTTI o=
r
> exceptions) and enforced/configurable SSO? Those are specialized needs. T=
hey
> benefit a limited selection of C++ programmers.

We have a different understanding of just how limited that selection is.

--=20

---=20
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 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-proposa=
ls/.

.

------=_Part_6658_1058843993.1436912228590
Content-Type: multipart/alternative;
 boundary="----=_Part_6659_522641604.1436912228590"

------=_Part_6659_522641604.1436912228590
Content-Type: text/plain; charset=UTF-8

Why not propose a std::basic_small_string<CharT,N,Traits,Allocator> and
while you're at it a std::small_vector<T,N,Allocator>. These types are
implemented by several libraries already and have wide applicability, even
if they are not necessarily mainstream. In my opinion, they are generic
enough, used widely enough, and painful enough to implement that they would
be good additions to the standard library. By using a separate type, we
don't risk making the same mistake that was made with CoW strings in the
past.

Even std::small_string<0> would be useful to me in cases where I want a
type to store a string as a data member but the string characters are not
hot so I don't want the SSO bytes wasting valuable cache space of the
parent type. SSO may be considered today to be a generally "better" string
optimization than CoW but there are still plenty of use cases where it
doesn't help or even hurts. There are also plenty of cases where we want to
use SSO and we know the SSO size that will cover 99% of our strings without
allocation.

--

---
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_6659_522641604.1436912228590
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Why not propose a std::basic_small_string&lt;CharT,N,=
Traits,Allocator&gt; and while you&#39;re at it a std::small_vector&lt;T,N,=
Allocator&gt;. These types are implemented=C2=A0by several libraries alread=
y and have wide applicability, even if they are not necessarily mainstream.=
 In my opinion, they are generic enough, used widely enough, and painful en=
ough to implement that they would be good additions to the standard library=
.. By using a separate type, we don&#39;t risk=C2=A0making the same mistake =
that was made with CoW strings in the past.</div><div>=C2=A0</div><div>Even=
 std::small_string&lt;0&gt; would be useful to me in cases where I want a t=
ype to store a string as a data member but the string characters=C2=A0are n=
ot hot so I don&#39;t want the SSO bytes wasting valuable cache space of th=
e parent type. SSO may be considered today to be a generally &quot;better&q=
uot; string optimization than CoW but there are still plenty of use cases w=
here it doesn&#39;t help or even hurts. There are=C2=A0also plenty of cases=
 where we want to use SSO and we know the SSO size that will cover 99% of o=
ur strings without allocation.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6659_522641604.1436912228590--
------=_Part_6658_1058843993.1436912228590--

.

On Tuesday 14 July 2015 15:17:08 Matthew Fioravante wrote:
> Even std::small_string<0> would be useful to me in cases where I want a
> type to store a string as a data member but the string characters are not
> hot so I don't want the SSO bytes wasting valuable cache space of the
> parent type. SSO may be considered today to be a generally "better" string
> optimization than CoW but there are still plenty of use cases where it
> doesn't help or even hurts. There are also plenty of cases where we want to
> use SSO and we know the SSO size that will cover 99% of our strings without
> allocation.

A small_string<0> would still do SSO if the size of the string is smaller than
the size of the overhead for non-small case. In other words, anything string
smaller than sizeof(void*)-1 bytes is likely to be SSO'ed.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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/.

.