220 4168 article Path: news.gmane.org!not-for-mail From: Hariharan Subramanian Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: A cleaner way to define nested class/structure Date: Thu, 2 May 2013 11:11:32 +0530 Lines: 244 Approved: news@gmane.org Message-ID: References: <27175469-a158-4bc1-9f30-66e3a647e931@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b3a7d92d26eb404dbb5afde X-Trace: ger.gmane.org 1367473295 22755 80.91.229.3 (2 May 2013 05:41:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 May 2013 05:41:35 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCJZFFHTQQIBBDPZQ6GAKGQEID32WCA@isocpp.org Thu May 02 07:41:34 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f69.google.com ([209.85.215.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UXmGs-0005tQ-9V for gclcip-std-proposals@m.gmane.org; Thu, 02 May 2013 07:41:34 +0200 Original-Received: by mail-la0-f69.google.com with SMTP id er20sf342708lab.0 for ; Wed, 01 May 2013 22:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:received-spf:mime-version :x-received:in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-google-group-id:list-post :list-help:list-archive:list-subscribe:list-unsubscribe:content-type; bh=8t+tA0WAhrgIohnXYxhAzEKLpn9ogF3AsQUDbPatTC4=; b=uq0Pfbcs/nb6PWfmdcmf8/ENQcwKW6JDw2NOSFC9jgjOm61OuVRsD55Mz3A+9BBbvC bWme6oKI3P658/GSugMg217tB/midvdVwke+MbHA73JWSeg771OVC/mGhoh3fCADkDB4 cS/8BLzTQU3kn+UuSomm57abWvx86Zd61uhmIC32MngfKMaKDgF/GIc4vEF9TCfBFAuy DI+KHoRxbcAddFn2+22kV9KyNeTRXcoH9EZN1dEhfIuTaBbpjrFEpVnldQAe9oDiG0Au PapXZRcDb74SDCdUtlaYGpvVSeAVPqKlhS6OOrr6mMZiTZRYFFlmt9J0zr/FsreoHRnD X-Received: by 10.112.73.7 with SMTP id h7mr5657437lbv.0.1367473293935; Wed, 01 May 2013 22:41:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.2.65 with SMTP id 1ls98229las.27.gmail; Wed, 01 May 2013 22:41:32 -0700 (PDT) X-Received: by 10.152.4.40 with SMTP id h8mr1922817lah.34.1367473292448; Wed, 01 May 2013 22:41:32 -0700 (PDT) Original-Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by mx.google.com with ESMTPS id qg10si837527lbb.275.2013.05.01.22.41.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 May 2013 22:41:32 -0700 (PDT) Received-SPF: pass (google.com: domain of tohari@gmail.com designates 209.85.217.171 as permitted sender) client-ip=209.85.217.171; Original-Received: by mail-lb0-f171.google.com with SMTP id u10so177718lbi.2 for ; Wed, 01 May 2013 22:41:32 -0700 (PDT) X-Received: by 10.112.145.230 with SMTP id sx6mr2088419lbb.49.1367473292208; Wed, 01 May 2013 22:41:32 -0700 (PDT) Original-Received: by 10.112.33.177 with HTTP; Wed, 1 May 2013 22:41:32 -0700 (PDT) In-Reply-To: X-Original-Sender: tohari@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of tohari@gmail.com designates 209.85.217.171 as permitted sender) smtp.mail=tohari@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:4168 Archived-At: --047d7b3a7d92d26eb404dbb5afde Content-Type: text/plain; charset=ISO-8859-1 Iteration 2: class Outer; class Outer::Inner1 { int i; }; Outer::Inner1 *i1; //The above should result in compilation error. Because we do not know yet if Inner1 is private or public //even though we are just declaring a pointer. It should wait till we define the Outer class. class Outer { public: class Inner1; //non-declaration of this should be a compilation error class Inner2; private: Inner1 inner1; //No issues Inner2 *inner2; //No issues }; class Outer::Inner2 { int j; }; Outer::Inner1 *i1; //No compilation error because we know that it's public -------- Because Inner1 is usable outside only after the Outer class is defined there should be no other change to the language specification. Regards, Hariharan S On Tue, Apr 30, 2013 at 11:19 PM, Lawrence Crowl wrote: > On Apr 29, 2013 Lawrence Crowl wrote: > > Why isn't the following solution sufficient? > > > > class Outer { > > class Inner1 { > > int i1; > > }; > > class Inner2; > > Inner1 inner1; > > Inner2 *inner2; > > }; > > > > class Outer::Inner2 { > > int i2; > > }; > > On Apr 29, 2013 Hariharan Subramanian wrote: > > It is sufficient but I think it is incomplete. I am able to define > > a nested class outside as long as I have a pointer/reference > > variable. This proposal completes it by giving the ability to > > define the nested class outside even if we have an object. This > > improves readability. This is as good as (or as bad as) the > > existing one. > > On 4/30/13, Tony V E wrote: > > It isn't very nice when Inner1 is large. > > > > Same with inline member functions - you can define them inside the > > class, but sometimes it is nicer to define them after the class > > (yet still in the header, still inline). The only difference with > > inner classes would be that you would need to define them first. > > > > You see similar things in boost libraries that use the > > boost::detail namespace. (There are other reasons to put stuff > > in boost::detail, inner classes is just one.) > > Okay, so you two have two reasons, useful generality and readability. > Now we need a discussion of any potential language ambiguities, the > costs of implementation, and eventually wording changes to the > standard. All of this should be collected into a formal paper for > a meeting. The next one is in Chicago this fall, but the committee > might be extra busy getting C++14 out, so were I you, I would shoot > for the meeting after that. > > -- > Lawrence Crowl > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/l865qYE3Wa8/unsubscribe?hl=en > . > To unsubscribe from this group and all its topics, 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/?hl=en. > > > -- --- 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/?hl=en. --047d7b3a7d92d26eb404dbb5afde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Iteration 2:

class Outer;

class Outer::Inner1 {
=A0 =A0= =A0 int i;
};

Outer::= Inner1 *i1;
//The above should result in compilation error. Because we do no= t know yet if Inner1 is private or public
//even though we = are just declaring a pointer. It should wait till we define the Outer class= ..

class Outer {
public:
=
=A0 =A0 class Inner1; =A0//non-declaration of this should be a c= ompilation error
=A0 =A0 class Inner2;

=
private:
=A0 =A0Inner1 inner1; =A0 //No issues
=A0 =A0Inner2 *inner2; =A0//No issues
};

class Outer::Inner2 {
=A0= =A0int j;
};

Outer::Inner1 *i1; //No = compilation error because we know that it's public

=
--------

Because Inne= r1 is usable outside only after the Outer class is defined there should be = no other change to the language specification.

Regards,
Hariharan S
<= div style>


On Tue, Apr 30, 2013 at 11:19 PM, Lawrence Crowl <crowl@goog= lers.com> wrote:
On Apr 29, 2013 Lawrence C= rowl <crowl@googlers.com> w= rote:
> Why isn't the following solution sufficient?
>
> class Outer {
> =A0 class Inner1 {
> =A0 =A0 int i1;
> =A0 };
> =A0 class Inner2;
> =A0 Inner1 inner1;
> =A0 Inner2 *inner2;
> };
>
> class Outer::Inner2 {
> =A0 int i2;
> };

On Apr 29, 2013 Hariharan Subramanian <tohari@gmail.com> wrote:
> It is sufficient but I think it is incomplete. I am able to define
> a nested class outside as long as I have a pointer/reference
> variable. This proposal completes it by giving the ability to
> define the nested class outside even if we have an object. This
> improves readability. This is as good as (or as bad as) the
> existing one.

On 4/30/13, Tony V E <tvaneerd@gmail.com> wrote:
> It isn't very nice when Inner1 is large.
>
> Same with inline member functions - you can define them inside the
> class, but sometimes it is nicer to define them after the class
> (yet still in the header, still inline). =A0The only difference with > inner classes would be that you would need to define them first.
>
> You see similar things in boost libraries that use the
> boost::detail namespace. =A0(There are other reasons to put stuff
> in boost::detail, inner classes is just one.)

Okay, so you two have two reasons, useful generality and readability.=
Now we need a discussion of any potential language ambiguities, the
costs of implementation, and eventually wording changes to the
standard. =A0All of this should be collected into a formal paper for
a meeting. =A0The next one is in Chicago this fall, but the committee
might be extra busy getting C++14 out, so were I you, I would shoot
for the meeting after that.

--
Lawrence Crowl

--

---
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/l8= 65qYE3Wa8/unsubscribe?hl=3Den.
To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscrib= e@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/?hl=3Den.



--
 
---
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-pro= posals/?hl=3Den.
 
 
--047d7b3a7d92d26eb404dbb5afde-- .