On Friday 27 February 2015 18:50:32 Matthew Fioravante wrote:
> Having a way to constexpr construct data structures is very useful when you
> want to make a global data structure because it eliminates the static
> initialization order race condition.

Note that it does not eliminate load-time impacts, since the destructors for
those types can't be constexpr, which means the compiler must register the
destruction with atexit() or similar function.

> At a minimum if at least vector, unordered_map, and string have constexpr
> default constructors if its possible would be enough for a lot of use cases.
>
> Assuming the underlying allocator constructor is constexpr, vector seems
> pretty straightforward. No sane vector implementation should be
> speculatively allocating memory in the default constructor anyway.
>
> string should be simple as well, especially with the SSO.

Unfortunately, that bumps into this requirement:

 string().c_str() != nullptr

Which means that either std::string's constructor must allocate memory, or
std::string must implement SSO, or it must get the pointer from somewhere
else.

In particular, the third solution is what GCC's libstdc++ implements and is
also the same solution that QString and QVector do:

> qout: << (void*)std::string().c_str()<< (void*)std::string().c_str()
<out> 0x619438 0x619438
> qout: << QString().constData() << QVector<int>().constData()
<qout> 0x7fd76edd91d8 0x7fd76edd91d8

> Are there any serious problems with trying to make the default constructors
> constexpr for these and other data structures?

Binary compatibility.

In order to allow for constexpr initialisation, the internal format of the
container needs to be carefully designed so either it won't need any pointers
or null pointers are acceptable. Given an existing codebase that needs
pointers and can't deal with nulls, you can't make the constructors constexpr
without breaking binary compatibility.

The best we can do is allow implementations to mark those constructors as
constexpr if they want to, but not mandate it.

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

.

------=_Part_103_2119323553.1425144542566
Content-Type: multipart/alternative;
 boundary="----=_Part_104_1307186129.1425144542566"

------=_Part_104_1307186129.1425144542566
Content-Type: text/plain; charset=UTF-8

On Friday, February 27, 2015 at 9:50:32 PM UTC-5, Matthew Fioravante wrote:
>
> Having a way to constexpr construct data structures is very useful when
> you want to make a global data structure because it eliminates the static
> initialization order race condition.
>

Trying to use constexpr to solve static initialization order is like using
a hammer on a screw. It only gives you a single "before static
initiailzation" phase, when what you really want is a specific order for
static initialization.

Also, I'm pretty sure "race condition" is not the word you're looking for
here.

Even if modules solve the static ordering problem, global objects still
> have runtime overhead before main() is called. Some projects like LLVM have
> strict policies about limiting these things for performance.
>

I do not like the idea of forcing implementations of standard containers
into such specific implementation behavior. To effectively *require*
implementations to use empty, constexpr default initialization takes away
too much freedom from implementations.

Also, you don't have to re-implement the objects to get this behavior. All
you need is a generalized global wrapper object that has an empty,
constexpr constructor. It will do the actual construction of the contained
object the first time someone requests access to its contents. It can even
contain the storage for the object internally via std::aligned_storage.

Even better, this will resolve the problem for any types that you need to
have this behavior for, not just certain standard containers. Indeed, I'd
be in favor of standardizing such a wrapper object.

--

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

<div dir=3D"ltr">On Friday, February 27, 2015 at 9:50:32 PM UTC-5, Matthew =
Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Having a way to constexpr construct data structures is very useful when=
 you want to make a global data structure because it eliminates the static =
initialization order race condition.</div></blockquote><div><br>Trying to u=
se constexpr to solve static initialization order is like using a hammer on=
 a screw. It only gives you a single "before static initiailzation" phase, =
when what you really want is a specific order for static initialization.<br=
><br>Also, I'm pretty sure "race condition" is not the word you're looking =
for here.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div></div><div>Even if modules solve the static ordering problem=
, global objects still have runtime overhead before main() is called. Some =
projects like LLVM have strict policies about limiting these things for per=
formance.</div></div></blockquote><div><br>I do not like the idea of forcin=
g implementations of standard containers into such specific implementation =
behavior. To effectively <i>require</i> implementations to use empty, const=
expr default initialization takes away too much freedom from implementation=
s.<br><br>Also, you don't have to re-implement the objects to get this beha=
vior. All you need is a generalized global wrapper object that has an empty=
, constexpr constructor. It will do the actual construction of the containe=
d object the first time someone requests access to its contents. It can eve=
n contain the storage for the object internally via std::aligned_storage.<b=
r><br>Even better, this will resolve the problem for any types that you nee=
d to have this behavior for, not just certain standard containers. Indeed, =
I'd be in favor of standardizing such a wrapper object.<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_104_1307186129.1425144542566--
------=_Part_103_2119323553.1425144542566--

.

--001a11394b88d7a3f105102f1cf0
Content-Type: text/plain; charset=UTF-8

On 28 February 2015 at 18:29, Nicol Bolas <jmckesson@gmail.com> wrote:

> I do not like the idea of forcing implementations of standard containers
> into such specific implementation behavior. To effectively *require*
> implementations to use empty, constexpr default initialization takes away
> too much freedom from implementations.
>

vector and basic_string already have noexcept default constructors (at
least as of N4296
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf>), so
they pretty much require no allocations take place with default
construction already.

Because the other growable containers are either fully or mostly (such as
deque) node-based, those are unlikely to get noexcept default constructors.

> --
>
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--001a11394b88d7a3f105102f1cf0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 28 February 2015 at 18:29, Nicol Bolas <span dir=3D"ltr=
">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gm=
ail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr"><div>I do not like the idea o=
f forcing implementations of standard containers into such specific impleme=
ntation behavior. To effectively <i>require</i> implementations to use empt=
y, constexpr default initialization takes away too much freedom from implem=
entations.<br></div></div></blockquote><div><br></div><div>vector and basic=
_string already have noexcept default constructors (at least as of=C2=A0<a =
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf">=
N4296</a>), so they pretty much require no allocations take place with defa=
ult construction already.</div><div><br></div><div>Because the other growab=
le containers are either fully or mostly (such as deque) node-based, those =
are unlikely to get noexcept default constructors.</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div>--=C2=A0<br></div></div></blockquote></div><div class=
=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a =
href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord=
..com</a>&gt;=C2=A0 (847) 691-1404</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 />

