220 17151 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Refined friend Date: Thu, 26 Mar 2015 14:51:42 +0200 Lines: 72 Approved: news@gmane.org Message-ID: References: <5D15F377-94B9-4114-BF16-835C4F30A331@gmail.com> <336a8758-5bdd-4c13-952c-62ad1ba14e1c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1427374313 22046 80.91.229.3 (26 Mar 2015 12:51:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Mar 2015 12:51:53 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRBXUB2CUAKGQEUHOOR2Y@isocpp.org Thu Mar 26 13:51:52 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f200.google.com ([209.85.213.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yb7GC-0008R7-UF for gclcip-std-proposals@m.gmane.org; Thu, 26 Mar 2015 13:51:45 +0100 Original-Received: by igcrw4 with SMTP id rw4sf28005776igc.1 for ; Thu, 26 Mar 2015 05:51:43 -0700 (PDT) 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:content-transfer-encoding :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=go55Fk/qJcWpT+8Nn5h8W5hqXnVlVxBxah8t53gYJpw=; b=giTn26KA50FIhwSdc3bIOGz74lwj2yCl2ooAlWohCEIHx6v+oT4hvno4qP+fV9Cu5n Cqcz8jiDONi1P4h0tQgXlGmRhoHZtfcWMhZKRYdvTmE4IG5CqZV+CktvV4CLulE+MAgS 4i0tL2jvqY6DfoDA9LiXypFvjqOPsLqeq+adFNmNaO+hLqlDbTB1mnDM6v7j6rT91NQ0 +sc/Rb0y8lKTuWpSsnsnKMHtk+IjjPhlQyU5YKv51vFlCZFvmr/h1fY1JGnIxfgVnLrX YWWVh03njgYPkPv2OU/k0XeA3kfupErmwUSn9+frNcQOfXfV1sRJgxVi/53grSJfeQPo O4ug== X-Gm-Message-State: ALoCoQkR5/32FKAChOgAH0oo8WpH7cxE2No+G8wspIGpJ+/+8ZlStzNp/f2dg8Nd3tsjVYRGlMHG X-Received: by 10.42.142.69 with SMTP id r5mr37129308icu.3.1427374303715; Thu, 26 Mar 2015 05:51:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.51.16.129 with SMTP id fw1ls702825igd.2.gmail; Thu, 26 Mar 2015 05:51:42 -0700 (PDT) X-Received: by 10.42.30.139 with SMTP id v11mr33991531icc.76.1427374302593; Thu, 26 Mar 2015 05:51:42 -0700 (PDT) Original-Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com. [2607:f8b0:4001:c03::235]) by mx.google.com with ESMTPS id f8si13822574igc.27.2015.03.26.05.51.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 05:51:42 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:4001:c03::235 as permitted sender) client-ip=2607:f8b0:4001:c03::235; Original-Received: by ieclw3 with SMTP id lw3so45240123iec.2 for ; Thu, 26 Mar 2015 05:51:42 -0700 (PDT) X-Received: by 10.50.124.164 with SMTP id mj4mr36189177igb.38.1427374302153; Thu, 26 Mar 2015 05:51:42 -0700 (PDT) Original-Received: by 10.36.86.209 with HTTP; Thu, 26 Mar 2015 05:51:42 -0700 (PDT) In-Reply-To: <336a8758-5bdd-4c13-952c-62ad1ba14e1c@isocpp.org> X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:4001:c03::235 as permitted sender) smtp.mail=ville.voutilainen@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:17151 Archived-At: On 26 March 2015 at 01:27, Dejan Milosavljevic wrote: >> Why would I use any kind of friends extensively, >> and why would I use these refined-friends extensively? >> If I need narrow/refined friends often, I'd say it's time to rethink my >> design. > > It is up to you to decide what do you want to use. > Some programmers do not use exception at all. In a contrary some of them = use > very often. > I see both code and I have no complains. > For one problem you can have more than one good solutions. That fails to answer the question. What is the use case where such narrow-friends need to be used extensively, and why will the alternatives not do? The motivation of the proposal fails to deliver answers to those questions. > In David Kraus solution we have 7 ( seven ) lines of code. > In David Rodr=C3=ADguez Ibeas 4 ( four ). > refined-friend only 1 ( one ). Those solutions try to allow access to a member that is a plain member. The= y do not consider alternative ways, like having a subobject that is public but has everything in it private, and declares the friends you need. In oth= er words, dividing the members differently. Such alternatives should be compar= ed to the proposed solution in the proposal. >>> Every additional members in some cases can consume too much memory e.g. >>> Color has Image for friend. >> How does that increase memory consumption? > Purposely or not AccessorForB::set_value can be virtual. > Make a million instance of A. Few unnecessary bytes for vtabel multiply w= ith > million. Then don't make a million instances of AccessorForB. There's no need for Memento pattern implementations to be allocated if they are not needed. >> Again, I fail to see why that's so bad. > friend breaks encapsulation. Accidentally or not it is possible to use ot= her Friends do not break encapsulation, they provide controlled access to a well-defined set of classes that are explicitly declared. > member avoiding original design. > Compiler will not warn or emit the error. With refined-friend you will ha= ve > error and that is the purpose of it. Yes, and there are other ways to get the same granularity. The onus is on the proposal to explain why it should get specific language support. --=20 ---=20 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 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-proposa= ls/. .