220 24828 article Path: news.gmane.org!not-for-mail From: Viacheslav Usov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Partial class: a separation of a class interface from its implementation with no memory costs Date: Mon, 29 Feb 2016 15:17:46 +0100 Lines: 109 Approved: news@gmane.org Message-ID: References: <374600f5-0397-4243-91bc-d01afd145e6c@isocpp.org> <59566830-e0fd-4730-9416-bc427c249c48@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c24f0624c06e052ce950be X-Trace: ger.gmane.org 1456755475 25096 80.91.229.3 (29 Feb 2016 14:17:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Feb 2016 14:17:55 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBDU6VRPKW4BBBC5G2G3AKGQEYTT7HPQ@isocpp.org Mon Feb 29 15:17:49 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aaOdx-0001lG-AF for gclcip-std-proposals@m.gmane.org; Mon, 29 Feb 2016 15:17:49 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id k196sf247802977vka.3 for ; Mon, 29 Feb 2016 06:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=tTgsjo9b6YAwg/zvhkh2Vz0C4Ka6xGxpEPMUPE6Tj9g=; b=fMrfEQB8jKdWHvVYTan7KS7WxpUzSkAc23JiM2eZmP7vo02ztgvnhv3Oc/jwZBLLZS uVPu+9Kkaegl/734x2Q717t7h5JXBWeKQS+Oioh9xnjvjN+UTn0SUkLIAEuFDhcI2y6W v3C/mRJfqGsjZRFRJiYcmcW/mBMxKUEab6+3FZsFDx1mnu8NCcAQKuy9csnP5DCZHi2X EsvF1KqaiNjdtECchw/1luxZjrBOlpCjedb5AuV4WWTFzguC9iksDyT+T9U2urMXj/HG fcfUi2RnndKv9TwOCyhH0IbqvOsjfnGzKdw1HTUfBdZ0lOr96R2G0nhYxumAkiBN0jwM AUnQ== 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:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=tTgsjo9b6YAwg/zvhkh2Vz0C4Ka6xGxpEPMUPE6Tj9g=; b=TI/8q0AfGYTpQJ0SLHGhfQaidQPrcVCxC3IEA3bl+Ju2NvjIYPcMMnw2IrFfb44Px+ fj8IzR36eTdbCB+p6jZYzHgmNqFcpor6z3EYAi5GyO4WL3nBnVSZGi/951bFvA5CE+d2 ZyTQl0vWKtso6WfN3J217f6j0OA3ujUnIdr86FXZY3rsKoNUYhUH75bfvZ+CWE2fcoSL LuJk1S6LfBYtgxRhClQPYsrAMKkaT+K/oSn00eP61Ac8YrzQXY9QIrrQfmQxKEHVm/CI 3NM811ipwTJ3OgSO3wfotU0kAgGLEM7mufLH+Rm0MjdJ91muodklssMWnwiEba28WiZd aT7w== X-Gm-Message-State: AG10YOTci7FJRkNdNrKxubjYaPozA4HmHUys/uncp12muSD69zuyJ7GGxV5HIUa821TG5A== X-Received: by 10.140.20.204 with SMTP id 70mr30397149qgj.18.1456755468460; Mon, 29 Feb 2016 06:17:48 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.130.162 with SMTP id of2ls1280122obb.48.gmail; Mon, 29 Feb 2016 06:17:47 -0800 (PST) X-Received: by 10.60.233.43 with SMTP id tt11mr12295517oec.36.1456755467362; Mon, 29 Feb 2016 06:17:47 -0800 (PST) Original-Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com. [2607:f8b0:4003:c01::22c]) by mx.google.com with ESMTPS id rp3si21652465oeb.29.2016.02.29.06.17.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Feb 2016 06:17:47 -0800 (PST) Received-SPF: pass (google.com: domain of via.usov@gmail.com designates 2607:f8b0:4003:c01::22c as permitted sender) client-ip=2607:f8b0:4003:c01::22c; Original-Received: by mail-ob0-x22c.google.com with SMTP id xx9so22250636obc.2 for ; Mon, 29 Feb 2016 06:17:47 -0800 (PST) X-Received: by 10.182.200.136 with SMTP id js8mr11741690obc.11.1456755467139; Mon, 29 Feb 2016 06:17:47 -0800 (PST) Original-Received: by 10.76.170.70 with HTTP; Mon, 29 Feb 2016 06:17:46 -0800 (PST) In-Reply-To: <59566830-e0fd-4730-9416-bc427c249c48@isocpp.org> X-Original-Sender: via.usov@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of via.usov@gmail.com designates 2607:f8b0:4003:c01::22c as permitted sender) smtp.mailfrom=via.usov@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-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:24828 Archived-At: --001a11c24f0624c06e052ce950be Content-Type: text/plain; charset=UTF-8 On Fri, Feb 26, 2016 at 5:04 PM, wrote: > The text of my proposal says explicitly "without recurring to bad C-like programming". I think your example (by the way, a one that we already thought) falls in that category. "Bad" is subjective. "C-like", given that clause 1.1.2 of the C++ standard says "C++ is a general purpose programming language based on the C programming language", means "C++-like" and is wholly tautological and thus irrelevant. If you want your proposal to gain traction, you need a very clear and unambiguous motivating part to it. As things stand now, the bold text in your proposal is SIMPLY NOT what you really want to address with your proposal, because those things are addressable with existing C++ means, however "C-like" they might seem to you. This confused message is very likely the reason you are getting largely negative feedback here. At the heart of your proposal, what you really want is the freedom as in pure C to use essentially forward-declared structures combined with the C++-like method calls, except that the methods in your proposal are never virtual. If your methods are never virtual, there is no functional difference whatsoever with using non-member functions ("C-like" in your terminology). The difference is purely syntactical, so your proposal is essentially about making your preferred function call syntax easier to use in a particular case. Is that an unreasonable thing to ask for? Not really. Is it so important that it will grab the full attention of the C++ committee? This is an interesting question, because the syntactical differences in function call syntax are a pretty hot topic for the C++ committee [1], with some decisions already made [2]. Cheers, V. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf [2] https://isocpp.org/blog/2015/11/kona-standards-meeting-trip-report -- 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/CAA7YVg3AOmiDXtY58AosYG%3DQhq9K8J0q%2BjjdgLEi1P0Bph6r%2BQ%40mail.gmail.com. --001a11c24f0624c06e052ce950be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Feb 26, 2016 at 5:04 PM, <daniele.bordes@gmail.com>= wrote:

