------=_Part_227_1516806250.1433567656646
Content-Type: multipart/alternative;
 boundary="----=_Part_228_184270213.1433567656646"

------=_Part_228_184270213.1433567656646
Content-Type: text/plain; charset=UTF-8

Hello everyone,

I would like to know if there would be interest in a proposal for detecting
when a string allocates in the heap.

The rationale for this is that there are environments in which heap
allocations should be forbidden,
but use of short strings can still be made, with the convenience of string
functions.
Embedded environments are such an example:


A static member function (or free?) could be provided. Something like:

//Pseudo-C++, no basic_string here to go straight to the question
class string {
   public:
       static std::size_t max_stack_allocated_size();
       static bool needs_dynamic_allocation(std::size_t sz);
};

Any interest in this?


--

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

<div dir=3D"ltr">Hello everyone,<div><br></div><div>I would like to know if=
 there would be interest in a proposal for detecting when a string allocate=
s in the heap.</div><div><br></div><div>The rationale for this is that ther=
e are environments in which heap allocations should be forbidden,</div><div=
>but use of short strings can still be made, with the convenience of string=
 functions.&nbsp;</div><div>Embedded environments are such an example:</div=
><div><br></div><div><br></div><div>A static member function (or free?) cou=
ld be provided. Something like:</div><div><br></div><div>//Pseudo-C++, no b=
asic_string here to go straight to the question</div><div>class string {</d=
iv><div>&nbsp; &nbsp;public:</div><div>&nbsp; &nbsp; &nbsp; &nbsp;static st=
d::size_t max_stack_allocated_size();</div><div>&nbsp; &nbsp; &nbsp; &nbsp;=
static bool needs_dynamic_allocation(std::size_t sz);</div><div>};</div><di=
v><br></div><div>Any interest in this?</div><div><br></div><div><br></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_228_184270213.1433567656646--
------=_Part_227_1516806250.1433567656646--

.

------=_Part_243_906290766.1433568343431
Content-Type: multipart/alternative;
 boundary="----=_Part_244_2074879638.1433568343431"

------=_Part_244_2074879638.1433568343431
Content-Type: text/plain; charset=UTF-8

On Saturday, June 6, 2015 at 1:14:16 AM UTC-4, german...@hubblehome.com
wrote:
>
> Hello everyone,
>
> I would like to know if there would be interest in a proposal for
> detecting when a string allocates in the heap.
>
> The rationale for this is that there are environments in which heap
> allocations should be forbidden,
> but use of short strings can still be made, with the convenience of string
> functions.
>

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.

This would be better for you in the long run, as you won't have to deal
with variances among standard library implementations (assuming you're
using more than one). This way, you have complete control over how many
characters you have, rather than being forced into whatever the lowest
common denominator is.

Oh, and since SSO is an *optimization*, it is not mandated by the standard,
so APIs based on it shouldn't be exposed by the standard either.

You're probably being tripped up by the current standard's unfortunate
reliance on std::basic_string for many APIs, as opposed to something more
open. Until std::string_view gets propagated to all appropriate APIs, that
will unfortunately keep annoying people who can't use basic_string.

--

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

<div dir=3D"ltr">On Saturday, June 6, 2015 at 1:14:16 AM UTC-4, german...@h=
ubblehome.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Hello everyone,<div><br></div><div>I would like to know if there w=
ould be interest in a proposal for detecting when a string allocates in the=
 heap.</div><div><br></div><div>The rationale for this is that there are en=
vironments in which heap allocations should be forbidden,</div><div>but use=
 of short strings can still be made, with the convenience of string functio=
