220 18157 <5700648f-5413-4547-b1e3-43aea2ee798f@isocpp.org> article Path: news.gmane.org!not-for-mail From: Adrien Hamelin Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Proposal: Optimizing out useless functions Date: Sat, 23 May 2015 01:46:21 -0700 (PDT) Lines: 434 Approved: news@gmane.org Message-ID: <5700648f-5413-4547-b1e3-43aea2ee798f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1862_964800397.1432370781921" X-Trace: ger.gmane.org 1432370789 8715 80.91.229.3 (23 May 2015 08:46:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 May 2015 08:46:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCDJNPOCWIPBBX74QCVQKGQEG7AK25A@isocpp.org Sat May 23 10:46:25 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f200.google.com ([209.85.220.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yw54a-0000cv-Ft for gclcip-std-proposals@m.gmane.org; Sat, 23 May 2015 10:46:24 +0200 Original-Received: by qkhi77 with SMTP id i77sf42101402qkh.3 for ; Sat, 23 May 2015 01:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:content-type :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=dxeKH1s+ZHcnM9e3i1uNxSfxRl8YBeuF+KwxoOFXoyc=; b=xShzfE5WiW26uynxS5aw09NzqW9ScKyuaZc+sUuzCv3FiKeeDNZZHf24u+eB6EJUYp tkVLeijqupuqtfUKLcz5SmU2sBwzvc1CWe2fTWf8+121B1/PZ5nBpxvSR/nT3PdrLZOU 3SjnPie7Qx5O3VxuqlTWCkBJOjjDoy6Dk/IqYwRT0UADUmyTNmhh6mTj7awFSeRQLk75 34DFWNJeF+yycV26yTvVaaCPVYdhayZBo/WK5cgN9MRZ26OdmoCqVK5UaR6qFNvaU9wN fcnTKEpxM7uCl+oUz6bmnddG2TX5o7hl5sGesRrmGwKQQg8PCCe2qjhoatGXUXiLgH7x zolw== 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:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=dxeKH1s+ZHcnM9e3i1uNxSfxRl8YBeuF+KwxoOFXoyc=; b=im90ApLRScZ2bpW4p84c0iVFJhZZpuvse8quwY0dlM46vD4uF0m0s7xudFO7by+hAu ax696J/OZYJyR2zNiLvoM7/McgEV35GuiaAImKMlylj6p6wtjKOFuvKWXrcT1qBmbTqR 8ec3j1tro+L2JrH7IZHCz/LrPYsQb2EcoVHg/xc02b0YLY66bKIaYqiYln9VOUXrm1Vr Kn7I7ibvpujAG0m33EkzId3gijJlsiuMwMJhgp7KQPgw/0UZnjMD27OEo5r8+x6/K5KC tezho7XQe/p0VQEuKeiBTCRdVvqTx0c4Ah00N+6EJcyCPhj0CEt33NScKc5CytMyKSaN Y4OA== X-Gm-Message-State: ALoCoQmT/9x8oXUnVayGXnSHVtlgpFUQeqAbbf7iNoNuDKRIcAcwQr/awRcyG67KtIVaHq1ucvQE X-Received: by 10.236.70.5 with SMTP id o5mr16683236yhd.9.1432370783557; Sat, 23 May 2015 01:46:23 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.89.148 with SMTP id v20ls2384297qgd.70.gmail; Sat, 23 May 2015 01:46:22 -0700 (PDT) X-Received: by 10.140.20.40 with SMTP id 37mr178894qgi.26.1432370782880; Sat, 23 May 2015 01:46:22 -0700 (PDT) X-Original-Sender: adrien.hamelin@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:18157 Archived-At: ------=_Part_1862_964800397.1432370781921 Content-Type: multipart/alternative; boundary="----=_Part_1863_781353863.1432370781921" ------=_Part_1863_781353863.1432370781921 Content-Type: text/plain; charset=UTF-8 Hi, I have written an idea I got to extend the C++ language on my blog and have been advised to post it here, so here it is. The basic idea is to help the compiler remove functions that are actually used but with no side effects. It does it automatically for simple functions, but it cannot always do it. An example I have is with a signal system. Imagine it is like this: template class Sender { public: // some code static void send(/* parameters */); }; template class Receiver { public: // some code template void receive(Function f); }; // Usage ////////////////////// // Elsewhere in the code ------ Receiver<0> receiver; // later... Sender<0>::send(/* parameters */); // later... receiver.receive([] (/* parameters */) { // something }); Pretty simple, each signal is differentiated by an ID. When a signal needs to be sent, one has just to call the send() function and every receivers that exist at that time will receive the signal and handle it when the receive() function is called. With a GUI library, for example, a lot of signals will be sent whether there is a receiver or not. But the send() function is not optimized out (at least in my test application with GCC and clang and -O3), so some CPU cycle are wasted when there are no receivers. My idea is then a keyword that indicates that if a function or a class does not exist at link time, when the executable is build, the dependent function calls can simply be removed from the program, with no side-effects, and some performance enhancements. For example, if we used as keyword "instancif" ("instance if"), it could be used like that: // condition is a class or a function instancif(SomeClassOrFunction) void f1() {} // condition is a member function instancif(SomeClass::SomeFunction) void f2() {} // also useful for classes? instancif(Something) class C1 { void f3(); template void f4(T); template T f5(); void f6(); }; // only for a class member instancif(Something) void C1::f3() {} // mixed with template template instancif(SomeTemplateClass) void C1::f4(T) {} // also with template for condition template instancif(SomeTemplateClass) T C1::f5() { return {}; } // and specialization template instancif(SomeOtherTemplateClass) void C1::f6() {} The keyword is not useful for a library user, so I believe it should be placed in the same manner as the "inline" keyword before the implementation of the function. So, do you have an opinion about that? Thanks. Regards, Adrien Hamelin PS: I have a comment that says this could be mixed with the possible "static if". PPS: the original blog post is https://aboutcpp.wordpress.com/2015/05/19/proposal-optimizing-out-useless-functions/ -- --- 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_1863_781353863.1432370781921 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have written an idea I got to ext= end the C++ language on my blog and have been advised to post it here, so h= ere it is. The basic idea is to help the compiler remove functions that are= actually used but with no side effects. It does it automatically for simpl= e functions, but it cannot always do it.
An example I have is wit= h a signal system. Imagine it is like this:

template <size_t ID>class Sender {
public:
  // some code
  static void sen= d(<= span style=3D"color: #800;" class=3D"styled-by-prettify">/* parameters */);
};
 
template <size_t ID>
class Receiver {
public:
  // some code
  template <typename Function>
  void receive(Fun= ction f);
};

// Usage //////////////////////
 
// Elsewhere= in the code ------
Receiver<0> receiver;
 
// later...
Sender<0>::send(/* parameters */);
 
// later...
receiver.receive([] (/* parameters */= ) {
  // something
});

= Pretty simple, each signal is differentiated by an ID. When a signal needs = to be sent, one has just to call the send() function and every receive= rs that exist at that time will receive the signal and handle it when the r= eceive() function is called.
With a GUI library, for example, a l= ot of signals will be sent whether there is a receiver or not. But the send= () function is not optimized out (at least in my test application with GCC = and clang and -O3), so some CPU cycle are wasted when there are no receiver= s. My idea is then a keyword that indicates that if a function or a class d= oes not exist at link time, when the executable is build, the dependent fun= ction calls can simply be removed from the program, with no side-effects, a= nd some performance enhancements. For example, if we used as keyword "insta= ncif" ("instance if"), it could be used like that:

// condition is a class or a function<= span style=3D"color: #000;" class=3D"styled-by-prettify">
instancif(SomeClassOrFunction) void f1() {}
//= condition is a member function
instancif(SomeClass::SomeFunction<int>)= void f2() {}
 
// also useful for classes?
instancif(Something) class C1 {
  void f3();=
 = template<= /span> <typename T>
  void f4(T);
&= nbsp; temp= late <typename T>
  T f5();
  void f6();
};
 
// only for a class member
instancif(Something) v= oid C1::f3() {}
// mixed with template
template <typename T&= gt;
ins= tancif(SomeTemplateC= lass<T>) void C1::f4(T) {}
// also with template for condition
template <typename T, typename V= >
in= stancif(SomeTemplate= Class<<= /span>V>) T C1::f5() { ret= urn {}; }
// and specialization
template <typename T>
instancif(Some= OtherTemplateClass<int, T>) void C1::f6() {}

The keyword is not useful for a libr= ary user, so I believe it should be placed in the same manner as the "inlin= e" keyword before the implementation of the function.

<= div>So, do you have an opinion about that? Thanks.

Regards,
Adrien Hamelin

PS: I have a co= mment that says this could be mixed with the possible "static if".
PPS: the original blog post is https://aboutcpp.wordpress.com/2015/0= 5/19/proposal-optimizing-out-useless-functions/

--

---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_1863_781353863.1432370781921-- ------=_Part_1862_964800397.1432370781921-- .