------=_Part_364_9972710.1378489058289
Content-Type: text/plain; charset=ISO-8859-1

I would like to propose to include specialization of std::stack for
std::forward_list.

In fact std::forward_list has already all characteristics of a stack. There
will be only one difference compared with the primary class std::stack:
the specialization will not contain member function size() because
std::forward_list has no such member.

What will you say?

--

---
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_364_9972710.1378489058289
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I would like to propose to include specialization of =
std::stack for std::forward_list. </div><div>&nbsp;</div><div>In fact std::=
forward_list has already all characteristics of a stack. There will be only=
 one difference compared with the primary class std::stack:&nbsp; the speci=
alization will not contain member function size() because std::forward_list=
 has no such member.</div><div>&nbsp;</div><div>What will you say?</div></d=
iv>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_364_9972710.1378489058289--

.

------=_Part_8718_1296828.1378491467798
Content-Type: text/plain; charset=ISO-8859-1

Instead of a single specialization, would it not be better to just make
size() only enabled for wrapped types which have a size() using some
enable_if logic?

On Friday, September 6, 2013 10:37:38 AM UTC-7, Vlad from Moscow wrote:
>
> I would like to propose to include specialization of std::stack for
> std::forward_list.
>
> In fact std::forward_list has already all characteristics of a stack.
> There will be only one difference compared with the primary class
> std::stack:  the specialization will not contain member function size()
> because std::forward_list has no such member.
>
> What will you say?
>

--

---
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_8718_1296828.1378491467798
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Instead of a single specialization, would it not be better=
 to just make size() only enabled for wrapped types which have a size() usi=
ng some enable_if logic?<br><br>On Friday, September 6, 2013 10:37:38 AM UT=
C-7, Vlad from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div>I would like to propose to include specialization of st=
d::stack for std::forward_list. </div><div>&nbsp;</div><div>In fact std::fo=
rward_list has already all characteristics of a stack. There will be only o=
ne difference compared with the primary class std::stack:&nbsp; the special=
ization will not contain member function size() because std::forward_list h=
as no such member.</div><div>&nbsp;</div><div>What will you say?</div></div=
></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_8718_1296828.1378491467798--

.

------=_Part_6209_863209.1378491945730
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

It will not be enough because std:;forward_list has no such member=20
functions as push_back() and back used in the realization of std::stack.
=20

=D0=D1=D4=CE=C9=C3=C1, 6 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 22:17:47 UTC+4=
 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Sean Middleditch=20
=CE=C1=D0=C9=D3=C1=CC:

> Instead of a single specialization, would it not be better to just make=
=20
> size() only enabled for wrapped types which have a size() using some=20
> enable_if logic?
>
> On Friday, September 6, 2013 10:37:38 AM UTC-7, Vlad from Moscow wrote:
>>
>> I would like to propose to include specialization of std::stack for=20
>> std::forward_list.=20
>> =20
>> In fact std::forward_list has already all characteristics of a stack.=20
>> There will be only one difference compared with the primary class=20
>> std::stack:  the specialization will not contain member function size()=
=20
>> because std::forward_list has no such member.
>> =20
>> What will you say?
>>
>

--=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_6209_863209.1378491945730
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>It will not be enough because std:;forward_list has n=
o such member functions as push_back() and back used in the realization of =
std::stack.</div><div>&nbsp;</div><div><br>=D0=D1=D4=CE=C9=C3=C1, 6 =D3=C5=
=CE=D4=D1=C2=D2=D1 2013&nbsp;=C7., 22:17:47 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=
=D4=C5=CC=D8 Sean Middleditch =CE=C1=D0=C9=D3=C1=CC:</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div dir=3D"ltr">Instead of a single specialization, would it n=
ot be better to just make size() only enabled for wrapped types which have =
a size() using some enable_if logic?<br><br>On Friday, September 6, 2013 10=
:37:38 AM UTC-7, Vlad from Moscow wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div d=
ir=3D"ltr"><div>I would like to propose to include specialization of std::s=
tack for std::forward_list. </div><div>&nbsp;</div><div>In fact std::forwar=
d_list has already all characteristics of a stack. There will be only one d=
ifference compared with the primary class std::stack:&nbsp; the specializat=
ion will not contain member function size() because std::forward_list has n=
o such member.</div><div>&nbsp;</div><div>What will you say?</div></div></b=
lockquote></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6209_863209.1378491945730--

.

2013/9/6 Vlad from Moscow <vlad.moscow@mail.ru>:
> I would like to propose to include specialization of std::stack for
> std::forward_list.
>
> In fact std::forward_list has already all characteristics of a stack. There
> will be only one difference compared with the primary class std::stack:  the
> specialization will not contain member function size() because
> std::forward_list has no such member.
>
> What will you say?

After you have "eliminated" size(), how do you proceed with push()?

I really don't like this suggestion: stack exists to present a
dedicated subset of operations adapted from a container. If you
specialize stack and start to remove or change the semantics of
functions, this is no longer a uniform wrapper. Since you seem to be
interested in a different kind of view on containers, I suggest to
invent a different one and not trying to distort an apple into a
coconut. std::vector<bool> has often been considered as a bad design
idea, because it does not provide the *same* guarantees as any other
std::vector<T>. Please lets not repeat the same kind of design error
again.

- Daniel

--

---
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_32_7412352.1378492447354
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Daniel, I can not agree with you. The semantic and the interface (except=20
the member function size()) of the stack will not be changed. In fact=20
std::forward_list is the most appropriate container for using as the base=
=20
of the stack. .
=20
By the way I have not understood what is the problem with push?

=D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D0=B0, 6 =D1=81=D0=B5=D0=BD=D1=82=D1=
=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3., 22:28:07 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Daniel Kr=C3=BCgler=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

> 2013/9/6 Vlad from Moscow <vlad....@mail.ru <javascript:>>:=20
> > I would like to propose to include specialization of std::stack for=20
> > std::forward_list.=20
> >=20
> > In fact std::forward_list has already all characteristics of a stack.=
=20
> There=20
> > will be only one difference compared with the primary class std::stack:=
=20
>  the=20
> > specialization will not contain member function size() because=20
> > std::forward_list has no such member.=20
> >=20
> > What will you say?=20
>
> After you have "eliminated" size(), how do you proceed with push()?=20
>
> I really don't like this suggestion: stack exists to present a=20
> dedicated subset of operations adapted from a container. If you=20
> specialize stack and start to remove or change the semantics of=20
> functions, this is no longer a uniform wrapper. Since you seem to be=20
> interested in a different kind of view on containers, I suggest to=20
> invent a different one and not trying to distort an apple into a=20
> coconut. std::vector<bool> has often been considered as a bad design=20
> idea, because it does not provide the *same* guarantees as any other=20
> std::vector<T>. Please lets not repeat the same kind of design error=20
> again.=20
>
> - Daniel=20
>

--=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_32_7412352.1378492447354
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Daniel, I can not agree with you. The semantic and th=
e interface (except the member function size()) of the stack will not be ch=
anged. In fact std::forward_list is the most appropriate container for usin=
g as the base of the stack.&nbsp;.</div><div>&nbsp;</div><div>By the way I =
have not understood what is the problem with push?</div><div><br>=D0=BF=D1=
=8F=D1=82=D0=BD=D0=B8=D1=86=D0=B0, 6 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=
=D1=80=D1=8F 2013&nbsp;=D0=B3., 22:28:07 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=
=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Daniel Kr=C3=BCgler =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;">2013/9=
/6 Vlad from Moscow &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"xisTM5GsF8oJ">vlad....@mail.ru</a>&gt;:
<br>&gt; I would like to propose to include specialization of std::stack fo=
r
<br>&gt; std::forward_list.
<br>&gt;
<br>&gt; In fact std::forward_list has already all characteristics of a sta=
ck. There
<br>&gt; will be only one difference compared with the primary class std::s=
tack: &nbsp;the
<br>&gt; specialization will not contain member function size() because
<br>&gt; std::forward_list has no such member.
<br>&gt;
<br>&gt; What will you say?
<br>
<br>After you have "eliminated" size(), how do you proceed with push()?
<br>
<br>I really don't like this suggestion: stack exists to present a
<br>dedicated subset of operations adapted from a container. If you
<br>specialize stack and start to remove or change the semantics of
<br>functions, this is no longer a uniform wrapper. Since you seem to be
<br>interested in a different kind of view on containers, I suggest to
<br>invent a different one and not trying to distort an apple into a
<br>coconut. std::vector&lt;bool&gt; has often been considered as a bad des=
ign
<br>idea, because it does not provide the *same* guarantees as any other
<br>std::vector&lt;T&gt;. Please lets not repeat the same kind of design er=
ror
<br>again.
<br>
<br>- Daniel
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_32_7412352.1378492447354--

.

2013/9/6 Vlad from Moscow <vlad.moscow@mail.ru>:
> Daniel, I can not agree with you. The semantic and the interface (except the
> member function size())

The single word "except" here is a show stopper for me. std::stack
guarantees access to a member size(), but your specialization won't
provide it.

> of the stack will not be changed. In fact
> std::forward_list is the most appropriate container for using as the base of
> the stack. .
>
> By the way I have not understood what is the problem with push?

std::forward_list does not provide members back() and and push_back()
for some good reason, because these functions cannot be implemented
efficiently for that container. Assuming you suggest to change within
the specialization the calls to front() and push_front() etc, this
changes semantics of the wrapped type. Before that change, we were
able to specify a concept of a type that can be wrapped by a stack,
e.g.

template <MemberStackLikeContainer C>
concept_map StackLikeContainer<C> {
  typedef Container<C>::reference reference;
  typedef Container<C>::const_reference const_reference;
  reference back(C& c) { return c.back(); }
  const_reference back(const C& c) { return c.back(); }
  void pop_back(C& c) { c.pop_back(); }
}

as presented in the last draft with concepts:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf

The fact that this uses language-provided requirements (concepts) is
not relevant for this discussion, the point I'm trying to make is that
your proposal would make the type requirements of std::stack complex
if not muddled. You can easily provide you own adapter of
std::forward_list to satisfy the StackLikeContainer (so to say) of
std::stack, if this is what you want (You have to decide by yourself,
how you handle the lack of size(). In theory you could add a size
counter as part of your adapter to StackLikeContainer, since the
required members are simple enough to update the internal size value
efficiently.

- Daniel

--

---
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/.

.

--089e0160b5e4a8d81f04e5bd3724
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 6, 2013 at 2:50 PM, Daniel Kr=FCgler <daniel.kruegler@gmail.com=
>wrote:

> 2013/9/6 Vlad from Moscow <vlad.moscow@mail.ru>:
> > Daniel, I can not agree with you. The semantic and the interface (excep=
t
> the
> > member function size())
>
> The single word "except" here is a show stopper for me. std::stack
> guarantees access to a member size(), but your specialization won't
> provide it.
>

Bit of a tangent here - I'm surprised forward_list doesn't have a size(),
since, as you say, it wouldn't be hard to implement.
(And assuming the list has more than a few elements, the additional memory
cost is negligible.  As is the performance cost.  IMO.)

Tony

--=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/.

--089e0160b5e4a8d81f04e5bd3724
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Fri, Sep 6, 2013 at 2:50 PM, Daniel Kr=FCgler <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@=
gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im">2013/9/=
6 Vlad from Moscow &lt;<a href=3D"mailto:vlad.moscow@mail.ru">vlad.moscow@m=
ail.ru</a>&gt;:<br>

</div><div class=3D"im">&gt; Daniel, I can not agree with you. The semantic=
 and the interface (except the<br>
&gt; member function size())<br>
<br>
</div>The single word &quot;except&quot; here is a show stopper for me. std=
::stack<br>
guarantees access to a member size(), but your specialization won&#39;t<br>
provide it.<br></blockquote></div><br><div>Bit of a tangent here - I&#39;m=
=20
surprised forward_list doesn&#39;t have a size(), since, as you say, it=20
wouldn&#39;t be hard to implement.<br></div>(And assuming the list has more=
=20
than a few elements, the additional memory cost is negligible.=A0 As is=20
the performance cost.=A0 IMO.)<br><br>Tony <br><br><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0160b5e4a8d81f04e5bd3724--

.

2013/9/6 Tony V E <tvaneerd@gmail.com>:
>
> On Fri, Sep 6, 2013 at 2:50 PM, Daniel Kr=FCgler <daniel.kruegler@gmail.c=
om>
> wrote:
>>
>> 2013/9/6 Vlad from Moscow <vlad.moscow@mail.ru>:
>> > Daniel, I can not agree with you. The semantic and the interface (exce=
pt
>> > the
>> > member function size())
>>
>> The single word "except" here is a show stopper for me. std::stack
>> guarantees access to a member size(), but your specialization won't
>> provide it.
>
>
> Bit of a tangent here - I'm surprised forward_list doesn't have a size(),
> since, as you say, it wouldn't be hard to implement.

See

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.htm

for the design rationale, especially regarding the omission of size().

Note that I didn't say that implementing forward_list with a constant
size() attribute is easy, I said that an adapter that satisfies the
StackLikeContainer requirements (using the nomenclature of C++ with
concepts) needed for the template parameter Container in std::stack is
easy to implement.

> (And assuming the list has more than a few elements, the additional memor=
y
> cost is negligible.  As is the performance cost.  IMO.)

This design choice was deliberate.

- Daniel

--=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_109_1501093.1378503963615
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In fact std::stack is a some sort of an abstract class. It supllies the=20
common interface for different realizations. It is the user who decides=20
whether it will use that or other realization. I do not see any reason that=
=20
prevents the user to use container std::forward_list as the realization of=
=20
the stack interface. There is no member function size()? Who did said that=
=20
it is very important for the stack? For std:;forward_list it is unimportant=
=20
but for std:;stack it is important. It is very strange. There should be one=
=20
stack in the C++ Standard. But the standard should provide any realization=
=20
the user want with using standard containers. std::forward_list is the most=
=20
appropriate realization of the stack in terms of effectiveness in the same=
=20
snse as std::forward_list itself. If you need to use member function size()=
=20
then there  is no problem. Use some other container instead of=20
std::forward_list.
=20

=D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D0=B0, 6 =D1=81=D0=B5=D0=BD=D1=82=D1=
=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3., 22:50:52 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Daniel Kr=C3=BCgler=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

> 2013/9/6 Vlad from Moscow <vlad....@mail.ru <javascript:>>:=20
> > Daniel, I can not agree with you. The semantic and the interface (excep=
t=20
> the=20
> > member function size())=20
>
> The single word "except" here is a show stopper for me. std::stack=20
> guarantees access to a member size(), but your specialization won't=20
> provide it.=20
>
> > of the stack will not be changed. In fact=20
> > std::forward_list is the most appropriate container for using as the=20
> base of=20
> > the stack. .=20
> >=20
> > By the way I have not understood what is the problem with push?=20
>
> std::forward_list does not provide members back() and and push_back()=20
> for some good reason, because these functions cannot be implemented=20
> efficiently for that container. Assuming you suggest to change within=20
> the specialization the calls to front() and push_front() etc, this=20
> changes semantics of the wrapped type. Before that change, we were=20
> able to specify a concept of a type that can be wrapped by a stack,=20
> e.g.=20
>
> template <MemberStackLikeContainer C>=20
> concept_map StackLikeContainer<C> {=20
>   typedef Container<C>::reference reference;=20
>   typedef Container<C>::const_reference const_reference;=20
>   reference back(C& c) { return c.back(); }=20
>   const_reference back(const C& c) { return c.back(); }=20
>   void pop_back(C& c) { c.pop_back(); }=20
> }=20
>
> as presented in the last draft with concepts:=20
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf=20
>
> The fact that this uses language-provided requirements (concepts) is=20
> not relevant for this discussion, the point I'm trying to make is that=20
> your proposal would make the type requirements of std::stack complex=20
> if not muddled. You can easily provide you own adapter of=20
> std::forward_list to satisfy the StackLikeContainer (so to say) of=20
> std::stack, if this is what you want (You have to decide by yourself,=20
> how you handle the lack of size(). In theory you could add a size=20
> counter as part of your adapter to StackLikeContainer, since the=20
> required members are simple enough to update the internal size value=20
> efficiently.=20
>
> - Daniel=20
>

--=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_109_1501093.1378503963615
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>In fact std::stack is a some sort of an abstract clas=
s. It supllies the common interface for different realizations.&nbsp;It is =
the user who decides whether it will use that or other realization. I do no=
t see any reason that prevents the user to use container std::forward_list =
as the realization of the stack interface. There is no member function size=
()? Who did said that it is very important for the stack? For std:;forward_=
list it is unimportant but for std:;stack it is important. It is very stran=
ge. There should be one stack in the C++ Standard. But the standard should =
provide any realization the user want with using standard containers. std::=
forward_list is the most appropriate realization of the stack in terms of e=
ffectiveness in the same snse as std::forward_list itself. If you need to u=
se member function size() then there&nbsp; is no problem. Use some other co=
ntainer instead of std::forward_list.</div><div>&nbsp;</div><div><br>=D0=BF=
=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D0=B0, 6 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=
=B1=D1=80=D1=8F 2013&nbsp;=D0=B3., 22:50:52 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Daniel Kr=C3=BCgler =D0=BD=
=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color:=
 rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">201=
3/9/6 Vlad from Moscow &lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"PfE8GnHXxYgJ">vlad....@mail.ru</a>&gt;:
<br>&gt; Daniel, I can not agree with you. The semantic and the interface (=
except the
<br>&gt; member function size())
<br>
<br>The single word "except" here is a show stopper for me. std::stack
<br>guarantees access to a member size(), but your specialization won't
<br>provide it.
<br>
<br>&gt; of the stack will not be changed. In fact
<br>&gt; std::forward_list is the most appropriate container for using as t=
he base of
<br>&gt; the stack. .
<br>&gt;
<br>&gt; By the way I have not understood what is the problem with push?
<br>
<br>std::forward_list does not provide members back() and and push_back()
<br>for some good reason, because these functions cannot be implemented
<br>efficiently for that container. Assuming you suggest to change within
<br>the specialization the calls to front() and push_front() etc, this
<br>changes semantics of the wrapped type. Before that change, we were
<br>able to specify a concept of a type that can be wrapped by a stack,
<br>e.g.
<br>
<br>template &lt;MemberStackLikeContainer C&gt;
<br>concept_map StackLikeContainer&lt;C&gt; {
<br>&nbsp; typedef Container&lt;C&gt;::reference reference;
<br>&nbsp; typedef Container&lt;C&gt;::const_reference const_reference;
<br>&nbsp; reference back(C&amp; c) { return c.back(); }
<br>&nbsp; const_reference back(const C&amp; c) { return c.back(); }
<br>&nbsp; void pop_back(C&amp; c) { c.pop_back(); }
<br>}
<br>
<br>as presented in the last draft with concepts:
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n291=
4.pdf" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/p=
apers/2009/<wbr>n2914.pdf</a>
<br>
<br>The fact that this uses language-provided requirements (concepts) is
<br>not relevant for this discussion, the point I'm trying to make is that
<br>your proposal would make the type requirements of std::stack complex
<br>if not muddled. You can easily provide you own adapter of
<br>std::forward_list to satisfy the StackLikeContainer (so to say) of
<br>std::stack, if this is what you want (You have to decide by yourself,
<br>how you handle the lack of size(). In theory you could add a size
<br>counter as part of your adapter to StackLikeContainer, since the
<br>required members are simple enough to update the internal size value
<br>efficiently.
<br>
<br>- Daniel
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_109_1501093.1378503963615--

.

--001a11c3fe90f36fbf04e5beb507
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 6, 2013 at 5:01 PM, Daniel Kr=FCgler <daniel.kruegler@gmail.com=
>wrote:

> >
> > Bit of a tangent here - I'm surprised forward_list doesn't have a size(=
),
> > since, as you say, it wouldn't be hard to implement.
>
> See
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.htm
>
> for the design rationale, especially regarding the omission of size().
>
>
Thanks for the link.  Note that it says:

"Note that similar considerations apply to std::list::size()."

Which, (IIUC) at the time, didn't require O(1) size(), but now does.
Wonder if forward_list is worth revisiting.

--=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/.

--001a11c3fe90f36fbf04e5beb507
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, Sep 6, 2013 at 5:01 PM, Daniel Kr=FCgler <span dir=3D"ltr">=
&lt;<a href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.k=
ruegler@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">&gt;<br><div class=3D"im"=
>
&gt; Bit of a tangent here - I&#39;m surprised forward_list doesn&#39;t hav=
e a size(),<br>
&gt; since, as you say, it wouldn&#39;t be hard to implement.<br>
<br>
</div>See<br>
<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.ht=
m" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/200=
8/n2543.htm</a><br>
<br>
for the design rationale, especially regarding the omission of size().<br>
<br></blockquote></div><br></div><div class=3D"gmail_extra">Thanks for the =
link.=A0 Note that it says:<br><br>&quot;Note that similar considerations a=
pply to
<span style=3D"font-family:Courier New">std::list::size()</span>.&quot;<br>=
<br></div><div class=3D"gmail_extra">Which, (IIUC) at the time, didn&#39;t =
require O(1) size(), but now does.=A0 Wonder if forward_list is worth revis=
iting.<br>
<br><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3fe90f36fbf04e5beb507--

.

------=_Part_125_3074965.1378509253187
Content-Type: text/plain; charset=ISO-8859-1



On Friday, September 6, 2013 7:37:38 PM UTC+2, Vlad from Moscow wrote:
>
> I would like to propose to include specialization of std::stack for
> std::forward_list.
>
> In fact std::forward_list has already all characteristics of a stack.
> There will be only one difference compared with the primary class
> std::stack:  the specialization will not contain member function size()
> because std::forward_list has no such member.
>
> What will you say?
>

why no `size()`? nobody can access inner list ergo stack can easy determine
size in const time. `std::stack` require only:

back
push_back
pop_back

that can be in case `std::forward_list` inverted to:

front
push_front
pop_front

maybe we need simple new version of stack? `std::stack_front`?



--

---
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_125_3074965.1378509253187
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, September 6, 2013 7:37:38 PM UTC+2, Vla=
d from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>I would like to propose to include specialization of std::sta=
ck for std::forward_list. </div><div>&nbsp;</div><div>In fact std::forward_=
list has already all characteristics of a stack. There will be only one dif=
ference compared with the primary class std::stack:&nbsp; the specializatio=
n will not contain member function size() because std::forward_list has no =
such member.</div><div>&nbsp;</div><div>What will you say?</div></div></blo=
ckquote><div>&nbsp;</div><div><font size=3D"2"><span style=3D"font-family: =
arial,sans-serif;">why no `size()`? nobody can access inner list ergo stack=
 can easy determine size in const time. `std::stack` require only:<br><br>b=
ack<br>push_back<br>pop_back<br><br>that can be in case `std::forward_list`=
 inverted to:<br><br>front<br>push_front<br>pop_front<br><br>maybe we need =
simple new version of stack? `std::stack_front`?<br><br></span></font><p><f=
ont size=3D"2"><span style=3D"font-family: arial,sans-serif;"><br></span></=
font></p><p><br></p></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_125_3074965.1378509253187--

.

------=_Part_122_16320066.1378511337665
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I doi not agree that we need a new version of stack. All what we need we=20
already have. Moreover stack does not require member function size(). It is=
=20
unnecessary function. What is size()? Inf act is is an analogy of an=20
iterator. Consider using size with an array something as
=20
for ( int i =3D 0; i < n; i++ ) a[i] =3D i;
=20
a + 0 and a + n give us iterators. However stack has no iterators so it=20
does not need the size() function. The logic of functionality of the stack=
=20
is simple. We are popping out elements of the stack while it is not empty.
=20
What we need is simply a specialization of std::stack for=20
std::forward_list. std::forward_list has all functionality of the stack.
=20
=20

=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=81=D0=B5=D0=BD=D1=82=D1=
=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3., 3:14:13 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C=20
inkwizyt...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

>
>
> On Friday, September 6, 2013 7:37:38 PM UTC+2, Vlad from Moscow wrote:
>>
>> I would like to propose to include specialization of std::stack for=20
>> std::forward_list.=20
>> =20
>> In fact std::forward_list has already all characteristics of a stack.=20
>> There will be only one difference compared with the primary class=20
>> std::stack:  the specialization will not contain member function size()=
=20
>> because std::forward_list has no such member.
>> =20
>> What will you say?
>>
> =20
> why no `size()`? nobody can access inner list ergo stack can easy=20
> determine size in const time. `std::stack` require only:
>
> back
> push_back
> pop_back
>
> that can be in case `std::forward_list` inverted to:
>
> front
> push_front
> pop_front
>
> maybe we need simple new version of stack? `std::stack_front`?
>
>
>
>

--=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_122_16320066.1378511337665
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I doi not agree that we need a new version of stack. =
All what we need we already have. Moreover stack does not require member fu=
nction size(). It is unnecessary function. What is size()? Inf act is is an=
 analogy of an iterator. Consider using size with an array something as</di=
v><div>&nbsp;</div><div>for ( int i =3D 0; i &lt; n; i++ ) a[i] =3D i;</div=
><div>&nbsp;</div><div>a + 0 and a + n give us iterators. However stack has=
 no iterators so it does not need the size() function. The logic of functio=
nality of the stack is simple. We are popping out elements of the stack whi=
le it is not empty.</div><div>&nbsp;</div><div>What we need is simply a spe=
cialization of std::stack for std::forward_list. std::forward_list has all =
functionality of the stack.</div><div>&nbsp;</div><div>&nbsp;</div><div><br=
>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=C7., 3:14:13 =
UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 inkwizyt...@gmail.com =CE=C1=D0=
=C9=D3=C1=CC:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br><br>On=
 Friday, September 6, 2013 7:37:38 PM UTC+2, Vlad from Moscow wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;"><div dir=3D"ltr"><div>I would like to propose to incl=
ude specialization of std::stack for std::forward_list. </div><div>&nbsp;</=
div><div>In fact std::forward_list has already all characteristics of a sta=
ck. There will be only one difference compared with the primary class std::=
stack:&nbsp; the specialization will not contain member function size() bec=
ause std::forward_list has no such member.</div><div>&nbsp;</div><div>What =
will you say?</div></div></blockquote><div>&nbsp;</div><div><font size=3D"2=
"><span style=3D"font-family: arial,sans-serif;">why no `size()`? nobody ca=
n access inner list ergo stack can easy determine size in const time. `std:=
:stack` require only:<br><br>back<br>push_back<br>pop_back<br><br>that can =
be in case `std::forward_list` inverted to:<br><br>front<br>push_front<br>p=
op_front<br><br>maybe we need simple new version of stack? `std::stack_fron=
t`?<br><br></span></font><p><font size=3D"2"><span style=3D"font-family: ar=
ial,sans-serif;"><br></span></font></p><p><br></p></div></div></blockquote>=
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_122_16320066.1378511337665--

.

--047d7bf0f67a70d88d04e5c00aa5
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 6, 2013 at 4:48 PM, Vlad from Moscow <vlad.moscow@mail.ru>wrote=
:

> I doi not agree that we need a new version of stack. All what we need we
> already have. Moreover stack does not require member function size(). It =
is
> unnecessary function. What is size()? Inf act is is an analogy of an
> iterator. Consider using size with an array something as
>
> for ( int i =3D 0; i < n; i++ ) a[i] =3D i;
>
> a + 0 and a + n give us iterators. However stack has no iterators so it
> does not need the size() function. The logic of functionality of the stac=
k
> is simple. We are popping out elements of the stack while it is not empty=
..
>
> What we need is simply a specialization of std::stack for
> std::forward_list. std::forward_list has all functionality of the stack.
>

We risk introducing surprising behavior if we add support for this. Right
now, std::stack::push adds elements to the *end* of the stack, and this is
an observable property in various ways (for instance, due to the container
member being protected rather than private). Consider:

template<template<typename...> struct Container>
struct MyStack : public std::stack<int, Container<int>> {
  using stack::stack;
  void print() {
    for (int n : this->c)
      std::cout << n << std::endl;
  }
};

If we taught std::stack to switch to using push_front instead of push_back
when its container is a std::forward_list,
MyStack<std::forward_list>::print would print in the opposite order from
MyStack<any_other_container>::print.

This seems a bit too reminiscent of std::vector<bool> for comfort.

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 3:14:13 UTC+4 =
=D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8
> inkwizyt...@gmail.com =CE=C1=D0=C9=D3=C1=CC:
>
>>
>>
>> On Friday, September 6, 2013 7:37:38 PM UTC+2, Vlad from Moscow wrote:
>>>
>>> I would like to propose to include specialization of std::stack for
>>> std::forward_list.
>>>
>>> In fact std::forward_list has already all characteristics of a stack.
>>> There will be only one difference compared with the primary class
>>> std::stack:  the specialization will not contain member function size()
>>> because std::forward_list has no such member.
>>>
>>> What will you say?
>>>
>>
>> why no `size()`? nobody can access inner list ergo stack can easy
>> determine size in const time. `std::stack` require only:
>>
>> back
>> push_back
>> pop_back
>>
>> that can be in case `std::forward_list` inverted to:
>>
>> front
>> push_front
>> pop_front
>>
>> maybe we need simple new version of stack? `std::stack_front`?
>>
>>
>>
>>  --
>
> ---
> 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/.
>

--=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/.

--047d7bf0f67a70d88d04e5c00aa5
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Sep 6, 2013 at 4:48 PM, Vlad from Moscow <span dir=
=3D"ltr">&lt;<a href=3D"mailto:vlad.moscow@mail.ru" target=3D"_blank">vlad.=
moscow@mail.ru</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I doi not agree that w=
e need a new version of stack. All what we need we already have. Moreover s=
tack does not require member function size(). It is unnecessary function. W=
hat is size()? Inf act is is an analogy of an iterator. Consider using size=
 with an array something as</div>
<div>=9A</div><div>for ( int i =3D 0; i &lt; n; i++ ) a[i] =3D i;</div><div=
>=9A</div><div>a + 0 and a + n give us iterators. However stack has no iter=
ators so it does not need the size() function. The logic of functionality o=
f the stack is simple. We are popping out elements of the stack while it is=
 not empty.</div>
<div>=9A</div><div>What we need is simply a specialization of std::stack fo=
r std::forward_list. std::forward_list has all functionality of the stack.<=
/div></div></blockquote><div><br></div><div>We risk introducing surprising =
behavior if we add support for this. Right now, std::stack::push adds eleme=
nts to the *end* of the stack, and this is an observable property in variou=
s ways (for instance, due to the container member being protected rather th=
an private). Consider:</div>
<div><br></div><div>template&lt;template&lt;typename...&gt; struct Containe=
r&gt;</div><div>struct MyStack : public std::stack&lt;int, Container&lt;int=
&gt;&gt; {</div><div>=9A using stack::stack;</div><div>=9A void print() {</=
div>
<div>=9A =9A for (int n : this-&gt;c)</div><div>=9A =9A =9A std::cout &lt;&=
lt; n &lt;&lt; std::endl;</div><div>=9A }</div><div>};<br></div><div><br></=
div><div>If we taught std::stack to switch to using push_front instead of p=
ush_back when its container is a std::forward_list, MyStack&lt;std::forward=
_list&gt;::print would print in the opposite order from MyStack&lt;any_othe=
r_container&gt;::print.</div>
<div><br></div><div>This seems a bit too reminiscent of std::vector&lt;bool=
&gt; for comfort.</div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">
<div>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013=9A=C7., 3:14:13=
 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 <a href=3D"mailto:inkwizyt...@g=
mail.com" target=3D"_blank">inkwizyt...@gmail.com</a> =CE=C1=D0=C9=D3=C1=CC=
:</div><div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);=
border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><br><br>On Friday, September 6, 2013 7:37:38 PM UTC+2, Vla=
d from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-lef=
t-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div>I would like to propose to include specialization of =
std::stack for std::forward_list. </div><div>=9A</div><div>In fact std::for=
ward_list has already all characteristics of a stack. There will be only on=
e difference compared with the primary class std::stack:=9A the specializat=
ion will not contain member function size() because std::forward_list has n=
o such member.</div>
<div>=9A</div><div>What will you say?</div></div></blockquote><div>=9A</div=
><div><font><span style=3D"font-family:arial,sans-serif">why no `size()`? n=
obody can access inner list ergo stack can easy determine size in const tim=
e. `std::stack` require only:<br>
<br>back<br>push_back<br>pop_back<br><br>that can be in case `std::forward_=
list` inverted to:<br><br>front<br>push_front<br>pop_front<br><br>maybe we =
need simple new version of stack? `std::stack_front`?<br><br></span></font>=
<p>
<font><span style=3D"font-family:arial,sans-serif"><br></span></font></p><p=
><br></p></div></div></blockquote></div></div></div><div class=3D"HOEnZb"><=
div class=3D"h5">

<p></p>

-- <br>
=9A<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bf0f67a70d88d04e5c00aa5--

.

On Fri, 2013-09-06 at 17:14 -0700, Richard Smith wrote:
> On Fri, Sep 6, 2013 at 4:48 PM, Vlad from Moscow <vlad.moscow@mail.ru>
> wrote:
>         I doi not agree that we need a new version of stack. All what
>         we need we already have. Moreover stack does not require
>         member function size(). It is unnecessary function. What is
>         size()? Inf act is is an analogy of an iterator. Consider
>         using size with an array something as
>
>         for ( int i = 0; i < n; i++ ) a[i] = i;
>
>         a + 0 and a + n give us iterators. However stack has no
>         iterators so it does not need the size() function. The logic
>         of functionality of the stack is simple. We are popping out
>         elements of the stack while it is not empty.
>
>         What we need is simply a specialization of std::stack for
>         std::forward_list. std::forward_list has all functionality of
>         the stack.
>
>
> We risk introducing surprising behavior if we add support for this.
> Right now, std::stack::push adds elements to the *end* of the stack,
> and this is an observable property in various ways (for instance, due
> to the container member being protected rather than private).

So, is a backward_list what is needed for Vlad's use case?

Please note that it would be a strange beast indeed as it won't support
insert(iterator, value), erase(iterator), begin() or end() (but rbegin()
and rend()). The forward_list proposal touches on this subject - mainly
by noting that it becomes an even odder container than forward_list.

/MF

--

---
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_220_1554714.1378530929825
Content-Type: text/plain; charset=ISO-8859-1



On Saturday, September 7, 2013 1:37:38 AM UTC+8, Vlad from Moscow wrote:
>
> I would like to propose to include specialization of std::stack for
> std::forward_list.
>
> In fact std::forward_list has already all characteristics of a stack.
> There will be only one difference compared with the primary class
> std::stack:  the specialization will not contain member function size()
> because std::forward_list has no such member.
>

The difference between list and forward_list is the overhead of the cached
size and back-links. This makes a difference in performance-constrained
computation.

The difference between a container and an adaptor is careful limitation of
the exposed interface and available information. This makes a difference in
library interfaces.

Library interfaces designed to limit access to information are seldom part
of a solution shaving off every possible byte and cycle. Ideally everything
is written at high level, but is there really a use case or all the
arguments theoretical?

For what it's worth, most of my singly-linked lists are implemented as
circular. forward_list is nice, but it's not one-size-fits-all in the usage
space it addresses, mainly because the Container concept is overconstrained
for utmost performance in many situations.

--

---
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_220_1554714.1378530929825
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, September 7, 2013 1:37:38 AM UTC+8, V=
lad from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>I would like to propose to include specialization of std::sta=
ck for std::forward_list. </div><div>&nbsp;</div><div>In fact std::forward_=
list has already all characteristics of a stack. There will be only one dif=
ference compared with the primary class std::stack:&nbsp; the specializatio=
n will not contain member function size() because std::forward_list has no =
such member.</div></div></blockquote><div><br>The difference between list a=
nd forward_list is the overhead of the cached size and back-links. This mak=
es a difference in performance-constrained computation.<br><br>The differen=
ce between a container and an adaptor is careful limitation of the exposed =
interface and available information. This makes a difference in library int=
erfaces.<br><br>Library interfaces designed to limit access to information =
are seldom part of a solution shaving off every possible byte and cycle. Id=
eally everything is written at high level, but is there really a use case o=
r all the arguments theoretical?<br><br>For what it's worth, most of my sin=
gly-linked lists are implemented as circular. <span style=3D"font-family: c=
ourier new,monospace;">forward_list</span> is nice, but it's not one-size-f=
its-all in the usage space it addresses, mainly because the Container conce=
pt is overconstrained for utmost performance in many situations.</div></div=
>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_220_1554714.1378530929825--

.

------=_Part_440_8719776.1378546257695
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

What you demonstarted is not a stack. You dealt with a container. So there=
=20
is nothing suprising that the elements are outputed in the reverse order.=
=20
It was your decision to use std::forward_list as a container.  It is the=20
same as you would use std::list and then decided to change it to=20
std::vector and now you wonder that std::vector has no member function=20
push_front.
=20
Your example demonstrates that the specialization of std::stack for=20
std::forward_list is very useful! Because it allows to output elements of a=
=20
stack in the natural order in which they are  stored in it that is in the=
=20
order FILO. =20
=20
Your example woukd be more appropriate for container adapter std::queue.:)
=20

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 4:14:38 UTC+4 =
=D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Richard Smith=20
=CE=C1=D0=C9=D3=C1=CC:

> On Fri, Sep 6, 2013 at 4:48 PM, Vlad from Moscow <vlad....@mail.ru<javasc=
ript:>
> > wrote:
>
>> I doi not agree that we need a new version of stack. All what we need we=
=20
>> already have. Moreover stack does not require member function size(). It=
 is=20
>> unnecessary function. What is size()? Inf act is is an analogy of an=20
>> iterator. Consider using size with an array something as
>> =20
>> for ( int i =3D 0; i < n; i++ ) a[i] =3D i;
>> =20
>> a + 0 and a + n give us iterators. However stack has no iterators so it=
=20
>> does not need the size() function. The logic of functionality of the sta=
ck=20
>> is simple. We are popping out elements of the stack while it is not empt=
y.
>> =20
>> What we need is simply a specialization of std::stack for=20
>> std::forward_list. std::forward_list has all functionality of the stack.
>>
>
> We risk introducing surprising behavior if we add support for this. Right=
=20
> now, std::stack::push adds elements to the *end* of the stack, and this i=
s=20
> an observable property in various ways (for instance, due to the containe=
r=20
> member being protected rather than private). Consider:
>
> template<template<typename...> struct Container>
> struct MyStack : public std::stack<int, Container<int>> {
>   using stack::stack;
>   void print() {
>     for (int n : this->c)
>       std::cout << n << std::endl;
>   }
> };
>
> If we taught std::stack to switch to using push_front instead of push_bac=
k=20
> when its container is a std::forward_list,=20
> MyStack<std::forward_list>::print would print in the opposite order from=
=20
> MyStack<any_other_container>::print.
>
> This seems a bit too reminiscent of std::vector<bool> for comfort.
>
> =D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 3:14:13 UTC+=
4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8=20
>> inkwizyt...@gmail.com =CE=C1=D0=C9=D3=C1=CC:
>>
>>>
>>>
>>> On Friday, September 6, 2013 7:37:38 PM UTC+2, Vlad from Moscow wrote:
>>>>
>>>> I would like to propose to include specialization of std::stack for=20
>>>> std::forward_list.=20
>>>> =20
>>>> In fact std::forward_list has already all characteristics of a stack.=
=20
>>>> There will be only one difference compared with the primary class=20
>>>> std::stack:  the specialization will not contain member function size(=
)=20
>>>> because std::forward_list has no such member.
>>>> =20
>>>> What will you say?
>>>>
>>> =20
>>> why no `size()`? nobody can access inner list ergo stack can easy=20
>>> determine size in const time. `std::stack` require only:
>>>
>>> back
>>> push_back
>>> pop_back
>>>
>>> that can be in case `std::forward_list` inverted to:
>>>
>>> front
>>> push_front
>>> pop_front
>>>
>>> maybe we need simple new version of stack? `std::stack_front`?
>>>
>>>
>>>
>>>  --=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 <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> 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_440_8719776.1378546257695
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>What you demonstarted is not a stack. You dealt with =
a container. So there is nothing suprising that the elements are outputed i=
n the reverse order. It was your decision to use std::forward_list as a con=
tainer.&nbsp; It is the same as you would use std::list and then decided to=
 change it to std::vector and now you wonder that std::vector has no member=
 function push_front.</div><div>&nbsp;</div><div>Your example demonstrates =
that the specialization of std::stack for std::forward_list is very useful!=
 Because it allows to output&nbsp;elements of&nbsp;a stack&nbsp;in the natu=
ral order in which they are&nbsp; stored&nbsp;in it&nbsp;that is in the ord=
er FILO.&nbsp;&nbsp;</div><div>&nbsp;</div><div>Your example woukd be more =
appropriate for container adapter std::queue.:)</div><div>&nbsp;</div><div>=
<br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=C7., 4:14:=
38 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Richard Smith =CE=C1=D0=C9=D3=
=C1=CC:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Fri, Sep 6, 2=
013 at 4:48 PM, Vlad from Moscow <span dir=3D"ltr">&lt;<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"ZSHfydGWGdsJ">vlad....@mail.=
ru</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div dir=3D"ltr"><div>I doi not agree that we =
need a new version of stack. All what we need we already have. Moreover sta=
ck does not require member function size(). It is unnecessary function. Wha=
t is size()? Inf act is is an analogy of an iterator. Consider using size w=
ith an array something as</div>
<div>&nbsp;</div><div>for ( int i =3D 0; i &lt; n; i++ ) a[i] =3D i;</div><=
div>&nbsp;</div><div>a + 0 and a + n give us iterators. However stack has n=
o iterators so it does not need the size() function. The logic of functiona=
lity of the stack is simple. We are popping out elements of the stack while=
 it is not empty.</div>
<div>&nbsp;</div><div>What we need is simply a specialization of std::stack=
 for std::forward_list. std::forward_list has all functionality of the stac=
k.</div></div></blockquote><div><br></div><div>We risk introducing surprisi=
ng behavior if we add support for this. Right now, std::stack::push adds el=
ements to the *end* of the stack, and this is an observable property in var=
ious ways (for instance, due to the container member being protected rather=
 than private). Consider:</div>