--001a11394b88d7a3f105102f1cf0--

.

--089e0160a8da65e56305102f2cae
Content-Type: text/plain; charset=UTF-8

On 28 February 2015 at 07:35, Thiago Macieira <thiago@macieira.org> wrote:

> In particular, the third solution is what GCC's libstdc++ implements and is
> also the same solution that QString and QVector do:
>
> > qout: << (void*)std::string().c_str()<< (void*)std::string().c_str()
> <out> 0x619438 0x619438
> > qout: << QString().constData() << QVector<int>().constData()
> <qout> 0x7fd76edd91d8 0x7fd76edd91d8
>

Is that std::string from gcc 4 or gcc 5?  The latter will finally have
C++11 compatible strings (I believe they have been holding off on this
because of ABI breakage).  I don't think the standard quite mandates the
small string optimization, but it is hard to imagine that there is a vendor
out that won't do it.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--089e0160a8da65e56305102f2cae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 28 February 2015 at 07:35, Thiago Macieira <span dir=3D=
"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@m=
acieira.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">In particular, the third so=
lution is what GCC&#39;s libstdc++ implements and is<br>
also the same solution that QString and QVector do:<br>
<br>
&gt; qout: &lt;&lt; (void*)std::string().c_str()&lt;&lt; (void*)std::string=
().c_str()<br>
&lt;out&gt; 0x619438 0x619438<br>
&gt; qout: &lt;&lt; QString().constData() &lt;&lt; QVector&lt;int&gt;().con=
stData()<br>
&lt;qout&gt; 0x7fd76edd91d8 0x7fd76edd91d8<br></blockquote><div><br></div><=
div>Is that std::string from gcc 4 or gcc 5?=C2=A0 The latter will finally =
have C++11 compatible strings (I believe they have been holding off on this=
 because of ABI breakage).=C2=A0 I don&#39;t think the standard quite manda=
tes the small string optimization, but it is hard to imagine that there is =
a vendor out that won&#39;t do it.</div></div>-- <br><div class=3D"gmail_si=
gnature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mail=
to:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=C2=A0 (847) 691-1404</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 />

--089e0160a8da65e56305102f2cae--

.

--Apple-Mail=_81EE7633-3C5E-4796-861E-82747FC82DA9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9303=E2=80=9301, at 8:27 AM, Nevin Liber <nevin@eviloverlor=
d.com> wrote:
>=20
> Is that std::string from gcc 4 or gcc 5?  The latter will finally have C+=
+11 compatible strings (I believe they have been holding off on this becaus=
e of ABI breakage).  I don't think the standard quite mandates the small st=
ring optimization, but it is hard to imagine that there is a vendor out tha=
t won't do it.

SSO is nice, but it=E2=80=99s orthogonal to refcounting or lack thereof.

The disadvantage of SSO is added size and complexity. Like any optimization=
 it needs to be benchmarked. A pipelined CPU without a conditional move ins=
truction could react worse than one with. Checking GCC, it did add SSO, at =
the expense of 8-12 bytes to every string object, which get wasted for larg=
e strings. There are potential branches in the copy constructor, destructor=
, and capacity().

Anyway, empty string representations can be shared even without refcounting=
.. Just initialize the pointer to the common empty string and the capacity t=
o zero. Anything the user does to require nonzero capacity will cause a rea=
llocation. (Instead of checking against null before deallocating, check aga=
inst the common empty string.)

Such a solution is already required for C++11 in the absence of SSO, and it=
=E2=80=99s constexpr-friendly, so is there any other problem?

--=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=_81EE7633-3C5E-4796-861E-82747FC82DA9
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=9303=
=E2=80=9301, at 8:27 AM, Nevin Liber &lt;<a href=3D"mailto:nevin@eviloverlo=
rd.com" class=3D"">nevin@eviloverlord.com</a>&gt; wrote:</div><br class=3D"=
Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"">Is that s=
td::string from gcc 4 or gcc 5?&nbsp; The latter will finally have C++11 co=
mpatible strings (I believe they have been holding off on this because of A=
BI breakage).&nbsp; I don't think the standard quite mandates the small str=
ing optimization, but it is hard to imagine that there is a vendor out that=
 won't do it.</div></div></div></div></div></blockquote><div><br class=3D""=
></div></div><div class=3D"">SSO is nice, but it=E2=80=99s orthogonal to re=
fcounting or lack thereof.</div><div class=3D""><br class=3D""></div><div c=
lass=3D"">The disadvantage of SSO is added size and complexity. Like any op=
timization it needs to be benchmarked. A pipelined CPU without a conditiona=
l move instruction could react worse than one with. Checking GCC, it did ad=
d SSO, at the expense of 8-12 bytes to every string object, which get waste=
d for large strings. There are potential branches in the copy constructor, =
destructor, and <font face=3D"Courier" class=3D"">capacity()</font>.<div cl=
ass=3D""><div class=3D""><br class=3D""></div><div class=3D"">Anyway, empty=
 string representations can be shared even without refcounting. Just initia=
lize the pointer to the common empty string and the capacity to zero. Anyth=
ing the user does to require nonzero capacity will cause a reallocation. (I=
nstead of checking against null before deallocating, check against the comm=
on empty string.)</div><div class=3D""><br class=3D""></div><div class=3D""=
>Such a solution is already required for C++11 in the absence of SSO, and i=
t=E2=80=99s constexpr-friendly, so is there any other problem?</div></div><=
/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=_81EE7633-3C5E-4796-861E-82747FC82DA9--

.

On Sunday 01 March 2015 01:27:17 Nevin Liber wrote:
> On 28 February 2015 at 07:35, Thiago Macieira <thiago@macieira.org> wrote:
> > In particular, the third solution is what GCC's libstdc++ implements and
> > is
> >
> > also the same solution that QString and QVector do:
> > > qout: << (void*)std::string().c_str()<< (void*)std::string().c_str()
> >
> > <out> 0x619438 0x619438
> >
> > > qout: << QString().constData() << QVector<int>().constData()
> >
> > <qout> 0x7fd76edd91d8 0x7fd76edd91d8
>
> Is that std::string from gcc 4 or gcc 5?  The latter will finally have
> C++11 compatible strings (I believe they have been holding off on this
> because of ABI breakage).  I don't think the standard quite mandates the
> small string optimization, but it is hard to imagine that there is a vendor
> out that won't do it.

