220 7602 <2bc74340-d319-4725-92dd-5b95b59db7c8@isocpp.org> article Path: news.gmane.org!not-for-mail From: mitchnull@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Fixing the private method issue Date: Wed, 6 Nov 2013 00:34:45 -0800 (PST) Lines: 251 Approved: news@gmane.org Message-ID: <2bc74340-d319-4725-92dd-5b95b59db7c8@isocpp.org> 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="----=_Part_35_12028995.1383726886030" X-Trace: ger.gmane.org 1383726884 20167 80.91.229.3 (6 Nov 2013 08:34:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Nov 2013 08:34:44 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC36XNFZ4YKBBJX646JQKGQEPASNAFY@isocpp.org Wed Nov 06 09:34:48 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f72.google.com ([209.85.219.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VdyZc-0007yW-6F for gclcip-std-proposals@m.gmane.org; Wed, 06 Nov 2013 09:34:48 +0100 Original-Received: by mail-oa0-f72.google.com with SMTP id m1sf5730345oag.7 for ; Wed, 06 Nov 2013 00:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=I5j4iBtDYWEkg0NRTpf9Gem3o8LugFqPDlcQElAl5eU=; b=fnB3FDBoLqcXd7h3QAo8NrZ1vKJEodRPhZzy/vaVov8Jsky96P5yoGrNrw697iktDs 0SPN3l80kguAA2eCI3jSE9NoxhOU4ySWB/LAvhFOPCEfTsUhwantQuDViFaxEmMKqkmP 3H8VeCu7MKuZwr+XFPcXXGHq2EoJiGVGiG8in1nXDkgW/pglEm6uYc4plnjZ0dpzl7bg Utsf4irulhp8I0FnqeKwyUlsAwCw8F5GQj7fF295TaFweREEQZjRVF7rciks1Uz86iF7 CvzmhUiADzengcQyejJkXwf/MBFSXypxm9ul2GTsjKUFM6ULuI7FjDjRJWfqcYjoxUIF CrJg== 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:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=I5j4iBtDYWEkg0NRTpf9Gem3o8LugFqPDlcQElAl5eU=; b=inE/B2Tr1QNsqaTAzy1dzII/KXcIbdPzUELzJqXNcO7Dgco/cNc0b+xi4xHWvRByl2 ge9UbJwGpPE7b6i6SCb11lUwXUU0yxnHBQNKgfYwLUGIr6kE4D6LXPJOKAhzK6EoWupe KYqc3KbPuTmsmeJxtDxmXsO6GMC+E/TUjLsS8mUCt4Qj3Tz16nVvg4936YpH932WQSVE ZlDi5cLzInQ5bgrjQVfW66H+7t0t8BZ+UJWBqyXsVFmFlDOyHaNqkb3lz2TzcaC4ujpa 5nr060uTRkkdsJh7DBvapSoGYe3ywGgVVDne31uOZGadu2ZxZdtmeyBb0PpOeT8qHd4v U9Zw== X-Gm-Message-State: ALoCoQnlT4YlcAhLLST9Rj4abKr/HBEzXosS2XsyAHa4yHz02LOUB2oyLBHj0DNA/hrK3ikWykLn X-Received: by 10.182.60.37 with SMTP id e5mr688334obr.30.1383726887231; Wed, 06 Nov 2013 00:34:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.117.97 with SMTP id kd1ls589030qeb.49.gmail; Wed, 06 Nov 2013 00:34:46 -0800 (PST) X-Received: by 10.49.133.225 with SMTP id pf1mr36238qeb.6.1383726886579; Wed, 06 Nov 2013 00:34:46 -0800 (PST) In-Reply-To: X-Original-Sender: mitchnull@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:7602 Archived-At: ------=_Part_35_12028995.1383726886030 Content-Type: text/plain; charset=ISO-8859-1 On Monday, November 4, 2013 11:17:24 PM UTC+1, Richard Smith wrote: > > 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; > } > The above code would not be valid in "class namespace", there is no "free-floating this pointer" just because you're in the "class namespace". As I wrote in my original post, the primary motivation for class-namespace is to allow the implementation of already declared members to be less verbose / more uniform, the new idea sparkled by this thread is to allow declaration / definition of yet undeclared _private_ member functions. I don't think they could be used to circumvent access control in any way. Basically, the following would be allowed in class-namespace: - using declarations - typedefs - definition of previously declared members / member functions - declaration / definition of new _private_ member functions or _private_ static member functions (these should probably be "special" regarding linkage, they should be TU bound and not exported, but I'm not (yet) well-versed with this area to express my ideas here correctly, sorry) - nested class-namespaces for implementation of previously declared nested classes Does this make sense? 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/. ------=_Part_35_12028995.1383726886030 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Monday, November 4, 2013 11:17:24 PM UTC+1, Ric= hard Smith wrote:
On Mon, Nov 4, 2013 at 12:36 PM, Zhihao Yuan <z...@miator.net> wrote:
=
On Mon, Nov 4, 2013 at 1:01 PM, Richard Smith <ric...@metafoo= ..co.uk> wrote:
>> //foo.cc:
>>
>> class Foo namespace {
>
>
> "class X namespace" looks a lot like "allow me to violate access contr= ol
> here, please".

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

If yo= u can add friends to a 'class namespace', you can trivially use it to viola= te 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) =3D 0;
} *launderer;

class = Foo namespace {
  struct FooLaunderer : Launderer {
    FooLaunderer() { launderer =3D this; }
    int get(Foo *p) { return p->_f; }
  } = static theLaunderer;
}
<= br>
The above code would not be valid in "class namespace", there= is no "free-floating this pointer" just because you're in the "class names= pace". As I wrote in my original post, the primary motivation for class-nam= espace is to allow the implementation of already declared members to be les= s verbose / more uniform, the new idea sparkled by this thread is to allow = declaration / definition of yet undeclared _private_ member functions. I do= n't think they could be used to circumvent access control in any way.
=

Basically, the following would be allowed in class-name= space:
- using declarations
- typedefs
- defi= nition of previously declared members / member functions
- declar= ation / definition of new _private_ member functions or _private_ static me= mber functions (these should probably be "special" regarding linkage, they = should be TU bound and not exported, but I'm not (yet) well-versed with thi= s area to express my ideas here correctly, sorry)
- nested class-= namespaces for implementation of previously declared nested classes

Does this make sense?
 

Foo::= FooLaunderer Foo::theLaunderer;

int evil_get_membe= r(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 local clas= s instead of a member function instead). So: this subtly breaks access cont= rol.

> But since we're brainstorming here, we can get most of the benefit her= e 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++ t= o 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 f= rom
    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 se= em like a big problem to me, especially not once we have modules. I don't t= hink 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>.
------=_Part_35_12028995.1383726886030-- .