<div><br></div><div>template&lt;template&lt;typename...&gt; struct Containe=
r&gt;</div><div>struct MyStack : public std::stack&lt;int, Container&lt;int=
&gt;&gt; {</div><div>&nbsp; using stack::stack;</div><div>&nbsp; void print=
() {</div>
<div>&nbsp; &nbsp; for (int n : this-&gt;c)</div><div>&nbsp; &nbsp; &nbsp; =
std::cout &lt;&lt; n &lt;&lt; std::endl;</div><div>&nbsp; }</div><div>};<br=
></div><div><br></div><div>If we taught std::stack to switch to using push_=
front instead of push_back when its container is a std::forward_list, MySta=
ck&lt;std::forward_list&gt;::<wbr>print would print in the opposite order f=
rom MyStack&lt;any_other_container&gt;::<wbr>print.</div>
<div><br></div><div>This seems a bit too reminiscent of std::vector&lt;bool=
&gt; for comfort.</div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(=
204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr">
<div>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=C7., 3:14=
:13 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 <a>inkwizyt...@gmail.com</a>=
 =CE=C1=D0=C9=D3=C1=CC:</div><div><div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb=
(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div dir=3D"ltr"><br><br>On Friday, September 6, 2013 7:37:38 PM UTC+2, Vla=
d from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;">
<div dir=3D"ltr"><div>I would like to propose to include specialization of =
std::stack for std::forward_list. </div><div>&nbsp;</div><div>In fact std::=
forward_list has already all characteristics of a stack. There will be only=
 one difference compared with the primary class std::stack:&nbsp; the speci=
alization will not contain member function size() because std::forward_list=
 has no such member.</div>
<div>&nbsp;</div><div>What will you say?</div></div></blockquote><div>&nbsp=
;</div><div><font><span style=3D"font-family: arial,sans-serif;">why no `si=
ze()`? nobody can access inner list ergo stack can easy determine size in c=
onst time. `std::stack` require only:<br>
<br>back<br>push_back<br>pop_back<br><br>that can be in case `std::forward_=
list` inverted to:<br><br>front<br>push_front<br>pop_front<br><br>maybe we =
need simple new version of stack? `std::stack_front`?<br><br></span></font>=
<p>
<font><span style=3D"font-family: arial,sans-serif;"><br></span></font></p>=
<p><br></p></div></div></blockquote></div></div></div><div><div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
ZSHfydGWGdsJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"ZSHfydGWGdsJ">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_440_8719776.1378546257695--

.

------=_Part_420_20486434.1378547675715
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

The stack has neither member function erase nor iterators.
=20

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 8:42:02 UTC+4 =
=D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Magnus Fromreide=20
=CE=C1=D0=C9=D3=C1=CC:

> On Fri, 2013-09-06 at 17:14 -0700, Richard Smith wrote:=20
> > On Fri, Sep 6, 2013 at 4:48 PM, Vlad from Moscow <vlad....@mail.ru<java=
script:>>=20
>
> > wrote:=20
> >         I doi not agree that we need a new version of stack. All what=
=20
> >         we need we already have. Moreover stack does not require=20
> >         member function size(). It is unnecessary function. What is=20
> >         size()? Inf act is is an analogy of an iterator. Consider=20
> >         using size with an array something as=20
> >          =20
> >         for ( int i =3D 0; i < n; i++ ) a[i] =3D i;=20
> >          =20
> >         a + 0 and a + n give us iterators. However stack has no=20
> >         iterators so it does not need the size() function. The logic=20
> >         of functionality of the stack is simple. We are popping out=20
> >         elements of the stack while it is not empty.=20
> >          =20
> >         What we need is simply a specialization of std::stack for=20
> >         std::forward_list. std::forward_list has all functionality of=
=20
> >         the stack.=20
> >=20
> >=20
> > We risk introducing surprising behavior if we add support for this.=20
> > Right now, std::stack::push adds elements to the *end* of the stack,=20
> > and this is an observable property in various ways (for instance, due=
=20
> > to the container member being protected rather than private).=20
>
> So, is a backward_list what is needed for Vlad's use case?=20
>
> Please note that it would be a strange beast indeed as it won't support=
=20
> insert(iterator, value), erase(iterator), begin() or end() (but rbegin()=
=20
> and rend()). The forward_list proposal touches on this subject - mainly=
=20
> by noting that it becomes an even odder container than forward_list.=20
>
> /MF=20
>
>

--=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_420_20486434.1378547675715
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>The stack has neither member function erase nor itera=
tors.</div><div>&nbsp;</div><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=
=D1=C2=D2=D1 2013&nbsp;=C7., 8:42:02 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=
=CC=D8 Magnus Fromreide =CE=C1=D0=C9=D3=C1=CC:</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-le=
ft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: so=
lid;">On Fri, 2013-09-06 at 17:14 -0700, Richard Smith wrote:
<br>&gt; On Fri, Sep 6, 2013 at 4:48 PM, Vlad from Moscow &lt;<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"nQunI_rtVDkJ">vlad...=
..@mail.ru</a>&gt;
<br>&gt; wrote:
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; I doi not agree that we need a new ver=
sion of stack. All what
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; we need we already have. Moreover stac=
k does not require
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; member function size(). It is unnecess=
ary function. What is
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; size()? Inf act is is an analogy of an=
 iterator. Consider
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; using size with an array something as
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; for ( int i =3D 0; i &lt; n; i++ ) a[i=
] =3D i;
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; a + 0 and a + n give us iterators. How=
ever stack has no
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; iterators so it does not need the size=
() function. The logic
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; of functionality of the stack is simpl=
e. We are popping out
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; elements of the stack while it is not =
empty.
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; What we need is simply a specializatio=
n of std::stack for
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; std::forward_list. std::forward_list h=
as all functionality of
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; the stack.
<br>&gt;=20
<br>&gt;=20
<br>&gt; We risk introducing surprising behavior if we add support for this=
..
<br>&gt; Right now, std::stack::push adds elements to the *end* of the stac=
k,
<br>&gt; and this is an observable property in various ways (for instance, =
due
<br>&gt; to the container member being protected rather than private).=20
<br>
<br>So, is a backward_list what is needed for Vlad's use case?
<br>
<br>Please note that it would be a strange beast indeed as it won't support
<br>insert(iterator, value), erase(iterator), begin() or end() (but rbegin(=
)
<br>and rend()). The forward_list proposal touches on this subject - mainly
<br>by noting that it becomes an even odder container than forward_list.
<br>
<br>/MF
<br>
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_420_20486434.1378547675715--

.

--001a11c2b36a8306b404e5c8acdb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2013/9/7 Tony V E <tvaneerd@gmail.com>

>
> On Fri, Sep 6, 2013 at 5:01 PM, Daniel Kr=FCgler <daniel.kruegler@gmail.c=
om>wrote:
>
>> >
>> > Bit of a tangent here - I'm surprised forward_list doesn't have a
>> size(),
>> > since, as you say, it wouldn't be hard to implement.
>>
>> See
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.htm
>>
>> for the design rationale, especially regarding the omission of size().
>>
>>
> Thanks for the link.  Note that it says:
>
> "Note that similar considerations apply to std::list::size()."
>
> Which, (IIUC) at the time, didn't require O(1) size(), but now does.
> Wonder if forward_list is worth revisiting.
>

For std::list there was decision to make in regard to trade-of between
size() and splice(), see

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2923.pdf

But list was a container that should *fully* satisfy the container
requirements, therefore the size() member existed from the C++98. Here we
had not choice to remove size() from list.

For forward_list the design idea was intentionally not to satisfy the
container requirements, but instead to provide a type that does not take
more space or time overhead relative to a hand-written C-style singly
linked list, see the note added to [forwardlist.overview] p1, especially
"Features that would conflict with that goal have been omitted." and the
text in above quoted paper. It is certainly possible to add a size() member
with O(1) guarantee but that would conflict with the design idea. Of-course
reconsidering previous ideas is always possible, but would probably require
a paper that provides some convincing arguments for such a change.

- Daniel

--=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/.

--001a11c2b36a8306b404e5c8acdb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
2013/9/7 Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.co=
m" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im"><br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">On Fri, Sep 6, 2013 at 5:01 PM, Daniel Kr=FCgler <span di=
r=3D"ltr">&lt;<a href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank=
">daniel.kruegler@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">&gt;<br><div>
&gt; Bit of a tangent here - I&#39;m surprised forward_list doesn&#39;t hav=
e a size(),<br>
&gt; since, as you say, it wouldn&#39;t be hard to implement.<br>
<br>
</div>See<br>
<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.ht=
m" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/200=
8/n2543.htm</a><br>
<br>
for the design rationale, especially regarding the omission of size().<br>
<br></blockquote></div><br></div></div><div class=3D"gmail_extra">Thanks fo=
r the link.=A0 Note that it says:<br><br>&quot;Note that similar considerat=
ions apply to
<span style=3D"font-family:Courier New">std::list::size()</span>.&quot;<br>=
<br></div><div class=3D"gmail_extra">Which, (IIUC) at the time, didn&#39;t =
require O(1) size(), but now does.=A0 Wonder if forward_list is worth revis=
iting.<br>
</div></div></blockquote><div><br></div></div>For std::list there was decis=
ion to make in regard to trade-of between size() and splice(), see<br><br><=
a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2923.pdf=
">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2923.pdf</a><br>
<br></div><div class=3D"gmail_extra">But list was a container that should *=
fully* satisfy the container requirements, therefore the size() member exis=
ted from the C++98. Here we had not choice to remove size() from list.<br>
<br>For forward_list the design idea was intentionally not to satisfy the c=
ontainer requirements, but instead to provide a type that does not take mor=
e space or time overhead relative to a hand-written C-style singly linked l=
ist, see the note added to [forwardlist.overview] p1, especially &quot;Feat=
ures that would conflict with that goal have been omitted.&quot; and the te=
xt in above quoted paper. It is certainly possible to add a size() member w=
ith O(1) guarantee but that would conflict with the design idea. Of-course =
reconsidering previous ideas is always possible, but would probably require=
 a paper that provides some convincing arguments for such a change.<br>
<br></div><div class=3D"gmail_extra">- Daniel<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2b36a8306b404e5c8acdb--

.

------=_Part_402_27930900.1378551721078
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think that  there is some mess in the C++ Standard. It is the std:;stack=
=20
that should not have member function size() because this function belongs=
=20
to entities that make ranges. The notion of the range is not applicable to=
=20
the stack.
=20
So it would be more logically consistent if std::forward_list would have=20
member function size() because it has forward iterators and could deal with=
=20
such algorithms as fill_n, copy_n and others ..._n while std::stack could=
=20
drop this member function.
=20

=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=81=D0=B5=D0=BD=D1=82=D1=
=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3., 14:32:37 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Daniel Kr=C3=BCgler=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

>
> 2013/9/7 Tony V E <tvan...@gmail.com <javascript:>>
>
>>
>> On Fri, Sep 6, 2013 at 5:01 PM, Daniel Kr=C3=BCgler <daniel....@gmail.co=
m<javascript:>
>> > wrote:
>>
>>> >
>>> > Bit of a tangent here - I'm surprised forward_list doesn't have a=20
>>> size(),
>>> > since, as you say, it wouldn't be hard to implement.
>>>
>>> See
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.htm
>>>
>>> for the design rationale, especially regarding the omission of size().
>>>
>>>
>> Thanks for the link.  Note that it says:
>>
>> "Note that similar considerations apply to std::list::size()."
>>
>> Which, (IIUC) at the time, didn't require O(1) size(), but now does. =20
>> Wonder if forward_list is worth revisiting.
>>
>
> For std::list there was decision to make in regard to trade-of between=20
> size() and splice(), see
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2923.pdf
>
> But list was a container that should *fully* satisfy the container=20
> requirements, therefore the size() member existed from the C++98. Here we=
=20
> had not choice to remove size() from list.
>
> For forward_list the design idea was intentionally not to satisfy the=20
> container requirements, but instead to provide a type that does not take=
=20
> more space or time overhead relative to a hand-written C-style singly=20
> linked list, see the note added to [forwardlist.overview] p1, especially=
=20
> "Features that would conflict with that goal have been omitted." and the=
=20
> text in above quoted paper. It is certainly possible to add a size() memb=
er=20
> with O(1) guarantee but that would conflict with the design idea. Of-cour=
se=20
> reconsidering previous ideas is always possible, but would probably requi=
re=20
> a paper that provides some convincing arguments for such a change.
>
> - Daniel
>

--=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_402_27930900.1378551721078
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I think that&nbsp; there is some mess in the C++ Stan=
dard. It is the std:;stack that should not have member function size() beca=
use this function belongs to entities that make ranges. The notion of the r=
ange is not applicable to the stack.</div><div>&nbsp;</div><div>So it would=
 be more logically consistent&nbsp;if std::forward_list would have member f=
unction size() because it has&nbsp;forward iterators and could deal with su=
ch algorithms as fill_n, copy_n and others&nbsp;..._n while std::stack coul=
d drop this member function.</div><div>&nbsp;</div><div><br>=D1=81=D1=83=D0=
=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=
=D1=8F 2013&nbsp;=D0=B3., 14:32:37 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=
=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Daniel Kr=C3=BCgler =D0=BD=D0=B0=D0=
=BF=D0=B8=D1=81=D0=B0=D0=BB:</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><br><div><div class=3D"gmail_quote">2013/9/7 Tony V E <span dir=3D=
"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"3JMifzER5f8J">tvan...@gmail.com</a>&gt;</span><br><blockquote class=3D"=
gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-=
left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: =
solid;">
<div dir=3D"ltr"><div><br><div><div class=3D"gmail_quote">On Fri, Sep 6, 20=
13 at 5:01 PM, Daniel Kr=C3=BCgler <span dir=3D"ltr">&lt;<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"3JMifzER5f8J">daniel....@g=
mail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;">&gt;<br><div>
&gt; Bit of a tangent here - I'm surprised forward_list doesn't have a size=
(),<br>
&gt; since, as you say, it wouldn't be hard to implement.<br>
<br>
</div>See<br>
<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.ht=
m" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/paper=
s/2008/<wbr>n2543.htm</a><br>
<br>
for the design rationale, especially regarding the omission of size().<br>
<br></blockquote></div><br></div></div><div>Thanks for the link.&nbsp; Note=
 that it says:<br><br>"Note that similar considerations apply to
<span style=3D"font-family: Courier New;">std::list::size()</span>."<br><br=
></div><div>Which, (IIUC) at the time, didn't require O(1) size(), but now =
does.&nbsp; Wonder if forward_list is worth revisiting.<br>
</div></div></blockquote><div><br></div></div>For std::list there was decis=
ion to make in regard to trade-of between size() and splice(), see<br><br><=
a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2923.pdf=
" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers=
/2009/<wbr>n2923.pdf</a><br>
<br></div><div>But list was a container that should *fully* satisfy the con=
tainer requirements, therefore the size() member existed from the C++98. He=
re we had not choice to remove size() from list.<br>
<br>For forward_list the design idea was intentionally not to satisfy the c=
ontainer requirements, but instead to provide a type that does not take mor=
e space or time overhead relative to a hand-written C-style singly linked l=
ist, see the note added to [forwardlist.overview] p1, especially "Features =
that would conflict with that goal have been omitted." and the text in abov=
e quoted paper. It is certainly possible to add a size() member with O(1) g=
uarantee but that would conflict with the design idea. Of-course reconsider=
ing previous ideas is always possible, but would probably require a paper t=
hat provides some convincing arguments for such a change.<br>
<br></div><div>- Daniel<br></div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_402_27930900.1378551721078--

.

--001a11c34302684e5904e5c91760
Content-Type: text/plain; charset=ISO-8859-1

2013/9/7 Vlad from Moscow <vlad.moscow@mail.ru>

> What you demonstarted is not a stack. You dealt with a container. So there
> is nothing suprising that the elements are outputed in the reverse order.
> It was your decision to use std::forward_list as a container.
>

It is not clear whose decision it will be, because the std::stack might be
used as an implementation detail of another template, so it the effects are
very unexpected and not aware of the implementer of the "outer2 template.

Keep also in mind that the protected member 'c' is part of the API, so
someone who derives from stack can expect that the member functions of c
required in the std::stack specification do exist. In case of your
hypothetical specialization of std::stack the derived template would break
when trying to refer to push_back(), back(), etc.

I also think that your assertion that stack "is a some sort of an abstract
class" is misleading. This type as an *adaptor* type, so like other
adaptors its specification relies on a well-defined set of operations from
the adapteed type. The standard library support  user-defined
specializations of library templates ([namespace.std]), if specialization
meets the standard library requirements for the original template. This is
not satisfied for std::forward_list, because the difference is observable,
*because* the member c is part of its API.



> It is the same as you would use std::list and then decided to change it to
> std::vector and now you wonder that std::vector has no member function
> push_front.
>

No, this example does not match here for std::stack, because std::stack
does not depend on any operation named push_front().


>  Your example demonstrates that the specialization of std::stack for
> std::forward_list is very useful! Because it allows to output elements of a
> stack in the natural order in which they are  stored in it that is in the
> order FILO.
>

Again I repeat that this can already be realized by providing an adaptor of
forward_list, that provides the required operations needed for std::stack.
There is no reason to assume that such an adaptor would cause any time
overhead. There would be a small space overhead to provide the size()
member, but obviously this idea was accepted when using std::stack based on
forward_list. I also consider this kind of adaptor as an interesting one
that is similar to reverse_iterator for iterators. I'm not sure that
reverse_container is the right name for it, but here the rough idea of such
a template:

template <class T, class Container = deque<T> >
class reverse_container {
public:
  typedef typename Container::value_type value_type;
  typedef typename Container::reference reference;
  typedef typename Container::const_reference const_reference;
  typedef typename Container::size_type size_type;
  typedef Container container_type;
  [..] // constructors
  bool empty() const { return c.empty(); }
  size_type size() const { return c.size(); }
  reference back() { return c.front(); }
  const_reference back() const { return c.front(); }

  void push_back(const value_type& x) { c.push_front(x); }
  void push_back(value_type&& x) { c.push_front(std::move(x)); }
  template <class... Args> void emplace_back(Args&&... args)
  { c.emplace_front(std::forward<Args>(args)...); }
  void pop_back() { c.pop_font(); }
  void swap(stack& s) noexcept(noexcept(swap(c, s.c)))
  { using std::swap; swap(c, s.c); }
private:
  Container c; // For exposition only
};

I'm leaving the decision open here, there are several ways to handle that.

- Daniel

--

---
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/.

--001a11c34302684e5904e5c91760
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">2013/9/7 Vlad from Moscow <span dir=3D"ltr">&lt;<a href=3D=
"mailto:vlad.moscow@mail.ru" target=3D"_blank">vlad.moscow@mail.ru</a>&gt;<=
/span><br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div>What you demonstarted is not a stack. You dealt with =
a container. So there is nothing suprising that the elements are outputed i=
n the reverse order. It was your decision to use std::forward_list as a con=
tainer.=A0</div>
</div></blockquote><div><br></div><div>It is not clear whose decision it wi=
ll be, because the std::stack might be used as an implementation detail of =
another template, so it the effects are very unexpected and not aware of th=
e implementer of the &quot;outer2 template. <br>
<br>Keep also in mind that the protected member &#39;c&#39; is part of the =
API, so someone who derives from stack can expect that the member functions=
 of c required in the std::stack specification do exist. In case of your hy=
pothetical specialization of std::stack the derived template would break wh=
en trying to refer to push_back(), back(), etc.<br>
<br></div><div>I also think that your assertion that stack &quot;is a some =
sort of an abstract class&quot; is misleading. This type as an *adaptor* ty=
pe, so like other adaptors its specification relies on a well-defined set o=
f operations from the adapteed type. The standard library support=A0 user-d=
efined specializations of library templates ([namespace.std]), if specializ=
ation meets the standard library requirements for the original template. Th=
is is not satisfied for std::forward_list, because the difference is observ=
able, *because* the member c is part of its API.<br>
</div><div><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div> It is the same as you would use std::list and then de=
cided to change it to std::vector and now you wonder that std::vector has n=
o member function push_front.</div>
</div></blockquote><div><br></div><div>No, this example does not match here=
 for std::stack, because std::stack does not depend on any operation named =
push_front().<br></div><div>=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">
<div dir=3D"ltr"><div>=A0Your example demonstrates that the specialization =
of std::stack for std::forward_list is very useful! Because it allows to ou=
tput=A0elements of=A0a stack=A0in the natural order in which they are=A0 st=
ored=A0in it=A0that is in the order FILO.=A0=A0</div>
</div></blockquote><div><br></div><div>Again I repeat that this can already=
 be realized by providing an adaptor of forward_list, that provides the req=
uired operations needed for std::stack. There is no reason to assume that s=
uch an adaptor would cause any time overhead. There would be a small space =
overhead to provide the size() member, but obviously this idea was accepted=
 when using std::stack based on forward_list. I also consider this kind of =
adaptor as an interesting one that is similar to reverse_iterator for itera=
tors. I&#39;m not sure that reverse_container is the right name for it, but=
 here the rough idea of such a template:<br>
<br>template &lt;class T, class Container =3D deque&lt;T&gt; &gt;<br>class =
reverse_container {<br>public:<br>=A0 typedef typename Container::value_typ=
e value_type;<br>=A0 typedef typename Container::reference reference;<br>=
=A0 typedef typename Container::const_reference const_reference;<br>
=A0 typedef typename Container::size_type size_type;<br>=A0 typedef Contain=
er container_type; <br>=A0 [..] // constructors<br></div><div>=A0 bool empt=
y() const { return c.empty(); }<br>=A0 size_type size() const { return c.si=
ze(); }<br>
=A0 reference back() { return c.front(); }<br>=A0  const_reference back() c=
onst { return c.front(); }<br>=A0 <br>=A0 void push_back(const value_type&a=
mp; x) { c.push_front(x); }<br>=A0 void push_back(value_type&amp;&amp; x) {=
 c.push_front(std::move(x)); }<br>
=A0 template &lt;class... Args&gt; void emplace_back(Args&amp;&amp;... args=
)<br>=A0 { c.emplace_front(std::forward&lt;Args&gt;(args)...); }<br>=A0 voi=
d pop_back() { c.pop_font(); }<br>=A0 void swap(stack&amp; s) noexcept(noex=
cept(swap(c, s.c)))<br>
=A0 { using std::swap; swap(c, s.c); }<br></div><div>private:<br></div><div=
>=A0 Container c; // For exposition only<br></div><div>};<br><br></div><div=
>I&#39;m leaving the decision open here, there are several ways to handle t=
hat.<br>
</div><div><br></div></div>- Daniel<br><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c34302684e5904e5c91760--

.

------=_Part_566_8743719.1378556104126
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=20
By the way when std:;stack was adopted there was no such a container as=20
std:;forward_list. It is the only std::vector that among other sequantial=
=20
containers has no member function push_front.
=20
So all sequantial containers can be split into two groups.=20
=20
The one that contains std::vector, std::deque and std::list may use=20
push_back and back() methods that to simulate the stack.
=20
The other group contains std:;deque, std::list and std:;forward_list that=
=20
canuse methods push_front and front to simulate the stack.
=20
I think no one group should be discriminated.=20

=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=81=D0=B5=D0=BD=D1=82=D1=
=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3., 15:02:30 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Daniel Kr=C3=BCgler=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

> 2013/9/7 Vlad from Moscow <vlad....@mail.ru <javascript:>>
>
>> What you demonstarted is not a stack. You dealt with a container. So=20
>> there is nothing suprising that the elements are outputed in the reverse=
=20
>> order. It was your decision to use std::forward_list as a container.=20
>>
>
> It is not clear whose decision it will be, because the std::stack might b=
e=20
> used as an implementation detail of another template, so it the effects a=
re=20
> very unexpected and not aware of the implementer of the "outer2 template.=
=20
>
> Keep also in mind that the protected member 'c' is part of the API, so=20
> someone who derives from stack can expect that the member functions of c=
=20
> required in the std::stack specification do exist. In case of your=20
> hypothetical specialization of std::stack the derived template would brea=
k=20
> when trying to refer to push_back(), back(), etc.
>
> I also think that your assertion that stack "is a some sort of an abstrac=
t=20
> class" is misleading. This type as an *adaptor* type, so like other=20
> adaptors its specification relies on a well-defined set of operations fro=
m=20
> the adapteed type. The standard library support  user-defined=20
> specializations of library templates ([namespace.std]), if specialization=
=20
> meets the standard library requirements for the original template. This i=
s=20
> not satisfied for std::forward_list, because the difference is observable=
,=20
> *because* the member c is part of its API.
>
> =20
>
>> It is the same as you would use std::list and then decided to change it=
=20
>> to std::vector and now you wonder that std::vector has no member functio=
n=20
>> push_front.
>>
>
> No, this example does not match here for std::stack, because std::stack=
=20
> does not depend on any operation named push_front().
> =20
>
>>  Your example demonstrates that the specialization of std::stack for=20
>> std::forward_list is very useful! Because it allows to output elements o=
f a=20
>> stack in the natural order in which they are  stored in it that is in th=
e=20
>> order FILO. =20
>>
>
> Again I repeat that this can already be realized by providing an adaptor=
=20
> of forward_list, that provides the required operations needed for=20
> std::stack. There is no reason to assume that such an adaptor would cause=
=20
> any time overhead. There would be a small space overhead to provide the=
=20
> size() member, but obviously this idea was accepted when using std::stack=
=20
> based on forward_list. I also consider this kind of adaptor as an=20
> interesting one that is similar to reverse_iterator for iterators. I'm no=
t=20
> sure that reverse_container is the right name for it, but here the rough=
=20
> idea of such a template:
>
> template <class T, class Container =3D deque<T> >
> class reverse_container {
> public:
>   typedef typename Container::value_type value_type;
>   typedef typename Container::reference reference;
>   typedef typename Container::const_reference const_reference;
>   typedef typename Container::size_type size_type;
>   typedef Container container_type;=20
>   [..] // constructors
>   bool empty() const { return c.empty(); }
>   size_type size() const { return c.size(); }
>   reference back() { return c.front(); }
>   const_reference back() const { return c.front(); }
>  =20
>   void push_back(const value_type& x) { c.push_front(x); }
>   void push_back(value_type&& x) { c.push_front(std::move(x)); }
>   template <class... Args> void emplace_back(Args&&... args)
>   { c.emplace_front(std::forward<Args>(args)...); }
>   void pop_back() { c.pop_font(); }
>   void swap(stack& s) noexcept(noexcept(swap(c, s.c)))
>   { using std::swap; swap(c, s.c); }
> private:
>   Container c; // For exposition only
> };
>
> I'm leaving the decision open here, there are several ways to handle that=
..
>
> - Daniel
>
>

--=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_566_8743719.1378556104126
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&nbsp;</div><div>By the way when std:;stack was adopt=
ed there was no such a container as std:;forward_list. It is the only std::=
vector that among other sequantial containers has no member function push_f=
ront.</div><div>&nbsp;</div><div>So all sequantial containers can be split =
into two groups. </div><div>&nbsp;</div><div>The one that contains std::vec=
tor, std::deque and std::list may use push_back and&nbsp;back() methods tha=
t to&nbsp;simulate the stack.</div><div>&nbsp;</div><div>The other group co=
ntains std:;deque, std::list and std:;forward_list&nbsp;that canuse methods=
 push_front and front to simulate the&nbsp;stack.</div><div>&nbsp;</div><di=
v>I think&nbsp;no one group should be discriminated.&nbsp;</div><div><br>=
=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=81=D0=B5=D0=BD=D1=82=D1=
=8F=D0=B1=D1=80=D1=8F 2013&nbsp;=D0=B3., 15:02:30 UTC+4 =D0=BF=D0=BE=D0=BB=
=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Daniel Kr=C3=BCgler =
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-=
color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid=
;"><div dir=3D"ltr">2013/9/7 Vlad from Moscow <span dir=3D"ltr">&lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Ox_v0KUAwVgJ">v=
lad....@mail.ru</a>&gt;</span><br><div><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: =
1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-=
left-style: solid;">
<div dir=3D"ltr"><div>What you demonstarted is not a stack. You dealt with =
a container. So there is nothing suprising that the elements are outputed i=
n the reverse order. It was your decision to use std::forward_list as a con=
tainer.&nbsp;</div>
</div></blockquote><div><br></div><div>It is not clear whose decision it wi=
ll be, because the std::stack might be used as an implementation detail of =
another template, so it the effects are very unexpected and not aware of th=
e implementer of the "outer2 template. <br>
<br>Keep also in mind that the protected member 'c' is part of the API, so =
someone who derives from stack can expect that the member functions of c re=
quired in the std::stack specification do exist. In case of your hypothetic=
al specialization of std::stack the derived template would break when tryin=
g to refer to push_back(), back(), etc.<br>
<br></div><div>I also think that your assertion that stack "is a some sort =
of an abstract class" is misleading. This type as an *adaptor* type, so lik=
e other adaptors its specification relies on a well-defined set of operatio=
ns from the adapteed type. The standard library support&nbsp; user-defined =
specializations of library templates ([namespace.std]), if specialization m=
eets the standard library requirements for the original template. This is n=
ot satisfied for std::forward_list, because the difference is observable, *=
because* the member c is part of its API.<br>
</div><div><br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 2=
04); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><d=
iv> It is the same as you would use std::list and then decided to change it=
 to std::vector and now you wonder that std::vector has no member function =
push_front.</div>
</div></blockquote><div><br></div><div>No, this example does not match here=
 for std::stack, because std::stack does not depend on any operation named =
push_front().<br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div dir=3D"ltr"><div>&nbsp;Your example demonstrates that the specializati=
on of std::stack for std::forward_list is very useful! Because it allows to=
 output&nbsp;elements of&nbsp;a stack&nbsp;in the natural order in which th=
ey are&nbsp; stored&nbsp;in it&nbsp;that is in the order FILO.&nbsp;&nbsp;<=
/div>
</div></blockquote><div><br></div><div>Again I repeat that this can already=
 be realized by providing an adaptor of forward_list, that provides the req=
uired operations needed for std::stack. There is no reason to assume that s=
uch an adaptor would cause any time overhead. There would be a small space =
overhead to provide the size() member, but obviously this idea was accepted=
 when using std::stack based on forward_list. I also consider this kind of =
adaptor as an interesting one that is similar to reverse_iterator for itera=
tors. I'm not sure that reverse_container is the right name for it, but her=
e the rough idea of such a template:<br>
<br>template &lt;class T, class Container =3D deque&lt;T&gt; &gt;<br>class =
reverse_container {<br>public:<br>&nbsp; typedef typename Container::value_=
type value_type;<br>&nbsp; typedef typename Container::reference reference;=
<br>&nbsp; typedef typename Container::const_reference const_reference;<br>
&nbsp; typedef typename Container::size_type size_type;<br>&nbsp; typedef C=
ontainer container_type; <br>&nbsp; [..] // constructors<br></div><div>&nbs=
p; bool empty() const { return c.empty(); }<br>&nbsp; size_type size() cons=
t { return c.size(); }<br>
&nbsp; reference back() { return c.front(); }<br>&nbsp;  const_reference ba=
ck() const { return c.front(); }<br>&nbsp; <br>&nbsp; void push_back(const =
value_type&amp; x) { c.push_front(x); }<br>&nbsp; void push_back(value_type=
&amp;&amp; x) { c.push_front(std::move(x)); }<br>
&nbsp; template &lt;class... Args&gt; void emplace_back(Args&amp;&amp;... a=
rgs)<br>&nbsp; { c.emplace_front(std::forward&lt;<wbr>Args&gt;(args)...); }=
<br>&nbsp; void pop_back() { c.pop_font(); }<br>&nbsp; void swap(stack&amp;=
 s) noexcept(noexcept(swap(c, s.c)))<br>
&nbsp; { using std::swap; swap(c, s.c); }<br></div><div>private:<br></div><=
div>&nbsp; Container c; // For exposition only<br></div><div>};<br><br></di=
v><div>I'm leaving the decision open here, there are several ways to handle=
 that.<br>
</div><div><br></div></div>- Daniel<br><br></div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_566_8743719.1378556104126--

.

------=_Part_3_20811837.1378556839442
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Saturday, September 7, 2013 1:02:01 PM UTC+2, Vlad from Moscow wrote:
>
> I think that  there is some mess in the C++ Standard. It is the std:;stac=
k=20
> that should not have member function size() because this function belongs=
=20
> to entities that make ranges. The notion of the range is not applicable t=
o=20
> the stack.
> =20
> So it would be more logically consistent if std::forward_list would have=
=20
> member function size() because it has forward iterators and could deal wi=
th=20
> such algorithms as fill_n, copy_n and others ..._n while std::stack could=
=20
> drop this member function.
> =20
>
> =D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=81=D0=B5=D0=BD=D1=82=D1=
=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3., 14:32:37 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Daniel Kr=C3=BCgler=20
> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
>> For std::list there was decision to make in regard to trade-of between=
=20
>> size() and splice(), see
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2923.pdf
>>
>> But list was a container that should *fully* satisfy the container=20
>> requirements, therefore the size() member existed from the C++98. Here w=
e=20
>> had not choice to remove size() from list.
>>
>> For forward_list the design idea was intentionally not to satisfy the=20
>> container requirements, but instead to provide a type that does not take=
=20
>> more space or time overhead relative to a hand-written C-style singly=20
>> linked list, see the note added to [forwardlist.overview] p1, especially=
=20
>> "Features that would conflict with that goal have been omitted." and the=
=20
>> text in above quoted paper. It is certainly possible to add a size() mem=
ber=20
>> with O(1) guarantee but that would conflict with the design idea. Of-cou=
rse=20
>> reconsidering previous ideas is always possible, but would probably requ=
ire=20
>> a paper that provides some convincing arguments for such a change.
>>
>> - Daniel
>>
> =20
Right now is impossible to remove `size()` from stack because some user=20
code depands on that, exactly same case as infamous `std::vector<bool>`.

`std::forward_list` is bare bone implementation, I dont think is good idea=
=20
add anything to it. If you really need `size()` you could add warper around=
=20
`std::forward_list`:

template<typename T>
class forward_list_size
{
    struct size_dec
    {
        size_dec(forward_list_size& r) : ref{ r }=20
        {
            ++ref._size;
        }
        ~size_dec()
        {
            --ref._size;
        }
        forward_list_size& ref;
    };
   =20
    std::forward_list<std::tuple<size_dec, T>> c;
    size_t _size;

public:
    size_t size() const
    {
        return _size; //alternative we can use O(N) version there
    }
   =20
    //rest of interface that look like forward_list<T>
};

good part of this is you dont force anyone else to pay for your need for=20
`size()` even if then dont use/want it. This example class could be made=20
more generic and allow any container that normally dont support O(1) size=
=20
function.

--=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_3_20811837.1378556839442
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, September 7, 2013 1:02:01 PM UTC+2, V=
lad from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>I think that&nbsp; there is some mess in the C++ Standard. It=
 is the std:;stack that should not have member function size() because this=
 function belongs to entities that make ranges. The notion of the range is =
not applicable to the stack.</div><div>&nbsp;</div><div>So it would be more=
 logically consistent&nbsp;if std::forward_list would have member function =
size() because it has&nbsp;forward iterators and could deal with such algor=
ithms as fill_n, copy_n and others&nbsp;..._n while std::stack could drop t=
his member function.</div><div>&nbsp;</div><div><br>=D1=81=D1=83=D0=B1=D0=
=B1=D0=BE=D1=82=D0=B0, 7 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2=
013&nbsp;=D0=B3., 14:32:37 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=
=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Daniel Kr=C3=BCgler =D0=BD=D0=B0=D0=BF=D0=B8=
=D1=81=D0=B0=D0=BB:</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);borde=
r-left-width:1px;border-left-style:solid"><div dir=3D"ltr">For std::list th=
ere was decision to make in regard to trade-of between size() and splice(),=
 see<br><div><br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2009/n2923.pdf" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc2=
2/wg21/docs/papers/2009/<wbr>n2923.pdf</a><br>
<br></div><div>But list was a container that should *fully* satisfy the con=
tainer requirements, therefore the size() member existed from the C++98. He=
re we had not choice to remove size() from list.<br>
<br>For forward_list the design idea was intentionally not to satisfy the c=
ontainer requirements, but instead to provide a type that does not take mor=
e space or time overhead relative to a hand-written C-style singly linked l=
ist, see the note added to [forwardlist.overview] p1, especially "Features =
that would conflict with that goal have been omitted." and the text in abov=
e quoted paper. It is certainly possible to add a size() member with O(1) g=
uarantee but that would conflict with the design idea. Of-course reconsider=
ing previous ideas is always possible, but would probably require a paper t=
hat provides some convincing arguments for such a change.<br>
<br></div><div>- Daniel<br></div></div></blockquote></div></blockquote><div=
>&nbsp;<br>Right now is impossible to remove `size()` from stack because so=
me user code depands on that, exactly same case as infamous `std::vector&lt=
;bool&gt;`.<br><br>`std::forward_list` is bare bone implementation, I dont =
think is good idea add anything to it. If you really need `size()` you coul=
d add warper around `std::forward_list`:<br><div class=3D"prettyprint" styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; word-wrap: break-word;"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">clas=
s</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> forward_=
list_size<br></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
ize_dec<br>&nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>&nbsp; &nbsp; &nbsp; &nbsp; size_dec</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">forward_list_size</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> r</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">ref</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> r </span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> <br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">++</span><span style=3D"color: #008;" class=3D"styled-by-prettify">ref</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">_size</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbs=
p; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
~</span><span style=3D"color: #000;" class=3D"styled-by-prettify">size_dec<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &=
nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">--</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">ref</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">_size</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>&nbsp; &nbsp; &nbsp; &nbsp; forward_list_size</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">ref</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>&nbsp; &nbsp; <br>&nbsp; &nbsp; std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">forward_list</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">tuple</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">size_dec</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&gt;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; size_t _si=
ze</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">public</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; size_t size</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> _size</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">//alternative we can use O(N) version=
 there</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
&nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; &nbsp; <br>&nbsp; &nbsp; </span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">//rest of interface that look like forward_list&lt;T&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></cod=
e></div><br>good part of this is you dont force anyone else to pay for your=
 need for `size()` even if then dont use/want it. This example class could =
be made more generic and allow any container that normally dont support O(1=
) size function.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3_20811837.1378556839442--

.

--001a1135e1f6a35e4404e5ca6610
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

forward_list doesn't implement .size() because it would make .splice() less
efficient. However, when forward_list is only used as a stack, that's not
an issue. Interesting.

Maybe the stack adapter could keep track of the size by itself in the cases
when the underlying container does not provide a .size(). (It'd be trivial,
push does ++, pop does --).


2013/9/7 <inkwizytoryankes@gmail.com>

>
>
> On Saturday, September 7, 2013 1:02:01 PM UTC+2, Vlad from Moscow wrote:
>
>> I think that  there is some mess in the C++ Standard. It is the
>> std:;stack that should not have member function size() because this
>> function belongs to entities that make ranges. The notion of the range i=
s
>> not applicable to the stack.
>>
>> So it would be more logically consistent if std::forward_list would have
>> member function size() because it has forward iterators and could deal w=
ith
>> such algorithms as fill_n, copy_n and others ..._n while std::stack coul=
d
>> drop this member function.
>>
>>
>> =D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=81=D0=B5=D0=BD=D1=82=
=D1=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3., 14:32:37 UTC+4 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Daniel Kr=C3=BCgler
>> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>
>>> For std::list there was decision to make in regard to trade-of between
>>> size() and splice(), see
>>>
>>>
>>> http://www.open-std.org/jtc1/**sc22/wg21/docs/papers/2009/**n2923.pdf<h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2923.pdf>
>>>
>>> But list was a container that should *fully* satisfy the container
>>> requirements, therefore the size() member existed from the C++98. Here =
we
>>> had not choice to remove size() from list.
>>>
>>> For forward_list the design idea was intentionally not to satisfy the
>>> container requirements, but instead to provide a type that does not tak=
e
>>> more space or time overhead relative to a hand-written C-style singly
>>> linked list, see the note added to [forwardlist.overview] p1, especiall=
y
>>> "Features that would conflict with that goal have been omitted." and th=
e
>>> text in above quoted paper. It is certainly possible to add a size() me=
mber
>>> with O(1) guarantee but that would conflict with the design idea. Of-co=
urse
>>> reconsidering previous ideas is always possible, but would probably req=
uire
>>> a paper that provides some convincing arguments for such a change.
>>>
>>> - Daniel
>>>
>>
> Right now is impossible to remove `size()` from stack because some user
> code depands on that, exactly same case as infamous `std::vector<bool>`.
>
> `std::forward_list` is bare bone implementation, I dont think is good ide=
a
> add anything to it. If you really need `size()` you could add warper arou=
nd
> `std::forward_list`:
>
> template<typename T>
> class forward_list_size
> {
>     struct size_dec
>     {
>         size_dec(forward_list_size& r) : ref{ r }
>         {
>             ++ref._size;
>         }
>         ~size_dec()
>         {
>             --ref._size;
>         }
>         forward_list_size& ref;
>     };
>
>     std::forward_list<std::tuple<size_dec, T>> c;
>     size_t _size;
>
> public:
>     size_t size() const
>     {
>         return _size; //alternative we can use O(N) version there
>     }
>
>     //rest of interface that look like forward_list<T>
> };
>
> good part of this is you dont force anyone else to pay for your need for
> `size()` even if then dont use/want it. This example class could be made
> more generic and allow any container that normally dont support O(1) size
> function.
>
> --
>
> ---
> 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/.
>

--=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/.

--001a1135e1f6a35e4404e5ca6610
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">forward_list doesn&#39;t implement .size() because it woul=
d make .splice() less efficient. However, when forward_list is only used as=
 a stack, that&#39;s not an issue. Interesting.<br><br>Maybe the stack adap=
ter could keep track of the size by itself in the cases when the underlying=
 container does not provide a .size(). (It&#39;d be trivial, push does ++, =
pop does --).<br>

</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/9/=
7  <span dir=3D"ltr">&lt;<a href=3D"mailto:inkwizytoryankes@gmail.com" targ=
et=3D"_blank">inkwizytoryankes@gmail.com</a>&gt;</span><br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">

<div dir=3D"ltr"><div class=3D"im"><br><br>On Saturday, September 7, 2013 1=
:02:01 PM UTC+2, Vlad from Moscow wrote:</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">

<div dir=3D"ltr"><div class=3D"im"><div>I think that=C2=A0 there is some me=
ss in the C++ Standard. It is the std:;stack that should not have member fu=
nction size() because this function belongs to entities that make ranges. T=
he notion of the range is not applicable to the stack.</div>

<div>=C2=A0</div><div>So it would be more logically consistent=C2=A0if std:=
:forward_list would have member function size() because it has=C2=A0forward=
 iterators and could deal with such algorithms as fill_n, copy_n and others=
=C2=A0..._n while std::stack could drop this member function.</div>

<div>=C2=A0</div><div><br>=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=
=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013=C2=A0=D0=B3., 14:32:37 U=
TC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=
=8C Daniel Kr=C3=BCgler =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:</div></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;pad=
ding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bord=
er-left-style:solid">

<div dir=3D"ltr">For std::list there was decision to make in regard to trad=
e-of between size() and splice(), see<div class=3D"im"><br><div><br><a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2923.pdf" targ=
et=3D"_blank">http://www.open-std.org/jtc1/<u></u>sc22/wg21/docs/papers/200=
9/<u></u>n2923.pdf</a><br>


<br></div><div>But list was a container that should *fully* satisfy the con=
tainer requirements, therefore the size() member existed from the C++98. He=
re we had not choice to remove size() from list.<br>
<br>For forward_list the design idea was intentionally not to satisfy the c=
ontainer requirements, but instead to provide a type that does not take mor=
e space or time overhead relative to a hand-written C-style singly linked l=
ist, see the note added to [forwardlist.overview] p1, especially &quot;Feat=
ures that would conflict with that goal have been omitted.&quot; and the te=
xt in above quoted paper. It is certainly possible to add a size() member w=
ith O(1) guarantee but that would conflict with the design idea. Of-course =
reconsidering previous ideas is always possible, but would probably require=
 a paper that provides some convincing arguments for such a change.<br>


<br></div><div>- Daniel<br></div></div></div></blockquote></div></blockquot=
e><div>=C2=A0<br>Right now is impossible to remove `size()` from stack beca=
use some user code depands on that, exactly same case as infamous `std::vec=
tor&lt;bool&gt;`.<br>

<br>`std::forward_list` is bare bone implementation, I dont think is good i=
dea add anything to it. If you really need `size()` you could add warper ar=
ound `std::forward_list`:<br><div style=3D"background-color:rgb(250,250,250=
);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wr=
ap:break-word">

<code><div><span style><br></span><span style=3D"color:#008">template</span=
><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">typename<=
/span><span style> T</span><span style=3D"color:#660">&gt;</span><span styl=
e><br>

</span><span style=3D"color:#008">class</span><span style> forward_list_siz=
e<br></span><span style=3D"color:#660">{</span><span style><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:#008">struct</span><span style> size_dec<br=
>=C2=A0 =C2=A0 </span><span style=3D"color:#660">{</span><span style><br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 size_dec</span><span style=3D"color:#660">(</sp=
an><span style>forward_list_size</span><span style=3D"color:#660">&amp;</sp=
an><span style> r</span><span style=3D"color:#660">)</span><span style> </s=
pan><span style=3D"color:#660">:</span><span style> </span><span style=3D"c=
olor:#008">ref</span><span style=3D"color:#660">{</span><span style> r </sp=
an><span style=3D"color:#660">}</span><span style> <br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#660">{</span><span=
 style><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"=
color:#660">++</span><span style=3D"color:#008">ref</span><span style=3D"co=
lor:#660">.</span><span style>_size</span><span style=3D"color:#660">;</spa=
n><span style><br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#660">}</span><span=
 style><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#660">~<=
/span><span style>size_dec</span><span style=3D"color:#660">()</span><span =
style><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#660">{</=
span><span style><br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#660"=
>--</span><span style=3D"color:#008">ref</span><span style=3D"color:#660">.=
</span><span style>_size</span><span style=3D"color:#660">;</span><span sty=
le><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#660">}</spa=
n><span style><br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 forward_list_size</span><span style=3D"color:#6=
60">&amp;</span><span style> </span><span style=3D"color:#008">ref</span><s=
pan style=3D"color:#660">;</span><span style><br>=C2=A0 =C2=A0 </span><span=
 style=3D"color:#660">};</span><span style><br>

=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 std</span><span style=3D"color:#660">::</sp=
an><span style>forward_list</span><span style=3D"color:#660">&lt;</span><sp=
an style>std</span><span style=3D"color:#660">::</span><span style>tuple</s=
pan><span style=3D"color:#660">&lt;</span><span style>size_dec</span><span =
style=3D"color:#660">,</span><span style> T</span><span style=3D"color:#660=
">&gt;&gt;</span><span style> c</span><span style=3D"color:#660">;</span><s=
pan style><br>

=C2=A0 =C2=A0 size_t _size</span><span style=3D"color:#660">;</span><span s=
tyle><br><br></span><span style=3D"color:#008">public</span><span style=3D"=
color:#660">:</span><span style><br>=C2=A0 =C2=A0 size_t size</span><span s=
tyle=3D"color:#660">()</span><span style> </span><span style=3D"color:#008"=
>const</span><span style><br>

=C2=A0 =C2=A0 </span><span style=3D"color:#660">{</span><span style><br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">return</span><sp=
an style> _size</span><span style=3D"color:#660">;</span><span style> </spa=
n><span style=3D"color:#800">//alternative we can use O(N) version there</s=
pan><span style><br>

=C2=A0 =C2=A0 </span><span style=3D"color:#660">}</span><span style><br>=C2=
=A0 =C2=A0 <br>=C2=A0 =C2=A0 </span><span style=3D"color:#800">//rest of in=
terface that look like forward_list&lt;T&gt;</span><span style><br></span><=
span style=3D"color:#660">};</span><span style><br>

