220 24308 <784f5fc0-3422-46d7-9bde-ed9b8b60f625@isocpp.org> article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Andr=C3=A9?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Choosing value categories using a specialized traits class Date: Wed, 10 Feb 2016 16:51:18 -0800 (PST) Lines: 295 Approved: news@gmane.org Message-ID: <784f5fc0-3422-46d7-9bde-ed9b8b60f625@isocpp.org> References: <20160210161034.4898896.57740.4502@gmail.com> <4718878.Khnkm2gQof@tjmaciei-mobl4> <7c278131-91ca-485b-a57f-373fa52f5ab9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_170_660383307.1455151878858" X-Trace: ger.gmane.org 1455151888 20101 80.91.229.3 (11 Feb 2016 00:51:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Feb 2016 00:51:28 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEZH2N45EFRBCFW562QKGQE36M7MDA@isocpp.org Thu Feb 11 01:51:22 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f200.google.com ([209.85.214.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aTfTe-0000AA-1u for gclcip-std-proposals@m.gmane.org; Thu, 11 Feb 2016 01:51:22 +0100 Original-Received: by mail-ob0-f200.google.com with SMTP id il1sf71059020obb.0 for ; Wed, 10 Feb 2016 16:51:21 -0800 (PST) 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 :content-type: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=M1CodpYbT/gSds/pFiOvzmp5YCQV0yl4V8eNhyU0yLo=; b=b/u70c1yC3ZYfzm7gwcT4C2Ql5vhz442WPDyUnemqiYP6qID8O0V6mp8SrF3EjVERi okgHSKoTSiu1OmrZUCM5tdoyimpRXCSn02d95/RPbrFR1rbeM+ReWEgSi2NNfowZJf3g YIz3EhB49idH3bRnbzvByOP2p3NR/2bLWVUrVYdJmAAYseLUzq8Izn8IuTEdgvtr+Lf2 dfrt9JALJVkJ2eLZ4zMLOUtYpmhCCJQMXqXtfr3mMSaG8LbjedQwOQF/8FIC8OF8Yuoj YyUlUulRFceGMotS9kUUk5sBUn07ZOyXGm+6IS7p3x1pIuTw5TYFT+J9wFQI/IPUE0qP bkOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type: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=M1CodpYbT/gSds/pFiOvzmp5YCQV0yl4V8eNhyU0yLo=; b=G4PLl0Uf3eZXG5cLu8sqRXblRBNKP5W0gT+wkdafuItELjD78cmbC1B+Y/2Cp/xZXg ZvJm5m3hzsliYmSweePfOaao6M6CezC6Sbwoy3lauWcfqtjCIZEHRPti72/BfNBPafKX aY8fka9G2q4Nj1WnvBuJKUtxTH4DHLvh9aoV5moOTHcgxOEuvt6WeAfOdszQ6dRzFdZR bsx6UVlBNBAWYm3Cfq8TEZzRW5lKwTRkLHUni3UrfIIoc0cDuOJGKIKzwr18ut8OJ110 6TyDQNcXGS1ZFpp9B7MxKggPlW2huNI3vu0oRMp1cMCAM88ZC90Q5FPGczPvw7zzfTvM 0yyQ== X-Gm-Message-State: AG10YOQyxh4chtLzBFqLEJiw7qydK7YfWcnQ9roDmEqtUbEhd9r4tWtLDLr2g8yrHwoX+w== X-Received: by 10.50.56.19 with SMTP id w19mr12394777igp.13.1455151881070; Wed, 10 Feb 2016 16:51:21 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.93.72 with SMTP id cs8ls1102099igb.29.canary; Wed, 10 Feb 2016 16:51:19 -0800 (PST) X-Received: by 10.50.66.175 with SMTP id g15mr449702igt.4.1455151879822; Wed, 10 Feb 2016 16:51:19 -0800 (PST) In-Reply-To: <7c278131-91ca-485b-a57f-373fa52f5ab9@isocpp.org> X-Original-Sender: andre.francisco@tryhype.co Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:24308 Archived-At: ------=_Part_170_660383307.1455151878858 Content-Type: multipart/alternative; boundary="----=_Part_171_348079167.1455151878859" ------=_Part_171_348079167.1455151878859 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Then again, passing by const reference could also be optimized by the=20 compiler. quinta-feira, 11 de Fevereiro de 2016 =C3=A0s 00:33:46 UTC, Andr=C3=A9 escr= eveu: > > I tend to agree, this would be better if solved at a language level. But= =20 > isn't there the downside of breaking backwards compatibility? After your= =20 > feedback I started considering how this could be solved at that level and= =20 > my thoughts go maybe to a new operator. Something like this? > > void push_back (const value_type &? val); > > > This seems quite intuitive (i.e. *is it passing by reference?*) even=20 > though this doesn't: > > void push_back (value_type &? val); > > In this case *val* must always be passed by reference, so the operator=20 > kind of loses its purpose. Either the operator would imply const or when= =20 > not const would be the same as passing by reference. > > The first thing that comes to mind is how the compiler would parse this= =20 > and whether it would add parse conflicts, but I don't think this could be= =20 > confused with the ternary operator or something of the sort, although I= =20 > need to give it some more though first. As you guys know I'm new around= =20 > here and haven't been following the forum for long, so to what extend is= =20 > the addition of a new operator OK? Or were you guys referring to somethin= g=20 > else? > > Also, I've reconsidered my initial proposal, and if this were to be solve= d=20 > at the framework level it could be solved with the first proposed solutio= n=20 > of a traits class or something less *bloaty*. Instead of a traits class= =20 > containing all those (most of them unnecessary) definitions, maybe=20 > something like this: > > void push_back (const typename argument::type val); > > This seems more intuitive and cleaner than the first approach, still=20 > resolving the problem at the framework level. Regarding the issue of tag= =20 > dispatching it would be solved the same way, but being so much more trivi= al=20 > I'm considering the rest first. Regarding exceptional cases such as the= =20 > ones you guys mentioned, this could always be specialized for them, as=20 > could the traits option, specially given Thiago's suggestion for a boolea= n=20 > alternative. > > Regarding copy-if-write, although it does seem like a great idea, am I=20 > wrong thinking that this can (and should?) be solved at a compiler level?= =20 > This can be done statically by each function marking their parameters as= =20 > either written or not and applying the flag recursively, and I don't see= =20 > the need for hints by the developer or language additions. > > All things considered, I think the operator approach is definitely the=20 > best, but using traits classes seems to be more backwards-friendly. What= =20 > are your thoughts on this? > > Again, my appreciation for your feedback. > Best regards, > Andr=C3=A9. > > quarta-feira, 10 de Fevereiro de 2016 =C3=A0s 18:51:55 UTC, Thiago Maciei= ra=20 > escreveu: >> >> On quarta-feira, 10 de fevereiro de 2016 11:10:34 PST Tony V E wrote:=20 >> > Not a bad idea.=20 >> >=20 >> > But I'd rather see some kind of language feature for param passing. A= =20 >> "pass=20 >> > by copy if cheap"=E2=80=8E syntax. Also a pass by copy-if-write (for c= ases=20 >> where=20 >> > the function body I available to determine that).=20 >> >=20 >> > Vaguely speaking.=20 >> >> Agreed.=20 >> >> For my Qt6 QVector, I have:=20 >> >> typedef typename std::conditional::value ||= =20 >> std::is_pointer::value, T, const T &>::type parameter_type;=20 >> >> Which is "good enough", but could be better. It won't catch trivial type= s=20 >> that=20 >> can be passed in registers, such as structs with size less than a=20 >> register (or=20 >> two).=20 >> >> Maybe we want a type trait (name TBD) that is true for those types. The= =20 >> standard should say that it is true at least for fundamental types and= =20 >> pointers, the rest to be implementation-defined.=20 >> >> This also goes back to the discussion on relocatable types and the=20 >> destructive=20 >> move.=20 >> >> --=20 >> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20 >> Software Architect - Intel Open Source Technology Center=20 >> >> --=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 https://groups.google.com/a/isocpp.org/group/std-propos= als/. ------=_Part_171_348079167.1455151878859 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Then again, passing by const reference could also be optim= ized by the compiler.