> The text of my proposal says explicitly "without recurri= ng to bad C-like programming". I think your example (by the way, a one= that we already thought) falls in that category.

"Bad" is subjective. = "C-like", given that clause 1.1.2 of the C++ standard says "= C++ is a general purpose programming language based on the C programming la= nguage", means "C++-like" and is wholly tautological and thu= s irrelevant. If you want your proposal to gain traction, you need a very c= lear and unambiguous motivating part to it. As things stand now, the bold t= ext in your proposal is SIMPLY NOT what you really want to address with you= r proposal, because those things are addressable with existing C++ means, h= owever "C-like" they might seem to you. This confused message is = very likely the reason you are getting largely negative feedback here.

At the hea= rt of your proposal, what you really want is the freedom as in pure C to us= e essentially forward-declared structures combined with the C++-like method= calls, except that the methods in your proposal are never virtual. If your= methods are never virtual, there is no functional difference whatsoever wi= th using non-member functions ("C-like" in your terminology). The= difference is purely syntactical, so your proposal is essentially about ma= king your preferred function call syntax easier to use in a particular case= ..

Is t= hat an unreasonable thing to ask for? Not really. Is it so important that i= t will grab the full attention of the C++ committee? This is an interesting= question, because the syntactical differences in function call syntax are = a pretty hot topic for the C++ committee [1], with some decisions already m= ade [2].

Cheers,
V.

[1] = http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201= 5/n4474.pdf

[2] https://isocpp.org/blog/2015/11/kona-st= andards-meeting-trip-report

--
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/CAA7YVg3AOm= iDXtY58AosYG%3DQhq9K8J0q%2BjjdgLEi1P0Bph6r%2BQ%40mail.gmail.com.
--001a11c24f0624c06e052ce950be-- .