It doesn't matter. C++11 compatibility does not imply the inability to use a
shared pointer for the default constructor. All it needs is to know how to
avoid passing that pointer to the allocator for freeing.

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

.

--001a1139d4cc778c66051033db48
Content-Type: text/plain; charset=UTF-8

On 1 March 2015 at 04:09, Thiago Macieira <thiago@macieira.org> wrote:

> It doesn't matter. C++11 compatibility does not imply the inability to use
> a
> shared pointer for the default constructor. All it needs is to know how to
> avoid passing that pointer to the allocator for freeing.
>

shared_ptr?  Given that C++11 disallows copy on write strings, how exactly
is shared_ptr useful?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--001a1139d4cc778c66051033db48
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 1 March 2015 at 04:09, Thiago Macieira <span dir=3D"ltr=
">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macie=
ira.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=
=3D"h5"><span style=3D"color:rgb(34,34,34)">It doesn&#39;t matter. C++11 co=
mpatibility does not imply the inability to use a</span><br></div></div>
shared pointer for the default constructor. All it needs is to know how to<=
br>
avoid passing that pointer to the allocator for freeing.<br></blockquote><d=
iv><br></div><div>shared_ptr?=C2=A0 Given that C++11 disallows copy on writ=
e strings, how exactly is shared_ptr useful?</div></div>-- <br><div class=
=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a =
href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord=
..com</a>&gt;=C2=A0 (847) 691-1404</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 />

--001a1139d4cc778c66051033db48--

.

> On 2015=E2=80=9303=E2=80=9301, at 2:02 PM, Nevin Liber <nevin@eviloverlor=
d.com> wrote:
>=20
> shared_ptr?  Given that C++11 disallows copy on write strings, how exactl=
y is shared_ptr useful?

Just an ordinary global. Thiago is saying the same thing as the last two pa=
ragraphs of my reply, except I was too wordy and he was more terse.

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

.

--001a11393836b4405e05103500b6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 1 March 2015 at 07:11, David Krauss <potswa@gmail.com> wrote:

>
> > On 2015=E2=80=9303=E2=80=9301, at 2:02 PM, Nevin Liber <nevin@eviloverl=
ord.com> wrote:
> >
> > shared_ptr?  Given that C++11 disallows copy on write strings, how
> exactly is shared_ptr useful?
>
> Just an ordinary global. Thiago is saying the same thing as the last two
> paragraphs of my reply, except I was too wordy and he was more terse.
>

A global shared_ptr for what?  Is it just a pointer to a '\0' byte??  That
sure sounds like you guys make your code way more overly complicated than
it ever needs to be.

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



--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

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

--001a11393836b4405e05103500b6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 1 March 2015 at 07:11, David Krauss <span dir=3D"ltr">&=
lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</=
a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
&gt; On 2015=E2=80=9303=E2=80=9301, at 2:02 PM, Nevin Liber &lt;<a href=3D"=
mailto:nevin@eviloverlord.com">nevin@eviloverlord.com</a>&gt; wrote:<br>
&gt;<br>
&gt; shared_ptr?=C2=A0 Given that C++11 disallows copy on write strings, ho=
w exactly is shared_ptr useful?<br>
<br>
</span>Just an ordinary global. Thiago is saying the same thing as the last=
 two paragraphs of my reply, except I was too wordy and he was more terse.<=
br></blockquote><div><br></div><div>A global shared_ptr for what?=C2=A0 Is =
it just a pointer to a &#39;\0&#39; byte??=C2=A0 That sure sounds like you =
guys make your code way more overly complicated than it ever needs to be.</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;=
mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@ev=
iloverlord.com</a>&gt;=C2=A0 (847) 691-1404</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 />

--001a11393836b4405e05103500b6--

.

--001a113a5a2a7b07930510352e69
Content-Type: text/plain; charset=UTF-8

On 1 March 2015 at 03:51, David Krauss <potswa@gmail.com> wrote:

>
> The disadvantage of SSO is added size and complexity. Like any
> optimization it needs to be benchmarked. A pipelined CPU without a
> conditional move instruction could react worse than one with. Checking GCC,
> it did add SSO, at the expense of 8-12 bytes to every string object, which
> get wasted for large strings. There are potential branches in the copy
> constructor, destructor, and capacity().
>

But that is compared with heap allocation, which isn't exactly
inexpensive.  And if you have large strings, it seems likely that these
costs are in the noise.

Like any engineering tradeoff, this one is biased towards certain types of
data at the expense of other types of data.  Do you have any evidence that
this tradeoff is a bad choice for the vast majority of uses of std::string?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--001a113a5a2a7b07930510352e69
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 1 March 2015 at 03:51, David Krauss <span dir=3D"ltr">&=
lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</=
a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><span=
 class=3D""><br></span><div>The disadvantage of SSO is added size and compl=
exity. Like any optimization it needs to be benchmarked. A pipelined CPU wi=
thout a conditional move instruction could react worse than one with. Check=
ing GCC, it did add SSO, at the expense of 8-12 bytes to every string objec=
t, which get wasted for large strings. There are potential branches in the =
copy constructor, destructor, and <font face=3D"Courier">capacity()</font>.=
</div></div></blockquote><div><br></div><div>But that is compared with heap=
 allocation, which isn&#39;t exactly inexpensive.=C2=A0 And if you have lar=
ge strings, it seems likely that these costs are in the noise.</div><div><b=
r></div><div>Like any engineering tradeoff, this one is biased towards cert=
ain types of data at the expense of other types of data.=C2=A0 Do you have =
any evidence that this tradeoff is a bad choice for the vast majority of us=
es of std::string?</div></div>-- <br><div class=3D"gmail_signature">=C2=A0N=
evin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evilove=
rlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691=
-1404</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 />

--001a113a5a2a7b07930510352e69--

.

--Apple-Mail=_35ECC943-4190-4F73-AC29-F4CF8931F0AD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9303=E2=80=9301, at 3:37 PM, Nevin Liber <nevin@eviloverlor=
d.com> wrote:
>=20
> Like any engineering tradeoff, this one is biased towards certain types o=
f data at the expense of other types of data.  Do you have any evidence tha=
t this tradeoff is a bad choice for the vast majority of uses of std::strin=
g?

