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

Hi

I am an application developer in the telcom industry with 30+ years of
experience with 15+ years of heavy c++ for high end networking devices.

I am working with code bases that started well  over 15 years ago and there
is no end in sight, hence, writing maintainable code is of natural interest
to me.

One of the ideas in this area is to have all members to have default
constructors. If encapsulating class is copyable/movable/assignable,
members should have copy/move/assignment. Hence, adding new members would
not require changes in constructors/assignments.

Hence everybody have to write its own wrapper providing default constructor
for integral types. I do believe that this approach has a lot of merit and
it will be popular, hence, it makes sense to support it in standard library
to avoid dealing with 10000 implementations of the same simple idea.

The example is below.

Thank you,

Aleksey Romanov

===============================================================


// Trivial wrapper class to add default initialization
// to integral types.
//
// PROs:
//   It seems that it will be used often
//   It is 100% optional - does not affect existing of planned code
//   It is trivially small
//   It is used only in class definitions
//   It does not require casts
//
// CONs:
//   Yet another thing to track and document

namespace std {

template<typename T>
class extype
{
public:
    extype() : val_() {}
    extype(T const& t) : val_(t) {}
    extype(T&& t) : val_(move(t)) {}

    operator const T&() const { return val_; }
    operator T&() { return val_; }
private:
    T val_;
};

}

// Usage example is below
//
// Note:
//   1. The extype is used only inside class.
//   2. Resolves code maintenance issue: if valC_ is added
//      there is no need to make chages in constructors
class X {
public:
    X() {}
    ...
    int valA() const { return valA_; }
    int valB() const { return valB_; }

private:
    extype<int> valA_;
    extype<int> valB_;
};

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfXA1B3TD29whzpCcuMH3H63nbp8tOWn1f3E7HBEnC6piYFkA%40mail.gmail.com.

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

<div dir=3D"ltr">Hi<br><br>I am an application developer in the telcom indu=
stry with
 30+ years of experience with 15+ years of heavy c++ for high end=20
networking devices.<br><br>I am working with code bases that started=20
well=C2=A0 over 15 years ago and there is no end in sight, hence, writing=
=20
maintainable code is of natural interest to me.<br><div><br></div><div>One
 of the ideas in this area is to have all members to have default=20
constructors. If encapsulating class is copyable/movable/assignable,=20
members should have copy/move/assignment. Hence, adding new members would n=
ot require changes in constructors/assignments.<br><br></div><div>Hence
 everybody have to write its own wrapper providing default constructor=20
for integral types. I do believe that this approach has a lot of merit=20
and it will be popular, hence, it makes sense to support it in standard=20
library to avoid dealing with 10000 implementations of the same simple=20
idea.<br><br></div><div>The example is below.<br></div><div><br></div><div>=
Thank you,<br><br></div><div>Aleksey Romanov<br><br>=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<wbr>=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D<wbr>=3D=3D=3D<br></div><div><br></div><div><br>// Trivial w=
rapper class to add default initialization<br>// to integral types.<br>//<b=
r>// PROs:<br>//=C2=A0=C2=A0 It seems that it will be used often<br>//=C2=
=A0=C2=A0 It is 100% optional - does not affect existing of planned code<br=
>//=C2=A0=C2=A0 It is trivially small<br></div><div>//=C2=A0=C2=A0 It is us=
ed only in class definitions<br></div><div>//=C2=A0=C2=A0 It does not requi=
re casts<br></div>//<br>// CONs:<br>//=C2=A0=C2=A0 Yet another thing to tra=
ck and document<br><br>namespace std {<br><br>template&lt;typename T&gt;<br=
>class extype<br>{<br>public:<br>=C2=A0=C2=A0=C2=A0 extype() : val_() {}<br=
>=C2=A0=C2=A0=C2=A0 extype(T const&amp; t) : val_(t) {}<br>=C2=A0=C2=A0=C2=
=A0 extype(T&amp;&amp; t) : val_(move(t)) {}<br>=C2=A0=C2=A0=C2=A0 <br>=C2=
=A0=C2=A0=C2=A0 operator const T&amp;() const { return val_; }<br>=C2=A0=C2=
=A0=C2=A0 operator T&amp;() { return val_; }<br>private:<br>=C2=A0=C2=A0=C2=
=A0 T val_;<br>};<br><br>}<br><br>// Usage example is below<br>//<br>// Not=
e:<br>//=C2=A0=C2=A0 1. The extype is used only inside class.<br>//=C2=A0=
=C2=A0 2. Resolves code maintenance issue: if valC_ is added<br>//=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 there is no need to make chages in constructors<br>cl=
ass X {<br>public:<br>=C2=A0=C2=A0=C2=A0 X() {}<br>=C2=A0=C2=A0=C2=A0 ...<b=
r>=C2=A0=C2=A0=C2=A0 int valA() const { return valA_; }<br>=C2=A0=C2=A0=C2=
=A0 int valB() const { return valB_; }<br><br>private:<br>=C2=A0=C2=A0=C2=
=A0 extype&lt;int&gt; valA_;<br>=C2=A0=C2=A0=C2=A0 extype&lt;int&gt; valB_;=
<br>};</div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfXA1B3TD29whzpCcuMH3H63nbp8tOWn1=
f3E7HBEnC6piYFkA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfXA1B3TD29=
whzpCcuMH3H63nbp8tOWn1f3E7HBEnC6piYFkA%40mail.gmail.com</a>.<br />

