------=_Part_621_1260389287.1413110669328
Content-Type: text/plain; charset=UTF-8

C++11 introduced constant intialization of globals/statics, which gave us a
new way to avoid the problems with initialization order of statics defined
in different source files.

Unfortunately there is no way to check that a non-const variable will be
statically initialized. It seems all too easy to accidentally write an
initializer in a way which is not eligible for constant initialization, in
which case the compiler will silently fall back to dynamic initialization.

How about using an attribute for this? Say:

[[static_init]] T val = f();

The attribute indicates the programmer's intention that static
initialization should apply, and asks the compiler to generate an error if
it is not eligible.

An attribute seems to be the perfect solution here because it does not
actually change the meaning of the code - variables would still be
statically initialized whether or not the attribute was used, provided that
the appropriate conditions are met. The only effect is that the compiler is
to give a warning if the actual meaning of the code does not match the
intent.

Does this sound like a worthwhile feature?

--

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

<div dir=3D"ltr">C++11 introduced constant intialization of globals/statics=
, which gave us a new way to avoid the problems with initialization order o=
f statics defined in different source files.<br><br>Unfortunately there is =
no way to check that a non-const variable will be statically initialized. I=
t seems all too easy to accidentally write an initializer in a way which is=
 not eligible for constant initialization, in which case the compiler will =
silently fall back to dynamic initialization.<br><br>How about using an att=
ribute for this? Say:<br><br>[[static_init]] T val =3D f();<br><br>The attr=
ibute indicates the programmer's intention that static initialization shoul=
d apply, and asks the compiler to generate an error if it is not eligible.<=
br><br>An attribute seems to be the perfect solution here because it does n=
ot actually change the meaning of the code - variables would still be stati=
cally initialized whether or not the attribute was used, provided that the =
appropriate conditions are met. The only effect is that the compiler is to =
give a warning if the actual meaning of the code does not match the intent.=
<br><br>Does this sound like a worthwhile feature?<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_621_1260389287.1413110669328--

.

--Apple-Mail=_958C3B10-6576-4ED1-B82E-2497101FBB35
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-10-12, at 6:44 PM, col3435 via ISO C++ Standard - Future Proposals =
<std-proposals@isocpp.org> wrote:

> C++11 introduced constant intialization of globals/statics,

That existed since C++98.

> which gave us a new way to avoid the problems with initialization order o=
f statics defined in different source files.

Little has changed in this regard either. More things are constant expressi=
ons now, with constexpr, and that specifier does provide an explicit guaran=
tee against dynamic initialization.

If you explicitly don't declare a const variable as extern, what you have i=
s not one global with ambiguous initialization order but a different global=
 for each translation unit (.cpp file). My recent proposal "inline variable=
s" (http://bit.ly/1qTSBiP) addresses the problem.

> Unfortunately there is no way to check that a non-const variable will be =
statically initialized.

Actually, there is, but it's terribly obfuscated. Use a constexpr reference=
 declaration:

constexpr T && val =3D f();

This requires that the initialization be static, but it does not make the v=
ariable constant.

I believe this to be a bug, not a feature.

> [[static_init]] T val =3D f();
>=20
> Does this sound like a worthwhile feature?

It looks better than the alternative, and it certainly meets the requiremen=
ts for a valid attribute. However, I'm not clear about when this is useful.

Can you describe how you came to want this?

--=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=_958C3B10-6576-4ED1-B82E-2497101FBB35
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;10&ndash;12, at 6:44 PM, col3435 via ISO C++ Standard - Future Propos=
als &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.or=
g</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><blockquote t=
ype=3D"cite"><div dir=3D"ltr">C++11 introduced constant intialization of gl=
obals/statics, </div></blockquote><div><br></div><div>That existed since C+=
+98.</div><br><blockquote type=3D"cite"><div dir=3D"ltr">which gave us a ne=
w way to avoid the problems with initialization order of statics defined in=
 different source files.<br></div></blockquote><div><br></div><div>Little h=
as changed in this regard either. More things are constant expressions now,=
 with constexpr, and that specifier does provide an explicit guarantee agai=