ns.</div></div></blockquote><div><br>In such environments, you are advised =
to write your own fixed-length string class. Remember: standard library obj=
ects are meant for general users. Some people have special needs, and they =
should write special types to handle them.<br><br>This would be better for =
you in the long run, as you won't have to deal with variances among standar=
d library implementations (assuming you're using more than one). This way, =
you have complete control over how many characters you have, rather than be=
ing forced into whatever the lowest common denominator is.<br><br>Oh, and s=
ince SSO is an <i>optimization</i>, it is not mandated by the standard, so =
APIs based on it shouldn't be exposed by the standard either.<br><br>You're=
 probably being tripped up by the current standard's unfortunate reliance o=
n std::basic_string for many APIs, as opposed to something more open. Until=
 std::string_view gets propagated to all appropriate APIs, that will unfort=
unately keep annoying people who can't use basic_string.</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_244_2074879638.1433568343431--
------=_Part_243_906290766.1433568343431--

.

------=_Part_246_19031279.1433568483196
Content-Type: multipart/alternative;
 boundary="----=_Part_247_2031126397.1433568483196"

------=_Part_247_2031126397.1433568483196
Content-Type: text/plain; charset=UTF-8



On Saturday, June 6, 2015 at 12:14:16 PM UTC+7, german...@hubblehome.com
wrote:
>
> Hello everyone,
>
> I would like to know if there would be interest in a proposal for
> detecting when a string allocates in the heap.
>
> The rationale for this is that there are environments in which heap
> allocations should be forbidden,
> but use of short strings can still be made, with the convenience of string
> functions.
> Embedded environments are such an example:
>
>
> A static member function (or free?) could be provided. Something like:
>
> //Pseudo-C++, no basic_string here to go straight to the question
> class string {
>    public:
>        static std::size_t max_stack_allocated_size();
>        static bool needs_dynamic_allocation(std::size_t sz);
> };
>
> I forgot constexpr:

//Pseudo-C++, no basic_string here to go straight to the question
class string {
   public:
       static constexpr std::size_t max_stack_allocated_size();
       static constexpr bool needs_dynamic_allocation(std::size_t sz);
};

--

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

<div dir=3D"ltr"><br><br>On Saturday, June 6, 2015 at 12:14:16 PM UTC+7, ge=
rman...@hubblehome.com wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">Hello everyone,<div><br></div><div>I would like to know if =
there would be interest in a proposal for detecting when a string allocates=
 in the heap.</div><div><br></div><div>The rationale for this is that there=
 are environments in which heap allocations should be forbidden,</div><div>=
but use of short strings can still be made, with the convenience of string =
functions.&nbsp;</div><div>Embedded environments are such an example:</div>=
<div><br></div><div><br></div><div>A static member function (or free?) coul=
d be provided. Something like:</div><div><br></div><div>//Pseudo-C++, no ba=
sic_string here to go straight to the question</div><div>class string {</di=
v><div>&nbsp; &nbsp;public:</div><div>&nbsp; &nbsp; &nbsp; &nbsp;static std=
::size_t max_stack_allocated_size();</div><div>&nbsp; &nbsp; &nbsp; &nbsp;s=
tatic bool needs_dynamic_allocation(std::<wbr>size_t sz);</div><div>};</div=
><div><br></div></div></blockquote><div>I forgot constexpr:</div><div><br><=
/div><div><div>//Pseudo-C++, no basic_string here to go straight to the que=
stion</div><div>class string {</div><div>&nbsp; &nbsp;public:</div><div>&nb=
sp; &nbsp; &nbsp; &nbsp;static constexpr std::size_t max_stack_allocated_si=
ze();</div><div>&nbsp; &nbsp; &nbsp; &nbsp;static constexpr bool needs_dyna=
mic_allocation(std::<wbr>size_t sz);</div><div>};</div></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_247_2031126397.1433568483196--
------=_Part_246_19031279.1433568483196--

.

--Apple-Mail=_CEB1B57A-13C3-495A-A8B0-6009C0AF1DE2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9306=E2=80=9306, at 1:14 PM, german.diago@hubblehome.com wr=
ote:
>=20
> Any interest in this?

If heap allocation is really unimplemented, it=E2=80=99s already called str=
ing::max_size(). And it wouldn=E2=80=99t really be considered an optimizati=
on since there=E2=80=99s no alternative.

Otherwise, I=E2=80=99m not sure what a program would do with it. Chopping t=
he ends off string literals that don=E2=80=99t need to be self-explanatory?=
 Seems like a lot of trouble for little gain.

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

--Apple-Mail=_CEB1B57A-13C3-495A-A8B0-6009C0AF1DE2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9306, at 1:14 PM, <a href=3D"mailto:german.diago@hubblehome.com" cla=
ss=3D"">german.diago@hubblehome.com</a> wrote:</div><br class=3D"Apple-inte=
rchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"=
">Any interest in this?</div></div></div></blockquote><br class=3D""></div>=
<div>If heap allocation is really unimplemented, it=E2=80=99s already calle=
d <font face=3D"Courier" class=3D"">string::max_size()</font>. And it would=
n=E2=80=99t really be considered an optimization since there=E2=80=99s no a=
lternative.</div><div><br class=3D""></div><div>Otherwise, I=E2=80=99m not =
sure what a program would do with it. Chopping the ends off string literals=
 that don=E2=80=99t need to be self-explanatory? Seems like a lot of troubl=
e for little gain.</div></body></html>

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

--Apple-Mail=_CEB1B57A-13C3-495A-A8B0-6009C0AF1DE2--

.

------=_Part_318_358007323.1433573487217
Content-Type: multipart/alternative;
 boundary="----=_Part_319_1927382414.1433573487217"

------=_Part_319_1927382414.1433573487217
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Saturday, June 6, 2015 at 12:36:39 PM UTC+7, David Krauss wrote:
>
>
> On 2015=E2=80=9306=E2=80=9306, at 1:14 PM, german...@hubblehome.com <java=
script:> wrote:
>
> Any interest in this?
>
>
> If heap allocation is really unimplemented, it=E2=80=99s already called=
=20
> string::max_size(). And it wouldn=E2=80=99t really be considered an optim=
ization=20
> since there=E2=80=99s no alternative.
>
> I think this is just an implementation-defined constant. Not sure wether =
I=20
am wrong or not. Is that a lot of work?
=20

> Otherwise, I=E2=80=99m not sure what a program would do with it. Chopping=
 the ends=20
> off string literals that don=E2=80=99t need to be self-explanatory? Seems=
 like a=20
> lot of trouble for little gain.
>

A common use case is to have a lot of short strings. I want to store them=
=20
in std::string (maybe) to have some convenience of the operations it=20
provides. If I do not know wether the string will allocate memory, how can=
=20
I use std::strings in the first place?

But maybe (and maybe only, I am not sure) a std::static_string<N> is a=20
better interface for this.=20

Thanks for your feedback.
=20

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

<div dir=3D"ltr"><br><br>On Saturday, June 6, 2015 at 12:36:39 PM UTC+7, Da=
vid Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D=
"word-wrap:break-word"><br><div><blockquote type=3D"cite"><div>On 2015=E2=
=80=9306=E2=80=9306, at 1:14 PM, <a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"MZKZoV-ZkWUJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">german...@hubblehome.com</a> wrote:</div><br><div><div dir=3D"l=
tr"><div>Any interest in this?</div></div></div></blockquote><br></div><div=
>If heap allocation is really unimplemented, it=E2=80=99s already called <f=
ont face=3D"Courier">string::max_size()</font>. And it wouldn=E2=80=99t rea=
lly be considered an optimization since there=E2=80=99s no alternative.</di=
v><div><br></div></div></blockquote><div>I think this is just an implementa=
tion-defined constant. Not sure wether I am wrong or not. Is that a lot of =
work?</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv style=3D"word-wrap:break-word"><div></div><div>Otherwise, I=E2=80=99m no=
t sure what a program would do with it. Chopping the ends off string litera=
ls that don=E2=80=99t need to be self-explanatory? Seems like a lot of trou=
ble for little gain.</div></div></blockquote><div><br></div><div>A common u=
se case is to have a lot of short strings. I want to store them in std::str=
ing (maybe) to have some convenience of the operations it provides. If I do=
 not know wether the string will allocate memory, how can I use std::string=
s in the first place?</div><div><br></div><div>But maybe (and maybe only, I=
 am not sure) a std::static_string&lt;N&gt; is a better interface for this.=
&nbsp;</div><div><br></div><div>Thanks for your feedback.</div><div>&nbsp;<=
br></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_319_1927382414.1433573487217--
------=_Part_318_358007323.1433573487217--

.

> On Jun 6, 2015, at 1:14 AM, german.diago@hubblehome.com wrote:
>=20
> Hello everyone,
>=20
> I would like to know if there would be interest in a proposal for detecti=
ng when a string allocates in the heap.
>=20
> The rationale for this is that there are environments in which heap alloc=
ations should be forbidden,
> but use of short strings can still be made, with the convenience of strin=
g functions.=20
> Embedded environments are such an example:
>=20
>=20
> A static member function (or free?) could be provided. Something like:
>=20
> //Pseudo-C++, no basic_string here to go straight to the question
> class string {
>    public:
>        static std::size_t max_stack_allocated_size();
>        static bool needs_dynamic_allocation(std::size_t sz);
> };
>=20
> Any interest in this?

If you can live without constexpr, you=E2=80=99ve already got it:

#include <iostream>
#include <string>

template <class String>
std::size_t
max_stack_allocated()
{
    String s;
    return s.capacity();
}

int
main()
{
    std::cout << max_stack_allocated<std::string>() << '\n';
    std::cout << max_stack_allocated<std::wstring>() << '\n';
}

Howard

--=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_1082_1415364901.1433657300545
Content-Type: multipart/alternative;
 boundary="----=_Part_1083_361533288.1433657300546"

------=_Part_1083_361533288.1433657300546
Content-Type: text/plain; charset=UTF-8

The real issue with SSO, in my experience, is a bit more complicated.

What if the std::string implementation doesn't support SSO at the string
lengths you need? Detecting it would at best just let you add a
static_assert telling users that the implementation is unusable. It doesn't
actually fix the problem with the implementation; it just makes it easier
to identify. And once you've rewritten std::string for one implementation,
you might as well just use your version on every implementation so you get
reliable behavior no matter where you go.

If the standard didn't rely on "QoI" here and just set something users can
rely on, we'd all be in a much better place. Just like how graphics APIs
provide implementation-provided upper bounds for many values but mandate a
reliable cross-implementation lower-bound, which is essential to writing
graphics programs that actually work across multiple
implementations/drivers.

An even more general solution would allow the user to specify a traits type
that defined that minimal bound. When we write our own STL replacements we
typically don't bother with such traits, since we can just design to our
specific needs, but the standard library probably wants to be a bit more
widely applicable.

On Friday, June 5, 2015 at 10:14:16 PM UTC-7, german...@hubblehome.com
wrote:
>
> Hello everyone,
>
> I would like to know if there would be interest in a proposal for
> detecting when a string allocates in the heap.
>
> The rationale for this is that there are environments in which heap
> allocations should be forbidden,
> but use of short strings can still be made, with the convenience of string
> functions.
> Embedded environments are such an example:
>
>
> A static member function (or free?) could be provided. Something like:
>
> //Pseudo-C++, no basic_string here to go straight to the question
> class string {
>    public:
>        static std::size_t max_stack_allocated_size();
>        static bool needs_dynamic_allocation(std::size_t sz);
> };
>
> Any interest in this?
>
>
>

--

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

<div dir=3D"ltr">The real issue with SSO, in my experience, is a bit more c=
omplicated.<div><br></div><div>What if the std::string implementation doesn=
't support SSO at the string lengths you need? Detecting it would at best j=
ust let you add a static_assert telling users that the implementation is un=
usable. It doesn't actually fix the problem with the implementation; it jus=
t makes it easier to identify. And once you've rewritten std::string for on=
e implementation, you might as well just use your version on every implemen=
tation so you get reliable behavior no matter where you go.</div><div><br><=
/div><div>If the standard didn't rely on "QoI" here and just set something =
users can rely on, we'd all be in a much better place. Just like how graphi=
cs APIs provide implementation-provided upper bounds for many values but ma=
ndate a reliable cross-implementation lower-bound, which is essential to wr=
iting graphics programs that actually work across multiple implementations/=
drivers.</div><div><br></div><div>An even more general solution would allow=
 the user to specify a traits type that defined that minimal bound. When we=
 write our own STL replacements we typically don't bother with such traits,=
 since we can just design to our specific needs, but the standard library p=
robably wants to be a bit more widely applicable.</div><div><br></div><div>=
On Friday, June 5, 2015 at 10:14:16 PM UTC-7, german...@hubblehome.com wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hello every=
one,<div><br></div><div>I would like to know if there would be interest in =
a proposal for detecting when a string allocates in the heap.</div><div><br=
></div><div>The rationale for this is that there are environments in which =
heap allocations should be forbidden,</div><div>but use of short strings ca=
n still be made, with the convenience of string functions.&nbsp;</div><div>=
Embedded environments are such an example:</div><div><br></div><div><br></d=
iv><div>A static member function (or free?) could be provided. Something li=
ke:</div><div><br></div><div>//Pseudo-C++, no basic_string here to go strai=
ght to the question</div><div>class string {</div><div>&nbsp; &nbsp;public:=
</div><div>&nbsp; &nbsp; &nbsp; &nbsp;static std::size_t max_stack_allocate=
d_size();</div><div>&nbsp; &nbsp; &nbsp; &nbsp;static bool needs_dynamic_al=
location(std::<wbr>size_t sz);</div><div>};</div><div><br></div><div>Any in=
terest in this?</div><div><br></div><div><br></div></div></blockquote></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_1083_361533288.1433657300546--
------=_Part_1082_1415364901.1433657300545--

.

------=_Part_116_2105083771.1433658110271
Content-Type: multipart/alternative;
 boundary="----=_Part_117_349854872.1433658110271"

------=_Part_117_349854872.1433658110271
Content-Type: text/plain; charset=UTF-8

(sorry for the self-reply)

An additional important point is interoperability. Just writing your own
string class is very problematic, even when necessary. If you need to work
around std::string for your environment then you also very likely need to
avoid libraries that use std::string. Which is most of them; that's the
whole point of having a standard string type. string_view will lessen the
problems here to a degree, but certainly not eliminate them.

This is something I've personally run into a lot with games, where some
otherwise very handy library ends up depending on a verboten STL type, or
Boost, or one of the oft verboten C++ features, or ends up working around
the same problems we have by implementing their own non-standard framework
library (and then we'd have to get all these libraries interoperating with
us and each other), and so we can't use the library and have to reimplement
it from scratch as well as the standard types.

It's a domino effect of wasted time and money.

On Saturday, June 6, 2015 at 11:08:20 PM UTC-7, Sean Middleditch wrote:
>
> The real issue with SSO, in my experience, is a bit more complicated.
>
> What if the std::string implementation doesn't support SSO at the string
> lengths you need? Detecting it would at best just let you add a
> static_assert telling users that the implementation is unusable. It doesn't
> actually fix the problem with the implementation; it just makes it easier
> to identify. And once you've rewritten std::string for one implementation,
> you might as well just use your version on every implementation so you get
> reliable behavior no matter where you go.
>
> If the standard didn't rely on "QoI" here and just set something users can
> rely on, we'd all be in a much better place. Just like how graphics APIs
> provide implementation-provided upper bounds for many values but mandate a
> reliable cross-implementation lower-bound, which is essential to writing
> graphics programs that actually work across multiple
> implementations/drivers.
>
> An even more general solution would allow the user to specify a traits
> type that defined that minimal bound. When we write our own STL
> replacements we typically don't bother with such traits, since we can just
> design to our specific needs, but the standard library probably wants to be
> a bit more widely applicable.
>
> On Friday, June 5, 2015 at 10:14:16 PM UTC-7, german...@hubblehome.com
> wrote:
>>
>> Hello everyone,
>>
>> I would like to know if there would be interest in a proposal for
>> detecting when a string allocates in the heap.
>>
>> The rationale for this is that there are environments in which heap
>> allocations should be forbidden,
>> but use of short strings can still be made, with the convenience of
>> string functions.
>> Embedded environments are such an example:
>>
>>
>> A static member function (or free?) could be provided. Something like:
>>
>> //Pseudo-C++, no basic_string here to go straight to the question
>> class string {
>>    public:
>>        static std::size_t max_stack_allocated_size();
>>        static bool needs_dynamic_allocation(std::size_t sz);
>> };
>>
>> Any interest in this?
>>
>>
>>

--

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

<div dir=3D"ltr">(sorry for the self-reply)<div><br></div><div>An additiona=
l important point is interoperability. Just writing your own string class i=
s very problematic, even when necessary. If you need to work around std::st=
ring for your environment then you also very likely need to avoid libraries=
 that use std::string. Which is most of them; that's the whole point of hav=
ing a standard string type. string_view will lessen the problems here to a =
degree, but certainly not eliminate them.</div><div><br></div><div>This is =
something I've personally run into a lot with games, where some otherwise v=
ery handy library ends up depending on a verboten STL type, or Boost, or on=
e of the oft verboten C++ features, or ends up working around the same prob=
lems we have by implementing their own non-standard framework library (and =
then we'd have to get all these libraries interoperating with us and each o=
ther), and so we can't use the library and have to reimplement it from scra=
tch as well as the standard types.</div><div><br></div><div>It's a domino e=
ffect of wasted time and money.</div><div><br>On Saturday, June 6, 2015 at =
11:08:20 PM UTC-7, Sean Middleditch wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr">The real issue with SSO, in my experience, is =
a bit more complicated.<div><br></div><div>What if the std::string implemen=
tation doesn't support SSO at the string lengths you need? Detecting it wou=
ld at best just let you add a static_assert telling users that the implemen=
tation is unusable. It doesn't actually fix the problem with the implementa=
tion; it just makes it easier to identify. And once you've rewritten std::s=
tring for one implementation, you might as well just use your version on ev=
ery implementation so you get reliable behavior no matter where you go.</di=
v><div><br></div><div>If the standard didn't rely on "QoI" here and just se=
t something users can rely on, we'd all be in a much better place. Just lik=
e how graphics APIs provide implementation-provided upper bounds for many v=
alues but mandate a reliable cross-implementation lower-bound, which is ess=
ential to writing graphics programs that actually work across multiple impl=
ementations/drivers.</div><div><br></div><div>An even more general solution=
 would allow the user to specify a traits type that defined that minimal bo=
und. When we write our own STL replacements we typically don't bother with =
such traits, since we can just design to our specific needs, but the standa=
rd library probably wants to be a bit more widely applicable.</div><div><br=
></div><div>On Friday, June 5, 2015 at 10:14:16 PM UTC-7, <a>german...@hubb=
lehome.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">Hello everyone,<div><br></div><div>I would like to know if there would b=
e interest in a proposal for detecting when a string allocates in the heap.=
</div><div><br></div><div>The rationale for this is that there are environm=
ents in which heap allocations should be forbidden,</div><div>but use of sh=
ort strings can still be made, with the convenience of string functions.&nb=
sp;</div><div>Embedded environments are such an example:</div><div><br></di=
v><div><br></div><div>A static member function (or free?) could be provided=
.. Something like:</div><div><br></div><div>//Pseudo-C++, no basic_string he=
re to go straight to the question</div><div>class string {</div><div>&nbsp;=
 &nbsp;public:</div><div>&nbsp; &nbsp; &nbsp; &nbsp;static std::size_t max_=
stack_allocated_size();</div><div>&nbsp; &nbsp; &nbsp; &nbsp;static bool ne=
eds_dynamic_allocation(std::<wbr>size_t sz);</div><div>};</div><div><br></d=
iv><div>Any interest in this?</div><div><br></div><div><br></div></div></bl=
ockquote></div></div></blockquote></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_117_349854872.1433658110271--
------=_Part_116_2105083771.1433658110271--

.

------=_Part_1119_157879467.1433660245863
Content-Type: multipart/alternative;
 boundary="----=_Part_1120_1337897824.1433660245863"

------=_Part_1120_1337897824.1433660245863
Content-Type: text/plain; charset=UTF-8

On Sunday, June 7, 2015 at 2:08:20 AM UTC-4, Sean Middleditch wrote:
>
> The real issue with SSO, in my experience, is a bit more complicated.
>
> What if the std::string implementation doesn't support SSO at the string
> lengths you need? Detecting it would at best just let you add a
> static_assert telling users that the implementation is unusable. It doesn't
> actually fix the problem with the implementation; it just makes it easier
> to identify. And once you've rewritten std::string for one implementation,
> you might as well just use your version on every implementation so you get
> reliable behavior no matter where you go.
>
> If the standard didn't rely on "QoI" here and just set something users can
> rely on, we'd all be in a much better place. Just like how graphics APIs
> provide implementation-provided upper bounds for many values but mandate a
> reliable cross-implementation lower-bound, which is essential to writing
> graphics programs that actually work across multiple
> implementations/drivers.
>

OK, imagine if, in 1998, the standards committee took your advice. Let's
say they decided to formalize a "QoI" feature of std::basic_string by, not
merely allowing it, but *requiring* it.

Only that optimization was copy-on-write, not SSO.

Remember: back then, we didn't know SSO was a good idea. Back then, CoW
sounded far more like the reasonable solution to so many string problems.
It was quite an optimization.

Back then.

The world has changed a lot in the 20+ years since then. What happens if
another shift takes place, and SSO goes from being an optimization to a
pessimization like CoW did? Now, all your standardization of that
implementation does is force the string type to be weakened.

The standard's committee should not be in the business of predicting the
future. Especially considering how bad they are at it.


> An even more general solution would allow the user to specify a traits
> type that defined that minimal bound. When we write our own STL
> replacements we typically don't bother with such traits, since we can just
> design to our specific needs, but the standard library probably wants to be
> a bit more widely applicable.
>

The standard library is already "widely applicable". That it is not
*universally* applicable is not a bug; it's a feature. It allows the
standard library to be relatively simple to use, to not have a bunch of
arbitrary tweaks for minor things that 99% of users won't care about.

The last thing we need is a bunch of arbitrary policies added on to our
types.

On Sunday, June 7, 2015 at 2:21:50 AM UTC-4, Sean Middleditch wrote:
>
> (sorry for the self-reply)
>
> An additional important point is interoperability. Just writing your own
> string class is very problematic, even when necessary. If you need to work
> around std::string for your environment then you also very likely need to
> avoid libraries that use std::string. Which is most of them; that's the
> whole point of having a standard string type. string_view will lessen the
> problems here to a degree, but certainly not eliminate them.
>

"to a degree"? How about "mostly"?

Oh sure, `string_view` won't magically make all existing uses of
std::string in APIs transform into std::string_view. But the option would
now exist. And most APIs don't actually care about the *storage* for a
string; it only needs to read the data. So most APIs that take std::string
or some similar string can very easily have overloads that take
std::string_view.

So, with appropriate code updates, you will have eliminated about 90% of
such interop problems. The remaining 10% can be divided into these
categories:

1) Functions that return std::string.

