220 30560 article Path: news.gmane.org!.POSTED!not-for-mail From: Patrice Roy Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Named constructors Date: Fri, 13 Jan 2017 16:14:32 -0500 Lines: 367 Approved: news@gmane.org Message-ID: References: <84cb007b-d3c2-4204-be97-27f7f0df0e7d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c1236fe02e8ee0546005295 X-Trace: blaine.gmane.org 1484342094 31241 195.159.176.226 (13 Jan 2017 21:14:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 13 Jan 2017 21:14:54 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDSZXMHWZIKBBOUG4XBQKGQE7U753II@isocpp.org Fri Jan 13 22:14:49 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 1cS9B8-0005vd-DJ for gclcip-std-proposals@m.gmane.org; Fri, 13 Jan 2017 22:14:30 +0100 Original-Received: by mail-pf0-f199.google.com with SMTP id f144sf149809130pfa.3 for ; Fri, 13 Jan 2017 13:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=BefVl5Wcs8SFgbABJmdMuPY2+6IAF5lvZYgg5xQ3jVk=; b=fUHbjmeia2ajBPd22lLgCt6gaW+DOaefT1C1nbzcn/GLjVotV+AVezZnyVBDCe8GX9 EgS1GUm0d/IrvitJ4uo7lq2LPMLQboainfRrd5xyZi2zNpSAC4zbVbXW2FuKo3Hsrq+Q SgEaQPtPQNl34ljGdSvJBw1MEGormLQEEy3A5Vw5LgC1Fz37CzRyABnuZq2csf2594Ri uyGfyH1yGCUnS5DpBV+WNc+ZVHGeG+WGCZMfF9idioRT1jXhb7LC9p9t3jsXQyWasygo P4cn66dAmfCWOaI3DKlAaH9EPTldz6FWf6PhEKS4s8Y+n4N0LIJEobMRUTsoikBHsTA/ 2esw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=BefVl5Wcs8SFgbABJmdMuPY2+6IAF5lvZYgg5xQ3jVk=; b=uL6phleHPhwf+VmcQ3EAwj+v8lBAFPe1tZZRdH2+FA7u2rKTw8WvpZyn0I7bwQTTZL Z/JeCEm+QsPa+qkfh93v8CipuNT7hMbbukacEIljJ8AGQsNwNXcE4Ldm35L0ORRP2k+W NNqv7uvjdHYmKEbMWQ/c1fH7gP2lOneHt1hFE8gSYqnj9geixT5VtDZ59KUni521aLz0 StTkkkmsfhMpNa6gOo0Ta+3C/+CDtA+scbFpayQAkq5l2G8cyLCXH1DCtiWEjAirP9t5 upMKOmB76SgVtM9H5Ez/rhlmvpmLy+J/DCfJS5OVGHIlY6Tt/jo7G0jGUG3GQWGA6qBV qgKQ== X-Gm-Message-State: AIkVDXKTEXjf893iG3wtE6lN4YizKshl03Ya+LbWlMjFbowb2BleWbs/lTW7PcI2UGqPkw== X-Received: by 10.99.111.142 with SMTP id k136mr7961375pgc.59.1484342074773; Fri, 13 Jan 2017 13:14:34 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.3.235 with SMTP id f98ls9915646otf.16.gmail; Fri, 13 Jan 2017 13:14:34 -0800 (PST) X-Received: by 10.176.90.139 with SMTP id w11mr10127063uae.106.1484342073996; Fri, 13 Jan 2017 13:14:33 -0800 (PST) Original-Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com. [2607:f8b0:400c:c08::22c]) by mx.google.com with ESMTPS id g82si3828373vke.199.2017.01.13.13.14.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 13:14:33 -0800 (PST) Received-SPF: pass (google.com: domain of patricer@gmail.com designates 2607:f8b0:400c:c08::22c as permitted sender) client-ip=2607:f8b0:400c:c08::22c; Original-Received: by mail-ua0-x22c.google.com with SMTP id y9so45903222uae.2 for ; Fri, 13 Jan 2017 13:14:33 -0800 (PST) X-Received: by 10.176.6.106 with SMTP id f97mr11674835uaf.118.1484342073418; Fri, 13 Jan 2017 13:14:33 -0800 (PST) Original-Received: by 10.159.35.115 with HTTP; Fri, 13 Jan 2017 13:14:32 -0800 (PST) In-Reply-To: X-Original-Sender: patricer@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of patricer@gmail.com designates 2607:f8b0:400c:c08::22c as permitted sender) smtp.mailfrom=patricer@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:30560 Archived-At: --94eb2c1236fe02e8ee0546005295 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable When I do this, I write an essentially constexpr Temperature where R is some empty tag class (Celsius, Fahrenheit, Kelvin) such that auto k =3D 273_K; // Temperature Temperature c =3D k; // converts from =C2=B0K to =C2=B0C I find this reduces the amount of conversions to write (I use a neutral unit, in this case Celsius, and I offer pre-tag to_neutral/ from_neutral constexpr conversions through per-tag traits). I find this has some =C2=ABplus=C2=BBes : - units are explicit - lots of conversions can be done at compile-time - a Temperature =C2=ABknows=C2=BB what its measurement unit is, which= can make I/O nicer Client code ends up being quite nice; such things as =C2=ABfromCelsius()=C2= =BB feel as an unsafe interface to me, making the user do things the type system could do by itself. There's a way to get a fast and safe interface with C++11 code as is. 2017-01-13 15:50 GMT-05:00 Bo Persson : > On 2017-01-12 14:07, stefan.pantos@torstonetech.com wrote: > >> I find my self regularly creating static factory functions on classes to >> better describe how something is being constructed or to avoid having >> flags passed which may have some invalid permutations. Now some times >> this is because of poor design(Lazy/efficient) but it does make me >> wonder if constructers with names different to their class would be >> helpful. >> >> Take this contrived example: >> | >> classTemperature >> { >> public: >> Temperature(floatk); >> Temperature(floatc,boolcelsiusOrFahrenheit);//An abomination >> >> floatinKelvin()const; >> floatinCelsius()const; >> floatinFahrenheit()const; >> private: >> floatkelvin; >> }; >> >> autozero =3DTemperature(0); >> autozeroC =3DTemperature(=E2=88=92273.15,true); >> autozeroF =3DTemperature(=E2=88=92459.67,false); >> >> classTemperature >> { >> public: >> structF{}; >> structC{}; >> structK{}; >> >> Temperature(floatk,K); >> Temperature(floatc,C); >> Temperature(floatf,F); >> >> floatinKelvin()const; >> floatinCelsius()const; >> floatinFahrenheit()const; >> private: >> floatkelvin; >> }; >> >> >> autozero =3DTemperature(0,Temperature::K()); >> autozeroC =3DTemperature(-273.15,Temperature::C()); >> autozeroF =3DTemperature(=E2=88=92459.67,Temperature::F()); >> >> classTemperature >> { >> public: >> staticTemperaturefromKelvin(floatk); >> staticTemperaturefromCelsius(floatc); >> staticTemperaturefromFahrenheight(floatf); >> >> floatinKelvin()const; >> floatinCelsius()const; >> floatinFahrenheit()const; >> private: >> floatkelvin; >> }; >> >> >> autozero =3DTemperature::fromKelvin(0); >> autozeroC =3DTemperature::fromCelsius(-273.15); >> autozeroF =3DTemperature::fromFahrenheight(=E2=88=92459.67); >> >> | >> >> >> First. I think most people wouldn't like the first. >> >> Second. Helpful for meta programming and I quite like it in general but >> this becomes more complex the more arguments involved. (wish I came up >> with a better example now.). >> >> Third. You cannot construct the temperature on the heap. But is as clear >> as the second. >> >> Would it be nice to do something like: >> | >> classTemperature >> { >> public: >> constructor fromKelvin(floatk); >> constructor fromCelsius(floatc); >> constructor fromFahrenheight(floatf); >> >> floatinKelvin()const; >> floatinCelsius()const; >> floatinFahrenheit()const; >> private: >> floatkelvin; >> }; >> >> >> autozero_ptr =3DnewTemperature::fromKelvin(0); >> autozeroC_ptr =3DnewTemperature::fromCelsius(-273.15); >> autozeroF_ptr =3DnewTemperature::fromFahrenheight(=E2=88=92459.67); >> | >> >> Please don't hold this against me but it does have some similarities to >> Objective-C's init methods or other languages where the argument names >> are used to select the call. >> >> > What about a pair of user defined literals > > Temperature operator""_K(long double); > Temperature operator""_C(long double); > > > Then we can just do > > auto temp =3D 273.15_K; > > > Bo Persson > > > -- > 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/is > ocpp.org/d/msgid/std-proposals/o5bein%2476p%241%40blaine.gmane.org. > --=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/CAKiZDp3G3Sjnnf2am_65BHiaFH%2B2NyhTbrkVkbf62p3bQ= iCZVg%40mail.gmail.com. --94eb2c1236fe02e8ee0546005295 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When I do this, I write an e= ssentially constexpr Temperature<R> where R is some empty tag class (= Celsius, Fahrenheit, Kelvin) such that