nst dynamic initialization.</div><div><br></div><div>If you explicitly don&=
rsquo;t declare a <font face=3D"Courier">const</font> variable as <font fac=
e=3D"Courier">extern</font>, what you have is not one global with ambiguous=
 initialization order but a different global for each translation unit (.cp=
p file).&nbsp;My recent proposal &ldquo;inline variables&rdquo; (<a href=3D=
"http://bit.ly/1qTSBiP" class=3D"bitmark-shortlink"><span class=3D"protocol=
">http://</span>bit.ly/1qTSBiP</a>) addresses the problem.</div><br><blockq=
uote type=3D"cite"><div dir=3D"ltr">Unfortunately there is no way to check =
that a non-const variable will be statically initialized. </div></blockquot=
e><div><br></div><div>Actually, there is, but it&rsquo;s terribly obfuscate=
d. Use a constexpr reference declaration:</div><div><br></div><div><font fa=
ce=3D"Courier">constexpr T &amp;&amp; val =3D f();</font></div><div><br></d=
iv><div>This requires that the initialization be static, but it does not ma=
ke the variable constant.</div><div><br></div><div>I believe this to be a b=
ug, not a feature.</div><br><blockquote type=3D"cite"><div dir=3D"ltr">[[st=
atic_init]] T val =3D f();<br><br>Does this sound like a worthwhile feature=
?</div></blockquote><div><br></div>It looks better than the alternative, an=
d it certainly meets the requirements for a valid attribute. However, I&rsq=
uo;m not clear about when this is useful.</div><div><br></div><div>Can you =
describe how you came to want this?<br><br></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=_958C3B10-6576-4ED1-B82E-2497101FBB35--

.

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



On Sunday, 12 October 2014 12:12:06 UTC+1, David Krauss wrote:
>
>
> On 2014=E2=80=9310=E2=80=9312, at 6:44 PM, col3435 via ISO C++ Standard -=
 Future Proposals=20
> <std-pr...@isocpp.org <javascript:>> wrote:
>
> C++11 introduced constant intialization of globals/statics,=20
>
>
> That existed since C++98.
>

Fair point, I stand corrected!

=20

>
> [[static_init]] T val =3D f();
>
> Does this sound like a worthwhile feature?
>
>
> It looks better than the alternative, and it certainly meets the=20
> requirements for a valid attribute. However, I=E2=80=99m not clear about =
when this=20
> is useful.
>
> Can you describe how you came to want this?
>

I'd like to be able to rely on the order-of-initialization guarantees that=
=20
this provides. Not sure my particular use-cases would be particularly=20
compelling for you - just a few logging and debugging objects which I'd=20
like to ensure can be safely used before main(), and this seems the easiest=
=20
way to achieve that. It's just a little frustrating that there's no direct=
=20
way to check that the code behaves as expected. An explicit check would=20
both ensure correctness and also provide a useful documentation purpose.

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

<div dir=3D"ltr"><br><br>On Sunday, 12 October 2014 12:12:06 UTC+1, David K=
rauss  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"wor=
d-wrap:break-word"><br><div><div>On 2014=E2=80=9310=E2=80=9312, at 6:44 PM,=
 col3435 via ISO C++ Standard - Future Proposals &lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"VhB2yfClpB0J" onmousedown=3D"t=
his.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">std-pr...@isocpp.org</a>&gt; wrote:</div><br><blockquote typ=
e=3D"cite"><div dir=3D"ltr">C++11 introduced constant intialization of glob=
als/statics, </div></blockquote><div><br></div><div>That existed since C++9=
8.</div></div></div></blockquote><div><br>Fair point, I stand corrected!<br=
><br>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div styl=
e=3D"word-wrap:break-word"><div><br><blockquote type=3D"cite"><div dir=3D"l=
tr">[[static_init]] T val =3D f();<br><br>Does this sound like a worthwhile=
 feature?</div></blockquote><div><br></div>It looks better than the alterna=
tive, and it certainly meets the requirements for a valid attribute. Howeve=
r, I=E2=80=99m not clear about when this is useful.</div><div><br></div><di=
v>Can you describe how you came to want this?<br></div></div></blockquote><=
div><br>I'd like to be able to rely on the order-of-initialization guarante=
es that this provides. Not sure my particular use-cases would be particular=
ly compelling for you - just a few logging and debugging objects which I'd =
like to ensure can be safely used before main(), and this seems the easiest=
 way to achieve that. It's just a little frustrating that there's no direct=
 way to check that the code behaves as expected. An explicit check would bo=
th ensure correctness and also provide a useful documentation purpose.<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_2129_1211204103.1413117250859--

.

------=_Part_189_1606879690.1413197622677
Content-Type: text/plain; charset=UTF-8


On Sunday, 12 October 2014 11:44:29 UTC+1, col...@yahoo.co.uk wrote:
>
>
> The attribute indicates the programmer's intention that static
> initialization should apply, and asks the compiler to generate an error if
> it is not eligible.
>
> An attribute seems to be the perfect solution here because it does not
> actually change the meaning of the code - variables would still be
> statically initialized whether or not the attribute was used, provided that
> the appropriate conditions are met. The only effect is that the compiler is
> to give a warning if the actual meaning of the code does not match the
> intent.
>
Do you want compilers to generate errors or warnings?

--

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

<div dir=3D"ltr"><br>On Sunday, 12 October 2014 11:44:29 UTC+1, col...@yaho=
o.co.uk  wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;" class=3D"gmail_quote"><div dir=3D"ltr"><br>The attrib=
ute indicates the programmer's intention that static initialization should =
apply, and asks the compiler to generate an error if it is not eligible.<br=
><br>An attribute seems to be the perfect solution here because it does not=
 actually change the meaning of the code - variables would still be statica=
lly initialized whether or not the attribute was used, provided that the ap=
propriate conditions are met. The only effect is that the compiler is to gi=
ve a warning if the actual meaning of the code does not match the intent.<b=
r></div></blockquote><div>Do you want&nbsp;compilers to generate errors or =
warnings?&nbsp;</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_189_1606879690.1413197622677--

.

------=_Part_98_1150749648.1413202247905
Content-Type: text/plain; charset=UTF-8



On Monday, 13 October 2014 11:53:42 UTC+1, Douglas Boffey wrote:
>
>
> On Sunday, 12 October 2014 11:44:29 UTC+1, col...@yahoo.co.uk wrote:
>>
>>
>> The attribute indicates the programmer's intention that static
>> initialization should apply, and asks the compiler to generate an error if
>> it is not eligible.
>>
>> An attribute seems to be the perfect solution here because it does not
>> actually change the meaning of the code - variables would still be
>> statically initialized whether or not the attribute was used, provided that
>> the appropriate conditions are met. The only effect is that the compiler is
>> to give a warning if the actual meaning of the code does not match the
>> intent.
>>
> Do you want compilers to generate errors or warnings?
>

I'd like to see an error. But, from looking though previous attribute
proposals, I'm a little unclear on whether *requiring* an error is
considered a good idea. The "deprecated" attribute seemed to go through
some change to make it merely advisory; I'm not sure I know exactly what
the arguments were there and whether they would also apply in this case.
Still, if it's possible to make it an error, that would be ideal.

--

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

<div dir=3D"ltr"><br><br>On Monday, 13 October 2014 11:53:42 UTC+1, Douglas=
 Boffey  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=
"><br>On Sunday, 12 October 2014 11:44:29 UTC+1, <a>col...@yahoo.co.uk</a> =
 wrote:<blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;borde=
r-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid=
" class=3D"gmail_quote"><div dir=3D"ltr"><br>The attribute indicates the pr=
ogrammer's intention that static initialization should apply, and asks the =
compiler to generate an error if it is not eligible.<br><br>An attribute se=
ems to be the perfect solution here because it does not actually change the=
 meaning of the code - variables would still be statically initialized whet=
her or not the attribute was used, provided that the appropriate conditions=
 are met. The only effect is that the compiler is to give a warning if the =
actual meaning of the code does not match the intent.<br></div></blockquote=
><div>Do you want&nbsp;compilers to generate errors or warnings?</div></div=
></blockquote><div><br>I'd like to see an error. But, from looking though p=
revious attribute proposals, I'm a little unclear on whether *requiring* an=
 error is considered a good idea. The "deprecated" attribute seemed to go t=
hrough some change to make it merely advisory; I'm not sure I know exactly =
what the arguments were there and whether they would also apply in this cas=
e. Still, if it's possible to make it an error, that would be ideal.<br><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_98_1150749648.1413202247905--

.

------=_Part_3166_1449111011.1413212411180
Content-Type: text/plain; charset=UTF-8


>
>
> I'd like to be able to rely on the order-of-initialization guarantees that
> this provides. Not sure my particular use-cases would be particularly
> compelling for you - just a few logging and debugging objects which I'd
> like to ensure can be safely used before main(), and this seems the easiest
> way to achieve that. It's just a little frustrating that there's no direct
> way to check that the code behaves as expected. An explicit check would
> both ensure correctness and also provide a useful documentation purpose.
>

I am not sure, but I think modules should provide better guarantees for
order of initialization. Would that make your proposal obsolete? The
problem with initialization is a side-effect of header files. When header
files are replaced by modules, the problem should disappear altogether.

--

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

<div dir=3D"ltr"><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"><div><br>I'd like to be able to rely on the order-of-initialization gua=
rantees that this provides. Not sure my particular use-cases would be parti=
cularly compelling for you - just a few logging and debugging objects which=
 I'd like to ensure can be safely used before main(), and this seems the ea=
siest way to achieve that. It's just a little frustrating that there's no d=
irect way to check that the code behaves as expected. An explicit check wou=
ld both ensure correctness and also provide a useful documentation purpose.=
<br></div></div></blockquote><div><br></div><div>I am not sure, but I think=
 modules should provide better guarantees for order of initialization. Woul=
d that make your proposal obsolete? The problem with initialization is a si=
de-effect of header files. When header files are replaced by modules, the p=
roblem should disappear altogether.&nbsp;</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_3166_1449111011.1413212411180--

.

--Apple-Mail=_4897486D-7905-4262-8248-D36FE247495F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-10-12, at 8:34 PM, col3435 via ISO C++ Standard - Future Proposals =
<std-proposals@isocpp.org> wrote:

> I'd like to be able to rely on the order-of-initialization guarantees tha=
t this provides. Not sure my particular use-cases would be particularly com=
pelling for you - just a few logging and debugging objects which I'd like t=
o ensure can be safely used before main(), and this seems the easiest way t=
o achieve that.

Such stateful objects aren't usually statically initializable. It would mak=
e sense, I suppose, for the default constructor of vector to be constexpr, =
but it makes somewhat less sense to so purposely observe the difference.

> It's just a little frustrating that there's no direct way to check that t=
he code behaves as expected. An explicit check would both ensure correctnes=
s and also provide a useful documentation purpose.

Would using an inline wrapper function sacrifice anything?

inline logger & master_log() {
    static logger ret {};
    return ret;
}

For a statically initializable object, the initialization never has to do a=
nything and the entire function should map to a simple global variable acce=
ss.

--=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=_4897486D-7905-4262-8248-D36FE247495F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;10&ndash;12, at 8:34 PM, col3435 via ISO C++ Standard - Future Propos=
als &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.or=
g</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><blockquote t=
ype=3D"cite"><div dir=3D"ltr">I'd like to be able to rely on the order-of-i=
nitialization guarantees that this provides. Not sure my particular use-cas=
es would be particularly compelling for you - just a few logging and debugg=
ing objects which I'd like to ensure can be safely used before main(), and =
this seems the easiest way to achieve that.</div></blockquote><div><br></di=
v><div>Such stateful objects aren&rsquo;t usually statically initializable.=
 It would make sense, I suppose, for the default constructor of vector to b=
e constexpr, but it makes somewhat less sense to so purposely observe the d=
ifference.</div><br><blockquote type=3D"cite"><div dir=3D"ltr">It's just a =
little frustrating that there's no direct way to check that the code behave=
s as expected. An explicit check would both ensure correctness and also pro=
vide a useful documentation purpose.<br></div></blockquote><br></div><div>W=
ould using an inline wrapper function sacrifice anything?</div><br><div><fo=
nt face=3D"Courier">inline logger &amp; master_log() {</font></div><div><fo=
nt face=3D"Courier">&nbsp; &nbsp; static logger ret {};</font></div><div><f=
ont face=3D"Courier">&nbsp; &nbsp; return ret;</font></div><div><font face=
=3D"Courier">}</font></div><div><br></div><div>For a statically initializab=
le object, the initialization never has to do anything and the entire funct=
ion should map to a simple global variable access.</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=_4897486D-7905-4262-8248-D36FE247495F--

.