quinta-feira, 11 de Fevereiro de 2016 =C3=A0s = 00:33:46 UTC, Andr=C3=A9 escreveu:
I tend to agree, this would be better if solved at a= language level. But isn't there the downside of breaking backwards com= patibility? After your feedback I started considering how this could be sol= ved at that level and my thoughts go maybe to a new operator. Something lik= e this?

=
void push_back=
 (const value_type &? val);

This seems quite intuitive =C2=A0(i.e. is it passing b= y reference?) even though this doesn't:

void push_back (value_type &? val);

In t= his case val must always be passed by reference, so the operator kin= d of loses its purpose. Either the operator would imply const or when not c= onst would be the same as passing by reference.

Th= e first thing that comes to mind is how the compiler would parse this and w= hether it would add parse conflicts, but I don't think this could be co= nfused with the ternary operator or something of the sort, although I need = to give it some more though first. As you guys know I'm new around here= and haven't been following the forum for long, so to what extend is th= e addition of a new operator OK? Or were you guys referring to something el= se?

Also, I've reconsidered my initial proposa= l, and if this were to be solved at the framework level it could be solved = with the first proposed solution of a traits class or something less blo= aty. Instead of a traits class containing all those (most of them unnec= essary) definitions, maybe something like this:

void push_back (<= /span>const typename = argument<value_type>::type val);
<= br>This seems more intuitive and cleaner than the first approach, still res= olving the problem at the framework level. Regarding the issue of tag dispa= tching it would be solved the same way, but being so much more trivial I= 9;m considering the rest first. Regarding exceptional cases such as the one= s you guys mentioned, this could always be specialized for them, as could t= he traits option, specially given Thiago's suggestion for a boolean alt= ernative.

