220 6812 article Path: news.gmane.org!not-for-mail From: snk_kid Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: [C++17][wish-list] first-class function types or function-type constraints Date: Mon, 30 Sep 2013 12:14:59 -0700 (PDT) Lines: 129 Approved: news@gmane.org Message-ID: References: <7316629.V0eLi24ydZ@tjmaciei-mobl2> <03c80957-6b0b-4ab9-9ad9-2bce80aaee41@isocpp.org> <3001150.rz4E6Vrz6O@tjmaciei-mobl2> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2233_17860666.1380568499578" X-Trace: ger.gmane.org 1380568498 23419 80.91.229.3 (30 Sep 2013 19:14:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Sep 2013 19:14:58 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCG6DCXN7IPRBNM3U6JAKGQERZPHVDY@isocpp.org Mon Sep 30 21:15:03 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 1VQivu-00044t-Ma for gclcip-std-proposals@m.gmane.org; Mon, 30 Sep 2013 21:15:02 +0200 Original-Received: by mail-ob0-f199.google.com with SMTP id vb8sf22252384obc.6 for ; Mon, 30 Sep 2013 12:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; 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 :content-type; bh=SBsS1yhVwvc9UiRd+m9ALoXpFeLTW5LCm8Dt9XVYulo=; b=pEp+HmV5F/w5IhBVYGb0P7gPfiHUFzZYq50pYFbDRdmOk3tORuzOaxUbMGZ5dOjk9x Q8/laQ/QVovYeOyqr/rqg1uyvKTtUDDSwBwbc0NHYl5saJUpc0wHqApBV4UgSk3+kAQp zU15r5iYw4VVKJeI6pAq+uf5K3C8SSYiwMMKZy+yeOC1zGZlM7uhMJ8Q7XfhK6tcdaNF /XRk378icbtcXpG0k8d2dKle9AX9I6OU/GwrCITqM1yv/XpEh5N6W4qdnq3DVyiiNk9z 6p7AxR/eJJnu36HPLbZUVdlXO8UuvBa84HL9p5KNOnPkX2NdJ/VzbE1egDS51t+pooQc U6Xw== X-Received: by 10.182.16.199 with SMTP id i7mr4259921obd.42.1380568501629; Mon, 30 Sep 2013 12:15:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.29.110 with SMTP id j14ls2029832igh.34.canary; Mon, 30 Sep 2013 12:15:01 -0700 (PDT) X-Received: by 10.50.2.74 with SMTP id 10mr529531igs.15.1380568501040; Mon, 30 Sep 2013 12:15:01 -0700 (PDT) In-Reply-To: X-Original-Sender: korcan.hussein@googlemail.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:6812 Archived-At: ------=_Part_2233_17860666.1380568499578 Content-Type: text/plain; charset=ISO-8859-1 > > >> - Depending on the implementation, debugging debug builds with >> std::function makes the call-stack bigger thus harder to debug. >> >> > I've never found "bigger call stack" as the issue with debugging. > I haven't had much problems personally but I've seen cases with other people tripping up and saying "why!!!", one example was where a one person was using std::function in function parameters a lot instead of using plain template function parameters, another programmer was debugging code and had a gigantic call-stack most of it all coming from implementation layers of different invocations of std::function. The example was roughly equivalent to nested std::for_each where the function parameter was using std::function (unlike std::for_each). It's definitely a head scratch when you see it, not so much in terms of difficulty but more in terms of why it has to be this way & wtf. Granted this was a particular implementation of std::function and doesn't necessarily apply to all compiler vendor implementations. >> - For example in VC++2010, if you look at the call-stack of using >> std::function vs a plain template function parameter in a debug-build. The >> situation gets worse when you have more complicated expressions involving >> nesting/composition of std::functions (either directly or indirectly). >> >> > As long as you are binding the functions at run time instead of compile > time, I fail to see how a different mechanism would be any better. > > My original intent is a bit more specific than asking for full on first-class functions (all though why not? why don't we discuss the possibility it instead of dismissing it out-right). I'm talking more about a mechanism to to specify and self-document what the parameter and returns type should/must be for a callable entity in a template function and maybe the basis for future versions of C++ which adds full first-class functions. I don't mean to say get rid of std::function outright, I'm willing to accept it in different cases like data-members and containers but for functions like the standard library generic algorithms where I think it's clear they don't use std::function for performance reasons it would be nice to have the ability to specify a function signature. -- --- 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/. ------=_Part_2233_17860666.1380568499578 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
  • Depending on the implementation, debugging debug b= uilds with std::function makes the call-stack bigger thus harder to debug. =

I've never found "bigger c= all stack" as the issue with debugging. 

I haven't had much problems personally but I've seen ca= ses with other people tripping up and saying "why!!!", one example was wher= e a one person was using std::function in function parameters a lot instead= of using plain template function parameters, another programmer was debugg= ing code and had a gigantic call-stack most of it all coming from implement= ation layers of different invocations of std::function.

The example = was roughly equivalent to nested std::for_each where the function parameter= was using std::function (unlike std::for_each). It's definitely a head scr= atch when you see it, not so much in terms of difficulty but more in terms = of why it has to be this way & wtf.

Granted this was a particul= ar implementation of std::function and doesn't necessarily apply to all com= piler vendor implementations.

  • For example i= n VC++2010, if you look at the call-stack of using std::function vs a plain= template function parameter in a debug-build. The situation gets worse whe= n you have more complicated expressions involving nesting/composition of st= d::functions (either directly or indirectly).

As long as you are binding= the functions at run time instead of compile time, I fail to see how a dif= ferent mechanism would be any better.
 

My original intent is a bit more specific than ask= ing for full on first-class functions (all though why not? why don't we dis= cuss the possibility it instead of dismissing it out-right). I'm talking mo= re about a mechanism to to specify and self-document what the parameter and= returns type should/must be for a callable entity in a template function a= nd maybe the basis for future versions of C++ which adds full first-class f= unctions.

I don't mean to say get rid of std::function outright, I'm= willing to accept it in different cases like data-members and containers b= ut for functions like the standard library generic algorithms where I think= it's clear they don't use std::function for performance reasons it would b= e nice to have the ability to specify a function signature.


--
 
---
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>.
------=_Part_2233_17860666.1380568499578-- .