--001a114b44744c48490545ce172f
Content-Type: text/plain; charset=UTF-8

Surely the rationale is that shadowing occurs by the innermost symbol of
any outer ones, just like in any other context.

The problem then is one of QoI, as frequently, not an issue - and certainly
not an inconsistency - with the language.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFimejx_MPQerKdFNxWAz6zkf%2BWeQdbPZSEQo_zQeyqUg%40mail.gmail.com.

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

<div dir=3D"ltr"><div>Surely the rationale is that shadowing occurs by the =
innermost symbol of any outer ones, just like in any other context.<br><br>=
</div>The problem then is one of QoI, as frequently, not an issue - and cer=
tainly not an inconsistency - with the language.<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFimejx_MPQerKdFNxWAz6zkf%2BWeQ=
dbPZSEQo_zQeyqUg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFimejx_M=
PQerKdFNxWAz6zkf%2BWeQdbPZSEQo_zQeyqUg%40mail.gmail.com</a>.<br />

--001a114b44744c48490545ce172f--

.

On 11 January 2017 at 09:08, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Hi,
>
>
> Could someone give me a good use case, the rationale, for hiding data
> members
>
> http://melpon.org/wandbox/permlink/mXshdsg9A3dY53Jn
>
> I understand that the language allows shadowing a variable in an inner scope
> of a function, but hiding base data members seems to me more risky.
>
> In the same way we have override when we are overriding a virtual function
> and we will get an error if there is no virtual function to override, we
> could have some kind of "hide"  data member. The compiler could then report
> a warning when the data member is hidden without an explicit "hide".
>
> I believe the same could apply to hidden overloaded functions.


See http://open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2852.html
and in particular the [[hiding]] part. The later paper
http://open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3206.htm
provides the current context-sensitive keyword approach, from which the
"new" part was dropped before C++11 shipped. Mostly because
1) it wasn't requested by NBs
2) it's deemed far less necessary
3) implementations already warn
4) it's a lot of work specification-wise and implementation-wise to provide both
a way to check for hiding and to selectively turn it off, for
questionable benefit.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYoazQc_Vcb%3D3vOARpGJtXuhpnXA9%3DgZzh%2BuOkbx5b0YQ%40mail.gmail.com.

.

Le 11/01/2017 =C3=A0 10:36, Ville Voutilainen a =C3=A9crit :
> On 11 January 2017 at 09:08, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr> wrote:
>> Hi,
>>
>>
>> Could someone give me a good use case, the rationale, for hiding data
>> members
>>
>> http://melpon.org/wandbox/permlink/mXshdsg9A3dY53Jn
>>
>> I understand that the language allows shadowing a variable in an inner s=
cope
>> of a function, but hiding base data members seems to me more risky.
>>
>> In the same way we have override when we are overriding a virtual functi=
on
>> and we will get an error if there is no virtual function to override, we
>> could have some kind of "hide"  data member. The compiler could then rep=
ort
>> a warning when the data member is hidden without an explicit "hide".
>>
>> I believe the same could apply to hidden overloaded functions.
>
> See http://open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2852.html
> and in particular the [[hiding]] part. The later paper
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3206.htm
> provides the current context-sensitive keyword approach, from which the
> "new" part was dropped before C++11 shipped.
Thanks Ville.  The "new" specifier corresponds quite closely to what I=20
was looking for.
Glad to see other had the same concern.
> Mostly because
> 1) it wasn't requested by NBs
> 2) it's deemed far less necessary
I agree it is a less usual error.
> 3) implementations already warn
Could you tell me which flags I need with  gcc or clang to get a warning=20
in this case.
> 4) it's a lot of work specification-wise and implementation-wise to provi=
de both
> a way to check for hiding and to selectively turn it off, for
> questionable benefit.
>
I'm sure this would some work, but given that there were already some=20
wording and that compilers are already reporting warnings, doesn't this=20
means that the works is almost already done for the big part?


Vicente

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0ef91f31-6e0f-cd37-c570-582f23ddd208%40wanadoo.f=
r.

.

On 11 January 2017 at 20:30, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
>> 3) implementations already warn
>
> Could you tell me which flags I need with  gcc or clang to get a warning in
> this case.

I don't know. See for example
https://msdn.microsoft.com/en-us/library/4b76ty10.aspx

>>
>> 4) it's a lot of work specification-wise and implementation-wise to
>> provide both
>> a way to check for hiding and to selectively turn it off, for
>> questionable benefit.
> I'm sure this would some work, but given that there were already some
> wording and that compilers are already reporting warnings, doesn't this
> means that the works is almost already done for the big part?