</span></div></code></div><br>good part of this is you dont force anyone el=
se to pay for your need for `size()` even if then dont use/want it. This ex=
ample class could be made more generic and allow any container that normall=
y dont support O(1) size function.<br>

</div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1135e1f6a35e4404e5ca6610--

.

------=_Part_475_30659149.1378557558699
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=20
It is a false conclusion. Nobody prevents users to use size() with their=20
stacks. But if they would want to use as the underlined container=20
std::forward_list then it will be their own decision. In this case they=20
will not use method size().

=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=81=D0=B5=D0=BD=D1=82=D1=
=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3., 16:27:19 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C=20
inkwizyt...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

>
>
> On Saturday, September 7, 2013 1:02:01 PM UTC+2, Vlad from Moscow wrote:
>>
>> I think that  there is some mess in the C++ Standard. It is the=20
>> std:;stack that should not have member function size() because this=20
>> function belongs to entities that make ranges. The notion of the range i=
s=20
>> not applicable to the stack.
>> =20
>> So it would be more logically consistent if std::forward_list would have=
=20
>> member function size() because it has forward iterators and could deal w=
ith=20
>> such algorithms as fill_n, copy_n and others ..._n while std::stack coul=
d=20
>> drop this member function.
>> =20
>>
>> =D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=81=D0=B5=D0=BD=D1=82=
=D1=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3., 14:32:37 UTC+4 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Daniel Kr=C3=BCgler=20
>> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>
>>> For std::list there was decision to make in regard to trade-of between=
=20
>>> size() and splice(), see
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2923.pdf
>>>
>>> But list was a container that should *fully* satisfy the container=20
>>> requirements, therefore the size() member existed from the C++98. Here =
we=20
>>> had not choice to remove size() from list.
>>>
>>> For forward_list the design idea was intentionally not to satisfy the=
=20
>>> container requirements, but instead to provide a type that does not tak=
e=20
>>> more space or time overhead relative to a hand-written C-style singly=
=20
>>> linked list, see the note added to [forwardlist.overview] p1, especiall=
y=20
>>> "Features that would conflict with that goal have been omitted." and th=
e=20
>>> text in above quoted paper. It is certainly possible to add a size() me=
mber=20
>>> with O(1) guarantee but that would conflict with the design idea. Of-co=
urse=20
>>> reconsidering previous ideas is always possible, but would probably req=
uire=20
>>> a paper that provides some convincing arguments for such a change.
>>>
>>> - Daniel
>>>
>> =20
> Right now is impossible to remove `size()` from stack because some user=
=20
> code depands on that, exactly same case as infamous `std::vector<bool>`.
>
> `std::forward_list` is bare bone implementation, I dont think is good ide=
a=20
> add anything to it. If you really need `size()` you could add warper arou=
nd=20
> `std::forward_list`:
>
> template<typename T>
> class forward_list_size
> {
>     struct size_dec
>     {
>         size_dec(forward_list_size& r) : ref{ r }=20
>         {
>             ++ref._size;
>         }
>         ~size_dec()
>         {
>             --ref._size;
>         }
>         forward_list_size& ref;
>     };
>    =20
>     std::forward_list<std::tuple<size_dec, T>> c;
>     size_t _size;
>
> public:
>     size_t size() const
>     {
>         return _size; //alternative we can use O(N) version there
>     }
>    =20
>     //rest of interface that look like forward_list<T>
> };
>
> good part of this is you dont force anyone else to pay for your need for=
=20
> `size()` even if then dont use/want it. This example class could be made=
=20
> more generic and allow any container that normally dont support O(1) size=
=20
> function.
>

--=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_475_30659149.1378557558699
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&nbsp;</div><div>It is a false conclusion. Nobody pre=
vents users to use size() with their stacks. But if they would want to use =
as the underlined container std::forward_list then it will be their own dec=
ision. In this case they will not use method size().</div><div><br>=D1=81=
=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=
=B1=D1=80=D1=8F 2013&nbsp;=D0=B3., 16:27:19 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C inkwizyt...@gmail.com =D0=
=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-col=
or: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">=
<div dir=3D"ltr"><br><br>On Saturday, September 7, 2013 1:02:01 PM UTC+2, V=
lad from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>I =
think that&nbsp; there is some mess in the C++ Standard. It is the std:;sta=
ck that should not have member function size() because this function belong=
s to entities that make ranges. The notion of the range is not applicable t=
o the stack.</div><div>&nbsp;</div><div>So it would be more logically consi=
stent&nbsp;if std::forward_list would have member function size() because i=
t has&nbsp;forward iterators and could deal with such algorithms as fill_n,=
 copy_n and others&nbsp;..._n while std::stack could drop this member funct=
ion.</div><div>&nbsp;</div><div><br>=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=
=B0, 7 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013&nbsp;=D0=B3., =
14:32:37 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=
=D0=BB=D1=8C Daniel Kr=C3=BCgler =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB=
:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex=
; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wid=
th: 1px; border-left-style: solid;"><div dir=3D"ltr">For std::list there wa=
s decision to make in regard to trade-of between size() and splice(), see<b=
r><div><br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20=
09/n2923.pdf" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21=
/docs/papers/2009/<wbr>n2923.pdf</a><br>
<br></div><div>But list was a container that should *fully* satisfy the con=
tainer requirements, therefore the size() member existed from the C++98. He=
re we had not choice to remove size() from list.<br>
<br>For forward_list the design idea was intentionally not to satisfy the c=
ontainer requirements, but instead to provide a type that does not take mor=
e space or time overhead relative to a hand-written C-style singly linked l=
ist, see the note added to [forwardlist.overview] p1, especially "Features =
that would conflict with that goal have been omitted." and the text in abov=
e quoted paper. It is certainly possible to add a size() member with O(1) g=
uarantee but that would conflict with the design idea. Of-course reconsider=
ing previous ideas is always possible, but would probably require a paper t=
hat provides some convincing arguments for such a change.<br>
<br></div><div>- Daniel<br></div></div></blockquote></div></blockquote><div=
>&nbsp;<br>Right now is impossible to remove `size()` from stack because so=
me user code depands on that, exactly same case as infamous `std::vector&lt=
;bool&gt;`.<br><br>`std::forward_list` is bare bone implementation, I dont =
think is good idea add anything to it. If you really need `size()` you coul=
d add warper around `std::forward_list`:<br><div style=3D"border: 1px solid=
 rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250,=
 250);"><code><div><span style=3D"color: rgb(0, 0, 0);"><br></span><span st=
yle=3D"color: rgb(0, 0, 136);">template</span><span style=3D"color: rgb(102=
, 102, 0);">&lt;</span><span style=3D"color: rgb(0, 0, 136);">typename</spa=
n><span style=3D"color: rgb(0, 0, 0);"> T</span><span style=3D"color: rgb(1=
02, 102, 0);">&gt;</span><span style=3D"color: rgb(0, 0, 0);"><br></span><s=
pan style=3D"color: rgb(0, 0, 136);">class</span><span style=3D"color: rgb(=
0, 0, 0);"> forward_list_size<br></span><span style=3D"color: rgb(102, 102,=
 0);">{</span><span style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; </span=
><span style=3D"color: rgb(0, 0, 136);">struct</span><span style=3D"color: =
rgb(0, 0, 0);"> size_dec<br>&nbsp; &nbsp; </span><span style=3D"color: rgb(=
102, 102, 0);">{</span><span style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbs=
p; &nbsp; &nbsp; size_dec</span><span style=3D"color: rgb(102, 102, 0);">(<=
/span><span style=3D"color: rgb(0, 0, 0);">forward_list_size</span><span st=
yle=3D"color: rgb(102, 102, 0);">&amp;</span><span style=3D"color: rgb(0, 0=
, 0);"> r</span><span style=3D"color: rgb(102, 102, 0);">)</span><span styl=
e=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, 0);"=
>:</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color:=
 rgb(0, 0, 136);">ref</span><span style=3D"color: rgb(102, 102, 0);">{</spa=
n><span style=3D"color: rgb(0, 0, 0);"> r </span><span style=3D"color: rgb(=
102, 102, 0);">}</span><span style=3D"color: rgb(0, 0, 0);"> <br>&nbsp; &nb=
sp; &nbsp; &nbsp; </span><span style=3D"color: rgb(102, 102, 0);">{</span><=
span style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; </span><span style=3D"color: rgb(102, 102, 0);">++</span><span style=
=3D"color: rgb(0, 0, 136);">ref</span><span style=3D"color: rgb(102, 102, 0=
);">.</span><span style=3D"color: rgb(0, 0, 0);">_size</span><span style=3D=
"color: rgb(102, 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"><br=
>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: rgb(102, 102, 0);=
">}</span><span style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; &nbsp; &nb=
sp; </span><span style=3D"color: rgb(102, 102, 0);">~</span><span style=3D"=
color: rgb(0, 0, 0);">size_dec</span><span style=3D"color: rgb(102, 102, 0)=
;">()</span><span style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; &nbsp; &=
nbsp; </span><span style=3D"color: rgb(102, 102, 0);">{</span><span style=
=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </s=
pan><span style=3D"color: rgb(102, 102, 0);">--</span><span style=3D"color:=
 rgb(0, 0, 136);">ref</span><span style=3D"color: rgb(102, 102, 0);">.</spa=
n><span style=3D"color: rgb(0, 0, 0);">_size</span><span style=3D"color: rg=
b(102, 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &n=
bsp; &nbsp; &nbsp; </span><span style=3D"color: rgb(102, 102, 0);">}</span>=
<span style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; &nbsp; &nbsp; forwar=
d_list_size</span><span style=3D"color: rgb(102, 102, 0);">&amp;</span><spa=
n style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 13=
6);">ref</span><span style=3D"color: rgb(102, 102, 0);">;</span><span style=
=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; </span><span style=3D"color: rg=
b(102, 102, 0);">};</span><span style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &=
nbsp; <br>&nbsp; &nbsp; std</span><span style=3D"color: rgb(102, 102, 0);">=
::</span><span style=3D"color: rgb(0, 0, 0);">forward_list</span><span styl=
e=3D"color: rgb(102, 102, 0);">&lt;</span><span style=3D"color: rgb(0, 0, 0=
);">std</span><span style=3D"color: rgb(102, 102, 0);">::</span><span style=
=3D"color: rgb(0, 0, 0);">tuple</span><span style=3D"color: rgb(102, 102, 0=
);">&lt;</span><span style=3D"color: rgb(0, 0, 0);">s<wbr>ize_dec</span><sp=
an style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, =
0, 0);"> T</span><span style=3D"color: rgb(102, 102, 0);">&gt;&gt;</span><s=
pan style=3D"color: rgb(0, 0, 0);"> c</span><span style=3D"color: rgb(102, =
102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; si=
ze_t _size</span><span style=3D"color: rgb(102, 102, 0);">;</span><span sty=
le=3D"color: rgb(0, 0, 0);"><br><br></span><span style=3D"color: rgb(0, 0, =
136);">public</span><span style=3D"color: rgb(102, 102, 0);">:</span><span =
style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; size_t size</span><span st=
yle=3D"color: rgb(102, 102, 0);">()</span><span style=3D"color: rgb(0, 0, 0=
);"> </span><span style=3D"color: rgb(0, 0, 136);">const</span><span style=
=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; </span><span style=3D"color: rg=
b(102, 102, 0);">{</span><span style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &n=
bsp; &nbsp; &nbsp; </span><span style=3D"color: rgb(0, 0, 136);">return</sp=
an><span style=3D"color: rgb(0, 0, 0);"> _size</span><span style=3D"color: =
rgb(102, 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"> </span><sp=
an style=3D"color: rgb(136, 0, 0);">//alternative we can use O(N) version t=
here</span><span style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; </span><s=
pan style=3D"color: rgb(102, 102, 0);">}</span><span style=3D"color: rgb(0,=
 0, 0);"><br>&nbsp; &nbsp; <br>&nbsp; &nbsp; </span><span style=3D"color: r=
gb(136, 0, 0);">//rest of interface that look like forward_list&lt;T&gt;</s=
pan><span style=3D"color: rgb(0, 0, 0);"><br></span><span style=3D"color: r=
gb(102, 102, 0);">};</span><span style=3D"color: rgb(0, 0, 0);"><br></span>=
</div></code></div><br>good part of this is you dont force anyone else to p=
ay for your need for `size()` even if then dont use/want it. This example c=
lass could be made more generic and allow any container that normally dont =
support O(1) size function.<br></div></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_475_30659149.1378557558699--

.

--=-jOiG4xax+2IZlkMldzNh
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On sab, 2013-09-07 at 14:35 +0200, Maurice Bos wrote:
> Maybe the stack adapter could keep track of the size by itself in the
> cases when the underlying container does not provide a .size(). (It'd
> be trivial, push does ++, pop does --).

Since the underlying container is part of the interface, though, any
changes made through it would not be recorded.  Imagine someone derives
from std::stack and makes modifications to the underlying container.
std::stack wouldn't be able to know this.

Cheers,
Patrick Niedzielski


--=-jOiG4xax+2IZlkMldzNh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAABAgAGBQJSKx6vAAoJECyWbNe9EHCfsl0H/1qsb36AiqQOfqVt68ApT97o
9/QiXhuZgk6wPWzqb9cwOp/lZqxD8HFA07aJvTAvZfV5gTWClJmx17p7y8EpG55l
egBq7+uJ7g1Zji9cLaUFPfm0N4EwF/5YJNxmJ+L4BSN6y8l8Twbl52e/WP4KYc25
e2ZZ+vixQgaYIzYRxPhOew5YWUxkJyGwKKICTt23RUUSr+6oZFu5ubm9THxupp+z
hf4CT7IjLUN8ZLMU/mLLKcMvk319upkg4Y30cYvweUWXpMwdEkQUa5LtoKTHVgLc
8EaY/CxiBQz96a9jQNg6nBPUBCB+thLlDHXNl7/ho7DsS1JlpDiuEI5SVCgvYxw=
=A9P1
-----END PGP SIGNATURE-----

--=-jOiG4xax+2IZlkMldzNh--


.

------=_Part_409_736482.1378557766964
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable



On Saturday, September 7, 2013 1:48:57 AM UTC+2, Vlad from Moscow wrote:
>
> I doi not agree that we need a new version of stack. All what we need we=
=20
> already have. Moreover stack does not require member function size(). It =
is=20
> unnecessary function. What is size()? Inf act is is an analogy of an=20
> iterator. Consider using size with an array something as
> =20
> for ( int i =3D 0; i < n; i++ ) a[i] =3D i;
> =20
> a + 0 and a + n give us iterators. However stack has no iterators so it=
=20
> does not need the size() function. The logic of functionality of the stac=
k=20
> is simple. We are popping out elements of the stack while it is not empty=
..
> =20
> What we need is simply a specialization of std::stack for=20
> std::forward_list. std::forward_list has all functionality of the stack.
> =20
> =20
>
> =D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 3:14:13 UTC+=
4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8=20
> inkwizyt...@gmail.com =CE=C1=D0=C9=D3=C1=CC:
>
>>
>> why no `size()`? nobody can access inner list ergo stack can easy=20
>> determine size in const time. `std::stack` require only:
>>
>> back
>> push_back
>> pop_back
>>
>> that can be in case `std::forward_list` inverted to:
>>
>> front
>> push_front
>> pop_front
>>
>> maybe we need simple new version of stack? `std::stack_front`?
>>
>>
After some thoughts I think concepts could graceful fix all this problems.

First we will have two specification for container that have or not have=20
`size()`. If container dont have `size()` stack will count it for him.

Second functions `push`, `pop` and `top` will call proxy function that will=
=20
chose correct function set:
`push_back`, `pop_back`, `back`
or if container dont have them, proxy will use:
`push_front`, `pop_front`, `front`
of course this function need work in sync and take full package not e.g.=20
`back` and `push_front`.

--=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_409_736482.1378557766964
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, September 7, 2013 1:48:57 AM UTC+2, V=
lad from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>I doi not agree that we need a new version of stack. All what=
 we need we already have. Moreover stack does not require member function s=
ize(). It is unnecessary function. What is size()? Inf act is is an analogy=
 of an iterator. Consider using size with an array something as</div><div>&=
nbsp;</div><div>for ( int i =3D 0; i &lt; n; i++ ) a[i] =3D i;</div><div>&n=
bsp;</div><div>a + 0 and a + n give us iterators. However stack has no iter=
ators so it does not need the size() function. The logic of functionality o=
f the stack is simple. We are popping out elements of the stack while it is=
 not empty.</div><div>&nbsp;</div><div>What we need is simply a specializat=
ion of std::stack for std::forward_list. std::forward_list has all function=
ality of the stack.</div><div>&nbsp;</div><div>&nbsp;</div><div><br>=D3=D5=
=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=C7., 3:14:13 UTC+4 =
=D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 <a>inkwizyt...@gmail.com</a> =CE=C1=D0=
=C9=D3=C1=CC:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left=
-width:1px;border-left-style:solid"><div dir=3D"ltr"><br><div><font size=3D=
"2"><span style=3D"font-family:arial,sans-serif">why no `size()`? nobody ca=
n access inner list ergo stack can easy determine size in const time. `std:=
:stack` require only:<br><br>back<br>push_back<br>pop_back<br><br>that can =
be in case `std::forward_list` inverted to:<br><br>front<br>push_front<br>p=
op_front<br><br>maybe we need simple new version of stack? `std::stack_fron=
t`?<br><br></span></font></div></div></blockquote></div></blockquote><div><=
br>After some thoughts I think concepts could graceful fix all this problem=
s.<br><br>First we will have two specification for container that have or n=
ot have `size()`. If container dont have `size()` stack will count it for h=
im.<br><br>Second functions `push`, `pop` and `top` will call proxy functio=
n that will chose correct function set:<br>`push_back`, `pop_back`, `back`<=
br>or if container dont have them, proxy will use:<br>`push_front`, `pop_fr=
ont`, `front`<br>of course this function need work in sync and take full pa=
ckage not e.g. `back` and `push_front`.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_409_736482.1378557766964--

.

------=_Part_586_3453378.1378558327201
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

The underlying container is not a part of the interface of std:;stack. The=
=20
interface of std::stack does not depend on the underlying container. It=20
would be very bad if the interface of std:;stack would depend on the=20
underlying container.  The stack is simply an abstraction that can be=20
realized with either one or another container.=20
=20

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 16:40:15 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 14:35 +0200, Maurice Bos wrote:=20
> > Maybe the stack adapter could keep track of the size by itself in the=
=20
> > cases when the underlying container does not provide a .size(). (It'd=
=20
> > be trivial, push does ++, pop does --).=20
>
> Since the underlying container is part of the interface, though, any=20
> changes made through it would not be recorded.  Imagine someone derives=
=20
> from std::stack and makes modifications to the underlying container.=20
> std::stack wouldn't be able to know this.=20
>
> Cheers,=20
> Patrick Niedzielski=20
>
>

--=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_586_3453378.1378558327201
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>The&nbsp;underlying container is not a part of the in=
terface of std:;stack. The interface of std::stack does not depend on the u=
nderlying container. It would be very bad&nbsp;if the interface of std:;sta=
ck would depend on the underlying container.&nbsp; The stack is simply an a=
bstraction that can be realized with either one or another container.&nbsp;=
</div><div>&nbsp;</div><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=
=D2=D1 2013&nbsp;=C7., 16:40:15 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 =
Patrick M. Niedzielski =CE=C1=D0=C9=D3=C1=CC:</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-lef=
t-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: sol=
id;">On sab, 2013-09-07 at 14:35 +0200, Maurice Bos wrote:
<br>&gt; Maybe the stack adapter could keep track of the size by itself in =
the
<br>&gt; cases when the underlying container does not provide a .size(). (I=
t'd
<br>&gt; be trivial, push does ++, pop does --).
<br>
<br>Since the underlying container is part of the interface, though, any
<br>changes made through it would not be recorded. &nbsp;Imagine someone de=
rives
<br>from std::stack and makes modifications to the underlying container.
<br>std::stack wouldn't be able to know this.
<br>
<br>Cheers,
<br>Patrick Niedzielski
<br>
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_586_3453378.1378558327201--

.

--=-THqwV6087PHP83zv8DJt
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On sab, 2013-09-07 at 05:52 -0700, Vlad from Moscow wrote:
> The underlying container is not a part of the interface of std:;stack. Th=
e=20
> interface of std::stack does not depend on the underlying container. It=
=20
> would be very bad if the interface of std:;stack would depend on the=20
> underlying container.  The stack is simply an abstraction that can be=20
> realized with either one or another container.=20