auto k =3D 273_K; // Te= mperature<Kelvin>
Temperature<Celsius> c =3D k; // con= verts from =C2=B0K to =C2=B0C

I find this reduces the amount o= f conversions to write (I use a neutral unit, in this case Celsius, and I o= ffer pre-tag to_neutral/ from_neutral constexpr conversions through per-tag= traits). I find this has some =C2=ABplus=C2=BBes :

  • un= its are explicit
  • lots of conversions can be done at compile-time
  • a Temperature<R> =C2=ABknows=C2=BB what its measurement unit is= , which can make I/O nicer
Client code ends up being q= uite nice; such things as =C2=ABfromCelsius()=C2=BB feel as an unsafe inter= face to me, making the user do things the type system could do by itself. T= here's a way to get a fast and safe interface with C++11 code as is.




2017-01-13 15:50 GMT-05:00 Bo Persson <bop@gmb.dk>:
On 2017-01-1= 2 14:07, stefan.pantos@torstonetech.com wrote:
I find my self regularly creating static factory functions on classes to better describe how something is being constructed or to avoid having
flags passed which may have some invalid permutations. Now some times
this is because of poor design(Lazy/efficient) but it does make me
wonder if constructers with names different to their class would be helpful= ..

Take this contrived example:
|
classTemperature
{
=C2=A0 =C2=A0public:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatk);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatc,boolcelsiusOrFahrenheit= );//An abomination