I=E2=80=99m just saying, it=E2=80=99s still feasible that some implementati=
on might have a reason for wanting to omit SSO, so it shouldn=E2=80=99t be =
construed as standard.

Given an empty string, you can=E2=80=99t assume that a copy of it will have=
 a different value for data(), nor that moving it will keep the same data()=
..

--=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=_35ECC943-4190-4F73-AC29-F4CF8931F0AD
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=9303=
=E2=80=9301, at 3:37 PM, Nevin Liber &lt;<a href=3D"mailto:nevin@eviloverlo=
rd.com" class=3D"">nevin@eviloverlord.com</a>&gt; wrote:</div></blockquote>=
<div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><div class=3D""><blockquote type=3D"cite" class=3D""=
><br class=3D""></blockquote></div></div></div></div></div><blockquote type=
=3D"cite" class=3D""><div class=3D""><div class=3D"gmail_quote" style=3D"fo=
nt-family: Helvetica; font-size: 12px; font-style: normal; font-variant: no=
rmal; font-weight: normal; letter-spacing: normal; line-height: normal; orp=
hans: auto; text-align: start; text-indent: 0px; text-transform: none; whit=
e-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width=
: 0px;"><div class=3D"">Like any engineering tradeoff, this one is biased t=
owards certain types of data at the expense of other types of data.&nbsp; D=
o you have any evidence that this tradeoff is a bad choice for the vast maj=
ority of uses of std::string?</div></div></div></blockquote></div><br class=
=3D""><div class=3D"">I=E2=80=99m just saying, it=E2=80=99s still feasible =
that some implementation might have a reason for wanting to omit SSO, so it=
 shouldn=E2=80=99t be construed as standard.</div><div class=3D""><br class=
=3D""></div><div class=3D"">Given an empty string, you can=E2=80=99t assume=
 that a copy of it will have a different value for&nbsp;<font face=3D"Couri=
er" class=3D"">data()</font>, nor that moving it will keep the same&nbsp;<f=
ont face=3D"Courier" class=3D"">data()</font>.</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=_35ECC943-4190-4F73-AC29-F4CF8931F0AD--

.

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3D=
utf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: spac=
e; -webkit-line-break: after-white-space;" class=3D"" dir=3D"auto"><br clas=
s=3D""><div class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""=
>On 2015=E2=80=9303=E2=80=9301, at 3:37 PM, Nevin Liber &lt;<a href=3D"mail=
to:nevin@eviloverlord.com" class=3D"">nevin@eviloverlord.com</a>&gt; wrote:=
</div></blockquote><div class=3D""><div dir=3D"ltr" class=3D""><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""><blockquote typ=
e=3D"cite" class=3D""><br class=3D""></blockquote></div></div></div></div><=
/div><blockquote type=3D"cite" class=3D""><div class=3D""><div class=3D"gma=
il_quote" style=3D"font-family: Helvetica; font-size: 12px; font-style: nor=
mal; font-variant: normal; font-weight: normal; letter-spacing: normal; lin=
e-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-=
transform: none; white-space: normal; widows: auto; word-spacing: 0px; -web=
kit-text-stroke-width: 0px;"><div class=3D"">Like any engineering tradeoff,=
 this one is biased towards certain types of data at the expense of other t=
ypes of data.&nbsp; Do you have any evidence that this tradeoff is a bad ch=
oice for the vast majority of uses of std::string?</div></div></div></block=
quote></div><br class=3D""><div class=3D"">I=E2=80=99m just saying, it=E2=
=80=99s still feasible that some implementation might have a reason for wan=
ting to omit SSO, so it shouldn=E2=80=99t be construed as standard.</div><d=
iv class=3D""><br class=3D""></div><div class=3D"">Given an empty string, y=
ou can=E2=80=99t assume that a copy of it will have a different value for&n=
bsp;<font face=3D"Courier" class=3D"">data()</font>, nor that moving it wil=
l keep the same&nbsp;<font face=3D"Courier" class=3D"">data()</font>.</div>=
<div class=3D""><br class=3D""></div><div class=3D""><blockquote type=3D"ci=
te" class=3D""><div class=3D"">A global shared_ptr for what?&nbsp; Is it ju=
st a pointer to a '\0' byte??&nbsp; That sure sounds like you guys make you=
r code way more overly complicated than it ever needs to be.</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-wi=
dth: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; =
padding-left: 1ex;"><div class=3D"HOEnZb"></div></blockquote></blockquote><=
div class=3D""><div class=3D""><br class=3D""></div></div><div class=3D"">T=
here=E2=80=99s no <font face=3D"Courier" class=3D"">shared_ptr</font>. See =
my first reply to this thread.</div></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 />

.

--089e0160a8da374bae0510375617
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 1 March 2015 at 09:03, David Krauss <potswa@gmail.com> wrote:

>
> I=E2=80=99m just saying, it=E2=80=99s still feasible that some implementa=
tion might have a
> reason for wanting to omit SSO, so it shouldn=E2=80=99t be construed as s=
tandard.
>

Stop making straw man arguments.  No one here is saying that SSO is
required.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

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

--089e0160a8da374bae0510375617
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 1 March 2015 at 09:03, David Krauss <span dir=3D"ltr">&=
lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</=
a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><span=
 class=3D""><br></span><div>I=E2=80=99m just saying, it=E2=80=99s still fea=
sible that some implementation might have a reason for wanting to omit SSO,=
 so it shouldn=E2=80=99t be construed as standard.</div></div></blockquote>=
<div><br></div><div>Stop making straw man arguments.=C2=A0 No one here is s=
aying that SSO is required.</div><div>--=C2=A0<br></div></div><div class=3D=
"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a hre=
f=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.co=
m</a>&gt;=C2=A0 (847) 691-1404</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 />

--089e0160a8da374bae0510375617--

.

------=_Part_56_2113060443.1425221298608
Content-Type: multipart/alternative;
 boundary="----=_Part_57_1269795062.1425221298608"

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