2) Functions that "return" std::string by parameter.

3) Functions that modify the contents of a std::string.

#1 and #2 can't be changed; you have to pick *some* type to use to handle
the storage of a string. And many users will pick std::string because...
it's there. Even if they picked the string type you like, that may not be
the string type other people like. And trying to design an "omni_string",
which is all things to all people, is a trail that ends in tears.

#3 generally can't be changed either. Most of such functions require the
insertion or deletions of characters. Even seemingly simple modifications
like upper/lowercase changes are impossible to do in Unicode without being
able to insert/delete characters. Even in UTF-32, there are codepoint
sequences which are considered one case, that map to a single codepoint in
another case.

I'd say the 90% interoperability that std::string_view gives you is the
best you can reasonably expect to get. Take it and move on.

It should also be noted that your attempt at a bunch of policies for
std::basic_string wouldn't work for interop anyway. At least, not without
copying. If the library uses a 16-character SSO std::string, but you use a
32-character one, you have to copy when crossing that boundary. That's just
as true as if it were using a different allocator on its std::string.


> This is something I've personally run into a lot with games, where some
> otherwise very handy library ends up depending on a verboten STL type, or
> Boost, or one of the oft verboten C++ features, or ends up working around
> the same problems we have by implementing their own non-standard framework
> library (and then we'd have to get all these libraries interoperating with
> us and each other), and so we can't use the library and have to reimplement
> it from scratch as well as the standard types.
>
> It's a domino effect of wasted time and money.
>