--001a1145b8deec121d0553bef876--

.

--94eb2c06001a770cb40553bf705c
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 7, 2017 at 2:09 PM, ar <ar123456@gmail.com> wrote:

> Hi
>
> I am an application developer in the telcom industry with 30+ years of
> experience with 15+ years of heavy c++ for high end networking devices.
>
> I am working with code bases that started well  over 15 years ago and
> there is no end in sight, hence, writing maintainable code is of natural
> interest to me.
>
> One of the ideas in this area is to have all members to have default
> constructors. If encapsulating class is copyable/movable/assignable,
> members should have copy/move/assignment. Hence, adding new members would
> not require changes in constructors/assignments.
>
> Hence everybody have to write its own wrapper providing default
> constructor for integral types. I do believe that this approach has a lot
> of merit and it will be popular, hence, it makes sense to support it in
> standard library to avoid dealing with 10000 implementations of the same
> simple idea.
>
> The example is below.
>
> Thank you,
>
> Aleksey Romanov
>
> ===============================================================
>
>
> // Trivial wrapper class to add default initialization
> // to integral types.
> //
> // PROs:
> //   It seems that it will be used often
> //   It is 100% optional - does not affect existing of planned code
> //   It is trivially small
> //   It is used only in class definitions
> //   It does not require casts
> //
> // CONs:
> //   Yet another thing to track and document
>
> namespace std {
>
> template<typename T>
> class extype
> {
> public:
>     extype() : val_() {}
>     extype(T const& t) : val_(t) {}
>     extype(T&& t) : val_(move(t)) {}
>
>     operator const T&() const { return val_; }
>     operator T&() { return val_; }
> private:
>     T val_;
> };
>
> }
>
> // Usage example is below
> //
> // Note:
> //   1. The extype is used only inside class.
> //   2. Resolves code maintenance issue: if valC_ is added
> //      there is no need to make chages in constructors
> class X {
> public:
>     X() {}
>     ...
>     int valA() const { return valA_; }
>     int valB() const { return valB_; }
>
> private:
>     extype<int> valA_;
>     extype<int> valB_;
> };
>

It seems to me that    int valA_=0    is easier to type and understand than
   extype<int> valA_   . Do you disagree?

It looks like you can use -Weffc++  in clang/gcc to find uninitialized
members. Together this would address your concerns i think.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeSiSzAXC9UFrL6mWEVjLJdG%3Dd7N03O0FV_iA0nv8i21YA%40mail.gmail.com.

--94eb2c06001a770cb40553bf705c
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 Fri, Jul 7, 2017 at 2:09 PM, ar <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:ar123456@gmail.com" target=3D"_blank">ar123456@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r">Hi<br><br>I am an application developer in the telcom industry with
 30+ years of experience with 15+ years of heavy c++ for high end=20