I would guess there are large parts of the work not done, especially
if you want to provide
the "check hiding declarations in this class" facility, and you want
to support members that
are not member functions. That was also a reason to drop that part, we
didn't think we have
enough time to do all that work for C++11, and doubted the benefit.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZZ%3DOOgDcZJ10JEM24OAXbubFEBtm4zNoUtogmofqzwpg%40mail.gmail.com.

.

------=_Part_10_802295980.1484184422493
Content-Type: multipart/alternative;
 boundary="----=_Part_11_666245453.1484184422493"

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

On Tuesday, January 10, 2017 at 11:08:11 PM UTC-8, Vicente J. Botet Escriba=
=20
wrote:
>
> Hi,
>
>
> Could someone give me a good use case, the rationale, for hiding data=20
> members
>
> http://melpon.org/wandbox/permlink/mXshdsg9A3dY53Jn
>
> I understand that the language allows shadowing a variable in an inner=20
> scope of a function, but hiding base data members seems to me more risky.
>
> In the same way we have override when we are overriding a virtual functio=
n=20
> and we will get an error if there is no virtual function to override, we=
=20
> could have some kind of "hide"  data member. The compiler could then repo=
rt=20
> a warning when the data member is hidden without an explicit "hide".
>
> I believe the same could apply to hidden overloaded functions.
>

Sounds like maybe a place for a compiler warning, but I don't see any=20
reason to change the language here.
Can you explain a bit more about what behavior you expected from that test=
=20
case?

B defines an "a =3D new A()" but does not use it
C defines an "a =3D nullptr" and then calls "a->test()", which of course is=
 UB

I also tried the obvious mutation of your code, which is to move the=20
definition of doit() into B. Then:

B defines an "a =3D new A()" and then calls "a->test()", which works fine
C defines an "a =3D nullptr" but does not use it

Nothing unexpected happened.
It would be surprising to me if C's definition of "a" were somehow=20
accessible within B (without the `virtual` keyword, anyway); but that=20
didn't happen, so I wasn't surprised.
What did you expect, and what was the surprising observation?

=E2=80=93Arthur

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e34e51f9-e16d-4f63-a1c5-0e36eb4e44a4%40isocpp.or=
g.

------=_Part_11_666245453.1484184422493
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, January 10, 2017 at 11:08:11 PM UTC-8, Vicente=
 J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <p><font size=3D"+1">Hi,</font></p>
    <p><font size=3D"+1"><br>
      </font></p>
    <p><font size=3D"+1">Could someone give me a good use case, the
        rationale, for hiding data members</font></p>
    <p><a href=3D"http://melpon.org/wandbox/permlink/mXshdsg9A3dY53Jn" targ=
et=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.g=
oogle.com/url?q\x3dhttp%3A%2F%2Fmelpon.org%2Fwandbox%2Fpermlink%2FmXshdsg9A=
3dY53Jn\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE-a1KHXXBQgyWJRDCHlOdU2KuaR=
A&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?=
q\x3dhttp%3A%2F%2Fmelpon.org%2Fwandbox%2Fpermlink%2FmXshdsg9A3dY53Jn\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE-a1KHXXBQgyWJRDCHlOdU2KuaRA&#39;;return =
true;">http://melpon.org/wandbox/<wbr>permlink/mXshdsg9A3dY53Jn</a></p>
    <p>I understand that the language allows shadowing a variable in an
      inner scope of a function, but hiding base data members seems to
      me more risky.</p>
    <p>In the same way we have override when we are overriding a virtual
      function and we will get an error if there is no virtual function
      to override, we could have some kind of &quot;hide&quot;=C2=A0 data m=
ember. The
      compiler could then report a warning when the data member is
      hidden without an explicit &quot;hide&quot;.</p>
    <p>I believe the same could apply to hidden overloaded functions.</p></=
div></blockquote><div><br></div><div>Sounds like maybe a place for a compil=
er warning, but I don&#39;t see any reason to change the language here.</di=
v><div>Can you explain a bit more about what behavior you expected from tha=
t test case?</div><div><br></div><div>B defines an &quot;a =3D new A()&quot=
; but does not use it</div><div>C defines an &quot;a =3D nullptr&quot; and =
then calls &quot;a-&gt;test()&quot;, which of course is UB</div><div><br></=
div><div>I also tried the obvious mutation of your code, which is to move t=
he definition of doit() into B. Then:</div><div><br></div><div>B defines an=
 &quot;a =3D new A()&quot; and then calls &quot;a-&gt;test()&quot;, which w=