On Sunday, March 1, 2015 at 2:25:16 AM UTC-5, Nevin ":-)" Liber wrote:
>
> On 1 March 2015 at 07:11, David Krauss <pot...@gmail.com <javascript:>>=
=20
> wrote:
>
>>
>> > On 2015=E2=80=9303=E2=80=9301, at 2:02 PM, Nevin Liber <ne...@evilover=
lord.com=20
>> <javascript:>> wrote:
>> >
>> > shared_ptr?  Given that C++11 disallows copy on write strings, how=20
>> exactly is shared_ptr useful?
>>
>> Just an ordinary global. Thiago is saying the same thing as the last two=
=20
>> paragraphs of my reply, except I was too wordy and he was more terse.
>>
>
> A global shared_ptr for what?  Is it just a pointer to a '\0' byte??  Tha=
t=20
> sure sounds like you guys make your code way more overly complicated than=
=20
> it ever needs to be.
>

He never said "shared_ptr"; *you* said that. He said "shared pointer". As=
=20
in "a pointer variable that all instances of the class share". A "shared=20
pointer", if you will.

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

<div dir=3D"ltr"><br><br>On Sunday, March 1, 2015 at 2:25:16 AM UTC-5, Nevi=
n ":-)" Liber 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">On 1 March 2015 at 07:11, David Krauss <span dir=3D"ltr">&lt;<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"TzPT5K9jxrAJ"=
 rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;">pot...@gmail.com</a>&gt;</=
span> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><span><br>
&gt; On 2015=E2=80=9303=E2=80=9301, at 2:02 PM, Nevin Liber &lt;<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"TzPT5K9jxrAJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">ne...@eviloverlord.com</a>&gt;=
 wrote:<br>
&gt;<br>
&gt; shared_ptr?&nbsp; Given that C++11 disallows copy on write strings, ho=
w exactly is shared_ptr useful?<br>
<br>
</span>Just an ordinary global. Thiago is saying the same thing as the last=
 two paragraphs of my reply, except I was too wordy and he was more terse.<=
br></blockquote><div><br></div><div>A global shared_ptr for what?&nbsp; Is =
it just a pointer to a '\0' byte??&nbsp; That sure sounds like you guys mak=
e your code way more overly complicated than it ever needs to be.</div></di=
v></div></div></blockquote><div><br>He never said "shared_ptr"; <i>you</i> =
said that. He said "shared pointer". As in "a pointer variable that all ins=
tances of the class share". A "shared pointer", if you will.<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_57_1269795062.1425221298608--
------=_Part_56_2113060443.1425221298608--

.

On Sunday 01 March 2015 06:48:18 Nicol Bolas wrote:
> > A global shared_ptr for what?  Is it just a pointer to a '\0'
> > byte??  That
> > sure sounds like you guys make your code way more overly complicated than
> > it ever needs to be.
>
> He never said "shared_ptr"; *you* said that. He said "shared pointer". As
> in "a pointer variable that all instances of the class share". A "shared
> pointer", if you will.

A "pointer to a null byte that is shared by all instances".

--
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 01 March 2015 08:37:22 Nevin Liber wrote:
> Like any engineering tradeoff, this one is biased towards certain types of
> data at the expense of other types of data.  Do you have any evidence that
> this tradeoff is a bad choice for the vast majority of uses of std::string?

I've never benchmarked SSO, but I can tell you from my statistics that over
95% of strings (at least in QString) are less than 16 characters long, which
constrains quite a lot when optimising code.

Very often, code optimisations like loop unrolling and SIMD vectoring are only
useful for larger data sets. My benchmarks show that the cost of adding more
complex SIMD operations to QString results in pessimisation of the common
case. Therefore, we use SIMD judiciously and the entry point needs to be
really simple.

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

.

------=_Part_437_1070510510.1425238458480
Content-Type: multipart/alternative;
 boundary="----=_Part_438_452147004.1425238458480"

------=_Part_438_452147004.1425238458480
Content-Type: text/plain; charset=UTF-8



On Saturday, February 28, 2015 at 12:29:02 PM UTC-5, Nicol Bolas wrote:
>
> On Friday, February 27, 2015 at 9:50:32 PM UTC-5, Matthew Fioravante wrote:
>>
>> Having a way to constexpr construct data structures is very useful when
>> you want to make a global data structure because it eliminates the static
>> initialization order race condition.
>>
>
> Trying to use constexpr to solve static initialization order is like using
> a hammer on a screw. It only gives you a single "before static
> initiailzation" phase, when what you really want is a specific order for
> static initialization.
>

If you want static ordering, you need to use a singleton lazy
initialization technique such as Meyers singleton. A new feature such as
modules can still be used to specify ordering if you need to control order
of destruction later.
Even if we eventually get modules its probably not going to be in C++17 and
once its available it will take even longer for libraries to adopt it.

Its much more common to have initialization order problems than destruction
problems. The only destruction order use case I've come across is
destroying a logger or debugging environment when you want to log and/or
debug global destructor code.Eliminating the question of ordering entirely
greatly simplifies things and also optimizes the startup time of your
application.



On Saturday, February 28, 2015 at 1:35:15 AM UTC-5, Thiago Macieira wrote:
>
> On Friday 27 February 2015 18:50:32 Matthew Fioravante wrote:
> > Having a way to constexpr construct data structures is very useful when
> you
> > want to make a global data structure because it eliminates the static
> > initialization order race condition.
>
> Note that it does not eliminate load-time impacts, since the destructors
> for
> those types can't be constexpr, which means the compiler must register the
> destruction with atexit() or similar function.
>

Destructors are usually much simpler


>
> > At a minimum if at least vector, unordered_map, and string have
> constexpr
> > default constructors if its possible would be enough for a lot of use
> cases.
> >
> > Assuming the underlying allocator constructor is constexpr, vector seems
> > pretty straightforward. No sane vector implementation should be
> > speculatively allocating memory in the default constructor anyway.
> >
> > string should be simple as well, especially with the SSO.
>
> Unfortunately, that bumps into this requirement:
>
>         string().c_str() != nullptr
>
> Which means that either std::string's constructor must allocate memory, or
> std::string must implement SSO, or it must get the pointer from somewhere
> else.
>

std::basic_string implementation  just needs a constexpr static const CharT
zero = 0; in its private section to solve this problem.