This is *your* problem, not C++'s.

Your problem is that you aren't writing C++ code; you're writing to some
!C++ language, which is a functional subset of C++. That's all well and
good, but the rest of us *don't* live in your little box. And if you expect
us to do so, you'll be waiting a while.

I understand that you didn't necessarily choose your programming
environment. But at the end of the day, you can't complain that some C++
library's writer dared to actually *use C++* in their code, rather than the
arbitrary subset you're limited to.

If you are allergic to Boost, that's something I can understand. But by
rejecting it, you are rejecting every library that uses it as a dependency.
And that's a lot of code. That was the choice you made when you rejected
it, and you should have considered that when making that choice (assuming
the choice wasn't made for you). The same goes for any other "oft verboten
C++ features" (FYI: Just because something is 'oft' for you doesn't make it
'oft' for everyone else too).

People who actually use the language in their code is not a problem that
the language needs to solve. It's only "a domino effect of wasted time and
money" for those who have arbitrary limits placed on what parts of the
language they can use. And while I empathize with you, complaining about it
or requesting features to "correct" this "problem" is the wrong way to go
about it.

--

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

<div dir=3D"ltr">On Sunday, June 7, 2015 at 2:08:20 AM UTC-4, Sean Middledi=
tch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">The=
 real issue with SSO, in my experience, is a bit more complicated.<div><br>=