Regarding copy-if-write, although it doe= s seem like a great idea, am I wrong thinking that this can (and should?) b= e solved at a compiler level? This can be done statically by each function = marking their parameters as either written or not and applying the flag rec= ursively, and I don't see the need for hints by the developer or langua= ge additions.

All things considered, I think the o= perator approach is definitely the best, but using traits classes seems to = be more backwards-friendly. What are your thoughts on this?

<= /div>
Again, my appreciation for your feedback.
Best regards,=
Andr=C3=A9.

quarta-feira, 10 de Fevereiro de 2016 = =C3=A0s 18:51:55 UTC, Thiago Macieira escreveu:
On quarta-feira, 10 de fevereiro de 2016 11:10:34 PST Tony V E = wrote:
> Not a bad idea.=20
>=20
> But I'd rather see some kind of language feature for param pas= sing. A "pass
> by copy if cheap"=E2=80=8E syntax. Also a pass by copy-if-wri= te (for cases where
> the function body I available to determine that).=20
>=20
> Vaguely speaking.

Agreed.

For my Qt6 QVector, I have:

=C2=A0 =C2=A0 typedef typename std::conditional<std::is_fundame= ntal<T>::value ||=20
std::is_pointer<T>::value, T, const T &>::type parameter_t= ype;

Which is "good enough", but could be better. It won't cat= ch trivial types that=20
can be passed in registers, such as structs with size less than a regis= ter (or=20
two).

Maybe we want a type trait (name TBD) that is true for those types. The= =20
standard should say that it is true at least for fundamental types and= =20
pointers, the rest to be implementation-defined.

This also goes back to the discussion on relocatable types and the dest= ructive=20
move.

--=20
Thiago Macieira - thiago (AT) macieira= ..info - thiago (AT) kde.org
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center

--

---
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals= /.
------=_Part_171_348079167.1455151878859-- ------=_Part_170_660383307.1455151878858-- .