networking devices.<br><br>I am working with code bases that started=20
well=C2=A0 over 15 years ago and there is no end in sight, hence, writing=
=20
maintainable code is of natural interest to me.<br><div><br></div><div>One
 of the ideas in this area is to have all members to have default=20
constructors. If encapsulating class is copyable/movable/assignable,=20
members should have copy/move/assignment. Hence, adding new members would n=
ot require changes in constructors/assignments.<br><br></div><div>Hence
 everybody have to write its own wrapper providing default constructor=20
for integral types. I do believe that this approach has a lot of merit=20
and it will be popular, hence, it makes sense to support it in standard=20
library to avoid dealing with 10000 implementations of the same simple=20
idea.<br><br></div><div>The example is below.<br></div><div><br></div><div>=
Thank you,<br><br></div><div>Aleksey Romanov<br><br>=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<wbr>=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D<wbr>=3D=3D=3D<br></div><div><br></div><div><br>// Trivial w=
rapper class to add default initialization<br>// to integral types.<br>//<b=
r>// PROs:<br>//=C2=A0=C2=A0 It seems that it will be used often<br>//=C2=
=A0=C2=A0 It is 100% optional - does not affect existing of planned code<br=
>//=C2=A0=C2=A0 It is trivially small<br></div><div>//=C2=A0=C2=A0 It is us=
ed only in class definitions<br></div><div>//=C2=A0=C2=A0 It does not requi=
re casts<br></div>//<br>// CONs:<br>//=C2=A0=C2=A0 Yet another thing to tra=
ck and document<br><br>namespace std {<br><br>template&lt;typename T&gt;<br=
>class extype<br>{<br>public:<br>=C2=A0=C2=A0=C2=A0 extype() : val_() {}<br=
>=C2=A0=C2=A0=C2=A0 extype(T const&amp; t) : val_(t) {}<br>=C2=A0=C2=A0=C2=
=A0 extype(T&amp;&amp; t) : val_(move(t)) {}<br>=C2=A0=C2=A0=C2=A0 <br>=C2=
=A0=C2=A0=C2=A0 operator const T&amp;() const { return val_; }<br>=C2=A0=C2=
=A0=C2=A0 operator T&amp;() { return val_; }<br>private:<br>=C2=A0=C2=A0=C2=
=A0 T val_;<br>};<br><br>}<br><br>// Usage example is below<br>//<br>// Not=
e:<br>//=C2=A0=C2=A0 1. The extype is used only inside class.<br>//=C2=A0=
=C2=A0 2. Resolves code maintenance issue: if valC_ is added<br>//=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 there is no need to make chages in constructors<br>cl=
ass X {<br>public:<br>=C2=A0=C2=A0=C2=A0 X() {}<br>=C2=A0=C2=A0=C2=A0 ...<b=
r>=C2=A0=C2=A0=C2=A0 int valA() const { return valA_; }<br>=C2=A0=C2=A0=C2=
=A0 int valB() const { return valB_; }<br><br>private:<br>=C2=A0=C2=A0=C2=
=A0 extype&lt;int&gt; valA_;<br>=C2=A0=C2=A0=C2=A0 extype&lt;int&gt; valB_;=
<br>};</div></blockquote><div><br></div>It seems to me that =C2=A0 =C2=A0in=
t valA_=3D0 =C2=A0 =C2=A0is easier to type and understand than =C2=A0 =C2=
=A0extype&lt;int&gt; valA_ =C2=A0 . Do you disagree?<div><br></div><div>It =
looks like you can use -Weffc++ =C2=A0in clang/gcc to find uninitialized me=
mbers. Together this would address your concerns i think.</div></div><br></=
div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeSiSzAXC9UFrL6mWEVjLJdG%3Dd7N=
03O0FV_iA0nv8i21YA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeSiSz=
AXC9UFrL6mWEVjLJdG%3Dd7N03O0FV_iA0nv8i21YA%40mail.gmail.com</a>.<br />

--94eb2c06001a770cb40553bf705c--

.

------=_Part_5006_1811496403.1499456797683
Content-Type: multipart/alternative;
 boundary="----=_Part_5007_1966662172.1499456797683"