</div><div>What
 if the std::string implementation doesn't support SSO at the string=20
lengths you need? Detecting it would at best just let you add a=20
static_assert telling users that the implementation is unusable. It=20
doesn't actually fix the problem with the implementation; it just makes=20
it easier to identify. And once you've rewritten std::string for one=20
implementation, you might as well just use your version on every=20
implementation so you get reliable behavior no matter where you go.</div><d=
iv><br></div><div>If
 the standard didn't rely on "QoI" here and just set something users can
 rely on, we'd all be in a much better place. Just like how graphics=20
APIs provide implementation-provided upper bounds for many values but=20
mandate a reliable cross-implementation lower-bound, which is essential=20
to writing graphics programs that actually work across multiple=20
implementations/drivers.</div></div></blockquote><div><br>OK, imagine=20
if, in 1998, the standards committee took your advice. Let's say they=20
decided to formalize a "QoI" feature of std::basic_string by, not merely al=
lowing it, but <i>requiring</i> it.<br><br>Only that optimization was copy-=
on-write, not SSO.<br><br>Remember:
 back then, we didn't know SSO was a good idea. Back then, CoW sounded=20
far more like the reasonable solution to so many string problems. It was
 quite an optimization.<br><br>Back then.<br><br>The world has changed a lo=
t in the 20+=20
years since then. What happens if another shift takes place, and SSO=20
goes from being an optimization to a pessimization like CoW did? Now,=20
all your standardization of that implementation does is force the string
 type to be weakened.<br><br>The standard's committee should not be in the =
business of predicting the future. Especially considering how bad they are =
at it.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>An
 even more general solution would allow the user to specify a traits=20
type that defined that minimal bound. When we write our own STL=20
replacements we typically don't bother with such traits, since we can=20
just design to our specific needs, but the standard library probably=20
wants to be a bit more widely applicable.</div></div></blockquote><br>The s=
tandard library is already "widely applicable". That it is not <i>universal=
ly</i>
 applicable is not a bug; it's a feature. It allows the standard library
 to be relatively simple to use, to not have a bunch of arbitrary tweaks
 for minor things that 99% of users won't care about.<br><br>The last thing=
 we need is a bunch of arbitrary policies added on to our types.<br><br>On =
Sunday, June 7, 2015 at 2:21:50 AM UTC-4, Sean Middleditch wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">(sorry for the self-rep=
ly)<div><br></div><div>An additional important point is interoperability. J=
ust writing your own string class is very problematic, even when necessary.=
 If you need to work around std::string for your environment then you also =
very likely need to avoid libraries that use std::string. Which is most of =
them; that's the whole point of having a standard string type. string_view =
will lessen the problems here to a degree, but certainly not eliminate them=
..</div></div></blockquote><div><br>"to a degree"? How about "mostly"?<br><b=
r>Oh sure, `string_view` won't magically make all existing uses of std::str=
ing in APIs transform into std::string_view. But the option would now exist=
.. And most APIs don't actually care about the <i>storage</i> for a string; =
it only needs to read the data. So most APIs that take std::string or some =
similar string can very easily have overloads that take std::string_view.<b=
r><br>So, with appropriate code updates, you will have eliminated about 90%=
 of such interop problems. The remaining 10% can be divided into these cate=
gories:<br><br>1) Functions that return std::string.<br><br>2) Functions th=
at "return" std::string by parameter.<br><br>3) Functions that modify the c=
ontents of a std::string.<br><br>#1 and #2 can't be changed; you have to pi=
ck <i>some</i> type to use to handle the storage of a string. And many user=
s will pick std::string because... it's there. Even if they picked the stri=
ng type you like, that may not be the string type other people like. And tr=
ying to design an "omni_string", which is all things to all people, is a tr=
ail that ends in tears.<br><br>#3 generally can't be changed either. Most o=
f such functions require the insertion or deletions of characters. Even see=
mingly simple modifications like upper/lowercase changes are impossible to =
do in Unicode without being able to insert/delete characters. Even in UTF-3=
2, there are codepoint sequences which are considered one case, that map to=
 a single codepoint in another case.<br><br>I'd say the 90% interoperabilit=
y that std::string_view gives you is the best you can reasonably expect to =
get. Take it and move on.<br><br>It should also be noted that your attempt =
at a bunch of policies for std::basic_string wouldn't work for interop anyw=
ay. At least, not without copying. If the library uses a 16-character SSO s=
td::string, but you use a 32-character one, you have to copy when crossing =
that boundary. That's just as true as if it were using a different allocato=
r on its std::string.<br>&nbsp;</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><div></div><div>This is something I've personally r=
un into a lot with games, where some otherwise very handy library ends up d=
epending on a verboten STL type, or Boost, or one of the oft verboten C++ f=
eatures, or ends up working around the same problems we have by implementin=
g their own non-standard framework library (and then we'd have to get all t=
hese libraries interoperating with us and each other), and so we can't use =
the library and have to reimplement it from scratch as well as the standard=
 types.</div><div><br></div><div>It's a domino effect of wasted time and mo=
ney.</div></div></blockquote><div><br>This is <i>your</i> problem, not C++'=
s.<br><br>Your problem is that you aren't writing C++ code; you're writing =
to some !C++ language, which is a functional subset of C++. That's all well=
 and good, but the rest of us <i>don't</i> live in your little box. And if =
you expect us to do so, you'll be waiting a while.<br><br>I understand that=
 you didn't necessarily choose your programming environment. But at the end=
 of the day, you can't complain that some C++ library's writer dared to act=
ually <i>use C++</i> in their code, rather than the arbitrary subset you're=
 limited to.<br><br>If you are allergic to Boost, that's something I can un=
derstand. But by rejecting it, you are rejecting every library that uses it=
 as a dependency. And that's a lot of code. That was the choice you made wh=
