220 29948 <146727c3-d49d-480d-950f-76a8104b5220@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Dawid Pilarski Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Frameless functions (force inline) Date: Mon, 19 Dec 2016 23:36:57 -0800 (PST) Lines: 87 Approved: news@gmane.org Message-ID: <146727c3-d49d-480d-950f-76a8104b5220@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1341_462713676.1482219417185" X-Trace: blaine.gmane.org 1482219420 24317 195.159.176.226 (20 Dec 2016 07:37:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 20 Dec 2016 07:37:00 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDMKPG65WENBBGN74PBAKGQE4FMYX6I@isocpp.org Tue Dec 20 08:36:56 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f72.google.com ([209.85.214.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJEyj-0005BK-UK for gclcip-std-proposals@m.gmane.org; Tue, 20 Dec 2016 08:36:54 +0100 Original-Received: by mail-it0-f72.google.com with SMTP id b123sf103917995itb.3 for ; Mon, 19 Dec 2016 23:36:58 -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:subject:mime-version: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=AfU8m4wFLdbKzpjcrGSsnLL2JmcOZz+RgKsFZeisMbY=; b=f+z8NFQiKM86mF3fJKnGKWqKuXVqcfCCEZgio3rmdEK6oL9IcFshCEAuuMMlTKp/xB a0rRWQ0QTOyqjXwdPvNUccsZCbaVIqSIdbqaeDMdrWNXu6b8fuAm4yaASruGqinBDesw sQTGPtM3mZ5YO49CnjxcozG9vbKofJEHy4T0+PBQ0Kw8LsS/VSHRrAnL1HuxBWrsin/6 YFCE1alNjxi/ZpD0kQWH1GCnq061UA8GWiiHkSvN5WgfY0vmYlwsB4t6UjmFnmM02zHV fBeIHTvUwEFr7LhAUYQy2R8SY9+QUTtEGkoLzTA7LvhlIYqArUO9cpjp6hHWKipdlotu uhWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version: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=AfU8m4wFLdbKzpjcrGSsnLL2JmcOZz+RgKsFZeisMbY=; b=JUHtFN6lW6oRhq5XLYmF8W4NFN7N+IBaDDfNPSgb/8o4VFXooUg+4kFqWhg/P1ims7 bLbqj/Mo9QqqBUrDr8k+/ZX3VV9yy/e7NOw4d0ybzR7Q1hFQI5xRiNHhmGmfy1DyGxtH 2HAfNcXZgc6tFB2Qjf6eyMk29QvVFtV21cKjgm2JOlxLhzDjuimhu6skh4/2oXaTH5q+ MxW0q2PNkxO6OsQMan4LOsKnqlLHy+ZXhu5aLjxdIxZ2Y/EdCvPe8hPST9gBXzS9jT71 I/licTx8nlgphXz6NIKUiqckasf1c4NarzjgK/zbjkJoYMT5LQQoS2RSyv91hNURb2bT 0jQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :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=AfU8m4wFLdbKzpjcrGSsnLL2JmcOZz+RgKsFZeisMbY=; b=e04HGNAqRLtOF0hzWSWgeMJodM0c3VaOjncCJv+nlEpQ6caJpd5p7CC0FC7WcMBfeY IG7HODeppCGNPNLGCpAqxnUWnV2KtE3ALO8nv3DE3jJ1/znU3JKcVb9Smr00JqIb7SM/ wwKTb39B9HzaqrrFpGEiOl/FzJPX0QR2gj+284a/stMg0IcAK2gGL/9+mfKzkA+9PTJe zUBLVM8ecFvz7AmVG/GPTxHbfMQpS4ZioDWxuwWx6Yln1MAh5nAVHDb0QDcNLs7a8WeX DslZPBjL4G3XNyclPhtDUGAtLmpdxOR7IQAbMxt46SHSj3r6Ix5T2F6ASaZKZ47ZU0TW 7+fg== X-Gm-Message-State: AIkVDXLAXSFzVjYjuiK4lRegdT7yaVAkO677H1pIvOC29CEWsdTfpyDLfPCJJhUK3JETiQ== X-Received: by 10.36.20.16 with SMTP id 16mr84267itg.23.1482219418305; Mon, 19 Dec 2016 23:36:58 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.18.246 with SMTP id g109ls17061070otg.7.gmail; Mon, 19 Dec 2016 23:36:57 -0800 (PST) X-Received: by 10.157.17.3 with SMTP id g3mr908904ote.8.1482219417514; Mon, 19 Dec 2016 23:36:57 -0800 (PST) X-Original-Sender: DawidPiCpp@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:29948 Archived-At: ------=_Part_1341_462713676.1482219417185 Content-Type: multipart/alternative; boundary="----=_Part_1342_690420060.1482219417185" ------=_Part_1342_690420060.1482219417185 Content-Type: text/plain; charset=UTF-8 MARK: moving post from std-discussions Question: Hi. The problem I would like to address, which has got no solution on language level is programmer not being able to force function to be inlined. I am completely fine with the fact, that compiler can decide, whether it's optimal to make function inlined or not and do so appropriately, so that inline is just a hint for the compiler. On the other hand there are situations, when you need to have a control over the call stack. Especially when playing with std::longjmp and std::setjmp for example to implement co-routines (this case however has already been addressed), so that one can create await() function (it's just an example). Solution would seem, to use compiler options to force inline functions, but then gcc rejects any function, that is to be force inlined, when using std::setjmp in it. This would seem to be a rare case, when one will have to use force inline. It also creates a risk, that people will start using force inline instead of simple inline to make "optimizations" therefore discarding compiler wisdom. Has this problem been addressed? Do you think it would be usefull? -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/146727c3-d49d-480d-950f-76a8104b5220%40isocpp.org. ------=_Part_1342_690420060.1482219417185 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
MARK: moving post from std-discussions

Question:Hi.

The problem I would like to address, which has got no=20 solution on language level is programmer not being able to force=20 function to be inlined.

I am completely fine with the fact, that=20 compiler can decide, whether it's optimal to make function inlined or= =20 not and do so appropriately, so that
inline is just a hint for the compi= ler.

On the other hand there are situations, when you need to have a control=20 over the call stack. Especially when playing with std::longjmp and=20 std::setjmp for example
to implement co-routines (this case however=20 has already been addressed), so that one can create await() function=20 (it's just an example).

Solution would seem, to use compiler=20 options to force inline functions, but then gcc rejects any function,=20 that is to be force inlined, when using std::setjmp in it.

This=20 would seem to be a rare case, when one will have to use force inline. It also creates a risk, that people will start using force inline instead=20 of simple inline to make
"optimizations" therefore discarding = compiler wisdom.

Has this problem been addressed? Do you think it wo= uld be usefull?

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/146727c3-d49d-480d-950f-76a8104b5220= %40isocpp.org.
------=_Part_1342_690420060.1482219417185-- ------=_Part_1341_462713676.1482219417185-- .