------=_Part_5007_1966662172.1499456797683
Content-Type: text/plain; charset="UTF-8"

On Friday, July 7, 2017 at 3:09:31 PM UTC-4, ar wrote:
>
> Hi
>
> I am an application developer in the telcom industry with 30+ years of
> experience with 15+ years of heavy c++ for high end networking devices.
>
> I am working with code bases that started well  over 15 years ago and
> there is no end in sight, hence, writing maintainable code is of natural
> interest to me.
>
> One of the ideas in this area is to have all members to have default
> constructors. If encapsulating class is copyable/movable/assignable,
> members should have copy/move/assignment. Hence, adding new members would
> not require changes in constructors/assignments.
>
> Hence everybody have to write its own wrapper providing default
> constructor for integral types. I do believe that this approach has a lot
> of merit and it will be popular, hence, it makes sense to support it in
> standard library to avoid dealing with 10000 implementations of the same
> simple idea.
>
> The example is below.
>

So you want a wrapper that forces *value initialization* on trivial types.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8df877a7-658d-48bb-887b-0df4fd67a857%40isocpp.org.

------=_Part_5007_1966662172.1499456797683
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, July 7, 2017 at 3:09:31 PM UTC-4, ar wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi<br><br>I am an=
 application developer in the telcom industry with
 30+ years of experience with 15+ years of heavy c++ for high end=20
networking devices.<br><br>I am working with code bases that started=20
well=C2=A0 over 15 years ago and there is no end in sight, hence, writing=
=20
maintainable code is of natural interest to me.<br><div><br></div><div>One
 of the ideas in this area is to have all members to have default=20
constructors. If encapsulating class is copyable/movable/assignable,=20
members should have copy/move/assignment. Hence, adding new members would n=
ot require changes in constructors/assignments.<br><br></div><div>Hence
 everybody have to write its own wrapper providing default constructor=20
for integral types. I do believe that this approach has a lot of merit=20
and it will be popular, hence, it makes sense to support it in standard=20
library to avoid dealing with 10000 implementations of the same simple=20
idea.<br><br></div><div>The example is below.<br></div></div></blockquote><=
div><br>So you want a wrapper that forces <i>value initialization</i> on tr=
ivial types.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8df877a7-658d-48bb-887b-0df4fd67a857%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8df877a7-658d-48bb-887b-0df4fd67a857=
%40isocpp.org</a>.<br />

------=_Part_5007_1966662172.1499456797683--

------=_Part_5006_1811496403.1499456797683--

.

------=_Part_4871_1279382348.1499456893496
Content-Type: multipart/alternative;
 boundary="----=_Part_4872_1333723530.1499456893496"

------=_Part_4872_1333723530.1499456893496
Content-Type: text/plain; charset="UTF-8"



On Friday, July 7, 2017 at 3:42:56 PM UTC-4, Brittany Friedman wrote:
>
>
>
> On Fri, Jul 7, 2017 at 2:09 PM, ar <ar12...@gmail.com <javascript:>>
> wrote:
>
>> Hi
>>
>> I am an application developer in the telcom industry with 30+ years of
>> experience with 15+ years of heavy c++ for high end networking devices.
>>
>> I am working with code bases that started well  over 15 years ago and
>> there is no end in sight, hence, writing maintainable code is of natural
>> interest to me.
>>
>> One of the ideas in this area is to have all members to have default
>> constructors. If encapsulating class is copyable/movable/assignable,
>> members should have copy/move/assignment. Hence, adding new members would
>> not require changes in constructors/assignments.
>>
>> Hence everybody have to write its own wrapper providing default
>> constructor for integral types. I do believe that this approach has a lot
>> of merit and it will be popular, hence, it makes sense to support it in
>> standard library to avoid dealing with 10000 implementations of the same
>> simple idea.
>>
>> The example is below.
>>
>> Thank you,
>>
>> Aleksey Romanov
>>
>> ===============================================================
>>
>>
>> // Trivial wrapper class to add default initialization
>> // to integral types.
>> //
>> // PROs:
>> //   It seems that it will be used often
>> //   It is 100% optional - does not affect existing of planned code
>> //   It is trivially small
>> //   It is used only in class definitions
>> //   It does not require casts
>> //
>> // CONs:
>> //   Yet another thing to track and document
>>
>> namespace std {
>>
>> template<typename T>
>> class extype
>> {
>> public:
>>     extype() : val_() {}
>>     extype(T const& t) : val_(t) {}
>>     extype(T&& t) : val_(move(t)) {}
>>
>>     operator const T&() const { return val_; }
>>     operator T&() { return val_; }
>> private:
>>     T val_;
>> };
>>
>> }
>>
>> // Usage example is below
>> //
>> // Note:
>> //   1. The extype is used only inside class.
>> //   2. Resolves code maintenance issue: if valC_ is added
>> //      there is no need to make chages in constructors
>> class X {
>> public:
>>     X() {}
>>     ...
>>     int valA() const { return valA_; }
>>     int valB() const { return valB_; }
>>
>> private:
>>     extype<int> valA_;
>>     extype<int> valB_;
>> };
>>
>
> It seems to me that    int valA_=0    is easier to type and understand
> than    extype<int> valA_   . Do you disagree?
>