orks fine</div><div>C defines an &quot;a =3D nullptr&quot; but does not use=
 it</div><div><br></div><div>Nothing unexpected happened.</div><div>It woul=
d be surprising to me if C&#39;s definition of &quot;a&quot; were somehow a=
ccessible within B (without the `virtual` keyword, anyway); but that didn&#=
39;t happen, so I wasn&#39;t surprised.</div><div>What did you expect, and =
what was the surprising observation?</div><div><br></div><div>=E2=80=93Arth=
ur</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e34e51f9-e16d-4f63-a1c5-0e36eb4e44a4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e34e51f9-e16d-4f63-a1c5-0e36eb4e44a4=
%40isocpp.org</a>.<br />

------=_Part_11_666245453.1484184422493--

------=_Part_10_802295980.1484184422493--

.

--001a1136a4228ea00b0545dec4e1
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 11, 2017 at 6:30 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

>
> 3) implementations already warn
>>
> Could you tell me which flags I need with  gcc or clang to get a warning
> in this case.
>
>
At a guess, -Wshadow ?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhG23zanZG_qMH%2Bq3czFd%3D3eUZdAOx8BGw9ybnJf3q7d7A%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jan 11, 2017 at 6:30 PM, Vicente J. Botet Escriba <span dir=3D"=
ltr">&lt;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vice=
nte.botet@wanadoo.fr</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
3) implementations already warn<br>
</blockquote>
Could you tell me which flags I need with=C2=A0 gcc or clang to get a warni=
ng in this case.<span class=3D""><br><br></span></blockquote><div><br></div=
><div>At a guess, -Wshadow ? <br></div></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhG23zanZG_qMH%2Bq3czFd%3D3eUZdA=
Ox8BGw9ybnJf3q7d7A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhG23zan=
ZG_qMH%2Bq3czFd%3D3eUZdAOx8BGw9ybnJf3q7d7A%40mail.gmail.com</a>.<br />

--001a1136a4228ea00b0545dec4e1--

.

On 12 January 2017 at 07:12, D. B. <db0451@gmail.com> wrote:
>
>
> On Wed, Jan 11, 2017 at 6:30 PM, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr> wrote:
>>
>>
>>> 3) implementations already warn
>>
>> Could you tell me which flags I need with  gcc or clang to get a warning
>> in this case.
>>
>
> At a guess, -Wshadow ?


No, but by all means keep on guessing if you think that's somehow entertaining.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbv_CtCOgQi8sEpqen082t1nZX5g2df044v_JbGVm3MQg%40mail.gmail.com.

.

--001a114cd8e683c22e0545e06f28
Content-Type: text/plain; charset=UTF-8

Wow, sorry for trying. I used that to reveal some warnings about shadowing
in certain scopes, where I can't currently be sure whether those included
member variables, and although I couldn't test it right now thought I'd
post it in case it included class members and would be useful.

I won't bother trying next time.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhE0EVryEmaQOA%3DSAdTfZwbu3no9obrpN5xHgSe0GupcUA%40mail.gmail.com.

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

<div dir=3D"ltr"><div>Wow, sorry for trying. I used that to reveal some war=
nings about shadowing in certain scopes, where I can&#39;t currently be sur=
e whether those included member variables, and although I couldn&#39;t test=
 it right now thought I&#39;d post it in case it included class members and=
 would be useful.<br><br></div>I won&#39;t bother trying next time.<br></di=
v>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhE0EVryEmaQOA%3DSAdTfZwbu3no9ob=
rpN5xHgSe0GupcUA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhE0EVryEm=
aQOA%3DSAdTfZwbu3no9obrpN5xHgSe0GupcUA%40mail.gmail.com</a>.<br />

--001a114cd8e683c22e0545e06f28--

.

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

On Thursday, 12 January 2017 07:12:11 UTC, D. B. wrote:
>
> Wow, sorry for trying. I used that to reveal some warnings about shadowin=
g=20
> in certain scopes, where I can't currently be sure whether those included=
=20
> member variables, and although I couldn't test it right now thought I'd=
=20
> post it in case it included class members and would be useful.
>

For the record: -Wshadow (clang, gcc, icc) and C4458 (MSVC) warn on local=
=20
variables shadowing various names including class non-static data members.=
=20
They do not warn on derived class NSDMs shadowing base class NSDMs.

At the risk of throwing some cold water on the thread, I think that if=20
compiler vendors are not supplying warnings for derived-base NSDM=20
shadowing/hiding that suggests that it is not considered much of a problem=
=20
in practice.

--=20


