220 6249 article Path: news.gmane.org!not-for-mail From: Vlad from Moscow Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Specialization of std::stack for std::forward_list Date: Sat, 7 Sep 2013 08:46:10 -0700 (PDT) Lines: 307 Approved: news@gmane.org Message-ID: References: <522b4794.4488440a.6ec0.ffffdbe9@mx.google.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_581_31739817.1378568770794" X-Trace: ger.gmane.org 1378568770 9781 80.91.229.3 (7 Sep 2013 15:46:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Sep 2013 15:46:10 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCXLLRHD7IDRBQ4UVWIQKGQEGYMIJZQ@isocpp.org Sat Sep 07 17:46:14 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ve0-f200.google.com ([209.85.128.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VIKiC-0005cY-NF for gclcip-std-proposals@m.gmane.org; Sat, 07 Sep 2013 17:46:12 +0200 Original-Received: by mail-ve0-f200.google.com with SMTP id oy12sf4205621veb.7 for ; Sat, 07 Sep 2013 08:46:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=Ah7lFxbMUIu/pB8nvdXdDWYpaXvSWKQ7rkWoffsaHfA=; b=mBWSLvtb2euAYajQtrcYP3Jx/W+ELMdz80Z2jvLTooYP0drDSvbtu7f+m2z4HJfdi5 d4SJa1uFnGywAgF+7VzjYS6NXm31JkKi1mzbUsZ/OrefP71zgMwnPNuovVKVAvhE3vc2 Wj0cuQKCwVyTqBSAWqRo78J3pV+eoaZeaX+zzWEx+eaoYol7+iRGLxJ1z2RIU1ebBcvP SHnH7JXbOanqqNGppFTdg9STLl9w2CQa0Dund0jweHuLL9zHBsr1xunBrqveoUm+odPc c0iTejLdhh71pMw2/E2tgWFB9q75OKHte9D4qvvk5e6NRdfve1Am2AclY9w8SY/Pg8je ywrQ== X-Received: by 10.236.19.225 with SMTP id n61mr2848887yhn.8.1378568771578; Sat, 07 Sep 2013 08:46:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.39.193 with SMTP id r1ls1299878qek.30.gmail; Sat, 07 Sep 2013 08:46:11 -0700 (PDT) X-Received: by 10.49.99.65 with SMTP id eo1mr381843qeb.3.1378568771129; Sat, 07 Sep 2013 08:46:11 -0700 (PDT) In-Reply-To: <522b4794.4488440a.6ec0.ffffdbe9@mx.google.com> X-Original-Sender: vlad.moscow@mail.ru 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:6249 Archived-At: ------=_Part_581_31739817.1378568770794 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Nevertheless the base class provides some part of the realization to its=20 derived class. One more private members are means of sharing the common=20 realization. Realization is not the interface.=20 =20 The interface of class std:;stack does not depend of the underlaying=20 container. It is its realization that depends on the features of the=20 underlined container. The stack is a logical adstraction and not the=20 "physical interface" as Ville says. It is the underlaying container=20 provides "physical interface" for std:;stack. It is because stack is a=20 logical abstraction std::stack is a container adapter. =20 std:;stack simply delegates part of the realization of its underlaying=20 container to its derived classes. Of course derived classes can rely on the= =20 this delegated realization of the underlined container of std:;stack.=20 Nevertheless this has nothing common with the interface of std::stack. The= =20 interface of std::stack iis not cjanged. =D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 19:34:43 UTC+4= =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Billy O'Neal=20 =CE=C1=D0=C9=D3=C1=CC: > Friend functions are part of the class External code cannot add friends= =20 > External code can add derived classes. > > Sent from a touchscreen. Please excuse the brevity and tpyos. > > ----- Reply message ----- > From: "Vlad from Moscow" > > To: > > Subject: [std-proposals] Specialization of std::stack for std::forward_li= st > Date: Sat, Sep 7, 2013 8:25 AM > > Protected members servers that to share the realization (not the=20 > interface) with its derived classes. If two classes share the common=20 > realization of course they depend on each other. However objects of deriv= ed=20 > classes are in general objects of base classes. So there is nothing commo= n=20 > with interface. There is common realization. > =20 > Wiyth same effect you could say that private members are also an interfac= e=20 > because friend functions depend on private members of the befriended clas= s.=20 > :)] > =20 > It is totally wrong approach. > > =D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 18:51:44 UTC= +4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Billy O'Neal=20 > =CE=C1=D0=C9=D3=C1=CC: > >> No, because x is private. >> >> If it is possible for code external to the class to depend on some=20 >> behavior or member of a class, than that behavior or member is part of t= he=20 >> interface of that class. (e.g. something like "push_back increases size = by=20 >> 1" is part of vector's interface, even though there is no way to express= =20 >> that constraint in the language) >> >> External code can rely on the protected container c by deriving from=20 >> stack. Therefore, it is part of the interface. External code can not dep= end=20 >> on the member x in your example, because it is private. Therefore it is = not=20 >> part of the interface. >> >> Sent from a touchscreen. Please excuse the brevity and tpyos. >> >> ----- Reply message ----- >> From: "Vlad from Moscow" >> To: >> Subject: [std-proposals] Specialization of std::stack for=20 >> std::forward_list >> Date: Sat, Sep 7, 2013 7:28 AM >> >> I even could write a more simple example.to demonstrate your wrong=20 >> conclusions. For example >> =20 >> class A >> { >> private:=20 >> int x; >> public: >> A( int i =3D 0 ) : x( i ) {} >> int get() const { return x; } >> }; >> =20 >> Does it mean that if function get() uses private member x that x is the= =20 >> interface of the class?! >> =20 >> =20 >> >> =D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 18:09:12 UT= C+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Patrick M.=20 >> Niedzielski =CE=C1=D0=C9=D3=C1=CC: >> >>> On sab, 2013-09-07 at 07:07 -0700, Vlad from Moscow wrote:=20 >>> > Again you are mistaken. The client code knows nothing about protected= =20 >>> > members of your class. It relies only on the interface you provided.= =20 >>> You=20 >>> > confuse the realization with the interface.=20 >>> >>> I'm sorry, I don't see how I haven't shown that the client code=20 >>> SneakyFoo that a user of my library would write knows nothing about=20 >>> Foo's protected member, especially since it uses the member.=20 >>> >>> I don't wish to continue this discussion any further, as you don't seem= =20 >>> to be addressing or trying to understand my points, and instead are jus= t=20 >>> claiming that I'm wrong without giving any reasoning.=20 >>> >>> Best,=20 >>> Patrick=20 >>> >> --=20 >> =20 >> ---=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to std-proposal...@isocpp.org. >> To post to this group, send email to std-pr...@isocpp.org. >> Visit this group at=20 >> http://groups.google.com/a/isocpp.org/group/std-proposals/. >> > --=20 > =20 > ---=20 > You received this message because you are subscribed to the Google Groups= =20 > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to std-proposal...@isocpp.org . > To post to this group, send email to std-pr...@isocpp.org . > Visit this group at=20 > http://groups.google.com/a/isocpp.org/group/std-proposals/. > --=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/. ------=_Part_581_31739817.1378568770794 Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: quoted-printable
Nevertheless the base class provides some part of the= realization to its derived class. One more private members are means of sh= aring the common realization. Realization is not the interface.
=  
The interface of class std:;stack does not depend of the u= nderlaying container. It is its realization that depends on the features of= the underlined container. The stack is a logical adstraction and not the "= physical interface" as Ville says. It is the underlaying container pro= vides "physical interface" for std:;stack. It is because stack is a logical= abstraction std::stack is a container adapter.
 
