220 6246 <6ac8afd6-befd-4bc9-a27e-4852837f72ac@isocpp.org> 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:25:04 -0700 (PDT) Lines: 219 Approved: news@gmane.org Message-ID: <6ac8afd6-befd-4bc9-a27e-4852837f72ac@isocpp.org> References: <522b3d80.6cf5420a.5c7c.ffffeeb7@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_676_14340099.1378567504311" X-Trace: ger.gmane.org 1378567506 30885 80.91.229.3 (7 Sep 2013 15:25:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Sep 2013 15:25:06 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCXLLRHD7IDRBUEKVWIQKGQEAWHYS7Q@isocpp.org Sat Sep 07 17:25:08 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f71.google.com ([209.85.216.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VIKNm-0007Yp-1R for gclcip-std-proposals@m.gmane.org; Sat, 07 Sep 2013 17:25:06 +0200 Original-Received: by mail-qa0-f71.google.com with SMTP id hu16sf2659058qab.2 for ; Sat, 07 Sep 2013 08:25:05 -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=jPxpeHH/jcmZiqBvfXTqRXwoOy5uB/EV3sTQnYYS3jU=; b=JihnkCmxsIiuO8LeorbqPMhqeKkEsehSMKkNxJEqgu8RzbWV8v/zFWHcQJErBMiudl LeHi+yd4Kl2LgqP2ZGAKHRPKYYjX46Oi542SCuDeUkDTCFSnLaERrPICOAF1Ywlkw1Ui UczsLriN3SCRro3AOpr2jzu3YbpM0REWULukvVYSGK8iWJAJ1wHQY/6Tuf9nKRkhl2qK pJsDUWpDYBeuElapJZskq2ceTro/dRbynQ+4Ucy2ZxMPogucKCYqWvHPTjmWNTxoSv0g QF0vmKvi1crCtDXzp6pnjkzI1DN3i0MtW0WEAgVZNQLR7Og3Lu11sls+rM03x2c3a5Hu KY8A== X-Received: by 10.236.14.100 with SMTP id c64mr2898023yhc.38.1378567505119; Sat, 07 Sep 2013 08:25:05 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.24.172 with SMTP id v12ls1273784qef.91.gmail; Sat, 07 Sep 2013 08:25:04 -0700 (PDT) X-Received: by 10.49.3.134 with SMTP id c6mr374086qec.0.1378567504639; Sat, 07 Sep 2013 08:25:04 -0700 (PDT) In-Reply-To: <522b3d80.6cf5420a.5c7c.ffffeeb7@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:6246 Archived-At: ------=_Part_676_14340099.1378567504311 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Protected members servers that to share the realization (not the interface)= =20 with its derived classes. If two classes share the common realization of=20 course they depend on each other. However objects of derived classes are in= =20 general objects of base classes. So there is nothing common with interface.= =20 There is common realization. =20 Wiyth same effect you could say that private members are also an interface= =20 because friend functions depend on private members of the befriended class.= =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 th= e=20 > interface of that class. (e.g. something like "push_back increases size b= y=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 depe= nd=20 > on the member x in your example, because it is private. Therefore it is n= ot=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 std::forward_li= st > 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 UTC= +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 just= =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 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_676_14340099.1378567504311 Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: quoted-printable
Protected members servers that to share the realizati= on (not the interface) with its derived classes. If two classes share the c= ommon realization of course they depend on each other. However objects of d= erived classes are in general objects of base classes. So there is nothing = common with interface. There is common realization.
 
<= div>Wiyth same effect you could say that private members are also an interf= ace because friend functions depend on private members of the befriended cl= ass. :)]
 
It is totally wrong approach.

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 18:5= 1: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 possible 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 ex= press that constraint in the language)

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

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

----- Reply message -----
From: "Vlad = from Moscow" <vlad....@mail.ru>
To: <std-pr...@= isocpp.org>
Subject: [std-proposals] 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 conclus= ions. For example
 
class A
{
= private:
   int x;
public:
 &= nbsp; A( int i =3D 0 ) : x( i ) {}
   int get() const {= return x; }
};
 
Does it mean that if f= unction get() uses private member x that x is the interface of the class?!<= /div>
  
 

=D3=D5=C2=C2=CF=D4= =C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 18:09:12 UTC+4 =D0=CF=CC=D8= =DA=CF=D7=C1=D4=C5=CC=D8 Patrick M. Niedzielski =CE=C1=D0=C9=D3=C1=CC:
On sab, 2013-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 &= 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_676_14340099.1378567504311-- .