220 24306 <7c278131-91ca-485b-a57f-373fa52f5ab9@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:33:46 -0800 (PST) Lines: 286 Approved: news@gmane.org Message-ID: <7c278131-91ca-485b-a57f-373fa52f5ab9@isocpp.org> References: <20160210161034.4898896.57740.4502@gmail.com> <4718878.Khnkm2gQof@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_130_557186018.1455150826446" X-Trace: ger.gmane.org 1455150836 2602 80.91.229.3 (11 Feb 2016 00:33:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Feb 2016 00:33:56 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEZH2N45EFRB25N562QKGQECM5SEJY@isocpp.org Thu Feb 11 01:33:50 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f199.google.com ([209.85.213.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aTfCg-0000P9-1K for gclcip-std-proposals@m.gmane.org; Thu, 11 Feb 2016 01:33:50 +0100 Original-Received: by mail-ig0-f199.google.com with SMTP id ik10sf63132110igb.2 for ; Wed, 10 Feb 2016 16:33:49 -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=Osfy0C5/KVQgGcqkBIJURM3sKAtWFtOn4bVf6/iPtBk=; b=gCSlPGHMatpAo9MNRsePI4l23jBBYISdTDyFva6KvyIHYB2WvpO/gqjmZ7HwoiuWvt mGkb/XMRYgGLeHnk9fsBrkMx718Tql/I7Sk5YLxI6yijN40pKoXnsnyoq9x6jioJFDJo F5g3Yhz0tLfIBIKpjqVCU8GmQFeYsbkiMOz988MAenHy2UaJu/i+kRIeeXQ0oPO8wQC4 +cItYq51N8vdcwbnOc+Zq5M4OvKrjtRc7MiGxzcbE54sF4Fm7PlrG4+AnVaTpEy9DzP3 QjIPDJVdlOJ2nrqwK6smYc//QLdDJ2IOtZ01Xwd/Ax1/0UJSy6rYZbfrtM5OLqXih7yN cl6Q== 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=Osfy0C5/KVQgGcqkBIJURM3sKAtWFtOn4bVf6/iPtBk=; b=SGdN3PefK1MOziWu43O3hSYVaCU7YVl7ANChHAX/sqdqnG3S/6bhClNy8qOuFra1Fr cUIHkFSwlRjW2fzt6MQZ4pkW+nTdPwKAQyoyoKnTWKCK5NsLnVlpa1gxtNxKYCmOwDel 6t9WBt0eqizV/jF9s8leeIZ+HdJVhxmAMWFz0HJ7FIfn42pZiqpmBanFuY5ifrPlkAb6 pZwcdW1j7O0qRB6AhtZny6E0ts4vE5qJ/2pqyZQA5gDJE3EJQGUMw2Jchki+5Xr3Xmlw S69jwaiDy2m1QjXyQDoa89ihUokNN5I/l1pQp8Di6TdGL2x1urnnPDi/MGf9SFDwggH7 jYEg== X-Gm-Message-State: AG10YOQsuBnQxLI3sFGg7M29uknvnsUp4pnHAx6TPVZXKVrBUtw7yLhruyE9sYQK4aVxWg== X-Received: by 10.182.46.201 with SMTP id x9mr14178361obm.43.1455150828815; Wed, 10 Feb 2016 16:33:48 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.158.20 with SMTP id h20ls331573ioe.98.gmail; Wed, 10 Feb 2016 16:33:47 -0800 (PST) X-Received: by 10.50.77.75 with SMTP id q11mr502766igw.9.1455150827578; Wed, 10 Feb 2016 16:33:47 -0800 (PST) In-Reply-To: <4718878.Khnkm2gQof@tjmaciei-mobl4> 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:24306 Archived-At: ------=_Part_130_557186018.1455150826446 Content-Type: multipart/alternative; boundary="----=_Part_131_987651911.1455150826453" ------=_Part_131_987651911.1455150826453 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 kind= =20 of loses its purpose. Either the operator would imply const or when not=20 const would be the same as passing by reference. The first thing that comes to mind is how the compiler would parse this and= =20 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 something= =20 else? Also, I've reconsidered my initial proposal, and if this were to be solved= =20 at the framework level it could be solved with the first proposed solution= =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 trivial= =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 boolean= =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 Macieira= =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 ca= ses 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 types= =20 > that=20 > can be passed in registers, such as structs with size less than a registe= r=20 > (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_131_987651911.1455150826453 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I tend to agree, this would be better if solved at a langu= age level. But isn't there the downside of breaking backwards compatibi= lity? After your feedback I started considering how this could be solved at= that level and my thoughts go maybe to a new operator. Something like this= ?

void push_b=
ack (const value_type &?=
 val);

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

=
void push_back (value_type &? val);

In this case val must always be passed by reference, so the operator kind of loses its pu= rpose. Either the operator would imply const or when not const would be the= same as passing by reference.

The first thing tha= t comes to mind is how the compiler would parse this and whether it would a= dd parse conflicts, but I don't think this could be confused with the t= ernary operator or something of the sort, although I need to give it some m= ore 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 the addition of a n= ew operator OK? Or were you guys referring to something else?
Also, I've reconsidered my initial proposal, and if this we= re to be solved at the framework level it could be solved with the first pr= oposed solution of a traits class or something less bloaty. Instead = of a traits class containing all those (most of them unnecessary) definitio= ns, maybe something like this:

void push_back (const<= /span> typename argument<valu= e_type>::<= /span>type val);

This seems more intuitive and cleaner than the first app= roach, still resolving the problem at the framework level. Regarding the is= sue of tag dispatching it would be solved the same way, but being so much m= ore trivial I'm considering the rest first. Regarding exceptional cases= such as the ones you guys mentioned, this could always be specialized for = them, as could the traits option, specially given Thiago's suggestion f= or a boolean alternative.

Regarding copy-if-write,= although it does seem like a great idea, am I wrong thinking that this can= (and should?) be solved at a compiler level? This can be done statically b= y each function marking their parameters as either written or not and apply= ing the flag recursively, and I don't see the need for hints by the dev= eloper or language additions.

All things considere= d, I think the operator approach is definitely the best, but using traits c= lasses seems to be more backwards-friendly. What are your thoughts on this?=

Again, my appreciation for your feedback.
Best regards,
Andr=C3=A9.

quarta-feira, 10 de Fe= vereiro de 2016 =C3=A0s 18:51:55 UTC, Thiago Macieira escreveu:
On quarta-feira, 10 de fevereiro de 2016 1= 1: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) maciei= ra.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_131_987651911.1455150826453-- ------=_Part_130_557186018.1455150826446-- .