220 4094 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: Tue, 30 Apr 2013 10:50:49 +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=047d7b3441d613207404db8d2a1a X-Trace: ger.gmane.org 1367299253 7787 80.91.229.3 (30 Apr 2013 05:20:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Apr 2013 05:20:53 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCJZFFHTQQIBBMNJ7WFQKGQELDGJNKI@isocpp.org Tue Apr 30 07:20:52 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 1UX2zi-0001WF-LB for gclcip-std-proposals@m.gmane.org; Tue, 30 Apr 2013 07:20:50 +0200 Original-Received: by mail-la0-f69.google.com with SMTP id er20sf159116lab.8 for ; Mon, 29 Apr 2013 22:20:50 -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=xmcs8xG9qQuhY/944Zf7+TQAFEQWYDFs75H9JjA+WOU=; b=nND9JgH12txfYESrPpbFTG2qOkNWVpNIQ/vmnzRahO2lx+9rwX5ze69PGNn+O/s9BJ 0JDwQC+yzHFi3w/9jEJT6+6n2RXvraIytajrAHq0Ns2vnG/rOW9CPMUzNaVGhaUKY33y +fG+MhP/orTu8LObWRL/KuelqlFNqEM5jIXD7d0b7WLlLwQW3bZVc293sZqNAXR4VNdJ RAs9n2fFfqZprIXCEZbSCKHlY9Hgozep0zqOojQOFduF9+gcpwjMHZXRugh3Kr2XXWwA 01PLpBt1bEWS8A0VQa4csu826htSXSBlnMX/4aNNeW2SDQgOPJM218BZU/s2LWT+KqBQ X-Received: by 10.112.59.10 with SMTP id v10mr11390852lbq.12.1367299250255; Mon, 29 Apr 2013 22:20:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.21.37 with SMTP id s5ls772lae.55.gmail; Mon, 29 Apr 2013 22:20:49 -0700 (PDT) X-Received: by 10.152.116.113 with SMTP id jv17mr24883241lab.35.1367299249772; Mon, 29 Apr 2013 22:20:49 -0700 (PDT) Original-Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by mx.google.com with ESMTPS id ua8si187539lbb.210.2013.04.29.22.20.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Apr 2013 22:20:49 -0700 (PDT) Received-SPF: pass (google.com: domain of tohari@gmail.com designates 209.85.217.177 as permitted sender) client-ip=209.85.217.177; Original-Received: by mail-lb0-f177.google.com with SMTP id x10so179700lbi.22 for ; Mon, 29 Apr 2013 22:20:49 -0700 (PDT) X-Received: by 10.112.129.202 with SMTP id ny10mr18283738lbb.124.1367299249609; Mon, 29 Apr 2013 22:20:49 -0700 (PDT) Original-Received: by 10.112.33.177 with HTTP; Mon, 29 Apr 2013 22:20:49 -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.177 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:4094 Archived-At: --047d7b3441d613207404db8d2a1a Content-Type: text/plain; charset=ISO-8859-1 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 Tue, Apr 30, 2013 at 12:27 AM, Lawrence Crowl wrote: > On 4/29/13, Hariharan Subramanian wrote: > > Problem: > > > > class Outer { > > class Inner1; > > class Inner2; > > > > Inner1 inner1; > > Inner2 *inner2; > > }; > > > > class Outer::Inner1 { > > int i1; > > }; > > > > class Outer::Inner2 { > > int i2; > > }; > > > > The code above results in compilation error because the class Inner1 is > not > > > > defined before the declaration of the object inner1. Inner2 obviously has > > no problem.Defining the nested classes within the Outer class hampers > > readability. > > > > Solution: > > > > class Outer; //Declare the Outer class > > > > class Outer::Inner1 { //Define the Inner1 class > > int i1; > > }; > > > > class Outer { //If this class is not defined in the same > > compilation unit then it should result in an error because Inner1 is > > defined as a nested class but the nesting class is undefined. > > class Inner1; //If this is absent then it should result in compilation > > error > > class Inner2; > > > > Inner1 inner1; > > Inner2 *inner2; > > }; > > > > class Outer::Inner2 { > > int i2; > > }; > > > > This solution honours the C++ convention that the class must be defined > > before creating an object of its type. This certainly improves > readability. > > Why isn't the following solution sufficient? > > class Outer { > class Inner1 { > int i1; > }; > class Inner2; > Inner1 inner1; > Inner2 *inner2; > }; > > class Outer::Inner2 { > int i2; > }; > > -- > 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. --047d7b3441d613207404db8d2a1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It is sufficient but I think it is incomplete. I am able t= o define a nested class outside as long as I have a pointer/reference varia= ble. 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 Tue, Apr 3= 0, 2013 at 12:27 AM, Lawrence Crowl <crowl@googlers.com> wr= ote:
On 4= /29/13, Hariharan Subramanian <tohar= i@gmail.com> wrote:
> Problem:
>
> class Outer {
> class Inner1;
> class Inner2;
>
> Inner1 inner1;
> Inner2 *inner2;
> };
>
> class Outer::Inner1 {
> int i1;
> };
>
> class Outer::Inner2 {
> int i2;
> };
>
> The code above results in compilation error because the class Inner1 i= s not
>
> defined before the declaration of the object inner1. Inner2 obviously = has
> no problem.Defining the nested classes within the Outer class hampers<= br> > readability.
>
> Solution:
>
> class Outer; //Declare the Outer class
>
> class Outer::Inner1 { //Define the Inner1 class
> int i1;
> };
>
> class Outer { =A0 =A0 =A0 =A0 =A0 //If this class is not defined in th= e same
> compilation unit then it should result in an error because Inner1 is > defined as a nested class but the nesting class is undefined.
> class Inner1; =A0 //If this is absent then it should result in compila= tion
> error
> class Inner2;
>
> Inner1 inner1;
> Inner2 *inner2;
> };
>
> class Outer::Inner2 {
> int i2;
> };
>
> This solution honours the C++ convention that the class must be define= d
> before creating an object of its type. This certainly improves readabi= lity.

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;
};

--
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.
 
 
--047d7b3441d613207404db8d2a1a-- .