Or even easier, `int valA{};`. Both syntaxes can go in member subobject
declarations as well as ordinary variables.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e6e12e8b-3a62-4863-b49f-1b244278c7e2%40isocpp.org.

------=_Part_4872_1333723530.1499456893496
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, July 7, 2017 at 3:42:56 PM UTC-4, Britt=
any Friedman wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><br><div><br><div class=3D"gmail_quote">On Fri, Jul 7, 2017 at 2:09 P=
M, ar <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"JaCYIHwNAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">ar12...@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi<br><br>I am an=
 application developer in the telcom industry with
 30+ years of experience with 15+ years of heavy c++ for high end=20
networking devices.<br><br>I am working with code bases that started=20
well=C2=A0 over 15 years ago and there is no end in sight, hence, writing=
=20
maintainable code is of natural interest to me.<br><div><br></div><div>One
 of the ideas in this area is to have all members to have default=20
constructors. If encapsulating class is copyable/movable/assignable,=20
members should have copy/move/assignment. Hence, adding new members would n=
ot require changes in constructors/assignments.<br><br></div><div>Hence
 everybody have to write its own wrapper providing default constructor=20
for integral types. I do believe that this approach has a lot of merit=20
and it will be popular, hence, it makes sense to support it in standard=20
library to avoid dealing with 10000 implementations of the same simple=20
idea.<br><br></div><div>The example is below.<br></div><div><br></div><div>=
Thank you,<br><br></div><div>Aleksey Romanov<br><br>=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<wbr>=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D<wbr>=3D=3D=3D<br></div><div><br></div><div><br>// Trivial w=
rapper class to add default initialization<br>// to integral types.<br>//<b=
r>// PROs:<br>//=C2=A0=C2=A0 It seems that it will be used often<br>//=C2=
=A0=C2=A0 It is 100% optional - does not affect existing of planned code<br=
>//=C2=A0=C2=A0 It is trivially small<br></div><div>//=C2=A0=C2=A0 It is us=
ed only in class definitions<br></div><div>//=C2=A0=C2=A0 It does not requi=
re casts<br></div>//<br>// CONs:<br>//=C2=A0=C2=A0 Yet another thing to tra=
ck and document<br><br>namespace std {<br><br>template&lt;typename T&gt;<br=
>class extype<br>{<br>public:<br>=C2=A0=C2=A0=C2=A0 extype() : val_() {}<br=
>=C2=A0=C2=A0=C2=A0 extype(T const&amp; t) : val_(t) {}<br>=C2=A0=C2=A0=C2=
=A0 extype(T&amp;&amp; t) : val_(move(t)) {}<br>=C2=A0=C2=A0=C2=A0 <br>=C2=
=A0=C2=A0=C2=A0 operator const T&amp;() const { return val_; }<br>=C2=A0=C2=
=A0=C2=A0 operator T&amp;() { return val_; }<br>private:<br>=C2=A0=C2=A0=C2=
=A0 T val_;<br>};<br><br>}<br><br>// Usage example is below<br>//<br>// Not=
e:<br>//=C2=A0=C2=A0 1. The extype is used only inside class.<br>//=C2=A0=
=C2=A0 2. Resolves code maintenance issue: if valC_ is added<br>//=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 there is no need to make chages in constructors<br>cl=
ass X {<br>public:<br>=C2=A0=C2=A0=C2=A0 X() {}<br>=C2=A0=C2=A0=C2=A0 ...<b=
r>=C2=A0=C2=A0=C2=A0 int valA() const { return valA_; }<br>=C2=A0=C2=A0=C2=
=A0 int valB() const { return valB_; }<br><br>private:<br>=C2=A0=C2=A0=C2=
=A0 extype&lt;int&gt; valA_;<br>=C2=A0=C2=A0=C2=A0 extype&lt;int&gt; valB_;=
<br>};</div></blockquote><div><br></div>It seems to me that =C2=A0 =C2=A0in=
t valA_=3D0 =C2=A0 =C2=A0is easier to type and understand than =C2=A0 =C2=
=A0extype&lt;int&gt; valA_ =C2=A0 . Do you disagree?</div></div></div></blo=
ckquote><div><br>Or even easier, `int valA{};`. Both syntaxes can go in mem=
ber subobject declarations as well as ordinary variables.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e6e12e8b-3a62-4863-b49f-1b244278c7e2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e6e12e8b-3a62-4863-b49f-1b244278c7e2=
%40isocpp.org</a>.<br />