Unfortunately, the underlying container is part of the interface of
std::stack.  There is a protected member "Container c" in std::stack
(see [queue.defn]).  Protected members make up part of the interface of
a class, because any one can derive from the class and access this
member.  It may not be in the public interface, but it definitely is
part of the interface.  (Remember, the standard specifies the interface,
not the implementation of types, and the standard specifies that
std::stack must have the underlying container "c" in the interface.)

--=-THqwV6087PHP83zv8DJt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAABAgAGBQJSKyckAAoJECyWbNe9EHCfP30IAMA51BeCUufVGJBAMhUZypQv
3JAIJS79skbqyaI07HlZM3tu77iSBjQ716mN7tooGSo1iyooo0HUCjwFk/zh9V8W
uXmcFlxKNXM9gjeN1W/brA1eyn4m170ReiUx6SuTCTn879Uc/WN5oVk9a0bdQTYa
bc4pJwu+qzoMNyoNVSGwGOgbwcH7T6MAeT401+Wx7Yi8Yv65XhTmHPZd6+pXPayJ
kWGgbr4LBznODtnogKUTlkCQTNzhZhfCC3W821QBSYImgbyVT8s9U/l6Ll45nFOd
uuVYBqkTSLg9tdcd8Ql8+XI0gKVk8kl4aJtIEks+m6oh+f2GWVBv0ChUyDrUULY=
=ucLr
-----END PGP SIGNATURE-----

--=-THqwV6087PHP83zv8DJt--


.

------=_Part_270_24487428.1378559985133
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

But visibility of `size()` will depend on it? In another post you saidthat:=
 "(..) In this case they will not use method size().". This is clearly=20
change of `std::stack` interface.

On Saturday, September 7, 2013 2:52:07 PM UTC+2, Vlad from Moscow wrote:
>
> The underlying container is not a part of the interface of std:;stack. Th=
e=20
> interface of std::stack does not depend on the underlying container. It=
=20
> would be very bad if the interface of std:;stack would depend on the=20
> underlying container.  The stack is simply an abstraction that can be=20
> realized with either one or another container.=20
> =20
>
> =D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 16:40:15 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 14:35 +0200, Maurice Bos wrote:=20
>> > Maybe the stack adapter could keep track of the size by itself in the=
=20
>> > cases when the underlying container does not provide a .size(). (It'd=
=20
>> > be trivial, push does ++, pop does --).=20
>>
>> Since the underlying container is part of the interface, though, any=20
>> changes made through it would not be recorded.  Imagine someone derives=
=20
>> from std::stack and makes modifications to the underlying container.=20
>> std::stack wouldn't be able to know this.=20
>>
>> Cheers,=20
>> Patrick Niedzielski=20
>>
>>

--=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_270_24487428.1378559985133
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">But visibility of `size()` will depend on it? In another p=
ost you<font size=3D"2"><span style=3D"font-family: arial,sans-serif;"><spa=
n dir=3D"auto"> said</span></span></font> that: "(..) In this case they wil=
l not use method size().". This is clearly change of `std::stack` interface=
..<br><br>On Saturday, September 7, 2013 2:52:07 PM UTC+2, Vlad from Moscow =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Th=
e&nbsp;underlying container is not a part of the interface of std:;stack. T=
he interface of std::stack does not depend on the underlying container. It =
would be very bad&nbsp;if the interface of std:;stack would depend on the u=
nderlying container.&nbsp; The stack is simply an abstraction that can be r=
ealized with either one or another container.&nbsp;</div><div>&nbsp;</div><=
div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=C7., 1=
6:40:15 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Patrick M. Niedzielski =
=CE=C1=D0=C9=D3=C1=CC:</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bo=
rder-left-width:1px;border-left-style:solid">On sab, 2013-09-07 at 14:35 +0=
200, Maurice Bos wrote:
<br>&gt; Maybe the stack adapter could keep track of the size by itself in =
the
<br>&gt; cases when the underlying container does not provide a .size(). (I=
t'd
<br>&gt; be trivial, push does ++, pop does --).
<br>
<br>Since the underlying container is part of the interface, though, any
<br>changes made through it would not be recorded. &nbsp;Imagine someone de=
rives
<br>from std::stack and makes modifications to the underlying container.
<br>std::stack wouldn't be able to know this.
<br>
<br>Cheers,
<br>Patrick Niedzielski
<br>
<br></blockquote></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_270_24487428.1378559985133--

.

------=_Part_482_8050380.1378560182964
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

I think you are mistaken. Protected members are the part of the realization=
=20
and also the part of realization of derived classes. It is not an=20
interface. One more the interface of std::stack does not depend on the=20
underlaying container.

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 17:16:20 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 05:52 -0700, Vlad from Moscow wrote:=20
> > The underlying container is not a part of the interface of std:;stack.=
=20
> The=20
> > interface of std::stack does not depend on the underlying container. It=
=20
> > would be very bad if the interface of std:;stack would depend on the=20
> > underlying container.  The stack is simply an abstraction that can be=
=20
> > realized with either one or another container.=20
>
> Unfortunately, the underlying container is part of the interface of=20
> std::stack.  There is a protected member "Container c" in std::stack=20
> (see [queue.defn]).  Protected members make up part of the interface of=
=20
> a class, because any one can derive from the class and access this=20
> member.  It may not be in the public interface, but it definitely is=20
> part of the interface.  (Remember, the standard specifies the interface,=
=20
> not the implementation of types, and the standard specifies that=20
> std::stack must have the underlying container "c" in the interface.)=20
>

--=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_482_8050380.1378560182964
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I think you are mistaken. Protected members are the p=
art of the realization and also the part of realization of derived classes.=
 It is not an interface. One more the interface of std::stack does not depe=
nd on the underlaying container.</div><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=
=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=C7., 17:16:20 UTC+4 =D0=CF=CC=D8=DA=CF=D7=
=C1=D4=C5=CC=D8 Patrick M. Niedzielski =CE=C1=D0=C9=D3=C1=CC:</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left:=
 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border=
-left-style: solid;">On sab, 2013-09-07 at 05:52 -0700, Vlad from Moscow wr=
ote:
<br>&gt; The underlying container is not a part of the interface of std:;st=
ack. The=20
<br>&gt; interface of std::stack does not depend on the underlying containe=
r. It=20
<br>&gt; would be very bad if the interface of std:;stack would depend on t=
he=20
<br>&gt; underlying container. &nbsp;The stack is simply an abstraction tha=
t can be=20
<br>&gt; realized with either one or another container.=20
<br>
<br>Unfortunately, the underlying container is part of the interface of
<br>std::stack. &nbsp;There is a protected member "Container c" in std::sta=
ck
<br>(see [queue.defn]). &nbsp;Protected members make up part of the interfa=
ce of
<br>a class, because any one can derive from the class and access this
<br>member. &nbsp;It may not be in the public interface, but it definitely =
is
<br>part of the interface. &nbsp;(Remember, the standard specifies the inte=
rface,
<br>not the implementation of types, and the standard specifies that
<br>std::stack must have the underlying container "c" in the interface.)
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_482_8050380.1378560182964--

.

----_com.android.email_440108531620610
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

You are wrong and your definition is rather silly, but call all it what you=
 want. Changing such a member breaks this code `class foo : stack <T> { siz=
e_t code() { return c.size(); } };`. That is all that matters and you are f=
ree to use your own silly definition of "interface" but you are not free to=
 ignore this breaking change.

- painstakingly typed in my mobile general purpose computing and communicat=
ion device; please do not make me type it again


Martinho

-------- Original message --------
From: Vlad from Moscow <vlad.moscow@mail.ru>=20
Date: =20
To: std-proposals@isocpp.org=20
Subject: Re: [std-proposals] Specialization of std::stack for std::forward_=
list=20
=20
I think you are mistaken. Protected members are the part of the realization=
 and also the part of realization of derived classes. It is not an interfac=
e. One more the interface of std::stack does not depend on the underlaying =
container.

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013=9A=C7., 17:16:20 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 05:52 -0700, Vlad from Moscow wrote:=20
> The underlying container is not a part of the interface of std:;stack. Th=
e=20
> interface of std::stack does not depend on the underlying container. It=
=20
> would be very bad if the interface of std:;stack would depend on the=20
> underlying container. =9AThe stack is simply an abstraction that can be=
=20
> realized with either one or another container.=20

Unfortunately, the underlying container is part of the interface of=20
std::stack. =9AThere is a protected member "Container c" in std::stack=20
(see [queue.defn]). =9AProtected members make up part of the interface of=
=20
a class, because any one can derive from the class and access this=20
member. =9AIt may not be in the public interface, but it definitely is=20
part of the interface. =9A(Remember, the standard specifies the interface,=
=20
not the implementation of types, and the standard specifies that=20
std::stack must have the underlying container "c" in the interface.)=20
--=20
=9A
---=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/.

--=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/.

----_com.android.email_440108531620610
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8"></head><body ><div><div>You are wrong and your definition is rath=
er silly, but call all it what you want. Changing such a member breaks this=
 code `class foo : stack &lt;T&gt; { size_t code() { return c.size(); } };`=
.. That is all that matters and you are free to use your own silly definitio=
n of "interface" but you are not free to ignore this breaking change.</div>=
<div><br></div><div>- painstakingly typed in my mobile general purpose comp=
uting and communication device; please do not make me type it again</div><d=
iv><br></div><div><br></div>Martinho</div><br><br><br>-------- Original mes=
sage --------<br>From: Vlad from Moscow &lt;vlad.moscow@mail.ru&gt; <br>Dat=
e:  <br>To: std-proposals@isocpp.org <br>Subject: Re: [std-proposals] Speci=
alization of std::stack for std::forward_list <br> <br><br><div dir=3D"ltr"=
><div>I think you are mistaken. Protected members are the part of the reali=
zation and also the part of realization of derived classes. It is not an in=
terface. One more the interface of std::stack does not depend on the underl=
aying container.</div><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=
=D2=D1 2013&nbsp;=C7., 17:16:20 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 =
Patrick M. Niedzielski =CE=C1=D0=C9=D3=C1=CC:</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-lef=
t-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: sol=
id;">On sab, 2013-09-07 at 05:52 -0700, Vlad from Moscow wrote:
<br>&gt; The underlying container is not a part of the interface of std:;st=
ack. The=20
<br>&gt; interface of std::stack does not depend on the underlying containe=
r. It=20
<br>&gt; would be very bad if the interface of std:;stack would depend on t=
he=20
<br>&gt; underlying container. &nbsp;The stack is simply an abstraction tha=
t can be=20
<br>&gt; realized with either one or another container.=20
<br>
<br>Unfortunately, the underlying container is part of the interface of
<br>std::stack. &nbsp;There is a protected member "Container c" in std::sta=
ck
<br>(see [queue.defn]). &nbsp;Protected members make up part of the interfa=
ce of
<br>a class, because any one can derive from the class and access this
<br>member. &nbsp;It may not be in the public interface, but it definitely =
is
<br>part of the interface. &nbsp;(Remember, the standard specifies the inte=
rface,
<br>not the implementation of types, and the standard specifies that
<br>std::stack must have the underlying container "c" in the interface.)
<br></blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br>
To post to this group, send email to std-proposals@isocpp.org.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br>
</body>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

----_com.android.email_440108531620610--



.

------=_Part_508_9688517.1378561177061
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

First of all I do not see any silly.
Secondly no code will be broken because it is the user decision what=20
underlaying container to use.
I see here only one silly thing. It is your example of class foo.

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 17:33:04 UTC+4=
 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 R. Martinho=20
Fernandes =CE=C1=D0=C9=D3=C1=CC:

> You are wrong and your definition is rather silly, but call all it what=
=20
> you want. Changing such a member breaks this code `class foo : stack <T> =
{=20
> size_t code() { return c.size(); } };`. That is all that matters and you=
=20
> are free to use your own silly definition of "interface" but you are not=
=20
> free to ignore this breaking change.
>
> - painstakingly typed in my mobile general purpose computing and=20
> communication device; please do not make me type it again
>
>
> Martinho
>
>
>
> -------- Original message --------
> From: Vlad from Moscow <vlad....@mail.ru <javascript:>>=20
> Date:=20
> To: std-pr...@isocpp.org <javascript:>=20
> Subject: Re: [std-proposals] Specialization of std::stack for=20
> std::forward_list=20
>
>
> I think you are mistaken. Protected members are the part of the=20
> realization and also the part of realization of derived classes. It is no=
t=20
> an interface. One more the interface of std::stack does not depend on the=
=20
> underlaying container.
>
> =D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 17:16:20 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 05:52 -0700, Vlad from Moscow wrote:=20
>> > The underlying container is not a part of the interface of std:;stack.=
=20
>> The=20
>> > interface of std::stack does not depend on the underlying container. I=
t=20
>> > would be very bad if the interface of std:;stack would depend on the=
=20
>> > underlying container.  The stack is simply an abstraction that can be=
=20
>> > realized with either one or another container.=20
>>
>> Unfortunately, the underlying container is part of the interface of=20
>> std::stack.  There is a protected member "Container c" in std::stack=20
>> (see [queue.defn]).  Protected members make up part of the interface of=
=20
>> a class, because any one can derive from the class and access this=20
>> member.  It may not be in the public interface, but it definitely is=20
>> part of the interface.  (Remember, the standard specifies the interface,=
=20
>> not the implementation of types, and the standard specifies that=20
>> std::stack must have the underlying container "c" in the interface.)=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 <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> 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_508_9688517.1378561177061
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>First of all I do not see any silly.</div><div>Second=
ly no code will be broken because it is the user decision what underlaying =
container to use.</div><div>I see here only one silly thing. It is your exa=
mple of class foo.</div><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=
=C2=D2=D1 2013&nbsp;=C7., 17:33:04 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=
=D8 R. Martinho Fernandes =CE=C1=D0=C9=D3=C1=CC:</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-=
left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: =
solid;"><div><div><div>You are wrong and your definition is rather silly, b=
ut call all it what you want. Changing such a member breaks this code `clas=
s foo : stack &lt;T&gt; { size_t code() { return c.size(); } };`. That is a=
ll that matters and you are free to use your own silly definition of "inter=
face" but you are not free to ignore this breaking change.</div><div><br></=
div><div>- painstakingly typed in my mobile general purpose computing and c=
ommunication device; please do not make me type it again</div><div><br></di=
v><div><br></div>Martinho</div><br><br><br>-------- Original message ------=
--<br>From: Vlad from Moscow &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"VO5GvZ3yMXsJ">vlad....@mail.ru</a>&gt; <br>Date:  =
<br>To: <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
VO5GvZ3yMXsJ">std-pr...@isocpp.org</a> <br>Subject: Re: [std-proposals] Spe=
cialization of std::stack for std::forward_list <br> <br><br><div dir=3D"lt=
r"><div>I think you are mistaken. Protected members are the part of the rea=
lization and also the part of realization of derived classes. It is not an =
interface. One more the interface of std::stack does not depend on the unde=
rlaying container.</div><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=
=C2=D2=D1 2013&nbsp;=C7., 17:16:20 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=
=D8 Patrick M. Niedzielski =CE=C1=D0=C9=D3=C1=CC:</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border=
-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style:=
 solid;">On sab, 2013-09-07 at 05:52 -0700, Vlad from Moscow wrote:
<br>&gt; The underlying container is not a part of the interface of std:;st=
ack. The=20
<br>&gt; interface of std::stack does not depend on the underlying containe=
r. It=20
<br>&gt; would be very bad if the interface of std:;stack would depend on t=
he=20
<br>&gt; underlying container. &nbsp;The stack is simply an abstraction tha=
t can be=20
<br>&gt; realized with either one or another container.=20
<br>
<br>Unfortunately, the underlying container is part of the interface of
<br>std::stack. &nbsp;There is a protected member "Container c" in std::sta=
ck
<br>(see [queue.defn]). &nbsp;Protected members make up part of the interfa=
ce of
<br>a class, because any one can derive from the class and access this
<br>member. &nbsp;It may not be in the public interface, but it definitely =
is
<br>part of the interface. &nbsp;(Remember, the standard specifies the inte=
rface,
<br>not the implementation of types, and the standard specifies that
<br>std::stack must have the underlying container "c" in the interface.)
<br></blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
VO5GvZ3yMXsJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"VO5GvZ3yMXsJ">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_508_9688517.1378561177061--

.

------=_Part_506_25686563.1378562027296
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

After this discussion I end up with conclusion that your solution is=20
correct one. Its simples and requare no changes in `std::stack` or in=20
`std::forward_list`.
Another thing is that if any problems would occur it will be during=20
compilation not in execution
(you cant remove anything from `std::forward_list` without using this=20
warper, therefore `size()` will always return correct value).

On Saturday, September 7, 2013 1:02:30 PM UTC+2, Daniel Kr=FCgler wrote:
>
> 2013/9/7 Vlad from Moscow <vlad....@mail.ru <javascript:>>
>
>> What you demonstarted is not a stack. You dealt with a container. So=20
>> there is nothing suprising that the elements are outputed in the reverse=
=20
>> order. It was your decision to use std::forward_list as a container.=20
>>
>
> It is not clear whose decision it will be, because the std::stack might b=
e=20
> used as an implementation detail of another template, so it the effects a=
re=20
> very unexpected and not aware of the implementer of the "outer2 template.=
=20
>
> Keep also in mind that the protected member 'c' is part of the API, so=20
> someone who derives from stack can expect that the member functions of c=
=20
> required in the std::stack specification do exist. In case of your=20
> hypothetical specialization of std::stack the derived template would brea=
k=20
> when trying to refer to push_back(), back(), etc.
>
> I also think that your assertion that stack "is a some sort of an abstrac=
t=20
> class" is misleading. This type as an *adaptor* type, so like other=20
> adaptors its specification relies on a well-defined set of operations fro=
m=20
> the adapteed type. The standard library support  user-defined=20
> specializations of library templates ([namespace.std]), if specialization=
=20
> meets the standard library requirements for the original template. This i=
s=20
> not satisfied for std::forward_list, because the difference is observable=
,=20
> *because* the member c is part of its API.
>
> =20
>
>> It is the same as you would use std::list and then decided to change it=
=20
>> to std::vector and now you wonder that std::vector has no member functio=
n=20
>> push_front.
>>
>
> No, this example does not match here for std::stack, because std::stack=
=20
> does not depend on any operation named push_front().
> =20
>
>>  Your example demonstrates that the specialization of std::stack for=20
>> std::forward_list is very useful! Because it allows to output elements o=
f a=20
>> stack in the natural order in which they are  stored in it that is in th=
e=20
>> order FILO. =20
>>
>
> Again I repeat that this can already be realized by providing an adaptor=
=20
> of forward_list, that provides the required operations needed for=20
> std::stack. There is no reason to assume that such an adaptor would cause=
=20
> any time overhead. There would be a small space overhead to provide the=
=20
> size() member, but obviously this idea was accepted when using std::stack=
=20
> based on forward_list. I also consider this kind of adaptor as an=20
> interesting one that is similar to reverse_iterator for iterators. I'm no=
t=20
> sure that reverse_container is the right name for it, but here the rough=
=20
> idea of such a template:
>
> template <class T, class Container =3D deque<T> >
> class reverse_container {
> public:
>   typedef typename Container::value_type value_type;
>   typedef typename Container::reference reference;
>   typedef typename Container::const_reference const_reference;
>   typedef typename Container::size_type size_type;
>   typedef Container container_type;=20
>   [..] // constructors
>   bool empty() const { return c.empty(); }
>   size_type size() const { return c.size(); }
>   reference back() { return c.front(); }
>   const_reference back() const { return c.front(); }
>  =20
>   void push_back(const value_type& x) { c.push_front(x); }
>   void push_back(value_type&& x) { c.push_front(std::move(x)); }
>   template <class... Args> void emplace_back(Args&&... args)
>   { c.emplace_front(std::forward<Args>(args)...); }
>   void pop_back() { c.pop_font(); }
>   void swap(stack& s) noexcept(noexcept(swap(c, s.c)))
>   { using std::swap; swap(c, s.c); }
> private:
>   Container c; // For exposition only
> };
>
> I'm leaving the decision open here, there are several ways to handle that=
..
>
> - Daniel
>
>

--=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_506_25686563.1378562027296
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">After this discussion I end up with conclusion that your s=
olution is correct one. Its simples and requare no changes in `std::stack` =
or in `std::forward_list`.<br>Another thing is that if any problems would o=
ccur it will be during compilation not in execution<br>(you cant remove any=
thing from `std::forward_list` without using this warper, therefore `size()=
` will always return correct value).<br><br>On Saturday, September 7, 2013 =
1:02:30 PM UTC+2, Daniel Kr=FCgler wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr">2013/9/7 Vlad from Moscow <span dir=3D"ltr">&lt=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Ox_v0KU=
AwVgJ">vlad....@mail.ru</a>&gt;</span><br><div><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div>What you demonstarted is not a stack. You dealt with =
a container. So there is nothing suprising that the elements are outputed i=
n the reverse order. It was your decision to use std::forward_list as a con=
tainer.&nbsp;</div>
</div></blockquote><div><br></div><div>It is not clear whose decision it wi=
ll be, because the std::stack might be used as an implementation detail of =
another template, so it the effects are very unexpected and not aware of th=
e implementer of the "outer2 template. <br>
<br>Keep also in mind that the protected member 'c' is part of the API, so =
someone who derives from stack can expect that the member functions of c re=
quired in the std::stack specification do exist. In case of your hypothetic=
al specialization of std::stack the derived template would break when tryin=
g to refer to push_back(), back(), etc.<br>
<br></div><div>I also think that your assertion that stack "is a some sort =
of an abstract class" is misleading. This type as an *adaptor* type, so lik=
e other adaptors its specification relies on a well-defined set of operatio=
ns from the adapteed type. The standard library support&nbsp; user-defined =
specializations of library templates ([namespace.std]), if specialization m=
eets the standard library requirements for the original template. This is n=
ot satisfied for std::forward_list, because the difference is observable, *=
because* the member c is part of its API.<br>
</div><div><br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div> It is the same as you would use std::list and then=
 decided to change it to std::vector and now you wonder that std::vector ha=
s no member function push_front.</div>
</div></blockquote><div><br></div><div>No, this example does not match here=
 for std::stack, because std::stack does not depend on any operation named =
push_front().<br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">
<div dir=3D"ltr"><div>&nbsp;Your example demonstrates that the specializati=
on of std::stack for std::forward_list is very useful! Because it allows to=
 output&nbsp;elements of&nbsp;a stack&nbsp;in the natural order in which th=
ey are&nbsp; stored&nbsp;in it&nbsp;that is in the order FILO.&nbsp;&nbsp;<=
/div>
</div></blockquote><div><br></div><div>Again I repeat that this can already=
 be realized by providing an adaptor of forward_list, that provides the req=
uired operations needed for std::stack. There is no reason to assume that s=
uch an adaptor would cause any time overhead. There would be a small space =
overhead to provide the size() member, but obviously this idea was accepted=
 when using std::stack based on forward_list. I also consider this kind of =