en you rejected it, and you should have considered that when making that ch=
oice (assuming the choice wasn't made for you). The same goes for any other=
 "oft verboten C++ features" (FYI: Just because something is 'oft' for you =
doesn't make it 'oft' for everyone else too).<br><br>People who actually us=
e the language in their code is not a problem that the language needs to so=
lve. It's only "a domino effect of wasted time and money" for those who hav=
e arbitrary limits placed on what parts of the language they can use. And w=
hile I empathize with you, complaining about it or requesting features to "=
correct" this "problem" is the wrong way to go about it.<br></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_1120_1337897824.1433660245863--
------=_Part_1119_157879467.1433660245863--

.

------=_Part_1017_1620296976.1433664937751
Content-Type: multipart/alternative;
 boundary="----=_Part_1018_91148025.1433664937751"

------=_Part_1018_91148025.1433664937751
Content-Type: text/plain; charset=UTF-8

On Saturday, June 6, 2015 at 11:57:25 PM UTC-7, Nicol Bolas wrote:
>
> On Sunday, June 7, 2015 at 2:08:20 AM UTC-4, Sean Middleditch wrote:
>>
>> The real issue with SSO, in my experience, is a bit more complicated.
>>
>> What if the std::string implementation doesn't support SSO at the string
>> lengths you need? Detecting it would at best just let you add a
>> static_assert telling users that the implementation is unusable. It doesn't
>> actually fix the problem with the implementation; it just makes it easier
>> to identify. And once you've rewritten std::string for one implementation,
>> you might as well just use your version on every implementation so you get
>> reliable behavior no matter where you go.
>>
>> If the standard didn't rely on "QoI" here and just set something users
>> can rely on, we'd all be in a much better place. Just like how graphics
>> APIs provide implementation-provided upper bounds for many values but
>> mandate a reliable cross-implementation lower-bound, which is essential to
>> writing graphics programs that actually work across multiple
>> implementations/drivers.
>>
>
> OK, imagine if, in 1998, the standards committee took your advice. Let's
> say they decided to formalize a "QoI" feature of std::basic_string by, not
> merely allowing it, but *requiring* it.
>
> Only that optimization was copy-on-write, not SSO.
>

Mistakes can happen. That doesn't mean that we should never make a change
again. Nor does it imply that mistakes can't be fixed. It absolutely does
not mean that we should not even talk about problems or ways to fix them.

I am somewhat amused by your chosen example. :)


> This is *your* problem, not C++'s.
>

C++ is a tool. Tools are meant to solve problems. Including common problems
frequently encountered in the HPC, games, financial, embedded, aeronautics,
real-time, etc. industries. That they aren't problems you encounter doesn't
mean that they aren't problems.


> Your problem is that you aren't writing C++ code; you're writing to some
> !C++ language, which is a functional subset of C++. That's all well and
> good, but the rest of us *don't* live in your little box. And if you
> expect us to do so, you'll be waiting a while.
>

I never once suggested you live in said "sandbox." I honestly don't care
where you live, and I certainly don't want to force you to move. I've done
nothing to indicate otherwise that I can recall.

I merely wish that the committee acknowledge that our needs exist, that we
are an important target market for C++ (if not you), and that tweaks and
changes can be made to stop being as problematic. Which they're starting to
do, in no small part because people have the audacity to actually talk
about the problems on this list.


> I understand that you didn't necessarily choose your programming
> environment. But at the end of the day, you can't complain that some C++
> library's writer dared to actually *use C++* in their code, rather than
> the arbitrary subset you're limited to.
>

That's... pretty much my point. Thanks?


> If you are allergic to Boost, that's something I can understand. But by
> rejecting it, you are rejecting every library that uses it as a dependency.
> And that's a lot of code. That was the choice you made when you rejected it
>

Indubitably. _Of course_ there's trade-offs. Obviously.

Pretty much every C++ library (save those explicitly written for games or
embedded, tellingly) depend on std::string.

Not nearly as many depend on Boost. Pretty key difference.

Having to avoid Boost is certainly not a problem which I expect the C++
committee to be concerned with addressing (though I expect them to
understand _why_ we make those decisions).

Having to avoid core types shipped with the bloody standard _is_ damn well
a problem I expect the committee to be concerned with.

It's not like it's just me. This isn't a one-off case or a personal
requirement. This is user after user, company after company, industry after
industry running into these requirements and the problems caused by the
standard's shortcomings. Often easily-fixed shortcomings.

Which is why we're here, talking about the problems, brainstorming
solutions, and eventually formally proposing changes.

--

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

<div dir=3D"ltr">On Saturday, June 6, 2015 at 11:57:25 PM UTC-7, Nicol Bola=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Su=
nday, June 7, 2015 at 2:08:20 AM UTC-4, Sean Middleditch wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">The real issue with SSO, in my=
 experience, is a bit more complicated.<div><br></div><div>What
 if the std::string implementation doesn't support SSO at the string=20
lengths you need? Detecting it would at best just let you add a=20
static_assert telling users that the implementation is unusable. It=20
doesn't actually fix the problem with the implementation; it just makes=20
it easier to identify. And once you've rewritten std::string for one=20
implementation, you might as well just use your version on every=20
implementation so you get reliable behavior no matter where you go.</div><d=
iv><br></div><div>If
 the standard didn't rely on "QoI" here and just set something users can
 rely on, we'd all be in a much better place. Just like how graphics=20
APIs provide implementation-provided upper bounds for many values but=20
mandate a reliable cross-implementation lower-bound, which is essential=20
to writing graphics programs that actually work across multiple=20
implementations/drivers.</div></div></blockquote><div><br>OK, imagine=20
if, in 1998, the standards committee took your advice. Let's say they=20
decided to formalize a "QoI" feature of std::basic_string by, not merely al=
lowing it, but <i>requiring</i> it.<br><br>Only that optimization was copy-=
on-write, not SSO.<br></div></div></blockquote><div><br></div><div>Mistakes=
 can happen. That doesn't mean that we should never make a change again. No=
r does it imply that mistakes can't be fixed. It absolutely does not mean t=
hat we should not even talk about problems or ways to fix them.</div><div><=
br></div><div>I am somewhat amused by your chosen example. :)</div><div>&nb=
sp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>This is <i>your</i> problem, not C++'s.<br></div></div></blockquote><d=
iv><br></div><div>C++ is a tool. Tools are meant to solve problems. Includi=
ng common problems frequently encountered in the HPC, games, financial, emb=
edded, aeronautics, real-time, etc. industries. That they aren't problems y=
ou encounter doesn't mean that they aren't problems.</div><div>&nbsp;</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Your pro=
blem is that you aren't writing C++ code; you're writing to some !C++ langu=
age, which is a functional subset of C++. That's all well and good, but the=
 rest of us <i>don't</i> live in your little box. And if you expect us to d=
o so, you'll be waiting a while.<br></div></div></blockquote><div><br></div=
><div>I never once suggested you live in said "sandbox." I honestly don't c=
are where you live, and I certainly don't want to force you to move. I've d=
one nothing to indicate otherwise that I can recall.</div><div><br></div><d=
iv>I merely wish that the committee acknowledge that our needs exist, that =
we are an important target market for C++ (if not you), and that tweaks and=
 changes can be made to stop being as problematic. Which they're starting t=
o do, in no small part because people have the audacity to actually talk ab=
out the problems on this list.</div><div>&nbsp;<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 dir=3D"ltr"><div>I understand that you did=
n't necessarily choose your programming environment. But at the end of the =
day, you can't complain that some C++ library's writer dared to actually <i=
>use C++</i> in their code, rather than the arbitrary subset you're limited=
 to.<br></div></div></blockquote><div><br></div><div>That's... pretty much =