=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinKelvin()const;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinCelsius()const;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinFahrenheit()const;
=C2=A0 =C2=A0private:
=C2=A0 =C2=A0 =C2=A0 =C2=A0floatkelvin;
};

autozero =3DTemperature(0);
autozeroC =3DTemperature(=E2=88=92273.15,true);
autozeroF =3DTemperature(=E2=88=92459.67,false);

classTemperature
{
=C2=A0 =C2=A0public:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 structF{};
=C2=A0 =C2=A0 =C2=A0 =C2=A0 structC{};
=C2=A0 =C2=A0 =C2=A0 =C2=A0 structK{};

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatk,K);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatc,C);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatf,F);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinKelvin()const;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinCelsius()const;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinFahrenheit()const;
=C2=A0 =C2=A0private:
=C2=A0 =C2=A0 =C2=A0 =C2=A0floatkelvin;
};


autozero =3DTemperature(0,Temperature::K());
autozeroC =3DTemperature(-273.15,Temperature::C());
autozeroF =3DTemperature(=E2=88=92459.67,Temperature::F());

classTemperature
{
=C2=A0 =C2=A0public:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 staticTemperaturefromKelvin(floatk);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 staticTemperaturefromCelsius(floatc);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 staticTemperaturefromFahrenheight(floatf);=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinKelvin()const;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinCelsius()const;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinFahrenheit()const;
=C2=A0 =C2=A0private:
=C2=A0 =C2=A0 =C2=A0 =C2=A0floatkelvin;
};


autozero =3DTemperature::fromKelvin(0);
autozeroC =3DTemperature::fromCelsius(-273.15);
autozeroF =3DTemperature::fromFahrenheight(=E2=88=92459.67);

|


First. I think most people wouldn't like the first.

Second. Helpful for meta programming and I quite like it in general but
this becomes more complex the more arguments involved. (wish I came up
with a better example now.).

Third. You cannot construct the temperature on the heap. But is as clear as the second.

Would it be nice to do something like:
|
classTemperature
{
=C2=A0 =C2=A0public:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 constructor fromKelvin(floatk);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 constructor fromCelsius(floatc);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 constructor fromFahrenheight(floatf);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinKelvin()const;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinCelsius()const;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinFahrenheit()const;
=C2=A0 =C2=A0private:
=C2=A0 =C2=A0 =C2=A0 =C2=A0floatkelvin;
};


autozero_ptr =3DnewTemperature::fromKelvin(0);
autozeroC_ptr =3DnewTemperature::fromCelsius(-273.15);
 autozeroF_ptr =3DnewTemperature::fromFahrenheight(=E2=88=92459.67);
|

Please don't hold this against me but it does have some similarities to=
Objective-C's init methods or other languages where the argument names<= br> are used to select the call.


What about a pair of user defined literals

Temperature operator""_K(long double);
Temperature operator""_C(long double);


Then we can just do

auto temp =3D 273.15_K;


=C2=A0 =C2=A0 Bo Persson


--
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-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/isocp= p.org/d/msgid/std-proposals/o5bein%2476p%241%40blaine.gmane.org.

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3G3Sjnnf= 2am_65BHiaFH%2B2NyhTbrkVkbf62p3bQiCZVg%40mail.gmail.com.
--94eb2c1236fe02e8ee0546005295-- .