220 7597 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Fixing the private method issue Date: Mon, 4 Nov 2013 14:17:24 -0800 Lines: 198 Approved: news@gmane.org Message-ID: References: <5eeafd6f-32f3-4281-9374-617af852fe21@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c1c4a6d713ee04ea61473f X-Trace: ger.gmane.org 1383603442 9484 80.91.229.3 (4 Nov 2013 22:17:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Nov 2013 22:17:22 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDVNBJG4YAIBB5NZ4CJQKGQEJ3FMODY@isocpp.org Mon Nov 04 23:17:28 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VdSSc-00015u-WE for gclcip-std-proposals@m.gmane.org; Mon, 04 Nov 2013 23:17:27 +0100 Original-Received: by mail-ie0-f197.google.com with SMTP id e14sf23331246iej.0 for ; Mon, 04 Nov 2013 14:17:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=A3JPx77hOXG3dRvU9RmByCi9kZPOZaU88PlFMC9PNr0=; b=CyEyOjAygFyN6AlyGZ+Q3emn0fSK3Z/wmK256OtFjOmGMZtr9wFa5MXuvHAE5t2VDC /Gzs0mGpAUKuQdetvlAFJ63TZylahPRnGRTtNDGV2hyF5xjXA5x4HKaSi4FM7vEMG5Tl JqV90/xWZxltiNt/dU3XhIcVxv1llGyAWweGWXYpPKWv0m2FmgVZxhCmO4io+4lg5Pya m4MjFudP/h9SgLrc0bsNzBqfUnjAmsPhIcu3lFl6BE7KOe5+398AYHp+/8icfqNCez4I twq2yUapPko6xoGRTNvt/yHHxy2NLAv44X/OY8kiyWf5UdG8hvSIiz+JbQmIuYJjRJxX P6NQ== X-Gm-Message-State: ALoCoQkcHMx0QePypO4txWKKc2Z5JNwSLRraLfZVAvudImyxlQueHhPxcmRV5qPeJRkgMTZVreDZ X-Received: by 10.182.126.137 with SMTP id my9mr6415052obb.13.1383603446099; Mon, 04 Nov 2013 14:17:26 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.51.40 with SMTP id h8ls2558181qeo.28.gmail; Mon, 04 Nov 2013 14:17:25 -0800 (PST) X-Received: by 10.52.34.109 with SMTP id y13mr11256534vdi.8.1383603445234; Mon, 04 Nov 2013 14:17:25 -0800 (PST) Original-Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [2607:f8b0:400c:c03::234]) by mx.google.com with ESMTPS id j1si5500334vci.26.2013.11.04.14.17.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 14:17:25 -0800 (PST) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c03::234 as permitted sender) client-ip=2607:f8b0:400c:c03::234; Original-Received: by mail-vc0-f180.google.com with SMTP id lc6so5159155vcb.11 for ; Mon, 04 Nov 2013 14:17:24 -0800 (PST) X-Received: by 10.52.243.138 with SMTP id wy10mr11056762vdc.2.1383603444811; Mon, 04 Nov 2013 14:17:24 -0800 (PST) Original-Sender: metafoo@gmail.com Original-Received: by 10.58.100.145 with HTTP; Mon, 4 Nov 2013 14:17:24 -0800 (PST) In-Reply-To: X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c03::234 as permitted sender) smtp.mail=metafoo@gmail.com; dkim=pass header.i=@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:7597 Archived-At: --001a11c1c4a6d713ee04ea61473f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 4, 2013 at 12:36 PM, Zhihao Yuan wrote: > On Mon, Nov 4, 2013 at 1:01 PM, Richard Smith > wrote: > >> //foo.cc: > >> > >> class Foo namespace { > > > > > > "class X namespace" looks a lot like "allow me to violate access control > > here, please". > > I don't think so. This scope, afaics, is private, with contents safe > to be added without changing the ABI. If you can add friends to a 'class namespace', you can trivially use it to violate access control (and get access to private members from some third party TU). You can get the same effect even without allowing friends in a 'class namespace', but you need to work a little harder. For instance: struct Launderer { virtual int get(Foo *p) = 0; } *launderer; class Foo namespace { struct FooLaunderer : Launderer { FooLaunderer() { launderer = this; } int get(Foo *p) { return p->_f; } } static theLaunderer; } Foo::FooLaunderer Foo::theLaunderer; int evil_get_member(Foo *p) { return launderer->get(p); } You can get the same effect without a static data member in the 'class namespace', but again it takes a little more work. And you can do the same thing without even using a member class (using a local class instead of a member function instead). So: this subtly breaks access control. > But since we're brainstorming here, we can get most of the benefit here > with > > extension methods alone: > > > > // foo.h > > class Foo { > > public: > > void doWork(); > > private: > > int _f; > > friend struct FooImpl; > > }; > > > > // foo.cc > > struct FooImpl { > > static void doWorkHelper(Foo *this) { > > doSomethingWith(_f); > > } > > }; > > > > void Foo::doWork() { > > doWorkHelper(); > > } > > I see two problems here: > > 1. Program is written for human to read. This approach, with > functions taking pointer to objects, basically reverted C++ to C; > > 2. Friend is flawed: what you need is to grant accessibility to > a set of functions, but what you do is to grant accessibility to > another class scope. I read this as another "solution from > implementation's view" like using private to make a class > non-copyable. > > There should be more simple, more obvious answer to the problem > raise in this thread. *shrug* It doesn't seem like a big problem to me, especially not once we have modules. I don't think it warrants a big heavy language feature of its own. -- --- 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/. --001a11c1c4a6d713ee04ea61473f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 4, 2013 at 12:36 PM, Zhihao Yuan <zy@miator.net> wrote:
On Mon, Nov 4, 2013 at 1:01 PM, Richard Smith <richard@metafoo.co.uk> wrote:
>> //foo.cc:
>>
>> class Foo namespace {
>
>
> "class X namespace" looks a lot like "allow me to viola= te access control
> here, please".

I don't think so. =A0This scope, afaics, is private, with content= s safe
to be added without changing the ABI.

If yo= u can add friends to a 'class namespace', you can trivially use it = to violate access control (and get access to private members from some thir= d party TU). You can get the same effect even without allowing friends in a= 'class namespace', but you need to work a little harder. For insta= nce:

struct Launderer {
=A0 virtual int get(Fo= o *p) =3D 0;
} *launderer;

class Foo= namespace {
=A0 struct FooLaunderer : Launderer {
= =A0 =A0 FooLaunderer() { launderer =3D this; }
=A0 =A0 int get(Foo *p) { return p->_f; }
=A0 } static th= eLaunderer;
}
Foo::FooLaunderer Foo::theLaunderer;

int evil_get_member(Foo *p) { return launderer->get= (p); }

You can get the same effect without a static data membe= r in the 'class namespace', but again it takes a little more work. = And you can do the same thing without even using a member class (using a lo= cal class instead of a member function instead). So: this subtly breaks acc= ess control.

> But since we're brainstorming here, we can get most of the benefit= here with
> extension methods alone:
>
> // foo.h
> class Foo {
> public:
> =A0 void doWork();
> private:
> =A0 int _f;
> =A0 friend struct FooImpl;
> };
>
> // foo.cc
> struct FooImpl {
> =A0 static void doWorkHelper(Foo *this) {
> =A0 =A0 doSomethingWith(_f);
> =A0 }
> };
>
> void Foo::doWork() {
> =A0 doWorkHelper();
> }

I see two problems here:

=A01. Program is written for human to read. =A0This approach, with
=A0 =A0 functions taking pointer to objects, basically reverted C++ to C;
=A02. Friend is flawed: what you need is to grant accessibility to
=A0 =A0 a set of functions, but what you do is to grant accessibility to =A0 =A0 another class scope. =A0I read this as another "solution from<= br> =A0 =A0 implementation's view" like using private to make a class<= br> =A0 =A0 non-copyable.

There should be more simple, more obvious answer to the problem
raise in this thread.

*shrug* It doesn'= t seem like a big problem to me, especially not once we have modules. I don= 't think it warrants a big heavy language feature of its own.

--
 
---
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>.
--001a11c1c4a6d713ee04ea61473f-- .