220 33150 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: template class to do default integral types initalization Date: Fri, 7 Jul 2017 12:48:13 -0700 (PDT) Lines: 187 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4871_1279382348.1499456893496" X-Trace: blaine.gmane.org 1499456901 5192 195.159.176.226 (7 Jul 2017 19:48:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Jul 2017 19:48:21 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB7WK77FAKGQE2YNP2FY@isocpp.org Fri Jul 07 21:48:17 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f199.google.com ([209.85.192.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dTZEX-0000ip-VC for gclcip-std-proposals@m.gmane.org; Fri, 07 Jul 2017 21:48:10 +0200 Original-Received: by mail-pf0-f199.google.com with SMTP id c12sf42447796pfj.12 for ; Fri, 07 Jul 2017 12:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to: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=S78UFIOeG2qN/bFZSkkapl9Q6VNapuGOzHo+1/ktXx0=; b=IjpT4FqWiwZ2rEPaFLAnnhvf1YktAR0IIq6c0ESxwuWgoNZ8mOHJ2+mCoeD4VLCDBy MPURi0Yk8gSN5JEbmdJKw83YQx27bX/b//VvhJbA5er1kZPEHRVEcuquKIdZgrnai5TG 2rzDf+GJZTYgEUk9yXWjf39CMUSuvW/OQ7K9DEvRfSDSmNMmJYOPV/Ke2rjCWIx0dj/a 4Yf6wD1YOW6bllcXawgb5IkjoDmnpKINrtTM3DLi9GzA2NGbsYVSqiTeB9ND1Jx22dFb IkkL/7VrTAyp0ceYiSKejUwoyFEmwNrVIRQ/BQ5dPznwnMeheYlss58rUqizY2D8G4G5 KDlg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to: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=S78UFIOeG2qN/bFZSkkapl9Q6VNapuGOzHo+1/ktXx0=; b=TJc/Ic/TUPUTnn0Uo+c6SdtAD8bzGQdYzBcey3fd56k+1apHWHmOXNKqS7mPjiJBfz XX0BaO2Bs+jaM3DClSITasxG/v6V0EXo1uv2o1QEkM3Xb77YXboDiEeJdIZQdsooaP1o +YvNZYUWHsKsIeMsZM+qJBOo+ZaavY9KUzhKpF1dTxFOiDFwy/9AmgffvGNF6AlpmZJf 99w2DnfQFQz9O6yKaa8kXDos4jXjcnnzdwWwB2WenOEnoSx9M9ls0guXfGpPfuC1Pzn4 nWQRGG9puNUz4voZr8sa+M3ck20kFAr7aRGMXN/oGhZ31u5697IqDnJA5gx5KA8PfkIs 2b0g== 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: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=S78UFIOeG2qN/bFZSkkapl9Q6VNapuGOzHo+1/ktXx0=; b=r4+zoyu+t1uIaQxRASG0Dd7/Z/dD9lsNKvflCrw4L1t6ZpkPzWlpTZ7ZTO1q0L8f1V sC710ZFeK+B19qaA0OZ35JywNN8o5w2YgIEqc1tlApSXC4Qv90qqr1RrB4jgJzEp5vrQ 6fS/vxs3aGMip4NIMq90IGe7GqUcVidu+FdpbHBXBa2kzOZe1Heovuu6uzCV+2fjLPEl bRt42kiSIDV4kphikHBKcafFV+2X2TTL7z1fd7vxmsQvSaZ+988jy98w42Qm7dQXOxRK oVOfJPhT4ns5Y77Ka44No+BC8K30lYPDeIUE+R8X9xn++F10K4b7WvTRshdBNz/ussgl M1cQ== X-Gm-Message-State: AIVw1116vMlxoBtDRMqnDW+i9UTO5QcgExV7YF7sQjfnagZHt8eh6cDS e2SdJhxnxjXczbdP X-Received: by 10.98.155.142 with SMTP id e14mr2732649pfk.17.1499456895093; Fri, 07 Jul 2017 12:48:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.7.142 with SMTP id f136ls1631771itf.14.canary-gmail; Fri, 07 Jul 2017 12:48:13 -0700 (PDT) X-Received: by 10.36.57.79 with SMTP id l76mr20340ita.8.1499456893921; Fri, 07 Jul 2017 12:48:13 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:33150 Archived-At: ------=_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 > > 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 >> 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 valA_; >> extype valB_; >> }; >> > > It seems to me that int valA_=0 is easier to type and understand > than extype 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


On Friday, July 7, 2017 at 3:42:56 PM UTC-4, Britt= any Friedman wrote:


On Fri, Jul 7, 2017 at 2:09 P= M, ar <ar12...@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=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_;=
};

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<int> valA_ =C2=A0 . Do you disagree?

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

--
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/e6e12e8b-3a62-4863-b49f-1b244278c7e2= %40isocpp.org.
------=_Part_4872_1333723530.1499456893496-- ------=_Part_4871_1279382348.1499456893496-- .