adaptor as an interesting one that is similar to reverse_iterator for itera=
tors. I'm not sure that reverse_container is the right name for it, but her=
e the rough idea of such a template:<br>
<br>template &lt;class T, class Container =3D deque&lt;T&gt; &gt;<br>class =
reverse_container {<br>public:<br>&nbsp; typedef typename Container::value_=
type value_type;<br>&nbsp; typedef typename Container::reference reference;=
<br>&nbsp; typedef typename Container::const_reference const_reference;<br>
&nbsp; typedef typename Container::size_type size_type;<br>&nbsp; typedef C=
ontainer container_type; <br>&nbsp; [..] // constructors<br></div><div>&nbs=
p; bool empty() const { return c.empty(); }<br>&nbsp; size_type size() cons=
t { return c.size(); }<br>
&nbsp; reference back() { return c.front(); }<br>&nbsp;  const_reference ba=
ck() const { return c.front(); }<br>&nbsp; <br>&nbsp; void push_back(const =
value_type&amp; x) { c.push_front(x); }<br>&nbsp; void push_back(value_type=
&amp;&amp; x) { c.push_front(std::move(x)); }<br>
&nbsp; template &lt;class... Args&gt; void emplace_back(Args&amp;&amp;... a=
rgs)<br>&nbsp; { c.emplace_front(std::forward&lt;<wbr>Args&gt;(args)...); }=
<br>&nbsp; void pop_back() { c.pop_font(); }<br>&nbsp; void swap(stack&amp;=
 s) noexcept(noexcept(swap(c, s.c)))<br>
&nbsp; { using std::swap; swap(c, s.c); }<br></div><div>private:<br></div><=
div>&nbsp; Container c; // For exposition only<br></div><div>};<br><br></di=
v><div>I'm leaving the decision open here, there are several ways to handle=
 that.<br>
</div><div><br></div></div>- Daniel<br><br></div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_506_25686563.1378562027296--

.

--=-ape4eM/dXv6e7DhgA6mc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On sab, 2013-09-07 at 06:23 -0700, Vlad from Moscow wrote:
> I think you are mistaken. Protected members are the part of the realizati=
on=20
> and also the part of realization of derived classes. It is not an=20
> interface.

That's a very unusual definition of interface.  Because client code
outside the class can use and rely on protected members, it forms part
of the boundary that outside code uses when using our class.  That's the
distinction between an interface and an implementation, and the idea
behind encapsulating the implementation so client code cannot know about
it.  An interface is a contract with outside code.  If outside code can
use something, it is (perhaps unwittingly) part of the interface.  The
implementation (while possibly implied by the interface) is free to vary
without the client code's knowledge, as long as the interface contract
is fulfilled.  Because the member "c" in std::stack is usable by client
code outside of std::stack, and because it has well-known and
well-defined semantics, it is a part of the std::stack interface.

Another way to think about it is to think about what would happen if the
symbol names were changed.  Let's take this class Foo as an example:

        class Foo {
        public:
          int bar() { return whatToReturn; }
        protected:
          void changeReturn(int i) { whatToReturn =3D i; }
        private:
          int whatToReturn =3D 0;
        };

Say Foo is part of my library libfoo.  If we were to change the name of
the public member function bar(), outside code that we have no control
over could be broken, because they may, and are allowed to, rely on it.
bar() is part of the interface, because outside code uses it.  If we
change the name of the private data member whatToReturn to myReturnValue
in all three places in the class, no one's code would be broken by this
change.  whatToReturn is not part of the interface, because no outside
code can possibly use it.  If we change the name of protected member
function changeReturn(), though, outside code that we have no control
over could also be broken, because they may, and are allowed to, rely on
it when they derive from our class.  changeReturn() is part of the
interface, because even though it's not public, we are allowing outside
code access to it.  If one of libfoo's clients writes the class:

        class SneakyFoo : public Foo {
        public:
          void sneaky() { changeReturn(-1); }
        };

and we change the name of the protected member function changeReturn(),
this code will break.  But if we change the name of whatToReturn as I
described above, SneakyFoo still works just fine.

Often protected members are called the "protected interface" of a class,
because they still form part of the interface, even though they aren't
public.

So in this case, yes, "Container c" is part of the interface=E2=80=94the
protected interface, yes, but still the interface=E2=80=94of std::stack.

Cheers,
Patrick Niedzielski

--=-ape4eM/dXv6e7DhgA6mc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAABAgAGBQJSKzARAAoJECyWbNe9EHCfeZYH/21EBgJ+YjMQMbDHeztUUCrz
z0gMr4fWl7qlzs1LiVg7hx88+DMF65lXCZrNUfxhT+XiJQpJtYIZuCsT8rYzzlQC
ztFcKpRjX4K4l/gK9/cptk/om0il9snxN7O9iSWVBYI7UYdarUGVvctzcJbgbLkB
LZYbd8EcIREoxc8E0eXOuKtJy8p0Irl1oYYB4M3LyA4CyaUhT4VsJj4Bfzaog2Vi
sEKMjkx2L5wBkdZUrgcijT960VqGOhh8fmrAe28fKZ2jh5HHpbA16GIn+NdYIFkr
P9z7vCivXHIfutBQdhSi/eplDbJN0i7bgb+WVJngfZQS0UkYrzG9AL3Yy6J3DM0=
=Mm+C
-----END PGP SIGNATURE-----

--=-ape4eM/dXv6e7DhgA6mc--


.

------=_Part_305_32329549.1378562478342
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Well, and what is your suggestion relative to size()?

=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=81=D0=B5=D0=BD=D1=82=D1=
=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3., 17:53:47 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C=20
inkwizyt...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

> After this discussion I end up with conclusion that your solution is=20
> correct one. Its simples and requare no changes in `std::stack` or in=20
> `std::forward_list`.
> Another thing is that if any problems would occur it will be during=20
> compilation not in execution
> (you cant remove anything from `std::forward_list` without using this=20
> warper, therefore `size()` will always return correct value).
>
> On Saturday, September 7, 2013 1:02:30 PM UTC+2, Daniel Kr=C3=BCgler wrot=
e:
>>
>> 2013/9/7 Vlad from Moscow <vlad....@mail.ru>
>>
>>> What you demonstarted is not a stack. You dealt with a container. So=20
>>> there is nothing suprising that the elements are outputed in the revers=
e=20
>>> order. It was your decision to use std::forward_list as a container.=20
>>>
>>
>> It is not clear whose decision it will be, because the std::stack might=
=20
>> be used as an implementation detail of another template, so it the effec=
ts=20
>> are very unexpected and not aware of the implementer of the "outer2=20
>> template.=20
>>
>> Keep also in mind that the protected member 'c' is part of the API, so=
=20
>> someone who derives from stack can expect that the member functions of c=
=20
>> required in the std::stack specification do exist. In case of your=20
>> hypothetical specialization of std::stack the derived template would bre=
ak=20
>> when trying to refer to push_back(), back(), etc.
>>
>> I also think that your assertion that stack "is a some sort of an=20
>> abstract class" is misleading. This type as an *adaptor* type, so like=
=20
>> other adaptors its specification relies on a well-defined set of operati=
ons=20
>> from the adapteed type. The standard library support  user-defined=20
>> specializations of library templates ([namespace.std]), if specializatio=
n=20
>> meets the standard library requirements for the original template. This =
is=20
>> not satisfied for std::forward_list, because the difference is observabl=
e,=20
>> *because* the member c is part of its API.
>>
>> =20
>>
>>> It is the same as you would use std::list and then decided to change it=
=20
>>> to std::vector and now you wonder that std::vector has no member functi=
on=20
>>> push_front.
>>>
>>
>> No, this example does not match here for std::stack, because std::stack=
=20
>> does not depend on any operation named push_front().
>> =20
>>
>>>  Your example demonstrates that the specialization of std::stack for=20
>>> std::forward_list is very useful! Because it allows to output elements =
of a=20
>>> stack in the natural order in which they are  stored in it that is in t=
he=20
>>> order FILO. =20
>>>
>>
>> Again I repeat that this can already be realized by providing an adaptor=
=20
>> of forward_list, that provides the required operations needed for=20
>> std::stack. There is no reason to assume that such an adaptor would caus=
e=20
>> any time overhead. There would be a small space overhead to provide the=
=20
>> size() member, but obviously this idea was accepted when using std::stac=
k=20
>> based on forward_list. I also consider this kind of adaptor as an=20
>> interesting one that is similar to reverse_iterator for iterators. I'm n=
ot=20
>> sure that reverse_container is the right name for it, but here the rough=
=20
>> idea of such a template:
>>
>> template <class T, class Container =3D deque<T> >
>> class reverse_container {
>> public:
>>   typedef typename Container::value_type value_type;
>>   typedef typename Container::reference reference;
>>   typedef typename Container::const_reference const_reference;
>>   typedef typename Container::size_type size_type;
>>   typedef Container container_type;=20
>>   [..] // constructors
>>   bool empty() const { return c.empty(); }
>>   size_type size() const { return c.size(); }
>>   reference back() { return c.front(); }
>>   const_reference back() const { return c.front(); }
>>  =20
>>   void push_back(const value_type& x) { c.push_front(x); }
>>   void push_back(value_type&& x) { c.push_front(std::move(x)); }
>>   template <class... Args> void emplace_back(Args&&... args)
>>   { c.emplace_front(std::forward<Args>(args)...); }
>>   void pop_back() { c.pop_font(); }
>>   void swap(stack& s) noexcept(noexcept(swap(c, s.c)))
>>   { using std::swap; swap(c, s.c); }
>> private:
>>   Container c; // For exposition only
>> };
>>
>> I'm leaving the decision open here, there are several ways to handle tha=
t.
>>
>> - Daniel
>>
>>

--=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_305_32329549.1378562478342
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Well, and what is your suggestion&nbsp;relative to&nb=
sp;size()?</div><div><br>=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=
=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013&nbsp;=D0=B3., 17:53:47 U=
TC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=
=8C inkwizyt...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div dir=3D"ltr">After this discussion I end u=
p with conclusion that your solution is correct one. Its simples and requar=
e no changes in `std::stack` or in `std::forward_list`.<br>Another thing is=
 that if any problems would occur it will be during compilation not in exec=
ution<br>(you cant remove anything from `std::forward_list` without using t=
his warper, therefore `size()` will always return correct value).<br><br>On=
 Saturday, September 7, 2013 1:02:30 PM UTC+2, Daniel Kr=C3=BCgler wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding=
-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; =
border-left-style: solid;"><div dir=3D"ltr">2013/9/7 Vlad from Moscow <span=
 dir=3D"ltr">&lt;<a>vlad....@mail.ru</a>&gt;</span><br><div><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;">
<div dir=3D"ltr"><div>What you demonstarted is not a stack. You dealt with =
a container. So there is nothing suprising that the elements are outputed i=
n the reverse order. It was your decision to use std::forward_list as a con=
tainer.&nbsp;</div>
</div></blockquote><div><br></div><div>It is not clear whose decision it wi=
ll be, because the std::stack might be used as an implementation detail of =
another template, so it the effects are very unexpected and not aware of th=
e implementer of the "outer2 template. <br>
<br>Keep also in mind that the protected member 'c' is part of the API, so =
someone who derives from stack can expect that the member functions of c re=
quired in the std::stack specification do exist. In case of your hypothetic=
al specialization of std::stack the derived template would break when tryin=
g to refer to push_back(), back(), etc.<br>
<br></div><div>I also think that your assertion that stack "is a some sort =
of an abstract class" is misleading. This type as an *adaptor* type, so lik=
e other adaptors its specification relies on a well-defined set of operatio=
ns from the adapteed type. The standard library support&nbsp; user-defined =
specializations of library templates ([namespace.std]), if specialization m=
eets the standard library requirements for the original template. This is n=
ot satisfied for std::forward_list, because the difference is observable, *=
because* the member c is part of its API.<br>
</div><div><br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 2=
04); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><d=
iv> It is the same as you would use std::list and then decided to change it=
 to std::vector and now you wonder that std::vector has no member function =
push_front.</div>
</div></blockquote><div><br></div><div>No, this example does not match here=
 for std::stack, because std::stack does not depend on any operation named =
push_front().<br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div dir=3D"ltr"><div>&nbsp;Your example demonstrates that the specializati=
on of std::stack for std::forward_list is very useful! Because it allows to=
 output&nbsp;elements of&nbsp;a stack&nbsp;in the natural order in which th=
ey are&nbsp; stored&nbsp;in it&nbsp;that is in the order FILO.&nbsp;&nbsp;<=
/div>
</div></blockquote><div><br></div><div>Again I repeat that this can already=
 be realized by providing an adaptor of forward_list, that provides the req=
uired operations needed for std::stack. There is no reason to assume that s=
uch an adaptor would cause any time overhead. There would be a small space =
overhead to provide the size() member, but obviously this idea was accepted=
 when using std::stack based on forward_list. I also consider this kind of =
adaptor as an interesting one that is similar to reverse_iterator for itera=
tors. I'm not sure that reverse_container is the right name for it, but her=
e the rough idea of such a template:<br>
<br>template &lt;class T, class Container =3D deque&lt;T&gt; &gt;<br>class =
reverse_container {<br>public:<br>&nbsp; typedef typename Container::value_=
type value_type;<br>&nbsp; typedef typename Container::reference reference;=
<br>&nbsp; typedef typename Container::const_reference const_reference;<br>
&nbsp; typedef typename Container::size_type size_type;<br>&nbsp; typedef C=
ontainer container_type; <br>&nbsp; [..] // constructors<br></div><div>&nbs=
p; bool empty() const { return c.empty(); }<br>&nbsp; size_type size() cons=
t { return c.size(); }<br>
&nbsp; reference back() { return c.front(); }<br>&nbsp;  const_reference ba=
ck() const { return c.front(); }<br>&nbsp; <br>&nbsp; void push_back(const =
value_type&amp; x) { c.push_front(x); }<br>&nbsp; void push_back(value_type=
&amp;&amp; x) { c.push_front(std::move(x)); }<br>
&nbsp; template &lt;class... Args&gt; void emplace_back(Args&amp;&amp;... a=
rgs)<br>&nbsp; { c.emplace_front(std::forward&lt;<wbr>Args&gt;(args)...); }=
<br>&nbsp; void pop_back() { c.pop_font(); }<br>&nbsp; void swap(stack&amp;=
 s) noexcept(noexcept(swap(c, s.c)))<br>
&nbsp; { using std::swap; swap(c, s.c); }<br></div><div>private:<br></div><=
div>&nbsp; Container c; // For exposition only<br></div><div>};<br><br></di=
v><div>I'm leaving the decision open here, there are several ways to handle=
 that.<br>
</div><div><br></div></div>- Daniel<br><br></div></div>
</blockquote></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_305_32329549.1378562478342--

.

------=_Part_571_22507046.1378562828394
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

Again you are mistaken. The client code knows nothing about protected=20
members of your class. It relies only on the interface you provided. You=20
confuse the realization with the interface.=20

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 17:54:25 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 06:23 -0700, Vlad from Moscow wrote:=20
> > I think you are mistaken. Protected members are the part of the=20
> realization=20
> > and also the part of realization of derived classes. It is not an=20
> > interface.=20
>
> That's a very unusual definition of interface.  Because client code=20
> outside the class can use and rely on protected members, it forms part=20
> of the boundary that outside code uses when using our class.  That's the=
=20
> distinction between an interface and an implementation, and the idea=20
> behind encapsulating the implementation so client code cannot know about=
=20
> it.  An interface is a contract with outside code.  If outside code can=
=20
> use something, it is (perhaps unwittingly) part of the interface.  The=20
> implementation (while possibly implied by the interface) is free to vary=
=20
> without the client code's knowledge, as long as the interface contract=20
> is fulfilled.  Because the member "c" in std::stack is usable by client=
=20
> code outside of std::stack, and because it has well-known and=20
> well-defined semantics, it is a part of the std::stack interface.=20
>
> Another way to think about it is to think about what would happen if the=
=20
> symbol names were changed.  Let's take this class Foo as an example:=20
>
>         class Foo {=20
>         public:=20
>           int bar() { return whatToReturn; }=20
>         protected:=20
>           void changeReturn(int i) { whatToReturn =3D i; }=20
>         private:=20
>           int whatToReturn =3D 0;=20
>         };=20
>
> Say Foo is part of my library libfoo.  If we were to change the name of=
=20
> the public member function bar(), outside code that we have no control=20
> over could be broken, because they may, and are allowed to, rely on it.=
=20
> bar() is part of the interface, because outside code uses it.  If we=20
> change the name of the private data member whatToReturn to myReturnValue=
=20
> in all three places in the class, no one's code would be broken by this=
=20
> change.  whatToReturn is not part of the interface, because no outside=20
> code can possibly use it.  If we change the name of protected member=20
> function changeReturn(), though, outside code that we have no control=20
> over could also be broken, because they may, and are allowed to, rely on=
=20
> it when they derive from our class.  changeReturn() is part of the=20
> interface, because even though it's not public, we are allowing outside=
=20
> code access to it.  If one of libfoo's clients writes the class:=20
>
>         class SneakyFoo : public Foo {=20
>         public:=20
>           void sneaky() { changeReturn(-1); }=20
>         };=20
>
> and we change the name of the protected member function changeReturn(),=
=20
> this code will break.  But if we change the name of whatToReturn as I=20
> described above, SneakyFoo still works just fine.=20
>
> Often protected members are called the "protected interface" of a class,=
=20
> because they still form part of the interface, even though they aren't=20
> public.=20
>
> So in this case, yes, "Container c" is part of the interface--the=20
> protected interface, yes, but still the interface--of std::stack.=20
>
> Cheers,=20
> Patrick Niedzielski=20
>

--=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_571_22507046.1378562828394
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Again you are mistaken. The client code knows nothing=
 about protected members of your class. It relies only on the interface you=
 provided. You confuse the realization with the interface. </div><div><br>=
=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=C7., 17:54:25 =
UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Patrick M. Niedzielski =CE=C1=D0=
=C9=D3=C1=CC:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">On sab, 2013-09-07 at 06:23=
 -0700, Vlad from Moscow wrote:
<br>&gt; I think you are mistaken. Protected members are the part of the re=
alization=20
<br>&gt; and also the part of realization of derived classes. It is not an=
=20
<br>&gt; interface.
<br>
<br>That's a very unusual definition of interface. &nbsp;Because client cod=
e
<br>outside the class can use and rely on protected members, it forms part
<br>of the boundary that outside code uses when using our class. &nbsp;That=
's the
<br>distinction between an interface and an implementation, and the idea
<br>behind encapsulating the implementation so client code cannot know abou=
t
<br>it. &nbsp;An interface is a contract with outside code. &nbsp;If outsid=
e code can
<br>use something, it is (perhaps unwittingly) part of the interface. &nbsp=
;The
<br>implementation (while possibly implied by the interface) is free to var=
y
<br>without the client code's knowledge, as long as the interface contract
<br>is fulfilled. &nbsp;Because the member "c" in std::stack is usable by c=
lient
<br>code outside of std::stack, and because it has well-known and
<br>well-defined semantics, it is a part of the std::stack interface.
<br>
<br>Another way to think about it is to think about what would happen if th=
e
<br>symbol names were changed. &nbsp;Let's take this class Foo as an exampl=
e:
<br>
<br>&nbsp; &nbsp; &nbsp; &nbsp; class Foo {
<br>&nbsp; &nbsp; &nbsp; &nbsp; public:
<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; int bar() { return whatToReturn; }
<br>&nbsp; &nbsp; &nbsp; &nbsp; protected:
<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; void changeReturn(int i) { whatToRet=
urn =3D i; }
<br>&nbsp; &nbsp; &nbsp; &nbsp; private:
<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; int whatToReturn =3D 0;
<br>&nbsp; &nbsp; &nbsp; &nbsp; };
<br>
<br>Say Foo is part of my library libfoo. &nbsp;If we were to change the na=
me of
<br>the public member function bar(), outside code that we have no control
<br>over could be broken, because they may, and are allowed to, rely on it.
<br>bar() is part of the interface, because outside code uses it. &nbsp;If =
we
<br>change the name of the private data member whatToReturn to myReturnValu=
e
<br>in all three places in the class, no one's code would be broken by this
<br>change. &nbsp;whatToReturn is not part of the interface, because no out=
side
<br>code can possibly use it. &nbsp;If we change the name of protected memb=
er
<br>function changeReturn(), though, outside code that we have no control
<br>over could also be broken, because they may, and are allowed to, rely o=
n
<br>it when they derive from our class. &nbsp;changeReturn() is part of the
<br>interface, because even though it's not public, we are allowing outside
<br>code access to it. &nbsp;If one of libfoo's clients writes the class:
<br>
<br>&nbsp; &nbsp; &nbsp; &nbsp; class SneakyFoo : public Foo {
<br>&nbsp; &nbsp; &nbsp; &nbsp; public:
<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; void sneaky() { changeReturn(-1); }
<br>&nbsp; &nbsp; &nbsp; &nbsp; };
<br>
<br>and we change the name of the protected member function changeReturn(),
<br>this code will break. &nbsp;But if we change the name of whatToReturn a=
s I
<br>described above, SneakyFoo still works just fine.
<br>
<br>Often protected members are called the "protected interface" of a class=
,
<br>because they still form part of the interface, even though they aren't
<br>public.
<br>
<br>So in this case, yes, "Container c" is part of the interface&mdash;the
<br>protected interface, yes, but still the interface&mdash;of std::stack.
<br>
<br>Cheers,
<br>Patrick Niedzielski
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_571_22507046.1378562828394--

.

--=-2X6d09uEo99czLW7sE/N
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On sab, 2013-09-07 at 07:07 -0700, Vlad from Moscow wrote:
> Again you are mistaken. The client code knows nothing about protected=20
> members of your class. It relies only on the interface you provided. 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 just
claiming that I'm wrong without giving any reasoning.

Best,
Patrick

--=-2X6d09uEo99czLW7sE/N
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAABAgAGBQJSKzOIAAoJECyWbNe9EHCft2QIALJRv6Aj7gk/SQsecS5ZOdjy
la2J2p9nhOEMGasebnnUtkeskrnZ5K3bDJbxImPLiUDmQ3MFseDNkd8J1eJPujWS
2i+maCiNrcBMTtrPyUBb5F1xk25mcKMk2f5ld4LD+5Qv0fZfM/UbjMILekcSsPOh
jIJpGOQtHQCPTkaJ7ZWYJCAtVxNOjU3ZCZUV4UsMNuvHUUbNQ30LhV5KSVVnBNxL
r4TIhDBgnqZdqRhTEgs1nWMnzPUCu/loMxwHS/IdqETUp5Q2k3vts6RJC/Aobx6F
PgSEb98amw6wrS1ozvOmEYyD3RFaXO9gmvdzeGrW1txXAIb4bmv2ysoQ5F503YE=
=1aPW
-----END PGP SIGNATURE-----

--=-2X6d09uEo99czLW7sE/N--


.

------=_Part_511_14671800.1378563303677
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Warper will count it. this will be simple operations like ++ and --, as=20
container in warper is private, problems that somebody remove elements cant=
=20
happen.=20

On Saturday, September 7, 2013 4:01:18 PM UTC+2, Vlad from Moscow wrote:
>
> Well, and what is your suggestion relative to size()?
>
> =D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=81=D0=B5=D0=BD=D1=82=D1=
=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3., 17:53:47 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C=20
> inkwizyt...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
>> After this discussion I end up with conclusion that your solution is=20
>> correct one. Its simples and requare no changes in `std::stack` or in=20
>> `std::forward_list`.
>> Another thing is that if any problems would occur it will be during=20
>> compilation not in execution
>> (you cant remove anything from `std::forward_list` without using this=20
>> warper, therefore `size()` will always return correct value).
>>
>> On Saturday, September 7, 2013 1:02:30 PM UTC+2, Daniel Kr=C3=BCgler wro=
te:
>>
>>> It is not clear whose decision it will be, because the std::stack might=
=20
>>> be used as an implementation detail of another template, so it the effe=
cts=20
>>> are very unexpected and not aware of the implementer of the "outer2=20
>>> template.=20
>>>
>>> Keep also in mind that the protected member 'c' is part of the API, so=
=20
>>> someone who derives from stack can expect that the member functions of =
c=20
>>> required in the std::stack specification do exist. In case of your=20
>>> hypothetical specialization of std::stack the derived template would br=
eak=20
>>> when trying to refer to push_back(), back(), etc.
>>>
>>> I also think that your assertion that stack "is a some sort of an=20
>>> abstract class" is misleading. This type as an *adaptor* type, so like=
=20
>>> other adaptors its specification relies on a well-defined set of operat=
ions=20
>>> from the adapteed type. The standard library support  user-defined=20
>>> specializations of library templates ([namespace.std]), if specializati=
on=20
>>> meets the standard library requirements for the original template. This=
 is=20
>>> not satisfied for std::forward_list, because the difference is observab=
le,=20
>>> *because* the member c is part of its API.
>>> =20
>>>
>>> - Daniel
>>>
>>>

--=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_511_14671800.1378563303677
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Warper will count it. this will be simple operations like =
++ and --, as container in warper is private, problems that somebody remove=
 elements cant happen. <br><br>On Saturday, September 7, 2013 4:01:18 PM UT=
C+2, Vlad from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div>Well, and what is your suggestion&nbsp;relative to&nbsp=
;size()?</div><div><br>=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=81=
=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013&nbsp;=D0=B3., 17:53:47 UTC+=
4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C =
<a>inkwizyt...@gmail.com</a> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padd=
ing-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;borde=
r-left-style:solid"><div dir=3D"ltr">After this discussion I end up with co=
nclusion that your solution is correct one. Its simples and requare no chan=
ges in `std::stack` or in `std::forward_list`.<br>Another thing is that if =
any problems would occur it will be during compilation not in execution<br>=
(you cant remove anything from `std::forward_list` without using this warpe=
r, therefore `size()` will always return correct value).<br><br>On Saturday=
, September 7, 2013 1:02:30 PM UTC+2, Daniel Kr=C3=BCgler wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1=
ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-sty=
le:solid"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>It is not c=
lear whose decision it will be, because the std::stack might be used as an =
implementation detail of another template, so it the effects are very unexp=
ected and not aware of the implementer of the "outer2 template. <br>
<br>Keep also in mind that the protected member 'c' is part of the API, so =
someone who derives from stack can expect that the member functions of c re=
quired in the std::stack specification do exist. In case of your hypothetic=
al specialization of std::stack the derived template would break when tryin=
g to refer to push_back(), back(), etc.<br>
<br></div><div>I also think that your assertion that stack "is a some sort =
of an abstract class" is misleading. This type as an *adaptor* type, so lik=
e other adaptors its specification relies on a well-defined set of operatio=
ns from the adapteed type. The standard library support&nbsp; user-defined =
specializations of library templates ([namespace.std]), if specialization m=
eets the standard library requirements for the original template. This is n=
ot satisfied for std::forward_list, because the difference is observable, *=
because* the member c is part of its API.<br>
</div><div>&nbsp;</div><div><br></div></div>- Daniel<br><br></div></div>
</blockquote></div></blockquote></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_511_14671800.1378563303677--

.

------=_Part_471_31798518.1378563481881
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

It uses the realization of its base class. Protected members mean that the=
=20
base class delegates the realization to its derived classes because it=20
trust them and nothing more. In your example the derived class used=20
this realization to build its interface.=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. Yo=
u=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
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_471_31798518.1378563481881
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>It uses the realization of its base class. Protected =
members mean that the base class delegates the realization to its derived c=
lasses because it trust them and nothing more. In your example the derived =
class used this&nbsp;realization&nbsp;to build its interface.&nbsp;</div><d=
iv><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=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:</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;">On sab, 2013-09-07=
 at 07:07 -0700, Vlad from Moscow wrote:
<br>&gt; Again you are mistaken. The client code knows nothing about protec=
ted=20
<br>&gt; members of your class. It relies only on the interface you provide=
d. You=20
<br>&gt; confuse the realization with the interface.=20
<br>
<br>I'm sorry, I don't see how I haven't shown that the client code
<br>SneakyFoo that a user of my library would write knows nothing about
<br>Foo's protected member, especially since it uses the member.
<br>
<br>I don't wish to continue this discussion any further, as you don't seem
<br>to be addressing or trying to understand my points, and instead are jus=
t
<br>claiming that I'm wrong without giving any reasoning.
<br>
<br>Best,
<br>Patrick
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_471_31798518.1378563481881--

.

------=_Part_519_11131011.1378564100298
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

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. Yo=
u=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
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_519_11131011.1378564100298
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I even&nbsp;could write a more simple example.to demo=
nstrate your wrong conclusions. For example</div><div>&nbsp;</div><div>clas=
s A</div><div>{</div><div>private: </div><div>&nbsp;&nbsp; int x;</div><div=
>public:</div><div>&nbsp;&nbsp; A( int i =3D 0 ) : x( i ) {}</div><div>&nbs=
p;&nbsp; int get() const { return x; }</div><div>};</div><div>&nbsp;</div><=
div>Does it mean that if function get() uses private member x that x is the=
 interface of the class?!</div><div>&nbsp;&nbsp; </div><div>&nbsp;</div><di=
v><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=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:</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;">On sab, 2013-09-07 at=
 07:07 -0700, Vlad from Moscow wrote:
<br>&gt; Again you are mistaken. The client code knows nothing about protec=
ted=20
<br>&gt; members of your class. It relies only on the interface you provide=
d. You=20
<br>&gt; confuse the realization with the interface.=20
<br>
<br>I'm sorry, I don't see how I haven't shown that the client code
<br>SneakyFoo that a user of my library would write knows nothing about
<br>Foo's protected member, especially since it uses the member.
<br>
<br>I don't wish to continue this discussion any further, as you don't seem
<br>to be addressing or trying to understand my points, and instead are jus=
t
<br>claiming that I'm wrong without giving any reasoning.
<br>
<br>Best,
<br>Patrick
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_519_11131011.1378564100298--

.

------=_Part_523_26683975.1378564869737
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

One more protected members mean that base class and its derived classes=20
share the common  realization.
=20

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 18:28:20 UTC+4=
 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Vlad from Moscow=20
=CE=C1=D0=C9=D3=C1=CC:

> 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
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_523_26683975.1378564869737
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>One more protected members mean that base class and i=
ts derived classes share the common &nbsp;realization.</div><div>&nbsp;</di=
v><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=C7.=
, 18:28:20 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Vlad from Moscow =CE=
=C1=D0=C9=D3=C1=CC:</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div=
>I even&nbsp;could write a more simple <a href=3D"http://example.to" target=
=3D"_blank">example.to</a> demonstrate your wrong conclusions. For example<=
/div><div>&nbsp;</div><div>class A</div><div>{</div><div>private: </div><di=
v>&nbsp;&nbsp; int x;</div><div>public:</div><div>&nbsp;&nbsp; A( int i =3D=
 0 ) : x( i ) {}</div><div>&nbsp;&nbsp; int get() const { return x; }</div>=
<div>};</div><div>&nbsp;</div><div>Does it mean that if function get() uses=
 private member x that x is the interface of the class?!</div><div>&nbsp;&n=
bsp; </div><div>&nbsp;</div><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=
=D1=C2=D2=D1 2013&nbsp;=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:</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">On sab, 2013-09-07 at 07:07 -0700, Vlad from Moscow wrote:
<br>&gt; Again you are mistaken. The client code knows nothing about protec=
ted=20
<br>&gt; members of your class. It relies only on the interface you provide=
d. You=20
<br>&gt; confuse the realization with the interface.=20
<br>
<br>I'm sorry, I don't see how I haven't shown that the client code
<br>SneakyFoo that a user of my library would write knows nothing about
<br>Foo's protected member, especially since it uses the member.
<br>
<br>I don't wish to continue this discussion any further, as you don't seem
<br>to be addressing or trying to understand my points, and instead are jus=
t
<br>claiming that I'm wrong without giving any reasoning.
<br>
<br>Best,
<br>Patrick
<br></blockquote></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_523_26683975.1378564869737--

.

------=_Part_0_1378565504095
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 interfac=
e of that class. (e.g. something like "push_back increases size by 1" is pa=
rt of vector's interface, even though there is no way to express that const=
raint in the language)

External code can rely on the protected container c by deriving from stack.=
 Therefore, it is part of the interface. External code can not depend on th=
e 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.moscow@mail.ru>
To: <std-proposals@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 conclusi=
ons. For example

class A
{
private:=20
int x;
public:
A( int i =3D 0 ) : x( i ) {}
int get() const { return x; }
};

Does it mean that if function get() uses private member x that x is the int=
erface of the class?!



=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 protected=20

> members of your class. It relies only on the interface you provided. 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 just

claiming that I'm wrong without giving any reasoning.



Best,

Patrick






--=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/.

--=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_0_1378565504095
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div style=3D"font-size: 12pt; font-family: Calibri,sans-serif;"><div>No, b=
ecause x is private.</div><div><br></div><div>If it is possible for code ex=
ternal to the class to depend on some behavior or member of a class, than t=
hat behavior or member is part of the interface of that class. (e.g. someth=
ing like "push_back increases size by 1" is part of vector's interface, eve=
n though there is no way to express that constraint in the language)</div><=
div><br></div><div>External code can rely on the protected container c by d=
eriving from stack. Therefore, it is part of the interface. External code c=
an not depend on the member x in your example, because it is private. There=
fore it is not part of the interface.</div><div><br></div><div>Sent from a =
touchscreen. Please excuse the brevity and tpyos.</div><br><div id=3D"htc_h=
eader">----- Reply message -----<br>From: &quot;Vlad from Moscow&quot; &lt;=
vlad.moscow@mail.ru&gt;<br>To: &lt;std-proposals@isocpp.org&gt;<br>Subject:=
 [std-proposals] Specialization of std::stack for std::forward_list<br>Date=
: Sat, Sep 7, 2013 7:28 AM</div></div><br><div dir=3D"ltr"><div>I even&nbsp=
;could write a more simple example.to demonstrate your wrong conclusions. F=
or example</div><div>&nbsp;</div><div>class A</div><div>{</div><div>private=
: </div><div>&nbsp;&nbsp; int x;</div><div>public:</div><div>&nbsp;&nbsp; A=
( int i =3D 0 ) : x( i ) {}</div><div>&nbsp;&nbsp; int get() const { return=
 x; }</div><div>};</div><div>&nbsp;</div><div>Does it mean that if function=
 get() uses private member x that x is the interface of the class?!</div><d=
iv>&nbsp;&nbsp; </div><div>&nbsp;</div><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =
=D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=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:</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-le=
ft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bor=
der-left-style: solid;">On sab, 2013-09-07 at 07:07 -0700, Vlad from Moscow=
 wrote:
<br>&gt; Again you are mistaken. The client code knows nothing about protec=
ted=20
<br>&gt; members of your class. It relies only on the interface you provide=
d. You=20
<br>&gt; confuse the realization with the interface.=20
<br>
<br>I'm sorry, I don't see how I haven't shown that the client code
<br>SneakyFoo that a user of my library would write knows nothing about
<br>Foo's protected member, especially since it uses the member.
<br>
<br>I don't wish to continue this discussion any further, as you don't seem
<br>to be addressing or trying to understand my points, and instead are jus=
t
<br>claiming that I'm wrong without giving any reasoning.
<br>
<br>Best,
<br>Patrick
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_0_1378565504095--


.

--089e01176cf716ddfa04e5cc55f2
Content-Type: text/plain; charset=ISO-8859-1

On 7 September 2013 17:28, Vlad from Moscow <vlad.moscow@mail.ru> wrote:

> I even could write a more simple example.to demonstrate your wrong
> conclusions. For example
>
> class A
> {
> private:
>    int x;
> public:
>    A( int i = 0 ) : x( i ) {}
>    int get() const { return x; }
> };
>
> Does it mean that if function get() uses private member x that x is the
> interface of the class?!
>
>
>
Whether get() uses a private member is irrelevant. Data members, including
private ones,
are part of the physical interface of that class. Read the Lakosbook
(http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620)
and be seriously illuminated.

--

---
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/.

--089e01176cf716ddfa04e5cc55f2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 7 September 2013 17:28, Vlad from Moscow <span dir=3D"ltr">&lt;<=
a href=3D"mailto:vlad.moscow@mail.ru" target=3D"_blank">vlad.moscow@mail.ru=
</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I e=
ven=A0could write a more simple <a href=3D"http://example.to" target=3D"_bl=
ank">example.to</a> demonstrate your wrong conclusions. For example</div>
<div>=A0</div><div>class A</div><div>{</div><div>private: </div><div>=A0=A0=
 int x;</div><div>public:</div><div>=A0=A0 A( int i =3D 0 ) : x( i ) {}</di=
v><div>=A0=A0 int get() const { return x; }</div><div>};</div><div>=A0</div=
><div>Does it mean that if function get() uses private member x that x is t=
he interface of the class?!</div>
<div><br><br></div></div></blockquote><div><br></div><div>Whether get() use=
s a private member is irrelevant. Data members, including private ones,<br>=
are part of the physical interface of that class. Read the Lakosbook<br>
(<a href=3D"http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp=
/0201633620">http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/d=
p/0201633620</a>)<br></div><div>and be seriously illuminated. <br></div></d=
iv>
<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01176cf716ddfa04e5cc55f2--

.

------=_Part_643_33022101.1378567235277
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

First of all I do not know what is the "physical interface". You can invent=
=20
many terms but they have nothing common the original meanings of the=20
interface and realization. Private and protected members of a class are its=
=20
realization not its interface. Protected members is a means to share the=20
realization (not interface) with derived classes. With the same success you=
=20
couls say that private members are "physical interface" because friend=20
functions uses private and protected members of the befriended class.
=20
In fact what you are calling "physical interface" is nothing more than a=20
realization of the class.

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 18:54:30 UTC+4=
 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Ville Voutilainen=20
=CE=C1=D0=C9=D3=C1=CC:

>
>
>
> On 7 September 2013 17:28, Vlad from Moscow <vlad....@mail.ru<javascript:=
>
> > wrote:
>
>> 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?!
>>
>>
>>
> Whether get() uses a private member is irrelevant. Data members, includin=
g=20
> private ones,
> are part of the physical interface of that class. Read the Lakosbook
> (
> http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/020163362=
0
> )
> and be seriously illuminated.=20
>
>

--=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_643_33022101.1378567235277
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>First of all I do not know what is the "physical inte=
rface". You can invent many terms but they have nothing common the original=
 meanings of the interface and realization. Private and protected members o=
f a class are its realization not its interface. Protected members is a mea=
ns to share the realization (not interface) with derived classes. With the =
same success you couls say that private members are "physical interface" be=
cause friend functions uses private and protected members of the befriended=
 class.</div><div>&nbsp;</div><div>In fact what you are calling "physical i=
nterface" is nothing more than a realization of the class.</div><div><br>=
=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=C7., 18:54:30 =
UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Ville Voutilainen =CE=C1=D0=C9=
=D3=C1=CC:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br><div><br>=
<br><div class=3D"gmail_quote">On 7 September 2013 17:28, Vlad from Moscow =
<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"af4cxP-fnH4J">vlad....@mail.ru</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div dir=3D"ltr"><div>I even&nbsp;could write =
a more simple <a href=3D"http://example.to" target=3D"_blank">example.to</a=
> demonstrate your wrong conclusions. For example</div>
<div>&nbsp;</div><div>class A</div><div>{</div><div>private: </div><div>&nb=
sp;&nbsp; int x;</div><div>public:</div><div>&nbsp;&nbsp; A( int i =3D 0 ) =
: x( i ) {}</div><div>&nbsp;&nbsp; int get() const { return x; }</div><div>=
};</div><div>&nbsp;</div><div>Does it mean that if function get() uses priv=
ate member x that x is the interface of the class?!</div>
<div><br><br></div></div></blockquote><div><br></div><div>Whether get() use=
s a private member is irrelevant. Data members, including private ones,<br>=
are part of the physical interface of that class. Read the Lakosbook<br>
(<a href=3D"http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp=
/0201633620" target=3D"_blank">http://www.amazon.com/Large-<wbr>Scale-Softw=
are-Design-John-<wbr>Lakos/dp/0201633620</a>)<br></div><div>and be seriousl=
y illuminated. <br></div></div>
<br></div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_643_33022101.1378567235277--

.

------=_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" <vlad....@mail.ru <javascript:>>
> To: <std-pr...@isocpp.org <javascript:>>
> 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 <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> 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

<div dir=3D"ltr"><div>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><div>&nbsp;</div><=
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. :)]</div><div>&nbsp;</div><div>It is totally wrong approach.</div><div=
><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=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:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div style=3D"font-family: Cal=
ibri,sans-serif; font-size: 12pt;"><div>No, because x is private.</div><div=
><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><div>Sent from a touchscreen. Please excuse the=
 brevity and tpyos.</div><br><div>----- Reply message -----<br>From: "Vlad =