On Sunday, March 1, 2015 at 2:06:30 PM UTC-5, Thiago Macieira wrote:
>
> On Sunday 01 March 2015 08:37:22 Nevin Liber wrote:
> > Like any engineering tradeoff, this one is biased towards certain types
> of
> > data at the expense of other types of data.  Do you have any evidence
> that
> > this tradeoff is a bad choice for the vast majority of uses of
> std::string?
>
> I've never benchmarked SSO, but I can tell you from my statistics that
> over
> 95% of strings (at least in QString) are less than 16 characters long,
> which
> constrains quite a lot when optimising code.
>

There may be some scenarios where the optiminal SSO buffer size (or not
using SSO at all) might be optimal with your universe of strings. If SSO
was configurable with a template size_t argument, users could configure it
how they like.

--

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

<div dir=3D"ltr"><br><br>On Saturday, February 28, 2015 at 12:29:02 PM UTC-=
5, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 20=
4); border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr">On Frida=
y, February 27, 2015 at 9:50:32 PM UTC-5, Matthew Fioravante wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-w=
idth: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid;=
 padding-left: 1ex;"><div dir=3D"ltr">Having a way to constexpr construct d=
ata structures is very useful when you want to make a global data structure=
 because it eliminates the static initialization order race condition.</div=
></blockquote><div><br>Trying to use constexpr to solve static initializati=
on order is like using a hammer on a screw. It only gives you a single "bef=
ore static initiailzation" phase, when what you really want is a specific o=
rder for static initialization.<br></div></div></blockquote><div><br></div>=
<div>If you want static ordering, you need to use a singleton lazy initiali=
zation technique such as Meyers singleton. A new feature such as modules ca=
n still be used to specify ordering if you need to control order of destruc=
tion later.</div><div>Even if we eventually get modules its probably not go=
ing to be in C++17 and once its available it will take even longer for libr=
aries to adopt it.<br></div><div><br></div><div>Its much more common to hav=
e initialization order problems than destruction problems. The only destruc=
tion order use case I've come across is destroying a logger or debugging en=
vironment when you want to log and/or debug global destructor code.Eliminat=
ing the question of ordering entirely greatly simplifies things and also op=
timizes the startup time of your application.</div><div><br></div><div><br>=
</div><div><br>On Saturday, February 28, 2015 at 1:35:15 AM UTC-5, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); bor=
der-left-style: solid; padding-left: 1ex;">On Friday 27 February 2015 18:50=
:32 Matthew Fioravante wrote:&nbsp;<br>&gt; Having a way to constexpr const=
ruct data structures is very useful when you&nbsp;<br>&gt; want to make a g=
lobal data structure because it eliminates the static&nbsp;<br>&gt; initial=
ization order race condition.&nbsp;<br><br>Note that it does not eliminate =
load-time impacts, since the destructors for&nbsp;<br>those types can't be =
constexpr, which means the compiler must register the&nbsp;<br>destruction =
with atexit() or similar function.&nbsp;<br></blockquote><div><br></div><di=
v>Destructors are usually much simpler</div><div>&nbsp;</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: =
1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; paddi=
ng-left: 1ex;"><br>&gt; At a minimum if at least vector, unordered_map, and=
 string have constexpr&nbsp;<br>&gt; default constructors if its possible w=
ould be enough for a lot of use cases.&nbsp;<br>&gt;&nbsp;<br>&gt; Assuming=
 the underlying allocator constructor is constexpr, vector seems&nbsp;<br>&=
gt; pretty straightforward. No sane vector implementation should be&nbsp;<b=
r>&gt; speculatively allocating memory in the default constructor anyway.&n=
bsp;<br>&gt;&nbsp;<br>&gt; string should be simple as well, especially with=
 the SSO.&nbsp;<br><br>Unfortunately, that bumps into this requirement:&nbs=
p;<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;string().c_str() =
!=3D nullptr&nbsp;<br><br>Which means that either std::string's constructor=
 must allocate memory, or&nbsp;<br>std::string must implement SSO, or it mu=
st get the pointer from somewhere&nbsp;<br>else.&nbsp;<br></blockquote><div=
><br></div><div>std::basic_string implementation &nbsp;just needs a constex=
pr static const CharT zero =3D 0; in its private section to solve this prob=
lem.</div></div><div><br></div><br>On Sunday, March 1, 2015 at 2:06:30 PM U=
TC-5, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On=
 Sunday 01 March 2015 08:37:22 Nevin Liber wrote:
<br>&gt; Like any engineering tradeoff, this one is biased towards certain =
types of
<br>&gt; data at the expense of other types of data. &nbsp;Do you have any =
evidence that
<br>&gt; this tradeoff is a bad choice for the vast majority of uses of std=
::string?
<br>
<br>I've never benchmarked SSO, but I can tell you from my statistics that =
over=20
<br>95% of strings (at least in QString) are less than 16 characters long, =
which=20
<br>constrains quite a lot when optimising code.
<br></blockquote><div><br></div><div>There may be some scenarios where the =
optiminal SSO buffer size (or not using SSO at all) might be optimal with y=
our universe of strings. If SSO was configurable with a template size_t arg=
ument, users could configure it how they like.</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_438_452147004.1425238458480--
------=_Part_437_1070510510.1425238458480--

.

------=_Part_666_3305313.1425265882136
Content-Type: multipart/alternative;
 boundary="----=_Part_667_1865304416.1425265882137"

------=_Part_667_1865304416.1425265882137
Content-Type: text/plain; charset=UTF-8



On Sunday, March 1, 2015 at 2:34:18 PM UTC-5, Matthew Fioravante wrote:
>
>
>
> On Saturday, February 28, 2015 at 12:29:02 PM UTC-5, Nicol Bolas wrote:
>>
>> On Friday, February 27, 2015 at 9:50:32 PM UTC-5, Matthew Fioravante
>> wrote:
>>>
>>> Having a way to constexpr construct data structures is very useful when
>>> you want to make a global data structure because it eliminates the static
>>> initialization order race condition.
>>>
>>
>> Trying to use constexpr to solve static initialization order is like
>> using a hammer on a screw. It only gives you a single "before static
>> initiailzation" phase, when what you really want is a specific order for
>> static initialization.
>>
>
> If you want static ordering, you need to use a singleton lazy
> initialization technique such as Meyers singleton. A new feature such as
> modules can still be used to specify ordering if you need to control order
> of destruction later.
> Even if we eventually get modules its probably not going to be in C++17
> and once its available it will take even longer for libraries to adopt it.
>