my point. Thanks?</div><div>&nbsp;<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div>If you are allergic to Boost, that's so=
mething I can understand. But by rejecting it, you are rejecting every libr=
ary that uses it as a dependency. And that's a lot of code. That was the ch=
oice you made when you rejected it</div></div></blockquote><div><br></div><=
div>Indubitably. _Of course_ there's trade-offs. Obviously.<br></div><div><=
br></div><div>Pretty much every C++ library (save those explicitly written =
for games or embedded, tellingly) depend on std::string.</div><div><br></di=
v><div>Not nearly as many depend on Boost. Pretty key difference.</div><div=
><br></div><div>Having to avoid Boost is certainly not a problem which I ex=
pect the C++ committee to be concerned with addressing (though I expect the=
m to understand _why_ we make those decisions).</div><div><br></div><div>Ha=
ving to avoid core types shipped with the bloody standard _is_ damn well a =
problem I expect the committee to be concerned with.</div><div><br></div><d=
iv>It's not like it's just me. This isn't a one-off case or a personal requ=
irement. This is user after user, company after company, industry after ind=
ustry running into these requirements and the problems caused by the standa=
rd's shortcomings. Often easily-fixed shortcomings.</div><div><br></div><di=
v>Which is why we're here, talking about the problems, brainstorming soluti=
ons, and eventually formally proposing changes.</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_1018_91148025.1433664937751--
------=_Part_1017_1620296976.1433664937751--

.

------=_Part_1025_257499667.1433674452283
Content-Type: multipart/alternative;
 boundary="----=_Part_1026_617354564.1433674452283"

------=_Part_1026_617354564.1433674452283
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sunday, June 7, 2015 at 4:15:37 AM UTC-4, Sean Middleditch wrote:
>
> On Saturday, June 6, 2015 at 11:57:25 PM UTC-7, Nicol Bolas wrote:
>>
>> On Sunday, June 7, 2015 at 2:08:20 AM UTC-4, Sean Middleditch wrote:
>>>
>>> The real issue with SSO, in my experience, is a bit more complicated.
>>>
>>> What if the std::string implementation doesn't support SSO at the strin=
g=20
>>> lengths you need? Detecting it would at best just let you add a=20
>>> static_assert telling users that the implementation is unusable. It doe=
sn't=20
>>> actually fix the problem with the implementation; it just makes it easi=
er=20
>>> to identify. And once you've rewritten std::string for one implementati=
on,=20
>>> you might as well just use your version on every implementation so you =
get=20
>>> reliable behavior no matter where you go.
>>>
>>> If the standard didn't rely on "QoI" here and just set something users=
=20
>>> can rely on, we'd all be in a much better place. Just like how graphics=
=20
>>> APIs provide implementation-provided upper bounds for many values but=
=20
>>> mandate a reliable cross-implementation lower-bound, which is essential=
 to=20
>>> writing graphics programs that actually work across multiple=20
>>> implementations/drivers.
>>>
>>
>> OK, imagine if, in 1998, the standards committee took your advice. Let's=
=20
>> say they decided to formalize a "QoI" feature of std::basic_string by, n=
ot=20
>> merely allowing it, but *requiring* it.
>>
>> Only that optimization was copy-on-write, not SSO.
>>
>
> Mistakes can happen. That doesn't mean that we should never make a change=
=20
> again. Nor does it imply that mistakes can't be fixed. It absolutely does=
=20
> not mean that we should not even talk about problems or ways to fix them.
>

Actually, you wouldn't be able to "fix" them. In either case.

If basic_string had enforced COW semantics from 1998 onward, there would be=
=20
no way to change this in 2011 without breaking *lots* of people. The only=
=20
"fix" for it would be to create yet another string type, and that's not a=
=20
fix.

And that's exactly why you can't do this kind of thing. Because if you get=
=20
it wrong, you're basically screwed forever.

It took C++ 6 years to get rid of auto_ptr (assuming C++17 ships on-time=20
with that change). And that was a class that pretty much nobody used, which=
=20
had an immediate drop-in replacement in C++11. How long do you think it=20
would take to get rid of a bad std::string?

Your problem is that you aren't writing C++ code; you're writing to some=20
>> !C++ language, which is a functional subset of C++. That's all well and=
=20
>> good, but the rest of us *don't* live in your little box. And if you=20
>> expect us to do so, you'll be waiting a while.
>>
>
> I never once suggested you live in said "sandbox." I honestly don't care=
=20
> where you live, and I certainly don't want to force you to move. I've don=
e=20
> nothing to indicate otherwise that I can recall.
>

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

Whether it is your intent or not, it has the effect of putting more people=
=20
in your box, even if only by legitimizing it. And that is something I hope=
=20
the committee never does.

I merely wish that the committee acknowledge that our needs exist, that we=
=20
> are an important target market for C++ (if not you),
>

I'm quite certain the committee understands that...
=20

> and that tweaks and changes can be made to stop being as problematic.
>

But what you're asking for *here* is not a "tweak". This isn't like asking=
=20
for `vector::capacity` to actually be respected (which, BTW, it totally=20
should be). You're talking about forcing what was an optimization to be a=
=20
requirement. Not only that, you're talking about making it *configurable.*

That's not a "tweak" anymore; that's a pretty sizable change to the very=20
nature of the class. Especially to a class that, as you put it, "Pretty=20
much every C++ library (...) depend on std::string." Which means that it=20
can hurt a lot of people if you get it wrong.
=20

> Which they're starting to do, in no small part because people have the=20
> audacity to actually talk about the problems on this list.
> =20
>
>> If you are allergic to Boost, that's something I can understand. But by=
=20
>> rejecting it, you are rejecting every library that uses it as a dependen=
cy.=20
>> And that's a lot of code. That was the choice you made when you rejected=
 it
>>
>
> Indubitably. _Of course_ there's trade-offs. Obviously.
>
> Pretty much every C++ library (save those explicitly written for games or=
=20
> embedded, tellingly) depend on std::string.
>
> Not nearly as many depend on Boost. Pretty key difference.
>
> Having to avoid Boost is certainly not a problem which I expect the C++=
=20
> committee to be concerned with addressing (though I expect them to=20
> understand _why_ we make those decisions).
>
> Having to avoid core types shipped with the bloody standard _is_ damn wel=
l=20
> a problem I expect the committee to be concerned with.
>

Specialized needs require specialized tools.

