220 7867 article Path: news.gmane.org!not-for-mail From: "Billy O'Neal" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal to add std::mem_to_fun Date: Tue, 19 Nov 2013 21:19:16 -0800 Lines: 299 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1133073a9a639504eb94eebd X-Trace: ger.gmane.org 1384924793 9008 80.91.229.3 (20 Nov 2013 05:19:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Nov 2013 05:19:53 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBDKLBLVE6ADBB7UMWGKAKGQEYC74GBI@isocpp.org Wed Nov 20 06:20:00 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f199.google.com ([209.85.214.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vj0Cl-0007GY-Vm for gclcip-std-proposals@m.gmane.org; Wed, 20 Nov 2013 06:20:00 +0100 Original-Received: by mail-ob0-f199.google.com with SMTP id gq1sf11666263obb.2 for ; Tue, 19 Nov 2013 21:19:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=bE4ltlBaSmbnOWETotxftuxrnzo+3QeSld23GZiY4ZM=; b=b7DPxNw1xXrcgsIS4eh70c+DADfERjyytOAd15V+wSOWh3T9kRFu3aa6ONd0X/VZop 0TOQgqAqwHeIvr0wpaH83IrCG2iTug7h82pVjqKPyuXnRJ6dCdvEdEE4K6CA3jBhw1ah 1N7BwOn5/otePu2AxK9mm/EoNDQDooLbJn1GvHsXpg73gn5RzWb1vujGjdPlAQpmvh1S t63pveH52d+UVExdwIflmMehjU2yCCsS6tTf3NzI/J65L0hqgDIAmzl/yeWnsXC0RoCV QsgOVysGp93ykAc12TesJsoLQrgfSOWvesHK0cgr8DdhJB4IRvVJgnsyGLbGrsms1Orf guBg== X-Gm-Message-State: ALoCoQmdM59zg9e8qHragSAlDDrP468emJ0aMUGFSKGXtPymA5+NLMesW4DJtZSZA65ZF2ugiU/I X-Received: by 10.182.53.165 with SMTP id c5mr11299835obp.0.1384924798806; Tue, 19 Nov 2013 21:19:58 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.26.227 with SMTP id o3ls3508006qeg.5.gmail; Tue, 19 Nov 2013 21:19:58 -0800 (PST) X-Received: by 10.236.14.202 with SMTP id d50mr26668807yhd.47.1384924798057; Tue, 19 Nov 2013 21:19:58 -0800 (PST) Original-Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [2607:f8b0:4003:c02::22b]) by mx.google.com with ESMTPS id 41si3628033yhf.227.2013.11.19.21.19.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 21:19:58 -0800 (PST) Received-SPF: pass (google.com: domain of billy.oneal@gmail.com designates 2607:f8b0:4003:c02::22b as permitted sender) client-ip=2607:f8b0:4003:c02::22b; Original-Received: by mail-oa0-f43.google.com with SMTP id g12so9991161oah.2 for ; Tue, 19 Nov 2013 21:19:57 -0800 (PST) X-Received: by 10.60.52.81 with SMTP id r17mr28798207oeo.3.1384924797623; Tue, 19 Nov 2013 21:19:57 -0800 (PST) Original-Received: by 10.182.87.37 with HTTP; Tue, 19 Nov 2013 21:19:16 -0800 (PST) In-Reply-To: X-Original-Sender: billy.oneal@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of billy.oneal@gmail.com designates 2607:f8b0:4003:c02::22b as permitted sender) smtp.mail=billy.oneal@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=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:7867 Archived-At: --001a1133073a9a639504eb94eebd Content-Type: text/plain; charset=ISO-8859-1 IMHO, this could go either way. I've never gone to a standards meeting or anything like that, but it seems the committee seems against messing with additional binders now that lambdas are in the core language. I'm not sure the name "mem_to_fun" makes sense -- the name "mem_fun" refers to making a binder to a "MEMber_FUNction" -- but you're not binding to a function at all here. This smooths over the syntactical issue of member function calls needing the syntax x->y, but the STL only accepting the syntax y(x). Perhaps the name you're looking for is "project" -- because what you're actually doing here is a projection. An alternate solution proposed by Sean Parent in his Going::Native 2013 talk involves defining different versions of the standard algorithms that accept optional projection functions as parameters. Billy O'Neal https://github.com/BillyONeal/ http://stackoverflow.com/users/82320/billy-oneal Malware Response Instructor - BleepingComputer.com On Tue, Nov 19, 2013 at 8:41 PM, wrote: > So I noticed browsing that there is currently not a way to > create a function object that can return just a member of an object. There > is a structure that converts a member function into a function object > callable via the class as an argument (std::mem_fun_t). My question is why > can't this exist for accessing members of a POD struct or even a class? > That could be useful for standard algorithms when you need access to a > specific member but don't wanna write out the lambda for it, eg: > > struct Books { > std::string author; > std::string title; > }; > > > // all we want is to make a set of titles of books from our library vector > std::set uniqTitles; > std::transform(library.begin(), library.end(), std::inserter(uniqTitles,uniqTitles > .end()), > [] (const Books& b) -> std::string > { > return b.title; > } > ); // why can't there be a standard way to just grab the member? > > so really the implementation / interface would look a lot like > std::mem_fun: > > template > struct mem_to_fun_t { > M T::*_mem; > explicit mem_to_fun_t(M T::*mem): _mem(mem) { } > > const M& operator()(const T& c) const{return c.*_mem;} > M& operator()(T& c) {return c.*_mem;} > }; > > > template inline > auto mem_to_fun(M T::*mem) -> mem_to_fun_t { > return mem_to_fun_t{mem}; > } > > it doesn't have to be exactly like this but perhaps a similar > implementation. > > Here is the ideone link if you wanna see how it could be used: > http://ideone.com/3uoDPV > > > -- > > --- > 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. > Visit this group at > http://groups.google.com/a/isocpp.org/group/std-proposals/. > -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --001a1133073a9a639504eb94eebd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
IMHO, this could go either way. I've never gone to a s= tandards meeting or anything like that, but it seems the committee seems ag= ainst messing with additional binders now that lambdas are in the core lang= uage.

I'm not sure the name "mem_to_fun" makes sense= -- the name "mem_fun" refers to making a binder to a "MEMbe= r_FUNction" -- but you're not binding to a function at all here. T= his smooths over the syntactical issue of member function calls needing the= syntax x->y, but the STL only accepting the syntax y(x).

Perhaps the name you're looking for is "projec= t" -- because what you're actually doing here is a projection.

An alternate solution proposed by Sean Parent in his = Going::Native 2013 talk involves defining different versions of the standar= d algorithms that accept optional projection functions as parameters.

Billy O'Neal
Malware Response Instructor - BleepingComputer.com


On Tue, Nov 19, 2013 at 8:41 PM, <dacamara.cameron@gmail.com> wrote:
So I noticed browsing <functional> that there is cur= rently not a way to create a function object that can return just a member = of an object. There is a structure that converts a member function into a f= unction object callable via the class as an argument (std::mem_fun_t). My q= uestion is why can't this exist for accessing members of a POD struct o= r even a class? That could be useful for standard algorithms when you need = access to a specific member but don't wanna write out the lambda for it= , eg:

stru= ct Books {
=A0 std::string author;
=A0 std::string title;
};


<= span style=3D"color:#800">// all we want is to make a set of titles of book= s from our library vector
std::set<std::string> uniqTitles;
std::transform<= span style=3D"color:#660">(library.begin(), library= ..end(),= std::inserter(uniqTitles= , uniqTitles.end()),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[]<= span style> (const Books& b) ->= ; std::string
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return b.title;<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
); // why can't there be a standard way to ju= st grab the member?

so really the implementation / interface w= ould look a lot like std::mem_fun:

template <typename T, type= name M>
struct mem_to_fun_t {
=A0 M T::*_mem;
=A0 explicit mem_to_fu= n_t(M T::*mem): _mem(mem) { }
=A0
=A0 const M& operator()(const T& c) const{return c.*_mem;}
=A0 M& operator()(= T& c) {return c<= /span>.*_mem;}
};


<= span style=3D"color:#008">template <typename T, typename M> inline
auto mem_to_fun= (M T::*mem) -> me= m_to_fun_t<T= ,M> {
=A0 return mem_to_fun_= t<T,M&g= t;{mem};
}
<= /div>
it doesn't have to be exactly like this but perhaps= a similar implementation.

Here is the ideone link= if you wanna see how it could be used:=A0http://ideone.com/3uoDPV


--
=A0
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/gro= up/std-proposals/.

--
 
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--001a1133073a9a639504eb94eebd-- .