I'm pretty sure that if modules are in C++17, the standard library will use
them. It'd be pretty silly to force everyone to write their own modules
that export standard library constructs.

Furthermore, your desired library change would also not see publication
until 2017 at the earliest. And since it could very well cause problems
with some implementations (in particular unordered_*), it could take time
for people to implement it (see libstdc++ and the time it took to get a
conforming C++11 std::basic_string, due to ABI issues).

I also disagree with the idea that the primary benefit of module-based
ordering of construction in some way is about destruction ordering. I mean
yes, it does solve that problem. But as you point out, most people need
construction ordering. And modules solves that problem.

Basically, my point is that constexpr-based ordering is a fake solution to
the problem. There's little point in requesting a library change to
implement a fake solution for a problem that we're trying desperately to
get a *real* fix for. After all, once you have module-based ordering, do
you really care about using constexpr-based ordering anymore?

Its much more common to have initialization order problems than destruction
> problems. The only destruction order use case I've come across is
> destroying a logger or debugging environment when you want to log and/or
> debug global destructor code.Eliminating the question of ordering entirely
> greatly simplifies things and also optimizes the startup time of your
> application.
>

I don't recall mentioning destruction, nor do I recall questioning the
general merits of having a strict ordering for the initialization of
objects. What I questioned was the (ab)use of constexpr as a means of
creating such an ordering.

--

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

<div dir=3D"ltr"><br><br>On Sunday, March 1, 2015 at 2:34:18 PM UTC-5, Matt=
hew Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><br>On Saturday, February 28, 2015 at 12:29:02 PM UTC-5, Nicol=
 Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div dir=3D"ltr">On Friday, February 27, 2015=
 at 9:50:32 PM UTC-5, Matthew Fioravante wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D=
"ltr">Having a way to constexpr construct data structures is very useful wh=
en you want to make a global data structure because it eliminates the stati=
c initialization order race condition.</div></blockquote><div><br>Trying to=
 use constexpr to solve static initialization order is like using a hammer =
on a screw. It only gives you a single "before static initiailzation" phase=
, when what you really want is a specific order for static initialization.<=
br></div></div></blockquote><div><br></div><div>If you want static ordering=
, you need to use a singleton lazy initialization technique such as Meyers =
singleton. A new feature such as modules can still be used to specify order=
ing if you need to control order of destruction later.</div><div>Even if we=
 eventually get modules its probably not going to be in C++17 and once its =
available it will take even longer for libraries to adopt it.<br></div></di=
v></blockquote><div><br>I'm pretty sure that if modules are in C++17, the s=
tandard library will use them. It'd be pretty silly to force everyone to wr=
ite their own modules that export standard library constructs.<br><br>Furth=
ermore, your desired library change would also not see publication until 20=
17 at the earliest. And since it could very well cause problems with some i=
mplementations (in particular unordered_*), it could take time for people t=
o implement it (see libstdc++ and the time it took to get a conforming C++1=
1 std::basic_string, due to ABI issues).<br><br>I also disagree with the id=
ea that the primary benefit of module-based ordering of construction in som=
e way is about destruction ordering. I mean yes, it does solve that problem=
.. But as you point out, most people need construction ordering. And modules=
 solves that problem.<br><br>Basically, my point is that constexpr-based or=
dering is a fake solution to the problem. There's little point in requestin=
g a library change to implement a fake solution for a problem that we're tr=
ying desperately to get a <i>real</i> fix for. After all, once you have mod=
ule-based ordering, do you really care about using constexpr-based ordering=
 anymore?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div></div><div>Its much more common to have initialization order=
 problems than destruction problems. The only destruction order use case I'=
ve come across is destroying a logger or debugging environment when you wan=
t to log and/or debug global destructor code.Eliminating the question of or=
dering entirely greatly simplifies things and also optimizes the startup ti=
me of your application.</div></div></blockquote><div><br>I don't recall men=
tioning destruction, nor do I recall questioning the general merits of havi=
ng a strict ordering for the initialization of objects. What I questioned w=
as the (ab)use of constexpr as a means of creating such an ordering.<br></d=
iv></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_667_1865304416.1425265882137--
------=_Part_666_3305313.1425265882136--

.

--001a11c25972297a0e0510473e19
Content-Type: text/plain; charset=UTF-8

On Sun, Mar 1, 2015 at 2:34 PM, Matthew Fioravante <fmatthew5876@gmail.com>
wrote:

>
>
> On Saturday, February 28, 2015 at 12:29:02 PM UTC-5, Nicol Bolas wrote:
>>
>> On Friday, February 27, 2015 at 9:50:32 PM UTC-5, Matthew Fioravante
>> wrote:
>>>
>>> Having a way to constexpr construct data structures is very useful when
>>> you want to make a global data structure because it eliminates the static
>>> initialization order race condition.
>>>
>>
>> Trying to use constexpr to solve static initialization order is like
>> using a hammer on a screw. It only gives you a single "before static
>> initiailzation" phase, when what you really want is a specific order for
>> static initialization.
>>
>
> If you want static ordering, you need to use a singleton lazy
> initialization technique such as Meyers singleton. A new feature such as
> modules can still be used to specify ordering if you need to control order
> of destruction later.
> Even if we eventually get modules its probably not going to be in C++17
> and once its available it will take even longer for libraries to adopt it.
>
> Its much more common to have initialization order problems than
> destruction problems. The only destruction order use case I've come across
> is destroying a logger or debugging environment when you want to log and/or
> debug global destructor code.
>

And global allocators (and/or mem-checkers).  Your allocator needs to stick
around until the last free/delete call.

I find destruction order a harder problem.  Construction order, as you
mention, has a solution - lazy singletons (as much as I hate singletons!).
Destruction order doesn't really have a nice solution.  Either you don't
delete at all (and get mem-checkers to complain), or use "phoenix
singletons" (that can be recreated as needed if they were already
destroyed) or you in-place construct your object into an array of static
chars (to avoid allocation), and never destroy it.  And make sure you are
not in a dll that has been unloaded...


> Eliminating the question of ordering entirely greatly simplifies things
> and also optimizes the startup time of your application.
>
>
Singletons are evil. Not just because of construction/destruction but also
dependency hiding, unit testing, etc. Avoid them whenever possible.

Tony

--

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