However, there is a way to give specialized tools a bit more=20
standardization than some library on GitHub: Technical Specifications.=20
Maybe SG-14 should focus on a TS that includes various features=20
(stand-alone, that don't affect existing types). A string class with=20
configurable SSO, etc. That way, even if the committee as a whole balks or=
=20
only wants to adopt some of it, the rest could still be published and=20
implemented as a TS.
=20

> It's not like it's just me. This isn't a one-off case or a personal=20
> requirement. This is user after user, company after company, industry aft=
er=20
> industry running into these requirements and the problems caused by the=
=20
> standard's shortcomings. Often easily-fixed shortcomings.
>

Except what you call "easily-fixed" causes a number of previously discussed=
=20
problems. You *decrease* interop, because different users will request=20
different sizes, which will require a copy. You increase the complexity of=
=20
basic_string, all for the use of a relative minority of users who rely on=
=20
SSO yet cannot write their own string type.

Look, I'm all for SG-14's general goal. I would have liked to see elements=
=20
of EASTL show up in C++11. I'd love to see flat_set/maps, noexcept=20
container moves where possible, and similar features. But there are many=20
things that really are specialized needs. Those that I mentioned=20
specifically are ones that more or less everyone could use and benefit from=
..

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

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

<div dir=3D"ltr">On Sunday, June 7, 2015 at 4:15:37 AM UTC-4, Sean Middledi=
tch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On =
Saturday, June 6, 2015 at 11:57:25 PM UTC-7, Nicol Bolas wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, June 7, 2015 at 2:0=
8:20 AM UTC-4, Sean Middleditch wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">The real issue with SSO, in my experience, is a bit mor=
e complicated.<div><br></div><div>What
 if the std::string implementation doesn't support SSO at the string=20
lengths you need? Detecting it would at best just let you add a=20
static_assert telling users that the implementation is unusable. It=20
doesn't actually fix the problem with the implementation; it just makes=20
it easier to identify. And once you've rewritten std::string for one=20
implementation, you might as well just use your version on every=20
implementation so you get reliable behavior no matter where you go.</div><d=
iv><br></div><div>If
 the standard didn't rely on "QoI" here and just set something users can
 rely on, we'd all be in a much better place. Just like how graphics=20
APIs provide implementation-provided upper bounds for many values but=20
mandate a reliable cross-implementation lower-bound, which is essential=20
to writing graphics programs that actually work across multiple=20
implementations/drivers.</div></div></blockquote><div><br>OK, imagine=20
if, in 1998, the standards committee took your advice. Let's say they=20
decided to formalize a "QoI" feature of std::basic_string by, not merely al=
lowing it, but <i>requiring</i> it.<br><br>Only that optimization was copy-=
on-write, not SSO.<br></div></div></blockquote><div><br></div><div>Mistakes=
 can happen. That doesn't mean that we should never make a change again. No=
r does it imply that mistakes can't be fixed. It absolutely does not mean t=
hat we should not even talk about problems or ways to fix them.</div></div>=
</blockquote><div><br>Actually, you wouldn't be able to "fix" them. In eith=
er case.<br><br>If basic_string had enforced COW semantics from 1998 onward=
, there would be no way to change this in 2011 without breaking <i>lots</i>=
 of people. The only "fix" for it would be to create yet another string typ=
e, and that's not a fix.<br><br>And that's exactly why you can't do this ki=
nd of thing. Because if you get it wrong, you're basically screwed forever.=
<br><br>It took C++ 6 years to get rid of auto_ptr (assuming C++17 ships on=
-time with that change). And that was a class that pretty much nobody used,=
 which 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?<br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>Your problem is that you aren=
't writing C++ code; you're writing to some !C++ language, which is a funct=
ional subset of C++. That's all well and good, but the rest of us <i>don't<=
/i> live in your little box. And if you expect us to do so, you'll be waiti=
ng a while.<br></div></div></blockquote><div><br></div><div>I never once su=
ggested you live in said "sandbox." I honestly don't care where you live, a=
nd I certainly don't want to force you to move. I've done nothing to indica=
te otherwise that I can recall.</div></div></blockquote><div><br>You want t=
o change the standard to make your preferred subset (-=C2=ADfno=C2=ADexcept=
ions, -=C2=ADfno=C2=ADrtti) actually a supported element of the standard. T=
hat's basically a red flag to C++ programmers saying "<i>Don't use these fe=
atures!</i>"<br><br>Whether it is your intent or not, it has the effect of =
putting more people in your box, even if only by legitimizing it. And that =
is something I hope the committee never does.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>I merely wish that the c=
ommittee acknowledge that our needs exist, that we are an important target =
market for C++ (if not you),</div></div></blockquote><div><br>I'm quite cer=
tain the committee understands that...<br>&nbsp;</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div>and that tweaks and changes c=
an be made to stop being as problematic.</div></div></blockquote><div><br>B=
ut what you're asking for <i>here</i> is not a "tweak". This isn't like ask=
ing for `vector::capacity` to actually be respected (which, BTW, it totally=
 should be). You're talking about forcing what was an optimization to be a =
requirement. Not only that, you're talking about making it <i>configurable.=
</i><br><br>That's not a "tweak" anymore; that's a pretty sizable change to=
 the very nature of the class. Especially to a class that, as you put it, "=
Pretty much every C++ library (...) depend on std::string." Which means tha=
t it can hurt a lot of people if you get it wrong.<br>&nbsp;</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Which they're sta=
rting to do, in no small part because people have the audacity to actually =
talk about the problems on this list.</div><div>&nbsp;<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>If you are allergic to B=
oost, that's something I can understand. But by rejecting it, you are rejec=
ting every library that uses it as a dependency. And that's a lot of code. =
That was the choice you made when you rejected it</div></div></blockquote><=
div><br></div><div>Indubitably. _Of course_ there's trade-offs. Obviously.<=
br></div><div><br></div><div>Pretty much every C++ library (save those expl=
icitly written for games or embedded, tellingly) depend on std::string.</di=
v><div><br></div><div>Not nearly as many depend on Boost. Pretty key differ=
ence.</div><div><br></div><div>Having to avoid Boost is certainly not a pro=
blem which I expect the C++ committee to be concerned with addressing (thou=
gh I expect them to understand _why_ we make those decisions).</div><div><b=
r></div><div>Having to avoid core types shipped with the bloody standard _i=
s_ damn well a problem I expect the committee to be concerned with.</div></=
div></blockquote><div><br>Specialized needs require specialized tools.<br><=
br>However, there is a way to give specialized tools a bit more standardiza=
tion than some library on GitHub: Technical Specifications. Maybe SG-14 sho=
uld focus on a TS that includes various features (stand-alone, that don't a=
ffect existing types). A string class with configurable SSO, etc. That way,=
 even if the committee as a whole balks or only wants to adopt some of it, =
the rest could still be published and implemented as a TS.<br>&nbsp;</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>It's not =
like it's just me. This isn't a one-off case or a personal requirement. Thi=
s is user after user, company after company, industry after industry runnin=
g into these requirements and the problems caused by the standard's shortco=
mings. Often easily-fixed shortcomings.</div></div></blockquote><div><br>Ex=
cept what you call "easily-fixed" causes a number of previously discussed p=
roblems. You <i>decrease</i> interop, because different users will request =
different sizes, which will require a copy. You increase the complexity of =
basic_string, all for the use of a relative minority of users who rely on S=
SO yet cannot write their own string type.<br><br>Look, I'm all for SG-14's=
 general goal. I would have liked to see elements of EASTL show up in C++11=
.. I'd love to see flat_set/maps, noexcept container moves where possible, a=
nd similar features. But there are many things that really are specialized =
needs. Those that I mentioned specifically are ones that more or less every=
one could use and benefit from.<br><br>But like language vivisection (ie: s=
tandard support for not having RTTI or exceptions) and enforced/configurabl=
e SSO? Those are specialized needs. They benefit a limited selection of C++=
 programmers.<br></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_1026_617354564.1433674452283--
------=_Part_1025_257499667.1433674452283--

.

On Jun 7, 2015, at 6:54 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> It took C++ 6 years to get rid of auto_ptr (assuming C++17 ships on-time with that change).

<nitpick> Umm... the fight to get rid of auto_ptr started here:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#move_ptr%20Example

It took 15 years. ;-)

Howard

--

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

.