------=_Part_4872_1333723530.1499456893496--

------=_Part_4871_1279382348.1499456893496--

.

------=_Part_1660_1572858438.1499459154338
Content-Type: multipart/alternative;
 boundary="----=_Part_1661_1966872874.1499459154338"

------=_Part_1661_1966872874.1499459154338
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le vendredi 7 juillet 2017 21:09:31 UTC+2, ar a =C3=A9crit :
>
> Hi
>
> I am an application developer in the telcom industry with 30+ years of=20
> experience with 15+ years of heavy c++ for high end networking devices.
>
> I am working with code bases that started well  over 15 years ago and=20
> there is no end in sight, hence, writing maintainable code is of natural=
=20
> interest to me.
>
> One of the ideas in this area is to have all members to have default=20
> constructors. If encapsulating class is copyable/movable/assignable,=20
> members should have copy/move/assignment. Hence, adding new members would=
=20
> not require changes in constructors/assignments.
>
> Hence everybody have to write its own wrapper providing default=20
> constructor for integral types. I do believe that this approach has a lot=
=20
> of merit and it will be popular, hence, it makes sense to support it in=
=20
> standard library to avoid dealing with 10000 implementations of the same=
=20
> simple idea.
>
> The example is below.
>
> Thank you,
>
> Aleksey Romanov
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
> // Trivial wrapper class to add default initialization
> // to integral types.
> //
> // PROs:
> //   It seems that it will be used often
> //   It is 100% optional - does not affect existing of planned code
> //   It is trivially small
> //   It is used only in class definitions
> //   It does not require casts
> //
> // CONs:
> //   Yet another thing to track and document
>
> namespace std {
>
> template<typename T>
> class extype
> {
> public:
>     extype() : val_() {}
>     extype(T const& t) : val_(t) {}
>     extype(T&& t) : val_(move(t)) {}
>    =20
>     operator const T&() const { return val_; }
>     operator T&() { return val_; }
> private:
>     T val_;
> };
>
> }
>
> // Usage example is below
> //
> // Note:
> //   1. The extype is used only inside class.
> //   2. Resolves code maintenance issue: if valC_ is added
> //      there is no need to make chages in constructors
> class X {
> public:
>     X() {}
>     ...
>     int valA() const { return valA_; }
>     int valB() const { return valB_; }
>
> private:
>     extype<int> valA_;
>     extype<int> valB_;
> };
>
=20
If the proposal for an [[uninitialized]] attribute makes it into the=20
standard, then compilers should be able to warn more agressively about=20
unmarked uninitialized integer variables.

I guess that it would mosty solve the problem.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1aeb1633-dc02-4b08-b4dd-742dde8def5d%40isocpp.or=
g.