from Moscow" &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"B_JaIqSu1l0J">vlad....@mail.ru</a>&gt;<br>To: &lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"B_JaIqSu1l0J">std-pr...@=
isocpp.org</a>&gt;<br>Subject: [std-proposals] Specialization of std::stack=
 for std::forward_list<br>Date: Sat, Sep 7, 2013 7:28 AM</div></div><br><di=
v dir=3D"ltr"><div>I even&nbsp;could write a more simple <a href=3D"http://=
example.to" target=3D"_blank">example.to</a> demonstrate your wrong conclus=
ions. For example</div><div>&nbsp;</div><div>class A</div><div>{</div><div>=
private: </div><div>&nbsp;&nbsp; int x;</div><div>public:</div><div>&nbsp;&=
nbsp; A( int i =3D 0 ) : x( i ) {}</div><div>&nbsp;&nbsp; int get() const {=
 return x; }</div><div>};</div><div>&nbsp;</div><div>Does it mean that if f=
unction get() uses private member x that x is the interface of the class?!<=
/div><div>&nbsp;&nbsp; </div><div>&nbsp;</div><div><br>=D3=D5=C2=C2=CF=D4=
=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=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:</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;">On sab, 2013-09-07 at 07:07 -0700, Vlad from =
Moscow wrote:
<br>&gt; Again you are mistaken. The client code knows nothing about protec=
ted=20
<br>&gt; members of your class. It relies only on the interface you provide=
d. You=20
<br>&gt; confuse the realization with the interface.=20
<br>
<br>I'm sorry, I don't see how I haven't shown that the client code
<br>SneakyFoo that a user of my library would write knows nothing about
<br>Foo's protected member, especially since it uses the member.
<br>
<br>I don't wish to continue this discussion any further, as you don't seem
<br>to be addressing or trying to understand my points, and instead are jus=
t
<br>claiming that I'm wrong without giving any reasoning.
<br>
<br>Best,
<br>Patrick
<br></blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
B_JaIqSu1l0J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"B_JaIqSu1l0J">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_676_14340099.1378567504311--

.

------=_Part_0_1378568083561
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Friend functions are part of the class  External code cannot add friends  E=
xternal code can add derived classes.

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

----- Reply message -----
From: "Vlad from Moscow" <vlad.moscow@mail.ru>
To: <std-proposals@isocpp.org>
Subject: [std-proposals] Specialization of std::stack for std::forward_list
Date: 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 c=
ourse they depend on each other. However objects of derived classes are in =
general objects 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 depend 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 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 interfac=
e of that class. (e.g. something like "push_back increases size by 1" is pa=
rt of vector's interface, even though there is no way to express that const=
raint in the language)

External code can rely on the protected container c by deriving from stack.=
 Therefore, it is part of the interface. External code can not depend on th=
e 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....@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 conclusi=
ons. For example

class A
{
private:=20
int x;
public:
A( int i =3D 0 ) : x( i ) {}
int get() const { return x; }
};

Does it mean that if function get() uses private member x that x is the int=
erface of the class?!



=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 protected=20

> members of your class. It relies only on the interface you provided. 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 just

claiming that I'm wrong without giving any reasoning.



Best,

Patrick






--=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-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.org/group/std-proposa=
ls/.






--=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/.

--=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_0_1378568083561
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div style=3D"font-size: 12pt; font-family: Calibri,sans-serif;"><div>Frien=
d functions are part of the class &nbsp;External code cannot add friends &n=
bsp;External code can add derived classes.</div><div><br></div><div>Sent fr=
om a touchscreen. Please excuse the brevity and tpyos.</div><br><div id=3D"=
htc_header">----- Reply message -----<br>From: &quot;Vlad from Moscow&quot;=
 &lt;vlad.moscow@mail.ru&gt;<br>To: &lt;std-proposals@isocpp.org&gt;<br>Sub=
ject: [std-proposals] Specialization of std::stack for std::forward_list<br=
>Date: Sat, Sep 7, 2013 8:25 AM</div></div><br><div dir=3D"ltr"><div>Protec=
ted members servers that to share the realization (not the interface) with =
its derived classes. If two classes share the common realization of course =
they depend on each other. However objects of derived classes are in genera=
l objects of base classes. So there is nothing common with interface. There=
 is common realization.</div><div>&nbsp;</div><div>Wiyth same effect you co=
uld say that private members are also an interface because friend functions=
 depend on private members of the befriended class. :)]</div><div>&nbsp;</d=
iv><div>It is totally wrong approach.</div><div><br>=D3=D5=C2=C2=CF=D4=C1, =
7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=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:</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex=
; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-lef=
t-style: solid;"><div style=3D"font-family: Calibri,sans-serif; font-size: =
12pt;"><div>No, because x is private.</div><div><br></div><div>If it is pos=
sible for code external to the class to depend on some behavior or member o=
f a class, than that behavior or member is part of the interface of that cl=
ass. (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=
 language)</div><div><br></div><div>External code 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 interface.</div><div><br></div>=
<div>Sent from a touchscreen. Please excuse the brevity and tpyos.</div><br=
><div>----- Reply message -----<br>From: "Vlad from Moscow" &lt;<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"B_JaIqSu1l0J">vlad.=
....@mail.ru</a>&gt;<br>To: &lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"B_JaIqSu1l0J">std-pr...@isocpp.org</a>&gt;<br>Subjec=
t: [std-proposals] Specialization of std::stack for std::forward_list<br>Da=
te: Sat, Sep 7, 2013 7:28 AM</div></div><br><div dir=3D"ltr"><div>I even&nb=
sp;could write a more simple <a href=3D"http://example.to" target=3D"_blank=
">example.to</a> demonstrate your wrong conclusions. For example</div><div>=
&nbsp;</div><div>class A</div><div>{</div><div>private: </div><div>&nbsp;&n=
bsp; int x;</div><div>public:</div><div>&nbsp;&nbsp; A( int i =3D 0 ) : x( =
i ) {}</div><div>&nbsp;&nbsp; int get() const { return x; }</div><div>};</d=
iv><div>&nbsp;</div><div>Does it mean that if function get() uses private m=
ember x that x is the interface of the class?!</div><div>&nbsp;&nbsp; </div=
><div>&nbsp;</div><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=
=D1 2013&nbsp;=C7., 18:09:12 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Pat=
rick M. Niedzielski =CE=C1=D0=C9=D3=C1=CC:</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-c=
olor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;=
">On sab, 2013-09-07 at 07:07 -0700, Vlad from Moscow wrote:
<br>&gt; Again you are mistaken. The client code knows nothing about protec=
ted=20
<br>&gt; members of your class. It relies only on the interface you provide=
d. You=20
<br>&gt; confuse the realization with the interface.=20
<br>
<br>I'm sorry, I don't see how I haven't shown that the client code
<br>SneakyFoo that a user of my library would write knows nothing about
<br>Foo's protected member, especially since it uses the member.
<br>
<br>I don't wish to continue this discussion any further, as you don't seem
<br>to be addressing or trying to understand my points, and instead are jus=
t
<br>claiming that I'm wrong without giving any reasoning.
<br>
<br>Best,
<br>Patrick
<br></blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
B_JaIqSu1l0J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"B_JaIqSu1l0J">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_0_1378568083561--


.

--089e0117601ff71f0704e5ccfb4c
Content-Type: text/plain; charset=ISO-8859-1

On 7 September 2013 18:20, Vlad from Moscow <vlad.moscow@mail.ru> wrote:

> First of all I do not know what is the "physical interface".
>

Feel free to educate yourself, then.


> You can invent many terms but they have nothing common the original
> meanings of the interface and realization. Private and
>

And those "original meanings" don't map to the c++ meanings 1-to-1, however
much you invent terms that you
think apply to c++.

--

---
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/.

--089e0117601ff71f0704e5ccfb4c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 7 September 2013 18:20, Vlad from Moscow <span dir=3D"ltr">&lt;<=
a href=3D"mailto:vlad.moscow@mail.ru" target=3D"_blank">vlad.moscow@mail.ru=
</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>First of all I do not =
know what is the &quot;physical interface&quot;. </div></div></blockquote><=
div>
<br></div><div>Feel free to educate yourself, then.<br>=A0<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>You can invent many terms but=
 they have nothing common the original meanings of the interface and realiz=
ation. Private and </div>
</div></blockquote><div><br></div><div>And those &quot;original meanings&qu=
ot; don&#39;t map to the c++ meanings 1-to-1, however much you invent terms=
 that you<br>think apply to c++.<br><br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0117601ff71f0704e5ccfb4c--

.

------=_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" <vlad....@mail.ru <javascript:>>
> To: <std-pr...@isocpp.org <javascript:>>
> 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" <vlad....@mail.ru>
>> To: <std-pr...@isocpp.org>
>> 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 <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> 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

<div dir=3D"ltr"><div>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. </div><div>=
&nbsp;</div><div>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&nbsp;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.</div><div>&nbsp;</div><div>=
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.</div><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=
=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=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:</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div style=3D"font-family: Calibri,sans-serif; font-size: 12pt;=
"><div>Friend functions are part of the class &nbsp;External code cannot ad=
d friends &nbsp;External code can add derived classes.</div><div><br></div>=
<div>Sent from a touchscreen. Please excuse the brevity and tpyos.</div><br=
><div>----- Reply message -----<br>From: "Vlad from Moscow" &lt;<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"oWy_EKq3UPcJ">vlad.=
....@mail.ru</a>&gt;<br>To: &lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"oWy_EKq3UPcJ">std-pr...@isocpp.org</a>&gt;<br>Subjec=
t: [std-proposals] Specialization of std::stack for std::forward_list<br>Da=
te: Sat, Sep 7, 2013 8:25 AM</div></div><br><div dir=3D"ltr"><div>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.</div><div>&nbsp;</div><div>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. :)]</div><div>&nbsp;</div>=
<div>It is totally wrong approach.</div><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =
=D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=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:</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; b=
order-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-s=
tyle: solid;"><div style=3D"font-family: Calibri,sans-serif; font-size: 12p=
t;"><div>No, because x is private.</div><div><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><di=
v>Sent from a touchscreen. Please excuse the brevity and tpyos.</div><br><d=
iv>----- Reply message -----<br>From: "Vlad from Moscow" &lt;<a>vlad....@ma=
il.ru</a>&gt;<br>To: &lt;<a>std-pr...@isocpp.org</a>&gt;<br>Subject: [std-p=
roposals] Specialization of std::stack for std::forward_list<br>Date: Sat, =
Sep 7, 2013 7:28 AM</div></div><br><div dir=3D"ltr"><div>I even&nbsp;could =
write a more simple <a href=3D"http://example.to" target=3D"_blank">example=
..to</a> demonstrate your wrong conclusions. For example</div><div>&nbsp;</d=
iv><div>class A</div><div>{</div><div>private: </div><div>&nbsp;&nbsp; int =
x;</div><div>public:</div><div>&nbsp;&nbsp; A( int i =3D 0 ) : x( i ) {}</d=
iv><div>&nbsp;&nbsp; int get() const { return x; }</div><div>};</div><div>&=
nbsp;</div><div>Does it mean that if function get() uses private member x t=
hat x is the interface of the class?!</div><div>&nbsp;&nbsp; </div><div>&nb=
sp;</div><div><br>=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:</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(2=
04, 204, 204); border-left-width: 1px; border-left-style: solid;">On sab, 2=
013-09-07 at 07:07 -0700, Vlad from Moscow wrote:
<br>&gt; Again you are mistaken. The client code knows nothing about protec=
ted=20
<br>&gt; members of your class. It relies only on the interface you provide=
d. You=20
<br>&gt; confuse the realization with the interface.=20
<br>
<br>I'm sorry, I don't see how I haven't shown that the client code
<br>SneakyFoo that a user of my library would write knows nothing about
<br>Foo's protected member, especially since it uses the member.
<br>
<br>I don't wish to continue this discussion any further, as you don't seem
<br>to be addressing or trying to understand my points, and instead are jus=
t
<br>claiming that I'm wrong without giving any reasoning.
<br>
<br>Best,
<br>Patrick
<br></blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
oWy_EKq3UPcJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"oWy_EKq3UPcJ">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_581_31739817.1378568770794--

.

------=_Part_647_33372396.1378568872731
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

I made a typo. I meant protected members are means of sharing the=20
realization.
=20

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 1
 9:46:10 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Vlad from Moscow =CE=C1=
=D0=C9=D3=C1=CC:

> 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 t=
he=20
> this delegated realization of the underlined container of std:;stack.=20
> Nevertheless this has nothing common with the interface of std::stack. Th=
e=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" <vlad....@mail.ru>
>> To: <std-pr...@isocpp.org>
>> Subject: [std-proposals] Specialization of std::stack for=20
>> std::forward_list
>> 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 deri=
ved=20
>> classes are in general objects of base classes. So there is nothing comm=
on=20
>> with interface. There is common realization.
>> =20
>> Wiyth same effect you could say that private members are also an=20
>> interface because friend functions depend on private members of the=20
>> befriended class. :)]
>> =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 UT=
C+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 =
the=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 expres=
s=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 de=
pend=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" <vlad....@mail.ru>
>>> To: <std-pr...@isocpp.org>
>>> 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 U=
TC+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 protecte=
d=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 see=
m=20
>>>> to be addressing or trying to understand my points, and instead are=20
>>>> 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=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an 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 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
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_647_33372396.1378568872731
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I made a typo. I meant protected members are means of=
 sharing the realization.</div><div>&nbsp;</div><div><br>=D3=D5=C2=C2=CF=D4=
=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=C7., 1</div><div>&nbsp;9:46:10 U=
TC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Vlad from Moscow =CE=C1=D0=C9=D3=
=C1=CC:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>Nevertheles=
s the base class provides some part of the realization to its derived class=
.. One more private members are means of sharing the common realization. Rea=
lization is not the interface. </div><div>&nbsp;</div><div>The interface of=
 class std:;stack does not depend of the underlaying container. It is its r=
ealization that depends on the features of the underlined container. The st=
ack is a logical adstraction and not the "physical interface" as&nbsp;Ville=
 says. It is the underlaying container provides "physical interface" for st=
d:;stack. It is because stack is a logical abstraction std::stack is a cont=
ainer adapter.</div><div>&nbsp;</div><div>std:;stack simply delegates part =
of the realization of its underlaying container to its derived classes. Of =
course derived classes can rely on the this delegated realization of the un=
derlined container of std:;stack. Nevertheless this has nothing common with=
 the interface of std::stack. The interface of std::stack iis not cjanged.<=
/div><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=
=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:</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div style=3D"font-fa=
mily: Calibri,sans-serif; font-size: 12pt;"><div>Friend functions are part =
of the class &nbsp;External code cannot add friends &nbsp;External code can=
 add derived classes.</div><div><br></div><div>Sent from a touchscreen. Ple=
ase excuse the brevity and tpyos.</div><br><div>----- Reply message -----<b=
r>From: "Vlad from Moscow" &lt;<a>vlad....@mail.ru</a>&gt;<br>To: &lt;<a>st=
d-pr...@isocpp.org</a>&gt;<br>Subject: [std-proposals] Specialization of st=
d::stack for std::forward_list<br>Date: Sat, Sep 7, 2013 8:25 AM</div></div=
><br><div dir=3D"ltr"><div>Protected members servers that to share the real=
ization (not the interface) with its derived classes. If two classes share =
the common realization of course they depend on each other. However objects=
 of derived classes are in general objects of base classes. So there is not=
hing common with interface. There is common realization.</div><div>&nbsp;</=
div><div>Wiyth same effect you could say that private members are also an i=
nterface because friend functions depend on private members of the befriend=
ed class. :)]</div><div>&nbsp;</div><div>It is totally wrong approach.</div=
><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=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:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div style=3D"font-family: =
Calibri,sans-serif; font-size: 12pt;"><div>No, because x is private.</div><=
div><br></div><div>If it is possible for code external to the class to depe=
nd on some behavior or member of a class, than that behavior or member is p=
art of the interface of that class. (e.g. something like "push_back increas=
es size by 1" is part of vector's interface, even though there is no way to=
 express that constraint in the language)</div><div><br></div><div>External=
 code can rely on the protected container c by deriving from stack. Therefo=
re, 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 =
interface.</div><div><br></div><div>Sent from a touchscreen. Please excuse =
the brevity and tpyos.</div><br><div>----- Reply message -----<br>From: "Vl=
ad from Moscow" &lt;<a>vlad....@mail.ru</a>&gt;<br>To: &lt;<a>std-pr...@iso=
cpp.org</a>&gt;<br>Subject: [std-proposals] Specialization of std::stack fo=
r std::forward_list<br>Date: Sat, Sep 7, 2013 7:28 AM</div></div><br><div d=
ir=3D"ltr"><div>I even&nbsp;could write a more simple <a href=3D"http://exa=
mple.to" target=3D"_blank">example.to</a> demonstrate your wrong conclusion=
s. For example</div><div>&nbsp;</div><div>class A</div><div>{</div><div>pri=
vate: </div><div>&nbsp;&nbsp; int x;</div><div>public:</div><div>&nbsp;&nbs=
p; A( int i =3D 0 ) : x( i ) {}</div><div>&nbsp;&nbsp; int get() const { re=
turn x; }</div><div>};</div><div>&nbsp;</div><div>Does it mean that if func=
tion get() uses private member x that x is the interface of the class?!</di=
v><div>&nbsp;&nbsp; </div><div>&nbsp;</div><div><br>=D3=D5=C2=C2=CF=D4=C1, =
7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=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:</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding=
-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; =
border-left-style: solid;">On sab, 2013-09-07 at 07:07 -0700, Vlad from Mos=
cow wrote:
<br>&gt; Again you are mistaken. The client code knows nothing about protec=
ted=20
<br>&gt; members of your class. It relies only on the interface you provide=
d. You=20
<br>&gt; confuse the realization with the interface.=20
<br>
<br>I'm sorry, I don't see how I haven't shown that the client code
<br>SneakyFoo that a user of my library would write knows nothing about
<br>Foo's protected member, especially since it uses the member.
<br>
<br>I don't wish to continue this discussion any further, as you don't seem
<br>to be addressing or trying to understand my points, and instead are jus=
t
<br>claiming that I'm wrong without giving any reasoning.
<br>
<br>Best,
<br>Patrick
<br></blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</blockquote></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_647_33372396.1378568872731--

.

------=_Part_630_11089791.1378569239731
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

There are many invented concepts that only confuse readers and have the=20
sense. For example one of such concept is to write definitions of pointers=
=20
in C++ the following way
=20
int* a, b;
=20
Now you have three attempts that to determine whether b is a pointer or=20
not. I give your some prompting: can you be sure that this code is written=
=20
in C++ and not in C#?
=20

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 19:41:10 UTC+4=
 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Ville Voutilainen=20
=CE=C1=D0=C9=D3=C1=CC:

>
>
>
> On 7 September 2013 18:20, Vlad from Moscow <vlad....@mail.ru<javascript:=
>
> > wrote:
>
>> First of all I do not know what is the "physical interface".=20
>>
>
> Feel free to educate yourself, then.
> =20
>
>> You can invent many terms but they have nothing common the original=20
>> meanings of the interface and realization. Private and=20
>>
>
> And those "original meanings" don't map to the c++ meanings 1-to-1,=20
> however much you invent terms that you
> think apply to c++.
>
>
>

--=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_630_11089791.1378569239731
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>There are many invented concepts that only confuse re=
aders and have the sense. For example one of such concept is to write defin=
itions of pointers in C++ the following way</div><div>&nbsp;</div><div>int*=
 a, b;</div><div>&nbsp;</div><div>Now you have three attempts that to deter=