This e-mail together with any attachments (the "Message") is confidential=
=20
and may contain privileged information. If you are not the intended=20
recipient or if you have received this e-mail in error, please notify the=
=20
sender immediately and permanently delete this Message from your system.=20
 Do not copy, disclose or distribute the information contained in this=20
Message.

Maven Investment Partners Ltd (No. 07511928), Maven Derivatives Ltd (No.=20
07511840) , MVN Asset Management Limited (No. 09659116), Maven Europe Ltd=
=20
(No. 08966593), Maven Derivatives Asia Limited (No.10361312) & Maven=20
Securities Holding Ltd (No. 07505438) are registered as companies in=20
England and Wales and their registered address is Level 3, 6 Bevis Marks,=
=20
London EC3A 7BA, United Kingdom. The companies=E2=80=99 VAT No. is 13553901=
6. Maven=20
Asia (Hong Kong) Ltd (No. 2444041) is registered in Hong Kong and its=20
registered address is 20/F, 198 Wellington St, Hong Kong.  Only Maven=20
Derivatives Ltd and MVN Asset Management Limited are authorised and=20
regulated by the Financial Conduct Authority (Maven Derivatives Ltd FRN:=20
607267, MVN Asset Management Limited FRN: 714429)

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/fa78dedc-53cc-41ac-90e5-a537c139d18a%40isocpp.or=
g.

------=_Part_198_419787531.1484232504551
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, 12 January 2017 07:12:11 UTC, D. B.  wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Wow, sorry=
 for trying. I used that to reveal some warnings about shadowing in certain=
 scopes, where I can&#39;t currently be sure whether those included member =
variables, and although I couldn&#39;t test it right now thought I&#39;d po=
st it in case it included class members and would be useful.<br></div></div=
></blockquote><div><br></div><div>For the record: -Wshadow (clang, gcc, icc=
) and C4458 (MSVC) warn on local variables shadowing various names includin=
g class non-static data members. They do not warn on derived class NSDMs sh=
adowing base class NSDMs.</div><div><br></div><div>At the risk of throwing =
some cold water on the thread, I think that if compiler vendors are not sup=
plying warnings for derived-base NSDM shadowing/hiding that suggests that i=
t is not considered much of a problem in practice.</div></div>
<br>
<p><font color=3D"#222222" face=3D"Arial, sans-serif" size=3D"2">This e-mai=
l together with any attachments (the &quot;Message&quot;) is confidential a=
nd may contain privileged information. If you are not the intended recipien=
t or if you have received this e-mail in error, please notify the sender im=
mediately and permanently delete this Message from your system. =C2=A0Do no=
t copy, disclose or distribute the information contained in this Message.</=
font></p><p><span style=3D"color:rgb(34,34,34);font-family:Arial,sans-serif=
"><font size=3D"2">Maven Investment Partners Ltd (No. 07511928), Maven Deri=
vatives Ltd (No. 07511840) , MVN Asset Management Limited (No. 09659116), M=
aven Europe Ltd (No. 08966593), Maven Derivatives Asia Limited (No.10361312=
) &amp; Maven Securities Holding Ltd (No. 07505438) are registered as compa=
nies in England and Wales and their registered address is Level 3, 6 Bevis =
Marks, London EC3A 7BA, United Kingdom. The companies=E2=80=99 VAT No. is 1=
35539016. Maven Asia (Hong Kong) Ltd (No. 2444041) is registered in Hong Ko=
ng and its registered address is 20/F, 198 Wellington St, Hong Kong. =C2=A0=
Only Maven Derivatives Ltd and MVN Asset Management Limited are authorised =
and regulated by the Financial Conduct Authority (Maven Derivatives Ltd FRN=
: 607267, MVN Asset Management Limited FRN: 714429)</font></span></p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fa78dedc-53cc-41ac-90e5-a537c139d18a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fa78dedc-53cc-41ac-90e5-a537c139d18a=
%40isocpp.org</a>.<br />

------=_Part_198_419787531.1484232504551--

.

------=_Part_201_305500166.1484232995158
Content-Type: multipart/alternative;
 boundary="----=_Part_202_991718563.1484232995158"

------=_Part_202_991718563.1484232995158
Content-Type: text/plain; charset=UTF-8


On Thursday, 12 January 2017 07:12:11 UTC, D. B. wrote:
>
> Wow, sorry for trying. I used that to reveal some warnings about shadowing
> in certain scopes, where I can't currently be sure whether those included
> member variables, and although I couldn't test it right now thought I'd
> post it in case it included class members and would be useful.
>