= std:;stack simply delegates part of the realization of its underlaying cont= ainer to its derived classes. Of course derived classes can rely on the thi= s delegated realization of the underlined container of std:;stack. Neverthe= less this has nothing common with the interface of std::stack. The interfac= e of std::stack iis not cjanged.

=D3=D5=C2=C2=CF=D4=C1, 7 =D3= =C5=CE=D4=D1=C2=D2=D1 2013 =C7., 19:34:43 UTC+4 =D0=CF=CC=D8=DA=CF=D7= =C1=D4=C5=CC=D8 Billy O'Neal =CE=C1=D0=C9=D3=C1=CC:
vlad.= ....@mail.ru>
To: <std-pr...@isocpp.org>
Subjec= t: [std-proposals] Specialization of std::stack for std::forward_list
Da= te: Sat, Sep 7, 2013 8:25 AM

Protected= members servers that to share the realization (not the interface) with its= derived classes. If two classes share the common realization of course the= y depend on each other. However objects of derived classes are in general o= bjects of base classes. So there is nothing common with interface. There is= common realization.
 
Wiyth same effect you could= say that private members are also an interface because friend functions de= pend on private members of the befriended class. :)]
 
=
It is totally wrong approach.

=D3=D5=C2=C2=CF=D4=C1, 7 = =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 18:51:44 UTC+4 =D0=CF=CC=D8=DA=CF= =D7=C1=D4=C5=CC=D8 Billy O'Neal =CE=C1=D0=C9=D3=C1=CC:
No, because x is private.

If it is possib= le for code external to the class to depend on some behavior or member of a= class, than that behavior or member is part of the interface of that class= .. (e.g. something like "push_back increases size by 1" is part of vector's = interface, even though there is no way to express that constraint in the la= nguage)

External code can rely on the protected co= ntainer c by deriving from stack. Therefore, it is part of the interface. E= xternal code can not depend on the member x in your example, because it is = private. Therefore it is not part of the interface.

Sent from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: "Vlad from Moscow" <vlad....@ma= il.ru>
To: <std-pr...@isocpp.org>
Subject: [std-p= roposals] Specialization of std::stack for std::forward_list
Date: Sat, = Sep 7, 2013 7:28 AM

I even could = write a more simple example= ..to demonstrate your wrong conclusions. For example
 
class A
{
private:
   int = x;
public:
   A( int i =3D 0 ) : x( i ) {}
   int get() const { return x; }
};
&= nbsp;
Does it mean that if function get() uses private member x t= hat x is the interface of the class?!
  
&nb= sp;

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nb= sp;=C7., 18:09:12 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Patrick M. Nie= dzielski =CE=C1=D0=C9=D3=C1=CC:
On sab, 2= 013-09-07 at 07:07 -0700, Vlad from Moscow wrote:
> Again you are mistaken. The client code knows nothing about protec= ted=20
> members of your class. It relies only on the interface you provide= d. You=20
> confuse the realization with the interface.=20

I'm sorry, I don't see how I haven't shown that the client code
SneakyFoo that a user of my library would write knows nothing about
Foo's protected member, especially since it uses the member.

I don't wish to continue this discussion any further, as you don't seem
to be addressing or trying to understand my points, and instead are jus= t
claiming that I'm wrong without giving any reasoning.

Best,
Patrick

--
 
---
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.or= g/group/std-proposals/.

--
 
---
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.or= g/group/std-proposals/.

--
 
---
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_581_31739817.1378568770794-- .