mine whether b is a pointer or not. I give your some prompting: can you be =
sure that this code is written in C++ and not in C#?</div><div>&nbsp;</div>=
<div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=C7., =
19:41:10 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Ville Voutilainen =CE=
=C1=D0=C9=D3=C1=CC:</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br>=
<div><br><br><div class=3D"gmail_quote">On 7 September 2013 18:20, Vlad fro=
m Moscow <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"0uL11ObnbJMJ">vlad....@mail.ru</a>&gt;</span> wrote:=
<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div dir=3D"ltr"><div>First of all I do not kn=
ow what is the "physical interface". </div></div></blockquote><div>
<br></div><div>Feel free to educate yourself, then.<br>&nbsp;<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-l=
eft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bo=
rder-left-style: solid;"><div dir=3D"ltr"><div>You can invent many terms bu=
t they have nothing common the original meanings of the interface and reali=
zation. Private and </div>
</div></blockquote><div><br></div><div>And those "original meanings" don't =
map to the c++ meanings 1-to-1, however much you invent terms that you<br>t=
hink apply to c++.<br><br></div></div><br></div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_630_11089791.1378569239731--

.

------=_Part_686_11361180.1378569317934
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

Again I made a typo. Should be "have no sense".
=20

=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 19:53:59 UTC+4=
 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Vlad from Moscow=20
=CE=C1=D0=C9=D3=C1=CC:

> There are many invented concepts that only confuse readers and have the=
=20
> sense. For example one of such concept is to write definitions of pointer=
s=20
> in C++ the following way
> =20
> int* a, b;
> =20
> Now you have three attempts that to determine whether b is a pointer or=
=20
> not. I give your some prompting: can you be sure that this code is writte=
n=20
> in C++ and not in C#?
> =20
>
> =D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 19:41:10 UTC=
+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Ville Voutilainen=20
> =CE=C1=D0=C9=D3=C1=CC:
>
>>
>>
>>
>> On 7 September 2013 18:20, Vlad from Moscow <vlad....@mail.ru> wrote:
>>
>>> First of all I do not know what is the "physical interface".=20
>>>
>>
>> Feel free to educate yourself, then.
>> =20
>>
>>> You can invent many terms but they have nothing common the original=20
>>> meanings of the interface and realization. Private and=20
>>>
>>
>> And those "original meanings" don't map to the c++ meanings 1-to-1,=20
>> however much you invent terms that you
>> think apply to c++.
>>
>>
>>

--=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_686_11361180.1378569317934
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Again I made a typo. Should be "have no sense".</div>=
<div>&nbsp;</div><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1=
 2013&nbsp;=C7., 19:53:59 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Vlad f=
rom Moscow =CE=C1=D0=C9=D3=C1=CC:</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb=
(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div di=
r=3D"ltr"><div>There are many invented concepts that only confuse readers a=
nd have the sense. For example one of such concept is to write definitions =
of pointers in C++ the following way</div><div>&nbsp;</div><div>int* a, b;<=
/div><div>&nbsp;</div><div>Now you have three attempts that to determine wh=
ether b is a pointer or not. I give your some prompting: can you be sure th=
at this code is written in C++ and not in C#?</div><div>&nbsp;</div><div><b=
r>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013&nbsp;=C7., 19:41:1=
0 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Ville Voutilainen =CE=C1=D0=C9=
=D3=C1=CC:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br><div><br>=
<br><div class=3D"gmail_quote">On 7 September 2013 18:20, Vlad from Moscow =
<span dir=3D"ltr">&lt;<a>vlad....@mail.ru</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div dir=3D"ltr"><div>First of all I do not kn=
ow what is the "physical interface". </div></div></blockquote><div>
<br></div><div>Feel free to educate yourself, then.<br>&nbsp;<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-l=
eft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bo=
rder-left-style: solid;"><div dir=3D"ltr"><div>You can invent many terms bu=
t they have nothing common the original meanings of the interface and reali=
zation. Private and </div>
</div></blockquote><div><br></div><div>And those "original meanings" don't =
map to the c++ meanings 1-to-1, however much you invent terms that you<br>t=
hink apply to c++.<br><br></div></div><br></div></div>
</blockquote></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_686_11361180.1378569317934--

.

--e89a8fb1fa622a310504e5ce198b
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

Let me see if I can clarify the point here.

Being part of the interface means that if something is changed or removed
about the class, other code will break. If tomorrow std::stack decided to
rename the container member "container" instead of "c", then no client
calling member functions or friend functions can break. (Implementations of
the public member functions may break, but those are part of the class
itself, not that class's interface).

However, because the member is protected, not private, an unknowably large
amount of code can be broken, which is outside the control of the author of
stack. Other code can observe that there is a member "c" which is the
container type, and may depend on that member having member functions
"push_back" or "size".

If class A "uses the realization of" class B, then A is using the interface
of B. Anything about B which A can observe is part of B's interface.
Anything A can not observe is not part of B's interface. Derived classes
can observe protected members of a class. As a result, if a class allows
derived classes, protected members are part of the class' interface.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sat, Sep 7, 2013 at 8:55 AM, Vlad from Moscow <vlad.moscow@mail.ru>wrote=
:

> Again I made a typo. Should be "have no sense".
>
>
> =D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 19:53:59 UTC=
+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Vlad from Moscow
> =CE=C1=D0=C9=D3=C1=CC:
>
>> There are many invented concepts that only confuse readers and have the
>> sense. For example one of such concept is to write definitions of pointe=
rs
>> in C++ the following way
>>
>> int* a, b;
>>
>> Now you have three attempts that to determine whether b is a pointer or
>> not. I give your some prompting: can you be sure that this code is writt=
en
>> in C++ and not in C#?
>>
>>
>> =D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 19:41:10 UT=
C+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Ville
>> Voutilainen =CE=C1=D0=C9=D3=C1=CC:
>>
>>>
>>>
>>>
>>> On 7 September 2013 18:20, Vlad from Moscow <vlad....@mail.ru> wrote:
>>>
>>>> First of all I do not know what is the "physical interface".
>>>>
>>>
>>> Feel free to educate yourself, then.
>>>
>>>
>>>> You can invent many terms but they have nothing common the original
>>>> meanings of the interface and realization. Private and
>>>>
>>>
>>> And those "original meanings" don't map to the c++ meanings 1-to-1,
>>> however much you invent terms that you
>>> think apply to c++.
>>>
>>>
>>>  --
>
> ---
> 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/.
>

--=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/.

--e89a8fb1fa622a310504e5ce198b
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Let me see if I can clarify the point here.</div><div=
>=9A</div><div>Being part of the interface means that if something is chang=
ed or removed about the class, other code will break. If tomorrow std::stac=
k decided to rename the container member &quot;container&quot; instead of &=
quot;c&quot;, then no client calling member functions=9Aor friend functions=
 can break. (Implementations of the public member functions may break, but =
those are part of the class itself, not that class&#39;s interface).</div>

<div>=9A</div><div>However, because the member is protected, not private, a=
n unknowably large amount of code can be broken, which is outside the contr=
ol of the author of stack. Other code can observe that there is a member &q=
uot;c&quot; which is the container type, and may depend on that member havi=
ng member functions &quot;push_back&quot; or &quot;size&quot;.</div>

<div>=9A</div><div>If class A &quot;uses the realization of&quot; class B, =
then A is using the interface of B.=9AAnything about B which A can observe =
is part of B&#39;s interface. Anything A can not observe is not part of B&#=
39;s interface. Derived classes can observe protected members of a class. A=
s a result, if a class allows derived classes, protected members are part o=
f the class&#39; interface.</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sat, Sep 7, 2013 at 8:55 AM, Vlad fro=
m Moscow <span dir=3D"ltr">&lt;<a href=3D"mailto:vlad.moscow@mail.ru" targe=
t=3D"_blank">vlad.moscow@mail.ru</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div dir=3D"ltr"><div>Again I made a typo. Should be &quot;have no sense&qu=
ot;.</div><div>=9A</div><div><br>=D3=D5=C2=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=
=C2=D2=D1 2013=9A=C7., 19:53:59 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 =
Vlad from Moscow =CE=C1=D0=C9=D3=C1=CC:</div><div><div class=3D"h5"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1=
ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-sty=
le:solid">

<div dir=3D"ltr"><div>There are many invented concepts that only confuse re=
aders and have the sense. For example one of such concept is to write defin=
itions of pointers in C++ the following way</div><div>=9A</div><div>int* a,=
 b;</div>

<div>=9A</div><div>Now you have three attempts that to determine whether b =
is a pointer or not. I give your some prompting: can you be sure that this =
code is written in C++ and not in C#?</div><div>=9A</div><div><br>=D3=D5=C2=
=C2=CF=D4=C1, 7 =D3=C5=CE=D4=D1=C2=D2=D1 2013=9A=C7., 19:41:10 UTC+4 =D0=CF=
=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Ville Voutilainen =CE=C1=D0=C9=D3=C1=CC:</di=
v>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quot=
e">
On 7 September 2013 18:20, Vlad from Moscow <span dir=3D"ltr">&lt;<a>vlad..=
...@mail.ru</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><div>First of all I do not know what is t=
he &quot;physical interface&quot;. </div>

</div></blockquote><div>
<br></div><div>Feel free to educate yourself, then.<br>=9A<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1=
ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-sty=
le:solid">

<div dir=3D"ltr"><div>You can invent many terms but they have nothing commo=
n the original meanings of the interface and realization. Private and </div=
>
</div></blockquote><div><br></div><div>And those &quot;original meanings&qu=
ot; don&#39;t map to the c++ meanings 1-to-1, however much you invent terms=
 that you<br>think apply to c++.<br><br></div></div><br></div></div>
</blockquote></div></blockquote></div></div></div><div class=3D"HOEnZb"><di=
v class=3D"h5">

<p></p>

-- <br>
=9A<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--e89a8fb1fa622a310504e5ce198b--

.

--047d7bfe97e055424b04e5ce3897
Content-Type: text/plain; charset=ISO-8859-1

On 7 September 2013 20:00, Billy O'Neal <billy.oneal@gmail.com> wrote:

>
>
> If class A "uses the realization of" class B, then A is using the
> interface of B. Anything about B which A can observe is part of B's
> interface.
>


Very much correct. That's also what the physical interface means; the data
members have a certain size,
so changing the size will break the physical interface. And some things
rely on that, like sizeof and
new, so it leads to practical ABI issues, however silent the standard is on
things like ABIs.

--

---
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/.

--047d7bfe97e055424b04e5ce3897
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 7 September 2013 20:00, Billy O&#39;Neal <span dir=3D"ltr">&lt;<=
a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail=
..com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>=A0<div>If class A &quo=
t;uses the realization of&quot; class B, then A is using the interface of B=
..=A0Anything about B which A can observe is part of B&#39;s interface.</div=
>
</div></blockquote><div><br><br></div><div>Very much correct. That&#39;s al=
so what the physical interface means; the data members have a certain size,=
<br></div><div>so changing the size will break the physical interface. And =
some things rely on that, like sizeof and<br>
</div><div>new, so it leads to practical ABI issues, however silent the sta=
ndard is on things like ABIs.<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bfe97e055424b04e5ce3897--

.

--001a11c2a12085f24104e5ce58fe
Content-Type: text/plain; charset=ISO-8859-1

Observing that kind of change is not well defined by the standard, however.
Compilers have long been allowed to insert extra data or otherwise change
the physical implementation of a class, from compiler to compiler, or from
compiler version to compiler version, or from complier setting to compiler
setting.

As far as the standard is concerned, there is no well defined way to
observe those kinds of changes.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sat, Sep 7, 2013 at 10:09 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 7 September 2013 20:00, Billy O'Neal <billy.oneal@gmail.com> wrote:
>
>>
>>
>> If class A "uses the realization of" class B, then A is using the
>> interface of B. Anything about B which A can observe is part of B's
>> interface.
>>
>
>
> Very much correct. That's also what the physical interface means; the data
> members have a certain size,
> so changing the size will break the physical interface. And some things
> rely on that, like sizeof and
> new, so it leads to practical ABI issues, however silent the standard is
> on things like ABIs.
>
>  --
>
> ---
> 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/.
>

--

---
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/.

--001a11c2a12085f24104e5ce58fe
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Observing that kind of change is not well defined by =
the standard, however. Compilers have long been allowed to insert extra dat=
a or otherwise change the physical implementation of a class, from compiler=
 to compiler, or from compiler version to compiler version, or from complie=
r setting to compiler setting.</div>

<div>=A0</div><div>As far as the standard is concerned, there is no well de=
fined way to observe those kinds of changes.</div></div><div class=3D"gmail=
_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div>=
<div>

<a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://git=
hub.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users=
/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/=
billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sat, Sep 7, 2013 at 10:09 AM, Ville V=
outilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.=
com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote"><div class=3D"im">On 7 September 2013 20:00, Billy O&#39;Neal <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank"=
>billy.oneal@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><br>=A0<div>If class A &quot;uses the rea=
lization of&quot; class B, then A is using the interface of B.=A0Anything a=
bout B which A can observe is part of B&#39;s interface.</div>


</div></blockquote><div><br><br></div></div><div>Very much correct. That&#3=
9;s also what the physical interface means; the data members have a certain=
 size,<br></div><div>so changing the size will break the physical interface=
.. And some things rely on that, like sizeof and<br>


</div><div>new, so it leads to practical ABI issues, however silent the sta=
ndard is on things like ABIs.<br></div></div><br></div></div><div class=3D"=
HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2a12085f24104e5ce58fe--

.

--047d7bfe97e09e4e6a04e5ce79e3
Content-Type: text/plain; charset=ISO-8859-1

On 7 September 2013 20:17, Billy O'Neal <billy.oneal@gmail.com> wrote:

> Observing that kind of change is not well defined by the standard,
> however. Compilers have long been allowed to insert extra data or otherwise
> change the physical implementation of a class, from compiler to compiler,
> or from compiler version to compiler version, or from complier setting to
> compiler setting.
>
> As far as the standard is concerned, there is no well defined way to
> observe those kinds of changes.
>
>
>
Sure, the size of a class object may or may not change when changing a size
of a data member. But it's bloody likely
that it does.

--

---
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/.

--047d7bfe97e09e4e6a04e5ce79e3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 7 September 2013 20:17, Billy O&#39;Neal <span dir=3D"ltr">&lt;<=
a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail=
..com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Observing that kind of=
 change is not well defined by the standard, however. Compilers have long b=
een allowed to insert extra data or otherwise change the physical implement=
ation of a class, from compiler to compiler, or from compiler version to co=
mpiler version, or from complier setting to compiler setting.</div>


<div>=A0</div><div>As far as the standard is concerned, there is no well de=
fined way to observe those kinds of changes.</div></div><div class=3D"gmail=
_extra"><div class=3D"im"><br><br></div></div></blockquote><div><br></div><=
div>
Sure, the size of a class object may or may not change when changing a size=
 of a data member. But it&#39;s bloody likely<br>that it does.<br></div></d=
iv><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bfe97e09e4e6a04e5ce79e3--

.

------=_Part_479_1880867704.1437059147563
Content-Type: multipart/alternative;
 boundary="----=_Part_480_142410996.1437059147564"

------=_Part_480_142410996.1437059147564
Content-Type: text/plain; charset=UTF-8

From point of view of pure logic, standard STL-supplied singly linked list
MUST be able to act as underlying implementation of standard STL-supplied
stack (as singly linked list is one of theoretically best ways to do stack).
When I noticed that std::forward_list was added in c++11, my first thought
was: "Oh! They did a great mistake! They had to add std::backward_list
instead! As it's more natural to push/pop at the end, and std::stack
requires it."
But on the other hand, Magnus Fromreide IS RIGHT that "it would be a
strange beast indeed as it won't support insert(iterator, value),
erase(iterator), begin() or end() (but rbegin() and rend())".

So, my conclusion is:

1.
Don't add specialization std::stack<T, std::forward_list<T>>. As it would
be quite unexpected to see front being used in case when with other
containers back is being used.

2.
Don't add std::backward_list: as std::forward_list is already standardized,
and per written by Magnus Fromreide.

3.
Add new adapter template class std::reverse_container<typename
BaseContainer>.
It would be able to work as std::stack<T,
std::reverse_container<std::forward_list<T>>>, unless user will try to
access std::stack::size. However, nowhere in documentation should be stated
that it is for tying std::forward_list and std::stack together. It's just
general purpose adapter.
It tries to publish all STL-stereotypical direction-neutral members of
BaseContainer, and to reverse all STL-stereotypical direction-sensitive
members of BaseContainer (with using std::reverse_iterator when needed).
Accessing a member of std::reverse_container<BaseContainer> that doesn't
have counterpart in BaseContainer causes template instantiation error. But
otherwise it is ok to use std::reverse_container with BaseContainer that
doesn't have all of STL-stereotypical members.

4.
Either add std::forward_list::size member that must act identically to
std::list::size.
Or mark std::list::size member as obsolete/discouraged in documentation.
Because the decision should be the same for std::list and std::forward_list
(at least, I see no reason for different decision on
std::forward_list::size and std::list::size).

Cheers.

On Friday, September 6, 2013 at 8:37:38 PM UTC+3, Vlad from Moscow wrote:
>
> I would like to propose to include specialization of std::stack for
> std::forward_list.
>
> In fact std::forward_list has already all characteristics of a stack.
> There will be only one difference compared with the primary class
> std::stack:  the specialization will not contain member function size()
> because std::forward_list has no such member.
>
> What will you say?
>

--

---
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_480_142410996.1437059147564
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">From point of view of pure logic, standard STL-supplied si=
ngly linked list MUST be able to act as underlying implementation of standa=
rd STL-supplied stack (as singly linked list  is one of theoretically best =
ways to do stack).<br>When I noticed that std::forward_list was added in c+=
+11, my first thought was: &quot;Oh! They did a great mistake! They had to =
add std::backward_list instead! As it&#39;s more natural to push/pop at the=
 end, and std::stack requires it.&quot;<br>But on the other hand, Magnus Fr=
omreide IS RIGHT that &quot;it would be a strange beast indeed as it won&#3=
9;t support insert(iterator, value), erase(iterator), begin() or end() (but=
 rbegin() and rend())&quot;.<br><br>So, my conclusion is:<br><br>1.<br>Don&=
#39;t add specialization std::stack&lt;T, std::forward_list&lt;T&gt;&gt;. A=
s it would be quite unexpected to see front being used in case when with ot=
her containers back is being used.<br><br>2.<br>Don&#39;t add std::backward=
_list: as std::forward_list is already standardized, and per written by Mag=
nus Fromreide.<br><br>3.<br>Add new adapter template class std::reverse_con=
tainer&lt;typename BaseContainer&gt;.<br>It would be able to work as std::s=
tack&lt;T, std::reverse_container&lt;std::forward_list&lt;T&gt;&gt;&gt;, un=
less user will try to access std::stack::size. However, nowhere in document=
ation should be stated that it is for tying std::forward_list and std::stac=
k together. It&#39;s just general purpose adapter.<br>It tries to publish a=
l<code></code><code></code>l STL-stereotypical direction-neutral members of=
 BaseContainer, and to reverse all STL-stereotypical direction-sensitive me=
mbers  of BaseContainer (with using std::reverse_iterator when needed). Acc=
essing a member of std::reverse_container&lt;BaseContainer&gt; that doesn&#=
39;t have counterpart in BaseContainer causes template instantiation error.=
 But otherwise it is ok to use std::reverse_container with BaseContainer th=
at doesn&#39;t have all of STL-stereotypical members.<br><br>4.<br>Either a=
dd std::forward_list::size member that must act identically to std::list::s=
ize.<br>Or mark std::list::size member as obsolete/discouraged in documenta=
tion.<br>Because the decision should be the same for std::list and std::for=
ward_list (at least, I see no reason for different decision on std::forward=
_list::size and std::list::size).<br><br>Cheers.<br><br>On Friday, Septembe=
r 6, 2013 at 8:37:38 PM UTC+3, Vlad from Moscow wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div>I would like to propose to in=
clude specialization of std::stack for std::forward_list. </div><div>=C2=A0=
</div><div>In fact std::forward_list has already all characteristics of a s=
tack. There will be only one difference compared with the primary class std=
::stack:=C2=A0 the specialization will not contain member function size() b=
ecause std::forward_list has no such member.</div><div>=C2=A0</div><div>Wha=
t will you say?</div></div></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_480_142410996.1437059147564--
------=_Part_479_1880867704.1437059147563--

.

------=_Part_176_828721028.1437061221372
Content-Type: multipart/alternative;
 boundary="----=_Part_177_387236219.1437061221372"

------=_Part_177_387236219.1437061221372
Content-Type: text/plain; charset=UTF-8



On Thursday, July 16, 2015 at 6:05:47 PM UTC+3, Sasha Unknown wrote:
>
> From point of view of pure logic, standard STL-supplied singly linked list
> MUST be able to act as underlying implementation of standard STL-supplied
> stack (as singly linked list is one of theoretically best ways to do stack).
> When I noticed that std::forward_list was added in c++11, my first thought
> was: "Oh! They did a great mistake! They had to add std::backward_list
> instead! As it's more natural to push/pop at the end, and std::stack
> requires it."
> But on the other hand, Magnus Fromreide IS RIGHT that "it would be a
> strange beast indeed as it won't support insert(iterator, value),
> erase(iterator), begin() or end() (but rbegin() and rend())".
>
> So, my conclusion is:
>
> 1.
> Don't add specialization std::stack<T, std::forward_list<T>>. As it would
> be quite unexpected to see front being used in case when with other
> containers back is being used.
>

You are dealing with a stack not with lists. And the stack has a
predictable behaviour. It is your choice what underlaying container to use.
In any case it is hidden from the user.


> 2.
> Don't add std::backward_list: as std::forward_list is already
> standardized, and per written by Magnus Fromreide.
>
> Nobody is going to add std::backward_list. However a single linked list
that allows to add elements to the tail is obviously needed. And I
sugessted such a list somewhere here.


> 3.
> Add new adapter template class std::reverse_container<typename
> BaseContainer>.
> It would be able to work as std::stack<T,
> std::reverse_container<std::forward_list<T>>>, unless user will try to
> access std::stack::size. However, nowhere in documentation should be stated
> that it is for tying std::forward_list and std::stack together. It's just
> general purpose adapter.
> It tries to publish all STL-stereotypical direction-neutral members of
> BaseContainer, and to reverse all STL-stereotypical direction-sensitive
> members of BaseContainer (with using std::reverse_iterator when needed).
> Accessing a member of std::reverse_container<BaseContainer> that doesn't
> have counterpart in BaseContainer causes template instantiation error. But
> otherwise it is ok to use std::reverse_container with BaseContainer that
> doesn't have all of STL-stereotypical members.
>
> Insetad of make the life easier you are trying to make the life harder.


> 4.
> Either add std::forward_list::size member that must act identically to
> std::list::size.
> Or mark std::list::size member as obsolete/discouraged in documentation.
> Because the decision should be the same for std::list and
> std::forward_list (at least, I see no reason for different decision on
> std::forward_list::size and std::list::size).
>
> The specialization of std::stack for std:;forward_list may have not data
member  size. But all specializations of std::stack shall have method clear
that I also proposed.

Cheers.
>
> On Friday, September 6, 2013 at 8:37:38 PM UTC+3, Vlad from Moscow wrote:
>>
>> I would like to propose to include specialization of std::stack for
>> std::forward_list.
>>
>> In fact std::forward_list has already all characteristics of a stack.
>> There will be only one difference compared with the primary class
>> std::stack:  the specialization will not contain member function size()
>> because std::forward_list has no such member.
>>
>> What will you say?
>>
>

--

---
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_177_387236219.1437061221372
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, July 16, 2015 at 6:05:47 PM UTC+3, Sasha Unknown wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;"><div dir=3D"ltr">From point of view of pure l=
ogic, standard STL-supplied singly linked list MUST be able to act as under=
lying implementation of standard STL-supplied stack (as singly linked list =
 is one of theoretically best ways to do stack).<br>When I noticed that std=
::forward_list was added in c++11, my first thought was: &quot;Oh! They did=
 a great mistake! They had to add std::backward_list instead! As it&#39;s m=
ore natural to push/pop at the end, and std::stack requires it.&quot;<br>Bu=
t on the other hand, Magnus Fromreide IS RIGHT that &quot;it would be a str=
ange beast indeed as it won&#39;t support insert(iterator, value), erase(it=
erator), begin() or end() (but rbegin() and rend())&quot;.<br><br>So, my co=
nclusion is:<br><br>1.<br>Don&#39;t add specialization std::stack&lt;T, std=
::forward_list&lt;T&gt;&gt;. As it would be quite unexpected to see front b=
eing used in case when with other containers back is being used.<br></div><=
/blockquote><div><br></div><div>You are dealing with a stack not with lists=
.. And the stack has a predictable behaviour. It is your choice what underla=
ying container to use. In any case it is hidden from the user. =C2=A0</div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">2.<br>Don&#3=
9;t add std::backward_list: as std::forward_list is already standardized, a=
nd per written by Magnus Fromreide.<br><br></div></blockquote><div>Nobody i=
s=C2=A0going to add std::backward_list. However a single linked list that a=
llows to add elements to the tail is obviously needed. And I sugessted such=
 a list somewhere here.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-col=
or: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">=
<div dir=3D"ltr">3.<br>Add new adapter template class std::reverse_containe=
r&lt;typename BaseContainer&gt;.<br>It would be able to work as std::stack&=
lt;T, std::reverse_container&lt;std::forward_list&lt;T&gt;&gt;&gt;, unless =
user will try to access std::stack::size. However, nowhere in documentation=
 should be stated that it is for tying std::forward_list and std::stack tog=
ether. It&#39;s just general purpose adapter.<br>It tries to publish al<cod=
e></code><code></code>l STL-stereotypical direction-neutral members of Base=
Container, and to reverse all STL-stereotypical direction-sensitive members=
  of BaseContainer (with using std::reverse_iterator when needed). Accessin=
g a member of std::reverse_container&lt;BaseContainer&gt; that doesn&#39;t =
have counterpart in BaseContainer causes template instantiation error. But =
otherwise it is ok to use std::reverse_container with BaseContainer that do=
esn&#39;t have all of STL-stereotypical members.<br><br></div></blockquote>=
<div>Insetad of make the life easier you are trying=C2=A0to make the life h=
arder.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204,=
 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">=
4.<br>Either add std::forward_list::size member that must act identically t=
o std::list::size.<br>Or mark std::list::size member as obsolete/discourage=
d in documentation.<br>Because the decision should be the same for std::lis=
t and std::forward_list (at least, I see no reason for different decision o=
n std::forward_list::size and std::list::size).<br><br></div></blockquote><=
div>The specialization of std::stack for std:;forward_list may have not dat=
a member=C2=A0=C2=A0size. But all specializations of std::stack shall have =
method clear that I also proposed.</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border=
-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style:=
 solid;"><div dir=3D"ltr">Cheers.<br><br>On Friday, September 6, 2013 at 8:=
37:38 PM UTC+3, Vlad from Moscow wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb=
(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div di=
r=3D"ltr"><div>I would like to propose to include specialization of std::st=
ack for std::forward_list. </div><div>=C2=A0</div><div>In fact std::forward=
_list has already all characteristics of a stack. There will be only one di=
fference compared with the primary class std::stack:=C2=A0 the specializati=
on will not contain member function size() because std::forward_list has no=
 such member.</div><div>=C2=A0</div><div>What will you say?</div></div></bl=
ockquote></div></blockquote>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_177_387236219.1437061221372--
------=_Part_176_828721028.1437061221372--

.

While I like the idea of making standard stack to work with standard
singly-linked list too, the way that you propose (adding
surprisingly-working specialization) seems unacceptable to me.

--

---
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/.

.