For the record: -Wshadow (clang, gcc, icc) and C4458 (MSVC) warn on local
variables shadowing various names including class non-static data members.
They do not warn on derived class NSDMs shadowing base class NSDMs.

At the risk of throwing some cold water on the thread, I think that if
compiler vendors are not supplying warnings for derived-base NSDM
shadowing/hiding that suggests that it is not considered much of a problem
in practice.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/057cd38b-d210-47e3-8974-c63479c3a984%40isocpp.org.

------=_Part_202_991718563.1484232995158
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Thursday, 12 January 2017 07:12:11 UTC, D. B.  wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Wow, s=
orry for trying. I used that to reveal some warnings about shadowing in cer=
tain scopes, where I can&#39;t currently be sure whether those included mem=
ber variables, and although I couldn&#39;t test it right now thought I&#39;=
d post it in case it included class members and would be useful.<br></div><=
/div></blockquote><div><br></div><div>For the record: -Wshadow (clang, gcc,=
 icc) and C4458 (MSVC) warn on local variables shadowing various names incl=
uding class non-static data members. They do not warn on derived class NSDM=
s shadowing base class NSDMs.</div><div><br></div><div>At the risk of throw=
ing some cold water on the thread, I think that if compiler vendors are not=
 supplying warnings for derived-base NSDM shadowing/hiding that suggests th=
at it is not considered much of a problem in practice.=C2=A0</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/057cd38b-d210-47e3-8974-c63479c3a984%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/057cd38b-d210-47e3-8974-c63479c3a984=
%40isocpp.org</a>.<br />

------=_Part_202_991718563.1484232995158--

------=_Part_201_305500166.1484232995158--

.

This is a multi-part message in MIME format.
--------------30ACDDCCEC2EE6F0AC02ECDE
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 12/01/2017 =C3=A0 15:48, edward.catmur@mavensecurities.com a =C3=A9crit =
:
> On Thursday, 12 January 2017 07:12:11 UTC, D. B. wrote:
>
>     Wow, sorry for trying. I used that to reveal some warnings about
>     shadowing in certain scopes, where I can't currently be sure
>     whether those included member variables, and although I couldn't
>     test it right now thought I'd post it in case it included class
>     members and would be useful.
>
>
> For the record: -Wshadow (clang, gcc, icc) and C4458 (MSVC) warn on=20
> local variables shadowing various names including class non-static=20
> data members. They do not warn on derived class NSDMs shadowing base=20
> class NSDMs.
>
Thanks, this is what I was aware of.
> At the risk of throwing some cold water on the thread, I think that if=20
> compiler vendors are not supplying warnings for derived-base NSDM=20
> shadowing/hiding that suggests that it is not considered much of a=20
> problem in practice.
You are surely right. I've found this kind of hiding code only once in=20
my life.

I believe I would have to satisfy myself with a clang-tidy check.

Vicente

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9ac2f030-6453-00c6-a578-78e8029ce639%40wanadoo.f=
r.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 12/01/2017 =C3=A0 15:48, <a
        class=3D"moz-txt-link-abbreviated"
        href=3D"mailto:edward.catmur@mavensecurities.com">edward.catmur@mav=
ensecurities.com</a>
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:fa78dedc-53cc-41ac-90e5-a537c139d18a@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">On Thursday, 12 January 2017 07:12:11 UTC, D. B.
        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>Wow, sorry for trying. I used that to reveal some
              warnings about shadowing in certain scopes, where I can't
              currently be sure whether those included member variables,
              and although I couldn't test it right now thought I'd post
              it in case it included class members and would be useful.<br>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>For the record: -Wshadow (clang, gcc, icc) and C4458 (MSVC)
          warn on local variables shadowing various names including
          class non-static data members. They do not warn on derived
          class NSDMs shadowing base class NSDMs.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    Thanks, this is what I was aware of.<br>
    <blockquote
      cite=3D"mid:fa78dedc-53cc-41ac-90e5-a537c139d18a@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>At the risk of throwing some cold water on the thread, I
          think that if compiler vendors are not supplying warnings for
          derived-base NSDM shadowing/hiding that suggests that it is
          not considered much of a problem in practice.</div>
      </div>
    </blockquote>
    You are surely right. I've found this kind of hiding code only once
    in my life.<br>
    <br>
    I believe I would have to satisfy myself with a clang-tidy check.<br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9ac2f030-6453-00c6-a578-78e8029ce639%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9ac2f030-6453-00c6-a578-78e8029ce639=
%40wanadoo.fr</a>.<br />

--------------30ACDDCCEC2EE6F0AC02ECDE--

.