------=_Part_1661_1966872874.1499459154338
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le vendredi 7 juillet 2017 21:09:31 UTC+2, ar a =C3=A9crit=
=C2=A0:<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">Hi<br>=
<br>I am an application developer in the telcom industry with
 30+ years of experience with 15+ years of heavy c++ for high end=20
networking devices.<br><br>I am working with code bases that started=20
well=C2=A0 over 15 years ago and there is no end in sight, hence, writing=
=20
maintainable code is of natural interest to me.<br><div><br></div><div>One
 of the ideas in this area is to have all members to have default=20
constructors. If encapsulating class is copyable/movable/assignable,=20
members should have copy/move/assignment. Hence, adding new members would n=
ot require changes in constructors/assignments.<br><br></div><div>Hence
 everybody have to write its own wrapper providing default constructor=20
for integral types. I do believe that this approach has a lot of merit=20
and it will be popular, hence, it makes sense to support it in standard=20
library to avoid dealing with 10000 implementations of the same simple=20
idea.<br><br></div><div>The example is below.<br></div><div><br></div><div>=
Thank you,<br><br></div><div>Aleksey Romanov<br><br>=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<wbr>=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D<wbr>=3D=3D=3D<br></div><div><br></div><div><br>// Trivial w=
rapper class to add default initialization<br>// to integral types.<br>//<b=
r>// PROs:<br>//=C2=A0=C2=A0 It seems that it will be used often<br>//=C2=
=A0=C2=A0 It is 100% optional - does not affect existing of planned code<br=
>//=C2=A0=C2=A0 It is trivially small<br></div><div>//=C2=A0=C2=A0 It is us=
ed only in class definitions<br></div><div>//=C2=A0=C2=A0 It does not requi=
re casts<br></div>//<br>// CONs:<br>//=C2=A0=C2=A0 Yet another thing to tra=
ck and document<br><br>namespace std {<br><br>template&lt;typename T&gt;<br=
>class extype<br>{<br>public:<br>=C2=A0=C2=A0=C2=A0 extype() : val_() {}<br=
>=C2=A0=C2=A0=C2=A0 extype(T const&amp; t) : val_(t) {}<br>=C2=A0=C2=A0=C2=
=A0 extype(T&amp;&amp; t) : val_(move(t)) {}<br>=C2=A0=C2=A0=C2=A0 <br>=C2=
=A0=C2=A0=C2=A0 operator const T&amp;() const { return val_; }<br>=C2=A0=C2=
=A0=C2=A0 operator T&amp;() { return val_; }<br>private:<br>=C2=A0=C2=A0=C2=
=A0 T val_;<br>};<br><br>}<br><br>// Usage example is below<br>//<br>// Not=
e:<br>//=C2=A0=C2=A0 1. The extype is used only inside class.<br>//=C2=A0=
=C2=A0 2. Resolves code maintenance issue: if valC_ is added<br>//=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 there is no need to make chages in constructors<br>cl=
ass X {<br>public:<br>=C2=A0=C2=A0=C2=A0 X() {}<br>=C2=A0=C2=A0=C2=A0 ...<b=
r>=C2=A0=C2=A0=C2=A0 int valA() const { return valA_; }<br>=C2=A0=C2=A0=C2=
=A0 int valB() const { return valB_; }<br><br>private:<br>=C2=A0=C2=A0=C2=
=A0 extype&lt;int&gt; valA_;<br>=C2=A0=C2=A0=C2=A0 extype&lt;int&gt; valB_;=
<br>};</div></blockquote><div>=C2=A0<br>If the proposal for an [[uninitiali=
zed]] attribute makes it into the standard, then compilers should be able t=
o warn more agressively about unmarked uninitialized integer variables.<br>=
<br>I guess that it would mosty solve the problem.<br><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1aeb1633-dc02-4b08-b4dd-742dde8def5d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1aeb1633-dc02-4b08-b4dd-742dde8def5d=
%40isocpp.org</a>.<br />

------=_Part_1661_1966872874.1499459154338--

------=_Part_1660_1572858438.1499459154338--

.