--001a11c25972297a0e0510473e19
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Mar 1, 2015 at 2:34 PM, Matthew Fioravante <span dir=3D"ltr">&l=
t;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><span class=3D""><br><br>On Saturday, February 28, 2015 at 12:29:0=
2 PM UTC-5, Nicol Bolas wrote:</span><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><spa=
n class=3D"">On Friday, February 27, 2015 at 9:50:32 PM UTC-5, Matthew Fior=
avante wrote:</span><span class=3D""><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">Havi=
ng a way to constexpr construct data structures is very useful when you wan=
t to make a global data structure because it eliminates the static initiali=
zation order race condition.</div></blockquote></span><div><br><span class=
=3D"">Trying to use constexpr to solve static initialization order is like =
using a hammer on a screw. It only gives you a single &quot;before static i=
nitiailzation&quot; phase, when what you really want is a specific order fo=
r static initialization.<br></span></div></div></blockquote><div><br></div>=
<div>If you want static ordering, you need to use a singleton lazy initiali=
zation technique such as Meyers singleton. A new feature such as modules ca=
n still be used to specify ordering if you need to control order of destruc=
tion later.</div><div>Even if we eventually get modules its probably not go=
ing to be in C++17 and once its available it will take even longer for libr=
aries to adopt it.<br></div><div><br></div><div>Its much more common to hav=
e initialization order problems than destruction problems. The only destruc=
tion order use case I&#39;ve come across is destroying a logger or debuggin=
g environment when you want to log and/or debug global destructor code.</di=
v></div></blockquote><div><br></div><div>And global allocators (and/or mem-=
checkers).=C2=A0 Your allocator needs to stick around until the last free/d=
elete call.<br><br></div><div>I find destruction order a harder problem.=C2=
=A0 Construction order, as you mention, has a solution - lazy singletons (a=
s much as I hate singletons!).<br></div><div>Destruction order doesn&#39;t =
really have a nice solution.=C2=A0 Either you don&#39;t delete at all (and =
get mem-checkers to complain), or use &quot;phoenix singletons&quot; (that =
can be recreated as needed if they were already destroyed) or you in-place =
construct your object into an array of static chars (to avoid allocation), =
and never destroy it.=C2=A0 And make sure you are not in a dll that has bee=
n unloaded...<br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div>Eliminating the question of ordering entirely greatly=
 simplifies things and also optimizes the startup time of your application.=
</div><div><br></div></div></blockquote><div><br></div><div>Singletons are =
evil. Not just because of construction/destruction but also dependency hidi=
ng, unit testing, etc. Avoid them whenever possible.<br><br></div><div>Tony=
<br><br></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 />

--001a11c25972297a0e0510473e19--

.

------=_Part_1148_1544219878.1425350274120
Content-Type: multipart/alternative;
 boundary="----=_Part_1149_1363615551.1425350274120"

------=_Part_1149_1363615551.1425350274120
Content-Type: text/plain; charset=UTF-8


>
>  After all, once you have module-based ordering, do you really care about
> using constexpr-based ordering anymore?


constexpr still provides an optimization in application startup time. But
you are right that modules are the complete solution.

On Monday, March 2, 2015 at 12:11:04 AM UTC-5, Tony V E wrote:
>
> Singletons are evil. Not just because of construction/destruction but also
> dependency hiding, unit testing, etc. Avoid them whenever possible.
>
> Tony
>
>
Singletons are useful for implementing class factories or plugin managers
where you have to manage some global state about registration tags and
entry point function pointers. The factory data starts out empty and does
not require runtime initialization so with constexpr it is guaranteed to
always be in a valid initialized state. If nothing accesses the factory at
destruction time, there are no destruction order problems either. As
mentioned earlier if shutdown time is critical you can make the singletons
not free their resources at all and just exit.




--

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

<div dir=3D"ltr"><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: sol=
id; padding-left: 1ex;" class=3D"gmail_quote"><span style=3D"font-size: 13.=
1428575515747px; color: rgb(34, 34, 34);">&nbsp;After all, once you have mo=
dule-based ordering, do you really care about using constexpr-based orderin=
g anymore?</span></blockquote><div><br></div><div>constexpr still provides =
an optimization in application startup time. But you are right that modules=
 are the complete solution.</div><br>On Monday, March 2, 2015 at 12:11:04 A=
M UTC-5, Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote"><div>Singletons are evil. Not ju=
st because of construction/destruction but also dependency hiding, unit tes=
ting, etc. Avoid them whenever possible.<br><br></div><div>Tony<br><br></di=
v></div></div></div></blockquote><div><br></div><div>Singletons are useful =
for implementing class factories or plugin managers where you have to manag=
e some global state about registration tags and entry point function pointe=
rs. The factory data starts out empty and does not require runtime initiali=
zation so with constexpr it is guaranteed to always be in a valid initializ=
ed state. If nothing accesses the factory at destruction time, there are no=
 destruction order problems either. As mentioned earlier if shutdown time i=
s critical you can make the singletons not free their resources at all and =
just exit.</div><div><br></div><div><br></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_1149_1363615551.1425350274120--
------=_Part_1148_1544219878.1425350274120--

.

On Monday 02 March 2015 18:37:53 Matthew Fioravante wrote:
> >  After all, once you have module-based ordering, do you really care about
> >
> > using constexpr-based ordering anymore?
>
> constexpr still provides an optimization in application startup time. But
> you are right that modules are the complete solution.

In this case that you're proposing, the optimisation is minimal, since a
startup-time "constructor" function still needs to be run to register the non-
constexpr destructor with atexit(). The additional impact of moving a few
values to addresses in memory is minimal.

Not to mention that as a QoI, the compiler could forego moving zeroes to zero-
initialised memory:

std::vector<int> v;

GCC:
        movq    $0, v(%rip)
        movq    $0, v+8(%rip)
        movq    $0, v+16(%rip)
Clang:
        xorps   %xmm0, %xmm0
        movups  %xmm0, v(%rip)
        movq    $0, v+16(%rip)
ICC:
        xorl      %eax, %eax
        movq      %rax, v(%rip)
        movq      %rax, 8+v(%rip)
        movq      %rax, 16+v(%rip)

(both libstdc++ and libc++)

With that optimisation, a constexpr constructor for these implementations of
std::vector would be exactly equivalent to the non-constexpr one.

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

.