220 33151 <1aeb1633-dc02-4b08-b4dd-742dde8def5d@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: morwenn29@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: template class to do default integral types initalization Date: Fri, 7 Jul 2017 13:25:54 -0700 (PDT) Lines: 183 Approved: news@gmane.org Message-ID: <1aeb1633-dc02-4b08-b4dd-742dde8def5d@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1660_1572858438.1499459154338" X-Trace: blaine.gmane.org 1499459157 1394 195.159.176.226 (7 Jul 2017 20:25:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Jul 2017 20:25:57 +0000 (UTC) Cc: ar123456@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC2ZP4V74IFBBUW477FAKGQEGHMQJ4I@isocpp.org Fri Jul 07 22:25:51 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f71.google.com ([74.125.83.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dTZp1-0008W2-1E for gclcip-std-proposals@m.gmane.org; Fri, 07 Jul 2017 22:25:51 +0200 Original-Received: by mail-pg0-f71.google.com with SMTP id z1sf44801278pgs.10 for ; Fri, 07 Jul 2017 13:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=DhESNH/XinrLGhfv174qDSZNBZ7yAu5OgTEBjFbpvVM=; b=tF2Ita4dYtbtkheuAHyYZKWnG25CEXKghZFZpR8QZkeXQ0GN16XNPhffJYnNya7Zdh rs9FhaDxtNKQYaidRDuz0PlB4YSX5VNVZ/slvLrPawtOLhTWkeNdDjvRkzIptyyGSPmQ g7gZR4HqFvfbbna+GPmj9uZLXbLni6G3pwhe1vlnt0jQXSLNNPgyYmoMVp+ztLCiBU+e aZwvz5f7ScvUaM4GdgCQI+PnfWVNwuR33FxmSilMZjdR0ECv8AC1m/XqydKm6SNH2xI1 lazmZGupZZ0YzbnaLtBGwXYvaLMKVEoxBGKd9Qxota8kanwowyOAa05sEh55bpge9QI8 9Q/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=DhESNH/XinrLGhfv174qDSZNBZ7yAu5OgTEBjFbpvVM=; b=OmI32McGEx4jrP8LRp5UOC47muQaiEfNANn+FDWArRhvdauecyE66WODR1dvsud6yW tBXQ/4Dw+l/VGGcFJuL5rf9NOkVceiA/tHQ2DyqDYRAV/j1DQAaeWfseiWxU5oHr2RQz LmCDavgFGYDKLR2hc5lonldKZgNdS7KMg0hns9C2FKaN+kC/gAXAX0c/rIhwhFV/J0IO eN/zVLzwjmTuZSbmP8xXKri/hXpiUsP9OyymJa17i/EbOUwm/hlnFr7593ATw52zmVZo vFLl+NNFmvPe4tYeCfWKZj96DW5KLPdK5cUKKPpUqLet1iIYqJNSaaiDgLaJUgFiW3xO tewQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=DhESNH/XinrLGhfv174qDSZNBZ7yAu5OgTEBjFbpvVM=; b=qalYBUpZ8GXOZd1qgD8w4KmPawWZTUbwpxXtySm7qcNVbafSZd9gHdhUk0b0K3vitH JDjGNJZYcOyW/6yn/koIsy74Jcz1TDFuHcNfhAy3T7QA4JZXVYCpl6ZWdcXQG3kZGF1e +n/nXYWgIPU/gFsIPbUT1PPE2qsmW+cX6N4yP6Vt3DROM8aCeCnlluU/+0n3fy7CCdzO fcSlwIU3BpQMikj0SY3zuFeeulDyuxRQipZhh93oxbWYaV0O2rQu3ntaWWRNLC8VNQ76 DsjSMFEnywc2Iw9sX6l6QL258UyuzRFHO4nOftq+Va11LDVw7XHSUh3QZwwNfdxB02Xe 51Jw== X-Gm-Message-State: AIVw111IYEk7Yi0veGheY4rapMg9Zaw2AB1reAaFL7GAvkrFrd90KETZ Qsb12puBnXp0YX8R X-Received: by 10.99.44.150 with SMTP id s144mr3224527pgs.13.1499459155973; Fri, 07 Jul 2017 13:25:55 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.94.207 with SMTP id h198ls1755922itb.5.canary-gmail; Fri, 07 Jul 2017 13:25:54 -0700 (PDT) X-Received: by 10.36.57.79 with SMTP id l76mr26437ita.8.1499459154810; Fri, 07 Jul 2017 13:25:54 -0700 (PDT) In-Reply-To: X-Original-Sender: morwenn29@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:33151 Archived-At: ------=_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 > 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 valA_; > extype 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
Le vendredi 7 juillet 2017 21:09:31 UTC+2, ar a =C3=A9crit= =C2=A0:
Hi
=
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.

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.

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.

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.

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 w= rapper class to add default initialization
// to integral types.
//// PROs:
//=C2=A0=C2=A0 It seems that it will be used often
//=C2= =A0=C2=A0 It is 100% optional - does not affect existing of planned code//=C2=A0=C2=A0 It is trivially small
//=C2=A0=C2=A0 It is us= ed only in class definitions
//=C2=A0=C2=A0 It does not requi= re casts
//
// CONs:
//=C2=A0=C2=A0 Yet another thing to tra= ck and document

namespace std {

template<typename T>class extype
{
public:
=C2=A0=C2=A0=C2=A0 extype() : val_() {}=C2=A0=C2=A0=C2=A0 extype(T const& t) : val_(t) {}
=C2=A0=C2=A0=C2= =A0 extype(T&& t) : val_(move(t)) {}
=C2=A0=C2=A0=C2=A0
=C2= =A0=C2=A0=C2=A0 operator const T&() const { return val_; }
=C2=A0=C2= =A0=C2=A0 operator T&() { return val_; }
private:
=C2=A0=C2=A0=C2= =A0 T val_;
};

}

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

private:
=C2=A0=C2=A0=C2= =A0 extype<int> valA_;
=C2=A0=C2=A0=C2=A0 extype<int> valB_;=
};
=C2=A0
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.
=
I guess that it would mosty solve the problem.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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.org.
------=_Part_1661_1966872874.1499459154338-- ------=_Part_1660_1572858438.1499459154338-- .